Subject: [alto] Draft-08 Information Resource Directory

From: Robert Varga <[email-masked]>
Date: Mon, 13 Jun 2011 19:57:18 +0200

Hi everyone,

I have couple of questions which I think need addressing in the way
Information Resource Directory (IRD) is specified.

1) Should the server include its own IRD in the response? It is not
clear if it is considered an Information Resource (IR) in itself.

2) I think we should only carry pointers to foreign IRDs, not IRs, as
that can lead to confusion. This is illustrated in section 7.6.3, where
the client may believe it can mix a
application/alto-networkmapfilter+json POST filter with a
application/alto-costmap+json Accept: header when talking to
http://custom.alto.example.com/maps.

3) I think local resources should have URI References instead of
Absolute URIs. It would save space and allow plain HTTP proxies to work.

-- 
Robert Varga
Pantheon Technologies, s.r.o.
Mlynske Nivy 56
831 05 Bratislava

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 13 Jun 2011 23:31:01 +0100

Robert,

> clear if it is considered an Information Resource (IR) in itself.

IMO the IRD is an IR and so a server could include the IRD in the response.

> http://custom.alto.example.com/maps.

I don't really understand what you mean by "only carry pointers to foreign IRDs, not IRs", could you elaborate?

The client does need some logic, for example that networkmapfilters return networkmaps and not costmaps, section 7.7.3 states the body of the POST is a networkfilter and the returned media type is a networkmap (not a costmap). So the example you cite is IMO a clear error on the client's behalf and the client would get returned an appropriate HTTP error response (and possibly an alto-error in the body depending on server support and what the client specified int he Accept request header).
   
> Absolute URIs. It would save space and allow plain HTTP proxies to work.

I disagree, there is no need for us to be prescriptive WRT URIs IMO it is just unnecessarily limiting implementations. If you are concerned about saving space I suggest we include a "base" property in the alto-directory media type to allow for relative URIs in the resource directory (similar to the way Atom/RFC4287 uses a base property for that purpose).

Ben

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 14 Jun 2011 14:34:08 +0800

I certainly see no point in constraining the representation of the URI, with one caveat:  If you permit relative URIs, clients need to support them.  That's not inherently simple, though most APIs do all the hard work for you.

On 2011-06-14 at 08:31:01, Ben Niven-Jenkins wrote:
> If you are concerned 
> about saving space I suggest we include a "base" property in the alto- 
> directory media type to allow for relative URIs in the resource 
> directory (similar to the way Atom/RFC4287 uses a base property for 
> that purpose).

I'm not a fan of explicit overrides for base URIs, though it can sometimes pay to be explicit, particularly if things move.

Using the nomenclature of HTTP, the base URI should be determined either from the effective request URI or the value of the Content-Location header.

See: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#section-6.1

Regarding clause 4, an unverified assertion about URI is sufficient for the purposes of identifying a base URI.

--Martin

---

From: Robert Varga <[email-masked]>
Date: Tue, 14 Jun 2011 12:39:58 +0200

Ben,

please see inline

> IMO the IRD is an IR and so a server could include the IRD in the response.

That is my thinking, too. But I can argue the opposite point:

1) IRD has a slightly different format then all the other IRs (no meta
field for example)
2) absolute URIs are used for pointers, the client may mistake a local
IRD for a pointer to different server -- in the hope it can find a
service which is not present on the server it is talking to.

I think we need to be very specific here.

> I don't really understand what you mean by "only carry pointers to foreign IRDs, not IRs", could you elaborate?

The current format does not allow the client to easily see which IRs are
local to the server and which are not. If we do not list local IRD in
itself and only allow it to list local IRs and foreign IRDs, the client
can easily see which is where.

> The client does need some logic, for example that networkmapfilters return networkmaps and not costmaps, section 7.7.3 states the body of the POST is a networkfilter and the returned media type is…

I agree that it would be a protocol violation, no question about that.

> I disagree, there is no need for us to be prescriptive WRT URIs IMO it is just unnecessarily limiting implementations. If you are concerned about saving space I suggest we include a "base" property…

URI References are more general then URIs, so this places a heavier
burden on the clients, but allows more, not less, flexibility. Also (as
pointed out by Thomas), HTTP has the mechanism to provide for base URIs,
so this really becomes a question of 'why not use them?'.

Bye,
Robert

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 Jun 2011 20:00:59 +0100

Robert,

> 1) IRD has a slightly different format then all the other IRs (no meta

IMO that is purely incidental. 

> service which is not present on the server it is talking to.

The client should know what it requested and act appropriately.

> can easily see which is where.

Why does it matter whether the client knows which are local and which aren't? What matters is the client knows how to access the resources it requires.

> so this really becomes a question of 'why not use them?'.

I wasn't arguing not to use them, I was simply saying that forcing 'local' resources to use URI References is unnecessary.

Ben