Subject: IPP>MOD - job-sheet-content attribute

From: Roger K Debry <[email-masked]>
Date: Fri, 5 Sep 1997 12:33:04 -0400

At the last PWG meeting, I suggested the definition of a new attribute,
based on the proposed dictionary attribute, to allow an admisnistrator
to collect end-user suuplied information to be printed on a job-sheet.
I was asked to generate a formal write-up. Here it is:

Job-Sheet-Content attribute

Problem Statement

Today the model document allows the end user to select whether or not a
job sheet should be printed, but there is no mechanism for a user to
specify what should be printed on the job sheet.  In many cases, an
administrator will establish the content of the job sheet, using
information that comes from the print job request itself, such as
job-name, or job-originating-user. However, these values are somewhat
limited, and an administrator may want to use other information not
available as a standard job attribute.

Suggested Solution

Using the proposed dictionary attribute (Hastings-deBry  proposal),
provide a means for the administrator to collect additional job-sheet
information.  This could incidentally be used for other purposes, such
as accounting.  This would be done with a new job template attributes
called "Job-Sheet-Content".

To help the client, each field to be printed on the job sheet is
represented by a pair of attributes:

1. The first attribute in the pair is of the form "prompt-n",
   where n is a digit starting with 1.

2. The second attribute is of the form "prompt-n-response".

This attribute provides a means for an administrator to collect
additional user information to be printed on a job sheet. There
is no standard set of semantics associated with the text data
supplied by the administrator or the end user.  Text is assumed to
be in the language of the end-user.

ISSUE: How does one associate the end-user's language with a set
of text dictionary attributes? In a multi-lingual configuration,
it must be possible for the server to select the dictionary entries
based on the end user's language.

For example, an administrator defines the job-sheet-content attribute
as the following text attributes:

"Prompt-1"           =  'Last Name'
"Prompt-1-response"  = '          '
"Prompt-2"           = 'Department'
"Prompt-2-response"  = '          '
"Prompt-3"           = 'Building'
"Prompt-3-response"  = '        '

In this example, the default values for the prompt-n-response attributes
were set to a strings of ASCII blanks. They could have been any text
string, perhaps a default name, or a string saying "enter text here".

A client application, getting the job-sheet-content-supported attribute,
would receive the above dictionary. Since there is no semantic associated
with the actual text data,  the client simply puts up the prompt and
collects the response from the end-user in the associated response field.
These fields are passed back to the IPP Printer with the print request
where the data input by the end user is printed on the job-sheet in a
format defined by the administrator.

Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---

From: Jay Martin <[email-masked]>
Date: Fri, 05 Sep 1997 13:26:14 -0400

Roger,

I really like this proposal.  Granted, it extends our reach yet
another step (in that we're not "going interactive"), but this
mechanism can be very, very useful in large environments, and may
be usable in billing situations, etc.

Regarding the language issue, couldn't we just add (yet another)
property to specify the language?  This property would be set and
returned by the client at job submission time.  I was thinking that
this would involve a list-selection mechanism, where the list entries
are the set of valid languages for which the Printer can handle.

Just my $0.02 worth.  Nice job on the write-up.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Jay Martin <[email-masked]>
Date: Fri, 05 Sep 1997 14:10:57 -0400

Oops...  I meant to say that we are _now_ going interactive

> another step (in that we're not "going interactive"), but this
                              ^^^

	...jay

---

From: Larry Masinter <[email-masked]>
Date: Mon, 8 Sep 1997 06:25:06 PDT

It would be much better for the server to send back a _form_
to the client for presentation to the user, rather than creating
yet another ad-hoc representation for a form with such a weak
semantics. There are lots of details of your proposal that are
incomplete (ASCII instead of UTF-8, no constraints on length or
data types of input, questions about the requested language
for prompts, etc.)

Larry

---

From: Jim Walker <[email-masked]>
Date: Tue, 09 Sep 1997 15:29:08 -0500

Roger,

I like your goal here... the idea of being able to have variable
information substituted into the job sheets.  However, let me
offer a little bit of a different twist on the solution.

In our system, we can reference attribute values from the document,
job, or printer object themselves.  For example, I can substitute
the value of job-owner, submission-time, printer-name, etc.
Obviously, any value that you would want to have available, would
have to be available as an attribute of one of the objects.  This,
however, has not been an obstacle for our customers.

The one thing that I do like in your scheme is that it *shows*
the user what information is necessary for the job sheet.
Perhaps there is some synergy between these two solutions?  For
example, we could have a job-sheet-content attribute that lists
the other attributes that will be used on the job sheet?

food for thought...
...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX