> 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.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.