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
