Subject: RE: [Ltru] implementation, application, protocol

From: "Addison Phillips" <[email-masked]>
Date: Mon, 5 Dec 2005 09:43:32 -0800

I think this is a good way to solve this set of comments. The problem here is that there a good bit of text already in place that talks about "specification, protocols, or applications" in Section 1 and these repeat a good bit of your proposed text. I propose instead to modify the paragraphs in question to say:

--
<t>Given a set of language identifiers, such as those defined in <xref target="RFC3066bis" />, various mechanisms can be envisioned for performing language negotiation and tag matching. </t>

<t>This document defines  several mechanisms for matching, selecting, or filtering content whose natural language is identified using Language Tags <xref target="RFC3066bis" />, as well as the syntax (called a "language range") associated with each of these mechanisms for specifying the user's language preferences. Applications, protocols, or specifications will have varying needs and requirements that affect the choice of a suitable mechanism. Depending on the matching scheme, there are various options left to the implementation. This means that the option is left to the protocol if the matching scheme is used by a protocol, or directly by the application in case there is no
protocol. If there is a protocol, the protocol might specify some options, while leaving others open to implementers of that protocol.
</t>
--

Addison P. Phillips
Globalization Architect, Quest Software

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Duerst
> Sent: Monday, December 05, 2005 1:22 AM
> To: LTRU Working Group
> Subject: [Ltru] implementation, application, protocol
> 
> [co-chair hat off]
> 
> I have earlier raised an issue about the words
> 'application' and 'protocol'. I don't think
> I talked about 'implementation' then, but that
> word is also all over the place, without ever
> being clearly grounded.
> 
> I propose that we add an explanation somewhere
> at the end of section 1. The following text is
> a first attempt, I'm sure it can be improved:
> 
> The matching schemes defined in this document can
> be used by (Internet) protocols, or, in cases where
> there is no protocol, directly by applications.
> Depending on the matching scheme, there are
> various options left to the implementation.
> This means that the option is left to the protocol
> if the matching scheme is used by a protocol, or
> directly by the application in case there is no
> protocol. If there is a protocol, the protocol may
> select some options, and my leave others open
> to implementers of that protocol.
> 
> Not sure the text above is very good, but I hope you
> at least get the idea I wanted to put out.
> 
> Regards,   Martin.
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Martin Duerst <[email-masked]>
Date: Tue, 06 Dec 2005 15:14:59 +0900

At 02:43 05/12/06, Addison Phillips wrote:
 >I think this is a good way to solve this set of comments. The problem here
 >is that there a good bit of text already in place that talks about
 >"specification, protocols, or applications" in Section 1 and these repeat a
 >good bit of your proposed text.

Sorry I missed that.

 >I propose instead to modify the paragraphs
 >in question to say:
 >
 >--
 ><t>Given a set of language identifiers, such as those defined in <xref
 >target="RFC3066bis" />, various mechanisms can be envisioned for performing
 >language negotiation and tag matching. </t>
 >
 ><t>This document defines  several mechanisms for matching, selecting, or
 >filtering content whose natural language is identified using Language Tags
 ><xref target="RFC3066bis" />, as well as the syntax (called a "language
 >range") associated with each of these mechanisms for specifying the user's
 >language preferences.

Can we turn this around, and mention the syntax first, and then the
matching mechanisms, to have this in document order?
Also, should we change 'selecting' to 'lookup' to allign terminology?

 >Applications, protocols, or specifications will have
 >varying needs and requirements that affect the choice of a suitable
 >mechanism. Depending on the matching scheme,

We use 'mechanism' twice above, and now change to 'scheme', which makes
it unclear whether these are the same or not. Either use 'scheme'
throughout, or use a phare such as "matching mechanism, hereafter
called matching scheme".

 >there are various options left to

Can we change "left to" to "for selection by", or something similar
that is more active in nature? (same again below)

Regards,    Martin.

 >the implementation. This means that the option is left to the protocol
 >if the matching scheme is used by a protocol, or directly by the
 >application in case there is no
 >protocol. If there is a protocol, the protocol might specify some options,
 >while leaving others open to implementers of that protocol.
 ></t>
 >--
 >
 >Addison P. Phillips