IPP Mail Archive: RE: IFX> RE: IPP> REG - Proposal for &q

IPP Mail Archive: RE: IFX> RE: IPP> REG - Proposal for &q

RE: IFX> RE: IPP> REG - Proposal for "job-recipient-name" Job Tem plate att ribute

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed Sep 20 2000 - 18:05:08 EDT

  • Next message: Hastings, Tom N: "IPP> EXC - IPP Override Attributes for Documents and Pages - down load ed"

    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.

    Cheers,
    - Ira McDonald, consulting architect at Xerox and Sharp
      High North Inc

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.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

    Michael,

    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
    (ftp://ftp.pwg.org/pub/pwg/ipp/new_PPE/pwg-ipp-prod-print-set1-000605.doc,
    .pdf):

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

    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.

    Michael,

    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?

    Tom

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    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
    attribute

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

    [This is a real-world example of something that is happening right
    now...]

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

    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                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    



    This archive was generated by hypermail 2b29 : Wed Sep 20 2000 - 18:23:33 EDT