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@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@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@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