Subject: IPP> Thanks Carl.

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

Mostly, very well put Carl.

IETF has neglected printing, but then  you can turn it around and ask the
same for printer companies, why did it take until late 1996 to get going ?
Who cares, but now that it IS being done, we all agree on achieving
quality.

>2) You are worried that most of the active participants happen to come from
>the US.

No, I am not at all worried where good ideas come from, providing this
subject is not closed by an implied fait accompli or hijacked by one or
more camps.  The savage attack I just got for questioning the wisdom of
HTTP is worry.  Why is this so delicate ? Am I transgressing on some
unspoken or hidden rule ?

I am merely concerned that HTTP is a bandwidth hog and that the US folks
have made an unconscious assumption that bandwidth is as relatively
plentiful as the US (exceptions and anomalies aside). That is all.

>4) It is true that we currently look at HTTP as one possible way to transfer
>the IPP operations.  A number of companies are going to launch such printing
>solutions as proprietary solutions over the next 6-18 months - you have the
>choice of de facto standards without any influence what-so-ever from the
>IETF or any other standards setting body, or to help in the development of a
>standard within the framework of IETF.

Sure, but that will happen no matter what, a consequence of the ever
thickening scheming and, er, strategy, of the printer manufactuer marketing
departments .   This leads to the same incompatibility problem you also
mention, which of course is not desirable, but in a crowded market, there
is the "differentiation" all the companies crave for as giving them that
elusive lead. The IMAP type proposal can accomodate a common IPP  standard
as well as extensions that keeps the competitive proprietory stuff enabled
without breaking the foundation, so everyone can be happy.

>6) If you are so worried about us being on the wrong track with HTTP (which
>is also on the IETF standards track in case you missed that), where are your
>constructive counter proposals for discussion?

IMAP, RFC 1730. Good startng point. Being stingy on bandwidth is important.
This needs work of course, but is worthy of a serious look in.

>7) If you think that we are running this project in a way that is not in
>line with the IETF guidelines, please point it out and I will make sure to
>correct it.

I am worried mainly at this magical arbitrary date will create a hack job.
On the other hand we don't want this to strctch out and become dinosaurs
like ISO.  But surely there is a middle ground. I am essentially stating
that IETF is a methodology of calm, careful, thoughtful  debate, not
rushing to deadlines or making decrees because everybody else is rushing
lemming like.  Yes HHTP is prevalent. But so is a lot of other stuff as
well, and some of that other prevalent stuff is better suited than HTTP for
our purposes.

I am prepared to put up concrete ideas, but not if HTTP has (against the
spirit of the IETF rules) become a fait accompli amongst the "inner circle"
because of expediency alone.  I am sure I am not the only one who wants a
stingy, pithy easy to understand protocol.  This is my main problem; the
indecent, unquestiong haste, like it is being shoved through before anyone
notices and/or objects.  This must not be set in stone until it has been
thoroughly examined and proven to be the best of a number of alternatives.
In other words, steam roller tactics is not acceptable IETF conduct.

Assuming this matter is not closed, then I will get cracking and would like
to see who else wants to work on the precise nuts and bolts of this ?
Patrick ? Randy ?

geoff