From m.kirk@opengroup.org Wed Aug 6 13:01:13 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 NAA19786 for ; Wed, 6 Aug 1997 13:01:09 +0200 Received: by mailgate.rdg.opengroup.org; id AA28317; Wed, 6 Aug 1997 12:02:35 GMT Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA05234; Wed, 6 Aug 1997 12:02:00 +0100 Received: from ppp192-153-166-61.rdg.opengroup.org(192.153.166.61) by mailhome.rdg.opengroup.org via smap (V1.3) id sma005216; Wed Aug 6 12:01:53 1997 Message-Id: <3.0.3.32.19970806115420.007e3c70@xopuk.rdg.opengroup.org> X-Sender: martin@xopuk.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 06 Aug 1997 11:54:20 +0100 To: James.Isaak@digital.com, rinehuls@access.digex.net From: Martin Kirk Subject: 15068-4 Print Admin Proposed Disp. of Comments Cc: sc22wg15@dkuug.dk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Disposition of Comments on CD Registration for: CD 15068-4: Information technology - Portable Operating System Interface (POSIX) System Administration - Part 4: Printing Interfaces This e-mail contains the Disposition of Comments for the 15068-4 CD Registration Ballot. The proposal was circulated for a 30-day comment period, which ended on July 11, 1997. No dissenting comments are received. 4 comments were received in the CD Registration Ballot, and are recorded below, together with the agreed disposition. Only one of the comments (from the Netherlands) contained a substantive issue. The changes described below will be incorporated into the document draft currently being prepared for re-circulation within the IEEE, and this draft will be submitted for CD Registration. Martin Kirk =================================== 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 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 is 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 ----------------------------------------------------------------------------