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