IPP Mail Archive: Re: IPP> regarding "ipp:" (I spoke too soon...)

IPP Mail Archive: Re: IPP> regarding "ipp:" (I spoke too soon...)

Re: IPP> regarding "ipp:" (I spoke too soon...)

Keith Moore (moore@cs.utk.edu)
Thu, 02 Jul 1998 19:04:11 -0400

> I still think your comparison does not hold up. In the same sense you could
> view HTTP as a transport protocol for HTML pages, and more lately XML
> pages.

And gif and jpeg files and java programs and etc. Obviously,
HTTP is a general purpose file transfer protocol. But printing
is not the same as file transfer.

But the problem is not that IPP is layering on top of the HTTP
protocol, the problem is that IPP wants to use the http: URL.

> How about IFAX and various other application projects that have been
> impertinent enough to re-use rather than re-invent?

IFAX is also having a hard time trying to shoehorn their model for
how they think fax works, into the model for Internet mail. But
basically they are two services for exchanging interpersonal messages -
one based on text and another based on images - and there's a lot
of synergy to be gained by combining the two. On the other hand,
when they try to violate the architecture of the email system,
they're getting pushback. The difference is that they're getting
it sooner in their lifespan than IPP did. On the other hand,
reconciling these issues is of fundamental importance to the ifax folks.
In the case of IPP we're not trying to fundamentally change how IPP
works - we're just trying to fix some notational bugs.

> Mind you, I have been involved in these kind of discussions for the last 20
> years and believe that I know what I am talking about. I think the truth of
> the matter is that the current Internet application protocols kind of
> emerged without any architecture what-so-ever, and that maybe now the IESG
> and IAB are starting to try to clean up the act. The IPP project just
> happens to be a road kill in that process. Am I right?

Well, in a sense, yes. We've got millions of users, an explosion
of new protocol development, vendor demands for quick development cycles,
and we've got ISPs and content-providers interfering with the needs of
users, and vendors interfering with the needs of ISPs, etc. ... all
of a sudden it has become much more important to try to sort out
the architecture, try to say who can do what, to prevent bad things
from happening.

Of course, if it weren't for these same forces, there wouldn't be
nearly as much reason for IPP to try to tunnel itself through HTTP.

It's not as if something has run over IPP; it's more like we've
diverted IPP to a ditch to keep it from hitting something moving
in the other direction and making an even larger mess.

Keith