This is a multi-part message in MIME format.
--------------2389178E21CA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Attached are the minutes from the Model Group meeting at Sun on
February 5. Thanks to Lee Farrell for providing his notes to me
to help fill in those gaps that I missed.
I have also uploaded the files to:
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/970205-ipp-mod-meeting.docftp://ftp.pwg.org/pub/pwg/ipp/minutes/970205-ipp-mod-meeting.txt
If someone could do the PDF, I would appreciate it.
enjoy...
...walker
--
Jim Walker <walker at dazel.com>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX
--------------2389178E21CA
Content-Type: text/plain; charset=iso-8859-1; name="970205-ipp-mod-meeting.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline; filename="970205-ipp-mod-meeting.txt"
IPP Model Group Meeting Minutes
February 5, 1997
San Jose, California
The meeting started on February 5 at 1:00PM. The attendees were:
Jim Walker -- DAZEL
Keith Carter -- IBM
Lee Farrell -- Canon
Tom Hastings -- Xerox
Carl-Uno Manros -- Xerox
Don Wright -- Lexmark
Bob Herriot -- Sun
Larry Masinter -- Xerox
Greg Mavroudis -- TrueSpectra
Steve Sutherland -- TrueSpectra
Scott Isaacson -- Novell (by phone)
The following agenda was suggested by Bob Herriot:
1) Attributes
2) Queues / fan-in and fan-out – what does the user see?
3) GetJobs printer information
4) Conformance
5) Scenarios (and conformance thereof)
Ultimately, the meeting focused on attributes only, touching upon the
other issues at various times. Bob Herriot had distributed a new
version of the IPP Model draft, which combined and simplified the
attributes. In general, the participants were happy with the idea of
job attributes being represented in the printer object, obviating the
need for the job template object, and the xxx-supported attributes.
During this discussion of attributes, it was questioned if they are
beneficial, useful, or just nice; for example, Microsoft's approach
does not have any attributes. Most felt that the attributes were
necessary.
The following is a summary of the more important issues that were
discussed.
o Production attributes and resource attributes
There are cases in the job attributes where an attribute is both
production and resource attributes. For example, the xxx-margin
attributes could be production instructions in the case of a text
document (i.e., these margins should be used when translating this
document to a format suitable for printing), or a resource attribute
in the case of a PostScript document (i.e., these are the margins that
were used in formatting this output). The current proposal in the
document (as added by Bob Herriot) is that the attributes have an
optional "embedded" tag to indicate that the attribute is a resource.
So, in the example above, the xxx-margin attributes would have no tag
in the case of a text document, but would have the "embedded" tag for
the PostScript document.
The conversation then degenerated into a discussion of whether the
length and width (and the xxx-margin problems, for that matter), are
really useful for text processing; for example, if I specify a width
for a text document, is it really going to be able to break and format
lines like I wanted. The group admitted that these might just be
solutions for the 5% case, but there was no motion to remove the
attributes.
o File type tag
Another new tag, or adornment, that was added to the Model document
was a tag to indicate an attribute or value that may be appropriate
for only a particular document format. For example, a printer may
only support number-up=4 for PostScript documents, so the attribute
value could be adorned so that the client could decide which
attributes and values are appropriate based upon the input document
format.
Discussion of this tag led to some interesting questions. For
example, what if the client does not know the file type yet? Also,
what if a job has multiple documents of varying formats (e.g., 1
PostScript document and 1 PCL document). There was no real decisions
made as to whether this tag was appropriate or not, because we
immediately jumped into...
o Multiple document jobs
We had a long discussion on multi-document jobs; we say that we will
support multiple documents, but we do not allow all attributes to be
different for each document. We already have at least two attributes,
document-format and document- content, that can vary across documents.
On a practical basis, people are going to want to have other
characteristics that are different for each document in a multi-
document job. The scenario that we referred to in justifying
generalizing the per-document attributes is the common case of
printing the first page of a letter on company letterhead, and the
rest of the letter on plain stock, except for the last page which is
printed on some third stock. This scenario could be viewed as three
documents being printed on three different media. (Alternatively,
this could be handled by submitting the letter as a single document,
and having special attributes for first-page-medium and
last-page-medium, but that is another discussion :-).
The question was raised about how important it is to really support
multiple documents per job. It was pointed out that Microsoft breaks
down a multi-document print request into separate jobs. However, it
was also pointed out that LPR does support multi-document print
jobs. (Everyone feels that IPP needs to do at least what LPR can do.)
This led to a discussion about what the concept of a "print job"
should be, with little consensus reached.
Bob suggested a compromise: we want to have multiple documents per
job, and have per-document attributes which override job-level
attributes. However, we should not address the syntax of this
capability at this time; let's attempt to ensure that our syntax does
not preclude future support of this feature. We have not yet decided
whether we do or do not need a separate document object, but the
general feeling seemed to be to keep it simple.
The discussion of multi-document jobs then led to the question of what
should be the behavior of a printer (or server) that is sent a
multi-document job, but can only support single-document jobs. This
led to the issue of...
o Compulsory/Non-compulsory attributes
We had first discussed the print-regardless attribute that had been
added in the latest version of the IPP Model document. We had decided
to remove this attribute, and have print-regardless be the default.
This would imply that a job would print in spite of errors in the job
specification; the server would simply make its "best effort" to print
the job. In addition, we discussed the idea of having a "compulsory"
adornment for attributes, which the user could use to indicate
particular attributes that the server is required to comply with, or
else reject the job. However, it was decided to table the idea of
this adornment for now.
As we discussed multi-document jobs, we got back into the discussion
of best effort versus compulsory behavior. Several people felt that
the previous decision of best effort being the default would result in
clients not being able to reliably print; IPP would end up with the
reputation that the client does not get what it asks for. Tom
Hastings also added that compulsory behavior as a default would be
better for standards compliance (i.e., strictest is best for
interoperability).
So, we decided that the previous decision was backwards; instead, we
felt that the default should be that any attributes that are specified
with a job shall be assumed to be compulsory, unless the attribute (or
attribute value) is explicitly adorned otherwise. Also, we will not
define what a best effort is; we will simply define the conforming
behavior.
Furthermore, we suggested that there may even be some attributes that
may not be adorned as non-compulsory, or best effort. For example,
the number of documents in a job is not really a characteristic of the
job that the client explicitly sets; rather, it is a characteristic of
the job that is implied from the number of documents included in the
submission. Consequently, if a client submits a multi-document job,
and the server does not support multi-document jobs, then the server
shall reject the job.
o Multi-valued attributes
We currently have one job submission attribute (notification-events)
that can be multi-valued; its syntax is setOfType2Enum. We discussed
whether to have distinguished values for this syntax. Originally the
discussion focused on a special value, "none", which would be used to
indicate the empty set. Tom Hastings suggested this distinguished
value so that a client could specify none (and override an explicit
default), and an administrator could set none as a default value, or
exclude it as a supported value. Bob Herriot noted that this
distinguished value would have to be treated specially (if none was
specified, then no other values could be specified for that
multi-valued attribute), and Larry Massinter reminded us that existing
standards (HTTP and SMTP) already use an empty string to represent the
empty set, or none. No decision was made, but it was suggested that
there might be other useful distinguished values, such as "all" and
"default".
o External references
Steve Sutherland suggested that a job should specify any external
references that are present in a document. The examples given were a
ColorWave (?) format used by his company (TrueSpectra), PDL's that
reference external fonts, and HTML files. Larry pointed out that a
problem with referencing Internet resources is that there needs to be
an agreed naming convention of these resources, because they may be
named differently by different clients. Also, the group was very wary
of treading into the problem of printing a tree of HTML references.
Ultimately, the decision was to add a new attribute for external
references that are (or will be) needed to process a document. This
attribute, if specified, will presumably list (by URL) resources that,
if retrieved ahead of time, can cause the document to be processed
more quickly.
o Several other interesting side discussions occurred:
- Larry suggested that we should have the capability in the protocol
to return multiple jobs as the result of a single print request.
Although this suggestion was made during the discussion of trying to
define the "best-effort" of printing a multi-document job at a server
that only supports single document jobs, it still might be of use in
other areas.
- Tom suggested that we should have conformance requirements on the
client as well as the server. The example sited was that a conformant
client verify that a server supports multi-document jobs before
submitting a multi-document job.
- Do we need a new attribute that specifies that all of the documents
in the job (and all of the copies) should be kept together?
- Once we have the capability of non-compulsory, there seem to be 4
different cases for (some) attributes:
What can the printer do ?
What is the client requesting ?
What does the server say it is going to do ?
What did the server actually do ?
We could use adornments for this (e.g., as-submitted, as-printed,
etc.).
- Larry suggested that we make the request syntax separate from the
response syntax. For example, I could ask for courier font or
fixedwidth font, so the request might be able to ask for A or B.
However, the response might include the values requested, the default
values, and the values used.
The meeting adjourned at 6:00 PM.
--------------2389178E21CA--