Re: [alto] Info Resource Dirs, OPTIONS, 300 Multiple Choices and all that jazz ....

[Richard Alimi <[e-mail]>]

Hi Martin,

On Thu, Jul 28, 2011 at 8:09 AM, Thomson, Martin
<[e-mail]> wrote:
...
>
> That said...  The way the text is structured implies something more complicated than it needs to be.  That is, it implies that an entry MAY identify a resource in a way that is not sufficiently defined to actuate that resource.  That's bad.  It does the clients a disservice and ought not happen in anything other than an error condition.
>

I'll note that the original text was less perscriptive in that it did
not recommend that clients use OPTIONS before they actuate the
resource.  The new text was written in response to Ben's comment: " I
don't think POSTing to expect a 300 "multiple choices" response is
what folks should be doing"
(http://www.ietf.org/mail-archive/web/alto/current/msg01035.html).

Looking back, this was regarding a particular example of a POST. In
that case, I agree with him (and I suspect he was only responding to
this particular case and not in general; I'm sure he'll correct me if
I'm wrong).  However, for a GET, I would think that requesting via GET
and then handling a 300 if it comes back is the better way (removes a
round-trip in the common case).

> Structuring the description in a different way could alleviate the problem.
>
> 1. a directory identifies resources as completely as possible
> 2. error handling requires good client feedback:
>  (a) all resources provide responses to OPTIONS requests that identify their own capabilities
>  (b) resources provide appropriate HTTP responses so that clients can correct mistakes (405, 406, etc...)

In general this is fine, but note that (2a), AFAIK, is giving up the
ability to deploy an ALTO Server by dumping some static files on a
standard HTTP Server (unless http server implementations that I don't
know about do support serving a static file in response to OPTIONS).
That was appealing in its simplicity and particularly if we would like
to reduce the barriers to adoption from the provider side.  However,
the discussion regarding making other services mandatory may end up
removing this anyways.

In (1), what does that actually mean to server implementers code-wise?
 Reduce the degrees of freedom (media-types, accepts, cost modes, cost
types) for each resource entry as much as possible?  Otherwise it
seems like some warm and fuzzy guidance that is hard to translate into
actual code.  Something more explicit along the lines of what Bill
described (exactly 1 media-type, 0 or 1 accepts) might be better here.

I'll note that aside from what I mentioned above regarding OPTIONS, I
would have thought that (2) should already be handled in the draft's
text (maybe aside from the "correct mistakes" phrase).  If not, can
you (or someone) suggest improved text?

Rich

> --Martin
>
> On 2011-07-28 at 10:35:24, Bill Roome wrote:
>> Section 7.6.2, Encoding of Information Resource Directory:
>>
>>    "Each entry MUST indicate a URI that either directly provides the
>>    indicated Information Resource, or responds to a HTTP OPTIONS
>> request
>>    which provides an Information Resource Directory with entries of
>>    additional Information Resources.
>>
>>    "If an ALTO Client makes a GET or POST request to a URI that does
>> not
>>    directly provide an indicated Information Resource, the ALTO Server
>>    MUST either reply with an HTTP 300 status code ("Multiple Choices")
>>    and an Information Resource Directory in the HTTP response¹s entity
>>    body, or indicate an appropriate HTTP status code. Note that in
>>    general, it is preferred that ALTO Clients use HTTP OPTIONS requests
>>    to discover additional Information Resources."
>>
>> Here's my philosophy about protocol designs: client-server protocols
>> should be designed to simplify the client. If that pushes work onto
>> the server, tough! The goal is to simplify the client.
>>
>> So what's the problem with those paragraphs? Consider the first. That
>> says the server has two distinct choices. How can a client discover
>> WHICH choice the server made? "Try it and find out."
>>
>> Please! That's an insult to client implementors. That's a clear case
>> of designing to simplify the server, at the expense of the client.
>>
>> Furthermore, this means a client must use three techniques to get the
>> information from a info directory:
>>   * A GET request to the primary directory URI,
>>   * An OPTIONS request to a multiple-type URI, or
>>   * A "300 Multiple Choices" error response to a GET or POST.
>>
>>
>> So what's my suggestion?  Drop those two paragraphs completely.
>> Instead, allow the information resource directory to contain an entry
>> for ANOTHER resource directory, with additional services. The media-
>> type would be application/alto-directory+json, of course. Eg,
>>
>>     }, {
>>        "uri" : "http://custom.alto.example.con/extra-dictionary",
>>        "media-types" : [ "application/alto-directory+json" ]
>>     }, {
>>
>>
>> Then if a client wants to explore those services, it can do a GET on
>> that URI.
>>
>> And for those who think the original specification is necessary -- the
>> OPTIONS and 300 response and all that -- now that we've had a
>> bake-off, how many servers actually implemented those options? How
>> many clients supported them?
>>
>>       - Bill Roome
>>
>>
>> _______________________________________________
>> alto mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/alto
>
>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>