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
