IPP Mail Archive: Re: IPP> Making [which-]document-format MANDATORY for

Re: IPP> Making [which-]document-format MANDATORY for

Tom Hastings (hastings@cp10.es.xerox.com)
Mon, 24 Nov 1997 11:46:51 PST

At 08:21 11/20/1997 PST, Roger K Debry wrote:
>I have read through the comments posted by Tom, Bob, and Scott
>and have the following comments:
>
>In general, I think that the proposal is a good one, and I appreciate
>the work done by Tom, Bob and Scott to clarify the handling of
>operation attributes.

snip...

>Section 4.3: Which-document-format attribute name does not
>match the model document, which lists this simply as
>document-format. If the client says "Give me the following printer
>attributes for document-format=IPDS and the printer doesn't
>support IPDS, why is the rule accept and ignore? What does
>ignore mean - not respond? Send back the listed attributes for
>some other (maybe the default) document-format? Either of these
>would be incorrect as far as the client was concerned.

After thinking about this some more, I'd like to make the following
proposal:

1. Rename "document-format" to "which-document-format" as agreed to on
the 11/19 telecon, not to use the same name for an Operation attribute
as for a Job Template attribute when the semantics are different.

2. Clarify that the "which-document-format" Operation attribute is
MANDATORY for a Printer object to support (so clients can always supply).

3. Clarify that the Printer object SHALL return the
'client-error-document-format-not-supported' status code, if the supplied
document format is
not supported (so that the client isn't mislead).

4. Continue recommending that a client SHOULD supply it, else they get
the results for the Printer's default which may be 'application/octet-stream'
which is the "or" of the supported values of the several document formats
that are auto-sensed.

5. Change what support of the "which-document-format" means. Instead of
requiring Printer objects to validate only for the specified document
format, which not many current system do, require the Printer object
to return the supported values that correspond to the validation that it
performs on the create operations:

If the Printer validates according to the document-format supplied in
the create, then the Printer SHALL also return values that are applicable
only to the document format requested in the Get-Attributes operation.

However, if the Printer oject is not that sophiscated (most aren't yet),
then
the Printer returns the attributes for the union of document formats that
it supports.

In other words, if a client queries the Printer, the client can find
all values that the Printer will accept in a create operation with
"ipp-attribte-fidelity" 'true' when the client supplies the same
"document-format" value in the create as it supplies in the
"which-document-format" in the Get-Attributes operation.

snip...

Tom

>
>Roger K deBry
>Senior Technical Staff Member
>Architecture and Technology
>IBM Printing Systems
>email: rdebry@us.ibm.com
>phone: 1-303-924-4080
>
>