From rinehuls@access.digex.net Thu Aug 7 18:34:42 1997 Received: from access2.digex.net (qlrhmEbBUV1EY@access2.digex.net [205.197.245.193]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id SAA13329 for ; Thu, 7 Aug 1997 18:34:41 +0200 Received: from localhost (rinehuls@localhost) by access2.digex.net (8.8.4/8.8.4) with SMTP id MAA07802 for ; Thu, 7 Aug 1997 12:34:21 -0400 (EDT) Date: Thu, 7 Aug 1997 12:34:21 -0400 (EDT) From: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2544 - Disposition of Comments Report on CD 15068-4 Registration - POSIX System Administration Printing Interfaces Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ___________________ beginning of title page _________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2544 August 1997 TITLE: Disposition of Comments Report on CD Registration for CD 15068-4: Information technology - Portable Operating System Interface (POSIX) System Administration - Part 4: Printing Interfaces SOURCE Secretariat, ISO/IEC JTC 1/SC22 WORK ITEM: JTC 1.22.21.03.03 STATUS: N/A CROSS REFERENCE: SC22 N2211, N2348 DOCUMENT TYPE: Disposition of Comments Report ACTION: To SC22 Member Bodies for information. Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Tel: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net __________________ end of title page; beginning of report __________ Disposition of Comments on CD Registration for: CD 15068-4: Information technology - Portable Operating System Interface (POSIX) System Administration - Part 4: Printing Interfaces 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. =================================== 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. ______________________ end of SC22 N2544 ____________________________