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

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

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

Carl Kugler/Boulder/IBM kugler at us.ibm.com
Wed Sep 13 19:32:36 EDT 2000

Well, we could have a 'job-recipient-names-supported' attribute for
validation with the 'any' or 'unknown' out-of-band escape hatch for those
cases where any job-recipient-name is supported.  (My ideal general
solution to this kind of recurring xxx-supported problem would be to have
two out-of-band values;  'any' meaning any value is accepted, and 'unknown'
meaning "we won't know until we try".)

BTW, we've already several mixed-typed attributes, for example:
     job-hold-until-supported (1setOf keyword | name)
     job-sheets-supported (1setOf keyword | name)
     media-supported (1setOf keyword | name)
     media-ready (1setOf keyword | name)

(Not to mention that every Name implies the mixed types NameWithoutLanguage
and NameWithLanguage, and therefore every Keyword | Name is really


Jay Martin <jkm at underscore.com>@pwg.org on 09/13/2000 04:57:22 PM

Please respond to jkm at underscore.com

Sent by:  owner-ifx at pwg.org

To:   "McDonald, Ira" <imcdonald at sharplabs.com>
cc:   "'Hastings, Tom N'" <hastings at cp10.es.xerox.com>, Michael Sweet
      <mike at easysw.com>, Carl Kugler/Boulder/IBM at IBMUS, "ipp (E-mail)"
      <ipp at pwg.org>, "QUALDOCS DL (E-mail)" <ifx at pwg.org>
Subject:  Re: IFX> RE: IPP> REG - Proposal for "job-recipient-name" Job
      Template att ribute

I agree completely with Ira on this.  In fact, this whole thread
is looking pretty scary to me with respect to administrative overhead.

Does anyone else feel that way?


"McDonald, Ira" wrote:
> Hi,
> 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...
> Cheers,
> - Ira McDonald, consulting architect at Xerox and Sharp
>   High North Inc
> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at 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?
> it is, then we also need a way for the administrator to say that the
> will accept any names, i.e., to indicate that any value is acceptable.
> 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
> 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.
> We never closed on that discussion from last July.
> 1. would cause a problem for existing clients to query "xxx-supported"
> 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.
> Comments?
> Tom
> -----Original Message-----
> From: Michael Sweet [mailto:mike at 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
> attribute
> "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
> no-value?
> I'm thinking this and the job-recipient-name attribute may need to
> be a type2 keyword | name(MAX), with keywords like:
>     none
>     administrator
>     operator
> 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 at easysw.com
> Printing Software for UNIX                       http://www.easysw.com

More information about the Ipp mailing list