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

[Richard Alimi <[e-mail]>]

Hi Bill,

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" ]
>  }, {

As I noted in a previous response, this is already done to distinguish
between GET and POST.  I'm okay with adding requirements as you note
above. It can reduce a small bit of logic at the client, but, as
Martin mentioned, I don't think it solves the problem you are trying
to solve.

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
>