Re: [Ltru] Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags)

"Phillips, Addison" <> Mon, 27 July 2009 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82DCE3A6AD4 for <>; Mon, 27 Jul 2009 09:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -107.599
X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fj498NoFH34R for <>; Mon, 27 Jul 2009 09:17:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 653333A6A8B for <>; Mon, 27 Jul 2009 09:17:46 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.43,277,1246838400"; d="scan'208";a="219292587"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jul 2009 16:17:42 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id n6RGHZdv002231 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 27 Jul 2009 16:17:35 GMT
Received: from ([]) by ([]) with mapi; Mon, 27 Jul 2009 09:17:36 -0700
From: "Phillips, Addison" <>
To: Julian Reschke <>
Date: Mon, 27 Jul 2009 09:17:33 -0700
Thread-Topic: Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: [Ltru] Proposed resolution for Issue 13 (language tags)
Thread-Index: AcoOr+m8v47pOdCDQWyed4uQiTrIDAAIFPQA
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: LTRU Working Group <>, HTTP Working Group <>
Subject: Re: [Ltru] Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jul 2009 16:17:47 -0000

Hello Julian,
> so I had a look at RFC 4647 and I'm totally open to allow more than
> Basic Filtering; but I'm not sure about what exactly we want to
> say...
> - require to try Basic Filtering First, but allow to fall back to
> Lookup when nothing is returned?

I think this would actually be a Bad Thing. Filtering and Lookup work very differently.

> - just stay point to Section 3.1 and leave it to the implementer?

I think that's probably a the best choice. There are different purposes to the matching schemes. 

I tend to think that HTTP's requirements are most like what the Lookup algorithm provides. That is, you can (and must) return exactly one result for a given request. It also works most like the resource-and-localization mechanisms in programming languages and (some) Web infrastructure. While filtering can return "exactly one" result, it isn't always clear what you will get and it works less well when a wide variety of content is available with closely related language tags.

On the other hand, there are implementations based on filtering (Basic Filtering *is* the algorithm in 2616) and these can be made to work. There are many applications where filtering is a good choice (this is especially true, for example, when aggregating content). So, although my personal preference would be to require Lookup, I don't think that choice can be the only one permitted.

I would suggest some text, but want to see other's reactions first.

Best Regards,


Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.