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

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 9 May 2011 09:04:00 +0200

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
+34-91-339-3608
Ericsson Spain

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 9 May 2011 17:50:58 +0200

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: [email-masked] [mailto:[email-masked]] 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
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 10 May 2011 07:50:42 +0200

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

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Yasubumi CHIMURA" <[email-masked]>
Date: Wed, 18 May 2011 20:54:02 +0900

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.

Best Regards,

Yasu Chimura
-----Original Message-----
From: Miguel A. Garcia [mailto:[email-masked]] 
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,

/Miguel

On 09/05/2011 17:50, DRAGE, Keith (Keith) wrote:
> 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.

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 19 May 2011 09:30:21 +0200

Hi Yasu,

My opinions, as an individual, below.

On 18/05/2011 13:54, Yasubumi CHIMURA wrote:
> 	For media using other transport protocols, the<fmt>  field is
> 	protocol specific.  Rules for interpretation of the<fmt>  sub-

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

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Yasubumi CHIMURA" <[email-masked]>
Date: Fri, 20 May 2011 13:51:00 +0900

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:[email-masked]] 
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,

BR,

    Miguel
>> If you are going to WGLC this document, surely you might as well make
this
> a working group draft.

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 20 May 2011 04:56:14 -0400

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.

Regards,

Gonzalo

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 23 May 2011 14:50:58 -0500

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 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.

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 :-)

>>>>> From: [email-masked] <mailto:[email-masked]>
>>>>> [mailto:[email-masked]] On Behalf
>>>>> Of Miguel A. Garcia
>>>>> Sent: 09 May 2011 08:04
>>>>> To: mmusic
>>>>> [email-masked] <mailto:[email-masked]>

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Mon, 23 May 2011 18:50:31 -0400

Kevin - 

Thanks for reviewing. See Inline...

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

> 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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 24 May 2011 10:58:27 -0500

On 05/23/2011 05:50 PM, Gonzalo Salgueiro wrote:
>> 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 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.

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.

> 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 one comment about
>>>>> draft-salgueiro-mmusic-image-iana-registration.
>>>>>
>>>>>>> <mailto:[email-masked]>
>>>>>>> AD-sponsored draft. So, the chairs would like the working group
>>>>>>> to take
>>>> a
>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>> Jabber: [email-masked] <mailto:[email-masked]> | SIP:
>> [email-masked] <mailto:[email-masked]> | Skype: kpfleming
>> Check us out at www.digium.com <http://www.digium.com> &
>> www.asterisk.org <http://www.asterisk.org>

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 24 May 2011 14:29:25 -0400

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

> 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.
> 
>> 
>>> 
> 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