Subject: [MMUSIC] IANA registration of the "image" media type in SDP

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 31 Mar 2011 11:05:15 +0200

As a chair

It has been made aware to the chairs that SDP has not registered an 
'image' media type, meaning that we should not be able to use 
"m=image..." in SDP.

RFC 4566 intends to create an IANA registry of media types (See Section
8.2.1 in RFC 4566), but while it registers "audio", "video", and others,
it does not register "image". This "image" mime type is widely used, for
example, for signaling T38 fax, or in the examples in comedia (RFC 4145).

To add a bit more complication, this registry has never been created,
even when RFC 4566 creates the registry. See 
http://www.iana.org/assignments/sdp-parameters

Both things (lack of registration of "image" media type and lack of the
registry itself) seem to be an oversight, and should be fixed.

In order to solve these issues, the chairs propose the following two actions:

- First, let's contact IANA and to find out if they can create the
registry that RFC 4566 mandates. Note that, as per RFC 4566 this would
not register the "image" media type, but all the others indicated in RFC 
4566.

- Second, we can open a bug and roll down this registration in a 4566bis
draft, that we should be working on to fix other found bugs.

There is an alternative to this second aspect: write a one-page 
Internet-Draft that registers the "image" media type. We think this might 
be an overkill, considering that we have a bug-fixing revision of 4566 in 
the pipeline, which could be done as fast as this alternative. And, we 
have still include the "image" media type in 4566bis.

Your comments are highly appreciated.

           Miguel and Flemming

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 31 Mar 2011 11:14:52 +0200

I remain to be convinced that there is enough new material on the table to spin a new version of 4566. I am also unaware of anything major in interoperability terms that needs to be fixed. In any case, generation of that version would take well over 12 months, and the IANA registration does not occur until IESG approval.

So I would suggest creating a new i-d that defines and registers the m=image. This is no different to what has occurred with many attribute values.

You can either use this new draft to also create the IANA table, or follow your proposed path of talking to IANA directly - both should be possible.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Miguel A. Garcia
> Sent: 31 March 2011 10:05
> To: mmusic
> Subject: [MMUSIC] IANA registration of the "image" media type in SDP
> 
> As a chair
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Thu, 31 Mar 2011 09:52:01 -0400

Almost a year ago Kevin Fleming and I had this discussion. We ran into this issue in the course of working with the ITU-T on a SIP Forum FoIP TG initiated contribution to T.38. When updating references from RFC 2327  to RFC 4566, we came across the fact that in RFC 2327 the possible values for the 'media' type are documented as sharing the name space with the top-level media content types in the MIME (RFC 2048) registry, whereas in RFC 4566 this statement does not appear. RFC 4566 does contain language that would appear to include such top-level media content types as valid 'media' types in SDP, but also establishes a new SDP-specific 'media' type registry. The MIME top-level media content registry *does* have a registration for 'image'. As you correctly note, IANA does not appear to have
actually created an SDP media type registry (and populated it with the values from RFC 4566). As a result of this we intended to write the I-D for consideration by MMUSIC to register the 'image' media type for SDP. We'll happily submit this if the group agrees.

Regards,

Gonzalo