A problem with Richard's suggestion to use
cost-mode: multi-cost-types
is that a legacy client will think that cost-type field is invalid.
A client could just ignore the offending cost-type, but use the other
cost-types and resources. That would be fine.
However, a legacy client could conclude that the ALTO server is screwy,
and reject the entire IRD. After all, Section 10.5 rather emphatically
says:
The [cost mode] string MUST have a value of either "numerical" or
"ordinal".
Note that rfc 7285 says a client must ignore fields which it does not
recognize, but it does not say that clients must ignore fields with
invalid values.
This is also a problem for an extension which invents new values for
cost-mode.
- Wendy Roome
On 07/18/2016, 14:11, "[email protected] on behalf of
[email protected]" <[email protected] on behalf of
[email protected]> wrote:
>Message: 4
>Date: Mon, 18 Jul 2016 14:11:37 -0400
>From: "Y. Richard Yang" <[email protected]>
>To: wang xin <[email protected]>
>Cc: Wendy Roome <[email protected]>, IETF ALTO
> <[email protected]>, Nico Schwan <[email protected]>
>Subject: Re: [alto] Review of draft-ietf-alto-multi-cost-02 (part 1)
>
>Tony,
>
>On Mon, Jul 18, 2016 at 4:09 AM, wang xin <[email protected]> wrote:
>
>>Dear Richard and all,
>>
>>For the problem on Section 3.1, my thinking is that though it is
>>incompatible with the definition in Section 11.2.3.6 in RFC7285, which
>>specifies that the "meta" field of a cost map response MUST include the
>>"cost-type" field, this would not cause an error for ALTO clients.
>>
>What I meant is that the response does not conform to the
>alto-costmap+json
>media type syntax, and hence a standard (component) parser of this media
>type should report an error.
>
>
>>Considering that if an ALTO client receives the response like the example
>>in Sec 3.1, the ALTO client is sure to be aware of the multi-cost
>>extensions (actually, the multi-cost result is expected by the client),
>>which is guaranteed by the input parameters in the cost map request. But
>>I
>>agree that the problem should be considered and solved.
>>
>>Some potential solutions: 1. Introducing new cost-type (by Richard's
>>comment); 2. Including an empty cost-type field (just to be consistent
>>with
>>RFC7285).
>>
>>
>>Hmm. For solution 2, an empty cost-type does not look elegant to me. One
>possibility is to use the cost-type to "point to" the multi-cost-types
>definition, forming some kind of "chaining" definition, e.g.,
>
>"cost-type": {
> "cost-mode": "multi-cost-types", "cost-metric": ?
>}
>"multi-cost-types" : [
> {"cost-mode": "numerical", "cost-metric": "routingcost"},
> {"cost-mode": "numerical", "cost-metric": "hopcount"}
> ]
>
>The key issue is whether we can use this as a general technique (aka
>grammar) for the other use cases, such as path vector, cost calendar,
>performance-stat objects, ...
>
>Richard
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
