Bill has stated concisely (as usual) what many of us have been
trying to "flag" for some time... that from 10,000 feet, IPP has lost it's
sense of streamline urgency and, although not a perfect solution, SWP appeared
to hit the mark with respect to these criteria.
> There was, at least at one time, a sense of urgency to the IPP
> mission. And this was accompanied by the understanding that a simple
> basic capability had the best chance of rapid approval, implementation
> and deployment. Indeed, one approach discussed was to provide multiple
> specifications, each concentrating on one major aspect, with an
> over-all structure making them compatible.
> However, IPP appears to reverted to the overall grand document
> approach which, I believe, will delay and possibly cripple the concept
> because there will be multiple proprietary, incompatible
> implementations in the field long before the ultimate IPP.
> The HP/Microsoft proposal appeared to be a refreshing return to the
> original concept; but it appears that IPP has simply absorbed it into
> an increasingly cumbersome mass.
Print by reference is not the only conflict (HTTP vs. IPP being the
heaviest in my opinion), but it represents an opportunity to renew and
exercise our philosophy which will reveal itself either as seeking
practical solutions to known problems or striving for architectural
perfection. We all feel an obligation to look forward, anticipate and
avoid pitfalls in the standards we are developing, but there comes a
time when it is wise to heed the "80/20" rule.
Stephen warns that print by reference could overwhelm printer based IPP
implementations if it means full HTTP client capabilities. This spawned
a great debate... one that every printer hardware and software vendor
wishes they really knew the answer to ... are customers more interested
in Peer-to-Peer or Server based solutions? Jay and Jeff have stated
opposite views. If we could gather 105 customers onto the reflector for
3 weeks, I doubt we would obtain a clear cut answer.
In my opinion, Larry has offered a convergence point for the Print by
Reference discussion:
>A HTTP client is not the same thing as a web browser.
>One way to simplify the 'footprint' requirement is to
>assert that any 'reference' that you want to 'print by'
>must be from, for example, a HTTP server, be directly
>available without redirection, and only be in a media type
>that the printer said it already supported.
>So, the implementation on the printer end would be basically:
> open a connection to the host in the URL
> send "GET url HTTP/1.1" and "accept: application/postscript"
> read the result:
> if not 200, error
> read headers:
> scan for content-type; if type isn't recognized, error
> read data as print data.
> close connection
>Maybe 100 lines of code? Certainly not megabytes.
>Don't turn a little capability (print by reference) into a big one
>(printer is a web browser) and then complain that the result is too big.
It may seem inappropriate for me to comment, since I have been
so heavily involved in trying to progress (and streamline) the job MIB
and have not made any specific detailed contributions to IPP. I haven't
been dealing with standards as long as some of you, but long enough to
understand (and have been part of) how group behavior among a bunch
of "brilliant" thinkers can be very difficult to manage, throttle and
maintain control of.
On this topic, I just offer that SWP is lacking Print by reference, which
many consider a real requirement. It is clear that various participants
view the need for IPP to scale from the Enterprise to the device. If kept
pragmatic and simple enough, I believe there might be a chance for SWP to
embrace Print by reference and satisfy the bulk of this requirement. If
not, the debate, and time, will rage on.
Harry