IPP Mail Archive: RE: IPP> Notification Subscriptions across

IPP Mail Archive: RE: IPP> Notification Subscriptions across

RE: IPP> Notification Subscriptions across Power Cycles

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Sep 05 2001 - 19:41:20 EDT

  • Next message: Joe's test 1 2 3: "IPP> TheLion Stock Roars Report - September 5, 2001"

    Dennis,

    Good catch that this thread has been only talking about Per-Job
    Subscriptions and needs to talk about Per-Printer Subscriptions as well. I
    agree that having Per-Job Subscriptions being persistent without Per-Printer
    Subscriptions would be strange. However, how about the opposite? If an
    implementation doesn't have persistent Jobs or Per-job Subscriptions, it
    might still choose to have persistent Per-Printer Subscriptions, right?

    The deleted June 2000 statement was:

    It is RECOMMENDED that all Subscription Objects be persistent.

    So the thinking back then applied to both Per-Job and Per-Printer
    Subscriptions.

    So how about the following sentence:

    If Jobs are persistent, i.e., are preserved across power cycles, then
    Per-Job and Per-Printer Subscription Objects MUST be persistent too.

    As to whether we need a way for the client to tell whether or not the
    Printer supports persistent subscriptions, the minutes of the July 12-13,
    2000 meeting show about the "notify-persistence" Subscription Template
    attribute had ISSUE 04 with it:

    ISSUE 04: It would be better for this attribute to be a Subscription
    Description attribute that the Printer sets to show whether the
    Object is persistent or not. Agree?

    No. The group agreed that this attribute is not useful. The entire
    section on notify-persistence will be removed.

    Thus the group did not want to indicate on a Subscription Object basis
    whether or not it was persistent (or let the client have a say).

    In May 17-18 2000 minutes, we agreed to the following change:

    12. Removed "persistent-jobs-supported" Printer Description attribute,
    since it has nothing to do with Notifications and is not needed to describe
    Subscription object persistence.

    As I recall the reasoning against having a Printer Description attribute
    that indicated whether or not Subscription objects were persistent, is
    because a Printer might run out of resource for keeping subscriptions
    persistent, so that such a promise might not be able to be honored.

    Tom

    -----Original Message-----
    From: Dennis Carney [mailto:dcarney@us.ibm.com]
    Sent: Wednesday, September 05, 2001 15:43
    To: ipp@pwg.org
    Subject: RE: IPP> Notification Subscriptions across Power Cycles

    1) Is there some reason that we would not want to say that if Per-Job
    Subscription Objects are persistent, Per-Printer Subscription Object MUST
    be persistent too? It would seem strange to me to have persistent Per-Job
    subscriptions, but non-persistent Per-Printer subscriptions, but the
    Per-Printer subscriptions are not being addressed in this discussion
    thread, for the most part.
    2) From an IPP client perspective, I would think the knowledge of whether a
    subscription is persistent or not is very important. If a subscription is
    not persistent, an algorithm needs to be run that checks up with the
    printer every so often, checking that the subscription is still there.
    Imagine the case where a non-persistent-subscription printer goes down 2
    seconds after the client subscribes: without a backup algorithm, the client
    will be waiting forever without hearing anything. So I would say that the
    spec should provide some method (it sounds like the "notify-persistence"
    subscription template attribute you mentioned would work) to allow the
    client to know if a given subscription is persistent or not.

    Dennis Carney
    IBM Printing Systems

     

                        "Hastings, Tom N"

                        <hastings@cp10.es. To: "McDonald, Ira"
    <IMcDonald@crt.xerox.com>, Harry Lewis/Boulder/IBM@IBMUS
                        xerox.com> cc: ipp@pwg.org

                        Sent by: Subject: RE: IPP>
    Notification Subscriptions across Power Cycles
                        owner-ipp@pwg.org

     

     

                        09/05/01 02:07 PM

     

     

    The June 2000 version of the Notification spec had the following statements
    as part of the "notify-persistence" Subscription Template attribute (which
    allowed the client to request persistence or not):

    It is RECOMMENDED that all Subscription Objects be persistent. If Jobs are
    persistent, the Per-Job Subscription Objects MUST be persistent too.

    We agreed to delete this Subscription Template attribute and the statement
    was deleted as well.

    Should we add the above statement back into the Notification Spec?

    Since the RFC 2911 doesn't appear to recommend persistent jobs, but does
    admit to an implementation having persistent jobs, how about just adding
    the
    second sentence to the Notification Spec:

    If Jobs are persistent, i.e., are preserved across power cycles, then
    Per-Job Subscription Objects MUST be persistent too.

    Adding such a statement is what Ira is suggesting as well.

    Also the statement that Harry excerpted from the
    "notify-lease-expiration-time" attribute description could be
    mis-interpreted:

    When the Printer powers up, it MUST set the value of this attribute in each
    persistent Subscription Object using the algorithm in the previous
    paragraph.

    Harry correctly interpreted the adjective "persistent" meaning any
    Subscription object that MAY be persistent rather than meaning that all
    Subscription objects are persistent (by definition).

    It might help to clarify that sentence by replacing it with the following
    statement:

    If a Printer has persistent Subscription object when it powers up, it MUST
    set the value of this attribute in each persistent Subscription Object
    using
    the algorithm in the previous paragraph.

    Comments?

    Thanks,
    Tom

    -----Original Message-----
    From: McDonald, Ira [mailto:IMcDonald@crt.xerox.com]
    Sent: Wednesday, August 29, 2001 09:13
    To: 'Harry Lewis'; ipp@pwg.org
    Subject: RE: IPP> Notification Subscriptions across Power Cycles

    Hi Harry,

    Concensus on more recent IPP Fax telecons this summer has been that
    Subscription objects themselves MUST have the same lifetime as
    their associated Jobs. And further that BOTH the Subscription and
    the Job (with _all_ of its attributes) MUST persist until the
    lifetime of the 'job-completed' event (last event) has expired.

    So, I suggest that:

    If an IPP Printer supports "persistent" Jobs (across power cycles),
    then that IPP Printer MUST support "persistent" associated per-job
    Subscriptions.

    Now, if event lifetimes are long enough, do the actual _events_
    "persist" into the next power cycle, if necessary (according to
    the event delivery method constraints in 'notify-recipient-uri')?

    Cheers,
    - Ira McDonald
      High North Inc

    -----Original Message-----
    From: Harry Lewis [mailto:harryl@us.ibm.com]
    Sent: Tuesday, August 28, 2001 6:51 PM
    To: ipp@pwg.org
    Subject: IPP> Notification Subscriptions across Power Cycles

    Does IPP have a "position" on either per-job (i.e. if job is spooled) or
    per-printer subscriptions and whether or not they should be preserved
    across power cycles?

    Looking at the Notification Spec (draft-ietf-ipp-not-spec-07) the only
    related discussion appears to be in Section 5.4.3 (When the Printer powers
    up, it MUST set the value of this
    (notify-lease-expiration-time) attribute in each persistent Subscription
    Object...) which implies per-printer subscriptions may be expected to
    persist
    across power cycle.
    ----------------------------------------------
    Harry Lewis
    IBM Printing Systems
    ----------------------------------------------



    This archive was generated by hypermail 2b29 : Wed Sep 05 2001 - 19:42:27 EDT