This had occurred to me. What worries me about the idea is that it's
going down the slippery slope toward having http: visible to users.
My experience is that users will see the ipp protocol elements; they
will not entirely be hidden. Having them at the HTTP protocol level
is confusing enough, but it seemed like a reasonable compromise
to make for the sake of code reusability.
As long as the client has to be able to deal with ipp: URLs from
users anyway, I don't see how having ipp: URLs in IPP protocol
elements places any more hardship on the client. It seems like
this conversion in the client only needs to be done in one place -
in the code that interfaces to the HTTP layer. Everywhere else,
the client should deal with URLs in ipp: format.
As for the use of https: in IPP attributes, I don't think IESG will
be very sympathetic. To me at least, the http:/https: distinction
seems insufficient for the purpose at hand, and I suspect that the
security ADs will agree. But whatever they decide about http/https,
I'll defer to their judgement on that one.
> Keith's solution creates a mapping problem for clients while giving no
> apparent benefit to the client. If there is a benefit at the client level,
> we have been unable to understand what it is.
There is definitely a benefit for clients that have plugins for different
URL types. A new ipp: URL type can be accomodated with an ipp plugin,
while the behavior for http: is either wired-in, or changing it to support
ipp incurs the possibility of changing the behavior for ordinary http access.
(and it gets worse if there are more than two protocols that want to
layer over http and use the http URL...whose plugin gets used -- the
ipp+http one or the xyz+http one?)
> If, indeed, the 'ipp' scheme is a good idea, I think that Keith's proposal
> makes the wrong partitioning of 'ipp' and 'http'. The partitioning should
> occur between client and user interface and not between the sending and
> receiving portions of the client.
I don't see the partition between sending and receiving portions of
the client. The partition I see is between the sending portion
of the client and its http module. It seems like a clean translation
to me, especially because it only needs to be done in the ipp->http
direction. What am I missing?
> I might support a requirement that users refer to a printer with an 'ipp'
> scheme (issue #2), even though such a requirement seems to be beyond a
> protocol standard.
>
> But before giving such support, I would like to understand why the IETF
> wants a scheme to specify the type of service. I would also like to see an
> IETF document that describes the intent and goals of this differentiation of
> schemes, as well as the infrastructure needed to support it. I would like
> to know how a protocol designer decides if a new service is different enough
> to warrant a new scheme.
Some thinking has been done about this. A draft document that discusses all
of these is being circulated internally by IESG and IAB, and being commented on.
> I would like to know if someone has thought about how to avoid the "new
> area code" problem as each new scheme is introduced. Without a such
> information, I am left wondering if the requirement of a new
> scheme for each new service will turn out to be a good idea.
I'm not sure I follow the area code analogy. To me the new area code
problem is that existing phone numbers have to change. That doesn't
happen when a new URL scheme is introduced, because it's naming new
services that didn't exist in the past.
The closest analogous problem that comes to mind is where you have a
service on protocol A named by an A: URL, and you want to offer
the service using (faster, cheaper, better) protocol B for those
cases that the client also supports B. This can be done with
URI resolution techniques that are being worked on, but they're not
yet ready for prime time. My guess is that the upcoming http-ng
work might well push this along, because nobody wants to change
all of those http: URLs that are out there for the sake of supporting
http-ng.
> Finally, I wonder how long it would have taken faxes to be deployed if
> someone had required a special fax number instead of a standard phone number.
I don't think it's a valid analogy. Faxes benefited from use of voice
lines - in most cases you didn't need a special phone line for faxes.
(and if you had needed a special fax line, the phone companies would
have tried to charge you more money for them.) But if there had been
phone lines and fax lines available at the same price, it would have
been a convenience - not a burden - for phone numbers to look slightly
different than fax numbers. Nobody would have ever gotten the two confused;
nobody would have ever dialed a wrong number and gotten a fax machine
instead of a voice, or vice versa.
As it is, ISDN does distinguish voice from fax from data. The distinction
didn't have to be in the phone number - it's another parameter in call
setup. That's like saying that we don't require the distinction between
ipp and http to be in the domain name of the server host - it should
be in the URL prefix for consistency with other URLs.
Keith