> -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > > 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. > 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. 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. -hadriel _______________________________________________ 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
