Patrik, > On Aug 9, 2016, at 12:06 PM, Patrik Fältström <p...@frobbit.se> wrote: > > On 4 Aug 2016, at 18:55, Dave Crocker wrote: > >>>> For URI records RFC 7553 says they're either named the same as SRV >>>> records, or they use enumservice names from the Enumservice >>> >>> Declaring a namespace as the union of two, independently-maintained >>> registries is a very efficient way to encourage -- actually in >>> theoretical terms, it guarantees -- collisions. >>> >> >> I see this as a fundamental problem with the URI spec, for the reason cited. >> I also think the current spec should be careful not to promote that problem. >> >> Suggestions? > > Add text that say that to resolve conflicts (what prefixes to use for URI or > SRV for "the web"?), it is encouraged to write explicit documents that say > what is to be used. > > I just submitted draft-faltstrom-httpbis-dns-00.txt is an example of what I > am thinking of, for URI and "the web", which explicitly say what to enter > into the registry that is defined by this document. My envision is to add > more text on the recommended way to use DNS in the case of "the web". > > TL;DR: draft-faltstrom-httpbis-dns-00.txt recommends _web._http for "the > web". Regardless of the registration of both ENUM services HTTP and HTTPS, > regardless of the various "names" used for port number 80 (etc) and > regardless of whether TCP or UDP (and other things being part of the HTTP > evolution...). > > It is "just" used for rewrite of the URI before the HTTP protocol takes over.
I read draft-faltstrom-httpbis-dns-01 and have some comments and questions. There's text in Section 5.4 of RFC7553 that indicates the precedence of URI over SRV for HTTP and I suggest similar text somewhere in the draft to make it clear that SRV is not involved and URI is an alternative to the (hypothetical) use of SRV for HTTP. I found the text hard to parse because "URI" is overloaded in the context of the draft. It can refer to (at least) the URI causing the processing, the URI RRset looked up as a result of processing, and the URI in the RDATA of a URI RR. In particular, I think the URI causing the processing and the URI in the RDATA should be referenced explicitly with different names: how about "input URI" and "target URI", respectively? The specific names don't matter as long as they're clearly defined. I think the specific algorithm should be made a bit clearer, in particular noting that multiple iterations could be required and being more explicit about the termination condition. An example would help a lot. Speaking of examples, is this how it works? - User types "example.com" - "http://example.com"; is the "input URI" - Look up _web._http.example.com/URI, result is URI RR with RDATA "http://www.example.com"; - "http://www.example.com"; is the "target URI", but becomes the new input URI in the next iteration. - Look up _web._http.www.example.com/URI, result is URI RR with RDATA "http://example.cloud-o-matic.com"; - "http://example.cloud-o-matic.com"; is the target URI, but becomes the new input URI in the next iteration. - Look up _web._http.example.cloud-o-matic.com/URI, result is NXDOMAIN - Look up example.cloud-o-matic.com/A and example.cloud-o-matic.com/AAAA, result is A and AAAA RRs - Connect via HTTP to IPv4/IPv6 per local preference, Happy Eyeballs, etc. A final question: where do you intend discussion of this draft to happen? Here in dnsop? Matt _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
