--------------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.doc
ftp://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@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--