Subject: [Ltru] WG last call for draft-ietf-ltru-matching

From: Martin Duerst <[email-masked]>
Date: Fri, 10 Mar 2006 07:41:55 +0900

The editors have submitted draft-11, which is now available at
http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-11.txt.

There have been no comments since that submission, which I hope is
an indication that we can go to the next stage.

I'm therefore starting a Working Group Last Call. The duration of the
Last Call is three (3) weeks to take into account the upcomming IETF
meeting, where many people may be busy. The Last Call will therefore
end on Thursday, March 30, 23:00 UTC (Friday, March 31st, 08:00
Japan time, Thursday, March 30, 3pm US Pacific, and so on).

Please read the above draft carefully and send in your comments.
Please mark each issue clearly, and indicate whether you think it
is editorial, substantive, or whatever. Please concentrate on
those points that you think are relevant for moving the document
forward (from typos to substantial oversights in case you find
any), rather than e.g. proposing yet another complicated new
matching scheme. Also, if there is any issue that you have found
earlier and that you think has not been appropriately addressed,
and you think it is still relevant for moving the document forward,
please mention this, too.

If you read the document and did not find any issues, please
send a mail to say so!

If as a result of WG Last Call, the document does not change
significantly, the document will be submitted to the Area
Director and the IESG for further processing. If the document
changes significantly, we will have another WG Last Call.
Significantly is defined as any change that reasonably may
create significant new comments/issues from somebody who
reviewed the document in this Last Call.

Regards,      Martin.

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

---

From: Mark Davis <[email-masked]>
Date: Thu, 09 Mar 2006 15:06:07 -0800

I did not find any issues, and am happy with the document as it is.

Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Mar 2006 16:20:29 +0100

On Fri, Mar 10, 2006 at 07:41:55AM +0900,
 Martin Duerst <[email-masked]> wrote 

> an indication that we can go to the next stage.

I've read it and study it and I have no objections. (Warning: I'm not
an expert in languages and I'm a member of LTRU for only a small
time.)

A small typo: 

A speaker of Breton in France, for example, may specify "be" followed
by "fr",

No, it may not. Breton is "br" ("be" is Belorusian).

---

From: "Addison Phillips" <[email-masked]>
Date: Fri, 10 Mar 2006 07:33:39 -0800

Thanks for the comments. I've updated draft-12 with the change to Breton.

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: Stephane Bortzmeyer [mailto:[email-masked]]
> Sent: 2006?3?10? 7:20
> To: Martin Duerst
> Cc: LTRU Working Group
> Subject: [Ltru] Re: WG last call for draft-ietf-ltru-matching
>

---

From: "Debbie Garside" <[email-masked]>
Date: Sat, 11 Mar 2006 15:27:58 -0000

Editorial comment:

Just a couple of paragraphs that do not read terribly well IMHO!

Section 3.3 (paragraph under figure 3) 3rd sentence reads:

"Not every specific level of tag granularity is usually available or
language content may be sparsely populated."

Proposed change to:
"Language content may be sparsely populated and not every specific level of
tag granularity is necessarily available".

Section 4.1 paragraph 7

"Such alterations SHOULD be avoided, if possible, since they remove
information that might be relevant elsewhere that would make use of that
information."

Proposed change to:
"Such alterations SHOULD be avoided, if possible, since they remove
information that might be relevant to other applications, specifications or
protocols.

Regards

Debbie Garside

> From: Martin Duerst [mailto:[email-masked]]
> Sent: 09 March 2006 22:42
> To: LTRU Working Group
> Subject: [Ltru] WG last call for draft-ietf-ltru-matching
>

---

From: Martin Duerst <[email-masked]>
Date: Mon, 13 Mar 2006 17:54:57 +0900

[co-chair hat off]

 >tag granularity is necessarily available".

+1

 >information that might be relevant to other applications, specifications or

Good, except that I'd exclude specifications, because in my
view of the world, specifications are mere documents, which don't
consume data.

Regards,    Martin.

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 13 Mar 2006 11:02:33 -0000

Martin wrote:

> Good, except that I'd exclude specifications, because in my view of the
world, specifications are mere documents, which don't consume data.

In which case perhaps "specifications" needs to be taken out at the
beginning of the paragraph? (from memory)

Regards

Debbie

-----Original Message-----
From: Martin Duerst [mailto:[email-masked]] 
Sent: 13 March 2006 08:55
To: Debbie Garside; 'LTRU Working Group'
Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching

[co-chair hat off]

At 00:27 06/03/12, Debbie Garside wrote:
 >"Language content may be sparsely populated and not every specific level
of  >tag granularity is necessarily available".

+1

>information that might be relevant to other applications, specifications or

Good, except that I'd exclude specifications, because in my view of the
world, specifications are mere documents, which don't consume data.

Regards,    Martin.

---

From: "Addison Phillips" <[email-masked]>
Date: Mon, 13 Mar 2006 12:16:28 -0800

> of
I modified this proposal slightly to say:

--
Language content is sometimes sparsely populated and content on every level
of tag granularity might not be available. 
--

This not only eliminates the use of 2119 keywords, but eliminates the
kind-of-chewy dependent clause.
> view of the world, specifications are mere documents, which don't
Yuck. The existing text is clumsy and redundant. I'd rather go in the other
direction and say less. I'd propose:

--
<t>Applications, specifications, or protocols that choose not to interpret
one or more private-use or extension subtags SHOULD NOT remove or modify
these extensions in content that they are processing, because this removes
information which might be used elsewhere. When a language tag instance is
to be used in a specific, known protocol, and is not being passed through to
other protocols, language tags MAY be altered to remove subtags and
extensions that are not supported by that protocol.</t>
--

Specifying what uses a language tag is not necessary. The point is that
removing subtags alters meaning and might remove something of interest to
someone else. 

Best Regards,

Addison

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 13 Mar 2006 20:28:08 -0000

Addison wrote:

> When a language tag instance is
> to be used in a specific, known protocol, and is not being passed 
> through to other protocols, language tags MAY be altered to remove 
> subtags and extensions that are not supported by that protocol.</t>

Don't like this... it encourages truncation and assumes foresight. If
anything I would cut this bit out altogether and just have the active part
as the 'SHOULD NOT' of the first sentence (yours updated).

Best regards

Debbie

> From: Addison Phillips [mailto:[email-masked]]
> Sent: 13 March 2006 20:16
> To: 'Martin Duerst'; 'Debbie Garside'; 'LTRU Working Group'
> >  >information that might be relevant to other applications,
> specifications
> > or
> >  >protocols.
> >

---

From: "Addison Phillips" <[email-masked]>
Date: Mon, 13 Mar 2006 13:55:19 -0800

I don't disagree... in fact, the sentence merely repeats the opposite of the
preceding "MAY". Removing it, though, leaves behind the original reason for
this sentence...

How about:

--
A protocol or application that consumes language tags MAY remove unsupported
extensions or subtags to make processing more efficient, as long as the
truncated tag is not forwarded to other processes.
--

Addison

Addison Phillips

> From: Debbie Garside [mailto:[email-masked]]
> Sent: 2006?3?13? 12:25
> To: 'Addison Phillips'; 'Martin Duerst'; 'Debbie Garside'; 'LTRU Working
> Group'
> through
> > to other protocols, language tags MAY be altered to remove subtags and
> through
> > to

---

From: John Cowan <[email-masked]>
Date: Mon, 13 Mar 2006 16:57:40 -0500

> truncated tag is not forwarded to other processes.

"outside the scope of the protocol or application".

The whole point of this hooraw is that IPP clients shouldn't send script
subtags to IPP servers.

-- 
John Cowan  [email-masked]  www.ccil.org/~cowan  www.ap.org
The penguin geeks is happy / As under the waves they lark
The closed-source geeks ain't happy / They sad cause they in the dark
But geeks in the dark is lucky / They in for a worser treat
One day when the Borg go belly-up / Guess who wind up on the street.

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 13 Mar 2006 22:46:58 -0000

YUCK!  Consumes...!!! 

How about:

Unsupported extensions or subtags MAY be removed by applications or
protocols during processing but MUST remain intact when forwarded.

Debbie

> Sent: 13 March 2006 21:55
> To: 'Debbie Garside'; 'Martin Duerst'; 'Debbie Garside'; 'LTRU Working
> Group'
> > > >  >information that might be relevant elsewhere that would make use
> of
> > > that
> > > >  >information."
> > > >  >
> > > >  >Proposed change to:
> > > information which might be used elsewhere. When a language tag
> instance
> > is

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 13 Mar 2006 20:25:00 -0000

Addison wrote:

> to be used in a specific, known protocol, and is not being passed through

Best regards

Debbie

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Mar 2006 12:46:58 +0100

Debbie Garside wrote:

> Unsupported extensions or subtags MAY be removed by
> applications or protocols during processing but MUST 
> remain intact when forwarded.

The intention is clear, but it sounds like an attempt to
enforce common sense.  Maybe the application or protocol
has reasons to forward only what it understood.  Bye, Frank

---

From: Jon Hanna <[email-masked]>
Date: Thu, 23 Mar 2006 12:01:34 +0000

> has reasons to forward only what it understood.  Bye, Frank

That's reasonable if what the application does is considered a 
transformation, not if it's considered to leave the source data intact, 
or transformed only in a well-defined manner which doesn't affect this.

Is it really "forwarding" if it alters the data in such a manner?

---

From: "Debbie Garside" <[email-masked]>
Date: Thu, 23 Mar 2006 15:15:21 -0000

I think Addison may have deleted the original paragraph entirely...in which
case issue resolved.

Regards

Debbie

> From: Jon Hanna [mailto:[email-masked]]
> Sent: 23 March 2006 12:02
> To: [email-masked]
> Subject: Re: [Ltru] less MUSTard?
> 
> Frank Ellermann wrote:
> > Debbie Garside wrote:
> >
> >

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 23 Mar 2006 08:28:55 -0800

> has reasons to forward only what it understood.  Bye, Frank
As a reminder, the editor's copy says:

--
Applications, specifications, or protocols that choose not to interpret one
or more private-use or extension subtags SHOULD NOT remove or modify these
extensions in content that they are processing, because this removes
information which might be used elsewhere. When a language tag instance is
to be used in a specific, known protocol, and is not being passed through to
other protocols, language tags MAY be altered to remove subtags and
extensions that are not supported by that protocol.
--

I'm not much in love with that para. I note, for example, that it is
embedded in a section of advice to end users on choosing language ranges and
thus is somewhat out of place. Why don't we move this to the end of Section
3.1 (with other general implementation information) and change it to read
something like:

--
Although an application, specification, or protocol can alter language tags
internally (to remove unsupported extensions, for example), other users or
processes might derive value from the original tag's information. If an
application, specification, or protocol alters a language tag internally, it
SHOULD NOT replace the original language tag in the content or protocol.
--

Addison

---

From: Mark Davis <[email-masked]>
Date: Thu, 23 Mar 2006 09:31:03 -0800

I like that a bit better, but there is still a problem in the last 
statement. Suppose that I have a process that is designed to return the 
language subtag. I have a protocol that pipes through it, because I want 
to extract that tag. The last sentence says I shouldn't do this, when I 
have a perfectly good reason for doing so. It is hard to express what we 
want without being tautological, but here is an attempt:

An application, specification, or protocol can alter language tags internally. For example, it may remove unsupported extensions, or suppress other subtags that may be irrelevant to the particular processing involved, or replace subtags in transient processing such as matching. However, such alteration does remove information from the language tag that may be important to other users or processes, and SHOULD NOT be done where the original information content is expected to remain unaltered.

Mark

---

From: John Cowan <[email-masked]>
Date: Thu, 23 Mar 2006 12:32:18 -0500

Mark Davis scripsit:

> An application, specification, or protocol can alter language tags 
> internally. For example, it may remove unsupported extensions, or suppress 
> other subtags that may be irrelevant to the particular processing involved, 
> or replace subtags in transient processing such as matching. However, such 
> alteration does remove information from the language tag that may be 
> important to other users or processes, and SHOULD NOT be done where the 
> original information content is expected to remain unaltered.

+1

-- 
John Cowan                              <[email-masked]>
http://www.ccil.org/~cowan              http://www.ap.org
                Charles li reis, nostre emperesdre magnes,
                Set anz totz pleinz ad ested in Espagnes.

---

From: "Debbie Garside" <[email-masked]>
Date: Thu, 23 Mar 2006 17:38:15 -0000

I would change this:

> internally.

To this:

> during internal processing procedures.

Debbie

> From: Mark Davis [mailto:[email-masked]]
> Sent: 23 March 2006 17:31
> To: Addison Phillips
> Cc: 'Frank Ellermann'; [email-masked]
> Subject: Re: [Ltru] less MUSTard? (was: WG lastcall fordraft-ietf-ltru-
> matching)
> 
> other subtags that may be irrelevant to the particular processing
> involved, or replace subtags in transient processing such as matching.
> However, such alteration does remove information from the language tag
> that may be important to other users or processes, and SHOULD NOT be done
> where the original information content is expected to remain unaltered.
> 
> Mark
> 
> 
> Addison Phillips wrote:
> > Frank Ellermann wrote:
> >
> through to

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 23 Mar 2006 10:41:16 -0800

+1

Addison Phillips

> Sent: 2006年3月23日 9:31
> Subject: Re: [Ltru] less MUSTard? (was: WG last call fordraft-ietf-ltru-
> matching)
>

---

From: Mark Davis <[email-masked]>
Date: Thu, 23 Mar 2006 11:41:02 -0800

"processing procedures" doesn't make sense to me. Can you explain why 
"internal processing" doesn't work?

Mark

Debbie Garside wrote:
>>> Applications, specifications, or protocols that choose not to interpret
>>>       
>> one
>>     
>>> or more private-use or extension subtags SHOULD NOT remove or modify
>>>       
>> these
>>     
>>> information which might be used elsewhere. When a language tag instance
>>>       
>> is
>>     
>>> embedded in a section of advice to end users on choosing language ranges
>>>       
>> and
>>     
>>> thus is somewhat out of place. Why don't we move this to the end of
>>>       
>> Section
>>     
>>> 3.1 (with other general implementation information) and change it to
>>>       
>> read
>>     
>>> something like:
>>>
>>> --
>>> Although an application, specification, or protocol can alter language
>>>       
>> tags
>>     
>>> internally (to remove unsupported extensions, for example), other users
>>>       
>> or
>>     
>>> application, specification, or protocol alters a language tag
>>>       
>> internally, it
>>

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 23 Mar 2006 11:49:45 -0800

Actually, the phrase is redundant. The sentence can read:

"An application, specification, or protocol can alter language tags."

Addison

Addison Phillips

> Sent: 2006年3月23日 11:41
> To: Debbie Garside
> Cc: 'Addison Phillips'; 'Frank Ellermann'; [email-masked]

---

From: "Debbie Garside" <[email-masked]>
Date: Thu, 23 Mar 2006 20:04:10 -0000

+1

> Sent: 23 March 2006 19:50
> To: 'Mark Davis'; 'Debbie Garside'
> Subject: RE: [Ltru] less MUSTard? (was: WG lastcall fordraft-ietf-ltru-
> matching)
>

---

From: "Debbie Garside" <[email-masked]>
Date: Thu, 23 Mar 2006 20:04:10 -0000

I just thought "internally" didn't really make sense... are we talking
internal to the language tag or internal processes (applications,protocols)

But if you are happy with it... fine by me

Debbie

> Sent: 23 March 2006 19:41
> To: Debbie Garside