I don't see the point in parsimony on return codes unless you're trying to
obscure something. And I don't find "We don't want [...]" particularly
compelling as it implies there's a one-size-fits-all on UI design. Were
SIPS an end to end mechanism there _might_ be a case to be made (and
I'd be extremely dubious even then), but it's far more broken than that
so making proscriptions against this or that is rather pointless.
Never try to teach a *pig* to sing; it wastes your time and it *annoys
the pig*. *...* Mark *Twain
Mike
*
Francois Audet wrote:
Oh, please with the rethoric.
Again, the idea is that a sip address is different than a sips address.
If you use a sip address when a sips is expected, then you'd get
the behavior you'd get for when there is no binging assigned.
It's as simple as that.
-----Original Message-----
From: Michael Thomas [mailto:[EMAIL PROTECTED]
Sent: Friday, July 27, 2007 07:58
To: Audet, Francois (SC100:3055)
Cc: Paul Kyzivat; [EMAIL PROTECTED]; Rohan Mahy; Eric
Rescorla; IETF SIP List
Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
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
