Subject: [Simple] Message Sessions: m= line format

From: Adam Roach <[email-masked]>
Date: Mon, 7 Apr 2003 18:47:40 -0500

The current draft currently outlines that the m= line
contains a literal, exhaustive list of all supported
media types. Because of the nature of IM, this is likely
to be rather large.

  m=message 49232 msrp/tcp message/cpim text/plain text/html
  text/rtf text/richtext image/gif image/jpeg image/png image/tiff
  image/vnd.ms.ink multipart/signed multipart/encrypted multipart/mixed 
  application/sip-iscomposing+xml

This raises two issues. The first is whether to allow
wildcarding, like HTTP does.

  m=message 49232 msrp/tcp message/cpim text/plain text/html
  text/rtf text/richtext image/* multipart/signed multipart/encrypted
  multipart/mixed application/sip-iscomposing+xml

Another thing to add might be the ability to group according to main
type. I don't have a good syntax to offer offhand. Perhaps something like:

  m=message 49232 msrp/tcp cpim
  m=text 49232 msrp/tcp plain html rtf richtext
  m=image 49232 msrp/tcp *
  m=multipart 49232 signed encrypted mixed
  m=application 49232 sip-iscomposing+xml

Or, alternately:

  m=message 49232 msrp/tcp message text image multipart application
  a=sub:message cpim
  a=sub:text plain html rtf richtext
  a=sub:image *
  a=sub:multipart signed encrypted mixed
  a=sub:application sip-iscomposing+xml

The second issue is it might make sense to express a preference for
certain types over others. For example, I might have a low-end
device that can convert HTML into plain-text for display, but doesn't
do a very good job of it. It would be nice to be able to express that;
something like:

  a=sub:text plain;q=1.0 html;q=0.5

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Apr 2003 17:02:50 -0400

> media types. Because of the nature of IM, this is likely
...
> wildcarding, like HTTP does.
...
> type. I don't have a good syntax to offer offhand. Perhaps something like:
...

Ben Campbell wrote:
 > I prefer doing the negotiation in SDP. This seems quite analogous to
 > codec selection for RTP.

I agree with Ben that this looks and smells a lot like codec 
negotiation, so I would prefer to do it the same way unless we find some 
insurmoutable problem.

If we view it the same way, then wildcarding is problematic. If one side 
says image/*, is the other side permitted to reduce that to some 
specific types of image? Also, will it ever be meaningful to use a 
wildcard? (Can anything properly claim to support *all* subtypes of a 
given type?)

I'm not too wild about the grouping schemes either. The first one 
results in multiple m= lines which raises all sorts of issues. The 
second moves the subtypes to a lines, which seems to make it more 
difficult to negotiate down. But maybe that one can be made to work 
reasonably.

If the list of names gets too long, using numbers and a= lines to define 
them seems plausible to me because it is analogous to codecs again. But 
it doesn't save any characters in the SDP, so might as well let the m= 
line be long.

I think there is a question of where you draw the line regarding 
formats. If some top level formats can contain other mime types, do all 
the contained types have to be mentioned? I guess the precedent with 
multipart is that you must.

Regarding reference, codecs are supposed to be listed in preference 
order. Do we need more?

	Paul

	Paul