Here are the meeting minutes from the Spetember Meeting in Atlanta.
I have also posted these to the ftp server as:
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0997.txtftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0997.pdf
Don
**********************************************
* Don Wright don at lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************
------ Minutes
-------------------------------------------------------------
Internet Printing Project Meeting Minutes
September 17-18, 1997
Atlanta, GA
The meeting started on September 17, 1997 at 8:40 AM led by
Carl-Uno Manros. These minutes were recorded by Don Wright.
The attendees were:
* Randy Turner - Sharp
* Ron Bergman - DataProducts
* Xavier Riley - Xerox
* Peter Zehler - Xerox
* Lee Farrell - Canon
* Yuji Sasaki - Japan Computer Industry
* Philip Thambidurai - Okidata
* Bob Pentecost - HP
* Rick Landau - Digital
* Richard Hart - Digital
* Lloyd Young - Lexmark
* Dale Wick - TrueSpectra
* Bill Wagner - DPI/Osicom
* Jeff Van Wie - Kodak
* Bob Herriot - Sun
* Don Wright - Lexmark
* Harry Lewis - IBM
* Steve Zilles - Adobe
* Mabrey Dozier - QMS
* Roger deBry - IBM
* Tom Hastings - Xerox
* Scott Isaacson - Novell
* Carl-Uno Manros - Xerox
Carl-Uno Manros reviewed the agenda for the two days.
Scott Isaacson reviewed the decision from the last
conference call to stop adding functionality and hold
additions for a version 2.0. At that call, we decided not
to make any of the job template attributes also document
attributes. Additionally, IPP V1 will have NO ATTRIBUTES
for documents including no longer having a document name.
Scott went through his list of issues which were posted to
the FTP server (ftp://ftp.pwg.org/ipp/new_MOD/issues-
970916.pdf).
1) Cancel semantics: trailing edge, new job-state reasons
from Tom Hastings.
2) Global: MUST, SHOULD, SHALL editor will fix
3) Global: Directory document will become an appendix to the
model document
4) Global: URI versus URL: leave as URIs. We will include a
requirement that the printer must support an http scheme
URL. If notification is supported then you must support at
least the mailto scheme.
5) Get-Jobs operation: What order are jobs returned? There
were a number of arguments on both sides of this issue. Not
all OS's return jobs in the same order. The document will
state that pending jobs SHALL be returned in the expected
order of execution. Completed jobs SHALL be returned with
the most recently completed jobs returned first. A enum
attribute will be added to specify whether the request is
for pending or completed jobs. Pending Held jobs are be
included as active jobs. Where they are included in the
list is implementation dependent.
6) References to Printer MIB and Job Monitoring MIB: We
will include references to these documents but not indicate
whether they are I-Ds or not.
7) Attribute Syntax: Text attributes are specified as 1 to
4095 characters. Anything that might be expected to be
exported to a MIB would need to be up to 255. -- Leave as it
is.
8) URL versus URI - see #4 above.
9) Attribute Syntax - date/time - reference the correct RFC
- Scott will do this.
10) Job Template Attributes: Job Priority - All
implementations must accept on the wire values of 1 to 100
and map them evenly to the internal priority levels. An
administrator can limit the range a particular user can
assign to his job. (100 is the highest priority.) How a UI
maps from the user to the wire is outside the scope of this
effort. Scott will write it up in the document as described
here.
11) Event Notification Content: Job-State Message and
Printer-State Message will be UTF-8 encoded ISO10646
characters in the human language negotiated.
12) Document Format: Change "mimeType" to "MediaType" and
reference RFC2046.
13) user-human-language: should be renamed to job-user-
human-language? - No - This is a job template attribute
which we currently plan to use information from the HTTP
headers (general or application/IPP?) to set this value.
Steve Zilles will write this up for inclusion in the model
document.
printer-name: need not be translated (set by admin)
printer-location: need not be translated (set by admin)
printer-description: need not be translated (set by admin)
printer-make-and-model: should be translated (set by mfg)
printer-state-message: translated (computed)
job-name: not translated (set by user)
job-state-message: translated (computed)
job-message-from-operator: need not be translated (set by
oper)
The typical internationalization religious discussion
ensued. Scott will update the model document to change the
definition of attribute syntax type text and name to include
a "language tag" (RFC2184) to precede the actual body of the
text returned. This is for both server and client created
text and names. The client will be able to ask for a
certain language from the server using the accept header
from HTTP. Implementations may need to remember the
language request so that notification or an event is
returned in the requested language.
14) time-since-pending/processing/completed -- perform the
editing change suggested and time will be in seconds and not
ticks.
Lunch Break: 11:30 - 1:00
Job-URI versus Job-id
At 1:00 we began the conference call to discuss the issues
of Job-URI versus Job-ID issue. Some of the issues were
listed:
1) Existing, job-id oriented APIs
2) Potential Object-oriented APO
3) Gateways
- IPP client <-> legacy system
- Legacy client <-> IPP Printer
4) Redirection
5) Scalability
6) "Helper" Attribute could return the numeric job id
The issue of the value of being able to see jobs submitted
via some legacy means as well as IPP submitted jobs using
IPP was discussed. Some participants felt that it is
necessary to expose all jobs submitted from any means while
others believed that this need was only temporary until
clients moved to IPP from the legacy environment.
How do we resolve the difference between the way the Job MIB
reports jobs versus a Job-URI?
Since the Job MIB provides more information such as which
page of the current job is printing, a client might want to
use the Job MIB to get these details that are not available
using IPP. How do you correlate the Job-URI with the JOB
ID?
We could add an attribute to the JOB MIB that would be the
JOB-URI -- Hastings
We could mandate a job id to be a part of the Job-URI using
some delimiters - P. Moore
For the cancel job case, the client must know how to build
the URI for the job if the URI is not retained just the
numeric job id - P. Moore
What if we provided two ways to identify the job:
1) job-URI
2) Printer-URI plus job-id
job-URI Discussion Conclusion:
All IPP printers shall generate, store (with the job
information) and return both the job-URI and a 32-bit job-id
on Print-Job, Print-URI or Create-Job. It will accept all
job operations (cancel-job, send-document, send-uri, and
get-attributes) on either the job-URI or on the Printer-URI
plus the job-id. Clients can utilize either method, i.e.
they can reference a job using the job-URI or the Printer-
URI plus the job-id. IDs are only meaningful in the context
of the Printer-URI to which it was originally submitted.
Get-Jobs will have to return both job-URI and job-ID as the
default. Scott will write this up in the model document.
If an "IPP printer" also implements the Job MIB, then the
job-id will be the same between the MIB and IPP.
- After the conclusion of the job-URI discussion, we
reviewed some of the
directions set during the morning session with those on the
conference call.
- While the conference call was still open, we discussed the
use of a port besides 80. It was the consensus that we
would not mandate an alternative port number but we would
not preclude some implementations from using alternative
ports. The protocol document should make a statement that
by default IPP should be supported by servers and clients
over port 80.
Model Issues:
15) Change PDL Override back to Boolean -- no
16) Covered by #13
17) Delete appendix C and reference IANA MIME registry: yes,
but include a couple of examples in the actual attribute
section.
18) Addition of document-formats-detected: No - if the
client knows the document format then it should use that
attribute and not depend on auto-sensing.
19) If Create-Job is supported then Send-Document must be
supported and Send-URI is optional.
20) No document level attributes - yes
21) Delete orientation as a job attribute - no - we will add
reverse landscape -- these only apply to the case of simple
text.
22) Compression - IPP will support none, compress, gzip and
deflate
23) Any character from ISO10646 (level 2) will be encoded in
UTF-8.
24) What does the server do when a time-out occurs after a
create-job?
- delete? (This action could depend on the fidelity
setting)
- close and hold?
- close and schedule?
Scott will document these cases and the ramifications.
25) Is any notion of time (absolute, relative) mandatory?
- absolute time is not mandatory
- relative time is mandatory
26) "media-ready" versus "media-supported"
There was a long discussion on the value of a "media-
supported" attribute so that a media that could be loaded by
an operator would be available to the client to choose from.
If a job is submitted with FIDELITY=TRUE and the media
requested is not in either list (media-ready or media-
supported) then the job would be rejected. If the media is
supported and not ready, the job would be held until the
media is loaded. If FIDELITY is not TRUE, the job would be
printed on the best available media. Scott will write this
up for immediate review.
27) Delete syntax for "copies-supported" - We will leave it
as it is and add an attribute "collated-copies-supported"
that would be available if the printer supported collating
copies.
28) Support for ftp and http schemes are required for all
IPP printers that implement Send-URI and Print-URI.
Document-URI-schemes-supported will not be implemented for
V1. User name and password from the ftp URL will be used if
provided otherwise anonymous will be used. The printer
should check for a supported scheme and reject unsupported
ones (a new error code is needed.)
29) Confusion over the group "printer-description" versus
the actual "printer-description" attribute. Scott will
document a change to remove the ambiguity.
30) Change "color-supported" to provide more information --
no change for V1.
31) Editorial: operations are changed to be like type2
enums and the pseudo-keywords will follow the keyword
syntax.
32) Status Codes and Operations will look like a type2 enum
but the name space will be managed separately from other
type2 enums. Scott will clean up this and #31 in the next
document.
33) Job-URI versus Job-id : see discussion and conclusions
above.
34) Need some text distinguishing minor version number
versus major version number. A change in the major version
implies a significant structural change while a minor
version can be parsed around and properly ignored. Steve
Zilles will submit some proposed wording for inclusion.
35) See #28 above.
36) Document attributes: document attributes are gone.
37) Default Job Template Attributes should not be treated as
PDL overrides.
38) If Fidelity is false and attributes are ignored, should
the response indicate what attributes were ignored? Yes -
document in the model document.
39) Same as #38.
40) See #19.
41) What should be used for media type when PDL is
automatic?
* When document format is missing then default is used.
* When application/octet-stream is sent to the printer the
printer does its best to figure it out and print it.
* Application/octet-stream is valid as the default and
means use the auto-sensing mechanism.
42) The last-sent document can be an empty document. In
fact any document can be empty. An empty document does not
print a blank sheet; however it will cause a partial sheet
to be printed.
43) The last-document attribute (either true or false) must
be included in any send-document or send-uri and is an error
if omitted.
44) If the printer implements the job-state-message then it
must return it in the Create-Job, Send-Job, and Send-URI
response.
45) "message-to-operator" operational attribute: keep
46) -- This number was skipped --
47) Document attribute issue - all document attributes
removed
48) Attribute Syntax assignments: Scott will not have
assignments in the model document. They will be in the
protocol document.
49) Delimiter Tag enums: These will also be in the protocol
document.
The meeting adjourned at 5:35PM
The meeting resumed at 8:30AM, working through the Model
issues.
50) Should the enum values be in decimal or hex. -- leave
them in hex.
51) Resolution attribute syntax: Will be fixed by Scott.
52) Does '1setOfX' attribute syntax need to indicate whether
order is important? : Yes, a statement will be added
53) Does 'rangeOfX' need to specify that lower is first: yes
54) Should notify-addresses have a default value? NO
55) printer-resolution should be of type resolution: Yes
56) Should compression have a default value? Don't need it;
client specifies any compression, default doesn't make
sense.
57) Job-sheets: When the client provided job-sheets is
invalid and FIDELITY is true then the printer will reject
the job.
58) Add printer-state-message as an optional field in event
notification content: OK
59) Event Notification Content -- What printable format is
time in? Scott will reference the RFC which defines an
ASCII format for time. Scott will move this to the optional
items at the end of the list.
60) Event Notification Content needs to be
internationalized: All 'text' and 'name' will be
internationalized with the language tag at the front of the
string.
61) 'multiple-document-handling' and slip sheets: Job-
sheets will be multi-valued. We will not, at this time, add
slip-sheets since this is type4 but it could be added later.
62) 'number-up' will be changed to a type 'setof' integers.
The lower bound will be 1. Borders on n-up images will be
implementation dependent. Scott will clean up the
definition of what 'logical' pages are based upon a
suggestion from Steve Zilles. Interaction of n-up,
orientaton, duplex and finishing need to be discussed in the
document -- Steve Zilles will send a draft to the list for
review.
63) IPP should explain printer resolution rather depending
upon the MIB - Yes
64) print-quality: Change to say that the value of the
attribute SHALL be used for the job -- ok
65) In the orientation section, change langSimpleText to the
right MediaType -- ok
66) orientation -- added reverse landscape and see Tom
Hasting write-up sent on 9/16, subject: MOD - ISSUES in
09/03 Model document.
67) "document-name" mandatory? - no document attributes
68) Should job-URI be a Job Status Attribute? -- It is now
returned as an operation attribute. Scott will change this
and add job-id to be just a job attribute that is returned.
Add 'number of intervening jobs' as an optional attribute
returned on the create request.
69) Generic Alerts from the Printer MIB - Peter will list
them and Scott will add these as additional printer events.
70) What about Media-Ready: covered as #26
71) Compression: covered as #22
72) Job URI versus job-id: covered in conference call on
Wednesday.
73) job-name versus job-user-label: No, we will have no job-
user-label
74) "user-human-language" fixed yesterday as #13.
75) New 'processing' description: New proposal from Tom
Hastings to be added with some additional clarification.
76) Show partitioning of state reasons with states -- No
77) see #76.
78) printer-up-time mandatory - yes
79) Proposal to fold the security document into the model
document - Scott will merge the documents and the result
reviewed by the working group. We will state that an IPP
printer must support all required authentication security
specified in HTTP/1.1 (change in protocol document). (Carl-
Uno reported that TLS will probably become a proposed
standard in the next few weeks.) After some discussion, the
group came around to the fact that in order to read what
security means are supported, you must already have made a
connection to the printer because the security mechanisms
are at the HTTP level or below and not at the IPP level. The
group did not want to include a mandate for TLS or TLS
framing as a part of IPP. The attribute "security-
mechanism-supported" is removed. We will add an attribute
"printer-tls-uri" which will have the uri for accessing the
printer in a TLS secure mode. If a server does any
security, it SHALL support TLS. If additional security
means are provided, we must add additional attributes.
Randy Turner will investigate and report on the
interoperability between SSL and TLS.
The security document mentions that the IPP printer must be
aware that a virus could be contained in the print job. How
that is to be prevented is not addressed by IPP. The
document should make this clear.
80) server-error-device-error: This error would only be
returned if the device error prevents the create from
happening. For example, if a printer doesn't spool and has
a limited buffer and the create can't happen because of a
device error (e.g. paper jam) then this error would be
returned. In the case of an IPP Printer with spooling, this
error would not be returned.
81) langAuto -- covered in #41.
82) Relationship to Printer MIB: If an implementation
chooses to have both IPP and the Printer MIB, a specified
set of attributes/object shall be identical. Harry Lewis
will draft this wording.
83) Relationship to Job MIB: If an implementation chooses to
have both IPP and the Job MIB, a specified set of
attributes/object shall be identical. Harry Lewis will
draft this wording.
Lunch break: 11:45 until 1PM
84) Proposal on tags (Attribute, Parameter, Data) in the
protocol now that Parameters are gone. -- After discussion,
we felt it was cleaner to have separate tags to divide up
the various sections of attributes:
- Operation Attribute Tag
- Printer Attribute Tag
- Job Attribute Tag
- Unsupported Job Attribute Tag
- Data Tag
By having separate printer-attribute and job-attribute tag
we can add a document-attribute tag or something else later.
This strategy will make parsing easier. Any Data-Tag would
be last; any Operational-Tag would be first. Each operation
will explicitly list the order of the tags. Scott will
document this approach and include explanation of why
various attributes are in each category.
More issues from Tom Hastings iss-903a.doc file. Starting
with issues 34.
TH34) Finishing and orientation: Will be covered by Steve
Zilles in his orientation, n-up, etc. document.
TH34a1) See RFC2046
TH34a2) Not applicable
TH35) user-human-language -- already covered in #13
TH36) job-id: will be positive number
TH37) user-human-language -- already covered in #13
TH38) job-state -- leave as type 1
TH39) time-x-x change from milliseconds to seconds - yes,
already decided
TH40) number-of-intervening-jobs: align with JOB MIB - yes
TH41) We will align k-octets, impressions and sheets with
the Job MIB.
TH42) Change the name of printer-description to printer-info
as decided in #29 above.
TH43) Copy some language from printer-driver-installer to
printer-make-and-model & others: Yes
TH44) Add text to indicate there should be an error reason
when the printer is "stopped."
TH45) Scott will add text to the document.
TH46) We have previously agreed not to align with the JOB
MIB in the area of defining what an active job is. See #5.
TH47) printer-human-language: Already decided in #13
TH48) Color: Already decided as #30
TH49) Internationalization: already decided in #13
TH50) Indicate that supported values might require human
(i.e. operator) action. An example of this should be
included in the completed description. -- OK
TH51) Add a suffix to some attributes (-supported) to make
it clear whether an attribute is default or supported -- OK
When we add this suffix, the base attribute name will not be
changed for grammatical reasons.
SECURITY
There are reserved port numbers for TLS & SSL on HTTP (port
443)
TLS is backwards compatible with SSL3. Actually TLS is
SSL3.1 The TLS I-D describes how to support SSL3
interoperability.
The group then discussed wording choices for stating the
security protocol requirements (SSL3, TLS, etc.) There were
four wording alternatives explored:
1) IPP Client/Servers must implement TLS with SSL3
compatibility
2) IPP Client/Servers shall be interoperable with a TLS
communicant
3) IPP Client/Servers must be TLS compliant.
4) #2 above plus "with SSL3 backward compatibility"
Decision: #1 with some section talking about a transition to
TLS.
PAGE FORMATING (N-UP, ORIENTATION, Etc.)
Steve Zilles presented material on this subject. Steve will
detail this more and post to the mailing list. Because all
the interactions with finishing will not be defined for V1,
the following enums for finishing were removed:
5,6,7,8,9,10. These values could be added back in for V2
when more work has been done to define them. The values for
punch, cover and bind will be moved up. While some
languages bind on the right and others bind on the left, we
will leave this as site specific. Bind-left and bind-right
could be added later.
MEDIA TYPES
Registration of printer datastreams -- Harald A. believes
that the only way to make sure it gets done is to do it
ourselves. Alternatives for registration:
1) application/print.xxx (application/print.ipds)
2) application/vnd.xxx (application/vnd.ppds)
3) application/vnd.company.xxx
(application/vnd.adobe.printgear)
4) application/xxx (application/postscript)
Anything that this group registers could include versions
and level but it is unclear if level and version could be
added to something that is already registered. The group
unanimously believed that it must do the registration and
would try to do #1 above with #2 as a fall-back.
MODEL
Add a new type called "range-of-int" that would be 8 bytes,
4 bytes for the low end and 4 bytes for the high end of the
range. -- YES, this would clearly differentiate range from
setof. We can now remove range-of-x since integer is the
only one we use.
SZ1) "Instance of a Printer", "Printer Object", "IPP
Printer" and "Instance of Printer Object" are all used to
mean the same thing. We should use only one -- "Printer
Object" - once the model document has introduced the concept
of an object.
SZ2) 3.2.1 needs more clarification in the area of Validate-
Job: Scott will
clarify this text.
SZ3) When is Job-name generated: The name is generated
before the response on the create is returned.
SZ4) "snapshot" for all job status attribute is taken at the
same time.
SZ5) How unsupported attributes are returned needs some
clarifications. Scott and Steve Zilles will work out this
wording.
SZ6) Section 3.3.4.1 change "_names (without values) or
attribute groups_" to and/or.
SZ7) Section 4.2 - Interaction of defaults with other values
-- no simple solution -- ignore for now. Default should be
described as the most likely value. For example is the
default is 2-sided but the media selected is transparency
then 2-sided does not apply.
SZ8) Section 4.2.17 - clarification is needed that only the
document data is compressed.
SCHEDULE
Carl-Uno reviewed the schedule --
There are now only two standards tracks documents -- "Model"
and "Protocol."
Informational documents -- "Requirements," "Rationale" and
"LPR Mapping"
When all these documents are published, Carl-Uno will issue
a last call for the working group. These comments get
reflected into the documents. The documents are then sent
to the IESG for a last call to the area directors. Once
they are turned over to the Area Directors much of the
control is removed from the hands of the working group.
After the documents have been turned over to the IETF, the
PWG group can continue to work on:
1) Interoperability testing
2) V2 requirements
3) Prototyping
4) etc.
The meeting adjourned at 5:20 PM.