Diego, > As I understand it, the proposal does not intend to keep a > registry of the URIs used for discovery (it is a parameter > for a query using HTTP GET) and, therefore, ALTO could > mandate its own URI, in the same way the U-NAPTR lookup > defines the string to be queried. > > The requirements on external registrations are essentially > the same in both cases (none, I think).
U-NAPTR application service tags are registered with IANA, and that is what the current ALTO discovery draft does. I wonder how and where ALTO would register its URI if it were using draft-jones-simple-web-discovery for discovery. Probably in new IANA registry? Such questions would probably have to be sorted out elsewhere in the IETF before ALTO discovery could rely on draft-jones-simple-web-discovery. > My point is that an > ALTO client would have to rely only in queries aligned with > the rest of the transport protocol, i.e. > plain HTTP(S), and not be required to include support for > specific DNS queries. I don't really understand your argument regarding the client. The ALTO client has to perform DNS queries anyway, i. e., DNS is not a new protocol on the client side. However, my impression is that draft-jones-simple-web-discovery could result in quite some complexity on the server side. My understanding of the proposal is that, if applied to ALTO, an access network provider would have to run a Web server for each access network domain names announced in the DHCP option according to RFC 5986. I could imagine that this results in quite some operational issues for an ISP: - Today, an operator might not run Web servers for domain names such as "dsl.westcoast.myisp.net", i. e., this might require a new server infrastructure. Compared to that, the DNS infrastructure already exists and just has to be extended by entries. - There may be synchronization issues, e. g. in case of domain mame renumbering, because different databases have to be kept in sync. Right now, for ALTO discovery to work well, an ISP may have to keep DHCP and DNS in sync, which are both well-established network services. With draft-jones-simple-web-discovery, a third Web infrastructure has to be taken into account. - I could imagine that load balancing mechanisms and strategies for DNS could be quite different from Web load balancing, also taking into account HTTP proxies etc. ALTO discovery requires that a topologically close server is discovered. The DNS infrastructure is a network service and thus somehow linked to topology, unlike a Web platform. Right now, all the points are speculation. It might be doable to engineer an ALTO discovery solution based on draft-jones-simple-web-discovery, if it becomes an IETF standard. But, as of now, I don't really understand what the benefit would be for ALTO. Michael _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
