The thing that makes me most uncomfortable with an option tag for info-packages is that it is expanding the scope of an option tag from a single well-defined extension/feature to a whole class of features that are not necessarily related. I see it as being analogous to defining an option tag for event-packages that could be used to fail calls because the UAS does not support SUBSCRIBE/NOTIFY. The other thing that is bothersome is that one day, the calls are failing for your mystery application, the next day they succeed because the UAS was upgraded to support SOME info-package, but not your mystery feature and you will have to terminate successful calls because of it.
I think we should change the section about OPTIONS to require the UAS to include its supported info-packages in the response if the request had a Recv-Info header. That way you could probe the far end if you really require your info-package to be there. cheers, (-:bob -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Willis Sent: Monday, November 24, 2008 8:42 AM To: Hadriel Kaplan Cc: SIP List; DRAGE, Keith (Keith) Subject: Re: [Sip] INFO Framework: Tags 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 _______________________________________________ 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
