Thanks Robert. See below. Make sure you reach the end before replying back.
> -----Original Message----- > From: Robert Sparks [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 05, 2007 06:49 > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; SIP IETF > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last > thoughts on transport=tls? > > What about the proxy->proxy (or some stable network server) > hop, where we expect there _isn't_ a transport-destroying > intermediary (hah) and that we expect they _do_ have > certificates? This is the case where I think we have a real > constituency (with real applications) that we're harming. > > Consider the routing decision that P1 needs to make. The > tools we have allow P1 to choose among the protocols it knows > how to use by administrative configuration. They let P2 > express policy about which protocols P1 should use (through > DNS). What they don't do is let P1 choose between protocols > based on a user's (or application's) input. Hi Robert, yes, I think it is a good summary. I'm not sure that we are "harming" anything by not having transport=tls because P1 can use static configuration or DNS to determine the transport to use between P1 and P2. The only thing that not having a transport=tls parameter implies is that P1 (as you put it) will not be able to determine that TLS should be used between P1 and P2 based on User (UAC) input (on that hop only). Transport=tls would allow the user to insist on the transport being tls for the last hop before the target domain (but says nothing about other hops). I'm still not convinced that this particular behavior is required or even desired. Remember that the UAC does have the means to enforce TLS accross ALL the hops using SIPS. Nevertheless, if people want to re-instate transport=tls, we can do it. It would have to include lots of text to explain the limitations, but it can certainly be done. > We've got this concept of a location service that you access > using REGISTER. > The spec talks about running it separately from a proxy - so > consider the case where a proxy either does query REGISTERs > or sends a request to a redirect server to figure out where > it's supposed to go. What it gets back is URIs in Contact > header fields. How can the location service tell the proxy > that's asking for a routing decision that "for this input > URI, goto this output URI and use TLS"? Yes, that is certainly a more concrete use case. Both for the location service you mention, or for redirect servers in general (when used for routing). This may be the main technical reason for re-instating transport=tls. I'd be willing to go along with that. There is also another reason, this time practical, for re-instating transport=tls. It is the fact that most implementations that support TLS today seem to use it. I've attempted to mitigate this problem in the current draft by writing up rules on how to deal with transport=tls in a backward compatible way, but I'm not convinced that it's enough. Perhaps formally recognizing transport=tls, and describing it's limitations (e.g., it doesn't solve NAT/FW, doesn't work with server-provided certs, etc.). Let's wait to see if anybody else chimes in on the idea of re-instating transport=tls. _______________________________________________ Sip mailing list https://www1.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
