Rohan Mahy wrote:
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.
The proposal out which had the two different warning codes alleviates
my concern which is that the implementor who doesn't much care about
IETF nanny proclamations has incentive to pay attention to them so that
it doesn't make _useless_ re-requests for SIP:.
Question: as currently defined can these two new warnings be reused by
any future method that is hopefully more secure than SIPS so that we don't
have to rehash this argument again?
Mike
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 representthe *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". Ifthey didn't read the draft, they'd fail the request since they got anunknown 4xx response. (compare that to a 3xx, which is known/usable withoutreading 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 ThomasCc: 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
