The critical issue here is the backwards compatibility question. If we accept that SIPS as written in RFC3261 (that is, with the last hop exception) is not and will never be implemented, then I suppose an option-tag is redundant. If not, though, then as a UAC sending a request, I would certainly want a proxy server to fail a SIPS request if it didn't understand that the last hop exception could not be invoked.
As such, in that case I'd see value for the option tag in Proxy-Require. The use of the option-tag in Proxy-Require would of course be at the discretion of the UAC sending a request. But of course, it is always the UAC that is requesting and invoking the protection of SIPS, so that seems like a natural fit. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Cullen Jennings [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 25, 2007 12:59 PM > To: Alan Johnston > Cc: Francois Audet; Peterson, Jon; [email protected]; Dean Willis; Keith > Drage > Subject: Re: [Sip] draft-ietf-sip-sips-03.txt > > > > Agree with Alan .... If this document was extending SIP then I would > understand the need for an option tag but the draft would not > need to > update 3261. > > On Apr 25, 2007, at 7:10 AM, Alan Johnston wrote: > > > I don't think we need an option tag for this - we are not > > fundamentally changing or extending RFC 3261. The intent of 3261 > > was that a sips call have encrypted signaling end-to-end, we are > > just clarifying how this should be done. > > > > Also, since there are no deployments of sips, there is no > backwards > > compatibility issue. > > > > Thanks, > > Alan > > > > > > Francois Audet wrote: > >> (Copying Dean and Jon and Hisham, because they are the > main people > >> who > >> expressed an opinion on this). > >> > >> The issue is how do we handle backward-compatibility, i.e., > >> implementations that > >> have implemented sips according to RFC 3261 but not to this draft. > >> > >> Because of the many issues highlighted in the draft, those > >> implementations are > >> likely to do proprietary "cheats" to handle SIPS, and they are also > >> likely to have things that are not really legal. Presumably, the > >> option-tag would > >> allow UAs and Proxies to know if an implementation is > "clean" or not. > >> You could then > >> provide alternative treatment for the "un-clean" implementation > >> (i.e., > >> don't allow > >> registration, protocol fix-up, manufacturer-specific > stuff, record an > >> aler, etc.). There are certainly other ways of doing this, and > >> this is largely > >> theoretical anyways because it's not like there is a large > numbers of > >> implementations out there. > >> > >> The second issue (perhaps more importantly) is the actual changes > >> that > >> we are making to RFC 3261. Specifically, the various deprecation > >> of last > >> hop ugrades/ > >> downgrades. > >> > >> The option-tag (with Proxy-required) allows for the sender of the > >> request to > >> enforce the deprecation of the last hop exception, i.e., > the session > >> will fail > >> with 420 if a proxy doesn't understand that it is supposed > to support > >> sips > >> properly as per the new draft. > >> I was thinking about the originator of the request as the > entity that > >> would want > >> to enforce no-last-hop-exception, but Cullent points out that > >> maybe it's > >> also > >> something that's up to the owner of the SIPS URI to > decide, in which > >> case the > >> option-tag is not useful (of course if you are that > worried about it, > >> you > >> could do "sips:[EMAIL PROTECTED]:sips". > >> > >> So.... > >> > >> I actually don't really care either way. Really. I'm fine > either way. > >> > >> Maybe we should do a virtual "hum". > >> > >> 1a - For the option-tag (but I could go either way) > >> 1b - For the option-tag (and I really insist on it) > >> 2a - Against the option-tag (but I could go either way) > >> 2b - Against the option-tag (and I really insist on it) > >> 3 - I really don't care > >> > >> > >> > >>> -----Original Message----- > >>> From: Cullen Jennings [mailto:[EMAIL PROTECTED] Sent: Sunday, > >>> April 22, 2007 20:21 > >>> To: Audet, Francois (SC100:3055) > >>> Cc: [email protected] > >>> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt > >>> > >>> > >>> On Apr 16, 2007, at 3:26 PM, Francois Audet wrote: > >>> > >>> > >>>> 2. Do we need the sips option tag? The current document > >>>> assumes that > >>>> we do use the option tag, and that is the preference of > >>>> the author. > >>>> (There is at least one dissenting voice on that one: > >>>> Hisham). > >>>> > >>> I'm confused on why we would need it and would want to > understand > >>> why it is needed before commenting on this. I don't buy the > >>> needing it to enforce deprecate of last hop rule - I see problem > >>> in that it leads to two bits that mean the same thing and > we have > >>> to deal with all the corner cases of when they conflict. It also > >>> makes me wonder if there are problems when a URI is copied from > >>> one situation to another and the REquires: sips header is not. > >>> > >>> Cullen <with my individual hat on> > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.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://www1.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://www1.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
