Rick and Ted (and other CIP4 Digital Printing WG members, PODi Job Ticketing
WG members, and FSG Job Ticket API members),
There is a one hour PWG (Printer Working Group) Semantic Model telecon this
Thursday, 10-11 AM PST (1-2 EST), to review two IPP documents:
IPP Document Object
IPP Color and Imaging Attributes
(See below how to obtain the documents)
See below for dial-in numbers and webex connections.
The attributes in the IPP Color and Imaging Attributes spec are the ones
just added to the CIP4/PODi/FSG IPP to JDF/1.1, CUPS, FSG JTAPI, PODi
mapping table.
If you want to send comments ahead of the meeting (much appreciated) join
the Semantic Model mailing list (which is needed in order to send email to
the list because of spam), subscribe using the usual Majordomo:
Send to majordomo@pwg.org
with the following in the body of the message:
subscribe sm
end
But you don't need to subscribe to join the teleconference (and your company
doesn't need to join the PWG either, though we welcome your company to do
so).
I'll send out a proposal from Michael Sweet for two additional attributes:
"adjust-hue" (integer(-180:180))
"image-subsample" (type2 keyword)
and a "resample-method" (type2 keyword) counter proposal for the latter in a
separate mail message.
Tom
-----Original Message-----
From: Zehler, Peter [mailto:PZehler@crt.xerox.com]
Sent: Monday, December 02, 2002 11:35
To: PWG Semantic Model WG (E-mail)
Subject: SM> This week's SM teleconference agenda and information
All,
This Thursday at 1pm EDT is the Semantic Model teleconference. The
teleconference is one hour long. It will be run using both phone and Webex.
Anyone that does not yet have Webex installed should do that before
Thursday. Information for the phone and Webex are included below.
The agenda for the Semantic Model teleconference is
1) Status on Semantic Model and associated schema
2) Discuss outstanding issues in the Document Object Specification
The 4 outstanding issues are included below in an excerpt from a mail
note from Tom Hastings
(The document has not been updated since our last conversation. The 6
included issues have been resolved.)
Note that this conversation is IPP specific.
"ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf"
3) Discuss "The Printer Working Group Standard for the Internet Printing
Protocol (IPP):
Color and Imaging Attributes"
"ftp://ftp.pwg.org/pub/pwg/ipp/new_COLOR/pwg5100.8-D01-021018.pdf"
Note that this conversation is IPP specific.
4) Next steps
Pete
Peter Zehler
XEROX
Xerox Architecture Center
Email: PZehler@crt.xerox.com
Voice: (585) 265-8755
FAX: (585) 265-8871
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-30E
Webster NY, 14580-9701
PS to Bob Taylor: Let me know if there is any problem with Webex for this
week.
________________________________________________________
Dial in Info:
Phone Number: (877) 776-6306
(Phone Number for Xerox Employees: 8*594-0576)
PARTICIPANT PASSCODE: 437874#
________________________________________________
webex info:
We will also use an on line tool called webex,
if you have not used this before, setup up by
following the First Time Users instructions.
Do this in advance of the meeting.
-------------------------
FIRST TIME USERS
-------------------------
For fully interactive meetings, including the ability
to present your documents and applications, a one-time
setup takes less than 10 minutes. Click this URL to set up now:
Then click New User.
-------------------------
On Thursday use:
https://hp.webex.com/join/
Then click join unlisted meeting.
Use the info below:
-------------------------
Webex MEETING SUMMARY
-------------------------
Name: PWG Semantic Model
Date: 12/5/2002
Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time)
10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time)
Meeting Number: 21366675
Meeting Password: pwg_sm
Host:
Bob Taylor (HP)
___________________________________________________
_________________________________________________________________________
Document Object Issues:
Pete,
I sent the original note to the SM DL on November 21. Here is the revised
note dropping the suggestion to make Send-Document OPTIONAL. Send-Document
should remain REQUIRED in the Document object spec for two reasons:
1. OPTIONAL operations aren't supported by clients.
2. If the client supplies "ipp-attribute-fidelity" = 'false' or omits it,
the client may as well use Send-Document since the Printer MUST accept it,
rather than the two operations: Create-Document and Send-Data.
Here is the original mail note with edits:
Peter has relayed some concerns raised at the Semantic Model WG meeting in
New
Orleans about low end (non-spooling) Printer support for the Document
object. Those concerns included:
A. Create-Document and Send-Data operations being REQUIRED for a Printer to
support.
B. A client can create "holes" in the document numbering space and send
documents in any order using the "document-number" operation attribute for
Create-Document, Send-Document, and Send-URI. The suggestion was to remove
the "document-number" operation attribute from the specification for all
operations. Then there can't be holes in the document numbers. Make the
client create the documents in the order wanted in the output, so that the
Printer will number them as the client wants. (Also need to deprecate the
"document-number" operation attribute for use with the Send-Document and
Send-URI operations in the PWG Document Overrides specification - IEEE-ISTO
5100.4).
Here is a rather long note that proposes to:
1. eliminate the REQUIRED Validate-Document operation altogether.
2. keep Create-Document and Send-Data REQUIRED (see reasoning below).
3. Remove the "document-number" operation attribute because it isn't needed
since Create-Document would always be available (see reasoning below).
4. Consider deleting the Cancel-Current-Document, since its pretty funky if
"copies" is > 1.
I've discussed this mail note with Gail Songer before sending it. She was
one of the people at the meeting who was concerned about low end Printers
that wanted to support the Document object. She could not find any flaws in
the reasoning in this email note.
Goals and Requirements for the Document object spec:
Goal 1. In order to improve interoperability, we need to eliminate
operations and operation attributes that are OPTIONAL for a Printer to
support. In fact, if an operation or operation attribute is OPTIONAL for a
Printer to support, it is highly unlikely that clients will bother to
support the feature. Also we want to define as small a number of different
ways to submit a multi-document job as possible, as long as they cover the
important use cases.
Goal 2: The Document object should be supportable by a non-spooling low end
printer as well as a higher end spooling printer.
The non-spooling low end printer can't support making copies (except for
really short documents), except for "sheet-collate" = 'uncollated'. Such a
Printer starts to mark document data as it is received. So such a Printer
cannot support "multiple-document-handling" =
'separate-document-collated-copies'.
In principle, the spooling printer can support all values of "sheet-collate"
and "multiple-document-handling".
However, the non-spooling Printer MUST keep the Document object (but not the
data) for the lifetime of the Job. The Printer cannot throw away the
Document object as soon as the Document has been printed, but MUST keep it
until the Job is completed. This requirement means that there is no extra
burden on a non-spooling Printer to have to accept multiple Create-Document
requests for a given job before getting any data. It has to keep all of the
Document objects for the life of the job anyway.
Goal 3. There are two client use cases that the spec needs to support:
Use Case A. A client should be able to validate all the documents in a
multi-document job, before sending the data for any of them. If the Printer
can't support a document or can't support it when combined with other
documents in the same job, the client can avoid sending any data, or decide
with the user which documents to actually submit in the Document Creation
operations.
Usage Case B. A client should be able to validate a document and send the
data, validate the next document and send its data, etc.
Given the above, here are my suggestions for the spec with my reasons:
1. Validate-Document should be removed from the spec (even though Printer's
are REQUIRED to support it in the current version).
If the client performs a Create-Document with "ipp-attribute-fidelity" =
'true', then it is practically the same as Validate-Document. If any of the
supplied attributes or values are unsupported, the Printer rejects the
operation and its the same a Validate-Document. Only if the Create-Document
succeeds, does the Printer actually create the Document object which is
probably what the client would want anyway (Use Case B). (In the unlikely
case that the client didn't want to create the Document object, the client
can do a Cancel-Document operation).
For the Validate-Document case when not supplying the "job-id", the client
can obtain the same functionality by using Validate-Job with each Document
separately, before sending any data (Use Case A).
Another reason to get rid of Validate-Document is because it doesn't
completely allow validation of all documents before sending any data (Use
Case A). For example, if a Printer object represents a one-sided color
printer and a two-sided black and white printer, Validate-Document will not
correctly validate a two-document job consisting of a two-sided black and
white document and a one-sided color job. This is because one of the
Document objects has to be created in order to validate the other Document
in combination. Secondly, if we REQUIRE Create-Document, there is no need
for Validate-Document, since Create-Document creates the Document object and
validates it in the context of the job (without the client sending any
data).
Also eliminating Validate-Document removes another REQUIRED operation
attribute for the Printer to support in Validate-Document, namely, the
"job-id". So the Printer doesn't have to have two validate paths, one for a
document in the context of a job and the other for the document by itself,
thereby simplifying Printer implementation and eliminating another set of
cases to be tested.
I know that the PSI also has Validate-Document, so we'll need to try to
convince them to drop Validate-Document as well.
2. Remove the "document-number" OPTIONAL operation attribute from the spec
for Create-Document, Send-Document, and Send-URI (Goal 1 above). The
"document-number" operation attribute was added to the Document Override
spec per request from Carl Kugler to support sending multiple document data
in parallel (on separate channels) for high end applications. The client
can force the Printer to number the documents by ordering the
Create-Document operations in the desired order and then send the data in
parallel for the documents. In order to meet the requirements of a
non-spooling printer, the client MUST issue the Send-Data request for each
document in order. If the Printer gets a Send-Data out of order (and can't
spool), then the Printer rejects the Send-Data with an error code:
"client-error-documents-not-in-order". If the client had a race between
different threads, then each thread will back off an try again when it gets
this error. If the client is single threaded, then the error indicates a
bug in the client.
3. Keep Create-Document and Send-Data as REQUIRED for the Printer to
support. Then these two operations are the preferred way for a client to
submit a multi-document job. Keeping them REQUIRED means that clients will
bother to support them. If they are OPTIONAL, most clients won't bother
supporting them. Finally, keeping them REQUIRED means that we can remove
the "document-number" operation attribute all together (as in point number 2
above), since Clients that want to submit data in parallel can do so using
multiple Create-Document calls in serial followed by multiple Send-Data
operations in parallel (on separate channels).
Having two operations, one to create the Document object and the other to
send the data, does REQUIRE the Printer to deal with the time-out problem.
But multi-document jobs already have to deal with the time-out problem,
after a Create-Job operation anyway, so timing out a Send-Data the didn't
happen soon enough after a Create-Document shouldn't be much of an extra
burden on the Printer.
After we did IPP/1.1, we wished that we had made Create-Job and
Send-Document REQUIRED, instead of Print-Job. After operational experience,
even Paul Moore regretted that Microsoft had demanded that the IPP WG make
Print-Job be REQUIRED and Create-Job/Send-Document be OPTIONAL. The problem
with Print-Job (and Send-Document) is that the client has to wait to get
back a failure status code in a Print-Job response until after the client
has wasted its time sending all of the data. Lets learn from our
experience with IPP/1.1 on the Job object and not repeat the same mistakes
on the Document object.
However, when the client supplies the "ipp-attribute-fidelity" = 'false' or
omits it, the client can be more efficient by using Send-Document, instead
of Create-Document and Send-Data, since the Printer MUST accept such a
request no matter what attributes and values are supplied. So keep
Send-Document REQUIRED as well.
Here is the list of operations:
Operation Name Printer Printer
support support
V0.1 proposed
Create-Document REQUIRED REQUIRED
Send-Data REQUIRED REQUIRED
Send-Document * REQUIRED REQUIRED
Send-URI * OPTIONAL OPTIONAL
Validate-Document REQUIRED delete
Get-Document-Attributes REQUIRED REQUIRED
Get-Documents REQUIRED REQUIRED
Set-Document-Attributes OPTIONAL OPTIONAL
Cancel-Document REQUIRED REQUIRED
Cancel-Current-Document OPTIONAL delete **?
Delete-Document OPTIONAL OPTIONAL
* The existing IPP/1.1 operations defined in [RFC2911] with an extension so
the client can supply Document Template attributes in a new attribute Group
in the request.
** Cancel-Current-Job is fine, but Cancel-Current-Document is pretty funky
if the job has multiple documents and "copies" is greater than 1.
Comments?
Thanks,
Tom
_________________________________________________________________________
This archive was generated by hypermail 2b29 : Tue Dec 03 2002 - 16:05:09 EST