Hi Yeshwant,

Apologies for my delayed reply.  We have noted your approval on the AUTH48 page 
<https://www.rfc-editor.org/auth48/rfc9695>.  If possible, we would appreciate 
a confirmation directly from Chris that the document is also ready for 
publication. 

Thanks for your help! 
RFC Editor/sg

> On Jan 17, 2025, at 8:06 AM, Yeshwant Muthusamy <yeshw...@yeshvik.com> wrote:
> 
> Hi Sandy,
> 
> Chris and I have reviewed the diff files and updates and we are fine with the 
> final version.
> 
> The document is APPROVED from the authors' perspective.
> 
> Please let me know if there are any other actions for us.
> 
> Thanks,
> Yeshwant
> 
> Yeshwant Muthusamy, Ph.D.
> Owner and Principal
> Yeshvik Solutions, LLC
> www.yeshvik.com
> +1 469-854-9836
> yeshw...@yeshvik.com
> 
> On Thu, Jan 16, 2025, 9:08 PM Sandy Ginoza <sgin...@staff.rfc-editor.org> 
> wrote:
> Hi Yeshwant, Chris,
> 
> Thank you for your review and for updating the XML.  We have updated the 
> document - thank you for your explanations.  Note that we updated the new 
> references to reflect accurate title information and include additional 
> author or organization information, as needed.  Please review the current 
> files and let us know if additional updates are needed or if you approve the 
> RFC for publication. 
>    https://www.rfc-editor.org/authors/rfc9695.xml
>    https://www.rfc-editor.org/authors/rfc9695.txt
>    https://www.rfc-editor.org/authors/rfc9695.pdf
>    https://www.rfc-editor.org/authors/rfc9695.html
> 
> AUTH48 diffs (highlights recent updates): 
>    https://www.rfc-editor.org/authors/rfc9695-auth48diff.html
>    https://www.rfc-editor.org/authors/rfc9695-auth48rfcdiff.html (side by 
> side)
> 
> Comprehensive diffs: 
>    https://www.rfc-editor.org/authors/rfc9695-diff.html
>    https://www.rfc-editor.org/authors/rfc9695-rfcdiff.html (side by side)
> 
> Thank you,
> RFC Editor/sg
> 
> 
> 
> > On Jan 15, 2025, at 9:21 AM, Yeshwant Muthusamy <yeshw...@yeshvik.com> 
> > wrote:
> > 
> > Sandy,
> > 
> > Please let me know if there is anything else needed from the authors (Chris 
> > and me). We are done with our changes/comments. You should have the revised 
> > XML file that I sent in the previous email.
> > 
> > Thanks,
> > Yeshwant
> > 
> > 
> > Yeshwant Muthusamy, Ph.D.
> > Owner and Principal
> > Yeshvik Solutions, LLC
> > www.yeshvik.com
> > +1 469-854-9836
> > yeshw...@yeshvik.com
> > 
> > 
> > 
> > On Fri, Jan 10, 2025 at 3:17 PM Yeshwant Muthusamy <yeshw...@yeshvik.com> 
> > wrote:
> > Sandy, Others,
> > 
> > Attached please find the XML source with the authors' comments and changes, 
> > in response to the comments marked [rfced] by the RFC Editors.
> > 
> > FWIW, we've also included the revised output files (.txt and .html), 
> > generated using xml2rfc -v3, reflecting all the changes made (with the 
> > exception of the deleting the Terminology section - we have left that for 
> > the Editors).
> > 
> > Authors' responses/comments/notes are clearly marked within the comment 
> > sections in the attached XML document. Examples: [AUTHORS' RESPONSE], 
> > [AUTHORS' NOTE], etc. 
> > 
> > Please let me know if something is unclear or if we have missed something.
> > 
> > Thanks for your patience.
> > 
> > Yeshwant
> > 
> > 
> > 
> > Yeshwant Muthusamy, Ph.D.
> > Owner and Principal
> > Yeshvik Solutions, LLC
> > www.yeshvik.com
> > +1 469-854-9836
> > yeshw...@yeshvik.com
> > 
> > 
> > 
> > On Fri, Jan 10, 2025 at 1:03 PM Sandy Ginoza <sgin...@staff.rfc-editor.org> 
> > wrote:
> > Hi Yeshwant,
> > 
> > We will wait to hear from you and Chris - thank you for the update. 
> > 
> > Thank you,
> > RFC Editor/sg
> > 
> > > On Jan 10, 2025, at 10:55 AM, Yeshwant Muthusamy <yeshw...@yeshvik.com> 
> > > wrote:
> > > 
> > > Sandy,
> > > 
> > > I completed my changes/revisions based on the Editors' comments. I have 
> > > sent them to my co-author, Chris Ullrich, for his review and additions, 
> > > if any (as we are not in the same location). I hope to hear back from 
> > > Chris today. We will get back to you as soon as possible.
> > > 
> > > Thanks for your patience.
> > > 
> > > Yeshwant
> > > 
> > > 
> > > 
> > > Yeshwant Muthusamy, Ph.D.
> > > Owner and Principal
> > > Yeshvik Solutions, LLC
> > > www.yeshvik.com
> > > +1 469-854-9836
> > > yeshw...@yeshvik.com
> > > 
> > > 
> > > 
> > > On Fri, Jan 10, 2025 at 12:51 PM Sandy Ginoza 
> > > <sgin...@staff.rfc-editor.org> wrote:
> > > Authors,
> > > 
> > > We do not believe we have heard from you regarding the questions below.  
> > > Please let us know how we may resolve the items listed below.
> > > 
> > > Thank you,
> > > RFC Editor/sg
> > > 
> > > > On Dec 23, 2024, at 11:12 PM, rfc-edi...@rfc-editor.org wrote:
> > > > 
> > > > Authors,
> > > > 
> > > > While reviewing this document during AUTH48, please resolve (as 
> > > > necessary) 
> > > > the following questions, which are also in the XML file.
> > > > 
> > > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in
> > > > the title) for use on https://www.rfc-editor.org/search. -->
> > > > 
> > > > 
> > > > 2) <!-- [rfced] We do believe the capitalized keywords are used in the 
> > > > RFC. 
> > > > Please review and let us know if any of the capitalized keywords should 
> > > > be 
> > > > used.  Otherwise, we will remove the Terminology section and related 
> > > > references. 
> > > > 
> > > > Original: 
> > > > 1.1.  Terminology
> > > > 
> > > >   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
> > > >   SHOULD,SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in
> > > >   this document are to be interpreted as described in BCP 14 [RFC2119]
> > > >   [RFC8174] when, and only when, they appear in all capitals, as shown
> > > >   here.
> > > > 
> > > > -->
> > > > 
> > > > 
> > > > 3) <!-- [rfced] Would you like to include references for the sales data 
> > > > listed? 
> > > > 
> > > > Original:
> > > >   *  iPhone (206+ million units sold in 2020): native support for
> > > >      haptic encoded data
> > > > 
> > > >   *  Android (1.38+ billion units sold in 2020): API support of haptic
> > > >      buffers
> > > > 
> > > >   *  W3C (HTML vibration API [W3C-Vibration]): Optionally supported in
> > > >      mobile web browsers.  W3C has also defined vibration extensions
> > > >      for gamepads [W3C-Gamepad]
> > > > 
> > > >   *  Game consoles (39+ million units sold in 2019): MS Xbox, Sony
> > > >      PlayStation, Nintendo Switch, etc.
> > > > 
> > > >   *  XR devices (9+ million units sold in 2019): OpenXR haptic API
> > > > -->
> > > > 
> > > > 
> > > > 4) <!-- [rfced] May we expand CE as Customer Edge?
> > > > 
> > > > Original:
> > > >   Since they represent the majority of CE devices, a strong
> > > >   case can be made for 'haptics' as a top-level media type.
> > > > -->
> > > > 
> > > > 
> > > > 5) <!-- [rfced] The text indicates the subtypes have not been 
> > > > registered by IANA, but ivs is being registered by this document.  
> > > > Please 
> > > > consider whether updates are needed.  Is it correct that ivs is the 
> > > > only 
> > > > type mentioned in Section 2.5 being registered at this time?  
> > > > Note: likely different, but we see ogg has been registered as an 
> > > > application subtype (see 
> > > > https://www.iana.org/assignments/media-types/application/ogg).
> > > > 
> > > > Original: 
> > > >   While these subtypes have *not* been registered with IANA or
> > > >   standardized (yet), the prevalence of these haptic data formats in a
> > > >   large number of devices around the world, pre-dating the
> > > >   standardization of haptic tracks in ISOBMFF, provides a compelling
> > > >   argument for 'haptics' to be designated as a top-level media type:
> > > > 
> > > > Perhaps remove mention of "not been registered with IANA?
> > > >   While these subtypes have *not* been standardized (yet), 
> > > >   the prevalence of these haptic data formats in a
> > > >   large number of devices around the world, pre-dating the
> > > >   standardization of haptic tracks in ISOBMFF, provides a compelling
> > > >   argument for 'haptics' to be designated as a top-level media type:
> > > > -->
> > > > 
> > > > 
> > > > 6) <!-- [rfced] hmpg and hjif are being registered by this document.  
> > > > Please consider how this text can be updated for accuracy.  
> > > > 
> > > > Original:
> > > >   These
> > > >   codes are not registered yet, but the plan is indeed to standardize
> > > >   these haptic coding formats in the near future.  Once standardized,
> > > >   these types should also be registered as subtypes of the 'haptics'
> > > >   top-level media type:
> > > > -->
> > > > 
> > > > 
> > > > 7) <!-- [rfced] For ease of the reader, we have updated "FourCC codes" 
> > > > as 
> > > > "FourCCs (four-character codes)".  Alternatively, may we replace 
> > > > "FourCC" 
> > > > with "four-character codes", because this is the only place FourCC is 
> > > > used?  
> > > > Please review. 
> > > > 
> > > > Original:
> > > >   The MPEG ISOBMFF proposal included an informative annex of known
> > > >   haptic coding formats with proposed FourCC codes for them.
> > > > 
> > > > Current:
> > > >   The MPEG ISOBMFF proposal included an informative annex of known
> > > >   haptic coding formats with proposed FourCCs (four-character codes)
> > > >   for them.
> > > > -->
> > > > 
> > > > 
> > > > 8) <!-- [rfced] Should "URLL" be "URLLC"?  If correct, may we expand 
> > > > URLLC 
> > > > as "Ultra-Reliable Low-Latency Communication (URLLC)"?  If not, please 
> > > > indicate how URLL should be expanded. 
> > > > 
> > > > Original:
> > > >   *  IEEE P1918.1.1 vibrotactile coding standard [IEEE-P191811] being
> > > >      developed under the IEEE Tactile Internet initiative as part of
> > > >      the 5G URLL profile.
> > > > -->
> > > > 
> > > > 
> > > > 9) <!-- [rfced] [ISOBMFF-IS] This reference is the most current
> > > > version of this standard, but there is a note on this version that 
> > > > states
> > > > "Expected to be replaced by ISO/IEC DIS 14496-12.2 within the coming
> > > > months."  Please let us know if publication of this document should be 
> > > > delayed until ISO/IEC DIS 14496-12.2 is formally published 
> > > > (see https://www.iso.org/standard/85596.html). 
> > > > 
> > > > Original:
> > > >   [ISOBMFF-IS]
> > > >              "ISO/IEC 14496-12 (7th Edition) Information technology —   
> > > >                          
> > > >              Coding of audio-visual objects — Part 12: ISO base media   
> > > >                          
> > > >              file format", <https://www.iso.org/standard/83102.html>.
> > > > -->
> > > > 
> > > > 
> > > > 10) <!-- [rfced] [IEEE-P191811] The original URL redirected to the
> > > > search page for IEEE Standards: https://standards.ieee.org/standard/. 
> > > > We have updated the reference as described on 
> > > > https://ieeexplore.ieee.org/document/10555007.  The status is marked as 
> > > > "Inactive - Draft".  Please review and let us know if any updates are 
> > > > needed. 
> > > > 
> > > >   [IEEE-P191811]
> > > >              "P1918.1.1 - Haptic Codecs for the Tactile Internet",
> > > >              <https://standards.ieee.org/project/1918_1_1.html>.
> > > > -->
> > > > 
> > > > 
> > > > 11) <!-- [rfced] Please review the "Inclusive Language" portion of the 
> > > > online Style Guide 
> > > > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> > > > and let us know if any changes are needed.  Updates of this nature 
> > > > typically result in more precise language, which is helpful for readers.
> > > > 
> > > > For example, please consider whether the following should be updated: 
> > > >   native
> > > > 
> > > > Note that native can be ambiguous because it is subjective.  Perhaps 
> > > > "built-in" would work? 
> > > > -->
> > > > 
> > > > 
> > > > Thank you.
> > > > 
> > > > RFC Editor
> > > > 
> > > > 
> > > > On Dec 23, 2024, at 11:03 PM, rfc-edi...@rfc-editor.org wrote:
> > > > 
> > > > *****IMPORTANT*****
> > > > 
> > > > Updated 2024/12/23
> > > > 
> > > > RFC Author(s):
> > > > --------------
> > > > 
> > > > Instructions for Completing AUTH48
> > > > 
> > > > Your document has now entered AUTH48.  Once it has been reviewed and 
> > > > approved by you and all coauthors, it will be published as an RFC.  
> > > > If an author is no longer available, there are several remedies 
> > > > available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> > > > 
> > > > You and you coauthors are responsible for engaging other parties 
> > > > (e.g., Contributors or Working Group) as necessary before providing 
> > > > your approval.
> > > > 
> > > > Planning your review 
> > > > ---------------------
> > > > 
> > > > Please review the following aspects of your document:
> > > > 
> > > > *  RFC Editor questions
> > > > 
> > > >   Please review and resolve any questions raised by the RFC Editor 
> > > >   that have been included in the XML file as comments marked as 
> > > >   follows:
> > > > 
> > > >   <!-- [rfced] ... -->
> > > > 
> > > >   These questions will also be sent in a subsequent email.
> > > > 
> > > > *  Changes submitted by coauthors 
> > > > 
> > > >   Please ensure that you review any changes submitted by your 
> > > >   coauthors.  We assume that if you do not speak up that you 
> > > >   agree to changes submitted by your coauthors.
> > > > 
> > > > *  Content 
> > > > 
> > > >   Please review the full content of the document, as this cannot 
> > > >   change once the RFC is published.  Please pay particular attention to:
> > > >   - IANA considerations updates (if applicable)
> > > >   - contact information
> > > >   - references
> > > > 
> > > > *  Copyright notices and legends
> > > > 
> > > >   Please review the copyright notice and legends as defined in
> > > >   RFC 5378 and the Trust Legal Provisions 
> > > >   (TLP – https://trustee.ietf.org/license-info).
> > > > 
> > > > *  Semantic markup
> > > > 
> > > >   Please review the markup in the XML file to ensure that elements of  
> > > >   content are correctly tagged.  For example, ensure that <sourcecode> 
> > > >   and <artwork> are set correctly.  See details at 
> > > >   <https://authors.ietf.org/rfcxml-vocabulary>.
> > > > 
> > > > *  Formatted output
> > > > 
> > > >   Please review the PDF, HTML, and TXT files to ensure that the 
> > > >   formatted output, as generated from the markup in the XML file, is 
> > > >   reasonable.  Please note that the TXT will have formatting 
> > > >   limitations compared to the PDF and HTML.
> > > > 
> > > > 
> > > > Submitting changes
> > > > ------------------
> > > > 
> > > > To submit changes, please reply to this email using ‘REPLY ALL’ as all 
> > > > the parties CCed on this message need to see your changes. The parties 
> > > > include:
> > > > 
> > > >   *  your coauthors
> > > > 
> > > >   *  rfc-edi...@rfc-editor.org (the RPC team)
> > > > 
> > > >   *  other document participants, depending on the stream (e.g., 
> > > >      IETF Stream participants are your working group chairs, the 
> > > >      responsible ADs, and the document shepherd).
> > > > 
> > > >   *  auth48archive@rfc-editor.org, which is a new archival mailing list 
> > > >      to preserve AUTH48 conversations; it is not an active discussion 
> > > >      list:
> > > > 
> > > >     *  More info:
> > > >        
> > > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> > > > 
> > > >     *  The archive itself:
> > > >        https://mailarchive.ietf.org/arch/browse/auth48archive/
> > > > 
> > > >     *  Note: If only absolutely necessary, you may temporarily opt out 
> > > >        of the archiving of messages (e.g., to discuss a sensitive 
> > > > matter).
> > > >        If needed, please add a note at the top of the message that you 
> > > >        have dropped the address. When the discussion is concluded, 
> > > >        auth48archive@rfc-editor.org will be re-added to the CC list and 
> > > >        its addition will be noted at the top of the message. 
> > > > 
> > > > You may submit your changes in one of two ways:
> > > > 
> > > > An update to the provided XML file
> > > > — OR —
> > > > An explicit list of changes in this format
> > > > 
> > > > Section # (or indicate Global)
> > > > 
> > > > OLD:
> > > > old text
> > > > 
> > > > NEW:
> > > > new text
> > > > 
> > > > You do not need to reply with both an updated XML file and an explicit 
> > > > list of changes, as either form is sufficient.
> > > > 
> > > > We will ask a stream manager to review and approve any changes that seem
> > > > beyond editorial in nature, e.g., addition of new text, deletion of 
> > > > text, 
> > > > and technical changes.  Information about stream managers can be found 
> > > > in 
> > > > the FAQ.  Editorial changes do not require approval from a stream 
> > > > manager.
> > > > 
> > > > 
> > > > Approving for publication
> > > > --------------------------
> > > > 
> > > > To approve your RFC for publication, please reply to this email stating
> > > > that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> > > > as all the parties CCed on this message need to see your approval.
> > > > 
> > > > 
> > > > Files 
> > > > -----
> > > > 
> > > > The files are available here:
> > > >   https://www.rfc-editor.org/authors/rfc9695.xml
> > > >   https://www.rfc-editor.org/authors/rfc9695.html
> > > >   https://www.rfc-editor.org/authors/rfc9695.pdf
> > > >   https://www.rfc-editor.org/authors/rfc9695.txt
> > > > 
> > > > Diff file of the text:
> > > >   https://www.rfc-editor.org/authors/rfc9695-diff.html
> > > >   https://www.rfc-editor.org/authors/rfc9695-rfcdiff.html (side by side)
> > > > 
> > > > Diff of the XML: 
> > > >   https://www.rfc-editor.org/authors/rfc9695-xmldiff1.html
> > > > 
> > > > 
> > > > Tracking progress
> > > > -----------------
> > > > 
> > > > The details of the AUTH48 status of your document are here:
> > > >   https://www.rfc-editor.org/auth48/rfc9695
> > > > 
> > > > Please let us know if you have any questions.  
> > > > 
> > > > Thank you for your cooperation,
> > > > 
> > > > RFC Editor
> > > > 
> > > > --------------------------------------
> > > > RFC9695 (draft-ietf-mediaman-haptics-05)
> > > > 
> > > > Title            : The 'haptics' Top-level Media Type
> > > > Author(s)        : Y. Muthusamy, C. Ullrich
> > > > WG Chair(s)      : Harald T. Alvestrand
> > > > Area Director(s) : Murray Kucherawy, Orie Steele
> > > > 
> > > > 
> > > 
> > 
> 

-- 
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org

Reply via email to