I've been thinking about this, also in the light of
comments made in some other internet media type registration
discussions, and I've come to the conclusion that it is
probably a bad idea to rely on the 'charset' attribute of
the 'application/ipp' media type *or* the content-language
attribute of the enclosing MIME message.
While those are the conventional ways of specifying the language
and charset of media types which are not self-contained,
that in fact (as was pointed out by others) it's pretty
unreliable, since the MIME headers can get separated from
the entity body. It's a stopgap for those types like
text/plain which have no other place to put the information.
Since you're defining application/ipp from scratch, this
rule doesn't apply.
On the other hand, it baffles me to try to construct a realistic
scenario where there will be many different charset parameters
for different strings in a single application/ipp message.
Why not just have some part of the wrapper define the default
charset for the entire message?
> It is NOT reasonable to transfer IPP requests and their
> correlated responses via email - they are synchronous and
> have no correlators, as the model and protocol are written.
Email itself has a correlator, mainly the message-id and
in-reply-to link. I send you a message with a message-id, and
you reply with an in-reply-to header. It's pretty clumsy,
I'll admit.
Larry
--
http://www.parc.xerox.com/masinter