Re: I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt

Hi,

I think Hadriel's proposal is fine.

Regards,

Christer 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 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:[email protected]]
> >> 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:[email protected]]
> >>>> 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 
> >>> [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
> 
_______________________________________________
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