Subject: Re: IPP> MOD - Minutes from Meeting at Sun on February 5 - .pdf file posted

From: Tom Hastings <[email-masked]>
Date: Tue, 18 Feb 1997 09:28:17 PST

I posted the .pdf file of the minutes:

-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 <[email-masked]>
>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 – 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.
>