This document is intended to become an IEEE-ISTO PWG standard.
If after that, we also want to send it to the IETF to
be published an Informational RFC, I believe we can
share the Copyright with them, believe that has been done
We obviously don't intend to include an IETF copyright before
it first has become a PWG standard. I do believe that, when
finished, this document should have an IEEE-ISTO copyright
notice, similar to what the IETF folks put on for the ISOC.
I expect that the IEEE-ISTO people ought to be able to help
us get the proper and legally correct copyright notice on it.
One of the main reasons for joining the IEEE-ISTO was to be
able to copyright our documents, so I don't understand what
the problem is.
> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
> Sent: Monday, January 31, 2000 4:56 PM
> To: 'Hastings, Tom N'; ipp
> Subject: RE: IPP> PPE - PWG IPP Production Printing Attributes - Set1
> post ed
>>> Hi Tom,
>> 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
>> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Monday, January 31, 2000 3:21 PM
> To: ipp
> 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
> 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
> (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
> with a collection? See ISSUE 02 (section 3.10.12) for a
> concrete example
> using "media-supported".
>> 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
> 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",
> 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
> Printer attribute?
>> 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.
> Tom Hastings