Hugo, my view is that "perPrinter" registrations apply in the following cases
1. A "print server" application (as opposed to a peer-to-peer situation) that
may establish the "perPrinter - allJobs" subscription and maintain it until the
queue on the server, itself, drains and becomes inactive. In this scenario, the
printer server has some OS supported means of relaying event notification back
to the ultimate end user.
2. An administrative or accounting application (I know... we're not supposed to
acknowledge we're treading here, so consider this comment hypothetical) that
needs to "stay in touch" with the printer regardless of (and out of band with)
any particular print activity.
I see the "perJob" registration in
3. Peer-to-Peer printing
4. Print Server (like 1, above) but notifications go directly from the device to
the end user... not through the server, necessarily or via any OS mechanism.
Harry Lewis
IBM Printing Systems
harryl at us.ibm.com
"Manros, Carl-Uno B" <cmanros at cp10.es.xerox.com> on 08/06/99 02:24:17 PM
To: IETF-IPP <ipp at pwg.org>
cc:
Subject: RE: IPP> NOT - Issue 1 - Add Subscription object? [ISSUE: reject/
ignore an already associated subscription?]
Hugo,
You are right that there are other ways to achieve the same effect, e.g. by
having a profile in your IPP client that always asks for the same kind of
subscription for all jobs that you submit. If we think that this is too
complicated for a printer or print server to keep track of, then we can
describe how it could be achieved from the client instead.
Carl-Uno
> -----Original Message-----
> From: Hugo Parra [mailto:HPARRA at novell.com]
> Sent: Friday, August 06, 1999 11:01 AM
> To: hastings at cp10.es.xerox.com; harryl at us.ibm.com> Cc: mike at easysw.com; ipp at pwg.org> Subject: RE: IPP> NOT - Issue 1 - Add Subscription object? [ISSUE:
> reject/ignore an already associated subscription?]
>>> I wonder how likely we are to run into the scenario Tom
> described (below). It is printer operators who are more
> likely to have rights to add and manage "per-printer"
> subscriptions. How will end-users get the subscription's id
> to send with their jobs if they are restricted to not deal
> with"per printer" registrations?
>> -Hugo
>> >>> "Hastings, Tom N" <hastings at cp10.es.xerox.com> 08/04/99
> 10:41AM >>>
> Harry wrote:
>> The only scenario where the user sends another job associated with an
> already
> assigned subscription should be with a "perPRINTER" subscription.
>> TH> In other words, the following scenario would happen:
>> 1. Some user creates a Subscription object and associates it with the
> Printer object using Create-Subscription with the
> "associated-printer" set
> to 'true'
> and gets back subscription-id 105.
>> 2. Later in a job creation operation, such as Print-Job, the (same or
> different) user passes in the "subscription-id" = '105'.
>> That is how the same Subscription object could be associated
> with both a
> Printer object and a Job object.
>> BTW, I like your shortened terminology of "per-printer"
> Subscription objects
> and "per-job" Subscription objects, rather that a "Subscription object
> associated with a Printer object" and a "Subscription object
> associated with
> a Job object".
> I think using this terminology will help understanding.
>>>>> The Problem with Sharing a Subscription object
>> The problems with allowing a single Subscription object to be both a
> perPrinter (subscription associated with the printer in the
> Create-Subscription operation)
> and a perJob (Subscription associated with a job in either the
> Create-Subscription operation or the job creation operation) are:
>> 1. There is one subscription ID and one object for the single
> Subscription
> object, so a Cancel-Subscription '105' would get rid of both.
>> 2. The job events in the subscription object, such as
> 'job-completed' mean
> different things for the perPrinter vs. the perJob. For the
> perPrinter,
> they mean any job and for the perJob, they mean only this job.
>> 3. There would be access control problems as well. What if I
> had created
> the perPrinter subscription object and you tried to associate
> it with your
> job. Should you be allowed to?
>>> Remember that both perPrinter and perJob subscriptions can
> have printer
> and/or job events in them. So I don't see any need for sharing the
> subscription object between the Printer object and one Job
> object. And you
> seem to agree that we don't want to allow sharing of a single
> Subscription
> object between several job objects. Subscription objects are
> so small,
> there is no real gain in sharing them. Sharing always
> complicated things,
> by adding use counts and raising nasty access control issues.
>> So, ok that a Subscription object either is associated with
> its Printer
> object or with ONE Job object or neither, because it is (and
> possibly others
> Subscription objects are) waiting to be associated with a
> (near) future Job
> object. Ok?
>> The object relationships can best be summarized in this
> picture that I put
> into the Notification Model document I sent Monday:
>> The object association relationships can be seen pictorially
> as (object
> containment not shown):
>> Subscription objects Printer object
> +----+ +------------+
> | s1 |<---------------------------------------------->| |
> +----++ | |
> | s2 |<--------------------------------------------->| p1 |
> +----++ | |
> | s3 |<-------------------------------------------->| |
> +----++ +------------+
> | s4 | Job objects
> +----++ +------+
> | s5 |<---------->| |
> +----++ | j1 |
> | s6 |<--------->| |
> +----++ +------++
> | s7 |<--------->| |
> +----+ | j2 |
> | |
> +------++
> | |
> | j3 |
> | |
> +------+
>> In words:
>> 6.1 Object Relationships
>> When the Subscription object is supported, it is created and
> associated with
> one Printer object, one previously created Job object, or
> neither (so that a
> subsequent job creation operation can perform the association
> of the Job
> object with the Subscription object and possibly other
> previously created
> Subscription objects).
>> The object relationships can be stated as follows:
>> The Printer object contains zero or more Subscription objects
> A Subscription object is contained in one Printer object
>> A Subscription object is exactly one of:
>> associated with one Printer object (s1-s3)
> associated with one previously created Job object (s5 and s6 are
> associated
> with job j1, s7 is associated with job j2)
> not associated with either a Printer object or a Job object (s4)
>> A Printer object is associated with zero or more Subscription
> objects (p1 is
> associated with s1-s3)
>> A Job object is associated with zero or more previously
> created Subscription
> objects:
> j1 is associated with s5 and s6;
> j2 is associated with s7
> j3 is not associated with any s objects
>> A Subscription object cannot be contained in or associated
> with more than
> one Printer object
> A Subscription object cannot be associated with more than one
> Job object
> A Subscription object cannot be associated with both a
> Printer object and a
> Job object
> A Subscription object MUST be associated ONLY with jobs that
> are contained
> in its Printer object
>> Tom
>>>> -----Original Message-----
> From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
> Sent: Wednesday, August 04, 1999 07:41
> To: Hastings, Tom N
> Cc: Michael Sweet; Hugo Parra; ipp at pwg.org> Subject: RE: IPP> NOT - Issue 1 - Add Subscription object? [ISSUE:
> reject/ ignore an already associated subscription?]
>>>>> Regarding this comment
>> >As for the case where the user sends another job that is associated
> >with an already assigned subscription, I don't think we've discussed
> >this possibility yet. My personal feeling is that reusing the
> >subscription ID should probably not be allowed, but we could also
> >treat it as a special renew operation that also changes the
> >subscription.
>> I see it differently. There are two types of subscription...
> "perJOB" or
> "perPRINTER".
> "PerPrinter" should be able to accommodate "myJobs" or "allJobs" (with
> filters
> for specific criteria in either case).
> Typically, a "perJOB" subscription would be expected as part
> of that Job
> submission
> Typically, a "perPRINTER" subscription would be expected via
> an "out of
> band"
> method but could occur in job submission
>> The only scenario where the user sends another job associated with an
> already
> assigned subscription should be with
> a "perPRINTER" subscription.
>> Harry Lewis
> IBM Printing Systems
>harryl at us.ibm.com>>> "Hastings, Tom N" <hastings at cp10.es.xerox.com> on 08/04/99 01:20:14 AM
>> To: Michael Sweet <mike at easysw.com>, Hugo Parra <HPARRA at novell.com>
> cc: ipp at pwg.org> Subject: RE: IPP> NOT - Issue 1 - Add Subscription object?
> [ISSUE: reject/
> ignore an already associated subscription?]
>>>>>> Hugo,
>> Michael did a good job answering your questions. Sound ok?
>> He had one issue:
>> Each subscription will be associated with a single printer or job
> object. There has been discussion of "subscription sets" that would
> allow a subscription to be associated with more than one object
> and/or set of conditions, but my feeling is that most people don't
> want to add this complexity, especially since the client is free to
> create additional subscriptions that do the same thing.
>> As for the case where the user sends another job that is associated
> with an already assigned subscription, I don't think we've discussed
> this possibility yet. My personal feeling is that reusing the
> subscription ID should probably not be allowed, but we could also
> treat it as a special renew operation that also changes the
> subscription.
>>> TH> I agree with his feeling that a subscription can only be
> associated with
> one Printer object or one Job object. That is what I put in the
> Notifications Model document that I send out Monday.
> Subscription objects
> are so big that there is any real savings to being able to
> have one shared
> between multiple jobs or between a Printer and a Job.
>> So if a Job Creation operation specifies a Subscription object that is
> already associated with another Job or the Printer, the Job Creation
> operation doesn't allow it.
>> ISSUE: Return an error which prevents the Job Creation, or
> accept the Job
> Creation anyway, but since the Job Creation returns the
> subscription ids
> that have been assigned, this erroneous one won't be in the list.
>> Ok?
>> Tom
>> -----Original Message-----
> From: Michael Sweet [mailto:mike at easysw.com]
> Sent: Friday, July 30, 1999 05:29
> To: Hugo Parra
> Cc: hastings at cp10.es.xerox.com; ipp at pwg.org> Subject: Re: IPP> NOT - Issue 1 - Add Subscription object?
>>> Hugo Parra wrote:
> > ...
> > <HParra> I think (a) works well. (b) has the problem that it's
> > done after the job has been created and runs the risk of missing
>> That's why a user can request notifications when the create-job,
> print-job, or print-uri operation is done.
>> > relevant events. (c) presents the following challenges: there's
> > no way to tell the printer what job to associate the subscription
> > with since no job-id has been generated. How does the printer
>> Sigh... The create-job, print-job, and print-uri operations will
> have added operation attributes to address this, either by specifying
> a subscription ID or the notification attributes to create a new
> subscription automatically.
>> > differentiate this subscription from an (a) subscription so that
> > it doesn't start generating events until a job-to-subscription
> > association is made? Also, what happens if the same suscription
> > id is used with more than one subsequent job creations. How do
>> Each subscription will be associated with a single printer or job
> object. There has been discussion of "subscription sets" that would
> allow a subscription to be associated with more than one object
> and/or set of conditions, but my feeling is that most people don't
> want to add this complexity, especially since the client is free to
> create additional subscriptions that do the same thing.
>> As for the case where the user sends another job that is associated
> with an already assigned subscription, I don't think we've discussed
> this possibility yet. My personal feeling is that reusing the
> subscription ID should probably not be allowed, but we could also
> treat it as a special renew operation that also changes the
> subscription.
>> > we clean up subscriptions that are never associated with a job?
>> First, subscriptions have a "lease" time, which means that after a
> certain amount of time the subscriptions are automatically expired
> (cancelled.) Once a subscription is tied to a job, however, the
> subscription will remain alive until the job is cancelled or
> completed.
>> > What happens if a subscription is removed before the job
>> When the subscription is cancelled the user no longer gets
> notifications.
>> > completes? Does the subscription go away automatically when the
>> As noted above, subscriptions that are tied to a job are cancelled
> when the job is completed or cancelled.
>> > job is removed? I think it should. Keeping subscriptions and
> > job objects in sync can be pretty involved.
> > ...
>> We've already done some preliminary design work to work notifications
> and subscriptions into CUPS 1.1, and the code to manage such things
> is not all that complicated.
>> > <HParra> There has to be a way for end-users to request
> > notification of events that are related or directly affect their
> > jobs and nothing else.
>> Then they just subscribe when they send the job, so the subscription
> applies to the job. Or they can do a create-subscription operation
> and supply the subscription-id attribute with the job creation
> operation.
>> --
> ______________________________________________________________________
> Michael Sweet, Easy Software Products
>mike at easysw.com> Printing Software for UNIX
http://www.easysw.com
"Your logic is impeccable, Captain. We are in grave danger."