IPP Mail Archive: IPP> NOT - IPPGET part of the IPPFAX telec

IPP> NOT - IPPGET part of the IPPFAX telecon, Friday, Aug 17

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Mon Aug 20 2001 - 21:25:54 EDT

  • Next message: sales@seebex.com: "IPP> Instant Messaging platform at your Web site is now a few clicks away"

    To IPP WG,

    I've extracted from the IPPFAX telecon notes the part of the IPPFAX telecon
    that dealt with IPPGET and have copied it.

    Please send any comments to the IPP DL.

    Thanks,
    Tom

    -----Original Message-----
    From: Hastings, Tom N
    Sent: Monday, August 20, 2001 18:17
    To: IPP FAX DL (E-mail)
    Subject: Notes on the IFX and IPPGET part of the IPPFAX telecon, Friday,
    Aug 17

    I've separated the notes about the UIF part and the IFX part of our IPPFAX
    telecon, Friday, August 17, since the former will be sent to the Internet
    FAX WG (ietf-fax@img.org), but the IFX notes will not. The added IPPGET
    issue 48 about URI matching was also raised and agreed and will be
    distributed to the IPP DL separately as well.

    Please send any comments about the notes to the mailing list.

    Agenda:
    10-11 AM - Address the Internet FAX WG concerns about UIF and the Adobe IPR
    issues with TIFF/FX.
    11-12 AM - continue with IFX issues 43, 45-47. Any IPPGET Issues.

    Attendees: John Pulera (Minolta Labs), Marty Joel (Netreon), Ira McDonald
    (High North), Rob Buckley (Xerox), Peter Zehler (Xerox), Tom Hastings
    (Xerox), Gail Songer (Netreon).

    Summary of the IFX Part:

    ... agreements deleted ...

    ****The following IPPGET ISSUE 48 will be copied to the IPP DL as well****

    ISSUE 48: How will the Receiving User get notified of an IPP FAX Job
    completion?

    AGREED> We reconfirmed that IPPGET is not a suitable method for use with
    Per-Job Subscription objects for notifying Receiving Users. IPPGET requires
    that each user do something every time the Printer is started in order to
    receive notifications. So we reconfirmed removing the uri matching function
    from the IPPGET Get-Notifications operation, even though we realized that
    there is no easy way for a client on a Receiver to search all Per-Job
    Subscription Objects using Get-Subscriptions. First such a client would
    have to poll using a Get-Jobs operation and see what new jobs had arrived
    since the last poll. Then it would have to do a Get-Subscriptions for each
    new job requesting the "notify-recipient-uri" attribute and match it.

    If the IPPGET Delivery Method is used on a Receiver to notify Receiving
    Users, it should be done by an operator application that creates a
    Per-Printer Subscription object that subscribes to 'job-completed' events
    for all Jobs. See agreement under ISSUE 49 (below) for further discussion
    about possible ways a Receiver can notify Receiving Users.

    The following affects the IPPFAX Protocol spec, not the IPPGET spec:

    ISSUE 49: Should we have an attribute that is similar which is to notify
    the recipient (person) of the arrival of the document? The URI could be
    'mailto', 'tel'. For the former, the IPPFAX Receiver sends an unsolicited
    email message saying that a document has been printed. The latter makes a
    phone call to announce that the document has been printed. This attribute
    does not require the recipient to have done anything ahead of time and does
    not require the recipient to be registered in any system. It is what a
    secretary typically does today when a FAX is received at a group FAX.

    AGREED> Instead of adding a Job Template attribute to allow the client to
    control the delivery of notification to Receiving Users, we agreed to simply
    add a Printer Description attribute that is a boolean that indicates whether
    or not the Receiver is currently configured to notify Receiving Users when
    an IPPFAX Job completes, so that the Sender doesn't have to also worry about
    notifying the Receiving User about the IPPFAX Job causing annoying duplicate
    notifications for the Receiver User. If the Receiver isn't notifying
    Receiving Users, then the Sender could notify Receiving Users either:

    a. by adding another Subscription Object with a push method, such as
    'mailto' or 'indp' (if supported) to the Job Creation operation with the
    Receiving User as the "notify-recipient-uri", or

    b. by sending an email message to the Receiving User (before or after the
    job completes, depending on the wishes of the Sending User).

    The IMPLEMENTATION DEFINED methods for the Receiver to notify Receiving Uses
    of completed IPPFAX Jobs include:

    1. Each Printer URI is for a separate user. Each Printer object has a
    configured Per-Printer Subscription object or equivalent that is subscribed
    to 'job-completed' events and uses a supported Event Notification Delivery
    Method to deliver the notification to the configured user.

    2. Each Printer object has a pre-allocated Per-Printer Subscription Object
    that is subscribed to 'job-completed' events and that an operator
    application uses to examine Job attributes, such as any fields in the Job's
    "ippfax-receiving-user-vcard" operation/Job Description attribute and/or the
    "printer-uri" and automatically notify the Receiving User by email,
    telephone, or pager.

    3. An operator/secretary launches an application that creates a Per-Printer
    Subscription object that notifies the operator/secretary by some supported
    Delivery Method (ippget, indp, or mailto).

    4. That application could examine Job attributes, such as any fields in the
    Job's "ippfax-receiving-user-vcard" operation/Job Description attribute
    and/or the "printer-uri" and automatically notify the Receiving User by
    email, telephone, or pager.

    5. That application could access a central data base or directory for the
    Receiving User as indicated in the "ippfax-receiving-user-vcard" and use the
    method indicated there.

    6. A person sits next to the Receiver and reads the start page and delivers
    the documents to the Receiving User.

    etc.

    Please send any comments to the IPP DL.

    Thanks,
    Tom



    This archive was generated by hypermail 2b29 : Mon Aug 20 2001 - 21:27:44 EDT