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
At 04:08 PM 7/2/98 PDT, Keith Moore wrote:
>[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
>>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: manros at cp10.es.xerox.com