George, I think you are correct in highlighting the role vs. protocol difference.
Looking at it like that, John's idea makes sense, although probably it should be inverted, so: _client._smtp._tcp.outbound.example.com This way case, it will happily support protocols that are not client/server (for example, one with more roles). It's not clear to me that this is actually cleaner than: _smtp-client._tcp.outbound.example.com Although it somehow feels better because the dots nicely separate the semantics encoded in the name. On the DNS side, I don't think any of the proposed solutions would be better or worse than any other. I don't think any are particularly complicated, or make verification more difficult. But it wouldn't be the first time that people argue for a particular approach to a protocol because it was the first thing they thought of. ;) Cheers, -- Shane At 2016-01-13 16:59:33 +1000 George Michaelson <g...@algebras.org> wrote: > I think the mapping of SMTP (a protocol, an over-the wire framing and > dialogue about exchanging mail) has been crossed (crossing-the-beam > crossed) with a ROLE. a client can be an SMTP speaker, and a > forwarder/delivery agent can be an SMTP speaker. They aren't performing the > sale role. > > So does DANE want to identify the ROLE being performed or the protocol > being used to do it? How would DANE feel if instead of SMTP it said > DECNet-Mail? > > The sub-domain thing, is that a real zone-cut? Are there detectable zone > boundaries? Or is this mapping dot-separated elements but without implying > a zone-cut? > > -G > > On Wed, Jan 13, 2016 at 3:55 PM, John Levine <jo...@taugh.com> wrote: > > > I'm having what seems to me a very peculiar argument over in DANE. > > > > There's a draft called draft-huque-dane-client-cert-02 about > > validating SSL certificates for client hosts. The idea, which seems > > reasonable, is that if an SMTP or other client presents a TLS > > certificate claiming that it's outbound.example.com, the server it's > > talking to can look up a TLSA record to see if the certificate is > > valid, analogously to the way a client looks up the server's TLSA. > > > > What's peculiar is the names. The previous proposal was to look up a > > TLSA at _smtp.outbound.example.com, then somone noted that _smtp is > > for servers, so they want to look up the newly invented name > > _smtp-client.outbound.example.com. If you have a client for some > > other service, you make up a name. (Read the draft if this seems like > > an implausible summary.) > > > > I suggested they could avoid a lot of future name collision pain by > > registering "client" as a pseudo_service name, and then looking up > > _smtp._client._tcp.outbound.example.com. If your client is using > > another service, you use the service's name from the existing registry > > of services instead of _smtp, e.g., _imaps._client.tcp.myhost.example. > > > > The DANE crowd thinks this is a terrible idea, it's too complicated, > > makes the SRV-ID verification harder, name collisions won't happen > > and/or are easily solved. Am I missing something, or are they? > > > > Signed, > > Confused > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
