Subject: RE: [Ltru] Re: Reference lists; AND ABNF GRAMMARS

From: "Addison Phillips" <[email-masked]>
Date: Thu, 21 Jul 2005 15:59:22 -0700

Kent,

Your ABNF is very clear and seems, at first look, to represent an improvement. But...

I'm inclined not to make these changes, not because they aren't more beautiful or even desirable, but simply because they are unnecessary changes at this late date.

If a lot of folks weigh in in-favor for the change, I'll do it, otherwise, this is a Last Call and the changes are editorial, not substantive. Since they affect the ABNF, I'd rather see a show of support for the change including recognition that it doesn't require an additional last call time period.

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: Kent Karlsson [mailto:[email-masked]]
> Sent: Thursday, July 21, 2005 3:46 PM
> To: Addison Phillips
> Cc: Mark Davis; Doug Ewell; LTRU Working Group
> Subject: RE: [Ltru] Re: Reference lists; AND ABNF GRAMMARS
> 
> > There was a substantive flaw as noted. I fixed it without
> > otherwise modifying the ABNF. I don't intend to modify the
> > ABNF further without working group consensus.
> >
> > I *will* update the matching ABNF with some of the
> > suggestions, since some of the ABNF is quite obscure, but the
> > matching draft isn't in last call.
> >
> > Addison
> 
> 
> I think it is very important that the -registry and the -matching
> grammars are as similar as ever possible. Otherwise there will be
> needless confusion. I'm a bit surprised that they are not at present
> in "synch".
> 
> I've looked at the comments from Addison and Doug, and the
> "as parallel as I can get them" grammars for -registry and -matching
> are given below. This without doing spurious name changes. However,
> I've added some nonterminals for clarity. I hope I have chosen names
> for the (new) nonterminals in such a way that they are at least not
> misleading.
> 
> This means changing also the -registry grammar.
> 
> =========================================================
> %% For -registry
> 
> Language-Tag    = langtag
>                 / privateuse         ; private use tag
>                 / grandfathered      ; grandfathered registrations
> 
> langtag         = (lang
>                    ["-" script]
>                    ["-" region]
>                    *("-" variant)
>                    *("-" extension)
>                    ["-" privateuse])
> 
> lang            = stdlang
>                 / stdlangext
>                 / reglang
> 
> stdlang         = 2*4ALPHA           ; shortest ISO 639 code
> 
> stdlangext      = stdlang
>                   1*3("-" extlang)
>                                      ; reserved for future use
> 
> reglang         = 5*8ALPHA           ; registered language subtag
> 
> extlang         = 3ALPHA
> 
> script          = 4ALPHA             ; ISO 15924 code
> 
> region          = stdregion
>                 / unregion
> 
> stdregion       = 2ALPHA             ; ISO 3166 code
> 
> unregion        = 3DIGIT             ; UN region number
> 
> variant         = regvariant
>                 / genvariant
> 
> regvariant      = 5*8alphanum        ; registered variant
> 
> genvariant      = (DIGIT 3alphanum)  ; generic variant
> 
> extension       = singleton 1*("-" (2*8alphanum))
> 
> singleton       = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT
>                 ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9"
>                 ; Single letters: x/X is reserved for private use
> 
> privateuse      = ("x"/"X") 1*("-" (1*8alphanum))
> 
> grandfathered   = 1*3ALPHA 1*2("-" (2*8alphanum))
>                                     ; grandfathered registration
>                                     ; Note: i is the only singleton
>                                     ; that starts a grandfathered tag
> 
> alphanum        = (ALPHA / DIGIT)   ; letters and numbers
> 
> =========================================================
> 
> %% for -matching
> 
> Language-Range  = langrange
>                 / privateuse         ; private use tag
>                 / grandfathered      ; grandfathered registrations
> 
> langrange       = (lang
>                    ["-"script]
>                    ["-" region]
>                    *("-" variant)
>                    ["-" privateuse])
> 
> lang            = stdlang
>                 / stdlangext
>                 / reglang
>                 / "*"
> 
> stdlang         = 2*4ALPHA           ; shortest ISO 639 code
> 
> stdlangext      = stdlang
>                   *2("-" extlang)
>                   ("-"(extlang / "*"))
>                                      ; reserved for future use
> 
> reglang         = 5*8ALPHA           ; registered language subtag
> 
> extlang         = 3ALPHA
> 
> script          = 4ALPHA             ; ISO 15924 code
>                 / "*"
> 
> region          = stdregion
>                 / unregion
>                 / "*"
> 
> stdregion       = 2ALPHA             ; ISO 3166 code
> 
> unregion        = 3DIGIT             ; UN region number
> 
> variant         = regvariant
>                 / genvariant
>                 / "*"
> 
> regvariant      = 5*8alphanum        ; registered variant
> 
> genvariant      = (DIGIT 3alphanum)  ; generic variant
> 
> privateuse      = ("x"/"X") 1*("-" (1*8alphanum))
> 
> grandfathered   = 1*3ALPHA 1*2("-" (2*8alphanum))
>                                     ; grandfathered registration
>                                     ; Note: i is the only singleton
>                                     ; that starts a grandfathered tag
> 
> alphanum        = (ALPHA / DIGIT)   ; letters and numbers
> 
> =========================================================
> 
> 		/kent k
> 

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

---

From: r&d afrac <[email-masked]>
Date: Fri, 22 Jul 2005 02:57:35 +0200

Dear Kent,
I am totally unable and definitely not interested in understanding the ABNF 
of a proposition I support (if it is a useful to some) as a complement of 
RFC 3066, but which will be blocked at some stage if it claims to be the 
replacement of RFC 3066, the BCP 47 and a exclusive and excluding standard 
for the Internet leading to a probable split of the Internet.

Addison is not excited to upgrade the ABNF, however beautiful or desirable 
it may be, because the "late date", says he. This seems an odd reason in a 
Last Call which is supposed to permit just that . Except if you consider 
the Varsaw ISO meeting, where Addison, Mark and Peter will quote the Draft 
in the appendixes of the ISO 639-3 and ISO 639-4 drafts. An RFC/BCP would 
have been better, but a timely unanimous support by the WG-Ltru through its 
WGLC is not that bad (even if it is not the case and even if everyone 
(will) know(s) it).

After having been clear on the political issue, I think no one will suspect 
me to support the proposed Open Source exclusion, nor will be able to 
accuse me not to have disclosed it and fought it, to try to obtain a Draft 
truly in favor of an Internet open use, in the respect of non analysed 
Charter of this WG. This is why I think I can today support Addison's 
proposition and favor a status quo on the text (and ABNF) at this stage. 
Because of this last point: everyone knows about it. And because of the 
reason given by Addison.

However, if you truly believe that the current ABNF is confusing and 
different between the two drafts and that the intelligibility of the Draft, 
whatever its other (de)merits absolutely call for the correction of the 
ABNF you propose, I will support you and call everyone to support you.

In this case, I remind you that the Open Source, innovation and reasonable 
other uses exclusion format ( privateuse      = ("x"/"X") 1*("-" 
(1*8alphanum)) ) is irrelevant as in violation with the Charter's 
requirement to correct RFC 3066's errors and with a documented project and 
beginning common practices quoted in this WG, and now running code. It 
should be modified to support a much larger alphanum size (we currently 
supports a memory size of 256) including characters such ".:#/?=".

Thank you for your comments.
jfc

At 00:59 22/07/2005, Addison Phillips wrote:
>I'm inclined not to make these changes, not because they aren't more 
>beautiful or even desirable, but simply because they are unnecessary 
>changes at this late date.
>
>If a lot of folks weigh in in-favor for the change, I'll do it, otherwise, 
>this is a Last Call and the changes are editorial, not substantive. Since 
>they affect the ABNF, I'd rather see a show of support for the change 
>including recognition that it doesn't require an additional last call time 
>period.
>
>Addison
>
>Addison P. Phillips