You mean, security through obscurity? I guess it's about par for
SIPS course.
Mike
Francois Audet wrote:
The intent is to be UNDISTINGUISHABLE.
We do NOT want the equipment to automatically downgrade. We want
the user to make the decision in a concious way.
Furthermore, we want to emphasise that the SIP and SIPS are
different addresses and are not interchangeable.
Rohan Mahy, Jon Peterson, Eric Rescorla,
Since you were the main people advocating this change, can
you make clear on the list what the rationale is.
Thanks.
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 26, 2007 16:17
To: Robert Sparks
Cc: Audet, Francois (SC100:3055); IETF SIP List
Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
Is the 480 intended to be *indistinguishable* from a 480
returned as a result of no registrations at all? Or is it
intended to be distinguishable but more obscure than an
explicit error response?
I think it needs to be distinguishable, one way or another.
The reason is that there are UIs where it makes sense to
downgrade. For
instance:
The input to the UI of the UA is just a dial string, not a
URI. It is up to the UA to decide what scheme to apply. It
can do this based on policy, or perhaps based on a "secure"
button on the phone. Typically the user won't know whether a
particular number should be sip or sips.
(Or even what that means.) The phone may decide to try sips
first and downgrade to sip if the sips doesn't work. If sips
works then it can display some sort of indication that the
call is more secure than if sip is used.
If the UA can't tell why the sips request failed then it will
have to retry the call in all cases.
The bottom line is that whether to downgrade is a valid
policy issue, and we shouldn't arbitrarily block it from working.
Paul
Robert Sparks wrote:
I think the 480 approach described below is the right thing to do.
RjS
On Jul 26, 2007, at 4:03 PM, Francois Audet wrote:
In the meeting, the issue of the error code to be used
when the wrong
URI is used in a request-URI (i.e., sip instead of sips, or
vice-versa) came up.
The status quo is 2 new error codes (418 and 419). Another
proposal
was to use only one (i.e., 418 with 2 new headers).
That proposal did not seem to get much traction. And
people were not
very with the status quo either.
Another proposal was to use 480 (Temporarily Unavailable)
and NOT to
use an explicit indication of the required/supported URIs
(SIP, SIPS,
etc.). Of course, one can always put text in the reason phrase to
describe the error for displaying to the end-use.
After talking to all the individual who seemed to have strong
opinions on this topic, it appears that the 480 approach is the
preferred approach.
Please let the list know if you are strongly opposed to
this outcome,
along with the reasons behind your opposition.
This is the last remaining issue to be closed in the draft, as a
result of WGLC.
_______________________________________________
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
_______________________________________________
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
