[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