- 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>
> 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 Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture.
Received on Saturday, 18 July 2009 19:59:06 UTC