IPP> ATT - Updated "job-recipient-name" spec from the 9/13 IPP WG meet ing and an ISSUE

IPP> ATT - Updated "job-recipient-name" spec from the 9/13 IPP WG meet ing and an ISSUE

IPP> ATT - Updated "job-recipient-name" spec from the 9/13 IPP WG meet ing and an ISSUE

Hastings, Tom N hastings at cp10.es.xerox.com
Thu Sep 21 13:48:53 EDT 2000


This is the updated specification from the IPP WG meeting, 9/13/00 in
Chicago.  I have an action item to make it an IETF Internet-Draft.  However,
there is an ISSUE that needs to be resolved:

ISSUE 01:  In the normal case of printing within an organization, i.e., on
an intranet where the user submitting the job is the same as the job
recipient, what should the client do about the "job-recipient-name"?  Always
submit it anyway, since it might be a more user friendly name that the
account name or login name he was given by the system administrator?  For
example, if printed job output is  filed by last name at the printer, but
the administrator gave the user a login name of first initial last name
(i.e., Bob Smith was given the login name of rsmith or worse: Smith27), the
client could supply the last name, followed by the first name (i.e., "Smith,
Bob A.") in the "job-recipient-name" attribute.  Also the client could let
the user set a local default that it always uses, unless the user wants to
really submit to some other user (or wants to print over the internet to
someone else).  If we follow this last line of reasoning, then the client
SHOULD supply the "job-recipient-name" even when the job recipient is
intended to be the same as the job submitter, right?  In other words, the
"job-recipient-name" could become that analog of the Email Display Name (as
distinguished from the email address which is more like the job owner/job
submitter).



Here is the updated spec as agreed at the IPP WG 9/13/00 meeting in Chicago.
Send comments to the DL.


job-recipient-name (name(MAX))

I had an action item from the last meeting to write up the
"job-recipient-name" Job Template attribute.  Such an attribute is needed
when a user submits a print job that is intended to be picked up by another
user, such as is typical when an IPP job is submitted across a firewall.
This attribute will also be useful for QUALDOCS.

Here is the proposed definition:


  +===================+======================+======================+
  | Job Attribute     |Printer: Default Value|  Printer: Supported  |
  |                   |   Attribute          |   Values Attribute   |
  +===================+======================+======================+
  | job-recipient-    | none                 | job-recipient-name-  |
  | name (name(MAX))  |                      | supported (boolean)  |
  +===================+======================+======================+


job-recipient-name (name(MAX))

This attribute contains the name of the person that is to receive the output
of the job.  The value of the "job-recipient-name" attribute is commonly
printed on job sheets printed with the job.  An example of another use of
the "job-recipient-name" attribute is if the printer accesses a database to
get job delivery instructions for the recipient of a job.  A zero-length
value indicates that there is no job recipient name.

The "job-recipient-name-supported" (boolean) Printer attribute indicates
whether this attribute is supported.





More information about the Ipp mailing list