Subject: Re: [alto] Endpoint property service, network maps and the PID property

From: Wendy Roome <[email-masked]>
Date: Tue, 30 Jul 2013 10:34:55 -0400

I agree that we're going off the deep end here. We need to keep it simple
and get the protocol out-the-door as soon as possible. So here's my
suggestion. There is one space of property names, and it's independent of
network maps. If a server wants to define a property that depends on the
network map, build the map id into the property name. So an EPS resource
does NOT have a "use" attribute. Instead, any dependency is implicit in
the property names.

So the IRD entry would be
  
{
   "id" : "endpoint-property",
   "uri" : "http://alto.example.com/endpointprop/lookup",
   "media-type" : "application/alto-endpointprop+json",
   "accepts" : "application/alto-endpointpropparams+json",
   "capabilities" : {
      "prop-types" : [ "pid", "map1.pid", "priv:myprop",
"priv:map1.otherprop" ]
    },
}

We would reserve the following property names:
   pid -- the pid in the default map
   networkid.pid -- the pid in that network map

The problem is the name restrictions. Resource IDs are 0x21 to 0x7e, any
length. Property names are alphanum, plus dash colon and period, and 32
characters or less. And any property name that doesn't start with priv: or
exp: is supposed to be centrally registered. How do you want to resolve
that conflict?

I think that while may be some useful global properties, most will be
private. So I suggest we reverse the registration convention, and relax
the rules on property names {9.8} to be:

Property names must be ascii characters in the range 0x21 to 0x7e, any
length. Names starting with "alto:" are reserved and must be centrally
registered. We register the names
    alto:pid
    alto:pid.*
The latter is for map-specific pids. We could reserve alto:*.pid instead,
but I think it's cleaner to reserve a simple prefix than a prefix & suffix
pattern.  So with that convention, the IRD above would become:

{
   "id" : "endpoint-property",
   "uri" : "http://alto.example.com/endpointprop/lookup",
   "media-type" : "application/alto-endpointprop+json",
   "accepts" : "application/alto-endpointpropparams+json",
   "capabilities" : {
      "prop-types" : [ "alto:pid", "alto:pid.map1", "myprop",
"map1.otherprop" ]
   },
}

    - Wendy Roome

On 07/30/2013 02:17, "[email-masked]" <[email-masked]> wrote:

>Message: 2
>Date: Mon, 29 Jul 2013 23:17:32 -0700
>From: Richard Alimi <[email-masked]>
>To: "Y. Richard Yang" <[email-masked]>
>Cc: Wendy Roome <[email-masked]>, "[email-masked]"
>	<[email-masked]>
>Subject: Re: [alto] Endpoint property service,	network maps and the
>	PID property
>Message-ID:
>	<[email-masked]>
>Content-Type: text/plain; charset="iso-8859-1"
>
>My personal opinion when looking at these options is that we're making it
>too complicated in the base protocol, and going past the point of fixing
>bugs. Apologies for not being able to make it to the session on Monday,
>but
>I personally would prefer the IRD to be more verbose and just have each
>filtered cost map or endpoint property service be allowed to specify at
>most one network map.  Would it then be reasonable to treat optimizations
>(such as querying across multiple network maps, and reducing number of
>entries in the IRD) as extensions?
>