Ahh - no what I missed was that you were giving a specific warning code for the 480 such that a machine can automatically warn the user and retry, disambiguating it from a generic 480. That's cool for me. I thought the options were either an ambiguous 480 or explicit 418, but it's now an explicit 480. Sounds good.
-hadriel > -----Original Message----- > From: Francois Audet [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 31, 2007 5:51 PM > To: Hadriel Kaplan > Cc: IETF SIP List > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > 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
