Subject: [MMUSIC] sdp-new unregistered media types

From: [email-masked]
Date: Thu, 6 May 2004 12:18:27 +0300

Hi Mark, Van, Colin,

Is Magnus's suggestion, to 'depreciate' "data" and "control" from SDP until they are IANA registered, feasible or likely?

(My interest lies in whether or not to consider using "data").

Cheers, Rod.

> -----Original Message-----
> From: ext Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, April 29, 2004 10:33 AM
> To: Walsh Rod (Nokia-NRC/Tampere)
> Cc: [email-masked]
> Subject: Re: [MMUSIC] And one more SDP-quiz question on protocol IDs
<snip>
> 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

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 6 May 2004 10:25:32 +0100

On Thursday 06 May 2004 10:18, [email-masked] wrote:
> Is Magnus's suggestion, to 'depreciate' "data" and "control" from SDP
> until they are IANA registered, feasible or likely?

I submitted -16 yesterday, without making that change. Unless there is 
strong consensus from the group to do so, I wish to avoid changes that are 
not backwards compatible.

Colin

---

From: Mark Handley <[email-masked]>
Date: Thu, 06 May 2004 10:47:12 +0100

>not backwards compatible.

Does anyone use "data" and "control"?  

The IANA considerations (at least in -15) only specify a SHOULD for
these matching the top level MIME types:

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

So the lack of a MIME Content Type for these isn't a problem, but
there should be a way to register media formats under these with IANA
- I believe currently there isn't.

But if there's no interoperability report for "data" and "control",
they should clearly be deprecated before moving to draft standard.

BTW, the first part of section 9 refers to a future registration of
application/sdp, but this is already registered, so if you haven't
already removed in from -16, you probably should do so.

Cheers,
	Mark

---

From: Colin Perkins <[email-masked]>
Date: Thu, 6 May 2004 11:41:08 +0100

On Thursday 06 May 2004 10:47, Mark Handley wrote:
> >strong consensus from the group to do so, I wish to avoid changes that
> > are not backwards compatible.
>

I thought "control" was used, not sure about data - expect for Rod's 
proposal for FLUTE.

> - I believe currently there isn't.

True. The IANA considerations section is something which has received a lot 
of work in -16, but there is more to do. This is one of the things to add.

> they should clearly be deprecated before moving to draft standard.

I expect SDP-new will cycle at proposed, there have been too many changes 
and there's no interop report.

> already removed in from -16, you probably should do so.

The first part of Section 9 in -16 is the MIME registration template for 
application/sdp.

Cheers,
Colin