480 means that the user identified by the Request-URI is recognized, but there is currently no valid forwarding location for that user. In this case, no SIPS contacts.
What many people are missing in the 480 vs. 418 argument is the following: - Existing implementations will treat new 4XX error codes as 400, which basically means "the protocol message is broken". - Existing implements will treat 480 with new Warning just like 480 witn no warning, i.e., as "Temporarily unavailable". There is a huge difference between the 2. 400 will lead you to believe that there is something wrong with the equipment (i.e., you may file a complaint with the manufacturer). Very bad. 480 just means the other end is not available at that address. Good. Everybody is happy. > -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 31, 2007 14:25 > To: 'Rohan Mahy'; 'Michael Thomas' > Cc: 'IETF SIP List'; Audet, Francois (SC100:3055); > [EMAIL PROTECTED]; 'Paul Kyzivat' > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > 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
