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