Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration

[Gonzalo Salgueiro <[e-mail]>]

Kevin - 

Thanks for reviewing. See Inline...

On May 23, 2011, at 3:50 PM, Kevin P. Fleming wrote:

> On 05/20/2011 03:56 AM, Gonzalo Salgueiro wrote:
>> Yasu & Miguel -
>> 
>> I also completely agree with Miguel's assessment that there is no value
>> in describing the packet format that is already well defined in T.38.
>> 
>> I have submitted an -02 version capturing the comments from this
>> discussion.
>> 
>> Please provide any feedback regarding the latest version of this draft.
> 
> I don't think that the comment raised here is exactly accurate.
> 
> The stipulation quoted is from the definition of the '<fmt>' field of the Media Description ('m' line). This is in reference to 'media formats', and only applies when the '<proto>' field is 'udp'. For T.38, the '<proto>' field is 'udptl', not 'udp', so this stipulation does not apply. In addition, even if the field were 'udp', 'image' is a top-level content type, not a value for the '<fmt>' field. An SDP description of a T.38 session would have an '<fmt>' value of 't38', which is defined to be valid by the T.38 recommendation itself.

You're right. In fact, as a result of knowing the T.38 protocol was udptl, I was intentionally broad in my statements relating to not providing packet formats for ANY of the valid T.38 transport protocols. Since we are in agreement that this registration is not a candidate for consideration of packet formats as requested in Section 5.14 of RFC4566, do I completely remove the innocuous item (#7 in Section 3 of draft-salgueiro-mmusic-image-iana-registration-03) stating that packet formats are not provided in this draft because it is instead delegated to T.38? Or is it viewed as useful statement that adds clarity and should remain in the draft?

I personally don't have a preference either way.

> 
> Interestingly, IANA has 'udptl' listed in the SDP parameters registry for 'proto', with the Reference being T.38... but RFC 4566 states that protocol registrations must refer to RFCs that describe the protocol, not documents from other SDOs :-)
> 
Yikes, that isn't good. In this case a pointer to T.38 is the right thing IMO, so I think this is something that can easily be amended in 4566bis. Copying Ali for awareness.

Regards,

Gonzalo

>> 
>> Regards,
>> 
>> Gonzalo
>> 
>> On May 20, 2011, at 12:51 AM, Yasubumi CHIMURA wrote:
>> 
>>> Hi Miguel,
>>> 
>>> Thank you for your support about Draft of "image" for T.38 SDP.
>>> I agree your opinion.
>>> 
>>> Best Regards,
>>> 
>>> Yasu Chimura
>>> -----Original Message-----
>>> From: Miguel A. Garcia [mailto:[e-mail]]
>>> Sent: Thursday, May 19, 2011 4:30 PM
>>> To: Yasubumi CHIMURA
>>> Cc: 'DRAGE, Keith (Keith)'; 'mmusic'; 'Flemming Andreasen'; 'Noriyuki
>>> SATO';
>>> 'OKUMURA Shinji'; Gonzalo Salgueiro
>>> Subject: Re: [MMUSIC] Process for
>>> draft-salgueiro-mmusic-image-iana-registration
>>> 
>>> Hi Yasu,
>>> 
>>> My opinions, as an individual, below.
>>> 
>>> On 18/05/2011 13:54, Yasubumi CHIMURA wrote:
>>>> Hi Miguel,
>>>> 
>>>> I'm Chimura from OKI-J and CIAJ.
>>>> 
>>>> I have one comment about draft-salgueiro-mmusic-image-iana-registration.
>>>> 
>>>> RFC4566 described the procedure following;
>>>> RFC4566 p24
>>>> The media type registration SHOULD define the packet
>>>> format for use with UDP transport.
>>>> ...
>>>> For media using other transport protocols, the<fmt> field is
>>>> protocol specific. Rules for interpretation of the<fmt> sub-
>>>> field MUST be defined when registering new protocols (see Section
>>>> 8.2.2).
>>>> 
>>>> Therefore, if it use without UDP transport in m=image, should be describe
>>>> the packet format.
>>>> 
>>>> And, if it use with UDP transport in m=image, should be describe the
>>>> definition of fmt and the attribution(a=) of SDP.
>>> 
>>> I get the point, I belive. But I doubt we can just define a single packet
>>> format for sending any type of "image" media types. I guess we should say
>>> that T38 is one of the possible packet formats, and the full packet
>>> format description when using UDP transport is described in ITU-T T.38
>>> recommendation. If in the future, there are additional formats of "image"
>>> with UDP, then a different specification should describe the packet
>>> format.
>>> 
>>> Also, notice that T38 allows several transport protocols, including TCP,
>>> UDP, UDPTL, RTP.
>>> 
>>> My suggestion is that the registration of the media type "image"
>>> delegates the packet format description over UDP to the media format
>>> description. Also, the draft should say that, when T38 is the media
>>> format, ITU-T T.38 contains the packet format description.
>>> 
>>> BR,
>>> 
>>> Miguel
>>>> 
>>>> Best Regards,
>>>> 
>>>> Yasu Chimura
>>>> -----Original Message-----
>>>> From: Miguel A. Garcia [mailto:[e-mail]]
>>>> Sent: Tuesday, May 10, 2011 2:51 PM
>>>> To: DRAGE, Keith (Keith)
>>>> Cc: mmusic; Flemming Andreasen; 'Yasubumi CHIMURA'
>>>> Subject: Re: [MMUSIC] Process for
>>>> draft-salgueiro-mmusic-image-iana-registration
>>>> 
>>>> Hi Keith,
>>>> 
>>>> An individual document will not go through an official WGLC, but I guess
>>>> the working group can always get a closer look at it before the author
>>>> submitting it as an individual submission.
>>>> 
>>>> /Miguel
>>>> 
>>>> On 09/05/2011 17:50, DRAGE, Keith (Keith) wrote:
>>>>> If you are going to WGLC this document, surely you might as well make
>>> this
>>>> a working group draft.
>>>>> 
>>>>> If it is AD sponsored, then the first question is sufficient - look
>>>>> at it
>>>> now, and then it goes for a four week IETF last call.
>>>>> 
>>>>> Keith
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] <mailto:[e-mail]>
>>>>>> [mailto:[e-mail]] On Behalf
>>>>>> Of Miguel A. Garcia
>>>>>> Sent: 09 May 2011 08:04
>>>>>> To: mmusic
>>>>>> Cc: Flemming Andreasen; 'Yasubumi CHIMURA'
>>>>>> Subject: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-
>>>>>> registration
>>>>>> 
>>>>>> In relation with the registration of the SDP 'image' media type, we are
>>>>>> going to try to expedite this draft, since it is a very simple missing
>>>>>> registration.
>>>>>> 
>>>>>> The idea is to progress the draft as an individual submission,
>>>>>> AD-sponsored draft. So, the chairs would like the working group to take
>>> a
>>>>>> closer look at it (it is a short one), so that we can go to WGLC in a
>>>>>> short time frame.
>>>>>> 
>>>>>> So please, send comments as soon as possible. Do not wait to the WGLC.
>>>>>> 
>>>>>> BR,
>>>>>> 
>>>>>> Miguel
>>>>>> --
>>>>>> Miguel A. Garcia
>>>>>> [phone]
>>>>>> Ericsson Spain
>>>>>> _______________________________________________
>>>>>> mmusic mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> 
>>> 
>>> --
>>> Miguel A. Garcia
>>> [phone]
>>> Ericsson Spain
>> 
>> 
>> 
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 
> -- 
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> Jabber: [e-mail] | SIP: [e-mail] | Skype: kpfleming
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at www.digium.com & www.asterisk.org
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic