Subject: SC22 N2544 - Disposition of Comments Report on CD 15068-4 Registration - POSIX System Administration Printing Interfaces

From: "william c. rinehuls" <[email-masked]>
Date: Thu, 7 Aug 1997 12:34:21 -0400 (EDT)

___________________ 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:  [email-masked]

__________________ 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 ____________________________