"Herriot, Robert" wrote:
> ...
> In the above scenario, does the printer receive information about the
> students name and group name or just the group name?
Both names. The group name (and password) gets past the HTTP
authentication, and the student name is used for accounting (and in
some cases billing).
We even have some customers that are using barcode readers to validate
jobs before they are printed (the student puts his ID card under the
reader to release the job in the queue).
> ...
> > Also, given the current (lack of) transport-level encryption in
> > IPP/1.0 (and likely in most IPP/1.1 products), HTTP authentication
> > is just as prone to spoofing as the requesting-user-name field in
> > the IPP request.
>> I agree, except that its a little harder because the spoofer needs to
> get two pieces of information: a password and a name.
Still not that difficult...
> ...
> > I still don't like making the requesting-user-name attribute that
> > weak. In the group-account scenario it would allow a member of the
> > group to "anonymously" submit a job...
>> I don't know what you mean by "that weak". IPP says that a client
> "should" supply the requesting user name. If none is supplied, the
> printer doesn't know who submitted the job except for basic/digest
> information, if any. However, a printer implementation is free to
> have a policy that denies access to anonymous job submitters.
I say "weak" because in your original proposal the HTTP username would
override the requesting-user-name attribute. The HTTP username *should*
be used, but IMHO only if requesting-user-name is not supplied.
Also, since the spec doesn't require requesting-user-name, I don't
think that a compliant server can refuse the job on that basis.
This isn't something for the standard, but definitely should be
discussed in the implementer's guide. Otherwise we'll end up with
inconsistent implementations (both servers and clients) which will
limit the acceptance of IPP by large installations.
> ...
> No, an implementation must support values that apply to its transport.
> The values of the attribute "uri-security-supported" are also tied to
> what HTTP makes available.
> ...
OK, that does make sense then...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com