Don
----------
Internet Printing Project Meeting Minutes
June 25-26, 1997
Nashua, NH
The meeting started on June 25, 1997 at 8:50 AM led by Carl-Uno Manros.
These
minutes were recorded by Don Wright. The attendees were:
* Lee Farrell - Canon
* Don Wright - Lexmark
* Scott Isaacson - Novell
* Jeff Copeland - QMS
* Bob Pentecost - HP
* Tom Hastings - Xerox
* Harry Lewis - IBM
* Carl-Uno Manros - Xerox
* Stuart Rowley - Kyocera
* Peter Zehler - Xerox
* J.K. Martin - Underscore
* Greg LeClair - Epson
* Chuck Adams - Tektronix
* Rick Landau - Digital
* Angelo Caruso - Xerox
* Bob Von Andel - Allego Software
* Rick Lomicka - Digital
* Jasper Wong - Xionics
* Charles Gordon - Osicom
* Shigern Ueda - Canon
* Frank Zhao - Panasonic
* Richard Hart - Digital
* Sue Gleeson - Digital
* David Kellerman - Northlake Software
* Lloyd Young - Lexmark
* Jeff Rackowitz - Intermec Corp
Carl-Uno Manros reviewed the agenda for the two days. We will have a
conference
call available on Thursday afternoon to discuss protocol encodings.
Scott Isaacson started off the meeting discussion on the Model document.
Scott
reviewed the major updates that were made in the latest version of the
Model
document. The following issues from Scott Isaacson's issues list available
from
the PWG ftp server at
ftp://ftp.pwg.org/pub/ipp/new_MOD/model-issues-970623.pdf
were then reviewed:
1) Cancel a job that does not exist - response is client-error-not-found -
CLOSED
2) Cancel a job without authority - response is client-error-unauthorized
or
client-error-forbidden or in a very secured environment
client-error-not-found -
CLOSED
3) Invalid URI print-uri/send-uri - response is client-error-not found -
CLOSED
4) New status code -> server-error-printer-error - leave in document -
CLOSED
5) New status code -> server-error-write-fault - leave in document - CLOSED
6) Add "spool-space-full" to printer state reasons - Yes - CLOSED
7) Add printer attribute "spooling-space-available" - No - CLOSED
8) HTTP/1.1 has "402 Payment Required", should IPP do the same? - No -
CLOSED
9) HTTP/1.1 405 Method Not Allowed returns an Allow header indicating what
is
allowed. Should we do something similar for invalid IPP operations. - No -
CLOSED
10) See #2 above.
11) Should we put "best-efforts" for IPP attributes concept back into the
model?
- CLOSED
Change existing name of "Best-Efforts" to "pdl-override" and make it
a printer description rather than a job-template attribute
"allow-substitutions" becomes a Boolean in the
TRUE - print anyway even if the attributes can't be supported
FALSE - print only if all attributes can be honored
12) Do we need something like 301 Moved Permanently and 302 Move
Temporarily? -
No - CLOSED
13) printer-resolution - Leave as keywords, everyone should input other
resolutions that should be in the list. Change SHOULD to SHALL. User
interface
may have to parse and translate resolution into localized units. Add units
to
resolution. - CLOSED
14) Get-Jobs response: Jobs are returned oldest to newest for process and
pending jobs and newest to oldest for completed, aborted and canceled jobs.
-
CLOSED
15) See #11.
16) MIME types for document-format - We will register these with IANA in
the
form of "application/vnd.Lexmark-PPDS" and change these from type KEYWORD
to
type NAME. Tom Hastings will investigate the correct format with IANA -
CLOSED
17) See #16. - CLOSED
18) No action by the group required - CLOSED
19) Are attribute group names MANDATORY - YES - CLOSED
20) "Printers" shouldn't return a default value that is does not support. -
CLOSED
20-New: Do we need to define a value for default that is "undefined" -
Dave
Kellerman will investigate.
21) Parameters on an operation may be omitted by the client but must be
supported by the printer. Scott will clarify action by the printer if the
parameter is omitted. - CLOSED
22) Which error codes are MANDATORY for a printer to support? - No need to
specify this in the spec.; this is just basic good design - CLOSED
22-New: Scott is going to remove the HTTP codes from the Model document.
More
work still needs to be done on error codes will be done in the Protocol
document.
23) Change text ANY and name ANY to UTF8 - No - CLOSED
24) Only allow lower-case letters in keywords - YES - CLOSED
25) Suggested syntax for private keywords - We will allow whatever is
allowed in
domain names so vendors can uniquely identify their new keywords. - CLOSED
26) Add job-aborted as an event to agree with the job-states - YES - CLOSED
27) Does printer-problem include when the job is in "pending-held." - YES,
but
not when the job is completed, canceled or aborted - CLOSED
28) How should "multiple-documents-are" treat the concatenation of multiple
files, should a new page be forced? "Single documents" should be
concatenated;
"multiple documents" are not. Comments and suggestions for content and
name
should be posted to the mailing list - CLOSED (but not locked)
29) Change SHOULD to SHALL for "printer-resolution" and "printer-quality"
-- yes, see #13 - CLOSED30) Localization - Scott will develop a list of the text that should be localized - OPEN
- Carl-Uno suggestion: Add a new section that identifies the information that will be returned for asynchronous notification. - Scott agreed to add this.
Break for lunch at 12:50; resumed at 2:30 PM.
31) Too many "shalls" - Replace them with "is" in the terminology section. Any others should be identified to the mailing list. Our conformance statements are probably too stringent; we should probably relax them. - Scott will re-examine whether they are all needed. - CLOSED
32) What is the definition of CONDITIONALLY MANDATORY and what is the "condition" that makes it mandatory? Generally if a feature or operation is implemented in a product then the CONDITIONALLY MANDATORY attribute, etc. shall be implemented. Tom Hastings will review for exceptions to the above. - CLOSED
33) Should we remove the sentence in 4.4 that prevents fan-in? - YES - CLOSED
34) What attributes could be returned in a Print-Job response? Randy has proposed a longer list than what is in the current model document. Only job- name and job-state are to be returned. Everything else can be retrieved using a GET-ATTRIBUTES for that job.
35) Unsupported Attributes and Unsupported Attributes Values will be merged into a single entity. If the Attribute is not supported the response will be "unsupported"; if a particular attribute value is unsupported, the response will be the unsupported value.
36) Cancel-Job response - add job-state and job-name - CLOSED
37) Should we break the write-up of GET ATTRIBUTES into a section on it for
Printer and a section for Job. - YES - CLOSED
38) In section 5.1.10.2, there is a security issue over how much information is returned about other user's jobs. - Leave as is; could also apply to printer attributes as well - CLOSED
39) Section 6.2.3 - Should the "job completion" event include completed without errors, aborted and canceled - YES - CLOSED
40) See #28
41) See #11
42) See #11
43) See #13
44) Name of job-k-octets-completed was changed to job-k-octets-processed - CLOSED
45) Should document-uri be returned in the query? Yes and NONE is the response for a document that had real content. - CLOSED
46) Should we use "partly" and "mostly" in section 6.5.11. -- NO. The adornments need to be changed to be a suffix rather than a prefix. -- CLOSED.
47) Issue on whether all attributes can be categorized as MANDATORY, CONDITIONALLY MANDATORY, etc. For example does a printer that knows about duplexing but doesn't have that feature installed report DUPLEX:NONE rather than not reporting duplex at all - YES - Tom Hastings and Scott will look at where these apply. - CLOSED.
48) Section 7.4 wording needs to be updated with information from the security document. - OPEN
49) Job-state and job-state-reason as posted need to be posted into the model document - Scott will do this - CLOSED
50) Should we call things that are passed in requests and responses that are not associated with attributes "parameters." -- We will generically call things passed back and forth as parameters including things that are or are not attributes/values -- Scott will update the model document. - CLOSED
51) How do default values attributes get associated with a new Job object?
-- They are never associated with the job because we don't want the default values to override the PDL. - CLOSED52) Conformance statements for other operations, i.e. the non-mandatory one, in the model document -- We will omit these until we have implementation experience.-- CLOSED
53) Security Attributes - How do we report/determine the security available/supported/required? Roger Debry has written this up. -- Scott will include Roger's proposal in the next Model document -- CLOSED.
The group reviewed the status codes section of Appendix A of the model document.
- Add an error code "client-error-not-possible" which can be used in the case where someone tries to cancel a job that has already completed. - Change "client-error-unauthorized" to "client-error-not-authenticated" - Keep "client-error-forbidden" as the catch-all which can be used in very secure environments to hide information. - Add "client-error-not-authorized" - Remove "client-error-method-not-allowed" - "entity-too-large" can also apply to the attributes not just the print data - "client-error-unsupported-media-type" should be removed - Change "server-error-operation-not-implemented" to "server-error-operation- not-supported" - remove "server-error-timeout" (This is handled by the protocol by dropping the connection) - remove "server-error-HTTP-version-not-supported" - change name of "server-error-IPP-version-not-supported" to "server-error- version-not-supported" whether the problem can be with either the major version or the minor version. The client has the responsibility to find the highest compatible version between the client and the server. - change name of "server-error-printer-error" to "server-error-device-error" - change "server-error-write-fault" to "server-error-temporary" - We need to make sure the description of all the errors make a statement about possible ways to recover from the error condition. - A general review needs to be made of the operations and determine what kinds of errors might occur. These should be reported to the mailing list and added to the model document. Additionally, error conditions discovered during prototyping need to be added to this list as well. David Kellerman will review the DPA errors to see what might apply.
The meeting adjourned at 6 PM. The meeting resumed at 8:40 AM on June 26, 1997.
Directory Schema ----------------
Issues:
1) Is information that is as variable as Media Ready stored in the directory? - NO - Additionally an object named something like "media available" that would like what could be put in the printer would be placed in the directory. - CLOSED
2) Printer Driver Installer is not in the directory schema - YES, keep it that way. The printer-more info-site or printer-more-info-manufacturer could point to WEB pages that have information about driver installer. Scott will make sure the text for these two objects is correct in both the model document and the directory schema. - CLOSED
3) Cost per page attribute is not in the schema. - Correct. This information should be made available from the printer-more-info-site URI. - CLOSED
4) How is "near my hotel" done? The attribute printer-location is available and could be used to find the "near my hotel" criteria. - CLOSED
5) Should Device ID be in the schema. No, since we don't have the driver installer attribute. - CLOSED
6) What security attributes should be in the schema? Waiting for security sub- group input and this will be inserted in the document -- CLOSED.
7) How does the schema deal with X.500 and similar directory's inheritance. -- The schema will not discuss this since it is implementation specific. -- CLOSED
8) The Directory Schema document should explicitly call out the attribute types and potential values as being those defined in and contained in the model document. - CLOSED
9) Section 2.1 - removed the SHALL; change to "is." -- CLOSED
Security --------
Carl-Uno reviewed the status and work in progress of the security document.
This document was recently published as an IETF draft. Most of the document is an overview of security scenarios and available solution. Section 6.2 contains the current set of recommendations.
Issues: 1. Does asynchronous notification require security? -- OPEN 2. The current model document does not yet include some kind of "security- attribute" for the printer which the printer would populate with the types of security it supports -- OPEN
Protocol --------
Primary topics that need to be included in the protocol document.
1) Operation encoding 2) Status Code mapping 3) Table of HTTP Headers 4) Examples
Operation encoding - three options on the table:
1) Binary encoding bin-length name bin-length value a) "value" is binary or text depending upon the context of "name" b) "value" is always text c) "value" is text or an enumerated value 2) Randy encoding name sp 1-4digits sp value 3) HTTP-like encoding name ":" value CRLF escape special characters inside value (= hex hex) cr is =0D lf is =0A = is =3D
A religious discussion ensued.
At this point, the group was fairly well split between #1 and #3 above with no support for #2.
The group decided that in all cases the "name" are text and not integers. Additionally, the "value" is encoded as text and not integers.
A discussion ensued as to whether we should map keywords to enumerations. This could affect how "value" is encoded in either #1 or #3 above.
Break for lunch at 11:35AM. Meeting resumed at 1PM.
The following people called into the conference call to join the meeting for the discussion of the encoding:
Stan McConnell Ira MacDonald Sylvan Butler Scott Lawrence Dan Codswell Randy Turner
Issues discussed: 1. Is there a value from an internationalization perspective in having the binary length encoding?
After some discussion the group at the meeting took a straw vote that with a strong majority (in fact consensus) in favor of a binary length encoding rather then an HTTP-like, delimiter based encoding. Keyword values currently in the model document will be mapped to enums when well known enums already exist (from the printer MIB, from the JOB MIB, from IANA, etc.) but this group will not go off and create new lists of enums for other attribute values.
We also decided that the following IPP operations are now mandatory and the
model document will be updated by Scott to include this.
For a printer object: 1. Get-Operations 2. Print-Job 3. Validate-Job 4. Get-Jobs 5. Get-Attributes
For a Job Object: 1. Cancel-Job 2. Get Attributes
Details of the Request format:
Byte Major Version Byte Minor Version 2Byte Operation -- repeat 2Byte Length of parameters var parameters -- endrepeat (the last chunk has a length of 0) var data
Details of the Response format:
Byte Major Version Byte Minor Version 2Byte Status (error codes) -- repeat 2Byte Length of parameters var parameters -- endrepeat (the last chunk has a length of 0) var data (If this data is present, there is an attribute "response-format" that says what this data is. This needs to be added to the model document.)
The protocol will operate in a synchronous, lock-step way which means that an application sends a request, then waits for a response before issuing the next request. We will not have transaction ids in the IPP protocol.
Issue: Do "ignored" attributes sent to a server with a job "hang around" if the job is queried. -- OPEN
Work to be done by the protocol group: 1) Finish Operation encoding 2) status code mapping 3) table of HTTP headers (how does IPP uses these) 4) Examples
Review of IPP-LPR mapping document ----------------------------------
There is no intent for anyone to implement a gateway between IPP and LPR. This document is simply informational so that someone that is used to LPR can understand how equivalent functions can be done with IPP.
Tom Hastings went through his new document and discussed it and the issues he identified. Those interested in this area should review and send their comments to the distribution list
Requirements Document ---------------------
Reviewers for the requirement document will include: Carl-Uno Manros Peter Zehler Roger Debry Others are encouraged to feed comments to the mailing list. The goal is to have a new version of the document for the Munich IETF meeting.
Why HTTP --------
Steve Zilles will write an informational RFC about why the group chose to map IPP to HTTP.
Mapping document to LDAP ------------------------
As a lower priority effort, the group would like to start on an LDAP mapping for the directory schema.
Returned to the protocol encoding discussion ---
Bob Herriot made a last suggestion to use the special value of the length of an attribute name being -1 means there are no more attributes in the list. Bob will write this up in the protocol document.
The meeting adjourned at 5:36PM. ----------