Hi Michael,
Next week's SM telecon is cancelled.
But two weeks from now (Thur 5/15) we intend to devote to
addressing your concerns about the Document Object spec.
So, could you possibly explain a little more your various
comments below by email? And (if you can) join the SM
telecon in two weeks?
Today, we decided to break the current Document Object
spec into _three_ specs:
1) IPP Document object - only document specific stuff
2) IPP Extensions for IPPFAX/PSI - only the extensions
needed for PSI and/or IPPFAX (but NOT the higher
REQUIRED conformance for any operation or attribute
- that is left to the IPPFAX or PSI specs themselves)
3) Miscellaneous IPP Extensions - stuff we want to add
to IPP, but not on the critical path for PSI/IPPFAX
We expect that these three specs progress (to Candidate
Standards) in the numeric order above (Document object
first, because it's critical to several PWG standards
and several FSG Open Printing standards).
[I don't understand how you can map Create-Document
to Validate-Job. Could you explain, please?]
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: Mike Sweet [mailto:mike@easysw.com]
Sent: Monday, April 28, 2003 11:08 PM
To: ipp@pwg.org
Subject: IPP> Document Object Spec Comments...
First, given the number of changes/issues, I think we need to do
another revision and review of the spec.
OK, here is a list of problems with the current document object
spec draft:
1. Create-Document and Send-Data are not well thought out.
Assuming that the current Validate-Job operation is
insufficient to validate the document format and job
template attributes for a document file, Create-Job
adds a serious Denial-of-Service vulnerability - just
do a bunch of Create-Job calls to use up all of the
server's resources.
My recommendation is to map PSI's Create-Document operation
to Validate-Job with the additional job/document template
attributes in the spec, and to map Send-Data to
Send-Document.
2. All MUSTs for the document-format-details collection
attributes should be CMUSTs.
3. document-format-details opens up a big can of security
worms, and has very limited usefulness. Like print-by-
reference, "packaged" files sometimes need authentication
(passwords). They also can (and often do) contain embedded
paths which are a serious security risk as well as an
interop nightmare. If the purpose is for supporting web
page printing, XHTML-Print is probably the way to go...
Also, it is not clear how a client is supposed to determine
whether the server supports this attribute; the absense of
document-format-details-supported may not be sufficient
since some implementations (e.g. CUPS) may choose not to
send collection attributes that are not requested to
avoid compatibility problems with clients that do not
support collections...
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Thu May 01 2003 - 19:48:34 EDT