Subject: Re: IPP> possible compromise?

From: Harry Lewis <[email-masked]>
Date: Wed, 15 Jul 1998 11:26:25 -0400

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

[email-masked] on 07/14/98 09:57:40 PM
Please respond to [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
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

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Jul 1998 12:07:05 -0400

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

I share your concern about the need for a timely end to the development
process.  

While I do have doubts about the viability of IPP security for some
of the scenarios that IPP has envisioned, I also recognize that my
expertise is limited in this area.  I would rather leave it to 
the security ADs to evaluate the adequacy of IPP security.  If it's 
okay with them, it will be okay with me.

Even if the security ADs share my concerns, I will push to get the
Proposed Standard versions of the IPP specifications published quickly 
and with as few changes as possible -- perhaps with some sort of
disclaimer about the limitations of the current security setup.  The 
vast majority of printing applications do not need a fully general 
security solution, and IPP should not be kept waiting until such a 
solution exists.  It may be that IPP needs additional work to 
define URL parameters and/or profiles for how TLS should be used 
in some of the scenarios, but even if this is necessary I believe 
that most of the work can be done in separate documents that aren't 
in the critical path for the main IPP set.

I am pushing for the IESG review to be complete by the end of July,
though there is some chance that the review will take two weeks
longer than that.  But I am hopeful that IESG can get the feedback to
IPP by end July, and complete IESG approval of any revisions before 
the Chicago IETF.

Keith

---

From: Harry Lewis <[email-masked]>
Date: Wed, 15 Jul 1998 16:04:24 -0400

I like the tune (different words) ... LPR was already out there... the IETF
wants to encourage a more interoperable standard... IPP isn't any worse,
security wise than LPR. I hope we can forgo the carrot and stick and
concentrate on the lettuce... as in let us do it ;-)

[email-masked] on 07/15/98 01:38:27 PM
Please respond to [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], Harry
Lewis/Boulder/IBM@ibmus
Subject: Re: IPP> possible compromise?

> I think it's useful to note that even LDAPv3 has recently been
> permitted to publish standards track RFCs WITHOUT any security
> mechanism (and a rather naive note that suggests read-only
> implementations).

The LDAPv3 case was a little odd.  LDAPv2 was already out there
without any useful security.  For various reasons, we wanted
to encourage people to move to LDAPv3, and LDAPv3 wasn't any
worse security-wise than LDAPv2.  The IESG note was the
carrot part of the compromise that was worked out.   The stick
was that the LDAP folks were supposed to do security before
anything else.   It didn't work very well; they drug their
feet about security.

> I maintain that even a read-only implementation of LDAPv3 without
> any security (for read) is a good deal more dangerous in the
> business liability and exposure sense that an implementation
> of IPP without any security in some printers is.

Obviously it depends on what information you're making available
through LDAPv3, and whether you're just doing so within your
enterprise vs. exporting it to the rest of the world.

Keith