[auth48] Re: [AD] Corrected: AUTH48 in markdown: RFC-to-be 9993 <draft-ietf-avtcore-rtp-haptics-14> for your review

[Karen Moore <[e-mail]>]

Hi Gorry, 

Thank you for providing your approval (noted at <https://www.rfc-editor.org/auth48/rfc9993>).

Authors, we will now work on the conversion of MD to XML, and we will get back to you shortly.

Best regards,

Karen Moore
RFC Production Center

> On May 24, 2026, at 6:20 AM, Gorry Fairhurst <[e-mail]> wrote:
> 
> On 22/05/2026 02:26, Karen Moore wrote:
>> Dear Hyunsik and *Gorry (AD),
>> 
>> Thank you for providing your approval - we have noted it on the status page for this document (https://www.rfc-editor.org/auth48/rfc9993)  We will now work on the conversion of MD to XML, and we will get back to you shortly.
>> 
>> * Gorry, please review the changes made to Figure 9 (Section 5.3.3), and let us know if you approve. The changes can be viewed in this file: https://www.rfc-editor.org/authors/rfc9993-auth48diff.html.
> 
> I see the "RTP Payload Header" is now consistent in Figures 8 and 9, and the definition in Figure 3.
> 
> I believe this to be correct, and approve.
> 
> Gorry
> 
>> 
>> 
>> —Files (please refresh)—
>> 
>> Updated MD file:
>> https://www.rfc-editor.org/authors/rfc9993.md
>> 
>> Updated output files:
>> https://www.rfc-editor.org/authors/rfc9993.html
>> https://www.rfc-editor.org/authors/rfc9993.pdf
>> https://www.rfc-editor.org/authors/rfc9993.txt
>> 
>> Diff files of the text:
>> https://www.rfc-editor.org/authors/rfc9993-diff.html (all changes)
>> https://www.rfc-editor.org/authors/rfc9993-rfcdiff.html (all changes side by side)
>> https://www.rfc-editor.org/authors/rfc9993-lastdiff.html (only last changes)
>> https://www.rfc-editor.org/authors/rfc9993-lastrfcdiff.html (only last changes side by side)
>> https://www.rfc-editor.org/authors/rfc9993-auth48diff.html (AUTH48 changes)
>> https://www.rfc-editor.org/authors/rfc9993-auth48rfcdiff.html (AUTH48 changes side by side)
>> 
>> Diff files of the kramdown:
>> https://www.rfc-editor.org/authors/rfc9993-md-diff.html (all changes)
>> https://www.rfc-editor.org/authors/rfc9993-md-rfcdiff.html (all changes side by side)
>> https://www.rfc-editor.org/authors/rfc9993-md-lastdiff.html (only last changes)
>> https://www.rfc-editor.org/authors/rfc9993-md-lastrfcdiff.html (only last changes side by side)
>> https://www.rfc-editor.org/authors/rfc9993-md-auth48diff.html (AUTH48 changes)
>> https://www.rfc-editor.org/authors/rfc9993-md-auth48rfcdiff.html (AUTH48 changes side by side)
>> 
>> For the AUTH48 status of this document, please see:
>> https://www.rfc-editor.org/auth48/rfc9993
>> 
>> Best regards,
>> 
>> Karen Moore
>> RFC Production Center
>> 
>>> On May 21, 2026, at 5:34 PM, Hyunsik Yang <[e-mail]> wrote:
>>> 
>>> Dear Karen,
>>> I approve all changes.
>>> 
>>> Thanks
>>> Best regards
>>> 
>>> Get Outlook for iOS
>>> From: Karen Moore <[e-mail]>
>>> Sent: Thursday, May 21, 2026 8:26:06 PM
>>> To: Hyunsik Yang <[e-mail]>; Xavier De Foy <[e-mail]>
>>> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
>>> Subject: Re: [auth48] Corrected: AUTH48 in markdown: RFC-to-be 9993 <draft-ietf-avtcore-rtp-haptics-14> for your review   Dear Hyunsik and Xavier,
>>> 
>>> Thank you for providing the updated MD file. This change is now reflected in our files - please review. Xavier, we have noted your approval at https://www.rfc-editor.org/auth48/rfc9993.
>>> 
>>> Hyunsik, please let us know if you approve the document in its current form or if any further updates are needed. Once we receive your approval, we will perform the conversion step.
>>> 
>>> —Files (please refresh)—
>>> 
>>> Updated MD file:
>>> https://www.rfc-editor.org/authors/rfc9993.md
>>> 
>>> Updated output files:
>>> https://www.rfc-editor.org/authors/rfc9993.html
>>> https://www.rfc-editor.org/authors/rfc9993.pdf
>>> https://www.rfc-editor.org/authors/rfc9993.txt
>>> 
>>> Diff files of the text:
>>> https://www.rfc-editor.org/authors/rfc9993-diff.html (all changes)
>>> https://www.rfc-editor.org/authors/rfc9993-rfcdiff.html (all changes side by side)
>>> https://www.rfc-editor.org/authors/rfc9993-lastdiff.html (only last changes)
>>> https://www.rfc-editor.org/authors/rfc9993-lastrfcdiff.html (only last changes side by side)
>>> https://www.rfc-editor.org/authors/rfc9993-auth48diff.html (AUTH48 changes)
>>> https://www.rfc-editor.org/authors/rfc9993-auth48rfcdiff.html (AUTH48 changes side by side)
>>> 
>>> Diff files of the kramdown:
>>> https://www.rfc-editor.org/authors/rfc9993-md-diff.html (all changes)
>>> https://www.rfc-editor.org/authors/rfc9993-md-rfcdiff.html (all changes side by side)
>>> https://www.rfc-editor.org/authors/rfc9993-md-lastdiff.html (only last changes)
>>> https://www.rfc-editor.org/authors/rfc9993-md-lastrfcdiff.html (only last changes side by side)
>>> https://www.rfc-editor.org/authors/rfc9993-md-auth48diff.html (AUTH48 changes)
>>> https://www.rfc-editor.org/authors/rfc9993-md-auth48rfcdiff.html (AUTH48 changes side by side)
>>> 
>>> For the AUTH48 status of this document, please see:
>>> https://www.rfc-editor.org/auth48/rfc9993
>>> 
>>> Best regards,
>>> 
>>> Karen Moore
>>> RFC Production Center
>>> 
>>> 
>>>> On May 21, 2026, at 3:40 PM, Hyunsik Yang <[e-mail]> wrote:
>>>> 
>>>> We agreed your update.  But we found that there is one more small update.
>>>> Please see the detail below.
>>>>  In figure9,  we changed (Cond.) to TS Offset. Because  “.)” make different figure when it represent as a PDF.
>>>>  I attached MD file too.
>>>>  Thanks.
>>>> Best regards,  From: Karen Moore <[e-mail]>
>>>> Sent: Thursday, May 21, 2026 5:41 PM
>>>> To: Hyunsik Yang <[e-mail]>; Xavier De Foy <[e-mail]>
>>>> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
>>>> Subject: Re: [auth48] Corrected: AUTH48 in markdown: RFC-to-be 9993 <draft-ietf-avtcore-rtp-haptics-14> for your review
>>>>  Dear Hyunsik,
>>>> 
>>>> Thank you for providing the updated MD file. Our files have been updated to reflect these changes. Also note that we fixed the formatting of the “ver” entry in Section 6.1 as requested.
>>>> 
>>>> Please review and let us know if any further changes are needed or if you approve the document in its current form. Once approvals are received from you and your coauthor, we will convert the MD file to XML.
>>>> 
>>>> —Files (please refresh)—
>>>> 
>>>> Updated MD file:
>>>> https://www.rfc-editor.org/authors/rfc9993.md
>>>> 
>>>> Updated output files:
>>>> https://www.rfc-editor.org/authors/rfc9993.html
>>>> https://www.rfc-editor.org/authors/rfc9993.pdf
>>>> https://www.rfc-editor.org/authors/rfc9993.txt
>>>> 
>>>> Diff files of the text:
>>>> https://www.rfc-editor.org/authors/rfc9993-diff.html (all changes)
>>>> https://www.rfc-editor.org/authors/rfc9993-rfcdiff.html (all changes side by side)
>>>> https://www.rfc-editor.org/authors/rfc9993-auth48diff.html (AUTH48 changes)
>>>> https://www.rfc-editor.org/authors/rfc9993-auth48rfcdiff.html (AUTH48 changes side by side)
>>>> 
>>>> Diff files of the kramdown:
>>>> https://www.rfc-editor.org/authors/rfc9993-md-diff.html (all changes)
>>>> https://www.rfc-editor.org/authors/rfc9993-md-rfcdiff.html (all changes side by side)
>>>> https://www.rfc-editor.org/authors/rfc9993-md-auth48diff.html (AUTH48 changes)
>>>> https://www.rfc-editor.org/authors/rfc9993-md-auth48rfcdiff.html (AUTH48 changes side by side)
>>>> 
>>>> For the AUTH48 status of this document, please see:
>>>> https://www.rfc-editor.org/auth48/rfc9993
>>>> 
>>>> Best regards,
>>>> 
>>>> Karen Moore
>>>> RFC Production Center
>>>> 
>>>> 
>>>>> On May 21, 2026, at 1:30 PM, Hyunsik Yang <[e-mail]> wrote:
>>>>> 
>>>>> Hello all,  Thanks for the review.
>>>>> While reviewing the draft, we found several points that could be updated to improve the content. I attached the MD file, and you can also find a summary below.
>>>>>  1) Author info change (removing the dot)
>>>>> OLD:
>>>>> Ins: HS. Yang  NEW: Ins: HS Yang
>>>>>   2) Section 5.2 (semantic -> semantics)
>>>>> OLD:
>>>>> The semantic of individual MIHS layers are not specified and are left for the application to assign.
>>>>> NEW:
>>>>> The semantics of individual MIHS layers are not specified and are left for the application to assign.
>>>>>  3) Section 5.4 (unit -> units)
>>>>> OLD:
>>>>> Whether this behavior is acceptable or not is application dependent, and the application can configure the encoder to generate MIHS unit of lengths with the appropriate variation.
>>>>> NEW:
>>>>> Whether this behavior is acceptable or not is application dependent, and the application can configure the encoder to generate MIHS units with lengths that have the appropriate variation.
>>>>>  4) Section 6.2 (details -> detail)
>>>>> OLD:
>>>>> maxlod:
>>>>> : This parameter indicates the maximum level of details (LODs) to use for the avatar(s).
>>>>> NEW:
>>>>> maxlod:
>>>>> : This parameter indicates the maximum level of detail (LOD) to use for the avatar(s).
>>>>>  5) Section 7.1 (adding a space)
>>>>> OLD:
>>>>> A typical sample rate is 8000Hz.
>>>>> NEW:
>>>>> A typical sample rate is 8000 Hz.
>>>>>  6) Figure 5.  (adding a space)
>>>>> OLD:
>>>>> (a) single unit      (b)fragmentation unit (c) aggregation packet
>>>>> NEW:
>>>>> (a) single unit      (b) fragmentation unit (c) aggregation packet
>>>>>  7) Section 10.1 (fix link)
>>>>> OLD:
>>>>> Optional parameters:
>>>>> : See {{sdp-registration}} of RFC 9993
>>>>>  NEW:
>>>>> Optional parameters:
>>>>> : See {{optional-param}} of RFC 9993.
>>>>>  8) Section 10.1 (media/haptics -> haptics/hmpg)
>>>>> OLD:
>>>>> The following entries identify the updates to the 'media/haptics' registration:
>>>>> NEW:
>>>>> The following entries identify the updates to the 'haptics/hmpg' registration:
>>>>>  9) Figure8 (fixed the RTP payload header length to fit 8 bits)
>>>>> OLD:
>>>>>         0                   1                   2                   3
>>>>>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |                          RTP Header                           |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |        RTP Payload Header     |       MIHS Unit 1 Size        |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |                           MIHS Unit 1                         |
>>>>>        |                                                               |
>>>>>        :                                                               :
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |        MIHS Unit 2 Size     |                                 |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 |
>>>>>        |                           MIHS Unit 2                         |
>>>>>        |                                                               |
>>>>>        |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |                               |...OPTIONAL RTP Padding        |
>>>>>        +-------------------------------+-------------------------------+
>>>>> NEW
>>>>>         0                   1                   2                   3
>>>>>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |                          RTP Header                           |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |RTP Payl. Head.|         MIHS Unit 1 Size      |               |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
>>>>>        |                           MIHS Unit 1                         |
>>>>>        |                                                               |
>>>>>        :                                                               :
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |        MIHS Unit 2 Size     |                                 |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 |
>>>>>        |                           MIHS Unit 2                         |
>>>>>        |                                                               |
>>>>>        |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |                               |...OPTIONAL RTP Padding        |
>>>>>        +-------------------------------+-------------------------------+
>>>>>  10) Figure9 (fixed the RTP payload header length to fit 8 bits, and the TS Offset header to fit 16 bits, as indicated in the text)
>>>>> OLD:         0                   1                   2                   3
>>>>>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |                          RTP Header                           |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |        RTP Payload Header     |       MIHS Unit 1 Size        |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |                           TS Offset           |               |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
>>>>>        |                           MIHS Unit 1                         |
>>>>>        |                                                               |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |       MIHS Unit 2 Size        |            TS Offset          |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |   TS Offset   |                                               |
>>>>>        |-+-+-+-+-+-+-+-+                                               |
>>>>>        |                          MIHS Unit 2                          |
>>>>>        |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |                               |...OPTIONAL RTP Padding        |
>>>>>        +-------------------------------+-------------------------------+
>>>>> NEW:         0                   1                   2                   3
>>>>>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |                          RTP Header                           |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |RTP Payl. Head.|         MIHS Unit 1 Size      |   TS Offset   |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |  (contd.)     |                                               |
>>>>>        +-+-+-+-+-+-+-+-+                                               |
>>>>>        |                           MIHS Unit 1                         |
>>>>>        |                                                               |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |       MIHS Unit 2 Size        |          TS Offset            |
>>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |                                                               |
>>>>>        |                          MIHS Unit 2                          |
>>>>>        |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>        |                               |...OPTIONAL RTP Padding        |
>>>>>        +-------------------------------+-------------------------------+
>>>>>  11) Section 6.1 (removed "is an integer that", to revert to the -14 draft wording)
>>>>> OLD:
>>>>> dvctypes:
>>>>> : This parameter is an integer that indicates, using a comma-separated list, the types of actuators. The device type is defined in {{ISO.IEC.23090-31}}: MPEG_haptics.reference_device object.type is a string that may contain the value "LRA", "VCA", "ERM", "Piezo", or "Unknown".
>>>>>  NEW:
>>>>> dvctypes:
>>>>> : This parameter indicates, using a comma-separated list, the types of actuators. The device type is defined in {{ISO.IEC.23090-31}}: MPEG_haptics.reference_device object.type is a string that may contain the value "LRA", "VCA", "ERM", "Piezo", or "Unknown".
>>>>>  12)  In 6.1, the parameter name "ver" is displayed on its own line, while the other parameter names are on the same line as the description. Maybe the format should be modified to display all the parameters in a consistent way.
>>>>>  Thanks.
>>>>> Best regards,  -----Original Message-----
>>>>> From: Karen Moore <[e-mail]>
>>>>> Sent: Wednesday, May 20, 2026 2:31 PM
>>>>> To: Hyunsik Yang <[e-mail]>; Xavier De Foy <[e-mail]>
>>>>> Cc: [e-mail]; [e-mail]; [e-mail];[e-mail]; [e-mail]; [e-mail]
>>>>> Subject: Re: [auth48] Corrected: AUTH48 in markdown: RFC-to-be 9993 <draft-ietf-avtcore-rtp-haptics-14> for your review
>>>>>  Dear Hyunsik,
>>>>>  Thank you for your reply.  We have updated our files accordingly.  Note that we updated one instance of “body-part-mask” to “body part mask”. Please let us know of any concerns.
>>>>>  Please review the contents of the document carefully as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document’s contents in its current form. We will await approvals from each author prior to moving forward with formatting updates.
>>>>>  For details of the AUTH48 process in kramdown-rfc (including the two-part approval process), see https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc.
>>>>>  --Files--
>>>>> Note that it may be necessary for you to refresh your browser to view the most recent version.
>>>>>  Updated MD file: https://www.rfc-editor.org/authors/rfc9993.md
>>>>>  Updated output files:
>>>>> https://www.rfc-editor.org/authors/rfc9993.html
>>>>> https://www.rfc-editor.org/authors/rfc9993.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9993.txt
>>>>>  Diff files of the text:
>>>>> https://www.rfc-editor.org/authors/rfc9993-diff.html (all changes) https://www.rfc-editor.org/authors/rfc9993-rfcdiff.html (all changes side by side) https://www.rfc-editor.org/authors/rfc9993-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9993-auth48rfcdiff.html (AUTH48 changes side by side)
>>>>>  Diff files of the kramdown: https://www.rfc-editor.org/authors/rfc9993-md-diff.html (all changes) https://www.rfc-editor.org/authors/rfc9993-md-rfcdiff.html (all changes side by side)https://www.rfc-editor.org/authors/rfc9993-md-auth48diff.html (AUTH48 changes)https://www.rfc-editor.org/authors/rfc9993-md-auth48rfcdiff.html (AUTH48 changes side by side)
>>>>>  For the AUTH48 status of this document, please see:
>>>>> https://www.rfc-editor.org/auth48/rfc9993
>>>>>  Best regards,
>>>>>  Karen Moore
>>>>> RFC Production Center
>>>>>  > On May 19, 2026, at 11:58 AM, Hyunsik Yang via auth48archive <[e-mail]> wrote:
>>>>>>> Dear RFC Editors,
>>>>>>> We have added comments for all of your questions.
>>>>>> Please check our answers for each question.
>>>>>>> Thanks.
>>>>>> Best regards,
>>>>>>> -----Original Message-----
>>>>>> From: [e-mail] <[e-mail]>
>>>>>> Sent: Monday, May 18, 2026 4:57 PM
>>>>>> To: Hyunsik Yang <[e-mail]>; Xavier De Foy
>>>>>> <[e-mail]>
>>>>>> Cc: [e-mail]; [e-mail];
>>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>>> [e-mail]
>>>>>> Subject: Re: Corrected: AUTH48 in markdown: RFC-to-be 9993
>>>>>> <draft-ietf-avtcore-rtp-haptics-14> for your review
>>>>>>> Authors,
>>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
>>>>>>> 1) <!--[rfced] FYI: We updated the short title that spans the header of the PDF file as shown below (full title fits the space).
>>>>>>> Original:
>>>>>>   RTP-Payload-Haptic
>>>>>>> Current:
>>>>>>   RTP Payload Format for Haptics
>>>>>> --> Thanks, we confirmed this.
>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use onhttps://www.rfc-editor.org/search.
>>>>>> --> touch /  tactile /  vibrotactile / kinesthetic
>>>>>>>> 3) <!--[rfced] FYI: In Figure 1, we adjusted the spacing of the middle box to include "Temporal Unit" on one line. Please let us know of any objections.
>>>>>> --> Thanks, we confirmed this.
>>>>>>>> 4) <!--[rfced] In Figure 2, should "(TS)" be added after "Timestamp" to correspond with the entry for timestamp and for consistency with the two terms that appear below it in the figure?
>>>>>>> Original:
>>>>>>   Timestamp
>>>>>>> Perhaps:
>>>>>>   Timestamp (TS)
>>>>>> --> Thanks, we confirmed this.
>>>>>>>> 5) <!--[rfced] We note different list styles in Sections 5.1, 5.2, and
>>>>>> 5.3.2. May we make these lists consistent by using the format shown
>>>>>> below?  (See the text for more examples.)
>>>>>>> Original:
>>>>>> (Section 5.1)
>>>>>>    Marker bit (M): 1 bit. The marker bit ...
>>>>>>    Timestamp (TS): 32 bits. A timestamp ...
>>>>>>> (Section 5.2)
>>>>>>    D (Dependency, 1 bit): This field indicates ...
>>>>>>    UT (Unit Type, 3 bits): This field indicates ...
>>>>>>> Perhaps:
>>>>>> (Section 5.1)
>>>>>>    M (Marker bit): 1 bit. The marker bit ...
>>>>>>    TS (Timestamp): 32 bits. A timestamp ...
>>>>>>> (Section 5.2)
>>>>>>    D (Dependency): 1 bit. This field indicates ...
>>>>>>    UT (Unit Type): 3 bits. This field indicates ...
>>>>>> --> Thanks, we confirmed this.
>>>>>>>> 6) <!--[rfced] We note two uppercase forms of "Haptic" in Sections 5.2 and 5.4. Are these correct as is, or should they be made lowercase for consistency?
>>>>>>> Current:
>>>>>>   The RTP payload header follows the RTP header.  Figure 3 describes
>>>>>>   the RTP payload header for Haptic.
>>>>>>>   In some multimedia conference scenarios using an RTP video mixer
>>>>>>   (e.g., when adding or selecting a new source), it is recommended to
>>>>>>   use Full Intra Request (FIR) feedback messages [RFC5104] with Haptics.
>>>>>> --> Yes, changing to lowercase “h” is fine in these two cases.  Additionally, we noticed that “for Haptic” (without s) appears 4 times, including once in the text (mentioned in “Current:” above) and 3 times in figure titles. In these 4 occurrences, “for Haptic” should be replaced with “for Haptics” (in figure titles) or “for haptics” (in text).
>>>>>>>> 7) <!--[rfced] FYI: In Figure 9, we moved the bit ruler over one space to the right to get the correct alignment (this is consistent with the other figures that contain bit rulers). Please let us know of any objections.
>>>>>> --> Thanks, we confirmed this.
>>>>>>>> 8) <!--[rfced] In the list in section 6.1, please clarify "may hold values among" (3 instances). Does this mean "may contain the values"? Also, is "or" (before "Custom") correct, or should it be "and/or"?
>>>>>>> One example
>>>>>>> Original:
>>>>>>   The avatar type is defined in [ISO.IEC.23090-31]:
>>>>>>   MPEG_haptics.avatar object.type is a string which may hold values
>>>>>>   among "Vibration", "Pressure", "Temperature", "Custom".
>>>>>>> Perhaps:
>>>>>>   The avatar type is defined in [ISO.IEC.23090-31]:
>>>>>>   MPEG_haptics.avatar object.type is a string that may contain the
>>>>>>   values "Vibration", "Pressure", "Temperature", or "Custom".
>>>>>> --> Thanks, we confirmed this.
>>>>>>>> 9) <!--[rfced] Please note that we updated the registration template in Section 6.2 as follows. Please let us know of any objections.
>>>>>>> Original:
>>>>>>  (1) Contact Information:
>>>>>>>       Name: Hyunsik Yang
>>>>>>       Email: [e-mail]
>>>>>>>  (2) Name being registered (as it will appear in SDP): haptics
>>>>>>>  (3) Long-form name in English: haptics
>>>>>>>  (4) Type of name ('media', 'proto', 'fmt', 'bwtype', 'nettype',
>>>>>>           or 'addrtype'): media
>>>>>>>  (5) Purpose of the registered name:
>>>>>>>       The 'haptics' media type for the Session Description Protocol
>>>>>>       is used to describe a media stream whose content can be
>>>>>>       rendered as touch-related sensations.
>>>>>>       The media subtype further describes the specific
>>>>>>       format of the haptics stream.  The 'haptics' media type for
>>>>>>       SDP is used to establish haptics media streams.
>>>>>>>  (6) Specification for the registered name: RFC XXXX
>>>>>>> Current:
>>>>>>   Contact name:  Hyunsik Yang
>>>>>>>   Contact email address:  [e-mail]
>>>>>>>   Name being defined (as it will appear in SDP):  haptics
>>>>>>>   Type of name:  media
>>>>>>>   Description:  The 'haptics' media type for the Session Description
>>>>>>      Protocol is used to describe a media stream whose content can be
>>>>>>      rendered as touch-related sensations.  The media subtype further
>>>>>>      describes the specific format of the haptics stream.  The
>>>>>>      'haptics' media type for SDP is used to establish haptics media
>>>>>>      streams.
>>>>>>>   Reference:  RFC 9993
>>>>>> --> Thanks, we confirmed this.
>>>>>>>> 10) <!--[rfced] The figure in Section 7 is marked as artwork. Please confirm if this is correct or if it should be marked as sourcecode instead.
>>>>>>> If it is marked as sourcecode, please consider whether the "type"
>>>>>> attribute should be set.
>>>>>>> The current list of preferred values for "type" is available at https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type"
>>>>>> attribute not set.
>>>>>>> --> Thanks. We confirmed. Since this is an SDP example, we will mark it as sourcecode with type="sdp".
>>>>>>>> 11) <!--[rfced] May we remove the second sentence below? It appears to be duplicate information from the first sentence.
>>>>>>> Original:
>>>>>>   The parameter 'ver' indicates the version of the haptic standard
>>>>>>   specification. If it is not specified, the The parameter 'ver'
>>>>>>   indicates the version of the haptic standard specification. If it is
>>>>>>   not specified, the value "2025" indicating the MPEG Haptics Coding
>>>>>>   standard ISO/IEC 23090-31:2025 [ISO.IEC.23090-31] SHOULD be inferred,
>>>>>>   although the sender and receiver MAY use a specific value based on an
>>>>>>   out-of-band agreement.
>>>>>>> Perhaps:
>>>>>>   The parameter 'ver' indicates the version of the haptic standard
>>>>>>   specification. If it is not specified, the value "2025" indicating
>>>>>>   the MPEG Haptics Coding standard ISO/IEC 23090-31:2025
>>>>>>   [ISO.IEC.23090-31] SHOULD be inferred, although the sender and
>>>>>>   receiver MAY use a specific value based on an out-of-band
>>>>>>   agreement.
>>>>>> --> Thanks, we confirmed this.
>>>>>>>> 12) <!--[rfced] We note "body-part-mask" as well as "body part mask"
>>>>>> (as defined in [ISO.IEC.23090-31]). Should the hyphenated form be updated as shown below for consistency?
>>>>>>> Original:
>>>>>>   In some other cases, some receivers MAY indicate a preference for a
>>>>>>   set of bitstream properties such as perceptions, min/max frequency,
>>>>>>   or body-part-mask, which contribute ...
>>>>>>> Perhaps:
>>>>>>   In some other cases, some receivers MAY indicate a preference for a
>>>>>>   set of bitstream properties such as perceptions, min/max frequency,
>>>>>>   or body part mask, which contribute ...
>>>>>> -->
>>>>>>>> 13) <!--[rfced] We note only one instance of "HMPG" - is this correct, or should it be lowercase? If it should remain as uppercase, how may we expand it?
>>>>>>> Original:
>>>>>>   The general congestion control considerations for transporting RTP
>>>>>>   data apply to HMPG haptics over RTP as well [RFC3550]
>>>>>> --> "HMPG" is not intended to be an acronym. It refers to the ".hmpg" MPEG-I haptics binary format defined in ISO/IEC 23090-31, so I revised it as follows.
>>>>>>> The general congestion control considerations for transporting RTP data apply to MPEG-I haptic data over RTP as well [RFC3550].
>>>>>>>> 14) <!--[rfced] May we revise this text to be two sentences to improve readability?
>>>>>>> Original:
>>>>>>   In case of congestion, a receiver or intermediate node MAY prioritize
>>>>>>   initialization MIHS units over other units, since initialization MIHS
>>>>>>   units contain metadata used to re-initialize the decoder, and MAY drop
>>>>>>   silent MIHS units before other types of MIHS units, since a receiver
>>>>>>   MAY interpret a missing MIHS unit as a silence.
>>>>>>> Perhaps:
>>>>>>   In case of congestion, a receiver or intermediate node MAY prioritize
>>>>>>   initialization MIHS units over other units, as these contain metadata
>>>>>>   that is used to reinitialize the decoder. Additionally, a receiver or
>>>>>>   intermediate node MAY drop silent units before other types, as a
>>>>>>   receiver MAY interpret a missing unit as silence.
>>>>>>> --> Thanks. We confirmed this.
>>>>>>>> 15) <!--[rfced] BCP 195 contains RFCs 8996 and 9325. Should there be a reference to BCP 195 in this sentence (with a corresponding entry under the Informative References section), or is the reference to [RFC9325] sufficient?
>>>>>>> Current:
>>>>>>   (D)TLS-based protection: For guidance on using TLS 1.3 and DTLS,
>>>>>>   applications should refer to BCP 195, including [RFC9325], which
>>>>>>   provides up-to-date recommendations.
>>>>>>> --> Thanks. We agree with your opinion.
>>>>>>> (D)TLS-based protection: For guidance on using TLS 1.3 and DTLS, applications should refer to [RFC9325], which provides up-to-date recommendations.
>>>>>>>> 16) <!-- [rfced] We had trouble matching up the text in the IANA Considerations with the IANA registrations.  We have attempted to make the text more clear.  This includes adding a section 10.2 to specify the new SDP parameters media registration.
>>>>>>> Please review carefully and let us know if any updates are needed.
>>>>>> --> Thanks. We confirmed this.
>>>>>>>> 17) <!--[rfced] FYI: We have added an expansion for the following abbreviation per Section 3.6 of RFC 7322 ("RFC Style Guide").
>>>>>> Please review this as well as each expansion in the document carefully to ensure correctness.
>>>>>>> Cyclic Redundancy Checks (CRCs)
>>>>>>> --> Thanks. We confirmed this.
>>>>>>>> 18) <!--[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.
>>>>>>> Note that our script did not flag any words in particular, but this should still be reviewed as a best practice.
>>>>>>> --> Thanks. We reviewed documents based on guidelines.
>>>>>>>> Thank you.
>>>>>> Karen Moore and Sandy Ginoza
>>>>>> RFC Production Center
>>>>>>>>> On May 18, 2026, at 1:48 PM, [e-mail] wrote:
>>>>>>> *****IMPORTANT*****
>>>>>>> Updated 2026/05/18
>>>>>>> RFC Author(s):
>>>>>>> Your document has now entered AUTH48.
>>>>>>> The document was edited in kramdown-rfc as part of the RPC pilot test
>>>>>> (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc)
>>>>>>> Please review the procedures for AUTH48 using kramdown-rfc:
>>>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instruction
>>>>>> s_completing_auth48_using_kramdown
>>>>>>> Once your document has completed AUTH48, it will be published as an
>>>>>> RFC.
>>>>>>>> Files
>>>>>> -----
>>>>>>> The files are available here:
>>>>>>  https://www.rfc-editor.org/authors/rfc9993.md
>>>>>>  https://www.rfc-editor.org/authors/rfc9993.html
>>>>>>  https://www.rfc-editor.org/authors/rfc9993.pdf
>>>>>>  https://www.rfc-editor.org/authors/rfc9993.txt
>>>>>>> Diff file of the text:
>>>>>>  https://www.rfc-editor.org/authors/rfc9993-diff.html
>>>>>>  https://www.rfc-editor.org/authors/rfc9993-rfcdiff.html (side by
>>>>>> side)
>>>>>>> Diff of the kramdown:
>>>>>>  https://www.rfc-editor.org/authors/rfc9993-md-diff.html
>>>>>>  https://www.rfc-editor.org/authors/rfc9993-md-rfcdiff.html (side by
>>>>>> side)
>>>>>>>> Tracking progress
>>>>>> -----------------
>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>> https://www.rfc-editor.org/auth48/rfc9993
>>>>>>>> Please let us know if you have any questions.
>>>>>>> Thank you for your cooperation,
>>>>>>> RFC Editor
>>>>>>>> [Banner]
>>>>>>> [Banner]<https://www.interdigital.com/white_papers/the-distributed-net
>>>>>> work-shift-enabling-ai-on-device?utm_source=signature&utm_medium=banne
>>>>>> r&utm_campaign=ai>
>>>>>>> The Distributed Network Shift Enabling AI On > Device<https://www.interdigital.com/white_papers/the-distributed-netwo
>>>>>> rk-shift-enabling-ai-on-device?utm_source=signature&utm_medium=banner&
>>>>>> utm_campaign=ai> This e-mail is intended only for the use of the
>>>>>> individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
>>>>>> --
>>>>>> auth48archive mailing list -- [e-mail] To
>>>>>> unsubscribe send an email to [e-mail]
>>>>>   
> 
>