Subject: [alto] IRD declaration

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 7 May 2013 16:18:59 -0400

Dear all,

As we work to finalize a newer version to get feedback, here is a quick
question that we need feedback/comments to have a quick closure. The issue
can be discussed using the current posted version (
http://datatracker.ietf.org/doc/draft-ietf-alto-protocol/?include_text=1),
although we will post a newer version soon.

Specifically, consider the first IRD example in Sec. 7.6.3. One can
identify that among the six entries, 5 are base or "leaf" entries, which
represent specific Information Resources, and one is a "container" entry:

{
         "uri" : "http://custom.alto.example.com/maps",
         "media-types" : [
           "application/alto-networkmap+json",
           "application/alto-costmap+json"
         ],
         "accepts" : [
           "application/alto-networkmapfilter+json",
           "application/alto-costmapfilter+json"
         ]
       },

In other words, one can envision that IRD can be a hierarchy for
flexibility and delegation.

A question is whether we explicitly distinguish such two types of
entries in syntax -- they are different in semantics already.

Note that distinguishing the two types by simply checking the number
of entries in media-types or accepts will be less robust.

One possibility is the following. A "leaf" IRD entry has the format:
 "uri": ""
 "media-type": ""
 "accept": ""
 "capabilities" : {}

A "container" IRD has the format:
  "uri" :
  "media-types" : []
  "accepts" : []
  // no capabilities

Any thought?

Richard

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 8 May 2013 10:17:33 +0200

Hi Richard,

since the new version has been submitted, the actual section with the
example you mention is 8.5.3
(http://tools.ietf.org/html/draft-ietf-alto-protocol-15#section-8.5.3).

On the substance of the question, I believe it's essential to have the
syntax flexible enough to reflect proper semantics. However -- forgive
the JavaScript speak --  with the current specification the distinction
between "leaf" and "container" would basically require a check on
(media-types.length == 1), while with the proposed change it would turn
out to (typeof media-types == "string"), correct?

If that's the case, honestly I don't see a big gain in doing it. But I'm
not an implementor nor have a strong preference, so I'll let others
express more articulated opinions. Either way works for me.

Enrico

On 5/7/13 10:18 PM, Y. Richard Yang wrote:
> question that we need feedback/comments to have a quick closure. The
> issue can be discussed using the current posted version
> (http://datatracker.ietf.org/doc/draft-ietf-alto-protocol/?include_text=1),
> Note that distinguishing the two types by simply checking the number of
> entries in media-types or accepts will be less robust. 
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 8 May 2013 14:34:27 -0400

Enrico,

> (http://tools.ietf.org/html/draft-ietf-alto-protocol-15#section-8.5.3).

Yes.

> out to (typeof media-types == "string"), correct?

It can be more complex. For example,  the just submitted version allows IRD
to announce multipe cost types of an unfiltered cost map with a single
media type. Hence we have a case that media-types has a length of 1 but we
do not have a leaf node.

As another example. Consider a possible future extension, where we may
consider allowing two media types for one IR: for example,  both the
current cost map format or a new matrix format. Hence, IRD could announce
two media types for it, and ALTO Clients can indicate one using http Accept
in request. Hence, we have a case of media-types with length > 1, but we
have a leaf.

Regardless indicating leaf vs non-leaf explicitly, I do not foresee
encountering non-encodable problems with the current spec. There can be
some difference in ease of implementation. My personal preference is
explicit leaf nodes and hence no need for a Client to request an IR but get
an IRD back. But the current spec works and can be more compact for IRD
representation.

Thanks!

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

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 8 May 2013 21:26:45 +0200

On 5/8/13 8:34 PM, Y. Richard Yang wrote:
> It can be more complex. For example,  the just submitted version allows
> IRD to announce multipe cost types of an unfiltered cost map with a
> single media type. Hence we have a case that media-types has a length of
> 1 but we do not have a leaf node.

Right, didn't think of that.

I agree that current spec is suboptimal for such a case. Can't tell
whether the gain from an extended spec is worth the added complexity.
Would love to hear from implementors.

Enrico

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 9 May 2013 23:28:38 -0400

Hi Enrico,

It may not worth changing the spec at this moment, but I as well would like
to hear from other implementors such as Wendy, ...

Richard