I have added the language about the gateway that I was asked to add
and I have tightened the language to make things (hopefully) clearer.
I have addressed cases that are not addressed with the current language.
-------------------------------------------------------------------------
3.1.5.2 The "requesting-user-name" Operation Attribute
Existing Wording:
A Printer object SHALL support the MANDATORY "requesting-user-name"
operation attribute that a client SHOULD supply in all operations.
This operation attribute is provided in case (1) there is no security
service being used, (2) the client and Printer object negotiate to no
authorization, or (3) the authentication service does not make
available to the Printer object an authenticated printable
representation of the user's name that is making the request. 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.
For create requests the Printer object, upon creating a new Job object,
SHALL store the originating user's name in the MANDATORY
"job-originating-user-name" Job Description attribute. The
"job-originating- user-name" attribute is used for presentation only,
such as returning in queries or printing on start sheets, and is not
used for matching the authenticated principal of subsequent
operations. If the Printer object has access to a more authenticated
printable representation of the user's name, the Printer object SHALL
store that value instead of the value supplied by the client in the
"requesting-user-name" operation attribute.
The Printer object, upon creating a new Job object, SHALL store the
originating user's principal credential in an internal
implementation-dependent Job Description attribute. This attribute is
not specified as part of IPP, since it is not of any interest to
clients. However, the Printer object uses this internal attribute for
matching the authenticated principal id of subsequent operations. If
the Printer object has access to a more authenticated representation of
the user's id, the Printer object SHALL store that value instead of the
value supplied by the client in the "requesting-user-name" operation
attribute. Otherwise, the Printer object SHALL store the value
supplied by the client in the "requesting-user-name" operation
attribute.
-------------------------------------------------------------------------
Proposed wording:
Each operation SHALL specify the user who is performing the operation
in two ways:
1) via the 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.
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
doesnt 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 doesnt 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 which is special and
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 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 guest for cases a and c.
The 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 guest for case a.