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: [email protected] <[email protected]> Sent: Monday, May 18, 2026 4:57 PM To: Hyunsik Yang <[email protected]>; Xavier De Foy <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] 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 on https://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: [email protected] (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: [email protected] 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, [email protected] 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_instructions_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-network-shift-enabling-ai-on-device?utm_source=signature&utm_medium=banner&utm_campaign=ai> The Distributed Network Shift Enabling AI On Device<https://www.interdigital.com/white_papers/the-distributed-network-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 -- [email protected] To unsubscribe send an email to [email protected]
