IPP> PPE - PWG IPP Production Printing Attributes - Set1 post ed

IPP> PPE - PWG IPP Production Printing Attributes - Set1 post ed

IPP> PPE - PWG IPP Production Printing Attributes - Set1 post ed

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Mon Jan 31 21:00:12 EST 2000


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'.
> Cheers,
> - 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:
> ftp://ftp.pwg.org/pub/pwg/ipp/new_PPE/pwg-ipp-prod-print-set1-
> 000131.doc
> ftp://ftp.pwg.org/pub/pwg/ipp/new_PPE/pwg-ipp-prod-print-set1-
> 000131.pdf
> I created the separate sub-directory new_PPE (for Production Printing
> Extensions).
> 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
> extension.
> 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
> 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 
> "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"
> 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.
> Thanks,
> Tom Hastings

More information about the Ipp mailing list