Subject: IPP> Attribute Summary

From: [email-masked]
Date: Mon, 25 Nov 1996 15:12:36 -0500

Classification:
Prologue:
Epilogue:

I have generated a table that summarizes the use of all of the attributes in
the current document IPP93).  This was an enlightening exercise for me. It
helped me to get my arms around all of the attribute discussion. I am attaching
the WORD document for anyone who might find it useful.  Would this be helpful
as an appendix to the document?

During this exercise, I came up with a number of questions and comments that
ought to be folded into a subsequent version of the document:

There are lots of client set attributes for which no default action is
described if the attribute is not specified. Many of these are probably
obvious, but ought to be written down for completeness. For example,
job-notification, job-retention-period, medium select, sides,
printer-resolution-select, and most of the "transformation" attributes.

Defining the document content as a doucment attribute seems "strange" to me.
Section 5.1 describes a quite different method for carrying the document
content.  These need to be reconciled. I'd recommend taking document-content
out as an attribute.

Do we need to define what happens when a client specifies a production
attribute that is not supported? Should the client code prohibit this from
happening some way? If it does, is this a "bug" in the client"?

I'm don't undestand the need for operation-attributes. The text seems to
suggest that these are used by the client to set attributes such as
job-originator, so that the end-user doesn't deal with these directly (for ease
of use or to prevent forgery). Why isn't this simply a matter of how the client
code is implemented? For example, if the end-user uses an id and password to
log onto the client, can't the client just pass these values along to the
Printer in the orginal print request? Why must they appear in a different
attribute? This only seems to complicate the oepration.

The 4th paragraph of section 6.2.7 (Job Production Attributes) needs some
editorial work. There appear to be some incomplete or run-on sentences.

In section 6.2.8.3, is the length of the media in lines rather than characters?
This would be consistent with top and bottom margin.

In this entire section on conversion attributes, we need to be crisp on the use
of document versus job.  I think that in the current version of the draft,
these should all apply to a job, not a document as the drfat is currently
written.  Otherwise should they be document attributes?

In section 6.2.8.11, it looks like default-font needs its own section heading.

It seems to me that job resource attributes are VERY optional since their
appearance depends upon major changes to things like device drivers.  If we are
going to suggest that device drivers be changed to generate these attributes
wouldn't we'd be better off asking device drivers to generate real IPP
attributes instead. For example, why ask a Postscript driver to change to add a
"media-used" attribute instead of asking it to generate the medium-select
attribute. I'm also concerned that we might expect intermediate software to
scan a PDL to locate all of the resources to be used - this seems an onerous
task.

I don't understand the use of job-intervening-jobs. Since this is a Job
Resources attribute and is supposedly set by a driver , what does it mean? What
does it mean if set by the client? Is it out of place?

The header for Section 6.4 suggests that all of these attributes are set by an
adminstrator.  Is this true? Why wouldn't we expect some to be set by the
Printer using SNMP to get the values from the Printer MIB?  Why require an
adminstrator to be put into teh middle where one is not required. Of course an
administratot may set policy attributes, such as maximum number of copies or
job size. Should these be defined as a seprate category of administrative or
policy attributes?

Since all of the Printer atributes might reflect a collection of printers
supported by a server, shouldn't all of the attributes in this section be
multi-valued. For example, should printer-name be #1string, suggesting that all
of the printer names would be returned if multiple printers were supported?  In
this section we sometimes use printer (lower-case) and sometimes
Printer(upper-case). We should crisp this up. Does printer (lower-case) really
mean output device?

I don't understand section 6.4.10, notification-address. What does it mean for
this to be a printer attribute, given that this value is sent to the Printer as
a job attribute? Similarly, what is the meaning of notification-events as a
printer attribute, given that it is sent to the Printer as a job attribute?

Following is my summary table...

Have a nice Thanksgiving everyone, see you in San Jose!