Tom,
I agree. My only comment is in item 1 below.
Pete
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
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Wednesday, May 14, 2003 6:38 PM
To: iPP at pwg.org
Subject: IPP> Document object spec Conformance ISSUES and proposals for
Operati ons
For discussion at the Thursday, May 15, SM Telecon:
Peter and I would like to propose that a goal for the Document Object spec
itself (the part that remains after having some of it split into two other
specs) is:
Simplify the Document object spec and maximize the interoperability by
having as few OPTIONAL operations as possible.
Thus we propose the following Operation Conformance requirements for the
Document object spec over and above RFC 2911. We'd like to see if there is
general agreement on the mailing list and at the telecon:
1. Remove the Create-Document and Send-Data operations from the spec
(asuming that we can't get agreement to make them REQUIRED). See previous
exchange between Michael Sweet and myself about this minor advantages of
Create-Document and Send-Data and the additional denial of service attacks
that they provide which as the same as Create-Job and Send-Document.
Rationale: A client MAY validate each document individually with
Validate-Job before sending any document data of any of the documents.
However, the added advantage of being able to validate a multi-document job
with dissimilar documents that might not be able to be accepted as a single
Job is not worth having these new Create-Document and Send-Data operations.
<PZ> I agree. Let's get rid of Create-Document and Send-Data.
I've always considered this a corner case. Any Printer can offer this
capability through the use of multi-document jobs, ValidateJob AND page
level Overrides. A complicated way to go when we already have Cancel-Job
to handle the rare case where Documents contain conflicting processing
instructions within a multi-Document Job on a Printer front ending
multiple dissimilar Printers that is encountered.</PZ>
Also Create-Document and Send-Data will require similar defensive
implementation in the Printer for Denial of Service attacks as do Create-Job
and Send-Document.
2. Make Create-Job and Send-Document REQUIRED.
3. Make support of multi-document Jobs REQUIRED.
Rationale: The real advantage of the Document object is for multi-document
jobs. Supporting the Document object only for Print-Job isn't really worth
the implementation cost for the very little end user benefit.
4. Keep the new Get-Documents, Get-Document-Attributes, Cancel-Document
REQUIRED.
5. Keep old Send-URI, and new Delete-Document, and new
Set-Document-Attributes OPTIONAL.
So the REQUIRED extensions from RFC 2911 are:
a. the added Document Template attributes group to the Send-Document (and
Send-URI, if implemented) operation where any Job Template attribute that
applies to an individual document may be supplied.
b. the added corresponding Document Description attributes that correspond
to the RFC2911 Operation and Job Description attributes.
c. The RFC2911 Create-Job, Send-Document become REQUIRED and multi-document
jobs become REQUIRED.
d. The new Get-Documents, Get-Document-Attributes, Cancel-Document
operations remain REQUIRED.
Everything else remains OPTIONAL.
Comments?
Thanks,
Tom and Peter