Subject: Re: [Ltru] Can a WG member update <http://trac.tools.ietf.org/wg/ltru/> ?

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 1 Jun 2009 22:56:16 -0700

Hi -

> From: "Martin J. Dürst" <[email-masked]>
> To: "Stephane Bortzmeyer" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Friday, May 29, 2009 1:59 AM
> Subject: Re: [Ltru] Can a WG member update <http://trac.tools.ietf.org/wg/ltru/> ? (Was: Issue #49: Add reference to RFC 5198
(Apps #2)
>
> I guess Randy should be able to answer this question, but he's away.
> I haven't been able to get a grip on this tracker myself, so for me, the
> question is more "can anybody except Randy handle this" rather than "can
> ordinary WG members update issues". But that may simply be a bilateral
> problem between me and this tracker.

You can, but only if you can log in (using the hard-to-see "login" link
near the upper right corner of the trouble ticket pages) and if your
account has been granted persmission to add/modify entries.

I think only Martin and I are supposed to have been given
those permissions for the ltru database.

Randy

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 06 Jun 2009 21:14:57 +0100

Alexey Melnikov wrote:

> This is the first batch. I received a fairly long list of comments and 
> still deciding what to do with the rest.

Sorry for the delay. This is the second batch. There would also be a
third (and the last) batch, with about 6 issues.

8). Section 1 currently says:

   This document replaces [RFC4646], which replaced [RFC3066] and its
   predecessor [RFC1766].  For a list of changes in this document, see
   Section 8.

RFC 4646 used to say:

   This document, in combination with [RFC4647], replaces [RFC3066],
   which replaced  [RFC1766].  For a list of changes in this document,
   see Section 8.

I think it would be more correct for 4646bis to say:

   This document replaces [RFC4646]. This document, in combination
   with [RFC4647] replaces [RFC3066] and its predecessor [RFC1766].
   For a list of changes in this document, see Section 8.

9). Several elements of the syntax in Section 2.1 are not complete
because there are extensive discussions elsewhere in the document that
describe the actual, and considerably restrictive, rules for valid
elements.  The relevant productions would be much more useful to the
reader if they cross-referenced the defining sections (e.g. in ABNF
comments).  Specific and important examples are that the "extlang"
production should point to Section 2.2.2 and the "irregular" and
"regular" ones should explicitly indicate that the preferred forms are
found in the registry in the "Preferred-value" entry for the relevant tag.

10). In Section 2.2

>    o  "Subtag" refers to a specific section of a tag, delimited by
>       hyphen, such as the subtags 'zh', 'Hant', and 'CN' in the tag "zh-
>       Hant-CN".  Examples of subtags in this document are enclosed in
>       single quotes ('Hant').
>
>    o  "Code" refers to values defined in external standards (and which
>       are used as subtags in this document).  For example, 'Hant' is an
>       [ISO15924] script code that was used to define the 'Hant' script
>       subtag for use in a language tag.  Examples of codes in this
>       document are enclosed in single quotes ('en', 'Hant').

These definitions make it sound that "code" and "subtag" are separate
categories. But "code" is a subset of "subtag".
Is there a need to have both "codes" and "subtags" in this document?

11). Paragraph 3 of Section 2.2 asserts that "...identification of the
subtag's type [is] possible, even if the content of the subtag itself is
unrecognized".

Without a table summarizing the rules a reader needs to infer them from
ABNF in Section 2.1 and possibly by reading the rest of the document. A
compact text or table summarizing the rules would improve the document.

12). In Section 2.2.1:

>    5.  Any language subtags of 5 to 8 characters in length in the IANA
>        registry were defined via the registration process in Section 3.5
>        and MAY be used to form the primary language subtag. An example
>        of what such a registration might include: one of the
>        grandfathered IANA registrations is "i-enochian".  The subtag
>        'enochian' could be registered in the IANA registry as a primary
>        language subtag (assuming that ISO 639 does not register this
>        language first), making tags such as "enochian-AQ" and "enochian-
>        Latn" valid.
>
>        At the time this document was created, there were no examples of
>        this kind of subtag and future registrations of this type are
>        discouraged: primary languages are strongly RECOMMENDED for
>        registration with ISO 639,

I suggest that the RECOMMENDED is changed to a MUST, i.e. an attempt to
register it with ISO 639 must be made. Even if the outcome might be
known, arguments given by ISO 639 might provide useful input to the
Language Subtag Expert.

>       and proposals rejected by ISO 639/ RA-
>        JAC will be closely scrutinized by the Language Subtag Reviewer
>        before they are registered with IANA.

This might be a big deal, so this might actually require wider review,
such as IETF LC.

13). In Section 3.5:

>    While the 'Description' field itself is not guaranteed to be stable
>    and errata corrections MAY be undertaken from time to time, attempts
>    to provide translations or transcriptions of entries in the registry
>    itself will probably be frowned upon by the community or rejected
>    outright, as changes of this nature have an impact on the provisions
>    in Section 3.4.

Suggested replacement for the paragraph:

   The 'Description' field itself is not guaranteed to be
   stable.  Corrections (possibly as errata) and updates are
   permitted with adequate justification.   However, addition
   of translations or transliterations are not considered
   sufficient justification for corrections or updates.

Reason: use of MAY is not an appropriate use of RFC 2119, as it is
trying to forecast the future and doesn't specify a protocol option.

---

From: Kent Karlsson <[email-masked]>
Date: Sun, 07 Jun 2009 00:16:23 +0200

>    For a list of changes in this document, see Section 8.

That would be a very minor point. The important point is that 4646bis
becomes BCP 47 (together with RFC 4647).

I suggest no change to that paragraph.

> found in the registry in the "Preferred-value" entry for the relevant tag.

I think the table of contents does sufficiently good job of that.
In addition, not all of "irregular"&"regular" have a preferred-values.

I suggest no change.

> Is there a need to have both "codes" and "subtags" in this document?

"Code" is what these items are called in the respective source standards.
They are not "subtags" in the source standards.

I suggest no change.

> compact text or table summarizing the rules would improve the document.

Perhaps. But anyone finding that text would also be able to figure it out
from the current text. And it would also cause more delay in adopting the
document.

I suggest no change.

> known, arguments given by ISO 639 might provide useful input to the

I think the current wording is sufficient. It makes no practical difference
to change to a "MUST".

I suggest no change.

> This might be a big deal, so this might actually require wider review,

What is a big deal? Why would an IETF LC be appropriate for this?

I suggest no change.

> trying to forecast the future and doesn't specify a protocol option.

"MAY" (and the other magic words) are used in this way all over the place
in this document. There is no protocol specified (though protocols may
*use* language tags as specified in the document). All the "MAY"s and
"MUST"s in 4646bis apply to the registry maintenance process and to what can
and cannot be done to the data items in the registry. That includes this
"MAY". That paragraph could be wordsmithed differently (takes time...), but
the "Description" fields still "MAY be changed" (by the regular maintenance
process).

I suggest no change.

    /kent k

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 07 Jun 2009 09:50:29 +0100

>Den 2009-06-06 22.14, skrev "Alexey Melnikov" <[email-masked]>:
 [...]

>They are not "subtags" in the source standards.
Ok with me.

>from the current text.
Are you sure?

>And it would also cause more delay in adopting the document.
>  
>
Lack of such table might cause delay in adopting this document by 
protocol developers.

>I think the current wording is sufficient. It makes no practical difference
If the document uses RECOMMENDED, where it is using MUST for other 
similar cases, then it needs to explain why there might be an exception 
here.
Just change this to MUST and be done with this issue.

>What is a big deal? Why would an IETF LC be appropriate for this?
To alert IAB and other interested parties about the situation.

---

From: Peter Constable <[email-masked]>
Date: Mon, 8 Jun 2009 12:19:53 -0700

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Karlsson

> "Code" is what these items are called in the respective source standards.

I'll start off by saying I'm have no qualms with the use of "code" in 4646bis at present. 

That said, Kent's claim is not generally true. While it's clear that there is common usage of "code" to refer to individual coding identifiers, in ISO coding standards "code" is usually formally defined as the complete coding system. The use of plural in the title of ISO 639 does was not a reflection of there being multiple identifiers / coded entities, but that there is more than one scheme. (The authors of 639-2 were a little bit imprecise in defining terms, so at times it may seem like "code" is used to mean an individual ID. Unfortunately, ISO 15924 used 639-2 as a model and went the wrong way, becoming the exception to the norm.)

For instance, here are definitions from various standards (I find the wording from 2382-4 makes this clearest):

ISO 639: 1988
language code: A set of symbols used to designate languages.

ISO 639-2:1998
code: data representation in different forms according to a pre-established set of rules
language code: combination of characters used to represent a language or languages

ISO 2382-4:1999
code / coding scheme: a collection of rules that maps the elements of a first set onto the elements of a second set
code value / code element / code (deprecated in this sense): the result of applying a code to an element of a coded set

ISO 3166-3:1999 (same definitions as ISO 3166-1:1997)
code: data transformation or data representation in different forms according to pre-established rules [Adapted from ISO 5127-1:1983, 1.1.4-06]
code element: result of applying a code to an element in a set of elements to be coded
country code: listing of country names with their representations by code elements

ISO 639-1:2002
code: data transformed or represented in different forms according to a pre-established set of rules
code element: individual entry in a code

ISO 639-3:2007
code: data transformed or represented in different forms according to a pre-established set of rules
code element: individual entry in a code table

ISO 3166-1:2005
code: set of data transformed or represented in different forms according to a pre-established set of rules [ISO 5127:2001, 1.1.4-07]
code element: the result of applying a code to an element of a coded set [ISO/IEC 2382-4:1999, 04.02.04] NOTE 2 In this part of ISO 3166 a code element represents a country name.
country code: listing of country names with their representations by code elements

Peter

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 8 Jun 2009 12:29:23 -0700

> I'll start off by saying I'm have no qualms with the use of "code"

I'll point out that we define the word 'code' in 4646bis (and 4646, for that matter) strictly as internal terminology. We did so to distinguish items from the underlying standards from items in the registry in the many places in the document where 'codes' from a standard are discussed in relation to 'subtags' in the registry. It's an important distinction and one that should be preserved. In fact, I'm slightly incredulous about the comment.

Addison

---

From: John Cowan <[email-masked]>
Date: Mon, 8 Jun 2009 15:35:29 -0400

> I'll start off by saying I'm have no qualms with the use of "code"

[details snipped]

During the WG discussion of 4646, I proposed changing "code" to "code
element" for conformity with ISO 639 and ISO 3166; however, that proposal
failed to gain consensus.

-- 
Even a refrigerator can conform to the XML      John Cowan
Infoset, as long as it has a door sticker       [email-masked]
saying "No information items inside".           http://www.ccil.org/~cowan
        --Eve Maler

---

From: Peter Constable <[email-masked]>
Date: Mon, 8 Jun 2009 13:04:13 -0700

With my comment? 

I was merely commenting on Kent's suggestion that our use is derived from ISO standards. Your clarification makes it clear that our use was definitely not derived from ISO standards, and so is not incompatible with my comment.

Peter

-----Original Message-----
From: Phillips, Addison [mailto:[email-masked]] 
Sent: Monday, June 08, 2009 12:29 PM
To: Peter Constable; Kent Karlsson; LTRU Working Group
Subject: RE: On "code" in ISO standards

> In fact, I'm slightly incredulous about the comment.

Addison

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 8 Jun 2009 13:05:08 -0700

> With my comment?

No, with the original comment.

Addison

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 08 Jun 2009 23:09:48 +0100

Alexey Melnikov wrote:

> Alexey Melnikov wrote:
>
>> This is the first batch. I received a fairly long list of comments 
>> and still deciding what to do with the rest.
>

Actually the last batch is down to 1 issue, but it is more serious.

14). Language Tag validity verification requires applications to keep 
up-to-date copies of the Language Tag registry. Such applications might 
be designed to automatically fetch new versions of the registry. This 
has three problems:
I). IANA is generally not happy about applications automatically 
downloading registries, unless data is located in DNS. This is primarily 
to scaling concerns.
II). There is also the issue of when application should be fetching the 
updated registry. I.e. what is the mechanism(s) for determining when to 
fetch.
III). The registry format is not designed for figuring out the minimal 
list of changes between any 2 versions. For example there is no way of 
only fetching changes since a given File-Date value.

BTW, are people aware of implementations that try to download Language 
Tag registry automatically?

While I don't expect this issue to be fully fixed at such a late stage, 
it needs to be discussed in the document. Some thoughts about what can 
be said on the topic:

Regarding I): application should be advised against frequent polling of 
the registry. For example:

  The registries specified in this document are not
  suitable for applications that require real-time access
  to, or retrieval, of the full registry contents.

It might be nice to have the File-Date value available as a separate 
short piece of data (a separate web page on IANA's website, a thing in 
DNS, etc.
But even with existing registry format it might be possible to minimize 
load on IANA's website by describing how HTTP/1.1 features can be used 
to only download necessary information, such as downloading the 
beginning of the registry which contains the File-Date field.

Regarding II): I think this needs some advice on which operations need 
and which don't need fetching of the registry.

Also this might mention that any application keeping a copy of the 
registry needs to preserve the File-Date value in some form.

Regarding III): I think it is Ok for now to explicitly acknowledge that 
this is an issue.

It might also be worth discussing how the registry format facilitates 
"diffing" 2 versions of the registry.

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 8 Jun 2009 15:53:39 -0700

I think this is a potentially serious problem, although we did address it during document development (of RFC 4646). Some of the changes in this document have watered down the way we addressed it in that document. There is also a general recognition that mechanically retrieving the registry is a Bad Thing.

> 
> 14). Language Tag validity verification requires applications to
> keep up-to-date copies of the Language Tag registry. 

Actually, this is false. The validity text is careful to say "as of the particular registry date" when referring to validity. There is an expectation that most implementation will use a specific registry version.

> Such applications might be designed to automatically fetch new versions of the registry.
> This has three problems:
> downloading registries, unless data is located in DNS. This is
> primarily to scaling concerns.

Obviously this would be a concern. In fact, Section 6 (Security Considerations) says:

--
Although the specification of valid subtags for an extension (see Section 3.7 (Extensions and the Extensions Registry)) MUST be available over the Internet, implementations SHOULD NOT mechanically depend on it being always accessible, to prevent denial-of-service attacks.
--

This should also address the IANA registry. I think that's an oversight. I actually thought it said both.

> updated registry. I.e. what is the mechanism(s) for determining
> when to fetch.

Usually: when you make a new or updated version of your software. Infrequent polling of the registry itself would also not be harmful. Neither would monitoring the list of registration forms (which IANA archives separately).

However, there is also a specific mechanism in Section 5.1 for knowing when a change is made:

--
Developers who are dependent upon the language subtag registry sometimes would like to be informed of changes in the registry so that they can update their implementations. When any change is made to the language subtag registry, IANA will send an announcement message to "[email-masked]" (a self-subscribing list that only IANA can post to).
--

> list of changes between any 2 versions. For example there is no way
> of only fetching changes since a given File-Date value.

No, there isn't. The records do not contain a "last modified" date. Is this necessarily important? When I update one of my implementations, I just reparse the latest registry. Stability rules exist to protect my doing it this way. Since the records are not in any particular order, there isn't necessarily utility to using diff to reconstruct changes either.

> 
> 
> BTW, are people aware of implementations that try to download
> Language Tag registry automatically?

Yes, see above.

> it needs to be discussed in the document. Some thoughts about what
> can be said on the topic:
> 
> Regarding I): application should be advised against frequent
> polling of the registry. For example:
> 

There are some notes already in place. It was considered during document development (of 4646). There is no evidence, btw, that implementations do rely on active access and, with the size expansion envisioned with this document, it seems less likely that an implementer would want to create such a linkage.

> beginning of the registry which contains the File-Date field.

One can subscribed to ietf-languages-announcements@. Also one can look at the list of registrations (http://www.iana.org/assignments/lang-subtags-templates/index.html). 

> 
> Regarding II): I think this needs some advice on which operations
> need and which don't need fetching of the registry.

*No* operations depend on fetching the registry at runtime. Only validation and canonicalization depend on a copy of the registry being available. Wording the I-D is always in terms of "as of a particular registry date".

> registry needs to preserve the File-Date value in some form.

It is actually already a requirement of being a validating processor. Section 2.2.9 says:

--
An implementation that claims to be validating MUST:
// ...
# Specify the particular registry date for which the implementation performs validation of subtags.
--

That is the File-Date. Note that the expectation (but not requirement) is that validating implementations are tied to a registry version, not obtaining it mechanically.

> 
> Regarding III): I think it is Ok for now to explicitly acknowledge
> that this is an issue.
> 
> It might also be worth discussing how the registry format
> facilitates "diffing" 2 versions of the registry.

It's possible, although once you've parsed the new registry, the diff doesn't matter so much. Note that stability rules generally prevent breaking changes.

Addison

---

From: John Cowan <[email-masked]>
Date: Mon, 8 Jun 2009 19:13:00 -0400

Alexey Melnikov scripsit:

> While I don't expect this issue [of excessive downloads] to be fully
> fixed at such a late stage,

"Late stage" is right.  This registry has been available for download
since November 2005, the approval date of RFC 4646 (then known as
3066bis).  The issue was raised then and resolved; why should it
be reraised now?  It's true that the 4646bis registry will be much
larger than the 4646 one, but available bandwidth has increased too.
If IANA is concerned about abuse of their resources, let them set up
authorized mirrors, or impose controls on download, or do something
else administrative.

-- 
John Cowan  <[email-masked]>  http://ccil.org/~cowan
Micropayment advocates mistakenly believe that efficient allocation of
resources is the purpose of markets.  Efficiency is a byproduct of market
systems, not their goal.  The reasons markets work are not because users
have embraced efficiency but because markets are the best place to allow
users to maximize their preferences, and very often their preferences are
not for conservation of cheap resources.  --Clay Shirkey

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 18:40:40 -0700

Hi -

> From: "Alexey Melnikov" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Cc: "Martin J. Dürst" <[email-masked]>; "Randy Presuhn" <[email-masked]>
> Sent: Saturday, June 06, 2009 1:14 PM
> Subject: Re: Additional issues with 4646bis raised by an Apps Review Team review
...
>    For a list of changes in this document, see Section 8.

This is now in the tracker as issue #55.
http://trac.tools.ietf.org/wg/ltru/trac/ticket/55

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 18:44:00 -0700

Hi -

...
...

This is now in the tracker as issue #56.
http://trac.tools.ietf.org/wg/ltru/trac/ticket/56

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 18:47:45 -0700

Hi -

...
...

This is now filed as ticket #57.
http://trac.tools.ietf.org/wg/ltru/trac/ticket/57

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 18:50:59 -0700

Hi -

...
...

Added as issue #58.
http://trac.tools.ietf.org/wg/ltru/trac/ticket/58

Randy

---

From: John Cowan <[email-masked]>
Date: Mon, 8 Jun 2009 21:54:13 -0400

> >    For a list of changes in this document, see Section 8.

This change is excessively finicky, but we may as well do it.

-- 
BALIN FUNDINUL          UZBAD KHAZADDUMU        [email-masked]
BALIN SON OF FUNDIN     LORD OF KHAZAD-DUM      http://www.ccil.org/~cowan

---

From: John Cowan <[email-masked]>
Date: Mon, 8 Jun 2009 21:55:41 -0400

> > found in the registry in the "Preferred-value" entry for the relevant tag.

This complaint should have been raised at RFC 4646 last call, and some
parts of it, arguably, at RFC 1766 last call.  It is very-late-stage
extra work and the WG should reject it.

-- 
John Cowan  [email-masked]    http://ccil.org/~cowan
Big as a house, much bigger than a house, it looked to [Sam], a grey-clad
moving hill.  Fear and wonder, maybe, enlarged him in the hobbit's eyes,
but the Mumak of Harad was indeed a beast of vast bulk, and the like of him
does not walk now in Middle-earth; his kin that live still in latter days are
but memories of his girth and his majesty.  --"Of Herbs and Stewed Rabbit"

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 18:56:48 -0700

Hi -

Note well that there are two very distinct issues in Apps #12.
This thread is the first of the two.  PLEASE do not confuse
them in your followups!

> Subject: Re: Additional issues with 4646bis raised by an Apps Review Team review
....
...

This is filed as issue #59 in the tracker.
http://trac.tools.ietf.org/wg/ltru/trac/ticket/59

Randy

---

From: John Cowan <[email-masked]>
Date: Mon, 8 Jun 2009 21:56:42 -0400

> > compact text or table summarizing the rules would improve the document.

The intention of RFCs, especially a complex one like this, is not to make
the document "accessible" to those who cannot be bothered to read it.
This is extra unnecessary work, and the WG should refuse it.

-- 
John Cowan   [email-masked]   http://ccil.org/~cowan
I must confess that I have very little notion of what [s. 4 of the British
Trade Marks Act, 1938] is intended to convey, and particularly the sentence
of 253 words, as I make them, which constitutes sub-section 1.  I doubt if
the entire statute book could be successfully searched for a sentence of
equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 19:00:38 -0700

Hi -

Please note that this is the second half of apps review comment #12.
Please do not confuse it with the first half of that same comment.

...
...

This is issue #60 in the tracker.
http://trac.tools.ietf.org/wg/ltru/trac/ticket/60

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 19:03:23 -0700

Hi -

...
> trying to forecast the future and doesn't specify a protocol option.

This is filed as report #61 in the tracker.
http://trac.tools.ietf.org/wg/ltru/trac/ticket/61

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 19:41:30 -0700

Hi -

...
>    For a list of changes in this document, see Section 8.

As a technical contributor, I have no objection to this proposed change.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 19:50:26 -0700

Hi -

...
> trying to forecast the future and doesn't specify a protocol option.

As a technical contributor...
While I recognized that the proposed text is well-meant, I cannot support
it.  It introduces a technical change to what the WG had agreed.  It
changes advice ("probably frowned upon") into a prohibition ("are not
considered sufficient").

Furthermore, I would argue that the use of MAY is in this case correct -
it's used to describe an optional activity, and those taking part in or
relying on this procedure must account for both the possibility that
the action can occur, and the possibility that it might not occur.

Consequently, I do not agree with making the proposed change.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 20:00:37 -0700

Hi -

...

I think adding this additional material to the ABNF would muddy
the distinctions spelled out in 2.2.9.  Also, all the relevant elaborations
are in the next (i.e. 2.2.*) sub-section, so it's not as though the
reader is left in suspense for any great length of time.  Consequently,
I do not think that it would be helpful to make this change.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 20:21:48 -0700

Hi -

...
...

Yes.

The claim that "code" is a subset of "subtag" is in my opinion incorrect.
The various "source" standards we use define a whole bunch of strings,
which they sometimes refer to as "codes" and sometimes as "code elements".
For sanity, and with no loss of clarity, we refer to those individual strings
as "codes."  The Language Subtag Registry contains information corresponding
to specific subtags.  The strings used to encode them happen to be the
same as the strings used for some codes in those source standards.
Maintaining the distinction is important, particularly in cases where the
source standard (e.g., through re-assignment) can potentially diverge from
the registry's usage of a particular string.

Consequently, I think the document should be left as it is in this regard.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 20:28:17 -0700

Hi -

...

My first preference would be to make no change here, out of concern
that last-minute changes like this tend to introduce errors.

If we MUST make a change, rather that adding more text or a table,
my preference would be to simply delete "These make identification of the subtag's
type possible, even if the content of the subtag itself is unrecognized. "  The rest
of the paragraph still says what needs to be said.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 8 Jun 2009 20:44:24 -0700

> that last-minute changes like this tend to introduce errors.

+1

> of the paragraph still says what needs to be said.

+1

Although, honestly, I think that sentence is useful.

Addison

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 20:46:00 -0700

Hi -

...
...

Requests for new primary language subtags are, particularly if
4645bis is approved, likely to be very infrequent and rather
specialized.  If the corresponding request for a new language
code  were rejected by the ISO 639 folk, then the odds are very good
that we'd be talking about a particularly fuzzy case of language vs.
variety, a particularly dead language or some other case that
will revolve around (1) specialized needs of those who want to
be able to tag material in this language and (2) some linguistic
argumentation about whether this can reasonably be considered
to be a variety of something already registered.  In either case,
I'm *highly* sceptical that much taking it to an IETF last call would
be enlightening or useful.  The people who care about such
things are either already on the [email-masked] list,
or will be recruited to that list by the party seeking the
registration.  To cite a past example, I cannot imagine how
having an IETF last call on Enochian would have been
helpful to anyone.

Consequently, I am strongly opposed to making this change.

Randy

---

From: Mark Davis <[email-masked]>
Date: Mon, 8 Jun 2009 20:47:15 -0700

I agree; I'd rather retain useful sentences...

Mark

On Mon, Jun 8, 2009 at 20:44, Phillips, Addison <[email-masked]> wrote:

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 20:48:51 -0700

Hi -

....
...

As a technical contributor, I can agree with this proposal, as long as the case
of non-response or negative response is covered.

Randy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 12:49:24 +0900

+1

On 2009/06/09 11:41, Randy Presuhn wrote:
> Hi -
>
>> From: "Alexey Melnikov"<[email-masked]>
>> To: "LTRU Working Group"<[email-masked]>
>> Cc: "Martin J. Dürst"<[email-masked]>; "Randy Presuhn"<[email-masked]>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 8 Jun 2009 20:49:59 -0700

> I do not think that it would be helpful to make this change.

I agree. As noted previously, I think it would be counterproductive to make the requested changes. There is utility in the ABNF alone (see well-formed in Section 2.2.9). The "relevant elaborations" have nothing to do with language tag syntax: they are strictly on what items appear in the registry and as recommendations to users as to when certain subtags have utility together. They don't change the structure of tags nor the *potential* range of each subtag type.

Addison

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 12:51:48 +0900

Co-chairs hat off:

The average reader of an IETF document knows that the syntax isn't 
everything. The document has subsections for each of the relevant 
constructs, which are easy to find from the TOC.

So I concur that there is no need to change this.    Regards,   Martin.

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 8 Jun 2009 20:52:24 -0700

> extra work and the WG should reject it.

The only way that the ABNF could be "complete" by this definition would be for it to actually *be* the registry, which is absurd. +1.

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 8 Jun 2009 21:00:45 -0700

IETF LC would be inappropriate as an outcome for a language registration request. There already exists the appeals process, which has never been actually used (threatened, yes, but never used). The process seems to work. Elaborating it seems unnecessary.

It is also the case that a language rejected by ISO 639RA and by the expert subtag reviewer and presumably the ietf-languages@ consensus process and which is an exceptional registration (frowned at by our own preceding text), yet not in a way worthy of appeal on procedural grounds, is probably wholly inappropriate for an IETF LC.

Addison

Addison Phillips

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: Monday, June 08, 2009 7:01 PM
> To: LTRU Working Group
> Subject: [Ltru] Issue #60: Require IETF Last Call for 2.2.1 (5)
> primary subtag case (Apps #12-b)
> 
> Hi -
>

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 8 Jun 2009 21:12:49 -0700

I would prefer that we not replace a recommendation with normative "MUST". If we must make a change, it should favor informative language. The registration process exists to be used. Advising requesters that ISO 639RA is a more suitable target, at least initially, is fine, but should not pose a restriction on the registration process in cases where a rejection is difficult to obtain.

I would propose instead:

--
At the time this document was created, there were no examples of
this kind of subtag and future registration of this type are
discouraged: primary languages ought to be registered with
ISO 639. Requests which have not been submitted to or which
have been rejected by ISO 639/RA-JAC will be closely 
scrutinized by the Language Subtag Reviewer before they are
registered with IANA.
--

Addison Phillips

> Sent: Monday, June 08, 2009 8:49 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] Issue #59: replace RECOMMENDED language with
> MUST languagein 2.2.1 (Apps #12a)
> 
> Hi -
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 21:58:08 -0700

Hi -

> Sent: Monday, June 08, 2009 3:09 PM
...
> "diffing" 2 versions of the registry.

This has been entered into the tracker as #62.
http://trac.tools.ietf.org/wg/ltru/trac/ticket/62

Randy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 15:11:30 +0900

co-chair hat off:

My strong preference is also to not make any changes here. I also have a 
strong preference for leaving the sentence in question in, as otherwise 
somebody might be missing this feature of language tags completely, 
which would be a pity.

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 15:24:02 +0900

co-chair hat off:

I fully agree with Randy. Bothering the IETF list with a last call on a 
single entry in a registry, for what will be a very marginal case, is 
going to upset more than it's going to help.

Regards,   Martin.

---

From: Peter Constable <[email-masked]>
Date: Mon, 8 Jun 2009 23:45:14 -0700

I agree on preferring no change: in addition to the reasons Randy gives, I note that this statement comes in the introduction to a detailed discussion on all of the various types of subtags, and that discussion, with reference to the ABNF, will allow the reader to understand how this statement is true.

If a change _must_ be made, I would not delete the sentence that Randy suggests: that sentence makes an observation in relation to an important design goal for 3066bis: that the syntax allow parsers to clearly recognize subtags of different types without reference to the registry. Rather, I would make a change replacing the third paragraph with the following (or something along these lines:

<suggested text>
The syntax of language tags has been designed to allow the type of information conveyed by each subtag to be recognizable even if the specific meaning of the subtags is not known. Apart from grandfathered tags (a limited enumeration), singletons, and private-use and extension subtags (which can be recognized by the preceding singletons), all subtags are of one of five types: primary language subtags, extended language subtags, script subtags, region subtags, or variant subtags. The syntax of language tags assigns distinct positions or length restrictions to each type of subtag. For example, a 4ALPHA subtag that is not the first subtag, does not follow a singleton and is not part of grandfathered subtag must always be a script subtag.

(The subsections that follow describe the various types of subtag. See these sections and also the ABNF in Section 2.1 for precise syntactic details that allow each type of subtag to be recognizable.)

This feature of the syntax allow tags to be parsed and processed without reference to the latest version of the underlying standards or the IANA registry and makes the associated exception handling when parsing tags simpler.
</suggested text>

Note: this issue is editorial in nature, not technical. I would be open to no change or any other suggested revision that is limited to changes of an editorial-only nature. Again, my first choice is for no change at this time.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn
Sent: Monday, June 08, 2009 8:28 PM
To: LTRU Working Group
Subject: Re: [Ltru] Issue #58: Add a summary of rules for recognizing subtagtype (Apps #11)

Hi -

...

Randy

---

From: Peter Constable <[email-masked]>
Date: Mon, 8 Jun 2009 23:51:58 -0700

Alexey already replied to Kent that he was OK with no change for this issue:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Sunday, June 07, 2009 1:50 AM
To: Kent Karlsson

[snip]

>Ok with me.

I concur with no change on this.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn
Sent: Monday, June 08, 2009 8:22 PM
To: LTRU Working Group
Subject: Re: [Ltru] Issue #57: Code / Subtag distinction (Apps #10)

Hi -

...
...

Yes.

Randy

---

From: Peter Constable <[email-masked]>
Date: Tue, 9 Jun 2009 00:03:22 -0700

I also prefer to see no change. 

If some change _must_ be made, I would make it a minimalist change, such as adding the following single line right after figure 1:

"Details regarding the various elements that make up language tags, including valid sources for subtags, are discussed in Section 2.2."

Again, my first choice is to leave things as they are.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn
Sent: Monday, June 08, 2009 8:01 PM
To: LTRU Working Group
Subject: Re: [Ltru] Issue #56: Section 2.1 syntax is not restrictive enough (Apps #9)

Hi -

...

Randy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 16:10:58 +0900

co-chair and shepherd hat on:

I have found six people who are against changing anything here.
Three of them also were okay with removing the sentence.

I think we have consensus for not changing anything. Randy, can you 
close this issue?

Thanks,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 16:15:18 +0900

co-chair hat off.

I would strongly prefer to leave it as is. From Randy's and Addison's 
messages, it seems that we need to go into wordsmithing details if we 
start to change something, and from the explanations, it doesn't seem 
worth the effort.

Regards,    Martin.

---

From: Peter Constable <[email-masked]>
Date: Tue, 9 Jun 2009 00:17:53 -0700

+1

Even if the text doesn't force this, de facto practice on the IETF-languages list will drive process that way (and that doesn't conflict with any procedural requirements stipulated in this doc).

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of "Martin J. Dürst"
Sent: Monday, June 08, 2009 11:24 PM
To: Randy Presuhn
Cc: LTRU Working Group
Subject: Re: [Ltru] Issue #60: Require IETF Last Call for 2.2.1 (5) primarysubtag case (Apps #12-b)

co-chair hat off:

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 16:20:49 +0900

co-chair hat off: I'm fully with Randy on this. There is no need for a 
change.     Regards,    Martin.

---

From: Peter Constable <[email-masked]>
Date: Tue, 9 Jun 2009 00:21:48 -0700

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of "Martin J. Dürst"
Sent: Tuesday, June 09, 2009 12:15 AM
To: Phillips, Addison
Cc: LTRU Working Group
Subject: Re: [Ltru] Issue #59: replace RECOMMENDED language with MUST languagein 2.2.1 (Apps #12a)

co-chair hat off.

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 16:23:09 +0900

co-chair hat off:

I concur with Randy. There is a subtle but important distinction between 
'code' and 'subtag', even if it can be seen as a distinction of role for 
the same string in many cases. Changing this to different terminology 
would also involve a lot of work all over the document to make sure we 
change things in exactly the right instances.

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 17:35:05 +0900

Hello Addison, others,

> Actually, this is false. The validity text is careful to say "as of the particular registry date" when referring to validity. There is an expectation that most implementation will use a specific re…

I think the problem here is with "there is an expectation". Of course we 
expect people to understand things our way, and to be reasonable. Yet 
still that's not always the case. An example story can be found at 
http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic.
Also, I know that W3C staff at one point was contacted by staff from the 
Unicode consortium about a similar issue.

> Obviously this would be a concern. In fact, Section 6 (Security Considerations) says:

Okay. Here is proposed text for insertion just before the currently last 
paragraph in section 6:

Although the Language Subtag Registry and the Language Tag Extensions 
Registry are available over the Internet, applications SHOULD NOT 
mechanically depend on it being always accessible, to prevent 
denial-of-service attacks.

> However, there is also a specific mechanism in Section 5.1 for knowing when a change is made:

I think this is well and good for the scenarios you are used to, similar 
to shrink-wrapped software. But somebody may think that they want to be 
more up-to-date, and build in some automatic updating mechanism into 
their software.

> There are some notes already in place. It was considered during document development (of 4646). There is no evidence, btw, that implementations do rely on active access and, with the size expansion…

I agree that there is no evidence that a language tag implementation 
currently does frequent downloads. But there is evidence for other cases 
of frequent downloads, where the frequency of changes is way smaller or 
non-existent.

I therefore suggest to continue the text I proposed above as follows:

The registries specified in this document are not suitable for frequent 
or real-time access to, or retrieval, of the full registry contents. 
Most applications do not need registry data at all. For the others, 
being able to validate or canonicalize language tags as of a particular 
registry date will be sufficient. Also, the registry contents changes 
only occasionally. Changes are announced to 
[email-masked]. Changes, or the absence thereof, 
can also easily be detected by looking at the File-Date record at the 
start of the registry, or by using features of the protocol used for 
downloading, without having to download the full registry.

> It is actually already a requirement of being a validating processor. Section 2.2.9 says:

I think what Alex means is that the diff would significantly reduce the 
amount of data that needs to be downloaded to update the registry to a 
new version.

Overall, I agree that we have discussed this issue before, but I also 
understand that Alex is concerned, probably not only by himself, but 
also about the fact that his fellow IESG members might easily bring up 
this issue as a "discuss". So I think it's better to have it clearly 
documented in the security section.

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 17:39:11 +0900

> Alexey already replied to Kent that he was OK with no change for this issue:

Thanks for reminding me, I somehow missed that. I also noted consensus 
moving that way, so I'd like to ask Randy to close this issue with no 
change.

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jun 2009 17:41:36 +0900

I have counted 6 people against some changes on this issue, and nobody 
really for, so I think we have consensus. Randy, can you please close 
this issue appropriately?

Regards,   Martin.

---

From: Peter Constable <[email-masked]>
Date: Tue, 9 Jun 2009 06:52:36 -0700

IETF LC is not needed. We already have an adequate proposal, review and appeal process.

I recommend no change.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn
Sent: Monday, June 08, 2009 7:01 PM
To: LTRU Working Group
Subject: [Ltru] Issue #60: Require IETF Last Call for 2.2.1 (5) primary subtag case (Apps #12-b)

Hi -

...
...

Randy

---

From: Peter Constable <[email-masked]>
Date: Tue, 9 Jun 2009 06:54:42 -0700

I've commented on this already: I don't see a need for any change.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn
Sent: Monday, June 08, 2009 6:57 PM
To: LTRU Working Group
Subject: [Ltru] Issue #59: replace RECOMMENDED language with MUST language in 2.2.1 (Apps #12a)

Hi -

....
...

Randy

---

From: Mark Davis <[email-masked]>
Date: Tue, 9 Jun 2009 08:35:53 -0700

+1
Mark

---

From: Peter Constable <[email-masked]>
Date: Tue, 9 Jun 2009 09:20:08 -0700

>> Although the specification of valid subtags for an extension (see 
>> Section 3.7 (Extensions and the Extensions Registry)) MUST be 
>> available over the Internet, implementations SHOULD NOT mechanically 
>> depend on it being always accessible, to prevent denial-of-service 
>> attacks.
>> --
>>
>> This should also address the IANA registry. I think that's an 
>> oversight. I actually thought it said both.
>
> Okay. Here is proposed text for insertion just before the currently 
> last paragraph in section 6:
>
> >>>>

That text looks OK to me.

> downloading, without having to download the full registry.

That also looks OK to me.

>> It's possible, although once you've parsed the new registry, 
>> the diff doesn't matter so much. Note that stability rules 
>> generally prevent breaking changes.

> amount of data that needs to be downloaded to update the registry to a 

But if we're directing implementations not to do real-time automated downloads, then it seems that the amount of data shouldn't be that much of an issue.

> documented in the security section.

That seems reasonable, and I think the text you suggested covers the key issues.

Peter

---

From: Mark Davis <[email-masked]>
Date: Tue, 9 Jun 2009 09:27:02 -0700

I agree with Peter.

Mark

On Tue, Jun 9, 2009 at 09:20, Peter Constable <[email-masked]>wrote:

> But if we're directing implementations not to do real-time automated
> downloads, then it seems that the amount of data shouldn't be that much of
> an issue.
>
>

---

From: Peter Constable <[email-masked]>
Date: Tue, 9 Jun 2009 09:35:31 -0700

I also don't think a change is necessary.

I agree with Randy: this use of MAY is indicating an optional activity that must be anticipated by implementations. I think the wording could be better; e.g. something along this line:

"The Description field MAY be modified. Modifications for errata corrections or clarifications of intent might be considered acceptable by the community, but attempts to provide translations or transcriptions of entries in the registry itself will probably be frowned upon by the community or rejected outright, as changes of this nature have an impact on the provisions in Section 3.4 (Stability of IANA Registry Entries). Note that, since modifications are possible, the Description field is not guaranteed to be stable."

A change to the text I've given here would be editorial, not technical, in nature. I don't consider it necessary or highly important, but would be open to that change should the editors be so inclined.

Peter

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 9 Jun 2009 09:51:35 -0700

(as contributor)

+1.

Addison Phillips

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Tuesday, June 09, 2009 9:27 AM
To: Peter Constable
Cc: "Martin J. Dürst"; Phillips, Addison; Alexey Melnikov; LTRU Working Group
Subject: Re: [Ltru] Issue #62: (AD #14) DoS potential (was: Re: AD issue #14 (DoS potential) Additional issues with 4646bis raised by an Apps Review Team review)

I agree with Peter.

Mark

On Tue, Jun 9, 2009 at 09:20, Peter Constable <[email-masked]<mailto:[email-masked]>> wrote:
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of "Martin J. Dürst"

> [email-masked]<mailto:[email-masked]>. Changes, or the absence thereof,

Peter

_______________________________________________
Ltru mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ltru

---

From: Kent Karlsson <[email-masked]>
Date: Tue, 09 Jun 2009 18:54:14 +0200

I agree.

    /kent k

Den 2009-06-09 18.35, skrev "Peter Constable" <[email-masked]>:

> I agree with Randy: this use of MAY is indicating an optional activity that
> must be anticipated by implementations. I think the wording could be better;
> e.g. something along this line:
> 
> "The Description field MAY be modified. Modifications for errata corrections
> or clarifications of intent might be considered acceptable by the community,
> but attempts to provide translations or transcriptions of entries in the
> registry itself will probably be frowned upon by the community or rejected
> outright, as changes of this nature have an impact on the provisions in
> Section 3.4 (Stability of IANA Registry Entries). Note that, since
> modifications are possible, the Description field is not guaranteed to be
> stable."
> 
> 
> A change to the text I've given here would be editorial, not technical, in
> nature. I don't consider it necessary or highly important, but would be open
> to that change should the editors be so inclined.
> 
> 
> 
> Peter

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 9 Jun 2009 12:21:31 -0700

Hi -

> To: "Phillips, Addison" <[email-masked]>
> Sent: Tuesday, June 09, 2009 12:10 AM
...

Done.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 9 Jun 2009 12:24:54 -0700

Hi -

> To: "Peter Constable" <[email-masked]>
> Sent: Tuesday, June 09, 2009 1:39 AM

Done.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 9 Jun 2009 12:27:23 -0700

Hi -

> Sent: Tuesday, June 09, 2009 1:41 AM
...

Done.

Randy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 10 Jun 2009 10:29:54 +0900

[hats on]

I have counted five people (this includes Randy, who commented on the 
general agreement with the need of doing something here in private) in 
favor of adding the two text pieces below, and nobody against.

I would like to ask the editors to integrate these texts into the newest 
version of their draft, and Randy to close this issue.

Regards,    Martin.

On 2009/06/10 1:51, Phillips, Addison wrote:
> On Tue, Jun 9, 2009 at 09:20, Peter Constable<[email-masked]<mailto:[email-masked]>>  wrote:

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 10 Jun 2009 10:36:05 +0900

[hats on]

I have seen four people who don't think we need a change on this, and 
nobody saying anything in favor of changing.

I'm interpreting this as consensus to not make any changes.
Randy, please close this issue accordingly.

Regards,    Martin.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 10 Jun 2009 11:23:00 +0200

On Mon, Jun 08, 2009 at 03:53:39PM -0700,
 Phillips, Addison <[email-masked]> wrote 
 a message of 116 lines which said:

> Developers who are dependent upon the language subtag registry
> sometimes would like to be informed of changes in the registry so
> that they can update their implementations. When any change is made
> to the language subtag registry, IANA will send an announcement
> message to "[email-masked]" (a
> self-subscribing list that only IANA can post to).

There is also a RFC 4287 feed at
<http://www.langtag.net/registries/lsr.atom>.  It could be improved if
necessary.

> > It might be nice to have the File-Date value available as a
> > separate short piece of data (a separate web page on IANA's
> > website, a thing in DNS, etc.  But even with existing registry
> > format it might be possible to minimize load on IANA's website by
> > describing how HTTP/1.1 features can be used to only download
> > necessary information, such as downloading the beginning of the
> > registry which contains the File-Date field.

The proper HTTP 1.1 way is to use a conditional GET. RFC 2616, section
14.25. The IANA HTTP server supports it fine. Here is how it is used
by the program behind <http://www.langtag.net/>:

if [ -e ${LTR_LOCAL} ]; then
  ltr_date=`head -n 1 ${LTR_LOCAL} | cut -d" " -f2`
  # Allow time to elapse. The date of the file at IANA is often the day after
  # the date written in the LSR. Heuristically, we add one day and a few hours.
  current_date=`date +"%Y%m%d %H:%M:%S" --date="${ltr_date} +1 day +4 hour"`
else
  # Trick to force a downloading
  current_date="19700101"
fi
curl --silent --output ${LTR_LOCAL}.TMP \
    --compressed \
    --referer ${MYURL} \
    --proxy "" \
    --time-cond "${current_date}" \
    --header "From: ${MAINTAINER}" \
  ${LTR_URL} ...

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 10 Jun 2009 18:51:21 +0900

[hats on]

Hello Stephane,

I'm assuming that you are sending the contribution below for 
documentation purposes. Just in case you think we need to reopen issue 
62, you would have to say that explicitly.

Everybody, at this stage, if you make information-only comments, please 
say so explicitly.

Regards,    Martin.

On 2009/06/10 18:23, Stephane Bortzmeyer wrote:
>   Phillips, Addison<[email-masked]>  wrote
> by the program behind<http://www.langtag.net/>:
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 10 Jun 2009 19:01:54 +0900

[hats on]

I currently have Kent, Randy, Peter, and myself down as against changes 
on this issue. There are also some eventuality proposals for new text, 
but these are currently not relevant. Please express your preference 
(and the reasons for it) if you haven't already done so. If you have 
expressed your opinion, but I haven't considered it, please also say so.

Unless somebody expresses a preference (and reason) for making a change, 
I'll declare consensus on this issue tomorrow my morning.

Regards,    Martin.

On 2009/06/10 1:54, Kent Karlsson wrote:
> I agree.
>
>      /kent k
>
> Den 2009-06-09 18.35, skrev "Peter Constable"<[email-masked]>:
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 10 Jun 2009 19:01:52 +0900

[hats on]

I currently have Kent, Peter, Mark, and myself down as against changes 
on this issue. Please express your preference (and the reasons for it) 
if you haven't already done so. If you have expressed your opinion, but 
I haven't considered it, please also say so.

Regards,    Martin.

On 2009/06/10 0:35, Mark Davis wrote:
> +1
> Mark
>
>
> On Tue, Jun 9, 2009 at 06:54, Peter Constable<[email-masked]>wrote:
>
> ------------------------------------------------------------------------
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 10 Jun 2009 14:12:41 +0200

On Wed, Jun 10, 2009 at 06:51:21PM +0900,
 Martin J. Dürst <[email-masked]> wrote 
 a message of 71 lines which said:

> documentation purposes.

Correct.

> Just in case you think we need to reopen issue 62, you would have to
> say that explicitly.

No, no, for me, this so-called DoS risk is a non-issue, so I'm happy
if #62 stays closed.

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 10 Jun 2009 08:12:02 -0700

I oppose the change because I consider the comment a misreading. Perhaps the sentence should be split into several separate sentences in order to separate normative from informative. However, the MAY keyword is there specifically to allow errata corrections (a problem that was raised during the development of this document).

Addison Phillips

> Behalf Of "Martin J. Dürst"
> Sent: Wednesday, June 10, 2009 3:02 AM
> To: Kent Karlsson
> Cc: LTRU Working Group

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 10 Jun 2009 08:12:02 -0700

I also oppose making the change.

Addison Phillips

> To: Mark Davis
> MUST language in 2.2.1 (Apps #12a)
> 
> [hats on]
> 
> Behalf Of
> >> Randy Presuhn
> >> Subject: [Ltru] Issue #59: replace RECOMMENDED language with
> MUST language
> >> in 2.2.1 (Apps #12a)
> >>
> >> Hi -
> >>
> >>> Subject: Re: Additional issues with 4646bis raised by an Apps
> Review Team
> >> review
> >> ....
> >>> 12). In Section 2.2.1:
> >>>
> >>>>         registry were defined via the registration process in
> Section
> >> 3.5

---

From: Peter Constable <[email-masked]>
Date: Wed, 10 Jun 2009 08:27:15 -0700

In that case, might it make sense to consider the change I suggested?

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillips, Addison
Sent: Wednesday, June 10, 2009 8:12 AM
To: "Martin J. Dürst"; Kent Karlsson
Cc: LTRU Working Group
Subject: Re: [Ltru] Issue #61: Problem with MAY in 3.5 on Description errata(Apps #13)

Addison Phillips

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 10 Jun 2009 08:38:51 -0700

Yes. I'm agreeable to that change.

Addison Phillips

> From: Peter Constable [mailto:[email-masked]]
> Sent: Wednesday, June 10, 2009 8:27 AM
> To: Phillips, Addison; "Martin J. Dürst"; Kent Karlsson
> Cc: LTRU Working Group
> Subject: RE: [Ltru] Issue #61: Problem with MAY in 3.5 on
> Description errata(Apps #13)
> 
> Behalf Of Phillips, Addison
> I oppose the change because I consider the comment a misreading.
> Perhaps the sentence should be split into several separate
> sentences in order to separate normative from informative. However,
> the MAY keyword is there specifically to allow errata corrections
> (a problem that was raised during the development of this document).
> 
> Addison Phillips
> > >> "The Description field MAY be modified. Modifications for
> errata
> > corrections

---

From: Mark Davis <[email-masked]>
Date: Wed, 10 Jun 2009 09:35:03 -0700

Although going in the right direction, I don't think it quite hits the mark,
since it is still talking about "the community", which is not defined and
has no other status in the document. It also gives no sense of who is doing
what. I have suggested language below, plus the other formulations for
comparison.

Mark:

The Description field MAY be modified, and is thus not guaranteed to be
stable. However, modifications are discouraged because of the negative
impact on the provisions in Section 3.4 (Stability of IANA Registry
Entries). Therefore the Language Subtag Reviewer SHOULD accept only
modifications for errata corrections or required clarifications of intent,
and SHOULD NOT accept translations or transcriptions of entries in the
registry.

OLD

>    sufficient justification for corrections or updates.

Peter:

The Description field MAY be modified. Modifications for errata corrections
stable.

Mark

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 10 Jun 2009 09:58:11 -0700

Hi -

> Cc: "LTRU Working Group" <[email-masked]>; "Alexey Melnikov" <[email-masked]>
> Sent: Tuesday, June 09, 2009 6:29 PM
> Subject: Re: [Ltru] Issue #62: (AD #14) DoS potential
>
> [hats on]
>

Done.

Randy

---

From: Peter Constable <[email-masked]>
Date: Wed, 10 Jun 2009 10:09:22 -0700

I’d be OK with that wording.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Wednesday, June 10, 2009 9:35 AM
To: Phillips, Addison
Cc: Peter Constable; "Martin J. Dürst"; Kent Karlsson; LTRU Working Group
Subject: Re: [Ltru] Issue #61: Problem with MAY in 3.5 on Description errata(Apps #13)

Although going in the right direction, I don't think it quite hits the mark, since it is still talking about "the community", which is not defined and has no other status in the document. It also gives no sense of who is doing what. I have suggested language below, plus the other formulations for comparison.

Mark:

The Description field MAY be modified, and is thus not guaranteed to be stable. However, modifications are discouraged because of the negative impact on the provisions in Section 3.4 (Stability of IANA Registry Entries). Therefore the Language Subtag Reviewer SHOULD accept only modifications for errata corrections or required clarifications of intent, and SHOULD NOT accept translations or transcriptions of entries in the registry.

OLD

Peter:

The Description field MAY be modified. Modifications for errata corrections or clarifications of intent might be considered acceptable by the community, but attempts to provide translations or transcriptions of entries in the registry itself will probably be frowned upon by the community or rejected outright, as changes of this nature have an impact on the provisions in Section 3.4 (Stability of IANA Registry Entries). Note that, since modifications are possible, the Description field is not guaranteed to be stable.

Mark

On Wed, Jun 10, 2009 at 08:38, Phillips, Addison <[email-masked]<mailto:[email-masked]>> wrote:
Yes. I'm agreeable to that change.

Addison Phillips

> From: Peter Constable [mailto:[email-masked]<mailto:[email-masked]>]
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> > > Den 2009-06-09 18.35, skrev "Peter
> > Constable"<[email-masked]<mailto:[email-masked]>>:
> > >
> > #-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]<mailto:[email-masked]>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 10 Jun 2009 19:10:45 +0100

Mark Davis wrote:

>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
Yes.

>     > [email-masked]
>     <mailto:[email-masked]>.
>
I hope you are not suggesting that every implementation that wants to 
automatically download the registry should subscribe to this mailing 
list ;-).

>     >Changes, or the absence thereof,
>
This looks good in general. I would have expanded on how to do this in 
HTTP, considering that the registry is exported over HTTP, but the 
current text is good enough.

Yes.

>     But if we're directing implementations not to do real-time
>     automated downloads, then it seems that the amount of data
>     shouldn't be that much of an issue.
>
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 10 Jun 2009 19:19:30 +0100

>Actually, this is false. The validity text is careful to say "as of the particular registry date" when referring to validity. There is an expectation that most implementation will use a specific reg…
Right.

>Obviously this would be a concern. In fact, Section 6 (Security Considerations) says:
Agree.

>Developers who are dependent upon the language subtag registry sometimes would like to be informed of changes in the registry so that they can update their implementations.
>
The key word here is "developers", not "implementations"

>When any change is made to the language subtag registry, IANA will send an announcement message to "[email-masked]" (a self-subscribing list that only IANA can post to).
>--
>  
>
>No, there isn't. The records do not contain a "last modified" date. Is this necessarily important? When I update one of my implementations, I just reparse the latest registry.
>
Updating a table which is a part of an implementation is not a concern, 
as it is done only once per implementation version.

>Stability rules exist to protect my doing it this way. Since the records are not in any particular order, there isn't necessarily utility to using diff to reconstruct changes either.
>  
>
I was thinking that the registry showing templates 
(<http://www.iana.org/assignments/lang-subtags-templates/index.html>) 
could be updated to show dates when each entry was approved. I think 
this would enable incremental updates.
 [snip]

>It's possible, although once you've parsed the new registry, the diff doesn't matter so much. Note that stability rules generally prevent breaking changes.
See above.
As a side note - diff like format would work nicely, as according to 
update rules, existing records can't move in the file.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 10 Jun 2009 19:25:38 +0100

>authorized mirrors, or impose controls on download, or do something
IANA might also go to IAB and ask for more money to handle LTRU 
registry. IAB might not be impressed by that.

---

From: Kent Karlsson <[email-masked]>
Date: Wed, 10 Jun 2009 20:40:59 +0200

> this would enable incremental updates.

Looking trough a few of the individual entries, they all seem to be dated,
both at the beginning and end (updated/created). But I guess you mean the
table in the index.html file (which is not a registry, just a table, the
format of which is not specified in 4646bis).

    /kent k

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 10 Jun 2009 19:44:51 +0100

Kent Karlsson wrote:

>table in the index.html file
>
Yes, so that all dates are in 1 place.

>(which is not a registry, just a table, the format of which is not specified in 4646bis).
>  
>
I know, but it might be a good idea if it is specified.

---

From: Kent Karlsson <[email-masked]>
Date: Wed, 10 Jun 2009 20:49:24 +0200

> I know, but it might be a good idea if it is specified.

Not at this stage of 4646bis development.

    /kent k

---

From: Peter Constable <[email-masked]>
Date: Wed, 10 Jun 2009 12:10:40 -0700

This is also my concern: it's late in the cycle and we need to drive to release. We shouldn't add new features unless there is really a gap that leaves our target scenarios broken, and I don't see that in this case. It feels like suggestions for providing registry diffs or displaying an index in a revised format should be possible candidates for a new charter.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Karlsson
Sent: Wednesday, June 10, 2009 11:49 AM
To: Alexey Melnikov
Cc: LTRU Working Group
Subject: Re: [Ltru] AD issue #14 (DoS potential) Additional issues with 4646bis raised by an Apps Review Team review

    /kent k

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 11 Jun 2009 10:20:11 +0900

Hello Alex,

[hats off, on a closed issue]

On 2009/06/11 3:10, Alexey Melnikov wrote:
>> From: [email-masked] <mailto:[email-masked]> On

>> That text looks OK to me.

Great.

> automatically download the registry should subscribe to this mailing

No. Every implementer, yes. But not all the copies of an implementation 
out in the field. And there are three reasons why it wouldn't be that 
bad even if implementers tried to do that:

First, while it's rather easy during an install process to fetch some 
data, e.g. over HTTP (assuming you're online), setting up an 
implementation to receive emails would require quite a bit of effort. 
Essentially, you have to create a new, dedicated email address on a 
foreign system.

Second, even if the number of subscribers grew quite a bit, sending out 
the emails would be way less bandwidth for IANA than being polled 
constantly (e.g. whenever an application processed a language tag).

Third, IANA is the active side. If need be, they could do anything they 
wanted, from temporarily stopping to accept new subscriptions to 
pressuring the creators of certain products (much more effective if they 
are the active party), and so on.

The above arguments are not given to suggest email notifications to 
deployed implementations are a good idea, quite to the contrary. If an 
implementer really decided they need something like this, they should 
subscribe to IANA once, and create their own notification system, which 
could also include creating and distributing diffs for the updates 
rather than resending or refetching the whole registry. As it would be 
their bandwidth, it would also be their motivation to optimize.

> current text is good enough.

Thanks.

I seem to remember discussing this a couple years or so ago. I think 
there were some good arguments against it, as IANA may want to use other 
protocols in the future.

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 11 Jun 2009 12:21:12 +0900

[hats on]

I declare consensus on the fact that we do not want to remove the MAY,
but are considering the clarification of the text. Please help 
converging on a version of the text that is clearer than the original, 
but doesn't change its meaning.

[Randy, this doesn't close this issue yet]

Please say whether you are okay with the new text proposed at the end of 
this mail.

> and SHOULD NOT accept translations or transcriptions of entries in the

This text introduces two new shoulds where we only had a MAY, unrelated 
to the comment. This is clearly inappropriate at this stage of the process.

> modifications are possible, the Description field is not guaranteed to be

I agree with Mark that 'community' isn't well defined. But it was in our 
original text, so we can leave it in. However, Peter's text doubles it. 
I propose removing the first one. I also re-added the quotes to 
'Description', split a sentence, removed " or clarifications of intent" 
(well intended, but not in the original text), and changed the 'might' 
to 'are' ("errata might be acceptable" sounds as if some errata are not 
acceptable, which I would have difficulties understanding). The new text 
I'm proposing is:

NEW text:
The 'Description' field MAY be modified. Modifications for errata 
corrections or clarifications of intent are considered acceptable. 
However, attempts to provide translations or transcriptions of entries 
in the registry itself will probably be frowned upon by the community or 
rejected outright, as changes of this nature have an impact on the 
provisions in Section 3.4. Note that, since modifications are possible, 
the Description field is not guaranteed to be stable.

Please say whether you are okay with the new text or want some 
additional changes. If you propose additional changes, please include 
your full new text after motivating the changes. If you propose changes, 
please try to stay as close as possible to the text and intent of the 
original text.

Regards,    Martin.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Jun 2009 00:16:16 -0700

Hi -

> To: "Mark Davis" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, June 10, 2009 8:21 PM
...
...

I do not see how this text is an improvement over the existing text.
Furthermore, since the reviewer's comment was only about the use
of "MAY", and since there have been no claims that any real or
potential operational or implementation problems would result from
the existing text, I see no reason to make a change here.

Randy

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 11 Jun 2009 10:53:11 +0100

[...]

> No. Every implementer, yes. But not all the copies of an 
> implementation out in the field. And there are three reasons why it 
> wouldn't be that bad even if implementers tried to do that:
>
> Second, even if the number of subscribers grew quite a bit, sending 
> out the emails would be way less bandwidth for IANA than being polled 
> Third, IANA is the active side. If need be, they could do anything 
> they wanted, from temporarily stopping to accept new subscriptions to 
> pressuring the creators of certain products (much more effective if 
> they are the active party), and so on.

Right.

> subscribe to IANA once, and create their own notification system, 
> which could also include creating and distributing diffs for the 
> updates rather than resending or refetching the whole registry. As it 
> would be their bandwidth, it would also be their motivation to optimize.

I think a reworded version of your last 2 sentences should be in the 
document. This is indeed the message I would like to convey to a reader 
of the document.

> there were some good arguments against it, as IANA may want to use 
> other protocols in the future.

4646bis is targeted for BCP and Best Current Practices change over time.

[Speaking as a contributor:] I would much prefer if the document 
encourages good protocol practices. It is not reasonable to assume that 
every reader would know the best way of doing the task, there are 
multiple examples of this being not true for other protocols.
The advice can start with "At the time of publication of this document 
IANA is exporting the Language Tag registry over HTTP, ..."

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 11 Jun 2009 20:36:27 +0900

[co-chair hat on]

Hello Randy,

(I would personally have been fine with keeping the text as is, and you 
probably overlooked that part of my message, but) I have already 
declared that we have consensus that we should improve the wording 
(without changing the substance), because we think that the comment was 
based (to some extent) on misunderstanding.

If you think that I judged that consensus wrongly, please say so, so 
that we can reopen discussion on that part.
If you think that moving issue resolution forward by declaring consensus 
on some part of an issue and then continue to resolve the remaining 
parts of the issue is procedurally inappropriate, please say so.

Otherwise, please help us concentrate on the issues (and subissues) 
currently being discussed, so that we can move forward as quickly as 
possible.

Regards,    Martin.

On 2009/06/11 16:16, Randy Presuhn wrote:
>> From: "Martin J. Dürst"<[email-masked]>
>> To: "Mark Davis"<[email-masked]>
>> Cc: "LTRU Working Group"<[email-masked]>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 11 Jun 2009 20:58:25 +0900

Hello Alex,

>> [hats off, on a closed issue]

or so I thought :-(

> document. This is indeed the message I would like to convey to a reader

By 'last two sentences', I assume you mean:

Also, the registry contents changes only occasionally. Changes are 
announced to [email-masked] 
<mailto:[email-masked]>.

Okay, here's some textual proposal:

This mailing list is intended for interested organizations and 
individuals, not for bulk subscription to trigger automatic software 
updates. The size of the registry makes it unsuitable for automatic 
software updates. Implementers considering integrating the Language 
Subtag Registry in an automatic updating scheme are strongly advised to 
distribute only suitably encoded differences, and only via their own 
infrastructure, not directly from IANA.

> IANA is exporting the Language Tag registry over HTTP, ..."

Okay, here is a textual proposal:

At the time of publication of this document IANA is making the Language 
Tag registry available over HTTP 1.1. The proper way to update a local 
copy of the Language Subtag Registry using HTTP 1.1 is to use a 
conditional GET [RFC2616].

This would mean that we have to add RFC 2616 to the references.

[hats on]
Because time is running out, I propose to publish -23 without the above 
additional texts. I leave it to Alex to tell us exactly what to do or 
otherwise to decide how to handle this to be able to move the draft 
forward in a timely manner.

[hats off]
I'm somewhat concerned that we start to put more and more stuff into the 
security section, where it might not necessarily belong, and that we are 
on a slippery slope to add more and more stuff. While I think that these 
operational issues are important, our document is a BCP on Language 
Tags, not on how to (or not to) download the Language Subtag Registry.

Regards,   Martin.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 11 Jun 2009 13:03:56 +0100

[...]

> <mailto:[email-masked]>.

No, I meant:

If an implementer really decided they need something like this, they should

> Subtag Registry in an automatic updating scheme are strongly advised 
> to distribute only suitably encoded differences, and only via their 
> own infrastructure, not directly from IANA.

I like this and I think it covers what I was referring to.

> At the time of publication of this document IANA is making the 
> Language Tag registry available over HTTP 1.1. The proper way to 
> update a local copy of the Language Subtag Registry using HTTP 1.1 is 
> to use a conditional GET [RFC2616].
>

This looks fine to me.

> [hats on]
> Because time is running out, I propose to publish -23 without the 
> above additional texts. I leave it to Alex to tell us exactly what to 
> do or otherwise to decide how to handle this to be able to move the 
> draft forward in a timely manner.

I can always add an RFC Editor note. So yes, publishing 23 without this 
text is fine.

> [hats off]
> I'm somewhat concerned that we start to put more and more stuff into 
> the security section, where it might not necessarily belong, and that 
> we are on a slippery slope to add more and more stuff. While I think 
> that these operational issues are important, our document is a BCP on 
> Language Tags, not on how to (or not to) download the Language Subtag 
> Registry.

Hats off: A separate section might be better.

---

From: Mark Davis <[email-masked]>
Date: Thu, 11 Jun 2009 06:56:04 -0700

I don't think yours is any improvement on the old text, so if that is the
only choice, I vote to leave as is.

Mark

On Wed, Jun 10, 2009 at 20:21, "Martin J. Dürst" <[email-masked]>wrote:

> but are considering the clarification of the text. Please help converging
> on a version of the text that is clearer than the original, but doesn't
> change its meaning.
>
> This text introduces two new shoulds where we only had a MAY, unrelated to
> the comment. This is clearly inappropriate at this stage of the process.
>
>  OLD
>>
> original text, so we can leave it in. However, Peter's text doubles it. I
> propose removing the first one. I also re-added the quotes to 'Description',
> split a sentence, removed " or clarifications of intent" (well intended, but
> not in the original text), and changed the 'might' to 'are' ("errata might
> be acceptable" sounds as if some errata are not acceptable, which I would
> have difficulties understanding). The new text I'm proposing is:
>
>
> NEW text:
> corrections or clarifications of intent are considered acceptable. However,
> attempts to provide translations or transcriptions of entries in the
> Section 3.4. Note that, since modifications are possible, the Description
> field is not guaranteed to be stable.
>
> Please say whether you are okay with the new text or want some additional
> changes. If you propose additional changes, please include your full new
> text after motivating the changes. If you propose changes, please try to
> stay as close as possible to the text and intent of the original text.
>
>
> Regards,    Martin.
>
> --

---

From: Peter Constable <[email-masked]>
Date: Thu, 11 Jun 2009 07:02:02 -0700

The reason that the reviewer commented on the use of MAY is that the wording was sufficiently lacking in clarify as to sound as though it was describing a future possibility rather than the intended meaning of expressly sanctioning certain actions. This revised wording makes that intended meaning clear.

Please reconsider.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn
Sent: Thursday, June 11, 2009 12:16 AM
To: LTRU Working Group
Subject: Re: [Ltru] Issue #61: Problem with MAY in 3.5 on Description errata(Apps #13)

Hi -

...
...

Randy

---

From: Peter Constable <[email-masked]>
Date: Thu, 11 Jun 2009 07:04:59 -0700

Mark, please see my reply to Randy.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Thursday, June 11, 2009 6:56 AM
To: Martin J. Dürst
Cc: Phillips, Addison; Peter Constable; Kent Karlsson; LTRU Working Group
Subject: Re: [Ltru] Issue #61: Problem with MAY in 3.5 on Description errata(Apps #13)

I don't think yours is any improvement on the old text, so if that is the only choice, I vote to leave as is.

Mark

On Wed, Jun 10, 2009 at 20:21, "Martin J. Dürst" <[email-masked]<mailto:[email-masked]>> wrote:
[hats on]

I declare consensus on the fact that we do not want to remove the MAY,
but are considering the clarification of the text. Please help converging on a version of the text that is clearer than the original, but doesn't change its meaning.

Please say whether you are okay with the new text proposed at the end of this mail.

Mark:

This text introduces two new shoulds where we only had a MAY, unrelated to the comment. This is clearly inappropriate at this stage of the process.

OLD

Peter:

I agree with Mark that 'community' isn't well defined. But it was in our original text, so we can leave it in. However, Peter's text doubles it. I propose removing the first one. I also re-added the quotes to 'Description', split a sentence, removed " or clarifications of intent" (well intended, but not in the original text), and changed the 'might' to 'are' ("errata might be acceptable" sounds as if some errata are not acceptable, which I would have difficulties understanding). The new text I'm proposing is:

NEW text:
The 'Description' field MAY be modified. Modifications for errata corrections or clarifications of intent are considered acceptable. However, attempts to provide translations or transcriptions of entries in the registry itself will probably be frowned upon by the community or rejected outright, as changes of this nature have an impact on the provisions in Section 3.4. Note that, since modifications are possible, the Description field is not guaranteed to be stable.

Please say whether you are okay with the new text or want some additional changes. If you propose additional changes, please include your full new text after motivating the changes. If you propose changes, please try to stay as close as possible to the text and intent of the original text.

Regards,    Martin.

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 11 Jun 2009 10:00:24 -0700

(editor hat)

In incorporating this fix, I notice a bug. The original DoS text referred to extension registries (those not controlled by IANA). The replacement text referred only to the ILSR and registry of extensions. Therefore I modified the existing sentence when doing the insert so that all three cases are covered. I also needed to correct the grammar of the first sentence and thus the result is an altered format. The new paragraph reads:

--
<t>To prevent denial-of-service attacks, applications SHOULD NOT depend on either the Language Subtag Registry or the Language Tag Extensions Registry being always accessible. Additionally, although the specification of valid subtags for an 
extension (see <xref target="extensions"/>) MUST be available over the Internet, implementations SHOULD NOT 
mechanically depend on those sources being always accessible.</t>
--

Addison Phillips

> Behalf Of Alexey Melnikov
> Sent: Thursday, June 11, 2009 2:53 AM
> To: "Martin J. Dürst"
> Cc: LTRU Working Group
> >>> > The registries specified in this document are not suitable
> for
> >>> frequent
> >>> > can also easily be detected by looking at the File-Date
> record
> >>> at the

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 11 Jun 2009 10:32:57 -0700

Lacking clear guidance, I am following Martin’s consensus determination that we should converge on a version of the text that is “clearer than the original, but doesn’t change its meaning”. I have therefore replaced this paragraph:

--
While the 'Description' field itself is not guaranteed to be stable and errata corrections MAY be undertaken from time to time, attempts to provide translations or transcriptions of entries in the registry itself will probably be frowned upon by the community or rejected outright, as changes of this nature have an impact on the provisions in Section 3.4 (Stability of IANA Registry Entries)<http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-22.html#ianastability>.
--

With the following, adapted from Martin’s proposal, but aping as closely as possible the original wording:

--
<t>The 'Description' field itself is not guaranteed to be stable and MAY be modified via the registration process. Errata
corrections or clarifications of intent are most typical.
Attempts to provide translations or transcriptions of entries
in the registry itself will probably be frowned upon by the community or
rejected outright, as changes of this nature have an impact on the
provisions in <xref target="ianastability"></xref>.</t>
--

Addison Phillips

From: Peter Constable [mailto:[email-masked]]
Sent: Thursday, June 11, 2009 7:05 AM
To: Mark Davis; Martin J. Dürst
Cc: Phillips, Addison; Kent Karlsson; LTRU Working Group
Subject: RE: [Ltru] Issue #61: Problem with MAY in 3.5 on Description errata(Apps #13)

Mark

Mark:

OLD

Peter:

NEW text:

Regards,    Martin.

---

From: Kent Karlsson <[email-masked]>
Date: Thu, 11 Jun 2009 19:44:39 +0200

I would suggest deleting "by the community", since that does not seem
to play any essential role in this paragraph, and some (Mark at least, IIRC)
found a reference to the "community" objectionable. Personally, I don't
like the formulation "frowned upon" either, but no-one else has
complained...

    /kent k

Den 2009-06-11 19.32, skrev "Phillips, Addison" <[email-masked]>:
> --
> <t>The 'Description' field itself is not guaranteed to be stable and
> MAY be modified via the registration process. Errata

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 11 Jun 2009 10:50:04 -0700

(editor hat off)

The word community was already present or I would have replaced it. The formulation ‘frowned upon’ also was already extant and was meant to give a sense of disapproval without actually saying anything normative.

Addison

Addison Phillips

From: Kent Karlsson [mailto:[email-masked]]
Sent: Thursday, June 11, 2009 10:45 AM
To: Phillips, Addison; Peter Constable; Mark Davis; Martin J. Dürst
Cc: LTRU Working Group
Subject: Re: [Ltru] Issue #61: Problem with MAY in 3.5 on Description errata(Apps #13)

I would suggest deleting "by the community", since that does not seem
to play any essential role in this paragraph, and some (Mark at least, IIRC)
found a reference to the "community" objectionable. Personally, I don't
like the formulation "frowned upon" either, but no-one else has complained...

    /kent k

---

From: Mark Davis <[email-masked]>
Date: Thu, 11 Jun 2009 11:21:00 -0700

I have no objections to the change. In some future version we can fix the
goofy use of "frowned upon by the community".

Mark

On Thu, Jun 11, 2009 at 10:32, Phillips, Addison <[email-masked]> wrote:

>  Lacking clear guidance, I am following Martin’s consensus determination
> that we should converge on a version of the text that is “clearer than the
> original, but doesn’t change its meaning”. I have therefore replaced this
> paragraph:
>
>
>
> --
>
> While the 'Description' field itself is not guaranteed to be stable and
> errata corrections MAY be undertaken from time to time, attempts to provide
> translations or transcriptions of entries in the registry itself will
> probably be frowned upon by the community or rejected outright, as changes
> of this nature have an impact on the provisions in Section 3.4 (Stability
> of IANA Registry Entries)<http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-22.html#ianastability>
> .
>
> --
>
>
>
> <t>The 'Description' field itself is not guaranteed to be stable and MAY be
> modified via the registration process. Errata
>
> *From:* Peter Constable [mailto:[email-masked]]
> *Sent:* Thursday, June 11, 2009 7:05 AM
> *To:* Mark Davis; Martin J. Dürst
> *Cc:* Phillips, Addison; Kent Karlsson; LTRU Working Group
> *Subject:* RE: [Ltru] Issue #61: Problem with MAY in 3.5 on Description
> errata(Apps #13)
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Mark Davis
> *Sent:* Thursday, June 11, 2009 6:56 AM
> *To:* Martin J. Dürst
> *Cc:* Phillips, Addison; Peter Constable; Kent Karlsson; LTRU Working
> Group
> *Subject:* Re: [Ltru] Issue #61: Problem with MAY in 3.5 on Description
> errata(Apps #13)
>
>
>

---

From: Peter Constable <[email-masked]>
Date: Thu, 11 Jun 2009 11:23:19 -0700

+1

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Thursday, June 11, 2009 11:21 AM
To: Phillips, Addison
Cc: Peter Constable; Martin J. Dürst; Kent Karlsson; LTRU Working Group
Subject: Re: [Ltru] Issue #61: Problem with MAY in 3.5 on Description errata(Apps #13)

I have no objections to the change. In some future version we can fix the goofy use of "frowned upon by the community".

Mark

On Thu, Jun 11, 2009 at 10:32, Phillips, Addison <[email-masked]<mailto:[email-masked]>> wrote:

--

--

--

--

Addison Phillips

It is an architecture.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mark Davis
Sent: Thursday, June 11, 2009 6:56 AM
To: Martin J. Dürst
Cc: Phillips, Addison; Peter Constable; Kent Karlsson; LTRU Working Group
Subject: Re: [Ltru] Issue #61: Problem with MAY in 3.5 on Description errata(Apps #13)

Mark

[hats on]

Mark:

OLD

Peter:

NEW text:

Regards,    Martin.

--

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Jun 2009 12:03:58 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Sent: Thursday, June 11, 2009 4:36 AM

No, there seem to be plenty of people who want to spend time fine-tuning
the wording, so I think you called the consensus correctly.

> parts of the issue is procedurally inappropriate, please say so.

No, although I find it quite a stretch  to read this "misunderstanding"
into the reviewer's comment, which read:

| Reason: use of MAY is not an appropriate use of RFC 2119, as it is
| trying to forecast the future and doesn't specify a protocol option.

...

Of course.  The substance of my comment is that I find the recently
word-smithed text no better than the original.  If we must change it,
I'd prefer something like this, which would also (incidentally) address
the reviewer's comment:

     The 'Description' field is not guaranteed to be stable.
     Corrections and clarifications of intent are examples of
     possible changes.  However, attempts to provide translations
     or transcriptions of entries (which by definition provide no
     new information) are unlikely to be approved.

I think the existing statement "as changes of this nature have an
impact on the provisions in Section 3.4" is simply incorrect, and *if*
we're going to open up this paragraph, that text should be stricken.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 11 Jun 2009 12:13:40 -0700

(editor hat OFF)

I prefer Randy's text to that in the draft. Any objection to putting it in place and then submitting the results??

Addison

Addison Phillips

> Sent: Thursday, June 11, 2009 12:04 PM
> To: LTRU Working Group

---

From: Kent Karlsson <[email-masked]>
Date: Thu, 11 Jun 2009 21:23:21 +0200

+1

The intent of the MAY, which is omitted in Randy's text, is covered
in section 3.4 point 3.

    /kent k

>> we're going to open up this paragraph, that text should be stricken.
Ltru mailing
> list
[email-masked]

---

From: Peter Constable <[email-masked]>
Date: Thu, 11 Jun 2009 12:47:14 -0700

I'm OK with Randy's text.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillips, Addison
Sent: Thursday, June 11, 2009 12:14 PM
To: Randy Presuhn; LTRU Working Group
Subject: Re: [Ltru] Issue #61: Problem with MAY in 3.5 on Description errata(Apps #13)

(editor hat OFF)

Addison

Addison Phillips

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 12 Jun 2009 15:52:41 +0900

(chair/shepherd hat on)

> The word community was already present or I would have replaced it. The formulation ‘frowned upon’ also was already extant and was meant to give a sense of disapproval without actually saying anyth…

Yes indeed. Everybody in the WG had ample time to propose a fix to these 
words. We are now past WG Last Call and past IETF Last Call.

We addressed comments we got from the Area Director (Alex) and an 
Application Area reviewer.

Next, we will have to work on addressing comments from the IESG, if any. 
If we start fixing our own text again, where there are no comments from 
the relevant parties, that may be seen as a sign that we think we are 
not yet done. But I hope nobody wants to go back to WG Last Call.

Regards,   Martin.

P.S.: I hope the RFC Editor will change

    (which, by definition provide no new information)

to

    (which, by definition, provide no new information)

or

    (which by definition provide no new information)

Editors, please put this on your list of things you may want to look at 
during the AUTH48 stage.

> Den 2009-06-11 19.32, skrev "Phillips, Addison"<[email-masked]>:
> --
> provisions in<xref target="ianastability"></xref>.</t>
> --

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 12 Jun 2009 16:29:31 +0900

When I wrote issue 43 below, that should have been issue 62, sorry.
Issue 43 is closed, I hope to your satisfaction.

Regards,   Martin.