On Wed, Jan 13, 2016 at 5:24 AM, Tony Finch <d...@dotat.at> wrote:
> John Levine <jo...@taugh.com> wrote:
> >
> > 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.)
>
Yes, folks, please read the draft and also the thread on DANE.
(And Shane - it wasn't the "first thing we though of" - in fact all
alternate
suggestions brought up in the thread had already be considered by the
authors of the draft.)
> This naming scheme is a bad idea because it looks very similar to XMPP SRV
> records but has confusingly different semantics.
>
> _xmpp-client refers to an XMPP server endpoint for use by clients.
> _xmpp-server refers to an XMPP server endpoint for use by other servers.
>
Yeah, this was discussed on DANE already, where I said the following:
Yeah, I'm aware of that. I think the XMPP community made an
unfortunate choice in those names - I might have suggested
"_xmpp-c2s" and "_xmpp-s2s" instead.
There is no established or standardized convention for client service names
in the IANA registry yet. Are we doomed to avoid "-client" just because of
the (unstandardized) precedent set by one application?
_submission refers to SMTP-like server endpoints for use by clients.
> _smtp-client is proposed to refer to SMTP client initiators.
>
> More generally this promises to clutter up the service identifier
> namespace with identifiers for clients, which are not services.
>
Yet the IANA registry seems to have a provision for registering
client service names (i.e. application specific identifiers used by
clients). So, the cluttering is already there. Perhaps there is a need
to create a separate registry.
As for cluttering up the namespace in a DNS zone and causing
collisions (John Levine's contention), I don't buy it. These application
labels
are organized underneath "client-specific" domain names - this does not
meet my definition of cluttering. All labels descending at that point
pertain
to the specific client, and usages for colliding labels are disambiguated
by the resource record type.
I like the idea of taking the server's service labels and prefixing
> them with _client.
>
Actually, that was one my original proposals outlined in -00 of the draft.
It was taken out after deliberations with my co-authors, but I do see a
rationale for it.
Here's the original draft:
https://tools.ietf.org/html/draft-huque-dane-client-cert-00
The current draft is:
https://tools.ietf.org/html/draft-huque-dane-client-cert-02
I am fine with reintroducing the "_client" label (and I believe Viktor is
too)
_if_ there is consensus for it. The service label then can rid itself of the
"-client" suffix, assuming IANA service registry folks do not raise
objections.
I can look into that.
The -00 draft did also contain an alternate suggestion that included
the transport label. I am far less convinced this is needed. Client
identities are not expected to be transport specific for the same
application,
so this introduces an unnecessary complication, and we should I think
be conservative in how much application semantics we encode into
domain names.
--
Shumon Huque
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
