> -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2008 8:42 AM > > I see things differently -- the reason we have trouble with our specs is > we've required everything useful to go through standardization with a > very high level of review required.
There are all sorts of reasons we have trouble with our specs, but one of them is not the amount of review required, but that we add in "features" or corner-cases into mechanisms that make them more complicated than the problem actually being addressed needs it to be. Because that makes the spec more complicated, the review takes longer and thus it takes a lot longer to stop changing and reach RFC status; and the spec being more complicated and taking longer means vendors just do their own thing or don't implement them as expected. Info-packages is a classic example of this. We have little hope of vendors implementing it if it ends up being complicated, because there is already an INFO mechanism today that works for their needs. > 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? > 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? -hadriel _______________________________________________ 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
