Henry, Of course, as with any specs we produce, but until the spec is written (not necessarily as an RFC) vendors can't implement it and the market can't therefore decide. All we can do in the IETF is assess whether we think it worthwhile to devote resources to writing an RFC.
John > -----Original Message----- > From: Henry Sinnreich [mailto:[EMAIL PROTECTED] > Sent: 05 December 2008 16:48 > To: Elwell, John; Victor Pascual Ávila > Cc: [email protected]; Cullen Jennings > Subject: Re: [Sip] scope of derive > > John, > > >it is difficult to tell whether a better-than-nothing > approach would be worthwhile. > > Is this not for the market to decide? > (Who are we?) > > Henry > > > > On 12/5/08 8:39 AM, "Elwell, John" <[EMAIL PROTECTED]> wrote: > > Viktor, > > > -----Original Message----- > > From: Victor Pascual Ávila [mailto:[EMAIL PROTECTED] > > Sent: 05 December 2008 13:47 > > To: Elwell, John > > Cc: Jiri Kuthan; [email protected]; Cullen Jennings > > Subject: Re: [Sip] scope of derive > > > > On Fri, Dec 5, 2008 at 12:34 PM, Elwell, John > > <[EMAIL PROTECTED]> wrote: > > > Jiri, > > > > > > It is well-known that I am not comfortable that we have a > > **deployable** > > > solution for preventing From URI spoofing. The reason it is not > > > deployable is because of B2BUAs, and to some extent because of > > > E.164-based URIs and the way they are handled in practice. > > Furthermore > > > there are issues with PSTN interworking, but we can't do > much about > > > that. > > > > > > I have tried to articulate these issues by means of several > > I-Ds over > > > the last year or so, but capturing a "problem statement" > > acceptable to > > > all seems to be an elusive goal. > > > > > > The reason seems to be that if I describe the problem in a > > certain way > > > (e.g., B2BUAs break the RFC 4474 signature), people say > > "but we can get > > > round this by doing A", so the problem statement has to be > > extended to > > > say why A doesn't work, and then people say "but you can > > get round it by > > > doing B", so the problem statement has to be further > > extended to say why > > > B will not work, and so on ad infinitum. > > > > > > So I would welcome any other attempts to write the problem > > statement. > > > > The whole identity problem cannot be solved in one shot. > [JRE] Jiri asked about problem statement, not solution. > > > > IMO the scope of DERIVE is very limited, which I consider > to be a good > > thing if we really want to have a deployable solution. > > > > Starting from the very beginning, I'm wondering if folks agree that: > > - From URI spoofing is a problem > > - Existing mechanisms present some shortcomings (see > > draft-elwell-sip-e2e-identity-important) > > - An "as much end-to-end as possible" solution is desired > > - This solution is desired to be *simple and deployable* > > - In the absence of some sort of authentication mechanism, URI > > verification is "better-than-nothing" > > - A "better-than-nothing" approach to URI verification may > provide the > > desired level of simplicity and deployability. > [JRE] The word "may" is important here. Until we find an > approach that is viable (and I don't think we are quite there > yet with DERIVE), it is difficult to tell whether a > better-than-nothing approach would be worthwhile. > > John > > > > - The used mechanism should work on a per-session basis. > This might be > > done by using any unique session-identifier/token shared between the > > calling and the called parties. > > > > I'd like to hear your opinions on this. > > > > Cheers, > > -- > > Victor Pascual Ávila > > > _______________________________________________ > Sip mailing list https://www.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://www.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
