Comment on draft-reschke-rfc2231-in-http-10 section 4.3

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