Subject: IPP> IPP. Resuming relavant discussions. RFC 1730 as a basis !

From: [email-masked] (geoff)
Date: Sun, 9 Mar 1997 18:15:48 -0700

1.      For the benefit of Jay Martin, I am uninterested in nationalism.
Just the best technical solution by as many clued up, open minded people as
possible. Please refrain from your ridiculous and unfounded personal
asides. Your attempts to marginalize and trivialize people, as opposed to
issues,  simply shows bias.  Shut up and keep your personal stuff out of
this forum and stick to the issues.

Thank you and good night. Now to resume a relevant thread:

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.

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

**********

Can people please look through this and see how it can be shamlessly
plaguerized for good ideas. I see a lot of potential here to steal a march
!!

geoff

---

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 10 Mar 1997 10:24:54 PST

>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

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: [email-masked]