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 - 18:43:51 EDT