Subject: [alto] Format of ALTO cost-types?

From: Wendy Roome <[email-masked]>
Date: Thu, 20 Mar 2014 09:54:06 -0400

Folks,

We were careful to spell out the length and character set restrictions on
cost-metrics, PID names, and so on. But unless I missed it, we didn¹t put
any restrictions on cost-type names. I think the natural place for that
would be {10.7}.

Are the restrictions listed somewhere else and I missed them?

If not, should we say that cost-type names must follow the same rules as
resource-ids, as defined in {10.2}?

Yes, I know it¹s too late to change the official document; I assume this
is a candidate for the errata sheet.

	- Wendy Roome

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 20 Mar 2014 14:59:13 -0400

Hi Wendy,

To clarify, you mean the assigned name in IRD. For example, in the example
below, it is "num-routing", "num-hop", right?

HTTP/1.1 200 OK
   Content-Length: 2333
   Content-Type: application/alto-directory+json

   {
     "meta" : {
        "cost-types": {
           "num-routing": {
              "cost-mode"  : "numerical",
              "cost-metric": "routingcost",
              "description": "My default"
           },
           "num-hop":     {
              "cost-mode"  : "numerical",
              "cost-metric": "hopcount"
           },
           "ord-routing": {
              "cost-mode"  : "ordinal",
              "cost-metric": "routingcost"
           },
           "ord-hop":     {
              "cost-mode"  : "ordinal",
              "cost-metric": "hopcount"
           }
        },

The related definition then is

 object-map {
     JSONString -> CostType;
   } IRDMetaCostTypes;

 object {
     JSONString cost-type-names<1..1>;
   } CostMapCapabilities;

The proposal is to limit JSONString? I agree that this is more consistent
with PIDName, Resource ID, ... We restricted PIDName and Resource ID with
an intention of introducing hierarchy in the future (e.g., this is why '.'
is not allowed ...) Is this necessary for CostType names?

Thanks!

Richard

On Thu, Mar 20, 2014 at 9:54 AM, Wendy Roome <[email-masked]>wrote:

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

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: Wendy Roome <[email-masked]>
Date: Thu, 20 Mar 2014 15:54:07 -0400

Richard,

Yes, those are the names I was referring to.

ALTO puts two restrictions on names: length and charset. I believe the
length restrictions were added for clients in languages like C with limited
support for arbitrary length strings. I gather a server at the first
inter-op test used very long tag strings, and one or more clients couldn¹t
handle them.

The charset restriction for PID names was to allow a possible hierarchy. The
charset restriction for resource ids was because resource-ids can be
qualifiers in resource-specific property names ‹ see {10.8.1}.

It would be nice to define a length limit for cost-type names, to simplify
clients and for consistency with the other name classes. I don¹t see any
inherent need to restrict their character set. But that said, it would make
the IRD a lot more readable if we restrict cost-type-names to the same
charset as resource ids.

BTW, a JSONString is any quoted string acceptable to JSON, isn¹t it? If so,
it can be any number of unicode characters. So saying that cost-type-names
must be JSONStrings does not restrict the names in any way.

- Wendy

From:  "Y. Richard Yang" <[email-masked]>
Date:  Thu, March 20, 2014 at 14:59
To:  Wendy Roome <[email-masked]>
Cc:  IETF ALTO <[email-masked]>
Subject:  Re: [alto] Format of ALTO cost-types?

Hi Wendy,

   {
     "meta" : {
        "cost-types": {
           "num-routing": {
              "cost-mode"  : "numerical",
              "cost-metric": "routingcost",
              "description": "My default"
           },
           "num-hop":     {
              "cost-mode"  : "numerical",
              "cost-metric": "hopcount"
           },
           "ord-routing": {
              "cost-mode"  : "ordinal",
              "cost-metric": "routingcost"
           },
           "ord-hop":     {
              "cost-mode"  : "ordinal",
              "cost-metric": "hopcount"
           }
        },
The related definition then is
 object-map {
     JSONString -> CostType;
   } IRDMetaCostTypes;
 object {
     JSONString cost-type-names<1..1>;
   } CostMapCapabilities;
The proposal is to limit JSONString? I agree that this is more consistent
with PIDName, Resource ID, ... We restricted PIDName and Resource ID with an
intention of introducing hierarchy in the future (e.g., this is why '.' is
not allowed ...) Is this necessary for CostType names?

Thanks!

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 21 Mar 2014 09:55:26 -0400

Hi Wendy,

On Thursday, March 20, 2014, Wendy Roome <[email-masked]> wrote:

> inter-op test used very long tag strings, and one or more clients couldn't
> handle them.
>

I remember the same.

>
> The charset restriction for PID names was to allow a possible hierarchy.
> The charset restriction for resource ids was because resource-ids can be
> qualifiers in resource-specific property names -- see {10.8.1}.
>
> clients and for consistency with the other name classes. I don't see any

Agreed.

Good catch indeed.

Richard

>
> BTW, a JSONString is any quoted string acceptable to JSON, isn't it? If
> so, it can be any number of unicode characters. So saying that
> cost-type-names must be JSONStrings does not restrict the names in any way.
>
> - Wendy
>
> From: "Y. Richard Yang" <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >
> To: Wendy Roome <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >
> Cc: IETF ALTO <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 21 Mar 2014 13:47:41 -0400

Hi all,

Below is a proposed potential small change (either RFC editor or Errata).
The change is not to address a correctness issue, but does make the
protocol easer to make. Please let us know if you see any problems. The
change is marked with -- new

------
9.2.2.  Encoding

   An Information Resource Directory response may include in "meta" the
   "cost-types" key, whose value is of type IRDMetaCostTypes defined
   below, where CostType is defined in Section 10.7,
   -- begin new
   and CostTypeName is
   defined in Section 10.7
   -- end new:

   object-map {
     CostTypeName -> CostType;   // -- new change from JSONString to
CostTypeName
   } IRDMetaCostTypes;

10.7.  Cost Type

   The combination of a CostMetric and a CostMode defines a CostType:

   object {
     CostMetric cost-metric;
     CostMode   cost-mode;
     [JSONString description;]
   } CostType;

   'description', if present, MUST contain a string with a human-
   readable description of the cost-metric and cost-mode.  An ALTO
   Client MAY present this string to a developer, as part of a discovery
   process.  But the field is not intended to be interpreted by an ALTO
   Client.

  -- begin new
  A Cost Type can be assigned a name in IRD (see Section 9.2.2). A Cost
  Type name is a JSON string with the same format as that of a PIDName
  (Section 10.1). The type 'CostTypeName' is used in this document to
  indicate a string of this format.
  -- end new

On Fri, Mar 21, 2014 at 9:55 AM, Y. Richard Yang <[email-masked]> wrote:

>> It would be nice to define a length limit for cost-type names, to
>> simplify clients and for consistency with the other name classes. I don't
>> see any inherent need to restrict their character set. But that said, it
>> would make the IRD a lot more readable if we restrict cost-type-names to
>> the same charset as resource ids.
>>
>
> Agreed.
>
> Good catch indeed.
>
> Richard
>
>>
>> To clarify, you mean the assigned name in IRD. For example, in the
>> example below, it is "num-routing", "num-hop", right?
>>
>> HTTP/1.1 200 OK
>>    Content-Length: 2333