Subject: RE: [Ltru] Re: non-terminal names

From: "Kent Karlsson" <[email-masked]>
Date: Thu, 9 Feb 2006 22:34:37 +0100 (CET)

Frank Ellermann wrote:

> 2.1 has its own idea of <language-tag>, but that won't fly
> with your concept, a <language-tag> is already defined in
> 3066bis.  We could just s/language/basic/ in 2.1:
>
>    basic-range    = basic-tag / "*"
>    basic-tag      = 1*8[alphanum] *["-" 1*8alphanum]

This is entirely suspicious, due to the square brackets;
the second production is equivalent to:
basic-tag      = *8alphanum  *( "-" 1*8alphanum )
which produces both the empty string as well as
strings like  -a, neither of which I think were intended.
I understand this production for language tags is intended
to be rather "loose", producing strings that aren't language tags.
But isn't this too "loose"? RFC 2616 sais:
language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

So I think that
basic-tag      = 1*8[alphanum] *["-" 1*8alphanum]
should be
basic-tag      = 1*8alphanum *("-" 1*8alphanum)

> Do we really want to mess with the 2616 and 3066 concept of
> a <Primary-subtag> ?  IMHO we can keep it as it always was:
>
>    basic-range    = basic-tag / "*"
>    basic-tag      = 1*8ALPHA *( "-" 1*8alphanum )

2616 appears to only allow 'alpha's, no 'num's... (but 3066 allows it in
the subtags, just as 3066bis).

> Besides the old 2.1 ABNF in the matching draft -09 is wrong:
>                        v        v
>    language-tag   = 1*8[alphanum] *["-" 1*8alphanum]
>
> The <Primary-subtag> isn't optional... ;-)

(Ok, so we agree; not using a fixed-width font for my emails made
me not see what you were trying to say here on the first reading.)

> Now the fun stuff, <extended-language-range> in chapter 2.2.
>
> Apparently we could get away with adding "-range" everywhere,
> I'd like that better than your "-pat" everywhere.

Either. Though they are really non-terminals producing "patterns"
(templates with which to match) not "ranges" (sets of in some way
contiguous values). But I guess that's a lost battle.

> Something's odd in the -09 ABNF and in your derived ABNF:
>
> Do we want "zero or more" <variant-range>s ?  What's the idea
> of more than one wildcard variant like say de-CH-*-*-x-oops ?
> No problem with de-CH-1996-*-x-okay, but de-CH-*-1996-x-weird
> is weird, or isn't it ?

No opinion, as yet.

> > I think that the current (v. -09) -matching production
>
> > extension = singleton *("-" (2*8alphanum)) [ "-*" ]
>
> > is wrong. It allows a singleton *alone* (no dash and second
> > component at all), which I don't think was intended.
>
> Yes, your version is better.  Adding the 4234-recommended
> "grouping" for alternatives after s/pat/range/ I get:
>
>    extension-range = extension
>                    / ( singleton *( "-" 2*8alphanum ) "-*" )

Better than Addison's suggested rewrite of that, I think.

> It's not completely obvious to find the <extlang> in your ABNF,
> therefore I propose to integrate your <extlang-pat> into the
> <language-pat> or <language-ranges> resp.:
>
>    language-range
>                  = language / "*"
>                  / (2*3ALPHA *2("-" 3ALPHA) "-*")

Hmm, not really fond of that. I still want to parallel the
tag and pattern productions as much as possible.

And the #/ "*"# part should still be on a line of its own.

		/kent k

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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Feb 2006 00:20:23 +0100

Kent Karlsson wrote:

> RFC 2616 sais:

Amended in the 2616 [errata] - no idea how they tricked the
RfC editor into using a page not hosted by RfC-editor.org 

IMHO the complete [errata]-procedure is broken, and it's also
not yet good enough what they propose in the "Techspec 3.15
issue 4":  <http://permalink.gmane.org/gmane.ietf.techspec/47>

> 2616 appears to only allow 'alpha's, no 'num's... (but 3066
> allows it in the subtags, just as 3066bis).

Yes, see above and the strange "outsourced" 2616-errata page.

 [*-range vs. *-pat]
> But I guess that's a lost battle.

I'm not hot about it, the idea to get rid of all stars is more
exciting than the names of the productions - but don't try me
with <id-right> vs. <id-domain> please, that's 2822/USEFOR :-)

>> de-CH-*-1996-x-weird is weird, or isn't it ?
> No opinion, as yet.

Add one million more stars, then it's more obvious... <gd&r>

> Hmm, not really fond of that.

Okay, proposal with <extlang-wild> posted in another article.

> I still want to parallel the tag and pattern productions as
> much as possible.

In that case you can't, all your other *-pat confused Addison
and me into missing the "plain" <extlang> case.  Bye, Frank