At Sun, 08 Apr 2007 15:01:30 -0500, Dean Willis wrote: > Eric Rescorla wrote:
> Section 3.2 Routing says: > > For example, consider the case of a UA that has registered with SIPS > contact header field. If a UAC later addresses a request using a SIP > Request-URI, the proxy will forward the request addressed to a SIP > Request-URI to the endpoint, as illustrated by message F13 in > Section 5.3 and in Section 5.4. The proxy forwards the request to > the UA using a SIP Request-URI and not the SIPS Request-URI used in > registration (and it does this by substituting the sip scheme to the > sips scheme in the registered contact header field binding). If the > proxy did not do this, and instead used a SIPS Request-URI, then the > response (e.g., a 200 to an INVITE) would have to include a SIPS > contact header field. That SIPS contact header field would then > force the other UA to use a SIPS contact header field in any mid- > dialog request, including the ACK (which wouldn't be possible if that > UA did not support SIPS). > > The preceding says that IF a user converts SIPS to SIP, then the proxies > will forward the request. No, it doesn't, since it's quite possible the user was GIVEN a SIP URI. This is further supported in the following: > > Section 4.1.2 page 12 says: > > Because registering with a SIPS contact header field implies a > binding to both a SIPS Contact and a corresponding SIP Contact, a UA > MUST NOT include both the SIPS and the SIP version of the same > contact header field in a REGISTER: it MUST only use the SIPS version > in this case. Similarly, a UA SHOULD NOT register both a SIP contact > header field and a SIPS contact header field in separate > registrations as the SIP contact header field would be superfluous. > Note however that a UA could register first with a SIP contact header > field (meaning it does not support SIPS), and later register with a > SIPS contact header field (meaning it now supports SIPS). > > If a UA wants to ensure that no requests are delivered without using > TLS on that last hop, the UA MUST use [I-D.ietf-sip-outbound]. > > If we are in proxyless scenario, then we aren't using outbound, and the > "last hop" is the UA to UA hop. Since the only way we have in the > current text to assure that TLS is used on this last hop is to use > outbound, and we aren't using outbound, then we have NO WAY to assure > that this hop is done using TLS. And as I've pointed out several times now, the only TECHNICAL way to do so is to tell the peer to use TLS. > Later in 4.1.2 we have: > > Location services > are therefore free to map from SIP to SIPS URIs as appropriate (see > [RFC3261]/26.4.4). When Bob registers, it therefore does not really > matter if he is using a SIP or a SIPS AOR, since they both refer to > the same user. > > All of these, taken together, say to me that it is reasonable for a user > who is handed a business card with only a SIPS URI on it to guess an > equivalent SIP URI and use it, and that the infrastructure will route > this request to the UAS. If that UAS is NOT using "outbound", then the > last hop may well be traversed without TLS. Well, I don't agree with this interpretation, but luckily since we're writing the spec rather than interpretating it, we don't have to engage in a lot of exegesis. I assert that if you're given only SIPS URI you MUST NOT attempt to map it to a SIP URI. Is there anyone who disagrees with this? If not, then why don't you propose some language that you believe would make this clear. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
