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

["Thomson, Martin" <[e-mail]>]

If you'll excuse the top post, I'll try to formulate a strategy for dealing with this problem.

The two paragraphs that Bill originally cited have a fairly significant problem: they describe non-deterministic behaviour.  That doesn't mean that you can't build a server that is easily deterministic, or one that relies solely on static files, or any of the other modes of operation you might want to enable, but it requires that a greater understanding is required to properly implement or deploy.

I'd suggest that you remove those specific paragraphs and instead include something like:

  Any resource MAY provide a response to an OPTIONS request that is in the format of an ALTO information resource directory.  This gives a client a means to discover resource capabilities.

On reflection, specific text on 300 responses probably isn't going to be useful.  Multi-choice is by definition non-deterministic.

Regarding IRD having only one content type and 0..1 accepts, that isn't going to change the underlying model.  Resources are going to need to be able to provide multiple content types.  Unless you want to foreclose on the use of conneg for version negotiation.

--Martin


On 2011-07-30 at 11:02:44, Richard Alimi wrote:
> 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
> >