Dean wrote (in response to Hadriel): > > 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. >
It's difficult to tell whether RFC 3427 updates RFC 3261 in this respect. It certainly does not change the IANA requirements, but it is unclear whether it is restating the existing requirements, or just mentioning them in an aside for completeness. Either way, it is currently required to be standards track RFC, but you can change it with another standards track RFC if you so wish to start the process for one. Keith > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2008 8:23 PM > To: Hadriel Kaplan > Cc: DRAGE, Keith (Keith); SIP List > Subject: Re: [Sip] INFO Framework: Tags > > > 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
