IPP> MOD - Should "operations-supported" values depend on the authenti cated role of the user?

IPP> MOD - Should "operations-supported" values depend on the authenti cated role of the user?

Hastings, Tom N hastings at cp10.es.xerox.com
Wed Jan 2 17:29:10 EST 2002


I'm sending this issue to both IPP and IPPFAX, since it affects IPP as well.

Peter thinks that IPPFAX shouldn't require that the Receiver return values
of the "operations-supported" Printer Description attribute that depend on
the authenticated role of the user making the query.  He thinks the values
returned should only depend on the URL supplied to the Printer object.

So that "operations-supported" would be the inclusive OR of all of the
operations that the Receiver supports for end users, operators, and
administrators authorized to use that URL.  The values returned for another
URL by the same Receiver (same Printer object), would be the inclusive OR of
all of the operations for end users, operations, and administrators
authorized to use that URL.

Another possibility for IPPFAX would be to make it a SHOULD for the Receiver
to return values that depend on the authenticated role of the user, rather
than a MUST, .

Or at least a MAY.

Discussion?

I'll add this as an ISSUE to the next version (0.9) of the document, unless
we get some email resolution of the subject.

Thanks,
Tom



	 -----Original Message-----
	From: 	Zehler, Peter  
	Sent:	Tuesday, December 18, 2001 06:49
	To:	Hastings, Tom N
	Subject:	RE: Questions about operations-supported and URLs
for a single Printer object

	Tom,

	Sorry for the delay.  I am now settled in to my new office.  I do
not see this as much of an issue.  Just because an operation is listed as
supported by a printer does not mean that the client has permission to
perform the operation.  Even if the operation is permitted does not mean
that the client is allowed to perform the operation on the specific target
(e.g. delete another user's job in IPP).  Why do we need to set role
specific limitations on "operations-supported"  I would think that the
behavior of limiting the capabilities of users in the client role would be
sufficient.  I have gotten used to permission denied error messages or
"client-error-not-authorized" in IPP and know what it means.  Getting an
command not found or "server-error-operation-not-supported" in IPP.  Does
the operations supported by a printer have to be different for users and
operators?

	Pete

		 -----Original Message-----
		From: 	Hastings, Tom N  
		Sent:	Friday, December 07, 2001 6:31 PM
		To:	McDonald, Ira
		Cc:	Zehler, Peter; Hastings, Tom N
		Subject:	RE: Questions about operations-supported and
URLs for a single Printer object

		Taking the view that URLs are either for end users only or
for operators only, IPPFAX section 5.4 operations-supported would become:

		The values of this attribute MUST depend on the URL supplied
in the "printer-uri" operation attribute.  For example, end users are not
allowed to use administrative operations, so that the URL for end users MUST
NOT return the administrative operation enums, such as "Disable-Printer"
enum when queried on the end user URL.  Conversely, the Receiver MUST NOT
support the Print-Job operation for operators (see section 8.1), so the
Print-Job enum MUST NOT be returned as the value of the
"operations-supported" attribute when queried with a URL that is meant only
for administration.  

		Comments?

		Tom

			 -----Original Message-----
			From: 	Hastings, Tom N  
			Sent:	Friday, December 07, 2001 15:25
			To:	McDonald, Ira
			Cc:	Zehler, Peter; Hastings, Tom N
			Subject:	RE: Questions about
operations-supported and URLs for a single Printer object

			I guess my real question is how are multiple URLs
used for a single Printer object, when one is for administration and the
other is for end users.

			Is the administrative URL only allow access by
administrators and the end user URL only allow access by end users (and not
operators or administrators)?  In this case, then the values returned by the
"operations-supported" need only depend on the URL.

			On the other hand, if the end user URL also allows
the operator and administrator access, then the values returned by
"operations-supported" would depend on the authenticated user, not the URL.

			Thanks,
			Tom

				 -----Original Message-----
				From: 	Hastings, Tom N  
				Sent:	Friday, December 07, 2001 15:19
				To:	Ira at Xerox XR&T McDonald (E-mail)
				Cc:	Tom Hastings (E-mail); Peter Zehler
(E-mail)
				Subject:	Questions about
operations-supported and URLs for a single Printer object

				Ira and Peter,

				We've agreed for IPPFAX (see Table 11 and
12) that there are certain operations that end users can do that operators
can't do (such as Print-Job) and certain operations that operators can do
that end users can do, such as Disable-Printer.

				So what is it that causes different values
of "operations-supported" to be returned in a Get-Printer-Attributes
response:

				1. the authentication of the user on the
same URL?  If the user is an end user, then he gets certain values returned,
and if the user authenticates as an operator they get back other values?

				OR

				2. the use of the end user URL versus the
operator URL?  If the user is authorized to use the end user URL, then he
gets end user values back.  If the user is authorized to use the operator
URL, then he gets the operator value back.

				The latter depends on the URL supplied.  The
former depends on the authentication for a single URL.

				This question needs to be answered for
section 5.4 operations-supported.

				Currently, it has the sentence:

				The values of this attribute MUST depend on
the URL Context.  But that was when we could have both IPP and IPPFAX URLs
for the same Printer object.  But now we can't.

				So should this sentence be changed to say
that the values depend on the authentication of the requesting user: end
user, versus operator, versus administrator?

				Or should this sentence be changed to say
that the values depend on the URL supplied as the value of the "printer-uri"
operation attribute.  [regardless of how the user is authenticated].

				Thanks,
				Tom  




More information about the Ipp mailing list