Subject: [Ltru] 2nd WG Last Call for draft-ietf-ltru-matching

From: Martin Duerst <[email-masked]>
Date: Tue, 02 May 2006 19:17:59 +0900

Dear LTRU WG,

Many of you have expected a Second WG Last Call, and here it is.
Sorry for the delay due to personal reasons.

I have looked through the discussion of the previous last call,
and tried to keep track of everything at
http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/.
If somebody thinks something is missing (or wrong), or would like
some details to be added, or has some questions, please tell me.
The substantive changes require another WG Last Call.

The duration of this Last Call is two (2) weeks, it will end on
Tuesday, May 16, 11:00 UTC (20:00 Japan, 13:00 France,...,
4:00am US Pacific, and so on).

Please read the draft at
http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt
carefully and send in comments, with a subject indicating
the issue. Please also send in a comment if you have read the
draft and haven't found any issue.

If you have read earlier drafts, please note that this draft
is a serious revision, better read on its own.

I hope that this time, we can successfully complete this last call
and send the draft to the IESG.

Regards,    Martin. 

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

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 2 May 2006 12:29:26 -0700

All,

Martin has asked me to enumerate the differences (comments received since
draft-12 was created) that are already incorporated into draft-13. This is
straightforward: Debbie Garside sent me a small number of editorial comments
in a paragraph on page 9. This paragraph used to say:

---
   Applications, protocols, or specifications, in addressing their
   particular requirements, can offer pre-processing or configuration
   options.  For example, an implementation could allow a user to
   associate or map a particular language range to a different value.
   Such a user might wish to associate the language range subtags 'nn'
   (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) with the more general
   subtag 'no' (Norwegian).  Or perhaps the user could associate the
   range "zh-Hans" (Chinese as written in the Simplified script) with
   the language tag "zh-CN" (Chinese as used in China, where the
   Simplified script is predominant) because content is available with
   that tag.  Documentation on how the ranges or tags are altered,
   prioritized, or compared in the subsequent match in such an
   implementation will assist users in making the best configuration
   choices.
---

The changes are in the last two sentences, making the bottom part of the
graf read:

---
   Or perhaps a user would want to associate
   requests for the range "zh-Hans" (Chinese as written in the
   Simplified script) with content bearing the language tag "zh-CN"
   (Chinese as used in China, where the Simplified script is
   predominant).  Documentation on how the ranges or tags are altered,
   prioritized, or compared in the subsequent match in such an
   implementation will assist users in making these types of
   configuration choices.
---

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: Martin Duerst [mailto:[email-masked]]
> Sent: 2006?5?2? 3:18
> To: LTRU Working Group
> Subject: [Ltru] 2nd WG Last Call for draft-ietf-ltru-matching
> 
> Dear LTRU WG,
>

---

From: John Cowan <[email-masked]>
Date: Thu, 4 May 2006 01:02:13 -0400

> draft and haven't found any issue.

Here are my comments, all editorial in nature:

1.  In Section 2.1, the first sentence of the first graf and the first
sentence of the second graf are overlapping and partly contradictory.
I suggest changing the first to:

	A "basic language range" (originally described by HTTP/1.1
	[RFC 2616] and later [RFC 3066bis] has the same syntax as an
	[RFC 3066bis] language tag or is the single character "*".

and removing the first sentence of the second graf altogether, but
expanding the following pronoun "They" to "Basic language ranges"
for clarity.

2.  In Section 2.2, for "useful in specifying" read "useful for
specifying".

3.  In Section 3, the second graf is redundant and confuses the
number of matching schemes with the number of *types* of matching
schemes.  I suggest it be removed in favor of changes to Section 3.1
following.

4.  In Section 3.1, for "types of matching" read "matching schemes",
and append "and returns zero or more matching language tags" to
list entries 1 and 2.

5.  In Section 3.3.1, replace the first sentenc with "Basic filtering
compares basic language ranges to language tags", for conformity wiht
Section 3.3.2.

6.  In Section 3.3.2, last graf, the words "One such difference is that"
don't seem to serve any purpose; I suggest they be removed.

7.  In Section 3.4, last graf, I suggest swapping the last two
sentences, with the exception of the words "For example" and "Another
possibility" which should be left in place.

8.  In Section 3.4.1, after "specification" insert "that uses lookup"
for clarity.

9.  In Section 3.4.1, the bullet list is a random mixture of tags
the algorithm might return as defaults, and the actions that the
calling application might take as a result.  I suggest these be
split more or less as follows:

	Some possible examples of default results are:

	* return a particular language tag designated for the operation

	* return a null string as a language tag value, in cases
	  where the protocol permits the empty value (yada yada)

	* return the language tag "i-default" (see [RFC 2277])

	* return an error condition or error message

	In turn, the application, protocol, or specification may choose to:

	* return an item with no language tag (yada yada)

	* return a list of available languages for the user to select from

10.  In Section 4.4. for "that apply" read "that can be applied" and
for "can also apply" read "can also be applied".

-- 
John Cowan    http://ccil.org/~cowan  [email-masked]
Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash,
The day and hour soon are coming / When all the IT folks say "Gosh!"
It isn't from a clever lawsuit / That Windowsland will finally fall,
But thousands writing open source code / Like mice who nibble through a wall.
        --The Linux-nationale by Greg Baker

---

From: Mark Davis <[email-masked]>
Date: Thu, 04 May 2006 09:34:13 -0700

My comments are

a) version 12 of the document is fine the way it is, but
b) I have no real objection to any of John's suggested changes, except 
the general one that we could making minor incremental improvements to 
this document until we die of exhaustion, *none* of which are or have 
been worth delaying the publication of 3066bis! (Let's get this damn 
thing out the door!)

Mark

P.S. Not sure why we are really concerned with a German noble (Graf) in 
this document ;-)

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 4 May 2006 10:41:55 -0700

> a) version 12 of the document is fine the way it is, but

+1 to that... but...

I don't mind minor editorial comments like these, since they will not prevent us from moving forward and may assist us at IETF Last Call by making the document better. This is, after all, a Last Call for comments. The only things that will prevent us finishing this document off are substantive comments that cannot be addressed or "major" editorial comments. Substantive comments we can consider on their own merits and I think we would approach a major edit with great caution.

Our goal here, IMO, should be to submit draft-13 in the best possible shape for an IETF Last Call and to convince the chairs that the document is ready for its real Last Call and subsequent adoption. To that end, clarification of the text is welcome: I do not want to have multiple IETF Last Calls. I'm kind of tired of that.

"Bring out 'yer dead."

Addison

Addison Phillips

> From: Mark Davis [mailto:[email-masked]]
> Sent: 2006年5月4日 9:34
> To: John Cowan
> Cc: LTRU Working Group
> Subject: Re: [Ltru] 2nd WG Last Call for draft-ietf-ltru-matching
> 
> My comments are
>

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 4 May 2006 10:43:56 -0700

Hi John,

Thanks for the comments. 

Comments on my proposed disposition of each follow.

Addison

Addison Phillips

> From: John Cowan [mailto:[email-masked]]
> Sent: 2006?5?3? 22:02
> To: Martin Duerst
> Cc: LTRU Working Group

Agreed, only I also extracted the parenthetical like this:

--
A "basic language range" has the same syntax as an <xref target="RFC3066"/>
language tag or is the single character "*". The basic language range was
originally described by <xref target="RFC2616">HTTP/1.1</xref> and later
<xref target="RFC3066"/>.
--
> 2.  In Section 2.2, for "useful in specifying" read "useful for

Done.
> schemes.  I suggest it be removed in favor of changes to Section 3.1

This would remove the definition of filtering and lookup. It would be better
to fix the inconsistencies in the language later.
> and append "and returns zero or more matching language tags" to

Changed the section title as proposed.
Change the intro to the list of schemes from:

--
This document describes three types of matching
--

To read:

--
This document describes three matching schemes
--
> compares basic language ranges to language tags", for conformity wiht

Done.
> don't seem to serve any purpose; I suggest they be removed.

Done.
> possibility" which should be left in place.

I like that more. Here is the resulting para (there are three sentences,
actually, and the middle sentence must be after the ASCII-order suggestion):

<t>For example, an implementation could map the extended language ranges to
basic ranges. Another possibility would be for an implementation to return
the matching tag that is first in ASCII-order. If the language range were
"*-CH" and the set of tags included "de-CH", "fr-CH", and "it-CH", then the
tag "de-CH" would be returned.</t>
> 8.  In Section 3.4.1, after "specification" insert "that uses lookup"

Done.
> 	* return a list of available languages for the user to select from

Hm... I don't see this particular one as necessary and think it subtracts
from the unity of the message. I didn't implement this change, as a result.
> for "can also apply" read "can also be applied".
Done.

---

From: John Cowan <[email-masked]>
Date: Thu, 4 May 2006 14:50:35 -0400

> Comments on my proposed disposition of each follow.

No complaints and no further comments.  I'm done.

-- 
After fixing the Y2K bug in an application:     John Cowan
        WELCOME TO <censored>                   [email-masked]
        DATE: MONDAK, JANUARK 1, 1900           http://www.ccil.org/~cowan

---

From: Erkki Kolehmainen <[email-masked]>
Date: Tue, 16 May 2006 13:39:54 +0300

I have read the document and I haven't found any particular issues with it.
The editorial comments that I might have made appear to have been dealt 
with.

Sincerely,
Erkki I. Kolehmainen

---

From: Erkki Kolehmainen <[email-masked]>
Date: Tue, 16 May 2006 13:39:54 +0300

Sincerely,
Erkki I. Kolehmainen