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

From: Paul Moore <[email-masked]>
Date: Thu, 2 Jul 1998 11:24:48 -0700

Not so. Every IPP packet is a fully conformant HTTP packet. We are not
inventing a new protocol in the scheme sense. Point any lan sniffer at an
IPP exchange and ask it what the protocol is - it will say its HTTP. The
argument you are using would say that SMTP is not TCP/IP. IPP is layered on
top of HTTP - same way that form-based upload is.

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Thursday, July 02, 1998 11:16 AM
To: Paul Moore
Cc: 'Keith Moore'; [email-masked]; [email-masked]
Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) 

> My fundamental objection is that we are being asked to use a new concept
> 'psuedo-schemes' without this idea being drilled into at all. There should
> at least be an I-Draft discussing the idea.

Actually, it's the other way around.  IPP is designing a new protocol.
It happens to look a lot like HTTP, and there's no problem with that.
But the notion that IPP can insist that their protocol should use 
the same URL type as an existing protocol, is a significant departure 
from well-established practice that requires substantial justification.  
 
> Secondly there were many details that needed to be clarified. Was this
> simply a client convenience or did 'ipp:' ever go over the wire being the
> deepest one. The general idea seems to be that it is a user convenience
> thing. 

No, ipp: needs to go over the wire in all of the IPP protocol elements.

> In this case it is a client implementation issue and has nothing to
> do with the wire protocol (which is what this discussion is about) and so
> should not be accepted. 

It's not just a client implementation issue; it affects servers also.

Nearly every new protocol these days gets a new URL type.  
The issues with use of ipp: are no worse than for any other protocol.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Jul 1998 14:43:05 -0400

> inventing a new protocol in the scheme sense. 

That's not the way IESG sees it.  IPP is chartered to develop a protocol.

If you are having problems that no other working group is having, 
because you're layering over http, maybe you're taking the wrong approach.

> Point any lan sniffer at an
> IPP exchange and ask it what the protocol is - it will say its HTTP. 

This could be considered a bug with IPP.

> The argument you are using would say that SMTP is not TCP/IP. 
> IPP is layered on top of HTTP - same way that form-based upload is.

HTTP is an application by itself.  TCP/IP is not.  
IPP is trying to layer one application on top of another.

Keith

---

From: Tom Hastings <[email-masked]>
Date: Thu, 2 Jul 1998 12:22:23 PDT

>That's not the way IESG sees it.  IPP is chartered to develop a protocol.

Yes, but the WG chose to use an approach in which IPP server applications
could be implemented on existing HTTP web servers.  If it is a new protocol,
then we can't use existing deployed web servers, correct?

>IPP is trying to layer one application on top of another.

True.  However, layering one application on another has been the experience
in OSI and other layered architectures.  Being constrained to only 7 levels
is not allowing one application to build on another.

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 2 Jul 1998 12:37:40 PDT

>IPP is trying to layer one application on top of another.

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.

BTW, who determines whether an application can or cannot be layered
on top of another? If is you who decides, we would have liked to hear 
this kind of strong objection much earlier in the project. 

If we are going to have these kind of discussions, it seems to me 
that the IAB should get involved, as they are rather fundamental 
Internet design decisions. Re-using existing infra-structure or not 
seems to be one important discussion point.

Carl-Uno

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Jul 1998 16:25:51 -0400

> then we can't use existing deployed web servers, correct?

There's a long tradition in IETF of reusing and/or adapting existing
technology, so there's no problem with that per se.  But there are 
several problems with overloading a new protocol on top of existing 
web *services*.  And the idea that IPP should be able to tunnel
through firewalls "by default" - thus overriding local site policy -
does great harm to the overall Internet architecture.

> in OSI and other layered architectures.  

And one of the things we learned from OSI is that if you have too many
layers - especially layers that don't fit well together - the result
isn't very effective.  Otherwise known as the 'leaning tower' effect.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Jul 1998 16:51:10 -0400

> it's own scheme? It wasn't last time I checked.

SMTP is not an application; end users don't use SMTP by itself.
MIME is only the latest in a series of versions of the 
internet message format, which SMTP was tailor-made to carry.

But there is at least some precedent.  ARPAnet email was originally 
implemented by sending text messages over FTP and depositing them
in a file named after the recipient.  But this didn't work very
well, and was soon replaced.  Some TOPS-20 people layered their 
SMTP implementations on top of telnet support in their kernel, but 
eventually this turned out to be a Bad Idea.  All of this was 
long before the net had tens of millions of users, back when 
casual experimentation had fewer risks associated with it.
It was also before there was a formal standardization process.

The belief in this case is that IPP is different enough from 
ordinary HTTP traffic that the two should be distinguished.
 
> this kind of strong objection much earlier in the project. 

Ultimately, the IESG determines what is acceptable in an Internet 
standards track protocol, with provision for appeal to the IAB.

I agree that earlier notification would have been better.  But 
IPP is trying to do something radically different than most 
other working groups (even though it intended to be conservative), 
and some of the implications of its approach were not apparent
until recently.

> seems to be one important discussion point.

The IAB Chair participated in today's IESG conference call.  A more 
detailed response will be forthcoming, and the IAB Chair has requested
that IAB be in on the discussions.

Keith

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 2 Jul 1998 14:32:10 PDT

>internet message format, which SMTP was tailor-made to carry.

Keith,

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. How about IFAX and various other application projects that have been
impertinent enough to re-use rather than re-invent?

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?

Carl-Uno
Carl-Uno Manros

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 02 Jul 1998 21:34:13 +0000

> > >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.

> 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        <[email-masked]>
Agranat Systems, Inc.   Embedded Web Technology     http://www.agranat.com/

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Jul 1998 19:04:11 -0400

> 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

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.

> 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