Hi, Nico,
On Sep 12, 2011, at 5:56 PM, Nico Williams <nico(_at_)cryptonector(_dot_)com>
wrote:
On Mon, Sep 12, 2011 at 5:30 PM, Joe Touch <touch(_at_)isi(_dot_)edu> wrote:
On 9/12/2011 2:43 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:57 PM, Joe Touch<touch(_at_)isi(_dot_)edu> wrote:
My claim is that:
SRVs represent services as they are currently assigned by IANA
a new RR could be useful for things that aren't sufficiently
expressible in the IANA service/port registry
Existence proofs show that this is not *actually* so.
The existence proof is that many SRV names have defined TXT fields,
including the following:
I meant existence as in "how it's used". I don't see why
Windows/AD/Samba/... can use SRV RRs the smart way while the rest of
us must not. That would be silly. It's not our fault that RFC2782 is
outdated. Nor is it our job to update it.
The Windows examples explain their use as basically a naming convention for
servers, where they
a) add a few prefixes to the FQDN
b) some of which violate DNS specs
c) where the FQDN doesn't match the hostname
i.e., they add foo._bar.nsf.example.net when they intend a FQDN of
nsf.example.net
There are three problems with that - which could interfere with other
interpretations of those SRV records (e.g., tools that might scan those records
to monitor service liveness).
But, let's see if we can change the direction of this thread (we're
going in circles).
Would you oppose an update to RFC2782 to standardize different SRV
RRset _name_ conventions?
I would, as per above. That would be pushing context-dependent syntax into the
SRV record rather than using a separate RR - where that syntax belongs. Note
that SRVs changed DNS RRset name conventions but only for the SRV RR. I.e., the
precedent is that changing the syntax requires a new RR.
If not, are you aware of any others who might?
If you don't object, who should be responsible for making the update,
keeping in mind that these alternative SRV RRset naming conventions
shipped long ago?
There are plenty of cases of protocols and extensions that are deployed that
don't meet spec.
If we should take a cue from deployed code, we should (IMO) follow Apple not
Microsoft in this case.
Joe
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf