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

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

[I'm using my reply to Scott's message to try to explain the
IESG position, along with the difficulties that this WG has seen.] 

Scott,

Ihe process has indeed been ineffective in this case, but IPP
has been an unusual working group.  

IETF has traditionally relied heavily on participation by 
the extended IETF community, to ensure that different protocols 
don't "stomp on one another".  This worked better when the 
community consisted of a few hundred people.  IPP's practice 
of schedling frequent private meetings (that happened to be 
co-located with PWG meetings) and telephone conferences has, 
whether intentionally or not, biased its participation towards 
printer vendors, and away from users, and isolated it from the 
rest of IETF.   This is one reason why there wasn't much 
discussion in the IETF conference meetings - IPP was too 
hard for an outsider to follow.

None of these were violations of process rules, as far as I
can tell, and yet they've had a definite effect.  IETF will
have to learn from the experience, and perhaps find new
ways of letting groups move quickly (the frequent meetings
and calls are quite helpful in this regard) while still 
making sure that the resulting pieces fit together.  

IPP has also been working from some very different assumptions 
from that of most IETF working groups.  Most groups have no
trouble making sure that their protocols are distinguished
from other protocols.  This is the only group I've ever seen 
that tried to get approval for their protocol to masquerade 
as another protocol!

And finally, IPP produced a thick set of documents at a time when 
there was already far too much load on the ADs.  We let ourselves 
take on too many working groups, and got spread too thin, and 
we're only now starting to get back to normal now that many of 
those groups are winding down.

So the task of preventing "foot injuries" has fallen to me, 
and to a lesser degree, to IESG.   I'd much rather have 
the extended IETF community do the job - they're better at it,
and it's too much stress for me to do it alone.

And for other groups that are similarly isolated, I'm working
very hard to get other IETF folks in the group, so that their
voices are heard before the group thinks it has finished its work.

...

Now as to the technical issue:  what I originally said was that
you had to be able to distinguish the traffic.  In my mind this
was probably either a different port or a differnt HTTP method -
with a different port being the well-established traditional 
approach, and also the one which probably caused the least
pain for existing implementations.  

But a different default port also implies a different URL type.
What's the sense of having a default port that you have to type
in explicitly?  And for that matter, what's the sense in forcing
users to type in http://hostname:port/foobar when they could
far more easily type ipp://hostname/foobar?  (There's no 
precedent for it, but arguably a PRINT method would have 
also needed a different URL type.)

To be frank, I have a difficult time understanding what all of
the fuss is about...it seems like quite a simple change to the 
code... unless somebody has already produced thousands of mask-
programmed ROMs with http: and not ipp: wired into them. 
To my mind this is a very minor change, not unlike changes that 
IESG often requests before approval.  

But I didn't want to be autocratic about this.  So I went to IESG
to make sure that I'm not the only one with this opinion, to make
sure I'm not out on a limb.  I went to IESG because they're the
folks who do the final review, and it's their opinion that matters.
The conversation goes something like this:

me: "the IPP folks want to use http for their URL type instead of ipp"

iesg: "why do they want to do that?"

me: "because they're layering on top of HTTP, and because existing
     proxies and APIs can deal with http URLs but not ipp URLs"

iesg: "why are they layering on top of HTTP?"

me: "because it's familiar, and it has something resembling security, 
     and especially because it can go through firewalls.  To be honest, 
     they're not the only group that wants to do this.  And it's not
     a bad idea to reuse existing technology; I'm just claiming that
     firewall admins need to be able to distinguish ipp traffic from
     ordinary web traffic.  A separate default port is the traditional
     way to do this, and a different URL type is the traditional way to
     indicate a different default port."

iesg: "how do they use an HTTP firewall to talk to a different port?"

me: "if you explicitly specify the port number in the URL, when
     talking to a proxy, the proxy will talk out that port." 

iesg: "so they want to use http: so that it can tunnel through firewalls?"

me: "basically, yes.  and APIs"

So the conversation winds down, and the conclusion is that the IESG
can't understand  why IPP needs to use http: for its own purposes,
nor why IPP expects to be able to bypass firewalls.  And I can't explain
it to them.  Nobody likes what firewalls do to deployability of new 
applications, but it sets a bad precedent if we bless the practice of 
ipp bypassing them.  The general feeling seemed to be that for better 
or worse, every new protocol has to punch another hole through firewalls, 
that it's up to the sysadmins to make decisions about whether the holes 
get punched, and IETF shouldn't be second-guessing them.

To me the harm *to users* of using http: (and implicitly the default 
of port 80, no matter what the spec says) far outweighs the effort 
at doing a global search through the code for "http" and modifying 
it to support "ipp" instead/also.

The end result is that IESG and IAB are going to discuss these issues
and define rules for layering things on top of HTTP and/or reusing
existing ports and URL types.  In the meantime, I've essentially been 
told by a very skeptical IESG that the IPP WG is going to have to
show substantial justification for using http: rather than ipp:

I can't imagine what the justification might be, and I haven't seen 
anything resembling such justification on the list.  But I and at least
a few IESG folks seemed willing to listen once more.

So here's what is going to happen.  The IPP drafts should be formally
considered by the IESG at its next telechat, or the one thereafter.  
(either 2 or 4 weeks from today) IPP shouldn't change anything until 
the IESG finishes its review, because it's always possible that
IESG will request other changes.  In the meantime, IPP needs to be 
aware that there's substantial IESG skepticism about using http: 
instead of ipp:.

Perhaps the best thing for IPP to do in the meantime is to prepare
a letter to IESG and/or IAB that states why it thinks it should 
be able to use http:.  That way, I don't have to try to be an advocate
for something I don't understand.

Keith

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 2 Jul 1998 17:19:21 PDT

Keith,

I am sorry, but I want to send you one more reply before shutting
up for a while and let others get a chance to comment after the
holidays.

I do not think that you have represented the WG particularly well,
if the IESG discussion went as you described. You seem to be hang up
on the belief that IPP was only designed to "sneak through firewalls".
I believe that everybody in the WG gave up on that idea about a year ago.

The more substantial reason was that we would make use of existing HTTP
code and implementations, that had already been debugged and demonstated to
work in a large scale, thereby expecting to shorten the time it would take
to develop and deploy IPP implementations. Another reason was that HTTP is
already being used in printers today for management (port 280 was defined
to run management info over HTTP, in case you did not know), built-in HTML
manuals etc., which means that using HTTP for IPP is one less transfer
protocol to implement in a printer.
 
Looking at things in retrospect, it would most certainly have costed us
much less time and effort to invent our own protocol from scratch rather
than spending valuable time in extended debates about how we can or cannot
use HTTP. But at this stage, when many companies are already preparing IPP
implementations for rollout, I do not see it as an alternative any more.

On your point that mostly printer vendors have participated in the work.
Who else then OS/NOS vendors supplying IPP clients, and printer and print
server vendors supplying IPP Printers, do you image would have a strong
interest to participate?  Who else do you expect would actually implement
IPP? Linux folks perhaps - possibly!

Have a nice 4th of July holiday,

Carl-Uno

>for something I don't understand.
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: Robert Herriot <[email-masked]>
Date: Thu, 02 Jul 1998 17:32:49 -0700

Keith,

SWAP (http://people.netscape.com/kswenson/SWAP/charter.html )
is a project with much similarity to IPP.  

It uses HTTP, but has special methods and encodes its parameters in XML.
It is for workflow management, but it has a set of operations that are 
rather similar to IPP (see below).  The SWAP web page list you, Keith Moore, 
as one of the area directors.

The following text comes from the SWAP charter:

   "The purpose of working group is to provide a simple HTTP based way to 
   invoke, monitor, control, and be informed about a generic asynchronous 
   service. 

   The protocol defines: 

        ·       a standard way to invoke a generic service, which returns an
instance ID 

   Then, using the ID, the protocol defines how to 

        ·       get the current status of that instance of the service, 
        ·       give that instance of the service data values 
        ·       pause or resume that instance of the service 
        ·       retrieve preliminary results of that instance of the service 
        ·       register an address to receive event notifications from the
service 
        ·       receive events from that instance of the service "

What are your thoughts about SWAP?  Are they going to be allowed to 
use an http scheme? 

Bob Herriot

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Jul 1998 20:54:22 -0400

> to develop and deploy IPP implementations. 

I was aware of this also, but had a hard time making the justification.
It was obvious to me at the beginning that it would take less time
to develop a simple protocol, or to model a new protocol on say SMTP,
than to layer something on top of HTTP/1.1 with all of its warts.
The implementation effort for the new protocol is nothing compared to 
the effort it takes to figure out what it means to layer something on
top of HTTP.  Still, I've never thought that IPP's use of HTTP (even
with POST) was a really bad design choice; just that it was perhaps 
not the best.  And the best is the enemy of the good, which is why
I never pushed back more than to say "think carefully about this choice".

Again, I don't think it's really the layering of IPP over HTTP that
the IESG questions; rather, it's the odd use of the http URL.
This may make sense to the IPP folks but looks really odd to IESG.
(I suspect it won't make sense to users, either.)  And when IESG 
starts to examine the assumptions behind the design choice, it
starts to look even stranger.  But a lot of this is beside the
point - I really have no problem supporting the choice of HTTP
as a substrate for IPP, and IESG isn't going to second-guess that
choice.  The issue is only the use of the http: prefix.  It may be 
that IESG places a larger value on user friendliness than IPP does.

And I don't see what it means to have a default port for the
protocol if you have to type that port explicitly in the URL.

(Another note: given the increasing prevalance of NAT boxes, 
IESG is increasingly suspicious of protocols that transmit
IP addresses, or port numbers, as part of the protocol payload.
Such protocols tend to fail in the presence of NATs.  So if
the IPP protocol has to return URLs that include port numbers,
people get worried.  It may be that this is not a problem - 
you probably have to set up a special tunnel through your NATs 
for IPP anyway - but the subject did come up in the IESG
discussion and will probably be analyzed further.)

> IPP? Linux folks perhaps - possibly!

OS implementors in general, not just Linux folks.  System and network
administrators.  People who had designed and/or implemented print 
spooler protocols in their own environments.  It doesn't take large 
numbers of these people, just enough to provide an alternate perspective.

Keith

---

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

SWAP isn't yet a working group; they haven't even held a BOF.  
We plan to invite them to hold a BOF in Chicago.
Their draft charter thus doesn't reflect any IETF direction.

Because we haven't got to the point of charter review,
we really haven't evaluated their proposal to see where 
it fits in the architecture.  It would be premature for me
to speculate about whether they should use http:. 

But SWAP aside, my feeling is that the only protocols that should
use the http: scheme are those which operate on the same data
sets as traditional HTTP.  So WebDAV counts, as does probably DASL.
Other uses of http:, like for instance iCalendar or EDI, are dubious. 

Keith

---

From: Jay Martin <[email-masked]>
Date: Fri, 03 Jul 1998 14:31:54 -0400

Keith,

> Such protocols tend to fail in the presence of NATs.

Sorry, but what is a "NAT box" ?

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Jul 1998 14:57:06 -0400

> Sorry, but what is a "NAT box" ?

Network address translator.  It's a kind of IP router that changes
the source or destination address, or the source or destination port,
as the packets pass through.  A popular kind of NAT box is one that
provides the illusion of Internet access to a private IP network,
mapping one or more external IP addresses to a number of private
IP addresses.  Such boxes do not necessarily provide a one-to-one
mapping between an internal IP address and the one that appears
on the global Internet.  So they sometimes change the port number,
as well as the address, to avoid conflicts between multiple
hosts using the same external address and the same port.  And
the mappings between external and internal addresses may be 
dynamically assigned and change from time to time.

What this means is that a client or server's notion of the IP address 
or port used in the conversation, may not be the same as the server 
or client's view from the other end of the connection.  

Pure NAT boxes break a number of protocols that, for one reason
or another, depend on the client and server sharing the same notion
of endpoint identifiers.  So real NAT boxes tend to perform 
not only IP-level translation, but serve as translating proxies
for a number of higher level protocols.  NATs thus share many 
characteristics as firewalls, and often these functions are combined 
in one box.  But NAT boxes are more evil (from an application protocol
designer's point-of-view) than firewalls that don't do NAT.

Lots of us hate these things, but for a variety of reasons including
scarcity of IP address space, and commodity pricing of dialup accounts 
limited to one IP address, they're widely deployed.

Keith