Subject: [alto] map-vtag format rules

From: Bill Roome <[email-masked]>
Date: Thu, 01 Sep 2011 09:36:41 -0400

There's also the question of what characters are legal in a map-vtag.

{7.5.1} says PID names have to be US-ASCII, alphanumeric, 64 characters
max. Why not do the same for map-vtags?

	- Bill Roome

>Date: Sat, 27 Aug 2011 07:58:47 +0200
>From: Enrico Marocco <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>
>Server implementations seen at the interoperability event have shown a
>broad variety of formats for the 'map-vtag' field, with lengths varying
>from 1 char to tens of chars. It has been pointed out that some explicit
>indication in the specs about the length and perhaps the format of the
>field could lead to a more homogeneous use of it.
>
>Possible options (please express and possibly motivate your preference):
>
>  1. leave the format and length unspecified, possibly allowing
>     implementations to override its semantics (e.g. piggybacking
>     additional/proprietary information);
>
>  2. define an upper limit to the length of the field, but leave format
>     unspecified;
>
>  3. other.
>
>--
>Ciao,
>Enrico

---

From: Richard Alimi <[email-masked]>
Date: Sat, 24 Sep 2011 11:19:41 -0700

> max. Why not do the same for map-vtags?

Well, so 7.5.1 also states that they must be alphanumeric characters
or the '.' character. Given that they are opaque and
not-to-be-standardized identifiers, then we could probably be much
less restrictive here.

How about for map-vtags: Any US-ASCII character within 0x20 and 0x7E
(before encoding according to JSON, of course).

Also, it has been requested that PID names also have a larger
character set.  Would there be any complaints with doing the same for
PID names (with the existing rule still in place about '.')?  The only
(admittedly-small) concern I would have is that it might be confusing
from a human-readability perspective if we ever did something with
hierarchical PIDs and other punctuation characters were combined with
the '.' in the same PID name.

Thoughts?
Rich

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

---

From: Bill Roome <[email-masked]>
Date: Mon, 26 Sep 2011 10:28:24 -0400

By "larger character set", do you mean 16-bit unicode? I can see where
that would be more general, but that will complicate implementations.

Also, it would be convenient of PIDs cannot contain "/", so PID names are
syntactically distinct from CIDRs. That simplifies configuration tables.
For example, a network map can be specified by a white-space-separated
sequence of PID names & CIDRs, where each CIDR is in the preceding PID.

Yes, of course I could use XML. But I find XML annoying to type, so I
prefer simpler alternatives whenever practical.

	- Bill Roome

---

From: Robert Varga <[email-masked]>
Date: Tue, 27 Sep 2011 11:44:14 +0200 (CEST)

I think Richard meant having ASCII names, but relaxing the alphanumeric restriction. I am all for it, as my experience from testing indicates that humans need some sort of punctuation in PID names, with underscore being the most widely used offender. How about unifying the restrictions for strings representing PID name, Cost Type and Endpoint Property?

Bye,
Robert

----- Original Message -----
From: "Bill Roome" <[email-masked]>
To: "Richard Alimi" <[email-masked]>
Cc: [email-masked]
Sent: Monday, September 26, 2011 4:28:24 PM
Subject: Re: [alto] map-vtag format rules

	- Bill Roome

---

From: Richard Alimi <[email-masked]>
Date: Tue, 27 Sep 2011 08:31:23 -0700

On Tue, Sep 27, 2011 at 2:44 AM, Robert Varga <[email-masked]> wrote:
> I think Richard meant having ASCII names, but relaxing the alphanumeric restriction.

Yes, still ASCII.

> I am all for it, as my experience from testing indicates that humans need some sort of punctuation in PID names, with underscore being the most widely used offender. How about unifying the restrictions for strings representing PID name, Cost Type and Endpoint Property?
>

I think there is a distinction between cost-type and endpoint property
as compared to pid names.  Cost-type and endpoint property will appear
in IANA registries and it would seem kind of "messy" to have all kinds
of weird punctuation there.  Beyond that, though, I don't know of a
good technical reason.

Rich