I have assumed that if a client submits a job J to printer P and then
queries the job id of J returned by the printJob operation for its
containing-printer-uri, it should get back P. But in any case, it can
still perform a Get-Jobs to P and see the job J in the list. So there
is no need for PrintJob to return containing-printer-uri because it
is the printer to which the PrintJob was submitted.
If someone who is not the owner of J queries J, then the P returned
may be different because of security issues. Thus containing-printer-uri
is a computed attribute whose value can differ for each query.
That's my view of it. I hope that others have the same understanding.
Bob Herriot
> From ipp-owner@pwg.org Wed Jan 14 11:32:51 1998
> X-Mailer: Novell GroupWise 4.1
> Date: Wed, 14 Jan 1998 12:04:00 -0700
> From: Scott Isaacson <SISAACSON@novell.com>
> To: ipp@pwg.org
> Subject: IPP> MOD - Problem with job ID and containing printer URI
> Mime-Version: 1.0
> Content-Disposition: inline
> Sender: ipp-owner@pwg.org
> X-Lines: 99
>
>
> We still have a problem with printer-uri, job-uri, job-id, and
> containing-printer-uri. Some statements of fact
>
> 1. The client supplied "printer-uri" in a create request MUST be one of the
> URIs in "printer-uri-supported"
> 2. For each new Job object, the Printer object generates both a "job-id" and
> a "job-uri".
> 3. If the client has a only a Job URI the client can query the Job to get
> the containing printer URI
> 4. We DO NOT return the "containing printer URI" in the create response, but
> we do return the Job URI and the Job ID. Since we do not return the
> containing printer URI, we are assuming that the containing printer URI MUST
> BE the same as the client supplied Printer URI.
>
> Here is the question:
>
> Should the Printer object generate the "containing-printer-uri" for a new
> Job object or should the Printer object use the client supplied
> "printer-uri"??
>
> Or stated another way:
>
> Should the "printer-uri" that a client uses on a create request be the
> "containing-printer-uri" or should the Printer object choose the value for
> "containing-printer-uri" which might be different than the client supplied
> printer URI in the create request?
>
> Some poeple have suggested that we should allow flexibility and allow the
> containing printer URI to be different than the original printer to which
> the create request was supplied. However, this would mandate:
>
> - ALWAYS returning a "containing-printer-uri" whenever the "job-id" is
> returned (create response, get Jobs query, query Job). We would never allow
> a client to get ONLY a job id. It MUST always get both since the client
> might query a Printer URI for a Job and then it might have to use a
> different Printer URI to query the job using the Job ID, so both must ALWAYS
> be returned.
> - The Job ID has no meaning in the the context of the Printer object being
> queried, only in the "contianing-printer-uri" Printer
>
> This seems convoluted. We have this flexibility in the Job URI (where it
> should be). We only introduced the Job ID for support for existing APIs. I
> am sure that these APIs to not support a Job ID coming back for a different
> printer than the one to which the job is being submitted.
>
> I think that the answer to the above should be:
>
> 1. The client supplied printer-uri should be the containing-printer-uri
> always! A client
> can always go back to Printer object to which the job was submitted and use
> the job-id.
> 2. If a client is querying a Printer for Jobs, the Printer only returns job
> ids for jobs that are associated with that Pritner URI
> 3. Leave the flexibility of Job identifiers that are independent of Printer
> URIs to the "job-uri" attribute not the "job-id"attribute.
>
> Scott
>
>
>
> ************************************************************
> Scott A. Isaacson
> Corporate Architect
> Novell Inc., M/S PRV-C-121
> 122 E 1700 S, Provo, UT 84606
> voice: (801) 861-7366, (800) 453-1267 x17366
> fax: (801) 861-2517
> email: sisaacson@novell.com
> web: http://www.novell.com
> ************************************************************
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>