Phil,
Not sure, but I think that this note is in concurrence with your views.
In any event:
1. Web vs. PEM.
What a strange basis for a confrontation. PEM does assert that it is for
messaging. But messaging and the Web have both been moving towards use of
Mime. (Reference to the various protocols other than HTTP/HTML as 'The
Web' is of course academically reasonable, but not helpful for these
protocol discussions. The Web is HTTP/HTML in terms of special protocol
definition. After that, it is a user-process integration of a collection
of independent, pre-existing protocols. That's useful, not in the purview
of a protocol standards effort.)
Either we believe Mime is a reasonable, common wrapping technique, or we
don't. It happens that I do, for most Web and messaging circumstances. If
we do believe it's reasonable, then we should seek to define and deploy as
much commonality of mechanism as possible. PEM, PGP, etc. are all oriented
towards object (rather than transport) security. Again, I think that that
is just the right model, for most circumstances.
2. 7bit vs. 8bit.
What a strange basis for a confrontation. It seems that some folks are
getting distracted by the details of the transport environment. For
reference, MIME tries to separate them, no doubt not adequately. Let me
suggest that Mime has a basic approach to separating and labeling objects
and then it has some syntax details, particularly designed to attend to the
(ummmmm....) vagaries of email transport.
The HTTP world has a nicer transport environment? Fine. Mime's binary
transport environment is sort-of defined, but actually turns out to be
kinda rough. It certainly is supposed to be appropriate for better
transport environments. Seems like the HTTP world would be a good
candidate for fixing that.
In the extreme, it may well be that some different details in the syntax
(e.g., byte count rather than boundary string) will make sense in a
legitimately binary environment. But be careful. One of the nice things
about protocol defined as text, as are HTTP and HTML, is that they are MUCH
easier to debug.
In any event, it sure would be nice if these design issues were treated
separably and cleanly.
3. Security schemes
I don't know if folks have noticed, but getting standardization and --
worse, still -- deployment of interoperable security mechanisms is quite
difficult. As in: all efforts to date have failed.
This ought to suggest to us that having fewer, not more, mechanisms is
worth working for. Why, then, would we want significantly different
mechanisms for the Web than for messaging?
And before one says that we aren't trying for that, ask youself just how
much security-related knowlege is being put into the Web's transport rather
than in its objects?
d/
--------------------
Dave Crocker
Brandenburg Consulting +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086
dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu