Re: I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt
Paul Kyzivat <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
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