Subject: IPP> MOD - Allow more JT attributes to be document attributes

From: Tom Hastings <[email-masked]>
Date: Wed, 10 Sep 1997 07:45:20 PDT

Subj:  Simple proposal to allow more Job Template attributes to be per-document
From:  Tom Hastings
File:  per-doc.doc
Date:  9/9/97

The latest draft Model document OPTIONALLY allows 5 job template attributes
to be document attributes when Create-Job/Send-Document and Send-URI
operations are implemented:

document-format
compression
document-k-octets
document-impressions
document-media-sheets

as agreed in Redmond.

See the table in section 4.2 and the list in section 4.4.

The table in section 4.2 is divided into two parts, with the above 5
attributes being last in the table.

I talked with Roger yesterday and we'd like to make the following proposal:

1. We'd like to move the boundary up to include the attributes from "media"
down through "page-range" as well.  Thus the following job template
attributes would become optional document attributes along with the above 5:
"media", "number-up", "sides", "printer-resolution", "print-quality" and
"page-range". 

The "finishing" and "copies" attributes already have the
"multiple-document-handling attribute to control their semantics, so maybe
they should remain as job level only.  Then move them up next to
"multiple-document-handling in section 4.2 so that it will be easier for
readers to understand their interaction.  

With the above changes, all of the job template attributes that make sense
for being per-document MAY be supported with Send-Document and Send-URI
operations.

2. Since section 3.3.1.1 indicates that these job template attributes are
OPTIONAL as document attributes, a client needs to be able to tell which are
supported as per-document attributes and which are supported only as job
attributes.  Therefore, we propose adding a "document-attributes-supported"
Printer description attribute in which the Printer returns the keyword names
of the Job Template attributes that it supports as document attributes in
the Send-Document and Send-URI operations.

3. We need to clarify what happens when a client supplies a job template
attribute at the job level in a Create-Job operation and then also specifies
the same attribute (with a different value) as a document attribute in the
Send-Document or Send-URI operation.  We think that the attribute specified
at the document level should override the value of the attribute specified
at the job level, but only for the documents to which the document attribute
is specified.  Thus the job level attribute specifies for any documents that
don't have that attribute specified.

For the three attributes that are counts: "document-k-octets",
"document-impressions", and "document-media-sheets", the value at the job
level, if supplied SHALL be the sum for the entire job, while the value at
the document level, if supplied SHALL be for that document alone.  So for
these three (extensive) attributes, the document level doesn't overide the
job level attribute, but, instead complements it.

4. On Get Attributes, we need to clarify that, depending on implemenation,
the Printer MAY either:
(1) factor out common document attributes and report them as job attributes,
instead of document attributes
(2) return all document attributes at the document level, regardless of how
the client has specified them
or
(3) preserve the job versus document attributes as supplied by the client,
since the semantic interpretation of all three representations of a job
SHALL be the same.

---

From: [email-masked] (Robert Herriot)
Date: Wed, 10 Sep 1997 12:26:46 -0700

As we add more attributes to the document level, we are making
validation more difficult.  With document level attributes it is
possible for CreateJob to succeed and for a later SendDocument to
fail because of an unsupported attribute.  Thus the success of
CreateJob is no longer an indicator of success and ValidateJob isn't
either because it assumes that all attributes are job level.
An attribute supported at the job level may fail at the document
level.

So I ask, are we starting down another slippery slope that should
best wait for some version after IPP Version 1.0? When we just
had document-format, we could mandate that it must be the same for
all documents, as required by some print systems. We could do the
same for compression. But now with document-k-octets, and additional
proposed attributes, things are getting more difficult.

The real issue is whether ALL attributes, even document ones, should be
in the PrintJob/CreateJob operation so that a job can be fully
validated during the initial operation, or should document level
attributes be in the SendDocument operation where it may be more
convenient to send them.  There are pros and cons. I think that we may
find it hard to make an irrevocable commitment at this late hour.

Bob Herriot

> From [email-masked] Wed Sep 10 07:58:34 1997
>

---

From: [email-masked] (Robert Herriot)
Date: Wed, 10 Sep 1997 13:00:25 -0700

If we want to go down the slippery slope that Tom proposes, I have an
alternate proposal to Tom's which avoids some of the problems in his
proposal. My proposal is that the default behavior of a server be for
it to support NO document attributes, but that a server implementation
can support any attribute on a document basis.  This allows servers to
conform to the standard and ignore this whole thorny problem of
document attributes.

If we have the attribute document-attributes-supported that Tom
proposes, an implementation that doesn't support document attributes
need not support this attribute either.

If an attribute-name is a member of the document-attributes-supported,
then the server supports that attribute with either its standard type,
e.g. key-word or with a dictionary value where that dictionary contains
an attribute named "default" for the job level behavior and one
additional attribute for each document which is different. Such an
attribute could be named '1' for the first document, '2' for the second
one, etc.  This leaves all information in the PrintJob/CreateJob operation
for easy validation.

For example, if media is letter for all documents in a job, then its
value is "letter".  If documents 1,2 and 4 four are letter but document
3 is legal, then media is a dictionary with two sub-attributes:
"default" has the value of "letter" and "3" has the value of "legal".
If "media" is not a member of document-attributes-supported or
document-attributes-supported is not a supported attribute in the
printer, the server treats a dictionary type for media as an unsupported
value and either rejects the job (fidelity is true) or does
substitution (fidelity is false).

Should we want to move ahead with Tom's proposal, and I don't know that
we do, then I think that my proposal offers a better way for different
levels of support.

My 2 cents.

Bob Herriot