-rw-r--r-- 1 pwg pwg 13824 Feb 11 15:11=
970205-ipp-mod-meeting.doc
-rw-r--r-- 1 pwg pwg 16714 Feb 18 17:28=
970205-ipp-mod-meeting.pdf
-rw-r--r-- 1 pwg pwg 11351 Feb 11 15:12=
970205-ipp-mod-meeting.txt
Tom
At 07:38 02/11/97 PST, Jim Walker wrote:
>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
> 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 =96 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=3D4 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.
>