Hi all, I'm just back from a longer break and started to read all ALTO documents with a fresh mind. One of my readings is of course draft-penno-alto-protocol-04.txt.
I have done my first review of the draft with the -03 revision and started reading -04 to see how far the "ALTO protocol" has made it. By the way, I still believe this should correctly read "ALTO protocol proposal", isn't it? ;) First of all, I'm a bit disappointed that the draft name says 'protocol', but there is still no complete protocol defined in that draft, that I could start to implement. The whole syntax is missing, even in the latest revision. This does not make life easier in judging whether the claimed ALTO protocol is progressing in the right direction. Reading the draft and understanding the different building blocks is very, very difficult, if not impossible for implementers not attending the ALTO WG. The draft starts with a lot of marketing talk in the beginning (sections 1 & 2) and afterwards tries to introduce the different elements. I'm stuck after section 4 (which introduces the Network Maps), as I would expect a clean and neat introduction to the Cost Maps. I do like the concept of these two maps, but I'm lost after reading the Section 4 and 5. Section 4 starts well with the Network Maps and I would expect the intro of the Cost maps, but instead the combination path rating and cost maps is introduced in Section 5. Some technical questions: - why do we need ordinal and numerical ranking. A numerical ranking would be just enough and also eliminate one degree of freedom (i.e., making the job of the implementers easier :) - how are ordinal/numerical lists sorted, i.e., is it descending or ascending. This is not defined, only implicit by guessing. - why POST for all operations if data is sent to the server, even though in some occasions (e.g., 7.3.3.1.1), if GET with parameters in URI just works? - why hard coded URI paths? do we need this, i.e., wouldn't it be fine to learn those paths while querying the server capabilities (Section 7.3.1.1) - where is the real protocol spec, i.e., the actual encoding of the entity bodies? That is probably the interesting part with a lot of work ahead. - where is the status code for the ALTO information query? There is only the http status code discussed. This status code does not say anything about the result of the queries, but about the http transport. - section 7.1.1: why does ALTO need to obey TCP transport considerations? Is it not enough to use standard TCP? Does this hint to some required tuning of the TCP transport? ;) - what is the measure of the ALTO server, if it is overloaded? - http caching: what cache directives shall be used for what information? You claim caching to be a strong point for the protocol, there is not much information about what to cache and how (see RFC 2616, Section 13. ...) Thanks, Martin [email protected] NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
