If the marginal cost for scalable security in clients is really
that high, there will be a sizable market for cheaper clients that
do only digest authentication. If by these clients turn out to be
the rule rather than the exception, we can change the standard when
it is revised. IETF has a strong tradition of deprecating, eliminating,
or making optional unused or under-used features as specifications
progress along the standards-track.
> Within corporate intranets, the marketplace hasn't shown much
> interest in paying for strong security.
Yes, but there's a significant difference in the cost of using a
technology which is (a) nonstandard, (b) in limited use, and
(c) encumbered by patents, than the cost of using a standard
technology which will be widely deployed and is not so encumbered.
> Shoving the interoperability problem
> onto the client end (who, per last weeks IETF discussion now
> have to always support TLS, in order to be IPP clients) is just
> pushing the problem around.
Yes, but "just" pushing the problem around would appear to make
the overall solution cheaper. You seem to be arguing that we
don't really need interoperable security. Most of the knowledgable
users of the Internet, I suspect, would strongly disagree.
> Why not address the real interoperability between mutually
> secure clients and servers and SEPARATELY between mutually
> insecure (or weakly secure with HTTP/1.1 native facilities)
> clients and servers. Why should it matter that every IPP
> client implements strong security?
So that all clients and servers can interoperate.
Keith