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

I agree. Lack there of, only means the IETF does not want an
interoperable solution

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Hadriel Kaplan
Sent: Saturday, March 28, 2009 1:19 AM
To: Adam Roach
Cc: SIP
Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt


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