IFX Mail Archive: IFX> RE: NOT - IPPGET Delivery Method ISSU

IFX> RE: NOT - IPPGET Delivery Method ISSUE 01: Event Wait Mode for Jo b Creation operations

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Mon Oct 29 2001 - 18:05:09 EST

  • Next message: Carl Kugler: "Re: IFX> RE: NOT - IPPGET Delivery Method ISSUE 01: Event Wait Mode for Jo b Creation operations"

    At the IPPFAX WG, we briefly discussed IPPGET ISSUE 01 (adding Event Wait
    Mode to Job Creation operations) and decided against it for the following
    reason:

    There can be Job or Printer events occurring even before the last data is
    sent in the Print-Job operation. Therefore, it is much better for the
    client to issue the Get-Notifications on a separate thread after getting
    back the "job-id".

    However, when writing up this mail message (and conferring with Gail
    Songer), there is a problem: The client has to wait to get the Job Creation
    response before it can to the Get-Notifications operation, since the client
    (now) MUST supply the "subscription-id" in the Get-Notifications operation.

    Requiring an IPP or IPPFAX Printer that supports Get-Notifications to also
    support Event Wait Mode on Job Creation operations, only helps a little.
    The client still has to wait for the Print Job response before the Printer
    will return additional responses with Events. So a simple Printer that
    starts to print pages as soon as it get them, might flow control off the
    client after a number of pages. Eventually, the client sends the last page
    of data and the Printer responds with the Subscription Id. Then the Printer
    sends the Events as additional responses.

    Another approach would be for the client to use Create-Job, instead of
    Print-Job. Then the subscription-id is returned to the client in the
    Create-Job response before the client sends any data with the Send-Document
    operation. However, currently Create-Job and Send-Document are OPTIONAL
    operations for both IPP and IPPFAX Printers.

    Would it be a solution to REQUIRE IPPFAX Receiver to support Create-Job and
    Send-Document (as well as Print-Job)?

    What about an IPP Printer that supports Get-Notifications?

    So IPPGET ISSUE 01 needs more discussion on the mailing list and this
    Friday's telecon.

    Thanks,
    Tom

    -----Original Message-----
    From: McDonald, Ira
    Sent: Wednesday, October 24, 2001 19:21
    To: Hastings, Tom N; ipp (E-mail); IPP FAX DL (E-mail)
    Cc: Kugler Carl (E-mail); Lewis Harry (E-mail)
    Subject: RE: IFX> NOT - IPPGET Delivery Method ISSUE 01: Event Wait Mode
    for Job Cr eation operations

    Hi Tom,

    I like this simplification. I agree that the Job Creation operation
    results (status codes) are already seriously complicated by the
    (multiple) Subscription objects that can be affixed to the Job
    Creation operation.

    Cheers,
    - Ira McDonald
      High North Inc

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Monday, October 22, 2001 2:23 PM
    To: ipp (E-mail); IPP FAX DL (E-mail)
    Cc: Kugler Carl (E-mail); Lewis Harry (E-mail)
    Subject: IFX> NOT - IPPGET Delivery Method ISSUE 01: Event Wait Mode for
    Job Cr eation operations

    I've been thinking more about ISSUE 01:

    ISSUE 01: Although we agreed to extend Job Creation operations to
    support Event Wait Mode, it seems to be an unnecessary complication, since
    the Printer MUST keep events for at least 15 seconds. So OK NOT to add the
    "notify-wait" (boolean) operation attribute to Job Creation operations and
    NOT have to have Job Creation responses return Event Notification Groups (in
    addition to returning Subscription Attribute Groups).

    I think the following simplifications would make it straightforward to
    support as an extension to Job Creation operations:

    1. Just add "notify-wait" (boolean) as a Job Creation (Create-Job,
    Print-Job, Print-URI) operation attribute and a Validate-Job operation
    attribute.

    A client MAY supply

    A Printer MUST support both values, if it supports Get-Notifications
    operation.

    2. Just add "notify-get-interval" (integer(0:MAX)) operation attribute to
    the Job Creation response.

    A Printer MUST support if it supports Get-Notifications.
    If a client setup an 'ippget' Subscription object in the Job Creation
    operation, a Printer MAY return "notify-get-interval" in which case a client
    MUST try the Get-Notifications again according to the interval returned.

    A Printer MUST support if it supports Get-Notifications. (Then there is no
    need for more Printer Description attributes to say whether Wait Mode is
    supported for Job Creation operations; it MUST be if Get-Notifications is
    supported.)

    3. In order not to complicate the status code coming back in the Job
    Creation response (which already as multiple groups coming back for each
    Subscription object and each group has its own "notify-status-code" as well
    as the operation having an "overall" status code, how about saying that the
    Job Creation response MUST NOT include any Notification Events. If the
    client requests Event Wait Mode in the Job Creation operation ("notify-wait"
    = 'true'), the Printer MUST return any Notification Events in subsequent
    responses, so that the status code for the Notification Events is exactly as
    it is in Get-Notification responses.

    How does that sound?

    Then the agreement reached in Toronto to specify Event Wait Mode for Job
    Creation would be met. The same Get-Notifications response code would be
    invoked by the Job Creation operations.

    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Friday, October 19, 2001 03:37
    To: ipp (E-mail); IPP FAX DL (E-mail)
    Subject: IFX> NOT - IPPGET Delivery Method down-loaded - REQUIRED for
    IPPFAX

    I've posted the updated IPPGET Event Notification Delivery Method that is
    REQUIRED for IPPFAX:

    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017.doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017-rev.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017-rev.doc

    The -rev version show the revisions since the July 17, 2001 version.

    It has all of the agreements reached at the August 1, IPP FAX meeting in
    Toronto and the subsequent 3 telecon, August 11, 14, and 17. See the
    telecon and meeting notes for the list of the changes.

    I'll send a .txt I-D later Friday. Please send any comments to the mailing
    list. We'll also review at the IPPFAX WG meeting, next Wednesday, October
    24 in San Antonio.

    There are two issues:

            ISSUE 01: Although we agreed to extend Job Creation operations to
    support Event Wait Mode, it seems to be an unnecessary complication, since
    the Printer MUST keep events for at least 15 seconds. So OK NOT to add the
    "notify-wait" (boolean) operation attribute to Job Creation operations and
    NOT have to have Job Creation responses return Event Notification Groups (in
    addition to returning Subscription Attribute Groups).

            ISSUE 02: How unique do we need the "notify-recipient-uri" (uri)
    URL now that the Printer doesn't use anything but the scheme in the URL to
    match on?

    Here are the major changes:

    1. Removed the "notify-recipients-uri" operation attribute from
    Get-Notifications, so no URI matching.

    2. Changed "notify-subscription-id" (integer(1:MAX)) to
    "notify-subscription-ids" (1setOf integer(1:MAX)); the client MUST supply
    with at least one value. Printer MUST support multiple-values.

    3. Added "notify-sequence-numbers" (1setOf integer(1:MAX)) to be parallel
    and be a floor to the Event Notifications sequence numbers returned. The
    client SHOULD supply. Printer MUST support multiple-values.

    4. In Event Wait Mode, each response is a full IPP response.

    5. Moved "notify-get-interval" back to the operations attributes group in
    the response.

    6. Added 'successful-ok-events-complete to indicate that there will be no
    more events for this Subscription object.

    7. The Printer MUST support Event Wait Mode.

    8. The client can end Event Wait Mode (without closing the connection) by
    sending "notify-wait" = 'false' any time. The Printer can end Event Wait
    Mode (without closing the connection) by returning "notify-get-internal"
    operation attribute any time (including immediately).

    9. Changed the lower limit for "ippget-event-life" from 1 to 15 seconds and
    recommend 60 seconds to agree with the PWG Job Monitoring MIB (RFC 2707).

    Thanks,
    Tom



    This archive was generated by hypermail 2b29 : Mon Oct 29 2001 - 18:05:31 EST