How does this relate to the statements in the IPP/1.0 Model document:
"...
5.1.5 The Get-Attributes operation allows client to obtain
information from a Printer or Job object.
...
5.1.5.1 ... The client shall submit the Get-Attributes request
to a Job URI or Printer URI.
..."
Does this not handle the needed separation of job and printer attributes?
Brian
>From ipp-owner at pwg.org Thu Jun 12 17:34 EDT 1997
>Date: Thu, 12 Jun 1997 14:22:07 PDT
>To: ipp at pwg.org>From: Carl-Uno Manros <cmanros at cp10.es.xerox.com>
>Subject: IPP> SEC & MOD - Get-Attributes operation
>>We have just finished our SEC conference call for today and feel confident
>that we now have all the important stuff that we expect to provide in the
>document and will issue a new I-D shortly. We expect to discuss with the
>Protocol group on Tuesday, what they might still need from us to go into
>their document.
>>One issue that came up, was related to the Get-Attributes operation.
>>It is quite possible that a particular Job on a printer has different
>security requirements than getting information about the Printer itself.
>The Job security level is often determined by the job owner, while the
>Printer security level is determined by the printer administrator.
>>This seems to be a good reason to split up the Get-Attributes into a
>Get-Job-Attributes and a Get-Printer-Attributes operation.
>(Remember we created two new ones yesterday, so we are on the roll here :-)
>>I know that we have had this kind of discussion previously, but this is a
>new argument that has now come up in support of making a split.
>>As far as I can remember from last time we discussed this, there are
>situations in which you want to get back both Printer attributes and Job
>attributes in a response (e.g. printer status, when you ask about job
>status), but is that really a strong enough reason to only have one
>Get-Attributes operation, or should we rather consider making some special
>rules for things like status information?
>>Comments?
>>Carl-Uno
Brian Grimshaw
Apple Computer, Inc.
brian at apple.com