IPP Mail Archive: RE: IFX> RE: IPP> REG - Proposal for &q

IPP Mail Archive: RE: IFX> RE: IPP> REG - Proposal for &q

RE: IFX> RE: IPP> REG - Proposal for "job-recipient-name" Job Tem plate att ribute

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed Sep 13 2000 - 18:21:24 EDT

  • Next message: Jay Martin: "Re: IFX> RE: IPP> REG - Proposal for "job-recipient-name" Job Template att ribute"


    I believe we MUST NOT have a 'job-recipient-names-supported'
    attribute for validation - in many environments, this would
    be a list of the entire corporate address book (100,000
    names in some real-world cases).

    I also believe it's impossible to successfully safely
    mix keywords (operator) and names (Tom.Hastings) in this
    same attribute - because it cannot be mapped into other
    protocols with preservation of the native type (keyword
    versus name).

    Please don't do this...

    - Ira McDonald, consulting architect at Xerox and Sharp
      High North Inc

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Wednesday, September 13, 2000 11:56 AM
    To: Michael Sweet; Kugler Carl (E-mail)
    Cc: ipp (E-mail); QUALDOCS DL (E-mail)
    Subject: IFX> 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 - 18:35:46 EDT