Note changed subject...

Sure, I think of course the URI RR is the best thing since sliced bread, but 
same for each one of the proponents of the other RRs.

I think we could look at the various deployment scenarios and demonstrate what 
design features each one of the RRs have. And with such a description, 
including why the life of the web hosting provider and web site owner ends up 
being easier it is possible to have a better discussion with implementors of 
various libraries that do http fetch. Like libcurl.

When comparing the RRs I agree with the features the other records have, but I 
want to because of this mention why URI is defined as it is.

1. NAPTR did not scale as the size of the RRSet ends up being so large. The 
selection of the subset of potential records one want should be in the initial 
query (QNAME, CLASS, TYPE) and not on the client side. Originally URI was 
because of that designed to replace NAPTR for the ENUM service, to make the 
algorithm simpler. But that was not accepted as people already had implemented 
the (nasty) NAPTR algorithm.

2. URI is a RR type that do use a prefix. It is correct one can not have a 
wildcard, but instead must explicitly have records for all hostnames in the URI 
that is served. This is though a conscious choice. See [3].

3. URI is a RR type that do use a prefix and thanks to this one can delegate 
the _tcp.example.com domain name to a separate DNS server and that way delegate 
across administrative boundaries. Like we already today handle quite often 
Active Directory and service discovery based on the AD mechanisms Microsoft 
have deployed. That way the AD server do not have to be the one that faces the 
internet etc. XFR ends up being simpler and what not.

4. URI do have as RDATA a full URI and not only a new hostname, and that way 
can be part of the rewrite that is to happen. One do not have to follow 
whatever well known URI scheme is to be used, but can instead directly refer to 
the new URI.

4.1. http://www.example.se/path&kalle=1

4.2. Look up _http._tcp.www.example.se -> https://example.se/site3/

4.3. Fetch with HOST=www.example.se https://example.se/site3/path&kalle=1

This is why I still push URI because I feel 1, 3 and 4 together outweighs 3.

But as other writes, what we lack is code.

   Patrik

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to