When the first discussions about the URI/URL and related transport
issues first came up, there were serious discussions and ranting
arguments about the need to 'make as few changes in the HTTP protocol
to allow printing from browsers', and why we could not change
the URI/URL scheme.
At the time I pointed out the problems with trying to alias the
HTTP port/service to the IPP port/service and was roundly trashed
for this ... umm... heretical suggestion.
I would now like to comment that adding a new protocol/method such
as ipp: is nothing major, and has been accommodated by most browser
developers in a pretty trivial way.
How and why do you ask? Look at Real Video and Real Audio.
Try feeding 'npm://<realaudio server>:<port>/realaudiofile.ra'
to your browser, and VOILA! it works. Sorta.
Based on existing 'state of the art' and 'current technology', I
find the argument of the difficulty of using ipp: in the URL rather
hard to swallow, but did not want to rock the boat so close to
closure on the standard.
Note carefully that I did not say that it works CLEANLY, just that
it works. Of course, somebody would have to write a program to
assist the Internet Explorer (I gather that this is now a generic
term for browser) to connect to and send the file to the server,
but this is clearly akin to distributing a print driver for a
printer... Something that most printer manufacturers seem to regard
as part of the cost of doing business.
Patrick Powell
Patrick Powell Astart Technologies,
papowell at astart.com 9475 Chesapeake Drive, Suite D,
Network and System San Diego, CA 92123
Consulting 619-874-6543 FAX 619-279-8424
LPRng - Print Spooler (http://www.astart.com)