Subject: [Ltru] harald's comments...

From: "Addison Phillips" <[email-masked]>
Date: Tue, 6 Dec 2005 10:40:35 -0800

... I incorporated most of them (one or two with slight editorial modification).

Here is a list of things I didn't incorporate. Most of these were not incorporated because I had questions or concerns.

1. Section 3.2.3. HTA: What's the logic with not treating x- just like any other extension? As far as I can see, it makes no difference, and makes the code more complex.

Comment: if you don't treat x- specially, then the range x-foobar matches ALL tags (because the quintuple is *,*,*,*,x-foobar instead of x-foobar,*,*,*,*). This isn't what is wanted, I think.

2. HTA: Implementation choice means unpredictable results. Say what the algorithm is.

Comment: We do. The choice here is the user's choice of "cut-off value", not a code/implementation choice. That is: the user might choose different scores as a suitable cutoff. Elsewhere we have implementation choices that might cause the problems you describe.

3. HTA: Need to say how this works together with the weights in a language priority list.

Comment: Yes, although several ideas have been proposed and not much comment supplied, so I don't know what text to insert.

4. Section 3.3. HTA: This means that one behaves as if each element a-b-c-d is replaced with the language priority list a-b-c-d, a-b-c, a-b, a. I think this is a Bad Idea.

Comment: No, that's not correct. The language priority list using filtering " a-b-c-d, a-b-c, a-b, a" can produce content such as "a-b-c-x" or "a-z". Lookup can ONLY produce the items "(default), "a", "a-b", "a-b-c", and "a-b-c-d". This is a very different thing. Unless I misunderstand your point.

5. Section 2.3. HTA: There is no syntactic distinction between basic and extended language ranges. The choice is made by the context. This needs to be made clear. **MORE**

Comment: I slightly agree, although I note that I've carefully kept Basic Language Ranges (BLRs) compatible with RFC 3066 while making XLRs strictly compatible with RFC 3066bis. We could go down either path, since, as I added today to draft-08:

--
 (although such ill-formed ranges will probably not match anything).
--

6. HTA: These comments add no value.

Comment: They are preserved from draft-registry. I can remove them, but I've been conservative with the ABNF so far.

7. HTA: ABNF error. Case insensitivty means that the two alternatives are equal.

Comment: Gee... now you tell us :-). This is a direct quote from 3066bis.

8. Section 2.4. HTA: The concept of "protocol" here does not make sense to me.

Comment: Me either: I inserted the text I was requested to insert.

9. HTA: Canonicalizing tags with extensions and not canonicalizing tags without extensions makes no sense to me.

Comment: I agree, but the text is silent about tags without extensions. Perhaps all this content should go in favor of just including the subtags as normal subtags?

10. Section 3. HTA: I do not agree with this characterization. Note also that the input to both matching and lookup will normally (I think) be a list of language ranges.

Comment: The latter part I think I've now corrected. The first sentence I don't know what to do with (noting that above I disagree with your perception of lookup).

New editor's copy of draft-08 is on my website. It is getting really hard to find thing, since several sections have been moved. I suggest we update to draft-08 SOON.

Best Regards,

Addison

Addison P. Phillips
Globalization Architect, Quest Software
http://www.quest.com

Internationalization is not a feature.
It is an architecture. 

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 06 Dec 2005 23:46:47 +0100

--On 6. desember 2005 10:40 -0800 Addison Phillips 
<[email-masked]> wrote:

> New editor's copy of draft-08 is on my website. It is getting really hard
> to find thing, since several sections have been moved. I suggest we
> update to draft-08 SOON.

publish early, publish often. Still 91 versions to go until the 2-digit 
field overflows!

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 07 Dec 2005 07:50:54 +0100

Addison Phillips wrote:

>> HTA: ABNF error. Case insensitivty means that the two
>> alternatives are equal.
 
> Comment: Gee... now you tell us :-). This is a direct

02-21: <http://mid.gmane.org/[email-masked]>
03-17: <http://mid.gmane.org/[email-masked]>
06-14: <http://mid.gmane.org/[email-masked]>
06-15: <http://mid.gmane.org/[email-masked]>
06-15: <http://mid.gmane.org/[email-masked]>
08-09: <http://mid.gmane.org/[email-masked]>

Well, we discussed it, didn't we ?  <g>

> I suggest we update to draft-08 SOON.

Let Martin and Harald finish their round with draft -07.  I'm
lazy and wait for -08.  Nobody needs the matching stuff soon:

When the registry exists it will take some time to register
missing Suppress-Scripts, and to add the tags on Doug's watch
list (stuff introduced after date-B = 2005-10-16).  Bye, Frank

---

From: Martin Duerst <[email-masked]>
Date: Wed, 07 Dec 2005 18:37:22 +0900

field overflows!

[co-chair hat off]

I hoped to be able to send in comments on all parts of the draft
before a republication :-).

[co-chair hat on]
Given the number of comments and changes in the recent days,
just go ahead, Addison.

Regards,   Martin.

---

From: Martin Duerst <[email-masked]>
Date: Wed, 07 Dec 2005 19:26:32 +0900

>Well, we discussed it, didn't we ?  <g>

There are different ABNF checkers around. I'm not sure which
one Addison used. I'm quite sure which one Harald used: he
wrote his own. I think there was an IESG discuss on an ABNF
issue, which came from Bill Fenner, who also has his own
checker. And the one at http://www.apps.ietf.org/abnf.c
says it's by Chris Newman.

It is not really clear to me whether a syntax such as "x" / "X"
is indeed an error. It depends on whether you want to strictly
check whether a string is allowed or not (in which case it's
just redundant, not an error), or if you want to use the ABNF
to cut the syntax into pieces for further processing, in which
case you need a deterministic grammar, which the above is not.

This is an important distinction; it is one of the main
reasons why we e.g. have XML Schema and RelaxNG, the former
requiring the schema to be deterministic, whereas the later
doesn't.

On a quick reading of http://www.ietf.org/rfc/rfc4234.txt,
I haven't found any indication that ABNFs have to be
deterministic. Of course, many if not most of them are,
because usually being able to process the syntax
deterministically is the point of the ABNF. But to determine
in general whether a syntax is deterministic or not isn't
that easy (the non-determinism can occur on a level much
higher than constants in the same rule.

Regards,   Martin.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 07 Dec 2005 14:20:20 +0100

Martin Duerst wrote:

> one Addison used.

We used Bill's.  "x" / "X" is syntactically fine, same idea as
"odd or (not even)", maybe redundant, but no syntax error.  Test
c = "x" / "X"  at http://rtg.ietf.org/~fenner/abnf.cgi

> I'm quite sure which one Harald used: he wrote his own.

Yes, listed at <http://tools.ietf.org/inventory/verif-tools>,
but I killed perl on my box.  Probably it would also say that
c = "x" / "X"  is okay, syntactically.

> it's just redundant, not an error

That's what we decided for 3066bis, "rough consensus".  Only I
didn't _like_ it, but I didn't claim that it's a syntax error:

| Please get the okay of an ABNF expert like Bill, Ned, Bruce,
| Dave, Scott, or Harald for the ( "x" / "X" )
 <http://mid.gmane.org/[email-masked]>

> deterministic.

Not required.  For USEFOR we abuse it as feature, abbreviated:

id-quote   = [id-text] id-special [id-text]
id-text    = 1*( atext / "." / id-special )
id-special = ".." / "\\" / ( "\" DQUOTE )

                    Bye, Frank

P.S. and OT:  still waiting for two comments about
1: <http://permalink.gmane.org/gmane.org.w3c.uri/701> =>
   02-14 <http://article.gmane.org/gmane.org.w3c.uri/429/raw>
2: <http://permalink.gmane.org/gmane.ietf.rfc822/11763> =>
   02-27 <http://article.gmane.org/gmane.ietf.rfc822/11337>

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Wed, 7 Dec 2005 08:47:11 -0500

> -----Original Message-----
> From: Frank Ellermann [mailto:[email-masked]] 
> Sent: Wednesday, December 07, 2005 8:20 AM
> To: [email-masked]
> Subject: [Ltru] Re: harald's comments...
> 
> Martin Duerst wrote:

[snip]

>  <http://mid.gmane.org/[email-masked]>

The issue of case sensitivity is described in section 2.3 of RFC 4234.  To
summarize:

"ABNF strings are case-insensitive and the character set for these strings
is us-ascii."

"To specify a rule that IS case SENSITIVE, specify the characters
individually.

For example:

  rulename =  %d97 %d98 %d99"

So, the answer depends on what you're trying to specify.  Are you trying to
require case sensitivity or not?  If not, you can just use either "x" or "X"
without worrying about the other.  If so, you should be using ( "%x58" /
"%x78" ) or ( "%d88" / "%d120" ) depending on whichever base you prefer to
use.

-Scott-

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 07 Dec 2005 15:34:37 +0100

Scott Hollenbeck wrote:

> you can just use either "x" or "X" without worrying about
> the other.

Yes, here we managed to use both, and I worried about that.
No serious issue, nobody's tempted to (ab)use subtags x-foo
and X-foo with a different meaning.
                                   Bye, Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 08 Dec 2005 11:18:27 +0100

> says it's by Chris Newman.

actually I used my eyeballs... my syntax checker is far less good than the 
newer alternatives.

And it's not strictly an ABNF error - my objection is to it being 
superfluous - it will leave people who know that ABNF is case insensitive 
about " " strings hunting for the sentence that says "in this case, we're 
using ABNF as if it was case sensitive" (there is none), and making people 
who don't know that ABNF is case insensitive assume that it is.

I prefer not to have it. But if the WG has reached consensus that this 
should be that way.... sigh; I'll let you have it.

                    Harald