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

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

    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