You are right in what you say Dean, but one thing I gotta comment on is that I really doubt that people will be giving out business cards with 2 sip addresses, one with sip: scheme and the other with sips: scheme.
I vision it as one sip address, scheme is not mentioned at all in the business card. The UI of the phone allows the user to select "secure call" or a check box. So the scenarios are: - I register with sips only. You call me without selecting "secure call". Your call would fail - I register with sips only. You call me and select "secure call". Your call would succeed - I register with sip only. You call me without selecting "secure call". Your call would succeed - I register with sip only. You call me and select "secure call". Your call would fail - I register both schemes, all calls succeed Also, you wrote:
Personally, I liked per-scheme registration. The WG didn't.
I thought that was what the group agreed. Or? Ekr suggested a MUST NOT and no one objected. Hisham On 13/04/07, Dean Willis <[EMAIL PROTECTED]> wrote:
Hisham Khartabil wrote: > This is somehow tied with Jonathan's thread related to retargetting > and downgrading from sips to sip (or upgrading). If we agree to > disallow both, then we are also disallowing what is being discussed in > this thread. > Not really. Upgrading and Downgrading, in the context of Johnathan's argument, occur when a proxy which was presented a URI of one scheme changes it to the other scheme. What the current text describes is that registration of a SIPS contact implicitly registers the equivalent SIP contact. This doesn't mean that any proxy can translate SIPS to SIP or SIP to SIPS. Instead, it means that a user who has registered just SIPS can receive both sorts of requests. If the request originates with SIP it will be delivered, just as it would if it originated SIPS. So you could put both SIP and SIPS on your business card, and a caller could just pick one. What I was worried about is what happens when a user who is given only a SIPS URI translates it to SIP and uses that to make a request. It may well be that the user was given only a SIPS URI because the called party really wants their incoming traffic secured. There's no way to COMPLETELY fix this, although it can be fixed from the serving proxy to UAS by either 1) use of outbound over TLS, or 2) going to a per-scheme registration as you propose. So what I asked for is just additional guidance to the user to reinforce the idea that they should not make this mistake. Not that users are really governed by RFCs, but some of them will make fewer mistakes if this sort of guidance is given. > If a UAS wants to be contactable with over UDP or TCP/TLS, then it can > register with 2 contact headers. Personally, I liked per-scheme registration. The WG didn't. The reason I like it is that it removes the incentive to assume that a URI of a different scheme than the one you were given to use is likely to work. This makes mistakes less likely to happen. -- 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
