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

From: Adam Roach <[email-masked]>
Date: Mon, 14 Apr 2003 16:48:41 -0500

Paul Kyzivat writes:

> 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?)

That's an interesting philosophical question. The answer that has
been given for HTTP is "yes". HTTP user agents generally send headers
like "Accept: text/html, text/plain, image/*, */*". When they get
back content that they cannot handle (presumably a relic of the
wildcarding), they ask the user what to do. And, in fact, SIP
inherits this behavior from HTTP; the "Accept" header can contain
"image/*".

But, in fact, IM is more like e-mail than HTTP. The approach that
e-mail has taken is, "send whatever content-type you want, the
recipient is responsible for figuring out how to render it."

With IM exchanges, this is even less problematic than with HTTP or
e-mail, since you (generally) have users on both ends of a real-time
connection. Upon receiving a message that your UA cannot decode,
you can just send text back saying, "Hey, I can't see/hear/etc
that. Can you try sending it some other way?"

The fundamental problem that I was attempting to point out in my
original message is that IM, like HTTP (and decidedly
unlike realtime media codecs), will generally end up with a *lot*
of different media types that are acceptable.

I thought my original message drove this point home sufficiently;
however, I'll attempt to elaborate. If I were to write an IM client
using the current message-sessions mechanism, and it were to query
the operating system about what types it thinks it would be able to
properly render, running it on the computer that I'm currently
sitting at would result in an m= line that looks like this:

m=message 49232 application/cdf application/fractals
application/futuresplash application/hta application/mac-binhex40
application/msaccess application/msword application/pdf
application/pics-rules application/pkcs10 application/pkcs7-mime
application/pkcs7-signature application/pkix-cert application/pkix-crl
application/postscript application/rat-file application/sdp
application/set-payment-initiation application/set-registration-initiation
application/smil application/streamingmedia application/vnd.adobe.xfdf
application/vnd.fdf application/vnd.framemaker application/vnd.mif
application/vnd.ms-excel application/vnd.ms-pki.certstore
application/vnd.ms-pki.pko application/vnd.ms-pki.seccat
application/vnd.ms-pki.stl application/vnd.ms-powerpoint application/vnd.rmf
application/vnd.rn-realaudio-secure application/vnd.rn-realmedia
application/vnd.rn-realmedia-secure application/vnd.rn-realmedia-vbr
application/vnd.rn-realplayer application/vnd.rn-realsystem-r1m
application/vnd.rn-realsystem-rjs application/vnd.rn-realsystem-rjt
application/vnd.rn-realsystem-rmj application/vnd.rn-realsystem-rmx
application/vnd.rn-realsystem-rom application/vnd.rn-rn_music_package
application/vnd.rn-rsml application/vnd.visio application/x-cdf
application/x-compress application/x-compressed application/x-director
application/x-gzip application/x-internet-signup application/x-iphone
application/x-java-jnlp-file application/x-laplayer-reg application/x-latex
application/x-mix-transfer application/x-mplayer2 application/x-ms-wmd
application/x-ms-wms application/x-ms-wmz application/x-msdownload
application/x-msexcel application/x-mspowerpoint application/x-pkcs12
application/x-pkcs7-certificates application/x-pkcs7-certreqresp
application/x-qem application/x-qet application/x-qex application/x-qexqif
application/x-quicktimeplayer application/x-rtsp application/x-sdp
application/x-shockwave-flash application/x-stuffit application/x-tar
application/x-troff-man application/x-vpeg005 application/x-wmplayer
application/x-x509-ca-cert application/x-zip-compressed application/xml
application/ymsgr audio/aiff audio/basic audio/blue-matter-offer
audio/blue-matter-song audio/mid audio/midi audio/mp3 audio/mpeg
audio/mpegurl audio/mpg audio/scpls audio/vnd.qcelp audio/vnd.rn-realaudio
audio/wav audio/x-aiff audio/x-background audio/x-gsm audio/x-la-lms
audio/x-la-lqt audio/x-liquid-file audio/x-liquid-secure audio/x-mei-aac
audio/x-mid audio/x-midi audio/x-mp3 audio/x-mpeg audio/x-mpegurl
audio/x-mpg audio/x-ms-wax audio/x-ms-wma audio/x-musicnet-download
audio/x-musicnet-stream audio/x-pn-realaudio audio/x-pn-realaudio-plugin
audio/x-realaudio audio/x-realaudio-secure audio/x-sd2 audio/x-wav image/bmp
image/gif image/jpeg image/pict image/pjpeg image/png image/svg
image/svg+xml image/svg-xml image/tiff image/tiff2 image/vnd.rn-realflash
image/vnd.rn-realpix image/x-icon image/x-jg image/x-macpaint image/x-pict
image/x-png image/x-quicktime image/x-sgi image/x-targa image/x-tiff
image/x-wmf image/x-xbitmap image/xbm image/xiff image/xiff2
interface/x-winamp-skin interface/x-winamp3-skin message/rfc822 midi/mid
text/blue-matter-content-ref text/css text/dlm text/h323 text/html text/iuls
text/plain text/scriptlet text/sgml text/vnd.rn-realtext
text/vnd.rn-realtext3d text/webviewhtml text/x-component text/x-scriptlet
text/x-vcard text/xml video/avi video/flc video/mpeg video/mpg video/msvideo
video/quicktime video/vnd.rn-realvideo video/vnd.rn-realvideo-secure
video/x-ivf video/x-mpeg video/x-mpeg2a video/x-ms-asf video/x-ms-asf-plugin
video/x-ms-wm video/x-ms-wmp video/x-ms-wmv video/x-ms-wmx video/x-ms-wvx
video/x-msvideo

Even *ignoring* the fact that we've exceeded normal MTUs at
least twice over, I don't think that's reasonable. I suspect
that some kind of wildcarding scheme is probably appropriate.

The more I chew on this, the more I think that SDP might be the
wrong place to do this, simply because the offer/answer model
doesn't seem to lend itself well to such large data sets. We might
give a bit more consideration to Aki's suggestion that we push
this type of negotiation (well, really, announcement) down to
the MSRP level.

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

They are listed in preference order only in the offer,
not in the answer.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Apr 2003 19:16:09 -0400

> of different media types that are acceptable.

Yes, I understand. I thought I mentioned it, but maybe the issue here is 
whether we should be negotiating all the nested content types or only 
the type of the envelope. If we expect the endpoints to just deal with 
whatever they get, then it makes sense to only negotiate the envelope 
type, which might just be cpim. Other types are then intended just for 
extension to other kinds of envelopes.

If you negotiate both envelope and content types there is an ambiguity 
about which types are acceptable for the envelope. Maybe I only support 
CPIM envelopes and text content in the envelope. But you might decide to 
send me text without an envelope. I don't see a good way to resolve that 
without SDP changes.

A problem with just negotiating the envelope is the cell phone guys will 
probably have trouble with it.

> m=message 49232 application/cdf application/fractals
...

> least twice over, I don't think that's reasonable.

 > I suspect

If there is any point in transmitting these at all then I agree.

I am still concerned with an offer containing image/* and an answerer 
who only wants to support one (or worse, two) kinds of images. The codec 
matching rules won't support that.

> this type of negotiation (well, really, announcement) down to

If it is intended to affect whether the call gets completed then I don't 
see how it can be in the media. Otherwise it might be sufficient to 
extend the response codes to indicate that some received media format 
wasn't handled because it isn't supported.

> They are listed in preference order only in the offer,

If the offer is in preference order, and the answer can omit things from 
the offer then you have to a certain extent taken both sides preferences 
into account.

What do you want - to form some sort of weighted preference order that 
takes into account the preferences of both sides? Sounds like overkill 
to me.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 19 Apr 2003 00:47:36 -0400

inline.

> inherits this behavior from HTTP; the "Accept" header can contain

Lets be careful here. The definition of Accept: image/* in HTTP is that 
it can truly accept ANY encoding for image. Thus, the fact that it can 
get back an encoding it doesn't actually understand just means that it 
really couldn't understand any encoding of image. I always thought that 
wildcarding in Accept is completely bogus, since really, it can never 
support ANY encoding.

> that. Can you try sending it some other way?"

You don't want to the user to have to type that. You really want an 
automated way to say - "this type was not understood". MSRP right now 
has no way to do that. We would need to add some kind of error response 
akin to 488.

> of different media types that are acceptable.

If we have a way of automatically indicating that a type was not 
understood (which I think is a good idea), then I think that it is OK to 
not list all supported formats. As you say, that list can be long. But, 
you do want to give some hint about the more common ones that you 
support up front, to avoid needless trial and error.

So, I would propose that the SDP operation works as defined today. 
However, we allow one of the m-line values to be a token that means "try 
it, and I'll let you know if not". So, an offer could look like this:

m=message 39482 text/plain text/html image/jpg try-it

I don't like using */*, since as I point out above, the semantic is NOT 
the same. Its not saying it supports any type, its saying that you 
should try the type, and you will get an error if its not supported.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com