Frankly, I question your ability to assess the editing process in this way.
You
have been asked at least once, in response to general comments you made, to
provide specific feedback about what's right and what's wrong in these
documents. You have done nothing along these lines to the best of my
knowledge.
I did not mean to cast dispersions on the editors. You and Jim and have done
an admirable job in responding to the many skeptics on the list (myself
included). By editing process I meant the circular debate we are involved in
on this list that is directed at improving the specification. I know that the
IETF is not supposed to vote, but we really need the equivalent of a Robert's
Rules of Order for e-mail based meetings. For example, the "motions" allow a
group to focus on a specific course of action.
Actually, Robert's Rules of Order work just fine for this sort of thing. All
you have to do is follow them. I do so to the best of my knowledge and ability,
and I try to point out when other people fail to do so. But they don't work at
all when the chair doesn't follow them -- no set of rules could possibly work
under such circumstances. See my previous messages for specifics.
My main frustration still comes from the lack of a clear definition of
PEM-MIME
requirements. Specific comments on a document are quite difficult when there
is not full agreement on the requirements.
I disagree absolutely, totally, and completely. We are in last call. As such,
the document issues which we should be concerned with most on a procedural
level are those of precision, clarity, and technical accuracy. Agreement with
the approach is not required to make such comments.
I still have some basic disagreements with the requirements that PEM-MIME
appears to be written towards. Specifically, the creation of the new
identifiers (ASCII, email, etc.) do not seem to be necessary given the success
of PGP. I see no reason to bundle new PGP-like features into the
specification
when PGP is already a defacto standard. There is no problem with PGP
competing
with a separate more structured PEM. There are different market requirements
that drive implementations. In the current PEM-MIME specification the
PGP-like
features have been added without PGP interoperability, without the full PGP
trust model, and without the clarity of PGP naming conventions.
I outlined the reasons why I disagree with this assessment in previous
messages. I think having these additional mechanisms in PEM are very useful in
getting PEM deployed, regardless of whether or not they happen to overlap in
some ways with PGP. (I also don't think they increase the overlap nearly as
much as people think.)
Separate from my disagreements with the goals of the specification, I do have
specific issues with the mechanisms that will be sent in a separate e-mail
note.
Thank you for the more detailed feedback. I hope that Jim will have time to use
some of it in the next round of revisions. However, it is unfortunate that you
have waited so long to provide it, since the document has been practically
rewritten from scratch in the meantime, which probably makes many if not most
of the comments obsolete.
Ned