Subject: Re: [alto] Cost-type names

From: Wendy Roome <[email-masked]>
Date: Thu, 18 Jul 2013 13:51:42 -0400

First, if a server provides multiple IRDs, are cost-type names local to
each IRD? Or are they global to the set of IRDs? The examples define
cost-type names in both IRDs, which implies the names are local. But I
didn't see anything that said that.

Second, {10.1.2.4} has the following sentence under the description of
cost-type-names:

    Since an unfiltered Cost Map is requested
    via an HTTP GET that accepts no input parameters,
    an ALTO Client MUST be led towards a resource
    that has a single element in the ¹cost-type-names¹ list.

I think that would be better expressed as

    Since an unfiltered Cost Map is requested
    via an HTTP GET that accepts no input parameters,
    the 'cost-type-names' capability for that resource
    can only contain one element.

That section also says:

    If there is more than one Cost Type in this list,
    then the ALTO Server SHOULD return an IRD to the client
    to lead it towards the URIs for the corresponding Cost Maps.

I don't understand what that means. Can anyone explain it?

	- Wendy Roome

---

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

> didn't see anything that said that.

Yes, they are local to an IRD.

>     can only contain one element.

This change sounds good to me.

> I don't understand what that means. Can anyone explain it?

This means that the ALTO Server may respond with an Multiple Choices (300)
status code with the body containing an IRD.  If I recall correctly, the
explicit statement about the HTTP 300 status code was removed after a
discussion about there being too strong of a coupling between ALTO and the
HTTP layers.  I know the WG has gone back and forth over appropriate
wording for this particular issue in the past.

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

---

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

> Yes, they are local to an IRD.

... and we can double-check the draft to ensure it states this explicitly.

---

From: Wendy Roome <[email-masked]>
Date: Fri, 19 Jul 2013 11:01:17 -0400

Yes, now I remember that discussion. But isn't the current wording
misleading?  I think the server only returns an IRD with a 300 status if the
client sends a GET request rather than a POST request.

- Wendy

From:  Richard Alimi <[email-masked]>
Date:  Fri, July 19, 2013 03:31
To:  Wendy Roome <[email-masked]>
Cc:  alto <[email-masked]>
Subject:  Re: [alto] Cost-type names

This means that the ALTO Server may respond with an Multiple Choices (300)
status code with the body containing an IRD.  If I recall correctly, the
explicit statement about the HTTP 300 status code was removed after a
discussion about there being too strong of a coupling between ALTO and the
HTTP layers.  I know the WG has gone back and forth over appropriate wording
for this particular issue in the past.

---

From: Richard Alimi <[email-masked]>
Date: Fri, 19 Jul 2013 20:27:23 -0700

On Fri, Jul 19, 2013 at 8:01 AM, Wendy Roome <[email-masked]>wrote:

> misleading?  I think the server only returns an IRD with a 300 status if
> the client sends a GET request rather than a POST request.
>

The way I read RFC2616, the 300 status code can be returned for either a
GET or a POST.

We'd be happy to find a better wording.  Do you have any suggestions?

Thanks,
Rich

---

From: Wendy Roome <[email-masked]>
Date: Mon, 22 Jul 2013 16:53:10 -0400

Ah!  I see my mistake: I didn't realize that section -- {10.1.2.4}  -- only
applied to full cost maps.

But since we've taken out the "OPTIONS" example, why not just say that for a
full cost-map, the "cost-type-names" capability can only have a single
entry?  That is, replace that whole paragraph with just:

cost-type-names:   The name of the one and only Cost Type returned by this
unfiltered cost-map service. Note that the value must be a JSON array
containing a single string.

Period.  Anything more just creates confusion.

- Wendy Roome

From:  Richard Alimi <[email-masked]>
Date:  Fri, July 19, 2013 23:27
To:  Wendy Roome <[email-masked]>
Cc:  alto <[email-masked]>
Subject:  Re: [alto] Cost-type names

On Fri, Jul 19, 2013 at 8:01 AM, Wendy Roome <[email-masked]>
wrote:
> Yes, now I remember that discussion. But isn't the current wording misleading?
> I think the server only returns an IRD with a 300 status if the client sends a
> GET request rather than a POST request.

The way I read RFC2616, the 300 status code can be returned for either a GET
or a POST.

Thanks,
Rich

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 24 Jul 2013 00:02:47 -0400

Hi Wendy, and Rich,

If we apply the principle that media-type in an IRD entry is correct, then
there are two cases for an unfiltered cost map:

A single cost-type in "cost-type-names" of an unfiltered cost map, then the
IRD of a media type of costmap entry is correct.

If multiple, then the "correct" media-type is IRD.

I am fine with either way, but not multiple cost-type-names, but a media
type of costmap.

Any comments?

Richard

On Mon, Jul 22, 2013 at 4:53 PM, Wendy Roome <[email-masked]>wrote:

> Ah!  I see my mistake: I didn't realize that section -- {10.1.2.4}  --
> only applied to full cost maps.
>
> But since we've taken out the "OPTIONS" example, why not just say that for
> a full cost-map, the "cost-type-names" capability can only have a single
>> This means that the ALTO Server may respond with an Multiple Choices
>> (300) status code with the body containing an IRD.  If I recall correctly,
>> the explicit statement about the HTTP 300 status code was removed after a

---

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

Richard,

We may be talking across each other here. My understanding is that the IRD
resource entry for a full cost map must have the media type
alto-costmap+json -- that's the only indication that this resource is a full
cost map.  Similarly, the media type for a filtered cost map resource must
be alto-costmapfilter+json.

So I'd say that if a resource's media-type is alto-costmap+json, its
cost-type-names capability MUST have a single value. Anything else is an
error. If media-type is alto-costmapfilter+json, then cost-type-names MUST
have one or more values. I don't see any case under which a resource with
media-type alto-costmap+json could legitimately return an IRD.

Perhaps you're thinking of the old scheme for linking IRDs, where the
resource in the "parent" that pointed to the "child" gave the union of all
the media-types and cost-types that resources in the child IRD could return?
I believe we dropped that, in favor of a simple resource with the media-type
application/alto-directory+json, and no summary of the services provided by
that IRD.

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Wed, July 24, 2013 00:02
To:  Wendy Roome <[email-masked]>
Cc:  Richard Alimi <[email-masked]>, alto <[email-masked]>
Subject:  Re: [alto] Cost-type names

Any comments?

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 24 Jul 2013 10:12:53 -0400

Hi Wendy,

On Wednesday, July 24, 2013, Wendy Roome wrote:

> resource entry for a full cost map must have the media
> type alto-costmap+json -- that's the only indication that this resource is
> a full cost map.
>

Correct. This is the current spec. An issue, as you pointed out, I believe,
is that, if the "cost-type-names" of its "capabilities" has multiple names,
then the actual return from the server will be an IRD, not
alto-costmap+json. Personally, I consider this an inconsistency, as you
pointed out.

>  Similarly, the media type for a filtered cost map resource must

The media-type is still alto-costmap+json. alto-costmapfilter+json is for
the accept. Right?

So, the rule is:

If media-type is alto-costmap+json, and no accepts (I.e., unfiltered map),
then the cost-type-names in its capabilities can include only one entry. I
believe that this is what you propose. If others do not see problems, we
say that we reach consensus.

Richard

> error.
If media-type is alto-costmapfilter+json, then cost-type-names MUST have
> one or more values. I don't see any case under which a resource with
> the media-types and cost-types that resources in the child IRD could
> return?  I believe we dropped that, in favor of a simple resource with the
> media-type application/alto-directory+json, and no summary of the services
> provided by that IRD.
>
> - Wendy Roome
>
>
> From: "Y. Richard Yang" <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>
> To: Wendy Roome <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>
> Cc: Richard Alimi <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>, alto <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>
> A single cost-type in "cost-type-names" of an unfiltered cost map, then
> the IRD of a media type of costmap entry is correct.
>

---

From: Wendy Roome <[email-masked]>
Date: Wed, 24 Jul 2013 10:26:24 -0400

Fine with me! 

Although I'd go one small step farther and say that if an entry has
media-type alto-costmap+json, then it must not have an "accepts" entry.
Similarly, a resource with media-type alto-networkmap+json cannot have
"accepts".

Note that a server can provide full and filtered cost map services with the
same uri, via GET and POST respectively. The IRD just needs two different
entries, with the same uri but different media-types. Nothing says uris must
be unique.

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Wed, July 24, 2013 10:12
Subject:  Re: [alto] Cost-type names

Hi Wendy,
ŠŠ
So, the rule is:

If media-type is alto-costmap+json, and no accepts (I.e., unfiltered map),
then the cost-type-names in its capabilities can include only one entry. I
believe that this is what you propose. If others do not see problems, we say
that we reach consensus.

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 24 Jul 2013 10:37:59 -0400

Hi Wendy,

> media-type alto-costmap+json, then it must not have an "accepts" entry.

Only specifying the predicate: media-type==alto-costmap+json && no accepts
=> #cost-type-names has one entry is safe.

Specifying media-type==alto-costmap+ json => no accepts will make it not
possible to list filtered cost maps. Right? Hence, we limit to the first
predicate. What do you think?

> Note that a server can provide full and filtered cost map services with
> the same uri, via GET and POST respectively. The IRD just needs two
> different entries, with the same uri but different media-types. Nothing
> says uris must be unique.
>

Yes. This is good comment and worthy of an explicit sentence to point it
out.

Thanks!

Richard

> ……

---

From: Wendy Roome <[email-masked]>
Date: Wed, 24 Jul 2013 10:47:35 -0400

Oops!  I forgot that full and filtered cost maps return the same media-type.
Sorry about that.

Yes, media-type==alto-costmap+json && accepts == ""  =>  cost-type-names has
one entry.
media-type==alto-costmap+json && accepts == "alto-costmapfilter+json"  =>
cost-type-names has one or more entries.

Again, profuse apologies!

- Wendy

From:  "Y. Richard Yang" <[email-masked]>
Date:  Wed, July 24, 2013 10:37
To:  Wendy Roome <[email-masked]>
Cc:  "Y. Richard Yang" <[email-masked]>, Richard Alimi
<[email-masked]>, alto <[email-masked]>
Subject:  Re: [alto] Cost-type names

Hi Wendy,

On Wednesday, July 24, 2013, Wendy Roome  wrote:
> Fine with me! 
> 
> Although I'd go one small step farther and say that if an entry has media-type
> alto-costmap+json, then it must not have an "accepts" entry.

 

Thanks!

Richard

> [email-masked]');> >

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 24 Jul 2013 13:14:57 -0400

On Wed, Jul 24, 2013 at 10:47 AM, Wendy Roome <[email-masked]>wrote:

>
> Yes, media-type==alto-costmap+json && accepts == ""  =>  cost-type-names
> has one entry.

Great! I think we have a consensus here, at least between the two of us :-)

Thanks again for pointing out the issue.

Richard

> Cc: "Y. Richard Yang" <[email-masked]>, Richard Alimi <[email-masked]>,
> alto <[email-masked]>
>
>> If media-type is alto-costmap+json, and no accepts (I.e., unfiltered
>> map), then the cost-type-names in its capabilities can include only one
>> entry. I believe that this is what you propose. If others do not see
>> problems, we say that we reach consensus.
>>
>> Richard
>>
>