Paul
Hisham Khartabil wrote:
> 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
>
