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

From: Adam Roach <[email-masked]>
Date: Mon, 14 Apr 2003 18:34:42 -0500

Paul Kyzivat writes:

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

Aha! I didn't get this from your previous message. Thanks for
clearing it up.

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

The issue is that most SIMPLE clients you see don't actually
use CPIM (or any other) envelopes; they just send content.
Without an envelope, you're back to the 3.5 kilobyte "m="
lines.

>  > I suspect
> > that some kind of wildcarding scheme is probably appropriate.
> 
> If there is any point in transmitting these at all then I agree.

So, if I have a client that isn't using CPIM or any other
enveloping scheme, what's my alternative?

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

Which is exactly the motivation behind my saying:

> > 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.
> 
> If it is intended to affect whether the call gets completed 
> then I don't 
> see how it can be in the media. 

The reason you have this relic in normal SDP is that we didn't
settle on a lowest common denominator. Because we need to be
able to handle, say, video-only or low-bitrate-only or low-
computational-complexity-only, there isn't a single codec that
was reasonable to call out as mandatory to implement.

Because of its relative simplicity compared to, say, voice and
video encoding, IM suffers no such shortcoming. At this point
in the game, we can mandate that *all* implementations of message
sessions MUST support text/plain. Doing so means that you never
have a null-set for common encodings.

> > They are listed in preference order only in the offer,
> > not in the answer.
> 
> 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.

No; you have taken the inviter's *preferences* into account,
and the invitee's *capabilities* into account. That's not
the same thing.

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

It sounds like yet another shortcoming of offer/answer for handling
IM to me.

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 14 Apr 2003 17:21:42 -0700

On Monday, April 14, 2003, at 04:34 PM, Adam Roach wrote:
>  IM suffers no such shortcoming. At this point

Note that text/plain has an optional charset=
parameter.  To achieve interoperability using the
least common denominator method, you will need to define
a mandatory-to-implement charset for text/plain
for all implementations.  This may be trivial in this
environment, but it is a common gotcha.

> and the invitee's *capabilities* into account. That's not

Note that the CONNEG work and the multipart/alternative
views of this are slightly different.   As a gross generalization,
multipart/alternative uses preference order (use the
first which matches), where the CONNEG strategy was
to take a modified set intersection method--gather all the
sets that match, then check the q-values on either
the group of sets the other side sent you or on your own
group of sets.  The big gotcha here is that people want
to do arithmetic on q-values, but they are ordinal, not cardinal,
and no amount of hoop jumping will turn them into
something else.