Hi, I think Hadriel's proposal is fine.
Regards, Christer > -----Original Message----- > From: sip-boun...@ietf.org [mailto:sip-boun...@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 30. maaliskuuta 2009 23:48 > To: Hadriel Kaplan > Cc: SIP; Adam Roach > Subject: Re: [Sip] I-D Inaction: > draft-kaplan-sip-secure-call-id-00.txt > > > > Hadriel Kaplan wrote: > > What's non-backward-compatible about it? The text would > say a UAC should generate a call-id without the IP/host > (which is completely in-line with 3261), and that a UAS must > continue to accept a call-id with ip/host. > > OK. I thought you were proposing to go further. > > What you say above here seems fine. (But of course some won't > implement SHOULD either.) > > Thanks, > Paul > > > I'll remove the ABNF change piece since people are worried > that may affect backwards compatibility, due to a future > strict-compliance parser checking for this update's ABNF and > rejecting legacy 3261 ABNF. So this update would only affect > the normative text and not the ABNF. > > > > -hadriel > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzi...@cisco.com] > >> Sent: Monday, March 30, 2009 12:55 PM > >> To: Hadriel Kaplan > >> Cc: Adam Roach; SIP > >> Subject: Re: [Sip] I-D Inaction: > >> draft-kaplan-sip-secure-call-id-00.txt > >> > >> Hadriel, > >> > >> I understand your logic. BUT are we agreed that we should > be making > >> non-backward-compatible normative changes to 3261 (or any > of the key > >> RFCs) for reasons other than correcting out and out errors and > >> ambiguities? Seems like that is the start of SIP/3.0. > >> > >> Paul > >> > >> Hadriel Kaplan wrote: > >>> Yeah I've been thinking about what you said the other day about > >>> this, > >> and I think I understand your point, but I still think > MUST's and an > >> update to 3261 would be good, for the following reasons: > >>> 1) We really should want to change 3261 to say MUST NOT put an ip- > >> address/hostname in the call-id. Really in 20/20 > hindsight I don't > >> think it should have had one to begin with. > >>> 2) It's easier for customers to force vendors to do something if > >>> there's > >> a MUST statement, standards-track RFC, vs. an informational > >> recommendation/should. > >>> 3) Endpoint UAC vendors should do it *before* getting > deployed and > >>> being > >> told by customers to change after-wards. Specifically I'm > thinking > >> about vendors who don't attend IETF and aren't that up-to-speed on > >> all the nuances and such. An update to 3261 with > normative mandatory > >> language is clearer, I think. > >>> -hadriel > >>> > >>> > >>>> -----Original Message----- > >>>> From: Adam Roach [mailto:a...@nostrum.com] > >>>> Sent: Friday, March 27, 2009 4:20 PM > >>>> > >>>> Which is why an informational draft explaining the problem is > >>>> useful, while a normative document... not quite so much. > >>>> > >>>> Tell UACs: "If you include machine names in your > Call-IDs, B2BUAs > >>>> will have reason to change them." There's no MUST or > MUST NOT here, > >>>> just an explanation of rationale. > >>>> > >>>> Tell B2BUAs: "If a Call-ID doesn't contain an @ sign, you'll do > >> everyone > >>>> a favor by not changing them, because it allows proper > correlation > >>>> of related transactions an dialogs." Again, no MUST; no > MUST NOT. > >>>> Just cause and effect. > >>>> > >>>> Then see if people want to play nice. The market will sort out if > >> that's > >>>> valuable or not. > >>>> > >>>> /a > >>> _______________________________________________ > >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use > >>> sip-implement...@cs.columbia.edu for questions on current sip Use > >>> sipp...@ietf.org 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 > sip-implement...@cs.columbia.edu for questions on current sip > Use sipp...@ietf.org 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 sip-implement...@cs.columbia.edu for questions on current sip Use sipp...@ietf.org for new developments on the application of sip
