From martin@opengroup.org Thu Jun 12 00:00:57 1997 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id AAA12065 for ; Thu, 12 Jun 1997 00:00:54 +0200 Received: by mailgate.rdg.opengroup.org; id AA01093; Wed, 11 Jun 1997 23:01:41 GMT Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA15354; Wed, 11 Jun 1997 23:00:48 +0100 Received: from ppp192-153-166-62.rdg.opengroup.org(192.153.166.62) by mailhome.rdg.opengroup.org via smap (V1.3) id sma015348; Wed Jun 11 23:00:32 1997 Message-Id: <3.0.1.32.19970611225446.007e9100@xopuk.xopen.org> X-Sender: martin@xopuk.xopen.org (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Jun 1997 22:54:46 +0100 To: sc22wg15@dkuug.dk From: Martin Kirk Subject: 15068-4 Print Admin Proposed Disp. of Comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" There was a small error in my earlier e-mail. I had 15068-3 in the first para below. This is corrected in this resend, just for the record. Martin SUBJECT: CD Registration for: CD 15068-4: Information technology - Portable Operating System Interface (POSIX) System Adminis- tration - Part 4: Printing Interfaces This e-mail contains the proposed Disposition of Comments for the 15068-4 CD Registration Ballot. The proposal is circulated for a 30-day comment period, and comments are due back to the Project Editor (Martin Kirk, m.kirk@opengroup.org) by July 11, 1997. If no dissenting comments are received, this proposal will be forwarded as the approved Dosposition of Comments. 4 comments were received, and are recorded below, together with the proposed disposition. Only one of the comments (from the Netherlands) contains a substantive issue. =================================== CANADA There is still some concern that this document, unlike most other POSIX documents, is based less on existing commercial implementations and is more of an invention. We also note that a more recent draft needs to be substituted for the draft submitted for registration. DoC: There is now a major, multi-vendor implementation of this specification and the complementary ISO DPA standard 10175. The developers of this implementation are contributors to the development of this standard, and hence their implementation experience is reflected in the development of this document. Regarding the draft to be submitted, see the response to the US comment. =================================== NETHERLANDS Paragraph 4.10.3.1.2, page 158, line 3255-3242. We are not entirely happy with the delete-after attribute. The accompanying text is somewhat confusing. The last sentence stating that the file should not be deleted if an error occurs during printing or the job is removed, seems apply only to delete-after=printing, although this is not stated. Even if it were stated this can still cause problems. Is printing on a machine that forgot to detect it ran out of toner an error? The user will think it is, but the system can not detect this. I think the user should always be prepared to reprint any document and can never rely on the system to detect that a document is printed to the users satisfaction. Therefore it might be better if this attribute was deleted from your specification. The transition to the printing system you propose is a good time to get rid of unnecessary features. DoC: Comments received from implementers of the draft standard are as follows: The POSIX delete-after attribute is one that is implemented by the client, not the server for a number of reasons: Delegation of delete rights to a server is a very tough security problem, whereas the client has access rights to delete the document (probably), if it can read the document, or if the client can't delete the document, its the clients problem, not the server. So the POSIX delete-after attribute has nothing to do with DPA and aligning with DPA. Also remember that POSIX can be implemented completely by a local print system, where delete-after would also make sense. And delete-after=spooling means that the client deletes the file after spooling it to the server. Very useful if the file is huge and a temporary file, such as the .ps file that PowerPoint generates. delete-after is a feature in LPR/LPD, I believe, so that we should keep it so that POSIX can do what LPR/LPD can do. So clarify the delete-after is a pseudo attribute that is not passed to the server (though it might be nice, but not necessary, to pass it for information on queries about the job). Accordingly, the proposed Disposition of Comments is that text should be added to the document to clarify the delete-after attribute is intended for implementation in the client. Additionally, text should added to clarify that the the behaviour of the delete-after attribute is implementation-defined when specific errors occur, as the detection of errors is implementation-dependent. The user should always be prepared to re-submit a job in case there were undetected errors =================================== UNITED KINGDOM The UK notes that the latest available draft should be the one presented for CD ballot. DoC: Regarding the draft to be submitted, see the response to the US comment. =================================== UNITED STATES OF AMERICA The USNB would point out that the version of this document that is subsequently balloted as the CD should be the appropriate IEEE draft document to be in compliance with the approved JTC 1/SC22 Synchronization Plan. DoC: The draft currently being prepared for re-circulation within the IEEE ballot process will be the draft that should be submitted for CD ballot. ---------------------------------------------------------------------------- MARTIN KIRK Apex Plaza, Forbury Road, T H E Reading, UK, RG1 1AX Development Manager E-Mail: m.kirk@opengroup.org O P E N WWW: www.opengroup.org Distributed Systems Management Tel: +44 (118) 950-8311 x2258 G R O U P Fax: +44 (118) 950-0110 Home Phone: +44 (1635) 42888 ----------------------------------------------------------------------------