I just read your issues list (but not the 37-page document yet).
I suggest that PWG specs that are *not* intended to become IETF
specs should instead become IEEE/ISTO specs - in which case they
would carry an IEEE copyright? The PWG process precedes the
adoption of IEEE/ISTO member status, doesn't it? Certainly
it is *not* appropriate to show an IETF copyright on non-IETF
documents and we should *never* publish any Internet-Draft
of a document not intended to be on the IETF 'standards track'.
- Ira McDonald (consulting architect at Sharp Labs America)
High North Inc
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Monday, January 31, 2000 3:21 PM
Subject: IPP> PPE - PWG IPP Production Printing Attributes - Set1 posted
I've posted a proposed set of PWG Production Printing Attributes - Set1 in:
I created the separate sub-directory new_PPE (for Production Printing
Note: At the recent IETF meeting, it was agreed that the new IETF IPP
Extensions WG (IPPEXT) would NOT work on Production Printing Extensions,
since there is little that the IETF could contribute. So it was agreed at
the subsequent PWG meeting, that the PWG would work on Production Printing
extensions to IPP. This is a first contribution. It is on the agenda for
the PWG New Orleans meeting, next week, 2/9 and 2/10.
I took at stab at a pro forma for PWG standards, so take a look at it from
that point of view as well as at the content for production printing.
Here is the abstract:
This document specifies an extension to the Internet Printing Protocol/1.0
(IPP) [RFC2565, RFC2566] and IPP/1.1 [ipp-mod, ipp-pro]. This extension
consists primarily of Job Template attributes defined for submitting print
jobs to production printers. These attributes permit a user to control
and/or override instructions in the document content to perform the
following functions: print on document covers, insert sheets into the
document, provide an accounting id, request accounting sheets, provide job
sheet messages, request error sheets, provide a message to the operator,
provide a job recipient name in cases that is intended to be different from
the job submitter's name, control the media used for job sheets, request
media by characteristic (size, weight, etc.), control collation, and shift
the image. This extension also defines the "current-page-order" Job
Description attribute and the 'none' out-of-band attribute value.
The document is 37 pages long. It uses the 'collection' attribute syntax
There are 5 issues:
ISSUE 01 - Or should there be separate "xxx-supported" Printer Description
attributes for each "xxx" collection member attributes so that Job Template
attributes that have a collection do not have corresponding "xxx-supported"
with a collection? See ISSUE 02 (section 3.10.12) for a concrete example
ISSUE 02 - Some of the attribute syntaxes of the "media-supported" member
attributes are not the same as the "media" member attributes since they
represent what the Printer supports, not what the client is supplying.
Should the member attributes of the "media-supported" collection be
"xxx-supported", instead of "xxx" member attributes?
Alternatively, it would be considerably simpler if the "media-supported"
remained simply a '1setOf (type3 keyword | name(MAX)) and there were
separate Printer Description attributes for each member attribute. For
example, separate Printer Description attributes: "color-supported",
"opacity-supported", etc. But their names need to have something about
"media" in them, say: "media-color-supported", "media-opacity-supported",
etc. If so, should the original names of the member attributes also have a
prefix of "media-color" and "media-opacity", so that the usual simple IPP
rule is take the "xxx" that the client supplies as a Job Template (member)
attribute and add "-supported" to get the corresponding "xxx-supported"
ISSUE 03 - Should we change the name from "collate-sheets" to
"uncollated-sheets", since the absence of the attribute (and non-support of
this attribute) is more likely to indicate collated sheets and so should be
the 'false' value of the attribute, rather than the 'true' value?
ISSUE 04 - Should we move the definition of the 'none' out-of-band value to
the 'collection' specification (ipp-coll), since that document is IETF
standards track, while this one is PWG?
ISSUE 05 - What sort of copyright do we want for PWG documents, if any? The
PWG Process paper says that the intent of PWG standards is to be "freely
usable" and "all PWG Members and Associates shall be free to use all
information received or publicly disclosed from the PWG", so not having any
PWG copyright will make that easier.
Please send comments to the DL.