Hi Harald, Murray,

Murray, please review the changes and let us know if you approve. 
Harald, thanks for your review and reply.  I’m sure it helps Murray make his 
decision. 

Thanks,
RFC Editor/sg

> On Jan 17, 2025, at 12:42 AM, Harald Alvestrand <har...@alvestrand.no> wrote:
> 
> Speaking as WG chair, I find the changes to be acceptable, and deem that they 
> do not impact the WG consensus to go forward with the document.
> 
> Harald
> 
> On 1/17/25 04:10, Sandy Ginoza wrote:
>> Hi Murray,
>> 
>> Would you please review the changes in the AUTH48 diff and let us know if 
>> you approve?  They are likely ok, but I’d prefer to err on the side of 
>> caution.
>> 
>>> 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)
>> Thanks,
>> RFC Editor/sg
>> 
>> 
>> 
>>> On Jan 16, 2025, at 7:06 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