Subject: Re: [alto] IRDs in draft 17

From: Wendy Roome <[email-masked]>
Date: Wed, 17 Jul 2013 12:13:24 -0400

A few comments on the new id and uses fields in the IRD:

* In the last part of {8.5.2}, shouldn't there be an entry describing the
"id" field?

* In the "custom" IRD in {8.5.4}, I assume the "filtered-network-map"
service returns a subset of the full map returned by
"default-network-map". So shouldn't that entry say that it uses
"default-network-map"?

* {8.5.2} says "uses" is an array. That's general, obviously, but can
anyone give an example of why "uses" would have more than one entry? For
that matter, when would "uses" ever refer to anything other than a full
network map service?

(At first I thought we'd need multiple entries to indicate that the client
could get the map from a full or filtered map service. But I think it's
much cleaner to say that the filtered network map service depends on the
full service.)

* The "custom" IRD in {8.5.4} depends on the "example" IRD in {8.5.3}, but
doesn't link to it. So by itself, the "custom" IRD is useless; the client
must also know about the "example" IRD.

Does that bother anyone?

That means that discovery should only return "parent" IRDs, like
"example", not "child" IRDs like "custom."

* When IRDs link to other IRDs, do we require that the links form a
non-looping rooted tree?  If so, fine; a client can easily start at the
root and walk the tree. But if links can loop, then the client has to
determine whether it's visited an IRD before. Unfortunately the client
cannot simply compare the URIs, because URI's aren't canonical. In
particular, redirection could mean that the client's idea of the root
IRD's URI might not be identical to what the ALTO server provider idea of
the root IRD's URI.

So the client needs some other mechanism to determine if it's visited an
IRD before. I suppose it could use the set of resource IDs as a key, but
that's a hassle. I think the easiest solution is to require that each IRD
in the set have a unique "id". Eg, add an IRD "id" field at the top level,
along with "meta" and "resources".

	- Wendy Roome

---

From: Richard Alimi <[email-masked]>
Date: Fri, 19 Jul 2013 00:52:34 -0700

> * In the last part of {8.5.2}, shouldn't there be an entry describing the
Yes - that is missing. We will add it.  Thanks for pointing it out.

> "default-network-map". So shouldn't that entry say that it uses
Yes - I think it should. We'll fix that and ensure the document says that
this should be done for filtered network maps.

> that matter, when would "uses" ever refer to anything other than a full

Example: filtered cost map uses the full cost map and the full network map.
 (We'll also fix the text in the document to state this explicitly.)

> much cleaner to say that the filtered network map service depends on the

Agreed.

> "example", not "child" IRDs like "custom."

Correct.  There was a response by Ben about this in another thread, and I
agree with the assessment there that its up to the client to have visited
the relevant pages.  In other words, I personally agree its not worth
guarding against clients who are "eager" and forget where they came from.

> along with "meta" and "resources".

ALTO Clients need to handle circular redirects from HTTP anyways, and this
is a very similar problem.  If a client wants to do something more
intelligent than just a hard cap on the number of redirects, then one
possibility would be to come up with a fingerprint for an IRD which is a
function of the resource IDs that the IRD describes.

Rich

>         - Wendy Roome
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>