Hi Michael,
Inline comments below.
Cheers,
- Ira
-----Original Message-----
From: Mike Sweet [mailto:mike at easysw.com]
Sent: Saturday, April 19, 2003 10:11 PM
To: McDonald, Ira
Cc: Hastings, Tom N; sm at pwg.org; ps at pwg.org; ipp at pwg.org
Subject: Re: [SPAM] RE: IPP> 4 significant proposed increases in
conformance requirem ents for the IPP Document object spec
McDonald, Ira wrote:
> ...
> Tom's notes are actually incomplete. A conforming implementation
> MUST support at least one scheme (I suggested we RECOMMEND that
> 'http:'), but an administrator _at_run_time_ may choose to disable
> this feature by reconfiguring "reference-uri-schemes-supported".
Well, then you will likely find very few implementations. We've
been working on Print-URI/Send-URI support for CUPS 1.2 and the
authentication/security/performance issues are a real hassle for a
real-world implementation.
Also, you can be sure that any CUPS implementation of the spec
WILL NOT enable print-by-reference by default for serious security
reasons, and there will be extremely high barriers in place to
limit how and where you can print from.
> I proposed making this operation (Send-URI) mandatory. But only
> if ALL implementations MUST support at least one reference scheme
> and SHOULD support 'http:' (note that PSI servers MUST support
> 'http:' for the AddDocumentByReference method).
Is there any practical reason why PSI can't just require stricter
requirements than the basic IPP mapping? It seems idiotic to
require print-by-reference for IPP whose goals are different than
PSI.
<ira> _my_ goal is full-bandwidth application gateways between
IPP and PSI. Everywhere that IPP doesn't have a feature at all
(the out-of-band push in PSI's AddDocumentByPush) or has made a
feature optional (PSI's AddDocumentByReference), the gateway will
fail entirely.
Note, PSI _is_ sending (over a TLS-secured channel) whatever
username and password or certificate necessary to do the SMTP,
IMAP, HTTPS, or whatever connection for the AddDocumentByReference,
from the client embedded in the PSI Print Service or Target Device.
If this is security nightmare for IPP, then the same applies to
PSI - why is it so hard if the Print Service simply impersonates
the end user? (I know this can't work if the end user's TLS
certificate is restricted to access from a pre-configured source
FQDN for the end user's system, but that problem _isn't_ soluble.)
</ira>
> I contend that the burden of adding a minimal HTTP client to an
> existing IPP-based printer is minimal. That's the question.
For a server that will only handle a single connection at a time,
and for simple accesses without authentication, it can be implemented
fairly easily.
However, for any non-trivial implementation there are authentication,
security, and performance issues that MUST be dealt with. Consider
a typical web application like email which uses HTTP authentication,
cookies, encryption, and probably some sort of host/ip-based session
key; a print-by-reference approach is doomed to fail even if we can
pass all of the required info to the IPP server, since it will somehow
have to re-login and go to the right URL. Assuming it *does* work
somehow, you need to securely manage this authentication information
or risk compromising a remote system.
I don't doubt that there is some minimal functionality that can be
provided by Print-URI and friends, however the cost/benefit ratio is
too high and I believe will hurt adoption of the document object
spec.
<ira> Well, print by reference is the main design center of PSI, so
if it will hurt adoption of IPP Document objects, then it will
equally hurt PSI adoption. Do you think PSI is in trouble??
</ira>
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com