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."