Subject: [Lager] Working Group Last Call: draft-ietf-lager-specification

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 8 Feb 2016 18:35:55 +0000

This message initiates a two-week Working Group Last Call for draft-ietf-lager-specification, ending Friday, February 19, 2016. Please submit substantive comments of support or other review feedback to this mailing list ([email-masked], preferably on this thread) or to [email-masked], prior to that date. We need to see comments reflecting support for the document or identification of any remaining issues in order to judge rough consensus of the working group before it can be sent to our Area Director to start the formal publication process. Here's a link to the document:

https://datatracker.ietf.org/doc/draft-ietf-lager-specification/

Thank you,
Scott and Marc

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 11 Feb 2016 12:05:09 +0000

> -----Original Message-----
> From: Lager [mailto:[email-masked]] On Behalf Of Hollenbeck,
> Scott
> Sent: Monday, February 08, 2016 1:36 PM
> To: lager WG ([email-masked])
> Subject: [Lager] Working Group Last Call: draft-ietf-lager-
> specification
> 
> This message initiates a two-week Working Group Last Call for draft-
> ietf-lager-specification, ending Friday, February 19, 2016. Please
> submit substantive comments of support or other review feedback to this
> mailing list ([email-masked], preferably on this thread) or to lager-
> [email-masked], prior to that date. We need to see comments reflecting
> support for the document or identification of any remaining issues in
> order to judge rough consensus of the working group before it can be
> sent to our Area Director to start the formal publication process.

A reminder: we need to see comments expressing support for the document in addition to any comments describing issues. The document can't move forward without WG consensus, and without last call comments Marc and I can take no measure of consensus. Please, read the document and share your thoughts.

Scott

---

From: Asmus Freytag <[email-masked]>
Date: Thu, 11 Feb 2016 08:45:30 -0800

> A reminder: we need to see comments expressing support for the document in addition to any comments describing issues. The document can't move forward without WG consensus, and without last call co…

There are a small number of minor typos that should be corrected during 
publication, but otherwise I see no issues with the document; the 
specification itself is being used successfully in several projects, 
including in the Root Zone LGR project. Altogether, about forty 
different LGRs or draft LGRs have been expressed in this format by now, 
covering writing systems from around the world.

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 17 Feb 2016 17:39:48 +0000

> sent to our Area Director to start the formal publication process.

As currently planned the last call described above ends in two days. To date there's been only one comment shared. That's nowhere near enough to say that we have consensus to move it forward. Please, people, get those comments in ASAP.

Scott

---

From: Kim Davies <[email-masked]>
Date: Wed, 17 Feb 2016 17:46:14 +0000

Hi all,

> As currently planned the last call described above ends in two days. To date there's been only one comment shared. That's nowhere near enough to say that we have consensus to move it forward. Pleas…

As a co-author, I believe the document is in good shape and ready to proceed. It has gone through four years of evolution as an I-D, most recently in the constructs of this working group. As Asmus noted it has been put to practical use by the Root LGR work. From my (IANA) perspective we are looking forward to migrating to the specification for our work once it is finalized.

kim

---

From: Sarmad Hussain <[email-masked]>
Date: Wed, 17 Feb 2016 17:53:41 +0000

Hi all

We have been using the specifications for Root zone LGR proposals for different scrips, some with complex variant mapping like Arabic, and some with complex structural rules like Khmer and Lao.  We have been able to capture the varied requirements for these scripts using the specifications and therefore support the draft.

Regards

Sarmad
ICANN IDN Program

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 17 Feb 2016 13:27:08 -0800

Sorry for the late response on this. I have tracked 
draft-ietf-lager-specification since it was draft-davies-idntables. The 
current draft is complete and fixes all the significant issues that I 
have heard during the discussion in the past few months. In particular, 
the changes made in the -07 significantly tightened up a lot of the 
prose. I believe that this is ready for IETF Last Call and 
standardization.

--Paul Hoffman

---

From: Alireza Saleh <[email-masked]>
Date: Thu, 18 Feb 2016 10:38:15 +0000

Hi,

Sorry for the late reply. And +1 in favor of supporting the specs.

-Alireza

On 2/17/16, 9:16 PM, "Lager on behalf of Kim Davies"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi all,
>
>> As currently planned the last call described above ends in two days. To
>>date there's been only one comment shared. That's nowhere near enough to
>>say that we have consensus to move it forward. Please, people, get those
>>comments in ASAP.
>
>As a co-author, I believe the document is in good shape and ready to
>proceed. It has gone through four years of evolution as an I-D, most
>recently in the constructs of this working group. As Asmus noted it has
>been put to practical use by the Root LGR work. From my (IANA)
>perspective we are looking forward to migrating to the specification for
>our work once it is finalized.
>
>kim

---

From: Wil Tan <[email-masked]>
Date: Fri, 19 Feb 2016 01:51:59 +1100

On Thu, Feb 18, 2016 at 4:39 AM, Hollenbeck, Scott <[email-masked]
> wrote:

> say that we have consensus to move it forward. Please, people, get those

I have an independent implementation of the draft with substantial coverage
of the rules processing. Aside from a small grammar bug [1] in the RelaxNG
I found today, I believe the draft is in good shape for standardization.

.wil

[1] https://trac.tools.ietf.org/wg/lager/trac/ticket/33

---

From: Audric Schiltknecht <[email-masked]>
Date: Thu, 18 Feb 2016 11:47:10 -0500

Hello,

The current draft fixes all main issues raised in the last months, and I believe is ready to move
forward for IETF Last Call.

Audric

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Feb 2016 17:49:47 -0500

Dear colleagues,

I have read draft-ietf-lager-specification-08, but I haven't reviewed
the appendices.  I have a few comments.  These are all pretty minor,
but I think that fixing them would make IETF last call easier.  I
think the document could go ahead without any of these changes if you
like.

I note the document uses RFC 2119 keywords, but there's no reference
to it.  Any reason?  (Probably wise to fix this; I think it's a
shepherd checklist thing anyway.)

§3.2: to follow the 2119 convention more closely, this could say

    Each "lgr" element MAY contain zero or one "meta" element, MUST
    contain exactly one "data" element, and MAY contain zero or one
    "rules" element; these three elements MUST be in that order.

I don't feel strongly about this.

§3.3

    The "unicode-version" element MUST be used by
   a consumer of the table to identify that it has the correct Unicode
   property data to perform operations on the table.

Given that the meta element is optional, what does a consumer do if
it's not there?

If a document is not versioned (3.3.1), that would seem to make it
possible for two interoperating consumers to use the "same" LGR and
get different results.  That would seem to be a bad thing.  Maybe say
that an LGR SHOULD have either a version or a date (or both), and note
the possibile consequences for interoperation if that fails?

§3.3.3 uses "specific" a lot, and I don't understand what distinction
it is making.  For instance, "If the LGR applies to a specific
script…" Is this to distinguish LGRs that apply to generic scripts?
If so, some text here explaining that would help.  Is this the point
of the "specific set of multiple languages or scripts" text?  (In that
case, I'm not sure "specific" is wanted.)

§3.3.4, "MUST be a valid absolute domain name, without a trailing
dot."  I'd spell that "a domain name written relative to the root
zone, in presentation format."  But that makes the whole thing kind of
strange, because you can represent the root zone (with ".").  Also,
what is a valid domain?  Is this a name that conforms to STD 13?  I
think that won't work, because there's no way to tell what encoding
the name is in, so you can't tell what the octets are.  I'd restate
this all as 'MUST be a valid domain name under IDNA2008 (i.e. a name
either containing at least one U-label or else a name made entirely of
NR-LDH labels).  It MUST be written relative to the root zone, in
presentation format; or else it MUST refer to the root zone itself,
using the presentation format ".".'  This is slightly problematic,
however, because it means that it wouldn't be possible to use this
mechanism to refer to policies that permitted (say) plain Unicode
characters in domain name labels.  Given the use case, that's probably
ok, but it means this mechanism won't work for names in (say)
apple.com (which reportedly uses spaces in SRV labels for wide-area
Bonjour).

This section also says 'values must be in a namespace "apptype"
previously defined in the document,' but doesn't say how to do that.
(Might be ok, but say something like "according to usual XML document
rules" or something?)

In §4, would it be prudent to say that a consumer of the LGR that
encounters either indistinct cp elements or ranges overlapping a cp
should simply reject the whole LGR?  Or what should they do?  That is,
does an error invalidate the document or just cause the element to be
ignored?  (I guess this is a general question.)

In §4.3.2: if you don't use the pre-defined dispositions, what bad
thing happens?  That is, why is this SHOULD?  (I guess I'm asking
whether this is 2119 SHOULD or whether it's just a pretty good idea.)

§4.3.5 has a STRONGLY RECOMMENDED, which is really just advice (and
anyway isn't a 2119 keyword).  I think the reasoning is clear. 

In § 5.2, it's a little strange that the text goes out of its way to
talk about not using the term "set", and then goes on to use the same
word freely.  I'd stick to "character class" for the reasons given.

§6.3 uses that pretty-good-idea meaning of RECOMMENDED again.  Why is
it recommended?  What bad thing happens if not?  In the description of
blocked, there's something wrong with the text such that I can't
understand it: "variant that has is undesirable as" I think the "has"
is just superfluous?  Also, in all of this, why "should"?  Isn't this
mostly "may"?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Asmus Freytag <[email-masked]>
Date: Thu, 18 Feb 2016 21:36:19 -0800

> think the document could go ahead without any of these changes if you

I've created a version that attempts to address most of these and pushed 
it up to
the github pending review.

github 
<https://github.com/kjd/lgr-specification/commit/1c9c778daad8ada2633a23b4be7544fbc114ef8e#diff-56ffc55ca239ffb55eae1b8613342a46>

This version also fixes the example noted in 
https://trac.tools.ietf.org/wg/lager/trac/ticket/35
(but I have not done anything about the schema)

I've added this set of comments as ticket 36

> shepherd checklist thing anyway.)
I put a citation in to the normative references, but haven't referenced 
it from the text.
If we want it we can add thatÂ  - where?, if not, it's easy to take out.
> Â§3.2: to follow the 2119 convention more closely, this could say
>

I think your wording is fine. I also checked the language for cases 
where optional->OPTIONAL makes sense and made a few may->MAY and cannot 
-> MUST NOT where appropriate (e.g. description of when attributes 
cannot occur).

I have generally aimed at using the rfc2119 language only where an 
attribute is defined (or its use for an element is described in detail, 
not for first mention in an earlier context).

> Â§3.3

The intent was that a valid unicode-version becomes mandatory if and 
when a construct

Â Â Â  Â Â Â  < class property="ppp:vvvv" />

is encountered. In that case, the spec intends that the consumer MUST 
NOT evaluate this construct, unless it can support the given version of 
the Unicode Standard.

I believe the existing language adequately expresses that; perhaps you 
could suggest more specific improvements to the wording. (There's that 
word again ;) ).

We did not want to require a Unicode version in cases where an LGR just 
lists code points(*), and we also didn't want to force processes that do 
not need to run the whole label evaluation rules to reject the XML, just 
because, for example, they don't support Unicode property access or the 
correct version. (For example, I can write an LGR-merge processor or 
LGR-diff engine that would need to process the file, but does not 
evaluate such property-based classes).

(*) for that case, if one wanted to know which Unicode version is 
minimally required one could compute that based on the "DerivedAge" 
property (highest value for any code point encountered is the minimally 
required version of Unicode). So the version is not needed for static 
lists of code points.

> the possibile consequences for interoperation if that fails?

Perhaps this simple note in the <metadata> section addresses the issue:

Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  <t>While neither a version nor a 
date element are required, their
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  omission makes it harder for 
interoperating consumers to ensure that
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  they are using the correct LGR. 
Their inclusion RECOMMENDED.</t>

> Â§3.3.3 uses "specific" a lot, and I don't understand what distinction
> scriptâ¦" Is this to distinguish LGRs that apply to generic scripts?
Point well taken. In some cases the word is used where "some" or "a 
given" is intended.
I've made those changes.

I propose to resolve two specific instances of "specific" in this 
specific way:

    Each optional "language" element identifies a language or script for
    which the LGR is intended... The tag may refer to a script plus
    undefined language if the LGR is not intended for a specific language.

The original language had "associated with" and "referring to" as the 
verbs, but I believe "intended for" is what we intended to get across. 
"Applies to" also works, so I kept that in the following sentence where 
I moved the "specific" from "script" to "language"

        If the LGR applies to a script, rather than a specific language..

> Â§3.3.4, "MUST be a valid absolute domain name, without a trailing

I think we would want to discuss this a bit further.
> (Might be ok, but say something like "according to usual XML document

Not sure about the best language, so no change.
> In Â§4, would it be prudent to say that a consumer of the LGR that
It's a bit of a general question. Some constraints are in the schema and 
make the document invalid on that level, but others are not, yet are 
definite error conditions where the document should be rejected (rather 
than an element ignored). I've identified four places where one could 
make that statement without having to repeat it at every level, but also 
close enough to the definitions as to not be totally generic.

I think this addition would be useful (at the end of Â§4):

        An LGR that defines the same code point more than once by any
        combination of "char" or "range" elements MUST be rejected.

And at the end of Â§4.3.1 (on variants being unique)

    Â Â Â Â Â Â Â Â  ....attributes, otherwise the document MUST be
    rejected.

And at the end of Â§5.1

        An LGR containing incorrectly defined or nested rules or match
        operators, or rules and match operators with invalid attributes
        or invalid or undefined attribute values MUST be rejected. Note
        that not all of the constraints defined here are validated by
        the schema.

And finally in Â§6.1, a change to the second paragraph:

        An action MUST NOT contain both a "match" and a "not-match"
        attribute, and the value of either attribute MUST be the name of
        a previously defined rule, otherwise the document MUST be
        rejected. AnÂ  action without any attributes is triggered by all
        labels unconditionally.

Incidentally, there's no such restriction on the contents of the other 
attributes and for the variant triggers I now note that explicitly. (We 
want to allow actions that are "no-ops" unless specific types of 
variants occur in the LGR, so that we can write default actions. 
However, for rules, we want to be able to make sure that the processor 
can locate a rule, so those are mandatorily defined - all of this is not 
new, just more explicit thanks to your comment.

> In Â§4.3.2: if you don't use the pre-defined dispositions, what bad

The intent is to really discourage people from using novel names for 
standard
dispositions. (Makes the whole thing more interoperable).
> Â§4.3.5 has a STRONGLY RECOMMENDED, which is really just advice (and

Actually, I would go so far and suggest that parsers MAY reject 
documents that they can't verify are symmetric and transitive, so I 
could see using lower case for strongly, but I think this is 
"RECOMMENDED" in the sense that it's something you should think twice 
before doing it differently.

For now, have changed STRONGLY --> strongly

The main reason it's not a MUST is that we don't want to burden parsers 
to actually have to verify this. However, for those parsers that do 
check for symmetry and transitivity, we could formally allow them to 
reject poorly specified contexts on variants). This would be a change 
not in the wording but the content of the spec.
> In Â§ 5.2, it's a little strange that the text goes out of its way to

We are not avoiding the term "set" as much as "character set". I just 
went through section 4 searching for "set" and the most common mention 
is in the context "set combination", referring to the mathematical 
operations on sets. I see no issue with those.

In 4.3.5 the bullets uses set twice by itself and I've chanted that to 
class.
> Â§6.3 uses that pretty-good-idea meaning of RECOMMENDED again.  Why is
> it recommended?  What bad thing happens if not?

If simple / standard LGRs all define custom dispositions it becomes 
difficult to compare them. Yet some non-simple/non-standard ones cannot 
be restricted a-prirori (not without loss of desirable generality).

I believe the "think twice" rule applies here, but it's aimed at a 
higher level of interoperability than just whether a parser can 
successfully parse the LGR on its own.

>   In the description of
fixe.

---

From: Yoshiro YONEYA <[email-masked]>
Date: Fri, 19 Feb 2016 22:49:50 +0900 (JST)

Dear all,

I reviewed the I-D.  It seems well described.
Followings are my minor comments.

Section 3.3.4.

The sentence 'Such application-defined type values must be in a 
namespace "apptype" previously defined in the document.' is 
somewhat ambigous to me.  The term "apptype" is only used here, 
and no explanations.  The term "the document" seems LGR definition 
but it can be read as this I-D.

Section 4.2.

The sentence 'To specify a conditional context a "when" or "not-when" 
attribute may be used.', I'd like to add "either" after "content".

Section 6.3.

The sentence 'allocatable  The resulting string should be reserved 
for use by the same operator of the origin string, but not automatically
allocated for use.' should be 'allocatable  The resulting string should 
be reserved for use by the same operator of the origin string, but not 
automatically activated for use.'.

I don't see clear distinction between "activated" and "valid".

Section Appendix A.

In the last rule '<action disp="consonants"' should be 
'<action disp="allocatable"'.

Regards,

-- 
Yoshiro YONEYA <[email-masked]>

On Mon, 8 Feb 2016 18:35:55 +0000 "Hollenbeck, Scott" <[email-masked]> wrote:

> Https://datatracker.ietf.org/doc/draft-ietf-lager-specification/
> 
> Thank you,
> Scott and Marc
>

---

From: Asmus Freytag <[email-masked]>
Date: Fri, 19 Feb 2016 07:55:07 -0800

> (Might be ok, but say something like "according to usual XML document

I think we should write

'Such application-defined type values must be in a
namespace "apptype", which, if used, must have been previously
defined according to the usual XML document rules.'

A./

---

From: Asmus Freytag <[email-masked]>
Date: Fri, 19 Feb 2016 08:16:17 -0800

> I don't see clear distinction between "activated" and "valid".

I don't know what the difference is between "allocated" and "activated", 
so I don't know how to resolve this.

Those seem very specific to the domain name registration process. Which 
is the point in using a generic disposition "valid" for the default 
action (catch all). Remember, type="domain" is, in principle, just one 
of the use cases, so it makes sense to default to "valid" for labels for 
which no other actions have been defined, including labels with variants 
that have no type attribute (also something that, strictly speaking, 
isn't useful for domain name LGRs).

If you want all valid labels to be activated:

<action disp="activated" />

as the last action will override the default, but the default implicit 
action should be useful in the most generic application.

A./

---

From: Asmus Freytag <[email-masked]>
Date: Fri, 19 Feb 2016 17:30:14 -0800

> attribute may be used.', I'd like to add "either" after "content".
Sure.
> '<action disp="allocatable"'.
I thought the intent was to show the ability to create your own 
dispositions.
Admittedly, the disposition doesn't make any "sense", nor does much of the
rest of the sample.

However, the example is now similar to a restriction that we find in some
South East Asian scripts, where there is a limit on the number of
consonants. Perhaps we simply should change this to "invalid" to be more
"typical".

(There's also a spacing issue before "<difference>" a few lines above.

A./

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 22 Feb 2016 11:53:58 +0000

The WG last call for draft-ietf-lager-specification ended on Friday 19 February. Thanks for all of your comments.

A few new issues were identified, but I didn't see anything that would require another WG last call. Once the authors address those comments we can ask our AD to review the document and bring it to the IESG for their and IETF-wide review.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 29 Feb 2016 14:00:19 +0000

Authors, do you have a plan for addressing the WG last call comments? When can we expect a document update?

Scott