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

[Gonzalo Salgueiro <[e-mail]>]

On May 24, 2011, at 11:58 AM, Kevin P. Fleming wrote:

> On 05/23/2011 05:50 PM, Gonzalo Salgueiro wrote:
>> 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.
> 
> I suggest removing it. Section 5.14 of RFC4566 only mandates that packet formats be documented for 'media types' (really 'media formats'), not top-level media content types, and only for media formats that operate over raw UDP.
> 
OK. I can certainly live with removing it since we are in violent agreement that it is not required to be there based on 5.14.

> The packet format description for 'image' over 'udptl' using the 't38' media format is properly delegated to the document that defines the 'udptl' protocol, which is the T.38 recommendation itself, so it appears that this is all consistent.
> 
>> 
>>> 
>>> 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.
> 
> Thanks.
> 
> I have a number of editorial changes I'd like to propose; would you prefer those be sent in some sort of 'diff' form as an email? If so, it would probably be easiest if you sent me the XML source and I sent you back a diff to that, and then you can decide whether to accept the changes or not.

I have sent along the XML separately to you to do with it as you see fit.

Regards,

Gonzalo
>> 
>> 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]>
>>>>>>>> [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]> <mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>> 
>>>>> 
>>>>> --
>>>>> Miguel A. Garcia
>>>>> [phone]
>>>>> Ericsson Spain
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> 
>>> 
>>> --
>>> Kevin P. Fleming
>>> Digium, Inc. | Director of Software Technologies
>>> Jabber: [e-mail] <mailto:[e-mail]> | SIP:
>>> [e-mail] <mailto:[e-mail]> | Skype: kpfleming
>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>>> Check us out at www.digium.com <http://www.digium.com> &
>>> www.asterisk.org <http://www.asterisk.org>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail] <mailto:[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