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
