On 9/20/07 10:58 PM, Brian Stucker wrote:
You've made some assertions in your arguments that I believe need some substantiation. You've said that the content-type is not enough to figure out what is going on at all. I disagee. I think a content type that says "I'm sending you DTMF digits in a particular format" is every bit as robust as the content-type that conveys MWI for instance, and a heck of a lot more specific than SDP is.
The problem isn't _in_ that direction. The problem is: how do I say "I am capable of receiving DTMF digits in an INFO message"?
The "Accept" header-field lets you say you understand the syntax, but doesn't convey what contexts it makes sense in.
The "Allow" header-field lets you say you can process INFO for some mime-types, but doesn't let you say which ones.
There is no current mechanism that lets you tie the semantics together, the way that event packages do. I've shown, in previous messages, how this can lead to ambiguity and consequent interoperability failure.
To be clear: I don't really care much whether we come up with INFO packages or whether we formally deprecate INFO, but the current situation is untenable.
I'm looking for consistent arguments that can be applied to problems outside of INFO so when the next bad idea (tm) comes along we can clearly point to this document and say "you're trying to do X which we can clearly show is bad and does not align to the things we think are good." I haven't read such an argument yet.
The argument you're looking for is part of Jonathan's service identification draft -- INFO, as currently defined, is a "Do What I Mean" method. For proper behavior, it requires either a closed-garden approach or implementations that can perform mind reading.
INFO with packages is a "Do What I Say" method. The arguments against it are weaker, but mostly resolve to this: Why would you send INFO, a message with no inherent semantics, with a package header that gives the intended meaning? The method itself is ostensibly what gives the message its intended meaning. These cases all cry out for a new method, and the IANA charges the same amount to register a new SIP method as they would to register a new INFO package. ;)
/a _______________________________________________ Sip mailing list https://www1.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
