Re: [Lager] Incoming AD review on draft-ietf-lager-specification-11.txt

On 3/30/2016 3:47 PM, Kim Davies wrote:
> Hi Alexey, Hi all,
>
> On 3/24/16, 10:46 AM, "Lager on behalf of Alexey Melnikov" <lager-bounces@ietf.org on behalf of aamelnikov@fastmail.fm> wrote:
>
>
>
>> In 11.3:
>>
>> I think this section needs a bit of work. Firstly, it might be better to
>> say that Standard Dispositions MUST NOT contain ":" character in order
>> to prevent clashes with private dispositions.
> OK.
>
>> Also, saying that registered values are lowercase ASCII (for example)
>> would be a good idea. If you want to only allow ASCII, but not to limit
>> values to lowercase letters, then you need to say whether values in the
>> registry are case-sensitive or not.
> I imagine this observation can be made more generally across the specification.
> I can make this change but wonder if the case-sensitivity needs to
> be explicit in other aspects of the specification for the same reason?

We have the following  names / id's in the spec:

language (*) - rfc5646
scope (*)
reference id
tag value
variant type
class name
rule name
property name(*) - uax42
disposition (*)

The ones marked with a * are externally visible. For some, we are 
referencing an external specification which settles the issue (noted 
following the "-"). For scope, we are specifying that type="domain" 
contains a domain name, so casing rules for domain names apply. For 
other uses we require an IETF spec or a different namespace, all casing 
rules would thus be external.

While we recommend the use of integers as reference IDs, we allow 
uppercase letters, but not lowercase ones.

For the other internally visible id values, such as tag, variant type, 
class and rule names, the simplest thing would be to make them case 
sensitive. (Especially for tag values, some mixed-case use has become 
the norm for the root zone LGR project, for example.) There's no benefit 
of allowing case-insensitive matching.

Changes needed:
5.3.2 "containing spaces. This value is" --> "containing spaces. This 
value is case-sensitive and is".
6.2.1 "single, identifier" --> "single, case-sensitive identifier"
6.2.2. "space separated tag values" --> "space separated and 
case-sensitive tag values"
6.3.4 "a unique "name" attribute, and all" --> "a "name" attribute 
containing a single case-sensitive identifier not containing spaces. 
Names for rules must be unique. All"

Leaves the disposition values. These are not used internal to the spec, 
but are the output values. For the IETF defined ones, I think we intend 
to use the exact strings (case sensitive), and for externally supplied 
ones, again that is up to anyone registering values.

A./
>
>>> Private Dispositions - This registry shall list dispositions that
>>> have been registered on a first-come first-served basis by third parties
>>> with the IANA. Such dispositions must take the form "entity:disposition"
>>> where the entity is a prefix that uniquely identifies the private user
>>> of the namespace. For example, "acme:reserved" could be a private extension
>>> used by the organization ACME to denote a disposition relating to reserved
>>> labels.
>> I think "entity" should be better specified. Which characters are
>> allowed? I would recommend either use domain names to describe ownerhip
>> (I can suggest some text) or use values from the PEN IANA registry
>> <https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers>?
> Given it sounds like you have a clear concept in your mind, I would appreciate
> suggested text on how to use domain names or PENs to namespace the private
> dispositions. A domain name based approach may be the simplest option here
> given that PENs may be an unfamiliar concept to typical authors of these tables,
> and are not used elsewhere in the document.
>
> kim
>
>
> _______________________________________________
> Lager mailing list
> Lager@ietf.org
> https://www.ietf.org/mailman/listinfo/lager