(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
