The resource that was requested (sips:[EMAIL PROTECTED]) is NOT
available. There may be a related but different resource available,
so it is nice as a courtesy to provide this information, but the
basic semantics should still be a 480.
thanks,
-rohan
On Jul 31, 2007, at 2:25 PM, Hadriel Kaplan wrote:
Yeah but a 480 implies the resource is not available, whereas in
reality the
resource *is* available using a different scheme. I guess one
question is
if the sips scheme literally means the UAS is a different
"resource". If
so, then registering a sips contact only should not implicitly make
the UAS
available for routing plain sip. The draft currently says they
represent
the *same* resource.
I'm not convinced by the downgrade argument. The far-end can just
as easily
send a 3xx redirecting the UAC to the sip contact. Per this new
draft the
proxies must not recurse on that, and the UAC should inform the
user before
doing so. But I think a new 4xx response code would be much more
likely to
make that a reality, as any vendor implementing support for
recursing on a
418 would have read the draft and seen where it says "inform the
user". If
they didn't read the draft, they'd fail the request since they got an
unknown 4xx response. (compare that to a 3xx, which is known/usable
without
reading this draft) Am I missing the gist of the concern?
-hadriel
-----Original Message-----
From: Rohan Mahy [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 31, 2007 12:04 PM
To: Michael Thomas
Cc: Rohan Mahy; IETF SIP List; Francois Audet;
[EMAIL PROTECTED];
Paul Kyzivat
Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
Michael,
The semantics of a request to a sip: resource are different from a
request to a sips: resource. If there are no Contacts registered
against a sips: resource, then the correct thing for the proxy to do
is to send a 480. This is the same thing the proxy would do if there
were no Contacts registered against a sip: resource.
We are not talking about a ciphersuite downgrade here. Providing an
error response code that encourages a client to downgrade is just
plain irresponsible.
thanks,
-rohan
On Jul 27, 2007, at 9:39 AM, Michael Thomas wrote:
Rohan Mahy wrote:
Michael,
At issue here is what the default implementor is likely to do.
With a new 4xx, the misguided but well-meaning implementor is
likely to try to "helpfully" "repair" the error without thinking
about or understanding the security context.
Using a Warning code raises the bar significantly, but still
allows automata to at least log what happened.
As I said, a receiver is completely at liberty to prevent the
downgrade by not
accepting the downgraded request. Problem solved by those who
care. On
the other hand I think it's pretty presumptuous that we "know" in
all cases
whether it's wrong to "repair" the error. Paul brought up several
examples.
Also: if the receiver allows non-SIPS requests why shouldn't you
infer that
they want you to "repair" the request? It sure seems like this is a
misguided
attempt at forcing ineffectual nannyware which is a pointless
enterprise for
IETF protocols.
Mike
_______________________________________________
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
