Attached are the text versions for the meeting minutes. These and a
PDF version will be uploaded to the server this evening. They will be
located in the pub/pwg/ipp/minutes directory as ipp-0697.pdf and .txt.
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 - CLOSED
30) 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. - CLOSED
52) 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.
----------