Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Apr 2009 09:08:20 +0100

I think the document is well written, but IANA registration rules are 
overwhelmingly complex. But I don't know if anything can be done about 
complexity of the registration procedure. IANA lists Michael Everson and 
Doug Ewell as the registry reviewers. Are they happy to continue being 
reviewers for the 4646bis?

I have some comments/issues that need to be addressed or at least 
discussed before requesting IESG review of the document. However I am 
happy for the document to go to the IETF LC as is, so I've initiated 
IETF LC for the document.

Below are my comments:

1).

> 2.2.1.  Primary Language Subtag

  [...]

>    5.  Any language subtags of 5 to 8 characters in length in the IANA

  [...]

>        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, and proposals rejected by ISO 639/
>        RA-JAC will be closely scrutinized before they are registered
>        with IANA.

[Unclear text] Scrutinized by whom? At this point in the document it is 
not clear who is going to perform the action.
I think you meant that this would be done by the designated registry 
reviewer, so I suggest adding a forward reference here.

2).

> 2.2.2.  Extended Language Subtags

 [...]

>    4.  Although the ABNF production 'extlang' permits up to three
>        extended language tags in the language tag, extended language
>        subtags MUST NOT include another extended language subtag in
>        their Prefix.  That is, the second and third extended language
>        subtag positions in a language tag are permanently reserved and
>        tags that include subtags in that position are invalid.

[Unclear text] Clarification on what is meant by "permanently reserved" 
here would be appreciated.
("Permanently reserved" == "MUST NOT be registered, unless a future 
version of this document changes that"?)

3). Section 2.2.4 says:

>        F.  All other UN numeric codes for countries or areas that do not
>            have an associated ISO 3166-1 alpha-2 code MUST NOT be
>            entered into the registry and MUST NOT be used to form
>            language tags.  For more information about these codes, see
>            Section 3.4.

And Section 3.4 says:

>   16.  UN M.49 has codes for both countries and areas (such as '276'
>         for Germany) and geographical regions and sub-regions (such as
>         '150' for Europe).  UN M.49 country or area codes for which
>         there is no corresponding ISO 3166-1 code SHOULD NOT be

Unless I am confused, I think this SHOULD NOT contradicts MUST NOT in 
section 2.2.4.
I think you need to change one of 2 sections.

>         registered, except as a surrogate for an ISO 3166-1 code that is
>         blocked from registration by an existing subtag.  If such a code
>         becomes necessary, then the registration authority for ISO
>         3166-1 SHOULD first be petitioned to assign a code to the
>         region.  If the petition for a code assignment by ISO 3166-1 is
>         refused or not acted on in a timely manner, the registration
>         process described in Section 3.5 MAY then be used to register
>         the corresponding UN M.49 code.  This way, UN M.49 codes remain
>         available as the value of last resort in cases where ISO 3166-1
>         reassigns a deprecated value in the registry.

4). In Section 2.2.9:

>    Note well: although the 'Language-Tag' production appearing in this
>    document is functionally equivalent to the one in [RFC4646], it has
>    been changed to prevent certain errors in well-formedness arising
>    from the old 'grandfathered' production.  This version of the ABNF is
>    RECOMMENDED as a replacement for the older version.

(nit) I suggest deleting the last sentence, as it doesn't provide any 
useful information to a reader (as the WG wants 
draft-ietf-ltru-4646bis-21bis.txt to replace RFC 4646, it is clear that 
the WG believes that the new ABNF is better). Also I don't think it uses 
RFC 2119 keyword properly.

5). In Section 2.2.9:

>    The format of the registry is described by the following ABNF (per
>    [RFC5234]):
>
>    registry   = record *("%%" CRLF record)
>    record     = 1*field
>    field      = ( field-name field-sep field-body CRLF )
>    field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
>    field-sep  = *SP ":" *SP
>    field-body = *([[*SP CRLF] 1*SP] 1*CHARS)
>    CHARS      = (%x21-10FFFF)      ; Unicode code points

[ABNF error] While I understand what you mean here, I think the 
definition of CHARS doesn't match the requirement to use UTF-8 encoding 
stated earlier in section 3.1.1:

   The registry is a [Unicode] text file, using the UTF-8 [RFC3629]
   character encoding, and consists of a series of records stored in a
   format based on "record-jar" (described in [record-jar]).

IMHO, you can use ABNF productions from [RFC3629] to fix that.

6). In Section 3.1.2:

> Field-names MUST occur no more
>    than once per record, with the exception of the 'Description',
>    'Comments', and sometimes the 'Prefix' field.

(nit) Suggestion to reword using MUST NOT. E.g.:

   Field-names MUST NOT occur more
   than once per record, with the exception of the 'Description',
   'Comments', and sometimes the 'Prefix' field.

7). In Section 3.4:

>    15.  Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 that
>         conflict with existing subtags of the associated type, including
>         subtags that are deprecated, MUST NOT be entered into the
>         registry.  The following additional considerations apply to
>         subtag values that are reassigned:

 [...]

>         F.  For ISO 3166-1 codes, if there is no associated UN numeric
>             code, then the Language Subtag Reviewer SHALL petition the
>             UN to create one.  If there is no response from the UN
>             within ninety days of the request being sent, the Language
>             Subtag Reviewer SHALL prepare a proposal for entering in the
>             IANA registry as soon as practical a registered variant
>             subtag as an alternate value for the new code.  The form of
>             the registered variant subtag will be at the discretion of
>             the Language Subtag Reviewer and MUST conform to other
>             restrictions on variant subtags in this document.  This
>             situation is very unlikely to ever occur.
>
>    16.  UN M.49 has codes for both countries and areas (such as '276'
>         for Germany) and geographical regions and sub-regions (such as
>         '150' for Europe).  UN M.49 country or area codes for which
>         there is no corresponding ISO 3166-1 code SHOULD NOT be
>         registered, except as a surrogate for an ISO 3166-1 code that is
>         blocked from registration by an existing subtag.  If such a code
>         becomes necessary, then the registration authority for ISO
>         3166-1 SHOULD

Why SHOULD is used here instead of SHALL?
Similar text in 15.F says SHALL, which is stronger.
Also, 15.F specifies expected response time (90 days), which is missing 
below. Any reason why you don't want to specify deadline in this case?

>         first be petitioned to assign a code to the
>         region.  If the petition for a code assignment by ISO 3166-1 is
>         refused or not acted on in a timely manner, the registration
>         process described in Section 3.5 MAY then be used to register
>         the corresponding UN M.49 code.  This way, UN M.49 codes remain
>         available as the value of last resort in cases where ISO 3166-1
>         reassigns a deprecated value in the registry.

8). In Section 3.5:

>    The fields in the "Record Requested" section SHOULD follow the
>    requirements in Section 3.1.

What are the reasons not to follow requirements in Section 3.1?
(I.e. why is SHOULD used instead of MUST?)

9).

> 3.8.  Update of the Language Subtag Registry
>
>    Upon adoption of this document the IANA Language Subtag Registry will
>    need an update so that it contains the complete set of subtags valid
>    in a language tag.  This collection of subtags, along with a
>    description of the process used to create it, is described by
>    [draft-4645bis].  IANA will publish the updated version of the
>    registry described by this document using the instructions and
>    content of [draft-4645bis].

(nit) I think both 4645bis and 4646bis should be published at the same time.
If this happens, then use of future tense in the published RFC would be 
confusing and will not match the reality.

I suggest adding an RFC Editor note asking to fix this sentence.

> Once published by IANA, the maintenance
>    procedures, rules, and registration processes described in this
>    document will be available for new registrations or updates.

10).

> 5.1.  Language Subtag Registry

 [...]

>    Whenever an entry is created or modified in the registry, the 'File-
>    Date' record at the start of the registry is updated to reflect the
>    most recent modification date in the [RFC3339] "full-date" format:
>    included in any request to insert or modify records will be a new
>    File-Date record indicating the acceptance date of the record.  This
>    record is to be placed first in the registry, replacing the existing
>    File-Date record.  In the event that the File-Date record present in
>    the registry has a later date than the record being inserted or
>    modified, then the latest (most recent) record will be preserved.

I am confused by which date is going to be used by IANA in this case.
Section 3.1.2 says:

   The first record in the registry is always the "File-Date" record.
   This record occurs only once in the file and contains a single field
   whose field-name is "File-Date".  The field-body of this record
   contains the last modification date of this copy of the registry,
   making it possible to compare different versions of the registry.

I think if File-Date record present in the registry has a later date 
than the record being inserted or modified, then IANA should use the 
date of update (which I assume would be after the record 
modification/addition date). This way any change to the IANA registry 
can be detected.

11).

> 4.2.  Meaning of the Language Tag

 [...]

>    o  For information objects whose purpose is to provide alternatives,
>       the associated language tags could be regarded as a hint that the
>       content is provided in several languages and that one has to
>       inspect each of the alternatives in order to find its language or
>       languages.  In this case, the presence of multiple tags might not
>       mean that one needs to be multi-lingual to get complete
>       understanding of the document.  Example: MIME multipart/
>       alternative.

I think this needs an informative reference to MIME.

12).

> 4.5.  Canonicalization of Language Tags

 [...]

>    3.  Subtags of type 'extlang' SHOULD be mapped to their Preferred-
>        Value.

Why use of SHOULD here? I.e. what is a good reason for violating this rule?
A pointer here to some case(s) would be appreciated here.

>   The field-body of the Preferred-Value for extlangs is an
>        "extended language range" and typically maps to a primary
>        language subtag.  For example, the subtag sequence "zh-hak"
>        (Chinese, Hakka) would be replaced with the tag "hak" (Hakka).

13).

> 4.6.  Considerations for Private Use Subtags

 [...]

>    However, in some cases content tagged with private use subtags MAY
>    interact with other systems in a different and possibly unsuitable
>    manner compared to tags that use opaque, privately defined subtags,
>    so the choice of the best approach sometimes depends on the
>    particular domain in question.

I think use of MAY is improper here and I suggest changing it to "can"

14). In Section 3.1.2:

>    o  Preferred-Value
>
>       *  Preferred-Value's field body contains a canonical mapping from
>          this record's value to a modern equivalent that is preferred in
>          its place.  Depending on the value of the 'Type' field, this
>          value can take different forms:

 [...]

>          +  For fields of type 'extlang', 'grandfathered', or
>             'redundant', 'Preferred-Value' contains an "extended
>             language range" ([RFC4647]) that is preferred for forming
>             the language tag.  That is, each of the subtags that appears
>             in the value MUST appear in the replacement tag;

You lost me here: what is "the value" and what is "the replacement tag" 
in this case.

>             additional
>             fields can be included in a language tag as described
>             elsewhere in this document.  For example, the replacement
>             for the grandfathered tag "zh-min-nan" (Min Nan Chinese) is
>             "nan", which can be used as the basis for tags such as "nan-
>             Hant" or "nan-TW" (note that the extended language subtag
>             form such as "zh-nan-Hant" or "zh-nan-TW" can also be used).

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 11:25:08 -0700

Hi -

Since our AD has supplied us with a fairly lengthy set of detailed
comments and has kindly numbered them, I'll enter them into the
issue tracker.   Please put yours responses to keep each issue in
a separate thread with an appropriate subject line - it'll make the
job of the editors and the document shepherd *much* easier.

Randy

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Apr 2009 20:08:40 +0100

>job of the editors and the document shepherd *much* easier.
It is probably worth reviewing the list of comments first. Some of them 
might be bogus.

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 12:17:10 -0700

Hi -

> From: "Alexey Melnikov" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Saturday, April 11, 2009 1:08 AM
> Subject: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt
...
> reviewer, so I suggest adding a forward reference here.
...

Ok with me.  Proposed text:
replace "scrutinized" with "scrutinized by the Language Subtag Reviewer
(see 3.2)"

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 12:22:20 -0700

Hi -

...
...

As a technical contributor, I agree that a little clarification would be helpful.
Your suggested text would be ok with me.

Randy

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Apr 2009 20:19:34 +0100

>replace "scrutinized" with "scrutinized by the Language Subtag Reviewer
Works for me.

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 12:25:55 -0700

Hi -

...

...
> >         reassigns a deprecated value in the registry.

As co-chair - we should make sure that the resolution of this issue and
tracker issue #40 (AD comment #7) are coordinated.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 12:30:51 -0700

Hi -

...
...

As a technical contributor, I agree with deleting the sentence.
The whole paragraph arose as a result of concerns about the
perception of the stability of the grammar.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 12:33:35 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Saturday, April 11, 2009 12:08 PM
> Subject: Re: [Ltru] AD review of draft-ietf-ltru-4646bis-21bis.txt
>
> Randy Presuhn wrote:
> 
> >Hi -
> >

They're already in the tracker. I actually prefer to have a complete
list, even if it turns out that some require little discussion.  The list
of open issues is available at http://trac.tools.ietf.org/wg/ltru/trac/report/1

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 12:42:14 -0700

Hi -

...
...

As a technical contributor...

Ewwww.

Our intention in the ABNF was *NOT* to describe the registry as a byte-stream,
but rather to describe it as a character stream.  I view the encoding of the
registry as UTF-8 (rather than UTF-16 or UTF-32 or EBCDIC :-) as a separate
matter from the ABNF, and think that trying to accomplish both in the
ABNF would only serve to confuse rather than enlighten.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 12:44:29 -0700

Hi -

...
...

As a technical contributor, I agree with the proposed change.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 12:50:56 -0700

Hi -

As co-chair - we should coordinate any changes we make here with the
resolution to issue #36 (AD comment #3).

...
> >         reassigns a deprecated value in the registry.

As a technical contributor, I agree that the two should be aligned.
Using "SHALL" here definitely makes sense.
I'd leave it to the folks who have had dealings with the relevant
agencies to comment on whether specifying a 90-day timeout
is necessary - there may be concerns about a need for flexibility.

Randy

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Apr 2009 20:51:53 +0100

>ABNF would only serve to confuse rather than enlighten.
In this case a comment saying that would be appreciated.

If you want to do both though, you can define CHARS using UTF-8 
sequences and add a comment that that corresponds to '%x21-10FFFF' 
Unicode range.

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 12:57:12 -0700

Hi -

...
...

I think the idea was to allow the language subtag reviewer to consider
requests that followed the spirit, if not the letter of the syntax.  Since
the LSR is not an automated process, and we do not want to introduce
artificial barriers to those needing language subtags, a little flexibility
is desirable.  Consequently, I think the SHOULD is ok - it's operational
advice, and failure to follow it to the letter won't necessarily cause any
problems at all.

Randy

---

From: John Cowan <[email-masked]>
Date: Sat, 11 Apr 2009 15:55:11 -0400

General disclaimer: I speak for myself, not for the WG.  When I say
"we", I'm reporting what I believe to be the facts.

> reviewers for the 4646bis?

Technically, only Michael is the Registry Reviewer.  Doug's role is that
of Imperial Chancellor.  :-)

> version of this document changes that"?)

No, it means "We guarantee that such subtags will never be registered
even if this document is revised."  A constraint on 4646bis is that
every tag that was well-formed in 4646 is still well-formed, so we
did not remove the grammar that allows tags like abc-def-ghi; however,
we give explicit permission for validators to reject them out of hand.

> Unless I am confused, I think this SHOULD NOT contradicts MUST NOT in 

I agree: 3.4 rule 16 should be MUST NOT.

> RFC 2119 keyword properly.

+1

> stated earlier in section 3.1.1:

Note that we don't use ABNF in quite the standard way: we use it to describe
sequences of characters rather than sequences of bytes, as is usual.
This is explained in the last paragraph of 2.1.

>   'Comments', and sometimes the 'Prefix' field.

+1

> below. Any reason why you don't want to specify deadline in this case?

+1

> (I.e. why is SHOULD used instead of MUST?)

+1

> confusing and will not match the reality.

In principle, IANA's change does not happen until after both 4646 and 4646bis
have been adopted (which is not the same as publication; publication usually
long postdates it), which is why the future is appropriate.

> modification/addition date). This way any change to the IANA registry 

This is a "shouldn't happen" situation, where at the time a modification
is made, the File-Date is later than the current date.  But if it does
happen, we never want to set the File-Date of the new version to be
earlier than the File-Date of the version being superseded.  That would
cause any entity trying to decide which of two versions to use to get
the wrong answer.

A great deal of the complexity of BCP 47, in any version, reflects
experience with the mistakes made over the years by IANA, the various
RAs and MAs, and ietf-languages.

> I think this needs an informative reference to MIME.

+1

> A pointer here to some case(s) would be appreciated here.

This is a political compromise between those who like extlangs and those
who don't, both of whom were very vehement in the WG.  We allow both
and we don't insist that one MUST be used.  It's better not to upset
the applecart here.

> I think use of MAY is improper here and I suggest changing it to "can"

+1

> You lost me here: what is "the value" and what is "the replacement tag" 

The input and the output, respectively, to the
preferred-value-normalization process.

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 13:05:03 -0700

Hi -

...
...

As a technical contributor...
the proposed fix works for me.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 13:18:31 -0700

Hi -

...

As a technical contributor...
I think the intent here is to handle a sequence of update requests
that arrive out of order.  (I frequently see delays of several hours
from IETF mailing lists, and things normally arrive thoroughly jumbled).
It would probably have been simpler to just say that it should always
simply be the date that the file was updated, and not talk about
the dates on the record(s) being added or updated.

Randy

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Apr 2009 21:16:12 +0100

>advice, and failure to follow it to the letter won't necessarily cause any
I understand and agree with the desire to be flexible.
However my understanding is that the request sent to IANA must be in the 
correct form. Maybe you should clarify that.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Apr 2009 21:17:24 +0100

>the dates on the record(s) being added or updated.
Agreed.

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 13:20:25 -0700

Hi -

...
...

As a technical contributor...
I'd prefer to simply delete the example.

Randy

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Apr 2009 21:23:37 +0100

>I'd prefer to simply delete the example.
I actually like the example. But this is up to the WG.

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 13:33:39 -0700

Hi -

...
...

As co-chair...
This point is at the intersection of a couple very contentious issues.
One is the question of whether the canonical form is stable over time,
and the other is the macrolanguage problem.  This language reflects
a compromise that I think leaves all parties to the debates equally
unhappy.  The reason for the "SHOULD" is that there are situations
where NOT doing the mapping would be operationally preferable.

As a technical contribtor...
Chinese and Arabic written materials are the "poster children" here,
especially when working with remove-from-right matching algorithms.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 13:36:54 -0700

Hi -

...
...

As a technical contributor...
I agree with the proposed change.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 14:03:01 -0700

Hi -

...
> >             the language tag.

As co-chair: I think we have a problem here.
In December 2008 we had lengthy discussion of whether
"extended language range" from RFC 4647 was the right
thing to use for prefixes.  The conclusion was that it was not.
I think we may have a similar problem here.

> >             That is, each of the subtags that appears

As a technical contributor...
I agree that the text as written might perhaps be described as
"obvious only if previously understood."  I'm not sure how to fix it.   

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 16:16:53 -0700

Hi -

> From: "John Cowan" <[email-masked]>
> To: "Alexey Melnikov" <[email-masked]>
> Sent: Saturday, April 11, 2009 12:55 PM
...
...

I have to agree with Alexey that some clarification is in order.
I wouldn't have come to the "will never be registered even if this
document is revised" from reading just what's in the I-D.  If we're
really really sure that's what we mean, I suggest replacing
"are invalid" with "are (and will always be) invalid".

Randy

---

From: Mark Davis <[email-masked]>
Date: Sat, 11 Apr 2009 17:45:57 -0700

agreed
Mark

On Sat, Apr 11, 2009 at 12:30, Randy Presuhn
<[email-masked]>wrote:

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

---

From: Mark Davis <[email-masked]>
Date: Sat, 11 Apr 2009 17:46:47 -0700

Agreed. (and this should be a MUST NOT)
Mark

---

From: Mark Davis <[email-masked]>
Date: Sat, 11 Apr 2009 17:49:03 -0700

agreed
Mark

---

From: Mark Davis <[email-masked]>
Date: Sat, 11 Apr 2009 17:50:26 -0700

I would rather keep examples; they are usually helpful in understanding the
text.
Mark

---

From: Mark Davis <[email-masked]>
Date: Sat, 11 Apr 2009 17:51:52 -0700

Yes, it needs to remain a SHOULD (not changed to MUST).
Mark

---

From: Mark Davis <[email-masked]>
Date: Sat, 11 Apr 2009 17:52:08 -0700

agreed
Mark

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Apr 2009 18:00:36 -0700

Hi -

> From: "Mark Davis" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Saturday, April 11, 2009 5:50 PM
> Subject: Re: [Ltru] Issue #44 (AD comment #11) informative reference to MIME
>

I could live with adding the necessary informative reference if folks
prefer to keep the example.

Randy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 12 Apr 2009 18:33:00 +0900

In my impression, this was not specifically the Language Subtag 
Reviewer, but the overall review process. But of course the Language 
Subtag Reviewer is a very important part of that process, and the 
ultimate arbiter. So I guess the proposed text should be fine. We don't 
have a (sub)section for the review process as such to point to.

Regards,    Martin.

On 2009/04/12 4:17, Randy Presuhn wrote:
> Hi -
>
>> From: "Alexey Melnikov"<[email-masked]>
>> To: "LTRU Working Group"<[email-masked]>

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 12 Apr 2009 18:57:19 +0900

Hello Alex,

>>> definition of CHARS doesn't match the requirement to use UTF-8
>>> encoding stated earlier in section 3.1.1:
>>>

There is nothing wrong in using the ABNF to describe characters rather 
than bytes. This has been done in the past. In some cases, it's actually 
the only solution, because the 'encoding' may not be limited to e.g. 
UTF-8, but also include things such as paper. For an example, please see 
http://tools.ietf.org/html/rfc3987#section-2.2, in particular the 
ucschar and iprivate productions.

Befor the actual ABNF, RFC 3987 uses the following text:

                                                       The syntax of this
    ABNF is described in [RFC2234].  Character numbers are taken from the
    UCS, without implying any actual binary encoding.  Terminals in the
    ABNF are characters, not bytes.

I hope this provides enough of a precedent. When drafting RFC 3987, I 
carefully checked the ABNF spec, to make sure this is the way this works.

For our draft, I suggest replacing

with something like:

    The format of the registry is described by the ABNF [RFC5234] below.
    Character numbers are taken from the UCS. Terminals in the ABNF are
    characters, not bytes.

The information about the file being in UTF-8 is higher up in the same 
subsection, so I don't think it needs to be repeated here. But if you 
think it's better to add it, we probably can do that.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 12 Apr 2009 19:15:04 +0900

[co-chair/shepherd hat on]

Okay, let's add the reference. This is RFC 2046 (Section 5.1.4, but I 
don't think a section number is necessary).

Regards,    Martin.

On 2009/04/12 10:00, Randy Presuhn wrote:
> Hi -
>
>> From: "Mark Davis"<[email-masked]>
>> To: "Alexey Melnikov"<[email-masked]>
>> Cc: "Randy Presuhn"<[email-masked]>; "LTRU Working Group"<[email-masked]>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 12 Apr 2009 19:15:19 +0900

>> advice, and failure to follow it to the letter won't necessarily cause

I agree with Randy and Doug that this should stay a SHOULD. If we view 
this as a protocol between the submitter and the reviewer(s)/list, a 
MUST is not appropriate because interoperability is possible otherwise, 
and because there might be good reasons (e.g. the submitter being an 
expert for a specific language, but not an expert in reading RFCs) to 
not be able to follow every last detail.

> correct form. Maybe you should clarify that.

That's already done, a bit lower (currently on the same page, at the 
bottom, although that might change):

    Before forwarding any registration to IANA, the Language Subtag
    Reviewer MUST ensure that all requirements in this document are met.
    This includes ensuring that values in the 'Subtag' field match case
    according to the description in Section 3.1.4 and that 'Description'
    fields are unique for the given record type as described in

    Section 3.1.5.  The Reviewer MUST also ensure that an appropriate
    File-Date record is included in the request, to assist IANA when
    updating the registry (see Section 5.1).

I don't think we need more; it's a fate of long and complicated 
documents that not everything is said in every place where a reader 
might look for it.

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 12 Apr 2009 19:15:37 +0900

Alex - Do you want a change here, or does "Agreed" mean that you are 
fine with the explanation?

Others: Can somebody propose text for a change?

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 12 Apr 2009 19:17:45 +0900

+1 (hats off).   Regards,   Martin.

On 2009/04/12 9:52, Mark Davis wrote:
> ------------------------------------------------------------------------
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 12 Apr 2009 11:46:32 +0100

> don't think a section number is necessary).

This would be fine with me.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 12 Apr 2009 11:48:26 +0100

> fine with the explanation?

I would like to see a change/clarification.
I was agreeing with:

I think this procedure is much simpler.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 12 Apr 2009 13:45:21 +0100

Martin J. Dürst wrote:

> than bytes.

I didn't say or wanted to imply that it was wrong.
My concern is that a naive reader would assume that UTF-8 doesn't need 
to be applied to the grammar.

> This has been done in the past. In some cases, it's actually the only 
> solution, because the 'encoding' may not be limited to e.g. UTF-8, but 
> also include things such as paper. For an example, please see 

Yes, that would be much better.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 12 Apr 2009 13:51:40 +0100

Martin J. Dürst wrote:

>>> artificial barriers to those needing language subtags, a little
>>> flexibility is desirable. Consequently, I think the SHOULD is ok - 
>>> it's operational
>>> advice, and failure to follow it to the letter won't necessarily cause
>>> any problems at all.
>>
> MUST is not appropriate because interoperability is possible 
> otherwise, and because there might be good reasons (e.g. the submitter 
> being an expert for a specific language, but not an expert in reading 
> RFCs) to not be able to follow every last detail.

Ok.

>    Reviewer MUST ensure that all requirements in this document are met.

(Pedantic) This still means that the Reviewer might violate the SHOULD 
while complying with the MUST.

> documents that not everything is said in every place where a reader 

Ok.

---

From: Mark Davis <[email-masked]>
Date: Sun, 12 Apr 2009 09:36:06 -0700

Thanks; I'd forgotten that the Reviewer has a MUST further down. Given that,
a SHOULD is fine for the submitter.
Mark

On Sun, Apr 12, 2009 at 03:15, "Martin J. Dürst" <[email-masked]>wrote:

>>> flexibility
>>> any
> I agree with Randy and Doug that this should stay a SHOULD. If we view this
> as a protocol between the submitter and the reviewer(s)/list, a MUST is not
> appropriate because interoperability is possible otherwise, and because
> there might be good reasons (e.g. the submitter being an expert for a
> specific language, but not an expert in reading RFCs) to not be able to
> follow every last detail.
>
> I don't think we need more; it's a fate of long and complicated documents
> that not everything is said in every place where a reader might look for it.
>
> Regards,    Martin.
> --

---

From: John Cowan <[email-masked]>
Date: Sun, 12 Apr 2009 14:03:58 -0400

>  the dates on the record(s) being added or updated.

Simpler, yes; but it has bad knock-on effects.  If IANA erroneously creates a version of
the Registry with a File-Date in the future (and the Official Doug has assured us
that this does happen), then the next update may create a situation where the File-Date
of the new version is less than the File-Date of the old version.  A process that
relies on the File-Date to decide whether to update its cached copy of the Registry
would be deceived into assuming the old version is newer than the new version.

The current algorithm is more complicated, but guarantees (provided the dates on the
updated items are correct, of course) that the File-Date is monotonically increasing.

I strongly object to changing the current algorithm.

-- 
First known example of political correctness:   John Cowan
After Nurhachi had united all the other         http://www.ccil.org/~cowan
Jurchen tribes under the leadership of the      [email-masked]
Manchus, his successor Abahai (1592-1643)
issued an order that the name Jurchen should       --S. Robert Ramsey,
be banned, and from then on, they were all           The Languages of China
to be called Manchus.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 12 Apr 2009 19:14:25 +0100

>would be deceived into assuming the old version is newer than the new version.
If that is one of the goals, then Ok. I wish all requirements are 
properly documented.

>I strongly object to changing the current algorithm.
I am not sure the current algorithm is correctly (or clearly) documented.
What would be result of the algorithm in the following case:

1). Update 1 with File-Date A, such as A > I1 (where I1 is IANA 
File-Date before the update 1)

2). Update 2 with File-Date B, B < A

?

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 12 Apr 2009 14:36:27 -0700

Hi -

> To: "Martin J. Dürst" <[email-masked]>
> Sent: Sunday, April 12, 2009 5:51 AM
> Subject: Re: [Ltru] Issue #41 (AD comment #8) section 3.5 SHOULD vs MUST
...
...

The key point is that the SHOULD applies to the submitter; the MUST
applies to the reviewer.

Randy

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Apr 2009 22:51:46 +0100

Folks,
The IETF LC for the document has ended and I am waiting for a new 
revision that addresses my issues before requesting IESG to review the 
document.

Thank you,
Alexey

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 29 Apr 2009 14:54:04 -0700

(editor hat on) It's in progress and should be completed for WG review tonight.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alexey Melnikov
> Sent: Wednesday, April 29, 2009 2:52 PM
> To: LTRU Working Group