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 tried to make this argument earlier (I think one should have separate registrations for sip and sips) but wasn't successful. Perhaps you've just made it more convincingly. > 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? If they haven't read the draft, failing the request is the Right Thing to Do. What we are apparently attempting to do is make it where an unread implementer is likely to Do the Wrong Thing, namely downgrade to sip: and try again. -- Dean _______________________________________________ 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
