Hi, Keith,
On 9/12/2011 10:47 AM, Keith Moore wrote:
...
I'm not looking for anything in particular. I just don't see any
justification for insisting that SRV records always be used with RFC
2782 style labels.
I have provided two:
1) that's the current standard (i.e., changing it requires
an update to RFC 2782, which this draft does not request)
Yes, but arguably 2782 is a poor fit for this application, and for many other
applications also.
You're welcome to:
a) submit a proposal to redefine RFC 2782
or, more usefully AFAICT:
b) submit a proposal for a new DNS record type
2) service lookups already depend on the semantic structure of
IANA service names, which is already only [name, transport]
There's nothing about the definition of the SRV RR that inherently constrains
the label that such RRs are associated with.
RFC 2782 specifies the syntax of the label - to the point of stating
which transports are allowed - not the target, though. That's a place
you can play if you want, AFAICT.
Adding further structure to these entities requires both a change to the
standard and a change to the registry.
Well, you can't really change the structure of SRV RRs, as they're
already in use for some things and in widely deployed code. But there's
no reason why an app couldn't specify a new use of SRV RRs with
different labels than specified by 2782.
I don't understand what you just said; I agree with the first part, but
that prevents the second.
As long as there were no
potential for collisions between 2782-style labels and the labels used
by the app, it wouldn't break anything. The fact that there's already a
standard existing for SRV RR labels shouldn't inherently preclude
standardization of a different kind of label associated with SRV.
IMO, you're suggesting a new RR, but seem to want all the benefits of
using SRV with none of the responsibility.
That's not how it works. If you want a new RR, declare it, and deal with
deployment, etc. If you want to use SRV RRs, either use them as
specified or change the spec.
Nor do I immediately see any justification for using
SRV at all if the application also needs to look up TXT records to get
the service's profile.
SRV records specify the structure that yields the port number, target, weight,
etc.
Sure, you could define TXT record fields for anything you wanted -
effectively redefining the DNS inside TXT records. However, you would
also need to define an indicator *required in all TXT records* that
would tell you whether to interpret the contents as A, AAAA, CNAME, SRV,
etc.
Well, that's the problem with TXT records. Or, to look at it
differently, it's a problem with the design of the DNS protocol in that
its way of labeling RR types is too limited.
You're welcome to define a new name service lookup protocol, either
using LDAP or custom too.
I.e., I agree that RR types are limited, but this WG doesn't get to
unilaterally redefine SRV types.
But looking at it still a different way, if you pick labels that are
unique to a particular application, there's no need for a type indicator
to be embedded in the TXT record. (Effectively this is moving the type
to the label.)
If you want to make that argument as a change to RFC 2782, then you need
to propose it in the DNS WG and wait for it to be accepted.
I don't think it will suffice, because for any label structure there
will be a use outside the intended that wants an exception. That's
basically the conversation we're having now. You're just kicking the
ball down the field.
...
Yes, you could just have the TXT record, but you'd then need to
define the SRV info in the TXT record as fields. For at many services,
additional fields beyond the SRV info isn't needed.
In principle, the apps that don't need anything beyond what SRV
provides could still use the SRV RR as it's defined in 2782 (whether or
not the same style of labels are used). It's (partially) the
warts-on-warts approach of TXT + SRV (or NAPTR + SRV, in a different
context), that I'm concerned about. I get the impression that there's a
set of people out there who keep insisting that SRV be used even though
it turns out not to be a good fit for many situations. Like this document.
Fair enough. Then don't use SRVs.
I've become fairly convinced that SRV is at best not widely
applicable, and at worst fairly harmful. One reason it's not widely
applicable is that there are too many cases where the application needs
to know more more than a list of (address,port) pairs to successfully
choose an instance of a service and use it. (Part of this is because SRV
isn't just being used to help an application connect to a protocol
service, but also, to choose an instance of a somewhat more abstract
service which might actually be implemented using multiple protocols
and/or multiple sets of optional features of a protocol).
A discussion about this document is not the place to argue for or
against SRVs, IMO.
This is a separate issue, which would argue (AFAICT) for a new
structured distributed index system.
One reason it's potentially harmful is that the existence of SRV
tempts various parties to think that it's okay to remap ports on the
wire and/or to insist that particular ports be used for particular
services. Another reason is that the use of default ports is subtly
different from one application to another, and trying to define a RR
that treats them all as the same is a Bad Idea. Once upon a time I ran
across an implementation of getaddrinfo() that did SRV lookup by
default, and it broke applications that used it in several ways.
That is not related to this doc either.
The bottom line for this particular draft is:
- SRV is of more limited applicability than originally assumed, therefore
- there's no need to defend the "purity" of SRV as defined by 2782, therefore
- there's no need to insist that all uses of the SRV RR use the labels as
defined in 2782
This document does not update RFC2782. Until this or some other doc
does, then the "purity" (i.e., spec) stands.
If this (or any other doc) tries to update RFC 2872, we will need to
have that discussion as a separate thread.
--
My bigger concern is why you insist on wanting to play in the SRV
sandbox and change the rules, but won't consider defining your own RR,
or even your own service for lookup.
You can't have it both ways - you cannot benefit from the distribution
of stable code based on standards and declare that you aren't required
to follow those standards.
Joe
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf