Subject: [Lager] Remaining Work Items

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 4 Jan 2016 13:48:27 +0000

Happy New Year!

Folks, we're currently behind schedule in terms of completing the work items specified in our charter:

https://datatracker.ietf.org/wg/lager/charter/

We have three issues open in the datatracker:

https://trac.tools.ietf.org/wg/lager/trac/report/1

These all look to be relatively simple to address, so let's get them done ASAP. Document authors, is there anything holding you up?

Scott

---

From: Kim Davies <[email-masked]>
Date: Mon, 4 Jan 2016 22:29:06 +0000

Hi Scott, Hi all,

> These all look to be relatively simple to address, so let's get them done ASAP. Document authors, is there anything holding you up?

For ticket 21, the only outstanding issue is who should be the Change Controller in section 10.1, which is the media type registration form. One interpretation of RFC 7303 could be that it should be the World Wide Web Consortium as that stakes out their responsibility given it has a “+xml” suffix. Specifically, section 4.2 reads that when using the suffix, “… the change controller has been changed to be the World Wide Web Consortium (W3C)”. An alternative conclusion would be the change controller should be the IESG given this is a Standards Track document. The latter seems more logical to me given the W3C has had no role in this specification, but I am not sure what the purpose of the language in RFC 7303 is intending to serve. Hopefully there is someone we can consult with to seek clarification on this item, but that is the issue at hand.

For ticket 29, Asmus has proposed changing some references to the Unicode specification to remove multiple different ways Unicode properties could be expressed, to have a single canonical long- and short-form way of representing them. I think this is a good idea and Wil seems to have concurred. It needs some new text to be put in the next edition.

For ticket 30, Asmus posted about this to the list just prior to the holiday break. I am not sure I’ve wrapped my head around the pros and cons of adding “valid” as an additional core disposition. I think it would be good to have some discussion about this on the list before making a call on it.

I think that’s it. With some additional feedback and a little work hopefully we can turn around a new draft with no known issues in the coming days.

kim

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 5 Jan 2016 10:44:32 +0900

Hello Kim, others,

Some comments from somebody who has extensively commented on drafts of 
RFC 7303 and its predecessor(s?) and has at one time been responsible 
for media registrations at W3C and W3C-IETF liaison.

On 2016/01/05 07:29, Kim Davies wrote:
> For ticket 21, the only outstanding issue is
who should be the Change Controller in section 10.1,
which is the media type registration form.
One interpretation of RFC 7303 could be that it should be
the World Wide Web Consortium as that stakes out their
responsibility given it has a “+xml” suffix.
Specifically, section 4.2 reads that when using the suffix,
“… the change controller has been changed to be
the World Wide Web Consortium (W3C)”.

This is an interesting misunderstanding. The last sentence of section 
4.2, currently reading
    In addition to the changes described above, the change controller has
    been changed to be the World Wide Web Consortium (W3C).

in more detail would read
    In addition to the changes described above, the change controller for
    the '+xml' Structured Syntax Suffix has been changed to be the World
    Wide Web Consortium (W3C).

I have submited an erratum on this.
(see https://www.rfc-editor.org/errata_search.php?eid=4578)

An alternative conclusion would be the change controller
should be the IESG given this is a Standards Track document.
The latter seems more logical to me given the W3C has had
no role in this specification, but I am not sure what the
purpose of the language in RFC 7303 is intending to serve.

Definitely more logical and the right thing to do.

Hopefully there is someone we can consult with to seek
clarification on this item, but that is the issue at hand.

I hope you are satisfied with my explanations.

Regards,   Martin.

---

From: Asmus Freytag <[email-masked]>
Date: Mon, 4 Jan 2016 20:07:18 -0800

> For ticket 21, the only outstanding issue is who should be the Change Controller in section 10.1, which is the media type registration form. One interpretation of RFC 7303 could be that it should b…

Seems logical. But I'm no expert on RFC7303
> For ticket 29, Asmus has proposed changing some references to the Unicode specification to remove multiple different ways Unicode properties could be expressed, to have a single canonical long- and…

I will be able to put new text together (relatively) shortly. Let's say 
a week?
> For ticket 30, Asmus posted about this to the list just prior to the holiday break. I am not sure I’ve wrapped my head around the pros and cons of adding “valid” as an additional core disposition.…

Yeah, I'd like to see some discussion as well. Also, Kim, if you have 
actual questions, I'd like to answer those as well.
> I think that’s it. With some additional feedback and a little work hopefully we can turn around a new draft with no known issues in the coming days.

I do have another issue. This one may or may not result in any changes 
in the spec, but I'd need some clarification on a question to know.

Question:

Specifically for scope="domain". Do people see the function of the LGR 
as describing all delegated plus the space of all (possible) future 
labels, or only the space of all future possible labels?

Inevitably, there will be, somewhere, some change to an LGR that's not 
fully backwards compatible. This may not be something as crude as 
restricting the available repertoire, but could be as subtle as a change 
in the definition of variants that suddenly would result in two 
delegated labels being in "collision" under the LGR. (Hypothetical 
scenarios that would motivate such changes are near infinite, from the 
need to support new code points, new languages, a spelling reform... so 
let's just take it as given that sometime, somewhere this proves 
inescapable).

If an LGR only applies to labels being applied for, then this is never 
an issue. The LGR is fine, the registry would contain the 
"grandfathered" delegations and nothing else needs to be done.

If, however, there's an implied required for an  LGR to always describe 
the total future namespace as well as any exceptions, then we would need 
to be sure to have a mechanism to capture such exceptions right in the 
definition of the LGR.

For labels affected by a subset in the change in variants definition 
that causes them to collide under the updated LGR, there is a simple way 
to use WLE rules to explicitly declare exceptional labels as "valid" 
even before evaluating their variant mappings under the LGR. It's not 
even super inefficient in the XML, just a rule that matches a <choice> 
among all literal strings. That would bypass the collision.

However, it's not a general enough mechanism, so, for example, it would 
not cover a scenario where an LGR has fewer code points than needed to 
cover existing labels. (This could happen, theoretically, in the root, 
as labels were delegated before adoption of an LGR with express promise 
that the LGR would not be bound by them as precedent).

Hence my question. Is there a need to cover grandfathered labels?

A./

PS: for any scope where no "registry" exists, clearly an LGR would have 
to always encompass all labels, but for "domain" we don't have that 
limitation, because there's always a way to know the actual delegation 
status of a label.

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 5 Jan 2016 12:42:10 +0000

From: Lager [mailto:[email-masked]] On Behalf Of Asmus Freytag
Sent: Monday, January 04, 2016 11:07 PM
To: [email-masked]
Subject: Re: [Lager] Remaining Work Items + 1 new question

Hi Scott, Hi all,

[SAH] My take: we should use “IESG” for an IETF standards track document.

Section 4.2 of RFC 7303 notes that “The registration process for specific '+xml' media types is described in [RFC6838].  New XML-based media type registrations in the IETF must follow these guidelines”. Section 4.7 of 6838 says “There are a number of additional requirements specific to the registration of XML media types.  These requirements are specified in [RFC3023]”. Unfortunately, 3023 was obsoleted by 7303, and we have a circular set of references and we’re back to 7303.

I don’t quite understand what “In addition to the changes described above, the change controller has been changed to be the World Wide Web Consortium (W3C)” applies to. If it applies to the last few sentences of the previous paragraph, it’s talking about non-IETF registrations. So let’s assume that it applies to non-IETF registrations and let’s look at the registry for some recent “+xml” examples:

atomcat+xml (RFC 5023): IESG
atomdeleted+xml (RFC 6721): IESG
auth-policy+xml (RFC 4745): IESG
application/load-control+xml (RFC 7200): IESG
rfc+xml (RFC TBD): RFC Editor (this is post-7303 with a non-W3C change controller)
xml-patch+xml (RFC 7351): IETF (this is post-7303 with a non-W3C change controller)

I think we have a consistent pattern. Use “IESG”.

Scott

---

From: Asmus Freytag <[email-masked]>
Date: Tue, 5 Jan 2016 07:11:14 -0800

> For ticket 29, Asmus has proposed changing some references to the Unicode specification to remove multiple different ways Unicode properties could be expressed, to have a single canonical long- and…

Text pushed to git-hub. As far as I am concerned, this is done, except 
for review by Kim and others.

> For ticket 30, Asmus posted about this to the list just prior to the holiday break. I am not sure I’ve wrapped my head around the pros and cons of adding “valid” as an additional core disposition.…

I still believe this needs to be done, but I am waiting on discussion on 
the list.

A./