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
server...

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



More information about the Ipp mailing list