Oh, please with the rethoric. Again, the idea is that a sip address is different than a sips address.
If you use a sip address when a sips is expected, then you'd get the behavior you'd get for when there is no binging assigned. It's as simple as that. > -----Original Message----- > From: Michael Thomas [mailto:[EMAIL PROTECTED] > Sent: Friday, July 27, 2007 07:58 > To: Audet, Francois (SC100:3055) > Cc: Paul Kyzivat; [EMAIL PROTECTED]; Rohan Mahy; Eric > Rescorla; IETF SIP List > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > You mean, security through obscurity? I guess it's about par > for SIPS course. > > Mike > > Francois Audet wrote: > > The intent is to be UNDISTINGUISHABLE. > > > > We do NOT want the equipment to automatically downgrade. We > want the > > user to make the decision in a concious way. > > > > Furthermore, we want to emphasise that the SIP and SIPS are > different > > addresses and are not interchangeable. > > > > Rohan Mahy, Jon Peterson, Eric Rescorla, > > > > Since you were the main people advocating this change, can you make > > clear on the list what the rationale is. > > > > Thanks. > > > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, July 26, 2007 16:17 > >> To: Robert Sparks > >> Cc: Audet, Francois (SC100:3055); IETF SIP List > >> Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > >> > >> Is the 480 intended to be *indistinguishable* from a 480 > returned as > >> a result of no registrations at all? Or is it intended to be > >> distinguishable but more obscure than an explicit error response? > >> > >> I think it needs to be distinguishable, one way or another. > >> > >> The reason is that there are UIs where it makes sense to > downgrade. > >> For > >> instance: > >> > >> The input to the UI of the UA is just a dial string, not a > URI. It is > >> up to the UA to decide what scheme to apply. It can do > this based on > >> policy, or perhaps based on a "secure" > >> button on the phone. Typically the user won't know whether a > >> particular number should be sip or sips. > >> (Or even what that means.) The phone may decide to try > sips first and > >> downgrade to sip if the sips doesn't work. If sips works > then it can > >> display some sort of indication that the call is more > secure than if > >> sip is used. > >> > >> If the UA can't tell why the sips request failed then it > will have to > >> retry the call in all cases. > >> > >> The bottom line is that whether to downgrade is a valid > policy issue, > >> and we shouldn't arbitrarily block it from working. > >> > >> Paul > >> > >> Robert Sparks wrote: > >> > >>> I think the 480 approach described below is the right thing to do. > >>> > >>> RjS > >>> > >>> On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: > >>> > >>> > >>>> In the meeting, the issue of the error code to be used > >>>> > >> when the wrong > >> > >>>> URI is used in a request-URI (i.e., sip instead of sips, or > >>>> vice-versa) came up. > >>>> > >>>> The status quo is 2 new error codes (418 and 419). Another > >>>> > >> proposal > >> > >>>> was to use only one (i.e., 418 with 2 new headers). > >>>> > >>>> That proposal did not seem to get much traction. And > >>>> > >> people were not > >> > >>>> very with the status quo either. > >>>> > >>>> Another proposal was to use 480 (Temporarily Unavailable) > >>>> > >> and NOT to > >> > >>>> use an explicit indication of the required/supported URIs > >>>> > >> (SIP, SIPS, > >> > >>>> etc.). Of course, one can always put text in the reason > phrase to > >>>> describe the error for displaying to the end-use. > >>>> > >>>> After talking to all the individual who seemed to have strong > >>>> opinions on this topic, it appears that the 480 approach is the > >>>> preferred approach. > >>>> > >>>> Please let the list know if you are strongly opposed to > >>>> > >> this outcome, > >> > >>>> along with the reasons behind your opposition. > >>>> > >>>> This is the last remaining issue to be closed in the draft, as a > >>>> result of WGLC. > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >>> > > > > > > _______________________________________________ > > 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
