Hadriel wrote: > 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?
Changing RFC 3261 is entirely possible. You write a draft that updates it. But we need to think through why that was made that way in the first place. I think you yourself have admitted that option-tags in Require headers are overused (and abused). Therefore I believe if we relax the IANA registration requirement for registering new ones, we also need to address how we stop people putting them in Require headers when they do not need to. regards Keith > -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2008 3:34 PM > To: Dean Willis > Cc: DRAGE, Keith (Keith); SIP List > Subject: RE: [Sip] INFO Framework: Tags > > > > > -----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? > > > -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
