Re: 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