- From: Chris Newman <Chris.Newman@Sun.COM>
- Date: Mon, 22 Mar 2010 16:32:33 -0700
- To: julian.reschke@greenbytes.de, ietf-http-wg@w3.org
- Cc: Ned Freed <ned.freed@mrochek.com>
RFC 2231 did not allow two parameters with the same name but different languages, at least in the context of continuations that was impossible. Absent continuations, RFC 2231 was otherwise silent on that topic. So section 4.3 adds a new feature over and above what RFC 2231 did. It's a feature that will make implementations significantly more complex and is likely to cause interoperability problems. Much of the experience with deployment of both language tagging and language variants in the IETF seems to result in unnecessary complexity. While there are good abstract arguments for language tagging in theory, it seems more often than not that the parties in the exchange are unable to put anything useful in the field in which case it falls into the realm of unnecessary complexity. In addition, we have experience where we attempted to allow language variants (multipart/alternative) and not only did that usage not deploy, it is actively broken despite being an explicit example in RFC 1766. The one place where I've seen language variants mostly work is when the language tag is actually included in the attribute name (LDAP does this) and the "search" mechanism allows wildcarding of languages. But having two attributes with the same name seems dangerous. My recommendation is to remove this feature as I believe it will not be used in practice and will add unnecessary complexity that is likely to create interoperability problems. - Chris
Received on Monday, 22 March 2010 23:33:05 UTC