IPP> MOD - Minutes from Meeting at Sun on February 5

IPP> MOD - Minutes from Meeting at Sun on February 5

IPP> MOD - Minutes from Meeting at Sun on February 5

Jim Walker walker at dazel.com
Tue Feb 11 10:38:54 EST 1997

This is a multi-part message in MIME format.

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:


If someone could do the PDF, I would appreciate it.


Jim Walker <walker at dazel.com>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX

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

The following is a summary of the more important issues that were

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

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

  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

  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

  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

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,

  - 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.


More information about the Ipp mailing list