Re: francois' comments and why RFC4474 not used in the field

Adam,
 
Yes, I think #2 might be the way ahead. We need to ensure that any
changes of behaviour that we require from B2BUAs in intermediate domains
is reasonable, in the sense that intermediate domains are not prevented
from doing things they have reasonable grounds for needing to do, and
that the burden on intermediate domains is not excessive (given that the
intermediate domain is not the main beneficiary from e2e identity). For
example, if we believe there is no fundamental reason for intermediate
domains to modify the call-id value, we might require those that do
modify call-id to change their behaviour. However, requiring
intermediate domains to add a signature may or may not be considered too
demanding.

John


________________________________

	From: [email protected] [mailto:[email protected]] On
Behalf Of Adam Roach
	Sent: 14 April 2009 23:59
	To: Dan Wing
	Cc: 'Cullen Jennings'; 'Jon Peterson'; [email protected]; 'Francois
Audet'; 'DRAGE,Keith (Keith)'; 'Dean Willis'
	Subject: Re: [Sip] francois' comments and why RFC4474 not used
in the field
	
	
	[with my individual contributor hat on]
	
	Dan Wing wrote: 

		On SIP networks today we have intermediaries modifying
SDP in transit.  It's
		happening now, on real networks.  I am really interested
in preserving
		identity over those networks.
		  


	And I have HTTP proxies that I'd love to send RTP through. At
some point, we've got to realize that certain types of old dogs aren't
even remotely suited for particularly demanding new tricks -- at least,
not without software upgrades.
	
	I think it's important to distinguish among three classes of
solutions in this space:
	
	

	1.	Identity that works through existing B2BUAs 
	2.	Identity that might not work through existing B2BUAs,
but that B2BUAs can be modified to work with 
	3.	Identity that precludes the presence of B2BUAs 


	There are clearly approaches that fit into each of these three
categories. There are a number of people (and I count myself among them)
who find the security properties of the proposals that fit into #1 to be
odious. There are also people who clearly find proposals in class #3
unacceptable for their lack of pragmatism.
	
	Now, there are also a number of people who have historically
staked out extremist positions that state that only solutions in
category #1 (or only solutions in category #3) are acceptable, and that
neither of the other two options could possibly be acceptable. I think
we need to ignore people arguing from either of these extreme positions,
because their positions are mutually exclusive, and can never be
rectified with each other.
	
	At the risk of suggesting compromise, I'll point out that there
*is* a way to mutually satisfy those people who reject solutions in
class #1 and those people who reject solutions in class #3. I suspect
that useful progress lies in that direction only.
	
	/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