Re: IPP> regarding "ipp:" (I spoke too soon...)
Scott Lawrence <lawrence@agranat.com> Thu, 02 July 1998 21:52 UTC
Delivery-Date: Thu, 02 Jul 1998 17:52:02 -0400
Return-Path: ipp-owner@pwg.org
Received: from cnri.reston.va.us (ns [132.151.1.1])
by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA11539
for <ietf-archive@ietf.org>; Thu, 2 Jul 1998 17:52:01 -0400 (EDT)
Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30])
by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA23625
for <ietf-archive@cnri.reston.va.us>; Thu, 2 Jul 1998 17:54:22 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com
(8.7.5/8.7.3) with SMTP id RAA11056 for <ietf-archive@cnri.reston.va.us>;
Thu, 2 Jul 1998 17:51:58 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 17:47:50 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id
RAA09229 for ipp-outgoing; Thu, 2 Jul 1998 17:34:48 -0400 (EDT)
Message-ID: <359BFCD5.FAE3F6D0@agranat.com>
Date: Thu, 02 Jul 1998 21:34:13 +0000
From: Scott Lawrence <lawrence@agranat.com>
Organization: Agranat Systems http://www.agranat.com/
X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.32 i686)
MIME-Version: 1.0
To: Keith Moore <moore@cs.utk.edu>
CC: IPP List <ipp@pwg.org>
Subject: Re: IPP> regarding "ipp:" (I spoke too soon...)
References: <199807022051.QAA11639@spot.cs.utk.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipp@pwg.org
Keith Moore wrote: > > > >HTTP is an application by itself. TCP/IP is not. > > >IPP is trying to layer one application on top of another. Actually, I've long been of the opinion that while the lines are blurred somewhat that current HTTP is really more a combination of Session and Presentation layers - it is used by web browsers to impelement interactions between web browsers and web servers, but it is clear that it is being adopted for other purposes as well. The request/response components of HTTP form brief 'sessions' - associations between application layer entities carried over a transport. Note that HTTP persistent connections do not even all carry requests from the same application endpoints (as in the case of a proxy combining requests from multiple clients to an origin server). MIME is really a form of presentation layer - it provides the metadata that enables the applications to communicate the form of the data being exchanged. Only the cache control features of HTTP are really application functions. It is my hope that the HTTP-NG effort can clarify the distinctions between the session-like, presentation-like, and application-like features, despite the fact that the Internet protocol family has historically behaved as though it was anathema to call anything above TCP anything but an application. > > In a sense you are right, but in effect IPP is sending MIME > > packages over HTTP. This has been our stragegy for more than a year. > > Is MIME over SMTP considered a separate application that needs > > it's own scheme? It wasn't last time I checked. > The belief in this case is that IPP is different enough from > ordinary HTTP traffic that the two should be distinguished. But that doesn't change the fact that the IPP group has been quite carefull not to alter or extend HTTP in order to do so - they have in fact layered thier work. -- Scott Lawrence Consulting Engineer <lawrence@agranat.com> Agranat Systems, Inc. Embedded Web Technology http://www.agranat.com/
- IPP> regarding "ipp:" (I spoke too soon...) Keith Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...) Carl-Uno Manros
- RE: IPP> regarding "ipp:" (I spoke too soon...) Paul Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...) Keith Moore
- RE: IPP> regarding "ipp:" (I spoke too soon...) Paul Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...) Keith Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...) Carl-Uno Manros
- Re: IPP> regarding "ipp:" (I spoke too soon...) Tom Hastings
- Re: IPP> regarding "ipp:" (I spoke too soon...) Carl-Uno Manros
- Re: IPP> regarding "ipp:" (I spoke too soon...) Keith Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...) Keith Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...) Keith Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...) Scott Isaacson
- RE: IPP> regarding "ipp:" (I spoke too soon...) Josh Cohen
- Re: IPP> regarding "ipp:" (I spoke too soon...) Carl-Uno Manros
- Re: IPP> regarding "ipp:" (I spoke too soon...) Scott Lawrence
- Re: IPP> regarding "ipp:" (I spoke too soon...) Keith Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...) Keith Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...) Randy Turner
- Re: IPP> regarding "ipp:" (I spoke too soon...) Carl-Uno Manros
- Re: IPP> regarding "ipp:" (I spoke too soon...) Robert Herriot
- Re: IPP> regarding "ipp:" (I spoke too soon...) Keith Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...) Keith Moore
- RE: IPP> regarding "ipp:" (I spoke too soon...) Josh Cohen
- Re: IPP> regarding "ipp:" (I spoke too soon...) Jay Martin
- Re: IPP> regarding "ipp:" (I spoke too soon...) Keith Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...)[a… Tom Hastings
- Re: IPP> regarding "ipp:" (I spoke too soon...)[a… Keith Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...)[a… Tom Hastings
- Re: IPP> regarding "ipp:" (I spoke too soon...)[a… Keith Moore
- IPP> clarification needed re: "ipp:" proposal Keith Moore
- Re: IPP> regarding "ipp:" (I spoke too soon...) papowell
- Re: IPP> regarding "ipp:" (I spoke too soon...)[a… Tom Hastings
- RE: IPP> regarding "ipp:" (I spoke too soon...) Ron Bergman
- IPP> On clarifying the proposal for a new IPP sch… Tom Hastings
- IPP> Re: On clarifying the proposal for a new IPP… Keith Moore
- Re: IPP> Re: On clarifying the proposal for a new… Carl-Uno Manros