Hadriel Kaplan wrote: > >> -----Original Message----- From: Dean Willis >> [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2008 >> 11:21 PM >> >> DRAGE, Keith (Keith) wrote: >>> But now you are making the assumption that all info-packages >>> require the call to fail if I do not support the info package. >> No, I'm not. I'm saying that SOME non-standards-track INFO packages >> will need the call to fail if the far end does not support INFO >> packages. If they don't need it to fail, they shouldn't use the >> options tag in a Require directive. > > Again, if a non-standards-track INFO package needs its info package, > they'll do non-standard things to get the behavior they need, by > putting their non-standard package name in Require, and it works. It > is not necessary for us to help them. And again doing a check for > the generic info-package draft support is not sufficient to > accomplish their goal anyway, because as soon as another device > supports the draft but not their specific non-standard one, they're > back to square one. So it's neither necessary nor sufficient. What > is there to debate over? > > >> This is pretty basic stuff, kids. Why are you making it so darned >> hard? > > Because it's easier (and cheaper) to debate this now than to handle > the tech-support calls later.
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. 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. 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? -- 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
