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
