Re: [AVTCORE] draft-hsyang-avtcore-rtp-haptics-02: Needs to register "haptics" as an SDP <media>

[Jonathan Lennox <[e-mail]>]

Yes, that looks correct!

You have one minor typo: it’s “Session Description Protocol”, singular, no “s” at the end.

Also, you don’t have to provide a telephone number if you don’t want to — the registration only requires an e-mail address.

Other than that, it’s exactly what I had in mind.  Thank you!

> On Mar 13, 2024, at 3:56 PM, Hyunsik Yang <[e-mail]> wrote:
> 
> Thanks for clarifying this issue, we could add the following text as a new subsection in section 6, to register the SDP parameter (this text is based on RFC6433 section 3).
>  
> Does it make sense?
>  
> Thanks.
> Best regards,
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>  
> ## “haptics” Session Description Protocols (SDP) Parameter Registration
>  
>    This memo registers an 'haptics' token in the media sub-registry of the
>    Session Description Protocols (SDP) Parameters registry.  This
>    registration contains the required information elements outlined in
>    the SDP registration procedure defined in Section 8.2.8 of RFC 4566 <https://www.rfc-editor.org/rfc/rfc4566#section-8.2.8>
>    [RFC4566 <https://www.rfc-editor.org/rfc/rfc4566>].
>  
>    (1)  Contact Information:
>  
>            Name: Hyunsik Yang
>            Email: [e-mail] <mailto:[e-mail]>
>            Telephone Number: (xxx) xxx-xxxx
>  
>    (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 <https://www.rfc-editor.org/rfc/rfc6466>
>  
>  
> From: Jonathan Lennox <[e-mail] <mailto:[e-mail]>> 
> Sent: Wednesday, March 13, 2024 12:00 PM
> To: Hyunsik Yang <[e-mail] <mailto:[e-mail]>>
> Cc: IETF AVTCore WG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; Xavier De Foy <[e-mail] <mailto:[e-mail]>>
> Subject: Re: draft-hsyang-avtcore-rtp-haptics-02: Needs to register "haptics" as an SDP <media>
>  
> That should be fine, but the specific issue I’m raising is a different one — the SDP media parameters registry at https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-1 is separate IANA registry from the top-level media types registry.  The values registered as SDP media parameters are a subset of the top-level media types, but not all top-level media types are defined for SDP.
>  
> Thus, you'll register “haptics” in this SDP registry as well.  I don’t think this should be controversial in any way, since all the hard work has already been done defining “haptics” as the top-level media type.
> 
> 
> On Mar 13, 2024, at 11:16 AM, Hyunsik Yang <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hello Jonathan!
> 
> First of all, Thanks for reviewing our draft and sharing feedback.
> 
> After our presentation during the IETF 118 meeting, we realized that the 'haptics' Top-level Media Type (https://datatracker.ietf.org/doc/draft-ietf-mediaman-haptics/) was actually registering the haptic top-level type and multiple haptic subtypes (including HMPG) with IANA. That is why we modified the draft to update the HMPG subtype registration with IANA (in section 6) and refer to the mediaman draft.
> 
> Please let us know if there are any issues with this approach. It's based on our best guess, but we may miss something.
> Thanks
> Best regards
> 
> -----Original Message-----
> From: Jonathan Lennox <[e-mail] <mailto:[e-mail]>>
> Sent: Tuesday, March 12, 2024 5:25 PM
> To: IETF AVTCore WG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: draft-hsyang-avtcore-rtp-haptics-02: Needs to register "haptics" as an SDP <media>
> 
> Hi - I’ve read over the rtp-haptics draft, and wanted to send in e-mail one comment I’ve made verbally in meetings (but probably not too coherently):
> 
> This draft also needs to register the SDP <media> value “haptics”, so “m=haptics” can be sent in SDP.
> 
> See RFC 8866 section 8.2 (specifically 8.2.2) for the details on how this is done; see also RFC 6466 which registered “image” as an SDP <media> (though that was done under the previous version of the process from RFC 4566, which was slightly different).
> 
> I don’t see any reason this registration can’t be done as part of the current draft, but I’ve cc’d mmusic to keep that group aware that this is happening.
> 
> --
> Jonathan Lennox (as an individual)
> 
> [Banner]
> 
> [Banner]<http://www.interdigital.com/white_papers/defining-the-xr-experience-enabling-the-immersivity-ecosystem-?utm_source=signature&utm_medium=Email&utm_term=xr&utm_content=banner&utm_campaign=defining_the_xr_experience>
> 
> Defining the XR Experience: Enabling the Immersivity Ecosystem<http://www.interdigital.com/white_papers/defining-the-xr-experience-enabling-the-immersivity-ecosystem-?utm_source=signature&utm_medium=Email&utm_term=xr&utm_content=banner&utm_campaign=defining_the_xr_experience>
> 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.