Hi Tom,
There should be a separate errata sheet for each PWG standard.
It should have a filename that clearly links it to the base
PWG standard (e.g., 'file-bis' as is used in ITU and ISO
standards and very commonly in updating more recent IETF
RFCs). By the way 'bis' is French, but perhaps this US-centric
organization can live with that. Alternatively, use a suffix
of 'errata'.
Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
High North Inc
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Thursday, February 22, 2001 5:03 PM
To: Bergman, Ron; Carl Kugler
Cc: ipp@pwg.org
Subject: RE: IPP> Typo in Override Attributes for Documents and Pages?
I like Ron's suggestion for an errata sheet for PWG standards.
Should it be a single errata sheet for all PWG standards, or a separate one
for each standard that has one with the file name indicating which standard
it is an errata for and maybe the date in case the same standard has
additional errata.
Presumably the errata sheet(s) would go in the same directory as the
standards themselves, i.e.:
ftp://ftp.pwg.org/pub/pwg/standards/
What about the web page? How should it refer to the errata? Just add a line
next to the standard that has the errata?
Thanks,
Tom
-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
Sent: Thursday, February 22, 2001 10:30
To: 'Hastings, Tom N'; Carl Kugler
Cc: ipp@pwg.org
Subject: RE: IPP> Typo in Override Attributes for Documents and Pages?
Tom,
I suggest adding an errata sheet to the directory for this document
and use to keep track of corrections until the next update. Document
revisions should be kept to a minimum. Maybe 6 months to 1 year
between updates. Some reasonable number should be selected.
Ron
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Thursday, February 22, 2001 9:00 AM
To: Carl Kugler
Cc: ipp@pwg.org
Subject: RE: IPP> Typo in Override Attributes for Documents and Pages?
Carl,
I agree, that you've found a typo. I would hope that we could fix PWG
standard problems like this as soon as they are found and re-post on the PWG
web site.
How should we indicate such an update?
Do we want to wait for a short period of time to see if any others are
found?
Comments?
Thanks,
Tom
-----Original Message-----
From: Carl Kugler [mailto:kugler@us.ibm.com]
Sent: Thursday, February 22, 2001 07:21
To: ipp@pwg.org
Subject: IPP> Typo in Override Attributes for Documents and Pages?
> 9.2 Send-Document and Send-URI Operation Requests
> Attributes are added to the Operation Attributes group.
>
> Group 1: Operation Attributes
>
> "input-document-number" (integer):
>
> The client OPTIONALLY supplies this attribute in order to
> inform the printer about the order of documents when the
> printer is sending the Input-Documents asynchronously.
What does that mean: the "printer" is sending the Input-Documents?
Shouldn't that be "client"?
-Carl
---------------------- Forwarded by Carl Kugler/Boulder/IBM on 02/22/2001
08:18 AM ---------------------------
Carl Kugler/Boulder/IBM@IBMUS@lists.sourceforge.net on 02/21/2001 04:56:56
PM
Sent by: lpr-discuss-admin@lists.sourceforge.net
To: Danek Duvall <dduvall@eng.sun.com>
cc: Ben Woodard <ben@valinux.com>, lpr-discuss@lists.sourceforge.net
Subject: Re: [Lpr-discuss] Re: job and document semantics
> Documents within an IPP job do not have any sense of ordering.
There is an IPP extension that does allow the client to specify the order
of documents. See:
Internet Printing Protocol (IPP):
Override Attributes for Documents and Pages
IEEE-ISTO Printer Working Group
Standard 5100.4-2001
February 7, 2001
(ftp://ftp.pwg.org/pub/pwg/ipp/new_EXC/pwg5100.4.doc [and .rtf and .pdf])
9.2 Send-Document and Send-URI Operation Requests
Attributes are added to the Operation Attributes group.
Group 1: Operation Attributes
"input-document-number" (integer):
The client OPTIONALLY supplies this attribute in order to
inform the printer about the order of documents when the
printer is sending the Input-Documents asynchronously. The
first Input-Document is 1, and subsequent Input-Documents are
numbered sequentially. If the value of "last-document" is
'true', then the value of this attribute is also the total
number of Input-Documents in the Job. If a client supplies
this attribute in one Send-Document or Send-URI operation in a
Job, it MUST send it in all such operations. A Printer deals
with missing Input-Documents in the same way as without this
attribute except that a time-out can occur with
Input-Documents anywhere in the Job. For example, a Printer
could receive Input-Documents 1 and 3 and not 2.
Danek Duvall <dduvall@eng.sun.com>@lists.sourceforge.net on 02/15/2001
04:34:02 PM
Sent by: lpr-discuss-admin@lists.sourceforge.net
To: Ben Woodard <ben@valinux.com>
cc: lpr-discuss@lists.sourceforge.net
Subject: [Lpr-discuss] Re: job and document semantics
On Thu, Feb 15, 2001 at 03:10:35PM -0800, Ben Woodard wrote:
> That makes things a lot easier. The only thing we have to pass is the
> IPP job ID. Do the send-documents have to be in any particular order
> for them to be processed by IPP appropriately.
Documents within an IPP job do not have any sense of ordering. That is,
you don't say `send document 4', you just send a document. The order they
come out on paper is the same as the order in which you send them, except
that you might request collated or uncollated copies (i.e.: "a b a b" or
"a a b b") and how things are stapled together (i.e., are a and b stapled
together, or is a one bound thing and b another).
Wendy & Norm -- I was wrong about the complete lack of ordering. The spec
(section 2.4.2 of RFC 2911) says that the document order "MUST be" either
"a b a b" (collated) or "a a b b" (uncollated).
Danek
_______________________________________________
Lpr-discuss mailing list
Lpr-discuss@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/lpr-discuss
_______________________________________________
Lpr-discuss mailing list
Lpr-discuss@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/lpr-discuss
This archive was generated by hypermail 2b29 : Fri Feb 23 2001 - 14:55:18 EST