> On 05 Nov 2015, at 20:51, Travis Burtrum <tra...@burtrum.org> wrote: > > Hello Peter, > > On 11/05/2015 01:27 PM, Peter Saint-Andre wrote: >> I haven't yet had time to look at your proposal in detail. However, >> there is no _tls Protocol name in RFC 2782 or RFC 6335. It seems strange >> for us to be the only ones using that non-standard value. > > At least Microsoft Lync and *I think* SIP (though I can't find a > reference right now) use 'tls' for the Protocol value as well. Also RFC > 2782 does not define values for it, leaving it to be any 'defined name’. SIP uses _sips._tcp for SIP over TLS.
> > This was discussed on the github pull request, and Dave Cridland wrote, > in part: >> I wasn't sure, either, about the use of _tls; so I asked Arnt >> Gulbrandsen (author of RFC 2782) - his opinion was that using _tls, >> and intermixing the _tcp proto records, was perfectly acceptable. His >> concerns were actually that he felt that ALPN should be made mandatory. I think the DNS directorate in the IETF should be consulted here. SIP has had a lot of discussions of using “TLS” as the name of a transport. The URI parameter “;transport=tls” was deprecated (but is still used as it’s the only option). The SIPS: URI scheme is more or less deemed useless and we recommend it not to be used. The Via: headers use TLS as a transport name though, so it’s confusing and not clear whether “tls” used as a transport is ok or not. With DTLS it becomes more confusing. Just to be a bit more confusing, the use of “_sips” in SRV has no connection to the “SIPS:” uri which is quite often an assumption of developers. SIP doesn’t have STARTTLS support. We do use DNS NAPTR for service discovery, so a service can request or recommend use of TLS by adding SRV names to the NAPTR records. I’ve been trying to stir up some interest for clearing up this mess in the SIPCORE IETF wg, but has had no luck so far. /O
