Diego, all, I won't give further pushback, even if I don't agree to quite a number of your statements. Just one further example to explain why SWD won't solve all problems: Even if we replace U-NAPTR by HTTP(S), according to RFC 5986, the ALTO client still needs access to DHCP options, which is yet another non-HTTP(S) interface to care about.
For what it is worth, I am convinced both a DNS-based and a HTTP(S) solution can be engineered, each with pros and cons. Yet, the former variant is much better understood in the IETF, and I fail to see a fundamental benefit of SWD that would compensate this. In order to move forward, if this helps to sort this issue, I think that we could add a non-normative section to the current draft (or, better, an appendix) that discusses an alternative HTTP-based discovery, in case that such a solution gets widely used in future. It could for instance summarize pros and cons according to this e-mail thread, and leave it up to a future document to standardize this variant (possible, after the mechanism is better worked out in the IETF). It is pretty clear anyway that the current ALTO discovery specification does not address all possible use cases of ALTO (cf. third party discovery). Any thoughts on that proposal? Michael _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
