We would have preferred to use the 'charset=..' parameter of the
document format, but there are a number of media types that are
registered that do NOT specify that the 'charset=..' paramater may
be used with them. For example, 'application/octet-stream'
and 'application/vnd.hp-PCL'. While PCL has an optional instruction
inside the document data that specifies the codeset, it is optional,
even when the codeset is different from US-ASCII (or HP Roman-8).
Therefore, we had to introduce the IPP "document-charset" (operational)
attribute. Rather than making it optional, we decided it would simplify
the recipient, if it was required for the sender to always included
and had to agree with the media type charset parameter, if present.
>
>You said something like:
>> Then the Printer
>> object NEED not parse the "document-format" media type
>> attribute value.
>
>(which doesn't seem to be a good use of "NEED", did you mean
>just "MAY" instead of "NEED NOT"?), but I don't get it. The
>Printer (object?) has to look at the document-format if it
>needs to know the document format, doesn't it?
Yes, the Printer does have to look at the value to make sure that it is
supported, but it doesn't have to parse any further once it reaches the
';' character.
We'll just delete the sentence.
>
>> 5. IPP Printer objects NEED NOT support HTTP/1.1 Accept
>> headers and IPP/1.0 does not address the processing
>> semantics for HTTP/1.1 Accept headers.
>
>HTTP/1.1 support for ACCEPT headers is optional, but
>Accept-language and Accept-charset is useful, e.g., when
>determining the language & charsets useful for HTTP
>warnings & error messages. I don't know if "does not
>address the processing semantics for HTTP/1.1 Accept headers"
>is useful advice. Is there an ambiguity?
We thought it was simpler to avoid the complexity of accept headers.
What we have is complicated enough.
Also in IPP, the client can query the server to see what languages
and char sets the server supports before creating a job or making a query.
Finally, IPP, unlike HTTP, the client is supplying language and charset
attributes as input and these attributes are stored on the job object.
Later queries of the job object and notifications use the value stored
with the job (or the Printer default for messages generated by the
Printer, if the stored language or charset is not supported).
Sound ok not to specify the semantics of accept headers?
Should we say that IPP implementations SHALL ignore the accept headers,
if present?
>
>Larry
>--
>http://www.parc.xerox.com/masinter
>
>