All,
Here are the resolutions to the Document Object issues that were reviewed at
the Semantic Model Teleconference. Tom Hastings will be updating the
document. Please send any corrections or additional issues to the Semantic
Model and IPP mailing lists.
Next week's telecon will review the "-actual" extension to IPP. See
ftp://ftp.pwg.org/pub/pwg/ipp/new_ACT/IPP-actual-attributes.pdf
Pete
Here are the 18 issues (which are also highlighted in the spec) and the
resolutions:
ISSUE 01: Need to add all new attributes to CIP4/PODi/FSG IPP mapping
document. When?
<PZ> The PWG Semantic Model and Schema are being updated with the Document
Object and will track its evolution. We will wait until the Document Object
is close to completion before bringing it to CIP4/PODi/FSG.<PZ/>
ISSUE 02: Do we want to say which values of "multiple-document-handling" a
Printer MUST support? The defined values are: 'single-document',
'single-document-new-sheet', 'separate-documents-uncollated-copies', and
'separate-documents-collated-copies'.
<PZ> We will not mandate any specific "multiple-document-handling". We will
leave it to implementations to declare which values they support. <PZ/>
ISSUE 03: Are the 3 attributes: 'document-number', 'document-state', and
'document-state-reasons' the right attributes to return when the client does
not supply the "requested-attributes" operation attribute? Should we
include the "document-id-uri" (uri) attribute that the Printer generates as
well?
<PZ> We will return the document equivalent of what is returned in
"GetJobs".
ISSUE 04: OK that we don't have a way to set all documents in a single
request? The Printer MUST reject the request with
'client-error-bad-request', if the client does not supply the
"document-number" operation attribute. There is no way to set all documents
explicitly in a single request, since a failure would require the Printer to
back out all changes in all documents. However, if the client sets the
corresponding attribute at the Job Level using the Set-Job-Attributes
operation, all documents in the job will be affected that don't have that
attribute explicitly supplied at the Document Level.
<PZ> We will not have a way to set attributes in all the documents in one
request. <PZ/>
ISSUE 05: OK, that Cancel-Document operation is OPTIONAL, while the
Cancel-Job operation is REQUIRED by [RFC2911]?
<PZ> The Cancel-Job operation will be mandatory. <PZ/>
ISSUE 06: OK to have the "message" operation attribute supplied in the
Cancel-Document operation be sent to the operator in some unspecified way,
like Cancel-Job, which could include setting the Job's "message-to-operator"
Job Template Job attribute or should we just do away with the "message"
operation attribute in the Cancel-Document operation?
<PZ> The Document operation attribute will be "document-message" in all
cases and it will populate the "document-message" attribute of the Document
Object. <PZ/>
ISSUE 07: OK not to have a "document-message-from-operator" for use with
Document operations, like with the Cancel-Current-Document operation that an
operator is likely to use?
<PZ> The Document operation attribute will be "document-message" in all
cases and it will populate the "document-message" attribute of the Document
Object. <PZ/>
ISSUE 08: Should a Document's "document-state-reasons" keep a Job from
being released with Release-Job? Or should there be no such reasons for the
"document-state-reasons" Document Description attribute? For example, what
about the 'resources-are-not-ready' value of the "document-state-reasons"
Document Description attribute? Or maybe the 'resources-are-not-ready' is
only for the "job-state-reasons" Job Description attribute. Then there
would't be any "document-state-reasons" that affect job scheduling.
<PZ> No value of "document-state-reason" will prevent the release of a Job.
The "document-state-reason" value 'resources-are-not-ready' will be removed
<PZ/>
ISSUE 09: Shouldn't we have both a "job-mandatory-attributes" and a
"document-management-attributes" operation attribute, one for use in Job
Creation operations and the other for use in Document Creation operations?
<PZ> Yes <PZ/>
ISSUE 10: MUST Printer return document-id-uri? See Table 5
<PZ> Yes <PZ/>
ISSUE 11: MUST Printer support document-id-uri? See Table 5
Table entry:
document-id-uri uri MUST? ISSUE 10 MUST? ISSUE 11
<PZ> Yes <PZ/>
ISSUE 12: The "document-name" Document Description attribute is settable by
Set-Document-Attributes (like "job-name")? But It's the only Document
Description attribute that is marked (r/w)? Do we really need to be able to
let a client change the "document-name" with the Set-Document-Attributes
operation?
<PZ> Yes <PZ/>
ISSUE 13: MUST Printer support document-id-uri as a Document Description
attribute?
<PZ> Yes (Note: The PWG Semantic Model has DocumentIdUri in
JobStateElements) <PZ/>
ISSUE 14 OK that we don't have job-message-from-operator as a Document
object attribute?
<PZ> Yes <PZ/>
ISSUE 15: Can we get rid of 'resources-are-not-ready' for the
document-state-reasons, since the Document object isn't scheduled?
<PZ> Yes <PZ/>
ISSUE 16: Should the "document-id-uri" Document Description attribute be
REQUIRED for the Printer to support in any Document Creation operation, as a
way of uniquely identifying a Document object across all Printers?
<PZ> Yes <PZ/>
ISSUE 17: Should we REQUIRE the Printer to accept a "document-id-uri" as an
alternative way for clients to specify the target of Document object
operations? I know that implementers have grumbled about the "job-uri"
being REQUIRED for the Printer to support and accept as the target.
<PZ> No <PZ/>
ISSUE 18: Or should the client be REQUIRED to support some of the Document
operations?
<PZ> No <PZ/>
Peter Zehler
XEROX
Xerox Architecture Center
Email: PZehler at crt.xerox.com
Voice: (585) 265-8755
FAX: (585) 265-8871
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-30E
Webster NY, 14580-9701