Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-04.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 1 Dec 2011 19:01:46 +0100

Hi Shinji,

my replies (as an individual). I am also copying Ali, since he is editing 
the draft.

On 30/11/2011 10:34, OKUMURA Shinji wrote:
> Hi,
>
> I have some questions concerning draft-ietf-mmusic-rfc4566bis-04.
>
> [Page 25]
>      "If the<proto>  sub-field is "udp" the<fmt>  sub-fields MUST
>      reference a media type describing the format under the "audio",
>      "video", "text", "application", or "message" top-level media
>      types.  The media type registration SHOULD define the packet
>      format for use with UDP transport."
>
> Q1. In this document, there are some "media type",
>      "top-level media content types", "top-level content type"
>      and "top-level media types".
>
>      Which do these mean "MIME media type" or "SDP media type"?
>      Or do the both of two have the same meaning?
>      I think these are ambiguous expressions.

I think in the past the original term was MIME type, but since it was not 
only used for e-mail, that old term has been nowadays being replaced by 
"media types".

A media type is composed of a "top-level media type", such as "audio", or 
"video", and a "subtype", such as "G729" or "iLBC". Sometimes, the 
"top-level media type" is also known as "Content type", or more simply, 
"type".

I agree with you that the draft should be coherent with the terminology. 
I suggest to avoid the word "MIME". And I suggest to pick one term for 
the "top-level media type", I don't have a strong preference for one.

>
> Q2. As for the "audio", "video", "text", "application", or "message"
>      top-level media types, where is the definition of the packet
>      format for use with UDP transport?
>      Why is it necessary for new media types?

I believe "audio" and "video" usually use the RTP/AVP as the transport 
protocol. So, these days we don't send "audio" or "video" directly over 
UDP, something that will imply to define the packet format. Instead, we 
send audio and video over RTP, following the audio video profile defined 
in RFC 3551.

Other media types, such as "message", may use other transport protocols. 
This is the case when MSRP is used as a transport protocol.

This is necessary for any media type, it is not enough to say that you 
are going to send the media over UDP, but you also need to define the 
packet format.

>
> [Page 36]
> 8.2.3.  Media Formats ("fmt")
>      "For the "udp" protocol, new formats SHOULD be registered.  Use of an
>      existing media subtype for the format is encouraged.  If no media
>      subtype exists, it is RECOMMENDED that a suitable one be registered
>      through the IETF process [RFC4288] by production of, or reference to,
>      a standards-track RFC that defines the transport protocol for the
>      format."
>
> Q3. When a new media format(such as t38) is registered,
>      why should we define a new format for "udp" protocol?
>      IMHO all media format don't need the "udp" protocol.

I understand the sentence a bit different. I think the sentence wants to 
say that if you are going to write "udp" in the <proto> field of the "m=" 
line, then you need to register the format, it is hasn't been done it 
yet. So, it does not say that every format should use UDP, but the other 
way round.

BR,

       Miguel

>
> Regards,
> Shinji
>
> [email-masked]
> Mon, 24 Oct 2011 10:57:30 -0700
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Multiparty Multimedia
>> Session Control Working Group of the IETF.
>>
>> 	Title			: SDP: Session Description Protocol
>> 	Author(s)		: Mark Handley
>> 						   Van Jacobson
>> 						   Colin Perkins
>> 						   Ali Begen
>> 	Filename		: draft-ietf-mmusic-rfc4566bis-04.txt
>> 	Pages			: 49
>> 	Date			: 2011-10-24
>>
>> 	This memo defines the Session Description Protocol (SDP).  SDP is
>> 	intended for describing multimedia sessions for the purposes of
>> 	session announcement, session invitation, and other forms of
>> 	multimedia session initiation.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-04.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-04.txt
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

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

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 02 Dec 2011 19:10:08 +0900

Hi Miguel,

thank you so much for your reply.

"Miguel A. Garcia" <[email-masked]>
Thu, 1 Dec 2011 19:01:46 +0100
>the "top-level media type", I don't have a strong preference for one.

I think it may not be necessary to avoid the word "MIME".
IIUC some of "media type" in this draft mean top-level "MIME"
media type that is registered with IANA.

>This is the case when MSRP is used as a transport protocol.

therefore, as for the "audio", "video", "text", "application",
or "message", the packet format for the <proto> sub-field "udp"
is not defined.

As a consequence I think the 1st sentence is needless.

>are going to send the media over UDP, but you also need to define the 

When we register new <fmt> sub-fields for the <proto> sub-field
"udp", it is necessary to define the packet format.
But, when we register only SDP media type without "proto" nor
"fmt", it is meaningless and impossible to define the packet
format for use with <proto> "udp".

As a consequence I think the 2nd sentence is needless.

Basically the packet format depends on both of <proto> and <fmt>.
And there is no reason for giving special treatment only to "udp".

>yet. So, it does not say that every format should use UDP, but the other 

When new <fmt> media format is used over the <fmt> field "udp", 
it is necessary. I see.

Regards,
Shinji