What I do need, however, is a timely end to the development process for=
this
standards specification. I suspect you would agree - none of us have
inexhaustible resources.
To this end, security appears to be a real "monkey wrench". Your statem=
ent
represents a basic "open loop" in my estimation.
>As for the use of https: in IPP attributes, I don't think IESG >will b=
e very
sympathetic. To me at least, the http:/https: >distinction seems insuf=
ficient
for the purpose at hand, and I >suspect that the security ADs will agre=
e. But
whatever they >decide about http/https, I'll defer to their judgement o=
n that
>one.
It is insufficient, at this point, to be in the position of taking a pr=
oposal
to the IESG which we know will fail to ratify and which is completely "=
Catch22"
in context. We can't have security because it's not there yet... yet we=
can't
use the security which is there. Unless there is some certainty of a ve=
ry near
term resolution of the security issue which will satisfy the IESG, I cl=
aim we
MUST focus (and adjust, if appropriate) the IPP effort on utilization o=
f a
viable interim security method.
Harry Lewis - IBM Printing Systems
owner-ipp@pwg.org on 07/14/98 09:57:40 PM
Please respond to owner-ipp@pwg.org
To: robert.herriot@Eng.Sun.COM
cc: moore@cs.utk.edu, ipp@pwg.org, moore@cs.utk.edu
Subject: Re: IPP> possible compromise?
> Keith and the IPP working group are in agreement:
>
> 1) Clients send only 'http' schemes in the HTTP Request-Line
> 2) Servers support the reception only of 'http' schemes in the HT=
TP
> Request-Line
>
>
> Keith and the IPP working group are in disagreement about:
> 1) the scheme in the value of IPP attributes, such as "printer-u=
ri".
> Keith wants 'ipp'. The IPP working group wants 'http'.
> 2) the scheme in external notation for printer URL's. Keith wants=
'ipp'.
> The IPP working group wants 'http'.
>
> The IPP working group wants an 'http' scheme for issue #1 because the=
y
> believe it is the cleanest design and avoids the mapping issue for cl=
ients
> that never expose a URL to a user. We don't understand the virtue of =
having
> an 'ipp' scheme in a block of data that a client must process, but th=
at
> neither a user nor networking software ever see. The 'http' choice (w=
ith its
> lack of mapping) also allows a print server to use an 'https' scheme =
in an
> IPP attribute without any mapping issues. Although 'https' is not a=
part
> of IPP, most vendors will probably support it for pragmatic reasons.=
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 n=
o
> 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 differe=
nt
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 supp=
ort
ipp incurs the possibility of changing the behavior for ordinary http a=
ccess.
(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 pro=
posal
> makes the wrong partitioning of 'ipp' and 'http'. The partitioning s=
hould
> occur between client and user interface and not between the sending a=
nd
> 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 IE=
TF
> 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 differentia=
tion 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 discusse=
s all
of these is being circulated internally by IESG and IAB, and being comm=
ented on.
> I would like to know if someone has thought about how to avoid the "n=
ew
> 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 i=
f
> 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 conf=
used;
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 distinct=
ion
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 betwee=
n
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
=