> After talking with Larry Masinter yesterday, I WITHDRAW my suggestion
> that IPP's 'document-format' attribute be an extended form of a MIME
> 'media-type' (used in 'Content-Type' headers), with an added 'language'
> Larry argues that this fosters incoherence (in IETF standard protocols)
> and forces an IPP Printer (ie, server application) to sometimes PARSE
> 'document-format', in order to construct MIME headers for 'Content-Type'
> and 'Content-Language' (thus 'document-format' would NOT be opaque to
> the IPP server application - this is not good).
> Instead, I suggest we have two MANDATORY attributes for job operations
> (and the Job Monitoring MIB):
> 1) 'document-format'
> - value is 'media-type' (with 'charset' for 'text/*' types)
> - maps one-to-one to MIME 'Content-Type' header
> 2) 'document-language'
> - value is an RFC 1766 compliant language tag
> - maps one-to-one to MIME 'Content-Language' header
> There remains one apparent problem with using MIME 'media-types' (see
> RFC 2046) for IPP 'document-format' - their possible limitation (see
> RFC 2046, section 4.1.2 'Charset Parameter', page 7) to the use of ONLY
> US-ASCII (7-bit) or ISO-8859-X (8-bit) character sets.
Such a restriction only exists in your imagination, I'm afraid. You need to
reread the section you cited. In particular, you should note that the list of
charsets it specifies is an *initial* list. Many other charsets can, and have
been, registered. Over 200 of them, as a matter of fact.
Now, there are a fair number of problems with our current charset registration
procedures, but lack of registered charsets definitely isn't one of them.
> Support for UTF-8 (RFC 2044, IANA registered character set type for ISO
> 10646 folded into a multi-octet 8-bit superset of US-ASCII, is critical
> for IPP documents.
UTF-8 is already registered and hence it is entirely legal to use it
in MIME. See:
> Support for ALL of the IANA registered character set
> types is highly desirable (and coherent with the revised ABNF for MIME
> parameter VALUES specified in RFC 2184).
This issue is being addressed in the new charset registration procedures. See
draft-freed-charset-reg-03.txt (soon to be -04) for specifics.