Hi Tom and Mike,
In the example 2 (ippfax) the 'job-recipient-name'
data type is wrong to hold an ADDRESS. Instead we
need an attribute called 'job-recipient-uri' (just
like 'notify-recipient-uri' in Subscription objects)
that is a standard URL.
- Ira McDonald, consulting architect at Xerox and Sharp
High North Inc
From: Hastings, Tom N [mailto:email@example.com]
Sent: Wednesday, September 20, 2000 2:47 PM
To: Michael Sweet
Cc: ipp (E-mail); QUALDOCS DL (E-mail)
Subject: IFX> RE: IPP> REG - Proposal for "job-recipient-name" Job
Template att ribute
Thanks for the examples.
For Example 1 sending a message to the operator, we have the following
extension attribute in the Production Printing Extension document
3.5 job-message-to-operator (text(MAX))
This attribute carries a message from the user to the operator to indicate
something about the processing of the print job. A zero length text value
indicates no message.
Note: this attribute may be used in conjunction with the IPP 1.0
"job-hold-until" Job Template attribute (see [ipp-mod] section 4.2.2);
specifically with the 'indefinite' value. This combination allows a client
to specify instructions to the operator, while simultaneously preventing the
job from being processed until some operator intervention occurs. This
combination is particularly useful in production printing environments,
where printer configuration may be required to properly print the job.
TH> How the message gets to the operator depends on implementation... I
believe our current notification specification will allow the operator to
create a Per-Printer Subscription for 'job-created' events. An operator
application could filter out the ones that are not in the 'pending-held'
state and notify the operator only when a job enters the 'pending-held'
state. Or maybe an implementation displays a message to the operator
whenever a job is created with a "job-message-to-operator" supplied.
TH> For Example 3, we have the following extension attribute in the
Production Printing Extension document:
3.7 job-sheet-message (text(MAX))
This attribute is used to convey a message that is delivered with the job,
and may be printed on a job sheet (e.g., the 'standard' job sheet). The
message may contain any type of information, but typically includes either
instructions for offline processing (e.g., finishing), or a message for the
TH> So its only example 2, ippfax, where a valid recipient is REQUIRED.
However, I would think that a hotel would require that the "job-recipient"
be supplied with any value. It could be the name of a hotel employee, if
the job was for that employee, a hotel guest, if for a guest, or a visitor's
name, if for a visitor. I suspect that you can walk up to most hotel desks
and leave a note, package, or letter for person "xxx" and say they will come
by and pick it up.
Were you aware of these two extension attribute proposals? They have been
in the PWG IPP FTP site for the past year waiting to get reviewed. They
were finally reviewed last week at the IPP WG meeting. However, some of
these attributes, such as the ones listed above, are clearly not limited to
use in Production Printing. Are we making a mistake hiding them in a PWG
Production Printing specification?
From: Michael Sweet [mailto:firstname.lastname@example.org]
Sent: Wednesday, September 20, 2000 14:08
To: Hastings, Tom N
Cc: ipp (E-mail); QUALDOCS DL (E-mail)
Subject: Re: IPP> REG - Proposal for "job-recipient-name" Job Template
"Hastings, Tom N" wrote:
> TH> You mean you want to print a job for the operator but don't know
> the operator's name, i.e., you want the operator to be the job
> recipient? I'd be interested for an example situation of when an
> end user would want to print a job for the operator.
Example 1: a printing company has a web-based printing service that
allows registered customers to submit files for printing. The
operator(s) of the printing equipment need to know when a job
comes in that required their attention (and the job is held until
the operator readies the printer and releases it), however the
customer does not know (and should not know) who will be doing the
[This is a real-world example of something that is happening right
Example 2: A coworker prints a document you forgot to a printer at
the hotel you are staying at. You don't know who will be receiving
the job, and the hotel requires a valid username or one of the
keywords, so you have to say "operator" and include a cover page with
Example 3: Same as example 2, but inside a company a la fax pickup.
Mind you, we can still do this without a keyword (just define special
names on the server for this sort of thing), but it would be nice to
have support for it in IPP (and not make everything we do in the
real world an extension...)
-- ______________________________________________________________________ Michael Sweet, Easy Software Products email@example.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Wed Sep 20 2000 - 18:17:31 EDT