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