On Sun, Jul 8, 2012 at 10:34 PM, Ben Niven-Jenkins <[email protected]> wrote: > Rich, Colleagues, > > Some comments from me inline... > > On 2 Jul 2012, at 07:38, Richard Alimi wrote: >> On Sun, May 13, 2012 at 11:14 PM, Sebastian Kiesel <[email protected]> >> wrote: >>>> REQ. ARv14-24: An ALTO client protocol SHOULD allow the ALTO server >>>> to add information about appropriate modes of re-use to its ALTO >>>> responses. Re-use may include redistributing an ALTO response to >>>> other parties, as well as using the same ALTO information in a >>>> resource directory to improve the responses to different resource >>>> consumers, within the specified lifetime of the ALTO response. The >>>> ALTO server SHOULD be able to express that >>>> >>>> o no re-use should occur >>>> >>>> o re-use is appropriate for a specific "target audience", i.e., a >>>> set of resource consumers explicitly defined by a list of host >>>> group descriptors. The ALTO server MAY specify a "target >>>> audience" in the ALTO response, which is only a subset of the >>>> known actual "target audience", e.g., if required by operator >>>> policies >>>> >>>> o re-use is appropriate for any resource consumer that would send >>>> (or cause a third party sending on behalf of it) the same ALTO >>>> query (i.e., with the same query parameters, except for the >>>> resource consumer ID, if applicable) to this ALTO server >>>> >>>> o re-use is appropriate for any resource consumer that would send >>>> (or cause a third party sending on behalf of it) the same ALTO >>>> query (i.e., with the same query parameters, except for the >>>> resource consumer ID, if applicable) to any other ALTO server, >>>> which was discovered (using an ALTO discovery mechanism) together >>>> with this ALTO server >>>> >>>> o re-use is appropriate for any resource consumer that would send >>>> (or cause a third party sending on behalf of it) the same ALTO >>>> query (i.e., with the same query parameters, except for the >>>> resource consumer ID, if applicable) to any ALTO server in the >>>> whole network >>> >>> REQ. ARv14-24: Partially compliant: first and last option supported >>> by HTTP mechanisms. Second and third option relied on the now-removed >>> section 8 of draft-ietf-alto-protocol-10 >> >> Yeah - I'm personally okay with this current state, since we >> consciously removed the section on Redistribution and left that for an >> extension. > > It's a while since I looked at ALTO in detail so my memory of various aspects > is a little hazy but I wonder if the HTTP Vary header can help us here?
It may help with parts of it, but note that some of these requirements depend on ALTO-layer information and not HTTP headers. Additionally, the redistribution mechanism was also designed for sending ALTO resources via non-HTTP protocols. > >>>> REQ. ARv14-27: An ALTO client protocol MUST include protocol >>>> versioning support, in order to clearly distinguish between >>>> incompatible versions of the protocol. >>> >>> REQ. ARv14-27: NOT compliant. There is no version field. >>> 7.6. states: "Future extensions or >>> versions of the ALTO Protocol SHOULD be accomplished by extending >>> existing media types or adding new media types, but retaining the >>> same format for the Information Resource Directory." >>> >>> As workaround, one could define new media types such as >>> alto-directory_v2_0+json or >>> alto2-directory+json >> >> Yeah. There was a discussion when going to the REST-ful approach >> about whether we wanted any explicit version numbers or not. The idea >> was that we didn't need an ALTO version number exposed to applications >> if we used media types appropriately. Using media types like you >> suggested is certainly one approach. > > Using media types along with HTTP conneg gives the advantage that the client > can specified a prioritised list of versions (of media-types) that it > supports in its requests and the server can respond appropriately (including > an appropriate error response if it cannot serialise the response in the > requested media-type version(s), e.g. because it needs to use a higher > versioned media-type than the client supports). > > The other advantage is that the protocol machinery to do the negotiation > already exists in HTTP and we do not need to redefine ALTO specific protocol > machinery to perform the same function. > > The downside is we end up minting new media-types for incompatible changes > between ALTO versions, but minting a new media-type is "cheap". > > Ben > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
