IPP Mail Archive: Re: IPP> REG - Proposal for "job-reci

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

From: Michael Sweet (mike@easysw.com)
Date: Wed Sep 13 2000 - 15:23:46 EDT

  • Next message: Michael Sweet: "Re: IPP> REG - Proposal for "job-recipient-name" Job Template attribute"

    "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@easysw.com
Printing Software for UNIX                       http://www.easysw.com

    This archive was generated by hypermail 2b29 : Wed Sep 13 2000 - 15:46:57 EDT