Subject: [Ltru] var3 posted

From: "Addison Phillips" <[email-masked]>
Date: Wed, 22 Feb 2006 15:56:46 -0800

All of the various edits (including some in response to Mark's last message) are in a -var3 edit, now posted:

   http://www.inter-locale.com/ID/draft-ietf-ltru-matching-10-var3.txt
   http://www.inter-locale.com/ID/draft-ietf-ltru-matching-10-var3.html

rfcdiff from ****var1**** is posted here:

   http://www.inter-locale.com/ID/var1-var3-diff.html

Looking for some +1's..... :-)

Best Regards,

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 08:32:49 +0100

> Looking for some +1's..... :-)

-2 for the ABNF in 2.1:  reuse of <language-tag>, <alphanum>
   instead of <ALPHA> for the first subtag

-1 for the ABNF in 2.2:  <alphanum> instead og <ALPHA> for the
   first subtag.

?? for the ABNF in 2.2:  It allows trailing stars, is that how
   it should be ?

-1 for MUSTard in 4.4:  The extreme 3066bis limits are for
   tags used in mail headers (2047/2231).  Longer ranges are
   fine, 33 and 42 shouldn't be mentioned  here in 'matching'.

Please delete chapter 6.  The rest (5, 7, 8, 9) appears to be
ready.  Please add a reference to [errata] wrt 2616:  Explain
in 2.1 why 2616 got it wrong, only the "primary tag" (hyphen-
delimited, not 3066bis terminology) is limited to ALPHA by
3066 as confirmed by 3066bis.
                              Bye, Frank

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 23 Feb 2006 09:05:01 -0800

Good catches all. Comments follow

~Addison

>    instead of <ALPHA> for the first subtag

Okay. I get it. Here is the update ABNF:

---
language-range   = (primary-subrange *["-" subrange]) / "*"
primary-subrange = 1*8ALPHA
subrange         = 1*8[alphanum]
alphanum         = ALPHA / DIGIT
---

NB> I used the production name "language-range" so that it clearly
supersedes the production in 3066 and 2616.

> -1 for the ABNF in 2.2:  <alphanum> instead og <ALPHA> for the

So I changed it to be:
--
extended-language-range = (primary-subrange / "*") *["-" (subrange / "*")]
--

Notice that we recycle the productions from language-range. If we have a
consensus to disallow trailing stars of any type (more on that just below),
the ABNF would be:

--
extended-language-range = (primary-subrange / "*") *["-" subrange]
--

> ?? for the ABNF in 2.2:  It allows trailing stars, is that how

Read The Fine Text. I debated not allowing the trailing stars, but it was
easy enough in the text to make allowances for them. The key thing is that
non-initial stars don't mean anything *in the matching schemes we define
here*. (They could mean something in some future matching scheme such as a
revived scoring, etc., although we don't say that)
>    fine, 33 and 42 shouldn't be mentioned  here in 'matching'.

Can we axe the whole section and replace it with (something like):

--
Language ranges are very similar to language tags in terms of content and
usage. The same types of restrictions on length that apply to language tags
could also apply to language ranges. Implementation, protocol, and
specificiation authors SHOULD apply the considerations in [RFC3066bis]
Section 4.3 (Length Considerations) where appropriate to language ranges and
language priority lists.
--
> 3066 as confirmed by 3066bis.

For those playing at home, chapter 6 is an ill-maintained changes section.
We will need one eventually that says "this is the first version of this
document".

WRT 2616, Frank means that their ABNF is incorrect. Here it is:

--
       Accept-Language = "Accept-Language" ":"
                         1#( language-range [ ";" "q" "=" qvalue ] )
       language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
--

Notice that digits are prohibited throughout. I added this text to Section
2.1, in the para just following the ABNF (where HTTP 1.1 is discussed):

---
(Note that the ABNF in <xref target="RFC2616"></xref> is incorrect, since it
disallows the use of digits anywhere in the 'language-range'.)
---

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 23 Feb 2006 09:09:00 -0800

Note, var3 is updated on-line.

Addison

Addison Phillips

> -----Original Message-----
> From: Addison Phillips [mailto:[email-masked]]
> Sent: 2006?2?23? 9:05
> To: 'Frank Ellermann'; [email-masked]
> Subject: RE: [Ltru] Frank's var3 comments
>

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 21:45:17 +0100

> language-range   = (primary-subrange *["-" subrange]) / "*"
                                        (            )
> primary-subrange = 1*8ALPHA

Okay, I'd use inline style as in 3066, matter of taste:

language-range     = ( 1*8ALPHA *( "-" 1*8alphanum ) ) / "*"

Please replace the square brackets - no error, but you'd get
a warning for  *[ x y ]  instead of *( x y )

> the production name "language-range" so that it clearly

+1

> extended-language-range = (primary-subrange / "*") *["-" (subrange / "*")]

Same here, replace square brackets, and maybe use inline style:

  extended-language-range = (1*8ALPHA / "*") *( "-" (1*8alphanum / "*"))

You don't use <primary-subrange> or <subrange> in the prose of
var3, therefore you could get rid of it.

> The key thing is that non-initial stars don't mean anything
> *in the matching schemes we define here*. (They could mean
> something in some future matching scheme such as a revived
> scoring, etc., although we don't say that)

Hm.  Then keep it in -10, we can discuss it next week for -11.

Yes, that's fine, incl. the SHOULD.

> disallows the use of digits anywhere in the 'language-range'.)

Please add "as stated in the errata" or similar, the authors
know it, but readers might miss it.  USEFOR drafts have even a
normative reference to [errata] - odd, but Bruce wanted it so.

                           Bye, Frank

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 23 Feb 2006 13:15:35 -0800

Comments follow.

Addison Phillips

> From: Frank Ellermann [mailto:[email-masked]]
> Sent: 2006?2?23? 12:45
> To: [email-masked]
> Subject: [Ltru] Re: Frank's var3 comments
> 
> Addison Phillips wrote:
> 
> 

I was trying to recycle the productions in both kinds of range.
> a warning for  *[ x y ]  instead of *( x y )

Agreed. DONE.
> var3, therefore you could get rid of it.

Agreed.
> Hm.  Then keep it in -10, we can discuss it next week for -11.

Okay. I am hesitant to remove without discussion.
> normative reference to [errata] - odd, but Bruce wanted it so.
Whoops... the errata. How do I refer to it?!? I've got
http://skrb.org/ietf/http_errata.html, but it would be useful to have the
XML for it. In the text I put:

--
(Note that the <xref target="RFC4234">ABNF</xref> in <xref
target="RFC2616"></xref> is incorrect, since it disallows the use of digits
anywhere in the 'language-range': this is mentioned in the <xref
target="RFC2616errata" format="none">errata</xref>.)
--

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 22:46:10 +0100

Addison Phillips wrote:

> Whoops... the errata. How do I refer to it?!?

I can't tell how it's _done_ in xl2rfc, but I know what the
output could look like, see: 

http://tools.ietf.org/html/draft-ietf-usefor-usefor#page-31

> I've got http://skrb.org/ietf/http_errata.html, but it
> would be useful to have the XML for it.

Better use the "canonical" URL http://purl.org/NET/http-errata
in case they move it to another hoster.  

> target="RFC2616"></xref> is incorrect,

Adding [4234] to ABNF everywhere is unnecessary, nut maybe 
it's the first occurence of "ABNF" in your text.

> this is mentioned in the <xref

Yes, something like that.  Plus a manual reference, take your
record-jar reference as template, replace its urn:isbn by the
canonical PURL (see above), add title 2161 errata, ready.  

Or try the minimalistic USEFOR style... ;-)   Bye, Frank