Re: multiple bodies in any SIP message

This is just rehashing the discussion from many months ago on this list about doing use-specific content-types which drove us to the package header to begin with.  Please don't make us go there again! (pretty-please!)

What does it matter to you where the package identifier is, in C-T vs. Info-Package?  Most of us feel it's a lot cleaner to keep them separate, and to put the package identifier in a SIP header vs. a MIME one.

-hadriel

> -----Original Message-----
> From: Christer Holmberg [mailto:[email protected]]
> Sent: Saturday, December 06, 2008 4:37 PM
> To: Hadriel Kaplan; Dean Willis
> Cc: SIP List; Paul Kyzivat
> Subject: RE: [Sip] multiple bodies in any SIP message
>
>
> Hi,
>
> >>So, something like "Content-Type: application/info+foo" would solve
> >>this. No need for new headers, no need for CIDs, no need for
> nothing...
> >>That is MY definition of KISS (apart from being one of the coolest
> >>rock band :)
> >
> >For one thing, we don't need to change ANY C-* in the INFO message and
> still get what we want - if that's not "simple" then I don't know what
> is.  :)
> >
> >It is also debatable that having a solution for a specific message type
> and then a different solution for other message types is "simple"; or
> even having a body "type" that is unique for each message
> >type vs. generic to all is "simple".  It may be simpler for the first
> message type you do it to, but then you have to reproduce that code for
> all message types anyway.
>
> If we have a package specific C-T value we probably don't even need the
> Info-Package header. So, absolutely no reason to link a header with a
> body part, because there is no header. Just like SDP.
>
> We use Send-Info to negotiate that we support foo, and then I send you
> foo with C-T: application/info+foo. Very simple.
>
> If people then want to define some generic SIP mechanism for some
> problem I am not sure we all agree what it is, fine. If needed, you can
> then use that solution also for your info package body parts.
>
> >>Because, in most cases today clients are able to find out what is in a
> message body, and what to do with it, based on the Content-Type value.
> >
> >No, that may be what some of them do in code, or what it appears like
> they're doing from a wireshark trace, but what 3261 says is that in fact
> there is a C-D that extends the C-T.  It just happens to be
> >that "session" is the implicit C-D for "application/sdp", and "render"
> is the implicit C-D for everything else.  So as far as we know they're
> actually doing it right.
>
> In my experience, the problem is not "context", because it is know what
> information is sent in what message. In addition, C-T (together with C-D
> if you like) tells you what a body part contains, so you can process and
> parse the message. There is no need to link any CIDs between SIP headers
> and body parts in order to figure out what to do.
>
> So, by using C-T for info packages it will work ecactly the same way for
> INFO. I look at C-T, and I process and parse the info package body part.
> Simple.
>
> >BTW, it's not that I disagree with you that content-types to date have
> been unambiguous in reality.  They have, afaik.  And I think we would be
> well-advised to keep future extensions from re-using
> >already defined C-T's if ambiguity could occur.  For most things we're
> pretty safe.  For example, any future Info package would be safe to
> re-use existing C-T's, because a negotiation mechanism is in
> >place to indicate package support, so you wouldn't get a message with
> the package to begin with if you didn't understand it and support
> disambiguating body parts.
>
> I just think it is very useful and simple to able to look at the C-T
> value in order to figure out what is in the body part...
>
> Regards,
>
> Christer

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip