>2. If IPP is to be a serious IETF standard, then accept the rules.
>Expedience and arbitrary deadlines are not a licence for crap, and after
>checking IETF rules I can't see anything that says "if you have to get
>something out, just make up anything for the sake of the deadline". Jay
>may laugh about this and trivialize IETF rules with his comments about the
>UN, but I am sure he is a lone voice and that we (mostly) all do take IETF
>procedures seriously , and that I am perfectly correct in drawing attention
>to compliance with a proven system for getting the best solutions.
>
>If you want a industry standard, that is to say, a compromise for the sake
>of a quick and dirty patch, then just say so and I will shut up. But if
>this group wants IETF respect and status, then the rules are well known.
>But you can't have it both ways - make the choice.
There is nothing sacred about the deadline, but the team that initiated
this project felt that we should not drag our feet on getting something
done, so we set an agressive schedule. It looks like things will take
longer, but it has helped us to keep focused and move ahead at a pretty
good pace so far.
We are trying to produce quality in a reasonable time frame, spending years
on a subject is no guarantee for quality. A number of companies involved in
the project have already started up prototyping teams to help us verify the
quality as we move along with the specifications. Also, getting the first
set of RFCs out is, as you know, only the first step in the Internet
standardization process.
>The Possible Solution For Lateral Thinkers
>****************************
>
>3. Apart from this general principle of strategy being driven by quality
>and truly lasting - as opposed to band-aid patches - solutions, the issue
>of a practical and lean bandwidth protocol is far from clear. I am putting
>forward the alternative of something modelled *along* the lines of IMAP IV
>or IMSP (RFC 1730, 1733 etc) - tailor made for distributed computing and
>associated problems - synch, minimalist bandwidth, mobile users - the guts
>and glory of the 'net !!
>
>---> see www.cac.washington.edu/imap
>
>IMAP is already in or will be soon be put into many applications, including
>Netscape and IE; Eudora I think has it as well. The point is that it
>exists and this can be leveraged off so as to satisfy a good scheme and at
>the same time enable a fastrack rollout. Application wise, it is a
>happening thing, and can be rapidly and cheaply be adapted to IPP needs.
>
> Modifications - some radical - may, of course, be needed, but the
>groudwork and concepts are done ! Code is available, and it is
>*extensible* and scalable. Printing has many similarities to mail clients
>and servers, and in the internet context must assume that the user may not
>use the same workstation more than once and that job status and the users
>presence to receive the status may be out of synch. Therefore submission,
>status, capabilitiy, storage and re-synch are all important. IMAP has
>thought of and does all of this.
>
>It includes:-
>
>Offline submission and subsequent re-synch
>
>Extensions - is compatible with known standards and also supports cute
>"proprietory features" where available, as per optional SNMP - just what is
>needed so people can print properly and still allow market differentiation
>whilst making these opposites compatible.
>
>MIME support
>
>Ability to get basic file info/status without the whole file (very useful
>for say checking out a forms db and capabilities == lower bandwidth); this
>also means that new info can be added or changed when the job is submitted
>to an unknown server for unknown conventions or conversions as needed
>
Our going in position was to not reinvent the wheel when it came to a
suitable transport for the IPP semantics. We needed a client-server type
Internet protocol that could handle requests and responses, and we were
looking for something that was already part of the average users desktop
software set, or might become so within the next year or so.
FYI, an earlier proposal to base IPP transport on RFC 1831 and 1832 was
shot down due to the latter requirement.
Although I have followed the IETF messaging standardization for a number of
years, it did not occur to me that IMAP (version 4) would be a suitable
alternative, but maybe you are right. IMAP is indeed a client-server type
protocol and it should start appearing on an increasing number of desktops
in the foreseeable future. What would worry me is if we had to start
changing it around a lot to make it do IPP.... Another consideration is
that we want to find mappings that at least some people declare that they
are prepared to implement - without implementations the standardization
process cannot proceed.
The immediate assumption from people, when we talk about using HTTP, is
that HTTP is a bandwidth hog etc., but if you now start following our
protocol discussions more in detail, you will quickly find that the way we
intend to use HTTP would not contribute to bandwidth hogging. We would also
map it to HTTP 1.1, which attempts to reduce the bandwidth problem. Using
MIME to package IPP might actually cause more overhead. More serious
concerns with HTTP might be things like reliability.
Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com