We had a large, long, and lengthy thread of discussion that I will try to summarize.
So far, almost everybody who has voiced an opinions says we need to fix, rather than deprecate, INFO. Opinions on fixing it vary. Most people seem to think we need a registry of INFO usages that will, at the very least, give us a table of the existing usages and the RFCs or other specs that define them. The sticky point of discussion is a negotiation and discovery mechanism. We've had on-list proposals for a strong mechanism based on the mode used in RFC 3265. Some folks think we need to do this, and others thing there's no reason to bother since it is not likely to get implemented because just inventing a non-standard INFO use is easier. Is there a middle ground? What if we were to: 1) Establish an INFO registry and register our existing usages, policy either "first come, first served" or "Specification required". 2) Define an Info-type header field and register (in the regoistry of #1) a value for each known Info usage. Fully-compliant implementations would send an Info-type header field with the appropriate value in every INFO message. 3) Require registration of an Info-type for each future usage into the registry of #1 above. 4) Define an "Info-type not supported" error response message. This handles the use case of a UAS that receives an INFO with an Info-type it does not understand. 5) For Info-types for which discovery is required, use a standards-track RFC to define a SIP extension and option tag, and use the usual OPTIONS/Require negotiation mechanism for discovery. We might consider revising each INFO-using RFC to define an appropriate option tag. This lets people easily register INFO usages and a corresponding Info-type tag. It lets nodes that don't understand an Info-type usage reject the message (at the expense of whacking the dialog, which arguably was already in need of whacking). And it provides a standard (although heavy) mechanism for discovery and negotiation when those are required. I think the above addresses the major concerns, is reasonably implementable, is reasonably operable, and requires the smallest possible effort to document. It's also pretty much backward compatible. -- Dean _______________________________________________ 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
