The following wording replaces all of in section 8.6 according to the
agreement at todays telcon.
----------------------------------------------
8.6 The "requesting-user-name" Operation Attribute
Each operation SHALL specify the user who is performing the operation
in both of the following two ways:
1) via the MANDATORY "requesting-user-name" operation attribute that a
client SHOULD supply in all operations. The client SHALL obtain the
value for this attribute from an environmental or network login name
for the user, rather than allowing the user to supply any value. If the
client does not supply a value for "requesting-user-name", the printer
SHALL assume that the client is supplying some anonymous name, such as
"anonymous".
2) via an authentication mechanism of the underlying transport which
may be configured to give no authentication information.
There are six cases to consider:
a) the authentication mechanism gives no information, and the client
doesn't specify "requesting-user-name".
b) the authentication mechanism gives no information, but the client
specifies "requesting-user-name".
c) the authentication mechanism specifies a user which has no human
readable representation, and the client doesn't specify
"requesting-user-name".
d) the authentication mechanism specifies a user which has no human
readable representation, but the client specifies
"requesting-user-name".
e) the authentication mechanism specifies a user which has a human
readable representation. The Printer object ignores the
"requesting-user-name".
f) the authentication mechanism specifies a user who is trusted and
whose name means that the value of the "requesting-user-name", which
must be present, is treated as the authenticated name.
The user-name has two forms:
one that is human readable: it is held in the MANDATORY
"job-originating-user-name" Job Description attribute which is set
during the job creation operations. It is used for presentation only,
such as returning in queries or printing on start sheets
one for authorization: it is held in an undefined (by IPP) Job object
attribute which is set by the job creation operation. It is used to
authorize other operations, such as Send-Document, Send-URI,
Cancel-Job, to determine the user when the my-jobs' attribute is
specified with Get-Jobs, and to limit what attributes to return with
Get-Attributes and Get-Jobs.
The human readable user name:
is the value of the "requesting-user-name" for cases b, d and f.
comes from the authentication mechanism for case e
is some anonymous name, such as "anonymous" for cases a and c.
The user name used for authorization:
is the value of the "requesting-user-name" for cases b and f.
comes from the authentication mechanism for cases c, d and e
is some anonymous name, such as "anonymous" for case a.
The essence of these rules for resolving conflicting sources of
user-names is that a printer implementation is free to pick either
source as long as it achieves consistent results. That is, if a user
uses the same path for a series of requests, the requests must all
appear to come from the same user from the standpoint of both the
human-readable user name and the user name for authorization This rule
must continue to apply even if a request could be authenticated by two
or more mechanisms. It doesn't matter which the several authentication
mechanism a Printer uses as long as it achieves consistent results. If
a client uses more than one authentication mechanism, it is recommended
that an administrator make all credentials resolve to the same user and
user-name as much as possible.