ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0897.txt
ftp://ftp.pwg.prg/pub/pwg/ipp/minutes/ipp-0897.pdf
Additionally, I have attached these minutes in text format
below.
Don
**********************************************
* Don Wright don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************
--------
Internet Printing Project Meeting Minutes
August 6-7, 1997
Redmond, WA
The meeting started on August 6, 1997 at 9:10 AM led by Carl-Uno Manros.
These
minutes were recorded by Don Wright. The attendees were:
* Lee Farrell - Canon
* Don Wright - Lexmark
* Steve Zilles - Adobe
* Scott Isaacson - Novell
* Bob Pentecost - HP
* Tom Hastings - Xerox
* Carl-Uno Manros - Xerox
* Stuart Rowley - Kyocera
* Peter Zehler - Xerox
* Greg LeClair - Epson
* Andy Davidson - Tektronix
* Rick Landau - Digital
* Jasper Wong - Xionics
* Jeff Rackowitz - Intermec Corp
* Theresa Rhoades - HP
* Bob Herriot - Sun
* Robert Tonkin - Kinkos
* Paul Moore - Microsoft
* Dave Kuntz - HP
* Roger deBry - IBM
* Ron Bergman - Dataproducts
* Harry Lewis - IBM
* Xavier Riley - Xerox
* Monte Johnson - Intel
* Philip Thambidurai - Okidata
* Zuyi Sacchi - Japan Computer Industry
* Yasuo Bato - Japan Computer Industry
* Atsushi Uchino - Seiko-Epson
* Dave Kellerman - Northlake Software
* Cal Brabrandt - Intel
* Bill Wagner - Osicom/DPI
Carl-Uno Manros reviewed the agenda for the two days.
Scott Isaacson began the technical part of the meeting with a review of
comments
and feedback concerning the model document.
1) "best-efforts" - currently a parameter, not an attribute. Discussion on
the
meaning of "best-efforts", what it means, is it granular enough, what about
a
pre-existing file of PDL? How does "PDL-override" interact with
"best-efforts"?
There was a significant number of participants believe that we would never
be
able to strictly define all the boundaries of "best-efforts" or
"PDL-override"
and that the details would be implementation dependent. We will have two
values
for "pdl-override" -- "attempted" and "not-attempted". For "best-efforts",
"TRUE" and "FALSE" will remain the values. The intent is that
implementation
will do the best job as possible. "n-up" was identified as one of the
attributes that would be very difficult to override with an IPP attribute.
We
decided to change "best-efforts" to be called "fidelity" and we reversed
the
meaning of TRUE and FALSE. TRUE means that the printer will do a really
good
job of guaranteeing fidelity or will reject the job. FALSE will mean that
the
printer has more flexibility in going ahead in printing if all the IPP
attributes cannot be guaranteed. We removed the "best-efforts-supported"
attribute. We will not provide a finer granularity for these
attributes/parameters for version 1.0. Now the discussion moved to whether
"Fidelity" should be a parameter or an attribute. As a result of this
discussion, we decided to remove the "Get-Operations Request" and added a
printer attributed called "Operations-supported" which can be requested and
is a
list of the supported operations. The discussion then moved to whether we
should distinguish between parameters and attributes. At first, there was
no
general consensus as to whether we needed to differentiate these two
values.
Some wanted to keep a separate set of operation parameters and to allow
them to
be found and parsed first. Others felt we could just specify an order of
the
attributes. Eventually, the group came around to an agreement that there
was no
reason to have a separate set of items called parameters. Instead, we will
define the order in which "operation attributes" will appear and that
"operation
attributes" will preceded "job template attributes" which will precede
"document
attributes."
Carl-Uno suggested that we create a flow-chart or something similar that
would
explain the interaction of "fidelity" and "pdl-override" and put it in the
appendix of the model document.
2) "job-problems" & "printer-problems" some editorial changes are being
made to
4.2.2. The issue of what the content of the notification message was
raised.
This of course raised issues of internationalization and whether the
information
should be human readable or machine readable or both. This issue was not
resolved at this time but is listed as one of the open problems.
3) Compression - leave it alone but add some references and perhaps add
some
additional compression types. We also decided that if compression is
supported
by the device, then "zip" must be supported. Because of the various
versions of
"zip" we decided that the "inflate/deflate" versions of "zip" would be
adopted.
4) job-k-octets, job-impressions, and job-media-sheets - the issue is when
is
this data supplied? For example is the data is not provided by the client,
when
is this information supplied by the printer? -- is it counted when the
job is
submitted? -- when the job is complete? -- something else? If this
information is not available, the printer should respond with a negative
integer
meaning unknown (-2). Additionally, these will be added as optional
document
attributes "document-k-octets", etc. These values, when queried, shall
return
the best available value as known by the printer. Therefore if the client
tells
the printer that the job is 1 byte and after the job has been received is
actually 100 bytes, at that point, the printer will respond with 100 bytes
rather than 1 byte. "job-k-octets" and the rest of these objects will not
be
multiplied by any copies value. The exact definitions of these will match
the
definitions in the Job MIB. As a side issue, we talked about creating
separate
attributes for collated-copies and uncollated-copies. Roger deBry will
report
on this proposal.
5) In the job object created when a job is created, we added job-name as
mandatory and made the three objects "time-since-*" as optional and also
made
"number-of-intervening-jobs" optional. We will add two new attributes:
"printer-current-time" and "printer-up-time". "printer-current-time" is
DATE/TIME and "printer-up-time" is in ticks. We changed the three
"time-since-
*" attributes to "time-at-*". We also changed the units to seconds rather
than
milliseconds.
6) Should we make a statement about which attributes should be localized?
Any
keywords are not localized. Scott will be cleaning up some of the
language in
the document. Job-name and Document-name will be returned just as provided
by
the client. After a long and tiring discussion, the group decided to keep
a
human-language attribute on a job, delete all attributes that reference a
character set, and mandate UTF-8.
7) New wording will be incorporated for processing as per Scott's
documented
proposal. Additional job-state-reasons will be included as collected in
the
meeting. Scott will attempt to match a reasonable set of job-states and
associated job-state-reasons.
8) Remove logfile-pending and logfile-transferring as job-state-reason
9) number-of-intervening jobs is an optional attribute that will simply
return
the number of jobs ahead of a specified job.
10) Remove print-uri-user and better define the printer-more-info and other
similar attributes. We came to no conclusion so we will leave this as an
open
issue and expect comments on the mailing list.
11) A long discussion was held about to deal with job identifiers and job
uri's
and how they would be used? -- how they would be mapped back to existing
applications? -- what is the format of a job identifier? -- is it just an
opaque string? -- should a cancel operation be directed to a printer uri or
to a
job uri? The group consensus was that the a job would be identified by two
entities: the printer URI and a 32-bit integer that identifies the job.
Roger deBry reviewed the plans for the Analysts briefing.
The group reviewed the agenda for Thursday prioritizing the Protocol and
Rational document before moving back to the model document.
The meeting recessed at 6PM.
The meeting resumed at 8:45AM on Thursday.
The meeting started with a review of the Rationale document by Steve
Zilles. No
significant issues were raised or discussed.
Xavier Riley reviewed an open issue relating to identification of the user.
One
option is to use a login name; the other is to use the user name obtained
from
the security credentials. The group reviewed John Wenn's recent note to
the
mailing list on this subject.
The consensus of the group was that the Security document does not need to
exist
as a separate document. Rather, the "what" and "why" content of the
document
should be folded into the Model document and the "how" content should be
folded
into the Protocol document. There was a discussion on what is the minimum
security that is required for an implementation to support.
Paul Moore strongly expressed that he believed we should simply state that
IPP
requires whatever HTTP/1.1 requires. Steve Zilles wants IPP to specify a
requirement for support Basic and Digest Authentication. IPP is not going
to
invent security; rather IPP will depend upon the underlying security of the
protocol. The document will clearly identify the security mappings and
usage in
the document as examples and not requirements. A draft addition to the
model
document will be created by Scott Isaacson to talk about how user names
will be
obtained and used.
Mid-morning break.
After the break, we began reviewing the protocol document. We discussed
the
changes that were made to the model that affect the protocol:
1) Elimination of parameters in favor of attributes in the protocol
2) The effects of the change in job uri and job id from the model
discussion on
Wednesday needs to be incorporated into the protocol.
Additional topics of discussion
1) Synchronize or eliminate the two lists of error codes in the model
document
and the protocol document - we will only have the list in the model
document.
2) Tag type additions will be type 2. If there are additional types
identified
now that need to be added, they should be written up and presented at the
September meeting in Atlanta.
3) Paul Moore will look at the HTTP header information contained in the
protocol
document and make sure it is correct. One area that is unclear is in the
ACCEPT
HEADER and CHARSET.
Several other editorial comments were brought up will be included in the
next
revision.
Lunch break at noon.
After lunch, Steve Zilles reviewed the agenda plan for the Munich meetings.
Scott Isaacson resumed reviewing the open issues with the model document.
1) Conditionally Mandatory is not sufficiently well defined in the model
document. The group discussed a number of alternatives including
defaulting
certain values. The group looked at a number of attributes to see if
default
behavior or default values could be assigned.
- priority = 50
- number-up = 0
- multiple documents = single
- sides = 1
- print quality = standard
- finishing = none
- copy = 1
After long discussion, the group decided that the printer attributes (xxx-
supported, xxx-default) will be optional. Scott will update the model
document
to reflect this direction.
Scott will add text to the model document explaining that defaults are the
default at the time the job is processed/printed not the default at the
time of
job submission.
2) MIME types - should we include more standardization of document formats
as
MIME type rather than an enumerated list of document formats and some kind
of
version numbering. Because there was no real solution to completely
identifying
the version of a document format, the group decided not to try to tackle
this
issue at this time.
3) Scott will write a section describing how the IPP model matches up with
the
Job MIB and Printer MIB.
4) For all transmission failures, the system should act as if a cancel was
received at the point of the transmission failure.
5) A null document is a valid document both when it is flagged as "not the
last
document" and when it is flagged as the last document.
6) Registering of new attributes will use a type 2 process.
7) Changes to the order of the attributes, syntax of existing attributes or
the
"mandatoriness" of attributes would change the major version number.
Changes to
the model would be reflected by minor version number changes and changes to
the
protocol encoding would be reflected by the major version number. This
will be
written up in the model document.
8) The "dictionary" attribute type proposed by Tom Hastings will be written
up
and presented with the other new types in Atlanta.
9) Job-originating-user is determined by the server, job-user-label is
supplied
by the client.
10) Leave color as a boolean and consider the extensions for version 2 or
for
vendor extensions.
11) Rather than using the multi-valued job attributes to represent the
attributes of the document as described in the model document in 3.2.6 Get-
Attributes Operation, the document attributes will be group together with
all
the attributes for a single document will be grouped together. This new
methodology will impact both the model and protocol. This will remain an
open
issue and will be worked.
12) We need to add an attribute document-charset attribute which indicates
the
charset of the document.
13) Add Optional filtering in Get-Jobs operation ---- no way!
14) Add job-started-processing as an enum value event to notify-events
attribute
that could cause a notification.
15) job-account-name would be a vendor extension and not a part of the IPP
model.
16) PDF and HTML should be registered as document formats. (EMF will also
be
added by Roger deBry.)
17) Roger deBry requested the Validate-Job be made optional. Paul Moore
explained the reason he wanted it was to prevent sending a large job only
to
find out that the server needed authentication and returning a
www.authenticate.
The group consensus was to leave validate-job as mandatory.
18) The list of operations supported will be a type 2 enum. A range of
enums
will include an experimental range that cannot be registered.
19) in 3.2.6, remove the "none" group.
20) 3.2.7.2 specifies the order of the jobs returned. Should we specify
these
or make them as implementation dependent? There was no obvious consensus
so
this issue was left open.
21) IBM requested additional attributes; these will be written up by Roger.
"page-range" to allow selected a starting and ending page number
"orientation" to change or force a specific orientation
allow the client to define what the "assigned-printer" is so the
server can rip the job and return it to the client's printer
add the ability to specify what is to be printed on the separator
sheet using the "job-sheets" attribute.
Specify printer-location as hierarchical - no that is administrator
specified
We specify toner-low as a job state reason -- should that be more
general - yes, Scott will write up.
Roger proposed to add a media-ready attribute in addition to the
media-supported attribute to be able to distinguish between media
that could be loaded versus what is installed in the printer.
Carl-Uno wrapped up the meeting with a reminder of the next meeting on
September
17&18 in Atlanta. Written documents for that meeting should be made
available
by September 10th. These documents will not be released to the IETF until
after
they are reviewed and updated after the Atlanta meeting. These dates need
to be
e-mailed out and placed on the WEB page.
The meeting adjourned at 6:00 PM.
--------