I agree with every one of your comments. Looks like your idea of a
Subscription Object has legs.
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Tuesday, July 27, 1999 13:23
To: Hastings, Tom N
Cc: ipp
Subject: Re: IPP> NOT - Issue 1 - Add Subscription object?
"Hastings, Tom N" wrote:
> ...
> 1. Instead of using a URI to specify the target of a Subscription
> operation, we suggest that a Subscription object be specified using
> a Printer URI and a subscription-id (32-bit integer), just like
> jobs. There as been a lot of push back on IPP's having a "job-uri"
> to specify the target of a Job operation, so lets not repeat that
> for the Subscription object.
Yeah, I was also wondering about using a URI vs. an id. I went with
the URI mainly because jobs also used it... :)
Doesn't matter to me as long as we have a consistent way of
identifying notifications.
> 2. Presumably the authorization and authentication for creating
> Subscription objects would be handled by the implementation the same
> as jobs, whatever that is.
That was my thinking as well. Throughout all of the previous
authentication wars it all came down to the authentication provided
by the transport protocol (HTTP), and I'm all for keeping with this
method as long as IPP uses HTTP.
> 3. The client would supply as part of a Create-Subscription
> operation would be one of the following:
>> a. The Printer-URI to associate this Subscription with (has to be
> the same Printer-URI as the target of the Create-Subscription
> operation
> b. The job-id (rather than the job-uri) of the (previously
> created) Job to associate this Subscription with.
> c. Neither - the Subscription will be associated in a subsequent
> create job operation (Create-Job, Print-Job, Print-URI,
> Validate-Job).
Sounds good.
> Until such an association is made between a Subscription object and
> either:
> (1) a Printer object (in which the Subscription object is
> contained) or
> (2) a Job object,
> the Subscription object doesn't produce any event notifications.
> This is because until the association is made, it isn't clear
> whether a Job event means all jobs or just the job that the
> subscription is associated with.
Again, good stuff...
> 4. A create job operation (Create-Job, Print-Job, Print-URI) perform
> the association implicitly between the job being created and the
> Subscription being passes as create job operation attributes.
> Presumably, an additional operation attribute in the create job can
> associated a previously created Subscription object with the Job
> being created.
> ...
I think this can be covered by supplying:
(1) a subscription-id attribute to associate the job with an
existing subscription,
(2) notify-xxx attributes to create a new subscription with the
job,
(3) none of the above so that no subscription is created or
associated.
For cases 1 & 2 the job operation would return the subscription-id
attribute or the appropriate error status.
--
______________________________________________________________________
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."