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?
...jay
"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? 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
> 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" 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.
>> 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