ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/minutes/970514-model-minutes.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/minutes/970514-model-minutes.txt
The text version is below:
--------------
IPP Model Meeting 5/14/97
Attendees:
Keith Carter, Patrick Powell, Peter Zehler, Carl-Uno Manros,
Steve Zilles, Randy Turner, Rob Klien, Bob Herriot, Scott
Isaacson, Tom Hasting, Jeff Copeland, Ron Bergman, Harry
Lewis
Agenda
1. Review High level goals
Must an IPP Printer spool?
Desktop vs. Workgroup
Section 3
Review SWP proposal and scope
2. Review Job Template Attributes
No xxx-capable
Definition of xxx-supported
xxx-available
3. Review Mandatory attributes
4. Protocol Issues
Look at Get Jobs
Look at Create-Job and Send-Document
Are all attributes required in the Create-Job
Model relationship to protocol
Use of MIME types
5. Extensibility Statements
6. Security
7. I18N
8 Review 9701512 version of the Model Doc
9. What does IETF require in terms of Management?
Discussion
1. Reviewed the high level goals as enumerated in the
Requirements Document and the Charter. Decided that the
Model as is stands is at the right level to support those
goals and requirements. Reaffirmed that an IPP Printer is a
logical abstraction that is more than just a "print device".
Text in the document should use Printer Object when there
might be confusion between an IPP Printer abstraction and a
print device.
2. Decided that section 3 needs to be just an introduction
of the IPP model, not a comparison between some generic
model that does not exist and IPP.
3. Clarified that the "originating-host" is always the host
of the job submitting client. "originating-host" is not
used in the case where the IPP Printer forwards the job onto
some other print subsystem.
4. Reminder that the Model document still includes concepts
that are not to be implemented in v1.0 of the protocol.
5. Steve Zilles reminded us that the IPP model is really a
OO Database model. The Printer, Job, and Document objects
are objects in the OO database. The Printer is responsible
for implementing a named logical instance of the data base
and for implementing an instance of an object to represent
itself in the database. There are no exposed operations to
create or delete or modify new instances of Printer objects
in IPP v1.0, but there are operations to query the database
objects (get-attributes, get-jobs). There are operations to
control the life cycle of the Job object though. create new
instances of Job objects (Create-Job) and Documents (Send-
Document); destroy Job objects (Cancel). The protocol is
just an access protocol into this OO Database.
6. We reviewed the diagrams on page 17 and 21. Theses need
to be simplified and condensed into a much more readable
section : specifically change Print Service => Native Print
Service
7. We all seemed to agree that explicit spooling operations
(get-document, resubmit, etc.) should not part of the model
8. Some suggested that RFC 758 or the Bradnor RFC are the
right documents to find correct language for conformance
9. There was some disagreement about fan-in. Agreed that
multiple clients fanning into the same IPP Printer is
expected and allowed as part of the model. Agreed that
multiple Printer Objects for a single printer output device
is allowed by the model, but not called out explicitly. Fan
in of that sort could be used for either multiple defaults
or access control manipulation.
10. Concluded that the Model document does not need to
address compatibility or coexistance with no modifications
to Existing Web Browsers or not (this is a protocol issue).
11 Reminded ourselves that there are really 3 pieces to the
overall IPP document suite: Abstract Model, Encoding, and
Transport mapping
12. For Job template attributes, we should ignore English
grammar rules for plural and singular and just use regular
rules for xxx, xxx-supported, and xxx-available. Decided
not to worry about xxx-capable type attributes.
13. There was much discussion on job-name: whether it should
be a mandatory attribute that the client must supply in the
submit request or whether it should be optional and one
could be generated by the Printer if not supplied by the
client. We decided to make ALL Job Template attributes
optional in the submit request. That means that the Printer
simply generates a name based on whatever info it has
(document names, user name, submitting host name, printer
name, etc.) The rules on job-name generation need to be
cleaned up to not be so limiting.
14. All "name", "text", and "fileName" attributes are
defined as characters in the Model document. This leaves
open the option of Unicode or other DBCS in the actual
protocol.
15. Reaffirmed that keywords must start with a character (no
digits)
16. The model document is now too verbose and full of too
much wasted space structure. The editor should compress the
format of the Model document.
17. We had a 3 hour discussion on best-effort. The final
proposal was to do away with any notion of "substitute"
values when there is a conflict between what is requested
and what is supported. The expectation is that if a client
specifies something and it is not supported, return an error
so that the client can query what is supported. best-effort
will now apply to only conflicts between IPP attributes and
what is in the document stream (PDL) itself. Proposed
values are: SHALL_HONOR_IPP_ATTR (IPP attribute values take
precedence over PDL instructions), SHOULD_HONOR_IPP_ATTR
(same as SHALL with no guarantees), and
NEED_NOT_HONOR_IPP_ATTR (PDL takes precedence over IPP
attributes).
18. Clarified that defaults are not overrides. What does a
user intend when the user does not specify an attribute:
either 1) They want the admin default, 2) They want the
PDL default. In either case, they really don't know or
care, they really care if they specify the value. The idea
of "default behavior" will be removed from the Model
document. It is not possible to specify a consistent
default behavior for features that are not implemented or
for extensions that are yet to be added.
19. When a Job object is created only supplied attributes
will be copied from the request into the Job object. In
order to determine the defaults that will be applied, query
the Printer Job Template attributes to get defaults.
20. There was a motion to include all of the Job Monitoring
MIB attributes in the IPP. This motion was rejected.
21. There was a discussion about including security concepts
in the Model document. There was a suggestion that there be
a "job-submitter-credentials" attribute in the submit
request. All security issues are still on hold awaiting
more details in the security document.
22. "orig-user" is part of the security solution and is not
mandatory.
23. Moved to change from "job-state-as-text" and "printer-
state-as-text" to "job-state-message" and "printer-state-
message", make them optional, and allow for less rigid rules
about text string content.
24. Moved to make all time related attributes relative to
job submission (not absolute time). That is "job-sumission-
time" moves to "time-since-submitted". There was also a
discussion about having "time-since-xxx" attributes for each
of the Job state transitions (pending to processing,
processing to completed). I did not capture the final
decision on this. These are mandatory
25. Moved to make printer-locales-supported and printer-
locale MANDATORY
26. Reminder that get-jobs includes a set of attributes in
which the requester has interest.
27. We had a discussion on using MIME registered types as
document-format values. I didn't capture a final decision
on this issue.
28. Decided that all implementations shall support a single
operation with data and separate create with later data
operations. However, as I record these minutes, I note that
this decision was reversed the next day at the general IPP
meeting where "levels of conformance" where introduced.
29. Issues about Job and Document fragmentation are left as
a protocol exercise. When there is resolution, the model
document will be updated to reflect the decision
30 We went through is "Issue:" paragraph in the 9970512
model document. Scott will update the Model document and
include new text to document the closed issues.
ACTIONS
-------------
1. Clean up picture on page 17, take out output device,
make an ASCII version of Steve's drawing
Who: Scott and Steve
2. Fix section 3. Do not put in management functions
Who: Patrick
3. Rename IPP Printer to IPP Printer Object
Who: Scott
4. name (start with char, at least length 1)
Who: Scott
5. Restructure the document
Who: Scott
6. Fix the section on "implements" it does not read
correctly as it pertains to Job attributes
Who: Scott
7. Define SHALL and SHOULD get rid of NEED_NOT
Who: Scott
8. Create a table of attributes
Who: Tom
9. Supply text for "color" Job Template attribute "color-
supported"
Who: Randy
10 Fix missing and incorrect conditionally mandatory
Who: Scott
11. Determine if the following Job Template attributes
should be mandatory or not: job name, best-effort, copies.
Who: Scott
12. job-state-reasons should be 1setOf
Who: Scott
13. Add printer-locales-supported and make it and printer-
locale MANDATORY
Who: Scott
14. Remove scheduling-algorithm
Who: Scott
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson@novell.com
W: http://www.novell.com
************************************************************