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
