IPP> possible compromise?

IPP> possible compromise?

Harry Lewis harryl at us.ibm.com
Wed Jul 15 11:26:25 EDT 1998


Keith, I am trying very hard to follow this discussion to some form of bedrock.
I'm not so adamant about the URL scheme... as long as I can base my initial
implementation on existing, off-the-shelf HTTP servers, which I think we have
safely agreed upon.

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 statement
represents a basic "open loop" in my estimation.

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

It is insufficient, at this point, to be in the position of taking a proposal
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 very near
term resolution of the security issue which will satisfy the IESG, I claim we
MUST focus (and adjust, if appropriate) the IPP effort on utilization of a
viable interim security method.

Harry Lewis - IBM Printing Systems



owner-ipp at pwg.org on 07/14/98 09:57:40 PM
Please respond to owner-ipp at pwg.org
To: robert.herriot at Eng.Sun.COM
cc: moore at cs.utk.edu, ipp at pwg.org, moore at 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 HTTP
> Request-Line
>
>
> Keith and the IPP working group are in disagreement about:
>    1)  the scheme in the value of  IPP attributes, such as "printer-uri".
>         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 they
> believe it is the cleanest design and avoids the mapping issue for clients
> 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 that
> neither a user nor networking software ever see. The 'http' choice (with 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 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






More information about the Ipp mailing list