Subject: [MMUSIC] And one more SDP-quiz question on protocol IDs

From: [email-masked]
Date: Wed, 28 Apr 2004 22:58:25 +0300

One of the implications of wanting an SDP description for FLUTE (previous email) is that we will need a protocol ID for the m line. Although this seems trivial to me, I would like to know if anyone has any great objections to "UDP/FLUTE" style? ("RTP/AVT", "udp" and "TCP" are existing examples)

So for example, you'd get an media field looking like this:
   m=data 12345 UDP/FLUTE 0 

(Any reason not to prefer "FLUTE/UDP"?)

Cheers, Rod.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Apr 2004 09:33:15 +0200

Hi Rod,

A few comments,

first it is RTP/AVP or RTP/SAVP, and in the near future also RTP/AVPF 
and RTP/SAVPF. I assume it was only a typo.

Personally I prefer FLUTE/UDP, which seems to be the more clear that the 
main protocol information is FLUTE, which in this case is transported 
over UDP. If anyone has another transport FOO that will work for FLUTE 
then they can specify FLUTE/FOO.

I don't think that using "data" as media type is appropriate at all. 
Although RFC 2327 mentions data I don't think it is appropriate at the 
current state. The media types that really is used to my knowledge is 
the ones using the names registered for MIME. See:
http://www.iana.org/assignments/media-types/index.html

If one looks at draft-ietf-mmusic-sdp-new-15.txt the following paragraph 
is present:

"9.2.1 Media types ("media")

    The set of media types is intended to be small and SHOULD NOT be
    extended except under rare circumstances.  The same rules should
    apply for media names as for top-level MIME content types, and where
    possible the same name should be registered for SDP as for MIME.  For
    media other than existing MIME top-level content types, a
    standards-track RFC MUST be produced for a new top-level content type
    to be registered, and the registration MUST provide good
    justification why no existing media name is appropriate (the
    "Standards Action" policy of RFC 2434 [5]."

In this respect I think that "application" is suitable for FLUTE. Can 
you please further motivate why data would be the right choice?

To avoid further confusion I am of the opinion that draft-ietf-sdp-new 
should be updated to move all unregistered media types into a note like:

Note: RFC 2326 mentions the media types "data" and "control", these are 
unregistered media types and should not be used. If these media types 
are deemed suitable in the future, they should be registered in 
accordance with section 9.2.1.

Cheers

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Stephen Casner <[email-masked]>
Date: Thu, 29 Apr 2004 08:23:13 -0700 (PDT)

On Wed, 28 Apr 2004 [email-masked] wrote:

> One of the implications of wanting an SDP description for FLUTE
> (previous email) is that we will need a protocol ID for the m
> line. Although this seems trivial to me, I would like to know if
> anyone has any great objections to "UDP/FLUTE" style? ("RTP/AVT",
> "udp" and "TCP" are existing examples)
>

The order of RTP/AVP is the order of decreasing significance.  That
is, AVP is a particular specialization (profile) of RTP.  There are
multiple second components that follow the first, but it is unlikely
that the symbol "AVP" will follow anything other than "RTP" and still
have the same meaning.

In the case of UDP and FLUTE, FLUTE is one of several protocols that
can be layered after UDP in the packet.  FLUTE is a specialization of
the use of UDP.  So I prefer UDP/FLUTE.

(I also prefer IP/TCP, because it reflects layering order, but the
common terminology is TCP/IP because TCP is considered layered "over"
IP.  I suppose this is another big-endian / little-endian issue.)

Note that in the case of "RTP/AVP", the use of UDP is implied.  To use
RTP over another lower-layer protocol requires a new term, such as
DCCP/RTP/AVP.

If FLUTE would only be used with UDP in this context, then UDP could
be implicit for FLUTE as well.

                                                        -- Steve