IPP Mail Archive: IPP> RESEND: OPS - ISSUE: Should Get-Print

IPP> RESEND: OPS - ISSUE: Should Get-Printer-Supported-Values require operator/admin privileges?

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Mar 29 2000 - 13:41:08 EST

  • Next message: egglestn@lexmark.com: "IPP> testing"

    I sent this last night, but it hasn't come through the reflector.

    Tom

    > -----Original Message-----
    > From: Hastings, Tom N
    > Sent: Wednesday, March 29, 2000 01:17
    > To: 'ipp'
    > Subject: OPS - ISSUE: Should Get-Printer-Supported-Values require
    > operator/admin privileges?
    >
    > While finishing the last remaining editing on the "Job and Printer Set
    > Operations" document, it occurred to me that the access control for the
    > Get-Printer-Supported-Values operation would be more useful to
    > Administrative clients, if it was the same as Set-Printer-Attributes,
    > instead of the same as Get-Printer-Attributes. This is because an
    > administrative client that supports the Set-Printer-Attributes operation
    > SHOULD perform a Get-Printer-Supported-Values operation first in order to
    > present to the administrator what the possible values are that can be set
    > for the "xxx-supported" Printer attributes. If the Printer rejects the
    > request due to access control, then the administrative client knows not to
    > bother putting up the Set-Printer-Attributes UI, since any
    > Set-Printer-Attributes operation will fail.
    >
    > (BTW, this would also provide a harmless way for the client to get the
    > Printer to issue a challenge, since the Get-Printer-Supported-Values
    > doesn't change the Printer).
    >
    > So ok if I make the access privileges for Get-Printer-Supported-Attributes
    > be the same as Set-Printer-Attributes, i.e.,:
    >
    > Access Rights: The authenticated user (see [ipp-mod] section 8.3)
    > performing this operation must be an operator or administrator of the
    > Printer object (see [ipp-mod] Sections 1 and 8.5).
    >
    > Then Get-Printer-Supported-Values will have the following differences with
    > Get-Printer-Attributes with number 5 being added:
    >
    > This operation has identical request/response attributes to the
    > Get-Printer-Attributes operation in IPP/1.1 [ipp-mod]. The operation also
    > behaves identically to the Get-Printer-Attributes operation in IPP/1.1
    > [ipp-mod] with the following exceptions:
    > 1. The Get-Printer-Supported-Values operation supports only
    > "xxx-supported" attributes.
    > 2. The Get-Printer-Attributes operation returns the current values of
    > requested attributes while the Get-Printer-Supported-Values operation
    > returns the values that are inherently supported by the implementation
    > code, i.e., the values that an administrative client can set in a
    > Set-Printer-Attributes request.
    > 3. The Get-Printer-Attributes operation returns the current values of
    > requested "xxx-supported" attributes that the Printer is configured to
    > accept in Job Creation operations, including additional values defined by
    > the administrator, while the Get-Printer-Supported-Values operation
    > returns only the values of "xxx-supported" attributes that are inherently
    > supported by the implementation and does not return any additional values
    > define by the administrator.
    > 4. The Get-Printer-Attributes never returns the 'admin-define'
    > out-of-band attribute value, while the Get-Printer-Supported-Attributes
    > operation is allowed to, if the implementation allows the administrator to
    > set additional values for an "xxx-supported" attribute.
    > 5. The Get-Printer-Attributes operation can be performed by an
    > end-user, while the Get-Printer-Supported-Values requires operator or
    > administrator privileges.
    >
    > If I don't hear any objections, I'll produce the document with this
    > addition.
    >
    > Thanks,
    > Tom
    >
    >
    >



    This archive was generated by hypermail 2b29 : Wed Mar 29 2000 - 13:47:42 EST