Re: multiple bodies in any SIP message

Fine, let's keep them separate. 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email protected]] 
Sent: Sunday, December 07, 2008 5:59 AM
To: Christer Holmberg; Dean Willis
Cc: SIP List; Paul Kyzivat
Subject: RE: [Sip] 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