Subject: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft

From: "Doug Ewell" <[email-masked]>
Date: Tue, 16 Aug 2005 06:52:03 -0700

> No further requests to change the ABNF in draft-registry or
> draft-matching should be entertained unless it can be demonstrated
> that the existing ABNF (a) contradicts the text of the draft, (b)
> fails when run through a validator, or (c) must be changed to reflect
> a new technical decision (which we should not be having at this point
> anyway).  Changes to the ABNF for cosmetic reasons should be
> discouraged.  "Contradiction" between text and ABNF refers only to
> context-free syntax.

> :: Further, I like to have the wildcard as the last alternative (like
> :: it was).
> :: AND, the [] around extlang are superfluous, as I think Frank
> :: already pointed out FOR THE -REGISTRY DRAFT, with an "of course"
> :: from Addison.

Oh well, I tried.  :-(

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

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

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 16 Aug 2005 12:11:56 -0700

I don't think it makes a difference to the registry draft. We might change the matching draft (which is not covered by the closure of the last call and the topic of this thread).

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 Randy Presuhn
> Sent: 2005?8?16? 12:10
> To: [email-masked]
> Subject: Re: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft
> 
> Hi -
> 
> Rather than artificially re-opening the WG last call, I suggest that if
> the
> poster believes strongly that this is important, it can be submitted
> as an IETF last call comment.  In the meantime, the WG of course
> is free to determine whether there is merit to this comment, in
> order to minimize the time required to process the potential IETF
> last call comment, if it is made.  That way, if necessary, we can
> include an appropriate note to the IESG in our publication request.
> 
> Randy, ltru co-chair
> 
> > From: "Frank Ellermann" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Tuesday, August 16, 2005 11:50 AM
> > Subject: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft
> >
> > >  extlang   = *2("-" 3ALPHA) ("-" ( 3ALPHA / "*"))
> > [...]
> > >  extlang   = *3("-" 3ALPHA)
> > >            / ( *2("-" 3ALPHA) "-*" )
> >
> > Oops, there is a major difference, the latter can be empty,
> > and then the square brackets would be in fact unnecessary
> > in both grammars as Kent and you said.  Still okay to keep
> > them.  For Kent's other vision "as similar a possible" the
> > latter is better, it preserves "can be empty".
> >
> > Switching to hardcore nitpicking mode, what we really want
> > is square brackets combined with 1*3( "-" 3ALPHA ) instead
> > of *3( "-" 3ALPHA ) in the registry draft => "never empty".
> >
> > If "somehow" this "missing" 1 "appears" after your AUTH48
> > in 3066bis it would be a major step forward for humankind
> > and the "lilly-guild" (not talking about Bruce).  Bye, Frank
> >
> >
> >

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 16 Aug 2005 13:45:53 -0700

RTFID (read the fine internet-draft).

The name "range" is not our invention. It has existed for quite some time in RFCs 1766 and 3066. Renaming it to pattern would likely confuse existing users?

The matching draft spells out what various kinds of range such as "sr-*" mean. 

The ranges are not ambiguous; the different matching schemes, however, treat some missing values differently.

It is the case that ranges have an in-built preference for remove-from-right matching and that there is no way to say "en-US (no script) but not en-xxxx-US (any script)". The matching draft is not as mature as the other work here, and comments and ideas I think are very much welcome.

Addison

Addison P. Phillips

> Behalf Of Kent Karlsson
> Sent: 2005?8?16? 12:59
> Frank got the analysis of my message right.
> 
> Yes, I want the grammars as similar as ever possible,
> but still combinable. Frank is also right about the
> [] and emptyness possibility.
> 
> B.t.w. I don't like the term "range" for something
> that is more like what is usually called a "pattern".
> 
> Further, in a language tag pattern like
> 
> sr-*
> 
> there is no way of telling if the * stands for
> "any 'extended language'", "any script", "any region",
> or "any variant".
> 
> But for
> 
> sr-*-Cyrl
> 
> the * stands for "any 'extended language'".
> 
> While in
> 
> sr-*-1900
> 
> the * may stand for "any 'extended language'",
> "any script", or "any region". (But not combined?)
> 
> 
> Does this matter? Or are the patterns on purpose ambiguous?
> If not, the different kinds of wildcards need differing syntax,
> e.g. a script wildcard could be *s, and a region wildcard could
> be *r (or whatever other differing syntax strikes your fancy).
> 
>    /kent k
> 
> 
>

---

From: "Peter Constable" <[email-masked]>
Date: Tue, 16 Aug 2005 13:57:06 -0700

> From: [email-masked] [mailto:[email-masked]]
On Behalf Of
> Addison Phillips

> The name "range" is not our invention. It has existed for quite some
time in RFCs
> 1766 and 3066. Renaming it to pattern would likely confuse existing
users?

Absolutely. Moreover, that term is used in dependent protocol
specifications such as HTTP (RFC 2616 and its precursors).

Peter Constable

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 17 Aug 2005 09:03:21 -0700

Correct. As soon as there's one star, it is available for all positions... up to the next concrete subtag.

Addison

Addison P. Phillips

> Behalf Of Frank Ellermann
> Sent: 2005?8?16? 18:03
> To: [email-masked]
> Addison Phillips wrote:
> > I hope this summary helps.
> 
> Yes, thanks.  So we have sr-* == sr-*-*-*-*, as soon as
> there's one star it's for all available positions.  Same
> idea for sr-*-1900 == sr-*-*-*-1900.
> 
> But sr-*-CYRL and sr-*-CYRL-*-* are different, correct ?
> 
>                        Bye, Frank
> 
> 
>