ftp://ftp.pwg.org/pub/pwg/new_MOD/minutes/
-rw-r--r-- 1 pwg pwg 16384 May 1 07:18 970425-model-telecon-minutes.doc
-rw-r--r-- 1 pwg pwg 8164 May 1 07:18 970425-model-telecon-minutes.pdf
I've also copied them as text into this message.
There will be another Model telecon, this Friday, 5/2, from 1-3 PDT (4-6 EDT).
Scott will send out an agenda.
Tom
Subj: Minutes of the 4/25/97 IPP Model telecon
From: Tom Hastings
Date: 4/30/97
File: cc970425.doc .pdf
Attendees: Jay Martin, Roger deBry, Keith Carter, Bob Herriot, Tom Hastings
Proposed Agenda:
1. Defaults (explicit vs implicit)
2. Best Effort
a. Client Print Request values vs Printer Supported values
(This is the current semantics of best-effort in the model doc.
(Note: I suggest this be a print operation parameter rather
than a Job attribute)
b. External Job Production Instructions vs Embedded values
3. Review conformance text
4. If we get rid of all tags, how do we handle "ready and not-ready"
5. Review mandatory attributes
6. Proposal for a color attribute?
7. Do we need security supported attribute?
8. Proposal for a "I can override the PDL with external attributes" attribute
(is this just item 2.b above?)
1. Defaults (explicit and implicit)
1a. We agreed to get rid of the large number of groups of attributes and
have only two groups. This will simplify implementation and the
specification. The groups agreed to are:
1b. For the Job object: job-status, and job-template
1c. For the Printer object: printer-status, and job-template
1d. When an attribute is registered the registration needs to specify to
which group the attribute is to become a member.
1e. Also the "all" group means both groups, i.e., all attributes, for each
object.
1f. We may want a more generic name for job-status and printer-status
groups, since each includes all attributes that are not part of the job
template group. Perhaps printer-status-and-description or
status-and-capabilities [no agreement on a better term]
1g. When a user submits a Get Attributes or a Get Jobs without specifying
any attributes or any groups, the default is "all". Then we don't need to
specify any simple subset, which would be contentious.
1h. The Job template attributes on the Job object specify what is wanted
when (1) supplied by the client in the Print operation and (2) when supplied
by the Printer as a default because the client did not supply the job
template attribute.
1i. The Job template attributes on the Printer object specify the default
value for the attribute. Thus the data type is the same for the job
template attribute when on the Job object or on the Printer object.
1j. For each xxx Job template attribute there shall be a corresponding
xxx-supported and xxx-ready Printer attribute. There will be a specified
mapping of the data types for the Job Template attributes to the
corresponding xxx-supported and xxx-ready attributes, as in the current
draft. There is nothing special about the first value of the xxx-supported
attribute; the first value is not the default value. See decision 1I.
1k. For Printer attributes that are not job template attributes there will
be none of the form xxx-supported.
1l. If the client does not supply an attribute, the Printer shall supply the
default value as specified by the Printer object (set by means outside IPP
V1.0). If the Printer does not implement that attribute the Printer shall
implement the "default behavior" for that attribute as specified in the
Model for each attribute.
1m. When new attributes are registered, their default behavior specification
should be what current implementations do that do not know about such an
attribute.
2. Best Effort
2a. We re-affirmed that for IPP V1.0, best efforts should be a per job
attribute.
We did not discuss the suggestion in the agenda that the best-efforts be a
Print operation input parameter, rather than a job template attribute.
Scott needs to tell us the advantage of making it a Print operation
parameter. Perhaps it is because the current specification requires that
the default value be 'do-not-substitute', so that the Printer object cannot
have a default value for this attribute that is different from
'do-not-substitute'. If best-efforts is changed from being a Job Template
attribute to being a Print operation input parameter, best-effort could also
become a job status attribute that the Printer copies from the Print
operation input parameter and returns on a Get-Attributes operation on a job
and a Get-Jobs operation.
2b. External Instructions vs. Embedded values (in the PDL)
We decided that the IPP job template attributes that a client supplies are
all overrides of what is in the PDL. Various systems will be able to
support such overrides to varying degrees, but systems are getting better at
allowing such overrides. Such overrides become more important as the web
significantly increases the percentage of print jobs that supply already
formatted documents (with embedded instructions) to be printed.
For IPP V1.0, we doubt that we will be able to come up with a mechanism to
allow the Printer to indicate which attributes the Printer supports as
embedded in the PDL and/or allows the client to override what is embedded in
the PDL. So the Printer object xxx-supported attribute values are ambiguous
as to (1) whether the Printer supports the client supplying such values in
the protocol to override what is in the PDL when the same instructions are
also in the PDL, or (2) whether such values may be supplied by the client
only when they are not in the PDL.
3. Review Conformance text in Model version 2.1
3a. Page 18, line 634: We did not agree that attributes that the client
supplies are "hints" in IPP. So delete "or hints".
3b. Page 18, line 651: We agreed that the value "unknown" cannot be returned
by a Printer as a default value. If the Printer object software had to deal
with a Printer for which the Printer object software cannot determine the
default value used by the output device, that Printer object software had
better always supply its own default value explicitly to the hardware
device, so the 'unknown' value is shall not be a legal value for a default
attribute.
3c. Similarly a client cannot submit the "unknown" value for a job template
attribute. Thus the supported values for a job template attribute are the
legal values that a client can submit and that a system administrator can
specify as the default values for the Printer.
3d. ACTION ITEM (Tom): Talk to Scott about the suggestion that the
Conformance section should just list which other sections and the pertinent
contents that a conforming Printer shall conform to and to move the
specifics to the sections where the operation is discussed. Then we achieve
both goals: (1) have a single place that an implementer can use as a check
list for conformance (which points to other sections for specifics) and (2)
put the specific conformance statements in the actual specification where
they will be easiest for the reader to understand.
4. Getting rid of all tags, how do we handle ready and not-ready
4a. We reaffirmed the idea of getting rid of all tags. They are too
complicated.
4b. The Printer object will have 3 attributes whose names are
algorithmically generated from the base xxx Job Template attribute:
xxx - means the default value (same name as the corresponding job
attribute and with the same syntax and values)
xxx-supported - means the supported values, whether ready or not.
xxx-ready - the subset of the xxx-supported values that are currently
ready, i.e., may be used without human intervention.
4c. We decided that having a Printer represent its capabilities with respect
to instructions embedded in the PDL would probably wait until after IPP V1.
ACTION ITEM (Jay Martin): Prepare a discussion slide for the San Diego
meeting about the ideal Printer driver that would be a Universal Printer
Driver. Such a driver would discover the capabilities of a Printer using
IPP, display the Printer's capabilities to the user, and produce the
required IPP to perform the user's selections.
We did not have time to get to agenda items 5-7.
8. Proposal for a "I can override the PDL with external attributes"
attribute. This is just 2b above.