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
