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

[Richard Alimi <[e-mail]>]

On Thu, Jul 28, 2011 at 11:07 AM, Bill Roome <[e-mail]> wrote:
> I understand; I sometimes have that affect on people!
>
> And yes, allowing a directory to identify other directories is
> sub-optimal. But it's useful when the entity providing the resource
> directory knows there's another server, but does not have the
> authoritative answer for exactly what services that server provides.
> Hence, "Sorry client, but ya better get the real information from this
> guy."
>
> Actually, here's my proposal in more detail. Each entry in the resource
> directory would have one -- AND ONLY ONE! -- media type, and 0 or 1 accept
> types. That's sufficient to define the service that entry provides and the
> method it expects.
>
> This does NOT mean that a URI is limited to one service, though, because a
> uri can appear in several entries. For example, the following means that
> "map-service" responds to a GET and returns the full map, or to a POST and
> returns a filtered map:
>
>  }, {
>    "uri" : "http://foobar/map-service",
>    "media-types" : [ "application/alto-networkmap+json" ]
>  }, {
>    "uri" : "http://foobar/map-service",
>    "media-types" : [ "application/alto-networkmap+json" ]
>    "accepts" : [ "application/alto-networkmapfilter+json" ]
>  }, {

One quick note. We already say that this one must indeed be split out:

   If an entry has an empty list for "accepts", then the corresponding
   URI MUST support GET requests.  If an entry has a non-empty list for
   "accepts", then the corresponding URI MUST support POST requests.  If
   an ALTO Server wishes to support both GET and POST on a single URI,
   it MUST specify two entries in the Information Resource Directory.

Your point does apply in the general case though (e.g., networkmap and
costmap at the same URI).

Rich

>
> I'd also suggest that the resource directory MUST be authoritative (at
> least within any Expires time). If the server cannot provide an
> authoritative description of the detailed services, then it should have
> give the uri of a directory server that can.
>
>
> Given that, is OPTIONS still necessary?
>
>        - Bill Room
>
>
>
> On 07/28/2011 13:19, "Thomson, Martin" <[e-mail]>
> wrote:
>
>>On 2011-07-28 at 12:33:10, Bill Roome wrote:
>>> I would appreciate it if you could explain how my proposal increases
>>> the coupling between the client and the server.
>>
>>I apologise, your proposal did not increase coupling.  'twas the
>>expression of philosophy that caused the allergic reaction.
>>
>>Thinking on it more, the technical proposal - that a directory can
>>identify other directories - is perfectly fine.  It's suboptimal, given
>>that the first directory could just as easily include the second, but
>>it's perfectly sound.
>>
>>There's a problem with resources that don't support GET, which is one of
>>the cases where you get 300 responses and where you need OPTIONS
>>requests.  But the general guidance there is to avoid the creation of
>>resources that don't do GET.
>>
>>--Martin
>>
>>
>
>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>