(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
