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 att ribute

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Sep 13 2000 - 14:56:06 EDT

  • Next message: Hastings, Tom N: "RE: IPP> REG - Proposal for "job-recipient-name" Job Template att ribute"

    Michael (and Carl),

    You raise an interesting issue as to whether the client MUST supply a
    recipient name that is validated against a list. If so, then
    "job-recipient-name-supported" should be such a list, i.e., 1setOf
    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.

    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 say that the Printer
    will accept any names, i.e., to indicate that any value is acceptable. This
    is something Carl Kugler has talked about for "document-format-supported"
    last July as well.

    We could indicate that any value for an "xxx" is acceptable in one of three

    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

    We never closed on that discussion from last July.

    1. would cause a problem for existing clients to query "xxx-supported" and
    get back a new out-of-band value that they didn't understand.

    2. is compatible with existing clients.

    3. Has the problem that if the policy is to not validate the "xxx"
    attribute, what value would be in the "xxx-supported" value? (We can't
    currently have no value in a 1setOf attribute).

    So I favor 2.



    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Thursday, September 07, 2000 17:15
    To: Hastings, Tom N
    Cc: ipp (E-mail); QUALDOCS DL (E-mail)
    Subject: Re: IPP> REG - Proposal for "job-recipient-name" Job Template

    "Hastings, Tom N" wrote:
    > ...
    > If the client omits this attribute in a create request, the printer
    > MAY use the "job-recipient-name-default" (name(MAX)) Printer
    > attribute value, unless it has not been configured by the
    > administrator, or MAY use the "authenticated user" name (see
    > [IPP-MOD] section 8.3), depending on implementation.
    > ...

    What if the default has not been configured? Will the -default
    attribute contain an empty string, or will it be passed as a

    I'm thinking this and the job-recipient-name attribute may need to
    be a type2 keyword | name(MAX), with keywords like:


    to specify no specific recipient or the current admin/operator for
    the device.

    > The "job-recipient-name-supported" (integer(0:255) Printer attribute
    > indicates the maximum length that the Printer will accept for the
    > "job-recipient-name" Job Template attribute without truncation. A
    > ...

    Since the client will likely not know how to shorten a name so that
    it remains unique, and since the recipient name will probably need
    to be a valid name on the destination system anyways, having an
    attribute that specifies the maximum number of significant characters
    isn't all that useful IMHO.

    Also, since the -supported attributes usually enumerate the supported
    values for an attribute, it might make more sense to name it
    "job-reciepient-name-max" instead.

    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:06:52 EDT