>>Basically, a large number of people wanted the error to NOT be explicit, and >>allow "downgrades". I still don't get it. In a similar scenario, if you're using a web browser then the user will know what sites are secure because of the padlock icon. When diverted away from a secure site (automatically) the user can see the padlock disappears. And in some cases, the browser will display a message to tell the user that the connection is no longer secure. I don't see why the equivalent thing can't be done in SIP/SIPS. The security (or lack of) doesn't matter provided the user is informed. It should be up to the user to decide if they want to allow a downgrade, not the protocol specification. I agree that a bad implementor could do the downgrade secretly but, for me, this is no different to a bad web browser which doesn't tell you about the security level - you simply wouldn't choose to use such a browser. I know SIP and HTTP are different but I can't see the difference in this case. Regards, Attila
________________________________ From: Francois Audet [mailto:[EMAIL PROTECTED] Sent: Wed 01/08/2007 22:19 To: Attila Sipos Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Basically, a large number of people wanted the error to NOT be explicit, and allow "downgrades". The use of the Warning is a compromise for them. The idea being that most people will ignore the warning and just fail the call, unless they really know what they are doing. ________________________________ From: Attila Sipos [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 01, 2007 14:05 To: Audet, Francois (SC100:3055); Michael Thomas Cc: IETF SIP List Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 by the way what were the objections? just curious. Regards, Attila ________________________________ From: Francois Audet [mailto:[EMAIL PROTECTED] Sent: Wed 01/08/2007 16:55 To: Michael Thomas Cc: IETF SIP List Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > -----Original Message----- > From: Michael Thomas [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 01, 2007 04:25 > To: Rohan Mahy > Cc: Hadriel Kaplan; 'IETF SIP List'; Audet, Francois > (SC100:3055); [EMAIL PROTECTED]; 'Paul Kyzivat' > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > Question: as currently defined can these two new warnings be > reused by any future method that is hopefully more secure > than SIPS so that we don't have to rehash this argument again? The draft uses the Warn-codes in 480. But it could be used by other response (e.g., 424 for location conveyance, if we decide it makes sense). Or any other response. I'm assuming you mean "other URI schemes" instead of "other methods". I currently have it as follows: 380 SIPS Not Allowed 381 SIPS Required So, obviously, they are tied to SIPS. If we defined another URI scheme (e.g., sipsec or whatever), then it would probably need new Warning Codes. The alternative, which I presented in Chicago, based on Attila's proposal (i.e., defining a new header that specifically list the Allowed or Required URI schemes) was NOT viewed favorably by the group. _______________________________________________ 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
