Re: [alto] alto-protocol-11 vs. alto-reqs-14

[Richard Alimi <[e-mail]>]

On Sun, Jul 8, 2012 at 10:34 PM, Ben Niven-Jenkins
<[e-mail]> 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 <[e-mail]> 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
>