W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

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

From: Phillips, Addison <addison@amazon.com>
Date: Sat, 18 Jul 2009 12:58:23 -0700
To: John Cowan <cowan@ccil.org>, Julian Reschke <julian.reschke@gmx.de>
CC: LTRU Working Group <ltru@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA01AB843BEC@EX-SEA5-D.ant.amazon.com>
> Julian Reschke scripsit:
> > The intention was to normatively refer to that matching algorithm
> that
> > actually is equivalent to what RFC2616 used to define (remember,
> we're
> > not changing the protocol here). Did we pick the wrong one?
> No, basic filtering is the RFC 2616 algorithm all right.  You might
> consider allowing HTTP servers to do lookup if basic filtering
> produces no results: Apache already does this.

Basic filtering is "pretty much" the 2616 algorithm--in fact, I think we went out of our way to make them compatible. But I think our understanding of language negotiation has evolved somewhat since 1999. There are a number of recommendations and statements in 2616 that suggest that both servers and client applications might tailor their matching behavior, etc.

I think it would be useful and wise to allow for both sorts of behavior. Many application servers use lookup (which is the locale/resource loading protocol for Windows, Java, etc.)

> Is there some reason why you aren't referring to BCP 47?

I think they are trying to be specific about their reference to avoid having <Language-Tag> change underneath them. 

Julian notes:

> The spec does refer to BCP 47: 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-07.html#RFC4647>.

Yes, but not in the same way as it refers to BCP 97.


Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

Received on Saturday, 18 July 2009 19:59:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:50 UTC