IPP> REG - Proposal for "job-recipient-name" Job Template attribute

IPP> REG - Proposal for "job-recipient-name" Job Template attribute

IPP> REG - Proposal for "job-recipient-name" Job Template attribute

Michael Sweet mike at easysw.com
Wed Sep 13 15:23:46 EDT 2000

"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

Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com

More information about the Ipp mailing list