Hi Jason, Thank you very much for taking a look. Please see below:
On Thursday 11 March 2010 3:38:53 pm Jason Livingood wrote: > You may want to make some of these tracker notes more verbose. At this point, since this is a first stab at fully specifying protocol details, my personal feeling is that we are still wide-open for discussion on the whole document. However, there on a few points that I think are particular important for this go-around: - IPv4/IPv6 needs much more thought before integrating it into the document. In particular, what are the right semantics for handling IPv4 and IPv6 with respect to indicating provider preferences? (Some initial questions are noted on Issue #9 for this)? - With regard to messaging (including usage of HTTP URIs and the actual body encodings), can people think of issues that might cause problems for deployment in an operational network (e.g., load-balancing configuration)? Difficult or non-intuitive implementation (both server-side and client-side)? Are there any ambiguities you can see? I thinking through the current protocol details we have tried to address these, but input from others would be extremely helpful. - For Redistribution, this is a capability that seemed to get favorable feedback at IETF76. The current implementation uses HTTP headers/trailers to send the signatures, and a certificate is encoded in the Server Capability response. The idea is that an ALTO Client can locally cache the certificate and only contact the ALTO Server very infrequently even if it is gathering ALTO information (i.e., ALTOResponse structs) from other ALTO Clients instead of the ALTO Server itself. For this part, what do people think about how such redistribution information is encoded in the protocol? Is there a clean way to do this without requiring custom HTTP headers/trailers? Does the spec sufficiently convey when redistribution should or should not be used? > In any case, was your objective to make the request and response simpler or > what's in body of the <ALTOResponse> itself? The changes from -02 -> -03 were to bring the encoding specification more in sync with other IETF specs and specify the structure of messages more formally (with adjustments made since we are actually specifying encoding within JSON). They were not intended to make the request/response simpler -- only to make the specification more precise. In the document, ALTOResponse is a JSON Object with certain required fields, which are specified in 7.2.3.3 (and the subsections thereof). This was the intent, anyways. Should this be made more clear? > > And depending upon the case, which section of > http://tools.ietf.org/html/draft-ietf-alto-protocol-03 would you like > targeted comments on? (7.5?) For protocol messaging, 7.5 is currently the guts of how ALTO Information is encoded. However, the current usage of HTTP (e.g., URI's, status codes, etc) in earlier subsections of Section 7 would be good to get feedback. As mentioned above, I would think that comments about the entire document are very useful, but the major changes in these couple of revisions have been to sections 6, 7, and 11 (so feel free to focus there). -- Richard Alimi Department of Computer Science Yale University _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
