Subject: RE: [Ltru] -01 nits

From: "Addison Phillips" <[email-masked]>
Date: Tue, 26 Apr 2005 13:19:26 -0700

Comments inline.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Frank Ellermann
> Sent: 2005?4?25? 20:13
> To: [email-masked]
> Subject: [Ltru] -01 nits
> 
> Hi, some observations in draft -01 in no particular order:
> 
> * [7] (Unicode 4) is not used.
>   Please delete this normative reference, [6] is good enough.
[Addison Phillips] 

Stale reference, but I recycled it as informative elsewhere.
> 
> * In chapter 2.1 "UTF-16LE" is not explained.
>   Please add [RfC 2781] as informative reference.
[Addison Phillips] 

Okay. Which is where I recycled Unicode and also refer to RFC2781.
> 
> * [13] (IETF-ICANN MoU about IANA)
>   Please delete this "normative" reference to an MoU-FYI.
>   Maybe use [RfC 2028] (BCP 11) as a reference to explain "IANA",
>   you already have it as [10] elsewhere.
[Addison Phillips] 

~sigh~ I put this in at someone's urging and can replace it.
> 
> * [16] (RfC 3978) is not used.
>   Please delete this normative reference, the boilerplates
>   work without it.
[Addison Phillips] 

Agreed.
> 
> * In chapter 3.1 replace the URL of XML 1.0 3rd ed. by the
>   generic URL of the latest XML 1.0 edition.
[Addison Phillips] 

Agreed. Done. Also fixed the specific URL (in the eref)
> 
> * Several "2-character code", "3-character code", "4-character subtags":
>   Using "alpha-2 code" etc. would be clearer and shorter where the ABNF
>   dictates 2ALPHA etc.
[Addison Phillips] 

I replaced all of these with the number spelled out (e.g. "two character" instead of "2-character"). Using plain English is preferable (to me) to using more mechanical looking text.
> 
> * There's still a *("-" extlang) in the ABNF, it should be at most one
>   ["-" extlang].
[Addison Phillips] 

No, since there is no restriction on how many extlangs there can be currently and the grammar permits them. We don't know how they will ultimately be used, so I am a bit loathe to remove the repeating aspect (no matter that it greatly complicates processing). 

If a consensus can be built to limit them then I will change the ABNF and text in draft-02. (I would favor limiting them to one occurrence).
> 
> * In chapter 2.1.1:  "In practice, this limits most tags to a sequence
>   of four subtags, and thus a length of 35 (excluding any extensions":
>   This limit is 8+(1+4)+(1+3)+(1+8)= 26 without extlang and 4 subtags.
>   With extlang it's only 25 = 3+(1+3)+(1+4)+(2+3)+(1+8).
[Addison Phillips] 

Okay. I didn't include the math, I put instead:

<t>In particular,  variant subtags SHOULD be used only with their recommended prefix.  In practice, this limits most tags to a sequence of four subtags, and
thus a maximum length of 26 characters (excluding any extensions or private use sequences). This is because subtags are limited to a length of eight characters and the extlang, script, and region subtags are limited to even fewer characters. See <xref target="choice"></xref> for more information on selecting the most appropriate Language Tag.</t>
> 
> * In chapter 2.1.1:  "Any such limitation MUST be clearly documented,
>   and such documentation SHOULD include the disposition of any longer
>   tags  (for example, whether an error value is generated or the
>   language tag is truncated).  If truncation is permitted it SHOULD
>   NOT permit a subtag to be divided."
> 
>   Proposed new text:  "Any limitation SHOULD be clearly documented.
>   Tags SHOULD NOT be truncated, but removing complete subtags right
>   to left MAY be permitted."
[Addison Phillips] 

I'd prefer to keep the MUSTard on the length limitation (it isn't that onerous an item, if you think about it: anything that limits the length will have to say what the limit is, no?). 

> 
> * In chapter 2.2.1:  7. The single character subtag 'i' is used by
>   some grandfathered tags (see Section 2.2.8) such as "i-klingon"
>   and "i-bnn".
>   Please replace the "almost" deprecated i-klingon by i-default.
[Addison Phillips] 

i-klingon was chosen in part because it is deprecated, not just because it was grandfathered.
> 
> * In chapter 2.2.2:  Please replace all "subtags" by "subtag".
>   Please remove "3. There MAY be any additional number of
>   extended language subtags."  At most one extlang, otherwise
>   it doesn't fly with RfC 2231 / 2047.
[Addison Phillips] 

See above note about extlang. If there is consensus I will change it.
> 
> * In chapter 2.2.7:  "Users who wished to utilize SIL Ethnologue".
>   Please delete this example, it muddies the water for ISO 639-3.
[Addison Phillips] 

Yes, but I need a replacement example. Want to suggest one?
> 
> * The ABNF layout in 3.1 is ugly, the main ABNF is better, please
>   use the same xml2rfc trick (artwork ?) as in 2.1:
> 
>   registry   = record *( "%%" CRLF record )
>   record     = 1*( field-name *SP ":" *SP field-body CRLF )
>   field-name = 1*( ALPHA / DIGIT / "-" )
>   field-body = *( ASC-char / LWSP )
>   ASC-char   = %x21-25 / %x27-7E / UNI-char    ; AMPERSAND is %x26
>   UNI-char   = "&#x" 2*6HEXDIG ";"
[Addison Phillips] 

Okay. It is an artwork, I just haven't cleaned it up.

Here is my cleanup:

registry   = record *("%%" CRLF record)
record     = 1*( field-name *SP ":" *SP field-body CRLF )
field-name = *(ALPHA / DIGIT / "-")
field-body = *(ASCCHAR/LWSP)
ASCCHAR    = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26
UNICHAR    = "&#x" 2*6HEXDIG ";"

Validated the results cleanly.
> 
>   This fixes the reported "no %% in the first / last line" problem.
>   The minimal length of a field-name should be one, not zero.
>   It also replaces the undefined NUM by DIGIT, and %x2D by "-".
[Addison Phillips] 

Okay. NUM is defined somewhere, but I replaced with DIGIT for consistency's sake.
> 
>   In theory a field-name starting or ending with a "-" would be a
>   bad idea, and a DIGIT in a field-name is also strange, but OTOH
>   we don't want to reinvent "ldh-string" for a known set of names.
[Addison Phillips] 

Exactly.
> 
> * Please delete the File-Date example or get rid of the first "%%":
>   %%
>   File-Date: 2004-06-28
>   %%
[Addison Phillips] 

Already done.
> 
> * Another proposal for the registry ABNF:
> 
>   registry    = record *( "%%" CRLF record )
>   record      = 1*( field CRLF )
>   field       = type / timestamp / reference / explanation
>   type        = ( subtagttype / tagtype ) 1*SP tagtext
>   subtagtype  = "Language:" / "Extlang:" / "Script:"
>               / "Region:" / "Variant:"
>   tagtype     = "Grandfathered:" / "Redundant:"
>   timestamp   = ( "File-Date:" / "Added:" / "Deprecated:" ) 1*SP date
>   reference   = ( "Canonical:" / "Suppress-Script:"
>                 / "Recommended-Prefix:" ) 1*SP tagtext
>   explanation = ( "Description:" / "Comment:" ) 1*SP text
>   date        = 4DIGIT "-" 2DIGIT "-" 2DIGIT    ; see RfC 3339
>   tagtext     = 1*( ALPHA / DIGIT / "-" )       ; note no WSP
>   text        = *SP ":" *( ASC-char / LWSP )    ; note folding WSP
>   ASC-char    = %x21-25 / %x27-7E / UNI-char    ; AMPERSAND is %x26
>   UNI-char    = "&#x" 2*6HEXDIG ";"
[Addison Phillips] 

That's really different and probably quite correct. But I'm not going to create a big ugly ABNF-and-full-text-edit before sending draft-01 off to I-D land. Let's dicuss for draft-02.
> 
>   This is quite different from the old ABNF, no more SP before the
>   COLON, at least one SP after the COLON, no "folding" for a date or
>   tagtext, "folding" only for a (long) Description: or a Comment:,
>   no UNI-char or special char in tagtext, a date syntax that needs
>   no further explanation (one example will do).
> 
>   Based on this ABNF chapter 3.1 could be much shorter and clearer.
>   It's not more necessary to dig through 3.1 to find all field names.
> 
> IMHO you could submit snapshots of complete drafts more often,
> and you also don't need Randy or Martin for a future -02, etc.
[Addison Phillips] 

I would like to submit them more often, but we needed to get through a big edit first that solved most problems first. In addition: we are behind schedule and I really REALLY want to finish this work. I am hoping that draft-02 or draft-03 is a Last Call draft (which we can approach by solving the remaining substantive issues).

At present I recognize one substantive issue that we need to resolve, namely the handling of country code changes. After that we are nearly done but for nits, unless I am missing something.

Thanks for your help.
[Addison Phillips] 

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 27 Apr 2005 02:22:49 +0200

Addison Phillips wrote:

 [IETF-ICANN MoU about IANA]
> ~sigh~ I put this in at someone's urging and can replace it.

If you like [RfC 2860] you could also move it to "informative".
BTW, have you ever tested <?rfc symrefs="yes" ?> with xml2rfc ?

 ["2-character code" vs. "alpha-2 code"]
> I replaced all of these with the number spelled out (e.g.
> "two character" instead of "2-character"). Using plain
> English is preferable (to me) to using more mechanical
> looking text.

Plain English is fine,  I also say byte when I mean octet, etc.
But you said that you're an "Unicadet", so I'm a bit surprised
that you prefer "character" when it's only A..Za..z, also known
as ALPHA.

>> it should be at most one ["-" extlang].

> No, since there is no restriction on how many extlangs there
> can be currently and the grammar permits them

That's not possible for the Internet.  Maybe delete ISO 639-3
and eliminate extlang completely if this scheme doesn't work
for language tags, or if it's unclear at the moment.

OTOH Peter's example indicates that they might get away with at
most two extlang as in aaa-bbb-ccc, and that's of course okay,
the worst "normal" case would then be length 29 instead of 26.

> I am a bit loathe to remove the repeating aspect (no matter
> that it greatly complicates processing).

I can understand that you don't like to limit it, and besides
RfC 2231 is a PITA.  If you'd get an ACK from Bruce or Ned for
the "unlimited extlang" it's okay.

> (I would favor limiting them to one occurrence).

That's apparently a hot issue for draft -02

> thus a maximum length of 26 characters (excluding any
> extensions or private use sequences). This is because
> subtags are limited to a length of eight characters and the
> extlang, script, and region subtags are limited to even
> fewer characters.

Yes, that's clear.  29 for two extlangs won't be a showstopper.

 [MUST be clearly documented]
> I'd prefer to keep the MUSTard on the length limitation (it
> isn't that onerous an item, if you think about it: anything
> that limits the length will have to say what the limit is,
> no?).

No, RfC 2231 is unfortunately not that clear, you have to read
it in conjunction with RfC 2047 to find the hard limit 76, then
you need the worst case of a charset name in the IANA registry,
plus 8 =?*?Q??=, some calculations for the =?*?B??= case, and
a worst case of a header field in Usenet (maybe), and finally
the result is _not_ clear, it depends on too many variables.

You cannot say "MUST be clearly documented" if you know a case
where that's not true.  3066bis wants to be compatible with
RfC 2231 / 2047.

But that nit was more about "it SHOULD NOT permit a subtag to
be divided":  I wanted to propose a clearer "if you truncate
tags remove complete subtags right to left".  Apparently my
proposal wasn't clear, Mark thought that I plan to maim poor
tags, actually I wanted to protect them as far as possible ;-)

 [replace the "almost" deprecated i-klingon by i-default]
> just because it was grandfathered.

It's a bad example because it's "almost" deprecated.  I didn't
know that it should be replaced by "tlh" because the IANA page
doesn't say so, and the last time I've seen it as an example on
a new W3C page was this year.  <OT> and it was in an argument
with Bruce and Ned about RfC 2231, the status of "i-klingon"
cost me a point in this debate. </OT>

 [Ethnologue]
> I need a replacement example. Want to suggest one?

No idea.  Maybe fr-US-x-cajun if it has no proper code.

> Here is my cleanup:
[...]
> Validated the results cleanly.

Better.  I'd avoid "shouting" (upper case) where possible, but
that's only a matter of taste.

 [ABNF variant eumerating field types ; date / tagtext / text]
> That's really different and probably quite correct. But I'm
> not going to create a big ugly ABNF-and-full-text-edit before
> sending draft-01 off to I-D land. Let's dicuss for draft-02.

Sure, I thought that's what I do.  But if you have fixed some
minor points before submitting -01 it's also fine, I only have
to replace pre-01 by the real -01 in my public I-D collection.

> In addition: we are behind schedule and I really REALLY want
> to finish this work.

Of course we are, it's the purpose of this WG to solve a few
real problems, and Doug can't invent "Suppress-Scripts" with a
random generator.

BTW, there's a problem in pre-01 about "Supress-Script" (4.2):

First you had "MUST NOT ... unless ...".  Then I wanted a short
"SHOULD NOT ..." without "unless".  Then Randy decided that the
consensus is something with "MUST NOT".

But now you have a "SHOULD NOT ... unless ...", that's exactly
the opposite of what Randy said, it's also not my "SHOULD NOT".

You also didn't add the rationale for this "MUSTard" (I like
this pun :-) i.e. existing RfC 3066 content and tools.

> I recognize one substantive issue that we need to resolve,
> namely the handling of country code changes.

That's also about "canonical" and "deprecated".  As it is we'd
get a more or less nice registry at date B (ignoring four lost
regions after date-A), but it would soon deteriorate again for
some future 3166-1 codes.
                           Bye, Frank