Re: INFO Framework: Tags
Dean Willis <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
On Nov 24, 2008, at 9:34 AM, Hadriel Kaplan wrote: > > >> Hence, people have done the simple >> things and just implemented non-standard solutions without the safety >> mechanisms of standard solutions. Personally, I'd like to see options >> tags available for informational documents, experimental documents, >> thrid-party specifications, and even first-come, first-served >> vendor-tree extensions. But that is NOT the process we have. > > Why is that, BTW? What was the rationale for changing option-tag > use between 2543 and 3261? > There was some well-founded concern that other SIP-using SDOs would use flexible extensibility specification to essentially rewrite SIP into a more-tentacled leviathan than it currently is, and that making extensions STD-RFC-required would force them back to the IETF for sanity review. There is widespread opinion that the specification divergence was reduced by this. Of course, there is also widespread opinion that we should surrender SIP to the telephone world, wash our hands, and go back to solving Internet problems, so you have to pick your opinions carefully. >> In you own words in other messages on this thread you explain how the >> vendors will happily do non-standard stuff if they need to get get >> things done, like invent their own option tag for an unregistered >> info >> package. Why should we force them to do that? > > That is a different question than "should we have an info-package > draft option tag". I'm fine with providing a way for non-standard > uses of Foo to identify their non-standard Foo in Supported. But I > guess that requires an update to 3261? Update to RFC 3427, actually, since that updates the specification strengths of 3261. -- 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