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

From: Alexey Melnikov <[email-masked]>
Date: Thu, 24 Mar 2016 17:46:19 +0000

Hi,

This is a well written document which was generally a pleasure to read.
And thank you for addressing Barry's comments, as some of the issues he
raised got me confused as well.

I do have several minor comments/nits that I would like to be
addressed/discussed:

In Section 4.3.5

The first mention of "media type" needs a normative reference to RFC
2045. This would save developers time with trying to find out what
syntax to support and where to find registered media types.

In 6.1:

>A rule MAY contain the following as child elements:

Nit: This is an invalid use of MAY, because it is not an implementation
choice. I don't think you meant here that implementations don't have to
support any of the listed child elements?

In 7.6:

> If no actions are defined for the standard disposition values of
> "invalid", "blocked", "allocatable", "activated", then the following
> implicitly defined default actions are evaluated.

Are default actions defined if none of the actions for recommended
standard dispositions is defined or if any of them is not defined? For
example, I was thinking whether it would be Ok to just automatically
(and unconditionally) append these default actions to any LGR file for
purposes of evaluation? If any action for standard disposition value is
already defined and it would take precedence, so the corresponding
default action would be ignored.

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.

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.

> 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>?

Please let me know if my comments are unclear.

Best Regards,
Alexey

---

From: Asmus Freytag <[email-masked]>
Date: Thu, 24 Mar 2016 16:44:04 -0700

I'll let Kim address the issues with 4.3.5 and 11.3 (media type and 
registration).

Here some comments on the issues raised against 6.1 and 7.6.

A./

> support any of the listed child elements?

What is the specification aimed at? It's a file format. That means, 
there are different levels of requirements for authors (of what may be a 
single LGR document, which does not have to include all possible 
features) and implementations (that we would expect of being able to 
interpret any well-formed LGR document). It seems to me:

  * Implementations (readers, parsers, validators) MUST support all
    features, including OPTIONAL ones.
  * Authors MAY supply any features, except those that MUST NOT be
    present, and MUST supply all required features.

In that context, MAY or not MAY in the above example?

Aside from that, would it have been better to write:

"A rule may contain the following OPTIONAL child elements"

> default action would be ignored.
Yes, this can be improved.

I think it would be cleanest to describe the "implicitly defined default 
actions" as a block of <action> elements that is added (virtually) 
beyond the last of the user-supplied actions. Any label not processed by 
the user-supplied actions would be processed by these "implicitly 
defined default actions" as if they were present in the file. As the 
last one is a "catch-all", all processing is guaranteed to end with a 
definite disposition for the label.

Note that the phrase used in the existing description ("standard 
disposition values") is potentially misleading, because we now make the 
distinction between "types" (on variant mappings) and "dispositions" (as 
result of processing labels). We didn't use to and this wording may be a 
holdover.

I'll look at suggested wording.

A./

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 25 Mar 2016 08:14:07 +0000

Hi Asmus,

> On 24 Mar 2016, at 23:29, Asmus Freytag (t) <[email-masked]> wrote:
> 
> I'll let Kim address the issues with 4.3.5 and 11.3 (media type and registration).
> 
> What is the specification aimed at? It's a file format. That means, there are different levels of requirements for authors (of what may be a single LGR document, which does not have to include all possible features)

Ok, but isn't that true for pretty much all the features in the format? Why is this one special?

> and implementations (that we would expect of being able to interpret any well-formed LGR document). It seems to me:
> 
> Implementations (readers, parsers, validators) MUST support all features, including OPTIONAL ones.

I thought your document was mostly targeting implementations. If not, having a separate section that covers authors might be a good idea.
> Authors MAY supply any features, except those that MUST NOT be present, and MUST supply all required features.

INHO, this is no better, because you are not telling who are they optional for.
> I think it would be cleanest to describe the "implicitly defined default actions" as a block of <action> elements that is added (virtually) beyond the last of the user-supplied actions. Any label not processed by the user-supplied actions would be processed by these "implicitly defined default actions" as if they were present in the file. As the last one is a "catch-all", all processing is guaranteed to end with a definite disposition for the label.

Right, this is what I thought.
> 
> Note that the phrase used in the existing description ("standard disposition values") is potentially misleading, because we now make the distinction between "types" (on variant mappings) and "dispositions" (as result of processing labels). We didn't use to and this wording may be a holdover.
> 

That would be great, thank you.

---

From: Asmus Freytag <[email-masked]>
Date: Fri, 25 Mar 2016 08:24:01 -0700

On 3/25/2016 1:14 AM, Alexey Melnikov wrote:
>> there are different levels of requirements for authors (of what may 
>> be a single LGR document, which does not have to include all possible 
>> features)
>
>> and implementations (that we would expect of being able to interpret 
>> any well-formed LGR document). It seems to me:
>>
> I thought your document was mostly targeting implementations. If not, 
> having a separate section that covers authors might be a good idea.
>>

Looked at the text in context. MAY ---> may is fine anyway, because the 
passage is somewhat introductory.
>> I think it would be cleanest to describe the "implicitly defined 
>> default actions" as a block of <action> elements that is added 
>> (virtually) beyond the last of the user-supplied actions. Any label 
>> not processed by the user-supplied actions would be processed by 
>> these "implicitly defined default actions" as if they were present in 
>> the file. As the last one is a "catch-all", all processing is 
>> guaranteed to end with a definite disposition for the label.
>
>> disposition values") is potentially misleading, because we now make 
>> the distinction between "types" (on variant mappings) and 
>> "dispositions" (as result of processing labels). We didn't use to and 
>> this wording may be a holdover.
>>

I cleaned up the passage and added a note that makes the point about 
default actions being treated as if added past the last user defined 
action.  (See below).

A./

  7.6 Default Actions <#default_actions>

If a label does not trigger any of the actions defined explicitly in the 
LGR, the following implicitly defined default actions are evaluated. 
They are shown below in their relative order of precedence (seeSection 
7.4 <#precedence>). Default actions have a lower order of precedence 
than explicit actions (seeSection 8.3 <#determining_dispositions>).

The default actions for variant labels are defined as follows. The first 
set is triggered based on the standard variant type values of "invalid", 
"blocked", "allocatable", "activated":

     <action disp="invalid" any-variant="invalid"/>
     <action disp="blocked" any-variant="blocked"/>
     <action disp="allocatable" any-variant="allocatable"/>
     <action disp="activated" all-variants="activated"/>

A final default action sets the disposition to "valid" for any label 
matching the repertoire for which no other action has been triggered. 
This "catch-all" action also matches all remaining variant labels from 
variants that do not have a type value.

     <action disp="valid" comment="Catch-all if other rules not met"/>

Conceptually, the implicitly defined default actions act just like a 
block of action elements that is added (virtually) beyond the last of 
the user-supplied actions. Any label not processed by the user-supplied 
actions would thus be processed by the default actions as if they were 
present in the LGR. As the last default action is a "catch-all", all 
processing is guaranteed to end with a definite disposition for the label.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 25 Mar 2016 16:51:36 +0000

All your suggestions look good, thank you!

---

From: Kim Davies <[email-masked]>
Date: Wed, 30 Mar 2016 22:47:31 +0000

Hi Alexey, Hi all,

>syntax to support and where to find registered media types.

OK, will add.

>to prevent clashes with private dispositions.

OK.

>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?

><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

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 30 Mar 2016 19:08:30 -0400

On 30 Mar 2016, at 18:47, Kim Davies wrote:

> Hi Alexey, Hi all,
>
> On 3/24/16, 10:46 AM, "Lager on behalf of Alexey Melnikov" 
> <[email-masked] on behalf of [email-masked]> wrote:
>
>
>
>
>>
>> In Section 4.3.5
>>

FYI, we used PEN for vCard4 private namespace. Having said that, the set 
of organisations for developing extensions of vCards is pretty small and 
well known and have 99% of chance of 1. having a PEN 2. large 
corporations with engineering staff that may find easy.  On the other 
hand, LGR editors could be linguistic experts which have no clue of the 
PEN and may not relate to PEN registration (even if it is FCFS). So I 
think domain names are probably better in this case.

Marc.

>
> kim_______________________________________________
> Lager mailing list
> [email-masked]

---

From: "Asmus Freytag (c)" <[email-masked]>
Date: Wed, 30 Mar 2016 20:41:06 -0700

> 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./

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 31 Mar 2016 09:59:40 +0100

Your proposal looks reasonable to me.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 31 Mar 2016 10:01:30 +0100

Hi Kim,

> On 30 Mar 2016, at 23:47, Kim Davies <[email-masked]> wrote:
> 
> Hi Alexey, Hi all,
> 

Yes, reviewing this generally in sensible.
> and are not used elsewhere in the document.

I think I would go with Marc's suggestion to use domain names.