On Mon, Nov 19, 2012 at 05:54:21PM +0100, Scharf, Michael (Michael) wrote: > 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?
I propose to add such a discussion to the Deployment Considerations document, if we want to have one at all. The discovery document should contain a technical specification as short and as precise as possible. S. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
