Jim,
Well, you caught me on a bad day, a Monday afternoon with too
much to do before yet another trip, so, I'll respond to your
marginally polite question about my motivation for not immediately
calling the question on this I-D.
The PEM WG has suffered through about 4 or 5 I-Ds on the topic
of PEM-MIME integration over what seems like about two years. It
started with a laudable goal of ensuring that MIME messages could be
carried in PEM and that PEM messages could be carried in MIME. The
first few attempts at this were not successful, as the subtlties of
plaintext signatues and cannocial representations in the MIME
environment posed problems. The pattern that emerged was that an I-D
would be prepared and it often was distributed two weeks prior to the
next IETF meeting, where discussion would detect yet another problem,
and the cycle would repeat.
Jeff Schiller proposed a simple, alternate solution to the
most recent set of problems of this sort, but it did not support the
recursive flexibility that the authors desired. So, in a spirit of
cooperation and a desire to make progress, Jeff graciously withdrew
his proposal, opening the way for a quick resolution. However, the
next version of the I-D was not just yet another revision in this long
process, but a rather radical redesign of PEM, keeping only some of
the syntax from 1421, and adding a host of "features" with little or
not accompanying rationale. Some of the features were responses to
discussions on PEM-DEV, but others seem harder to trace to any PEM WG
discussions. The lack of accompanying rationale, plus the relatively
low "readability" of the document overall, made it very difficult to
determine the full implications of this redesign of the protocol.
The fact that TISPEM had already been modified to implement
these features, the details of which had not been discussed in the WG,
was a bit surprizing. This gave the impression that the
authors/implementors had decided on this new design and were
presenting it for approval by the WG, but that the Wg per se had not
had a say in the protocol redesign. The fact that TIS later dropped
support for the older version of TISPEM, that supported the
RFC-defined protocol, also lent an impression of "coercion" to this
process.
My recollection of the last PEM WG meeting, captured in my
notes, suggests that a number of details of the I-D were discussed and
that there was general agreement on some of the problems with that
draft and some suggestions for changes. However, as I noted in my
last message, it's been over 3 months since I provided detailed
comments to you. There has been no inter-meeting discussion of these
topics on PEM-DEV, just the traditional two-week-prior-to-the
IETF-meeting revision of the I-D. Well, I have several tasks that I
am working on, as I suspect is true of many of the other PEM WG
members. I don't feel that we should have to drop whatever else we
have been doing and quickly review yet another revision of this I-D
and then quickly vote on it after the authors have taken such a long
time to make changes and release the document. Also, since TISPEM
has, for some time, reflected the design decisions of TIS
implementors, rather than the output of the WG, it would hardly seem
that mere standards process is standing in your way.
So, Jim, now you have a thorough discussion of my "motivation"
for proposing a late December or early January time frame for the vote
you requested. If there is substantial demand from the WG for an
earlier vote, I'll certainly accede to such demand.
Steve