I agree Patrick and, if I recall correctly, Randy from Sharp.
This lemming type rush towards SNMP/II/HTTP is the worst choice. This is a
classic case of the tail wagging the dog.
Strong words, but this has gone far enough. IPP must be driven by brains,
not inertia or path of least resistance.
Both HTTP and SNMP were invented for different reasons in a very different
stage of the 'net. HTTP is undergoing some radical changes - some by way
of commercial forces from Redmond, not official standards, and it is clear
in my mind that if selected it will fall into chaos and incompatibility in
the next year or two. HTTP is already bent and warped beyond the wildest
dreams of its inventors, and the herion type addiction for multi-media -
all focused around the web - will make this MUCH worse, especially when
Microsoft and others develop proprietory "enhancements". The networked
computer industry in very much molten right now, and in particular is the
future of the web, or whatever it becomes.
Here we are bashing printer concepts to fit in. Why ? Well because HTTP is
"there" (or rather, for now in its current form), and so is SNMP Mk.1. So
is a lot of other things, but none of them are necessarily good or relevant
to the future.
SNMP "just happened" in the printer industry- like RS232. Nothing really
good about it (or bad), just that is how it was to avoid manufacturers in
the past from squabbling over proprietory stuff. For example, Geneva is
the centre of diplomacy. No one knows why, nor is it particularly great,
but everyone just shrugs their shoulders and says "What the hell ? It is
always been like that".
This needs to be thoroughly discussed by email. Some of us live outside of
the USA (indeed, most of the world does), and can't make it to these IPP
meetings. No use of email in debate means limiting the quality of input
and challenging of notions, proof, and starting the cycle again until the
best idea is found. This is the core of science and engineering.
If this is not discussed in email then IPP will be a US centric thing. All
others are a scream nobody can hear.
This is **very bad indeed**, because it will then unconsciously assume that
that everywhere in the world has the same bandwidth and scale of economies
as the US, and HTTP is just groovy because there is bandwidth galore. The
idea of 56 or 64k of connectivity online as a household norm is a fantasy
in many parts of the world, such as in Asia. We will get an inappropriate
"solution" because of the narrow mindedness of US based
experiences/assumptions that everywhere is just like the USA. There are
serious router table problems as it is, massive cacheing and so on in many
countries. We should not add further to that problem with mediocre
I see a core group of names here effectively making decisions on things
because they seem to think they have a de facto monopoly. This is not the
correct procedure, spirit or rules for standard making.
We are here to make the best, not just the most expedient and be damned !!
The IETF has certain rules, certain traditions of technical excellence and
wide, international participation to make sure it will work for everyone,
not just a handful of printer companies for their US market.
I am going to refer this to the secretary of the internet society as an
example of yet another US hijack and problem waiting to happen because of
the assumption that HTTP is the "only" way to go and the rest of the world
can slop bandwidth around in the same manner as is implicitly assumed from
what I see. Putting an entire printer set of objects and scenarios in HTTP
Can we please have an open, honest debate on this that everyone can have
say in as per IETF traditions ?
At 12:08 PM 8/3/97, Patrick Powell wrote:
># I think it's fair to say that there is suspicion both on the
># part of some members of IPP to IETF, and of some members of IETF
># toward IPP. The best way to address this problem is to get the
># two groups working together.
># > However, it would be important for someone who is highly motivated
># > (because of existing business in legacy LPR systems) to take a look at
># > the IPP model and subsequent protocol to insure that this LPR mapping
># > can be done. If there are any real concerns, voice them now. I have
># > not heard major issues to date.
>>I am one of those people. I am the author of several LPR based print
>spooling systems and the reason I got involved was to make sure that
>RFC1179 is obsoleted by something rational.
>>I have some concerns - most of which revolve around PRESENTATION
>of the standard and making things uniform and understandable to
>the IETF audience. In addition, I think that the scope of the IPP
>protocol discussions and model is too limited - better to do it
>all at once rather than to have SNMP/SNMP II all over again.
>># Nor do I think there are any. It's just a matter of documenting
># how it is done.