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
