"Hastings, Tom N" wrote:
> ...
> recipient name that is validated against a list. If so, then
> "job-recipient-name-supported" should be such a list, i.e., 1setOf
This raises a security concern for potential attacks...
> name(MAX). On the other hand, if the recipient is more like an
> open FAX model, then it would be an administrative burden to have
> to keep the name list up to date. Also you may want to include
> someone who is a visitor or a guest who doesn't have an account
> on the system.
I think the current ambiguity over what the user-name attributes
will contain should simply be resolved in the implementation
documents - for IPP printing applications, user-name attributes
should match up with usernames, while fax applications may or may
not follow that method.
The name attribute type can certainly handle things either way...
> How useful is having the Printer have the list of valid recipient
> names? If it is, then we also need a way for the administrator to
It's useful, but like many things needs the proper security in
place to make it safe from cracking and/or SPAM'ing.
> ...
> We could indicate that any value for an "xxx" is acceptable in one
> of three ways:
>> 1. with a new out-of-band 'any' in the "xxx-supported"
>> 2. use the existing 'no-value' to mean don't validate if it occurs
> in an "xxx-supported" attribute.
>> 3. with a new Printer Description attribute that listed those
> "xxx-supported" attribute name keywords for which no validation was
> the policy.
In the general case, an "any" value type would be useful for the
-supported attributes.
For the user-name stuff, it might be more appropriate to define
a new attribute that defines what the server expects for the
user-name attributes, e.g.:
printer-user-name-usage (type2 keyword)
with standard keywords of:
none - user names are not used at all
info - user names are informational
acct - user names must match local accounts
This at least would allow clients to pass in the appropriate
information (username or real name) depending on the type of
server...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com