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

["Phillips, Addison" <[e-mail]>]

> 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.