34. Section 4.2.16, "document-format": Need a reference to the spec for
what can be included in the value of this attribute. I believe that the RFC
is 1521, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms
for Specifying and Describing the Format of Internet Message Bodies" which
has a more recent version. From RFC 1521, the value of the
"document-format" is a "The Content-Type Header Field value". For example,
in addition to the name of the MIME-type, such as 'application/postscript',
or 'text/plain', the coded character set can also be specified as:
'text/plain; charset=us-ascii' or other coded character set names from the
IANA coded character set registry.
RFC 1521 requires the charset attribute, if the media type is text, else the
coded character set shall be assumed to be us-ascii. We either need to
re-state that, or require that the value for "document-format" SHALL conform
to the requirements of a Content-Type Header Field value in RFC 1521 (or
successor). An example would be very helpful.
Being able to specify the coded character set for text formats is
particularly important (since we don't have an attribute for it. Presumably
the values of the "document-format-supported" Printer attribute would
contain the various character sets supported for the 'text/plain' type,
e.g., 'text/plain; charset=us-ascii', 'text/plain; charset=ISO-8859-1'
34a. Section 4.2.16, "document-format": We need to decide whether to
restrict the values to a subset of what is allowed in Content-Type Header
Field. For example, the seven standard types are: text, multi-part,
messsage, image, audio, video, and application. Presumably, any could be
supported, and since we have the "document-format-supported" Printer
attribute, a client can determine which values are supported.
However, what about the "Content-transfer-encoding" attribute, where
different types of Content-transfer-encoding, where the values are:
"7bit" ; case-insensitive
/ "quoted-printable"
/ "base64"
/ "8bit"
/ "binary"
/ "x-token
and presumably utf-8 is a new one?
Listing all supported combinations of media-type and coded character set
makes sense. However, if they all can be supported with several
content-transfer-encodings, then the number of values is the product of the
number of each that are supported. Alternatively, we could add a separate
Printer description attribute: "content-transfer-encodings" supported.
What other capabilities of MIME content headers do we need to consider?