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 18:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3E8B3A6CB8 for <>; Mon, 27 Jul 2009 11:16:34 -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 OW22AA7qCn6i for <>; Mon, 27 Jul 2009 11:16:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A6A1B3A6C6F for <>; Mon, 27 Jul 2009 11:16:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.43,277,1246838400"; d="scan'208";a="303129865"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jul 2009 18:15:39 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id n6RIFMDD012958 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 27 Jul 2009 18:15:30 GMT
Received: from ([]) by ([]) with mapi; Mon, 27 Jul 2009 11:15:15 -0700
From: "Phillips, Addison" <>
To: John Cowan <>
Date: Mon, 27 Jul 2009 11:15:13 -0700
Thread-Topic: [Ltru] Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags)
Thread-Index: AcoO4DS2KPsclnYcT+iENS2nimCJLgAAJOqg
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: Julian Reschke <>, 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 18:16:35 -0000

> Phillips, Addison scripsit:
> > 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.
> Actually, no; that's an oversimplification of HTTP.  

Well... what I was trying to say was "HTTP is most commonly used in a way that I think works better with Lookup". That is, most typically, HTTP is used to return a single resource at the end of a URI. I'm well aware that there are other cases, including the 300 case, which is why I went on to say the rest of what I said :-). 

This is also why I didn't suggest that we merely replace filtering with lookup. I do think that the most common use of HTTP involves returning a single information object for a single request and, in the case where language negotiation is done at all, these typically fit Lookup more closely than Basic Filtering. A significant subset fit Basic Filtering better. And a different significant subset happen to use Basic Filtering (even if Lookup would have been a better choice) simply because 2616 said to.

> The question is, then, what to do if there is no resource that
> specifies
> those minimum requirements.  Apache in this case applies the lookup
> algorithm
> to loosen the client requirement in hopes of finding something
> usable.

Yes, and this is neither "Basic Filtering" nor "Lookup". Similarly, implementations sometimes make use of outside information (Mark Davis's example of Breton falling back to French, for example). And so forth. The problem, as I see it, is that over-specificity in HTTPbis might lead implementers astray and we really need a more comprehensive treatment of language negotiation so that folks can choose wisely.