If you have an implementation that wants to only implement the RFC 1422
subset under MIME/PEM, there's nothing in the MIME/PEM draft, by my
reading, that would prohibit this. (This is modulo the key selector
issue --- the key selector issue means that you have to store one
additional bit of information in your X.500 directory, but X.500
directory are supposed to be the best thing since sliced bread, and
they're flexible enough to handle this, right?)
The question is, what does it mean to be compliant with MIME/PEM? Do
you get to pick and choose like this, and if so, what will it mean if
a vendor touts MIME/PEM compatibility if they only implement what they
feel like? They won't interoperate with someone else who has picked
and chosen a different part.
I think that the draft is responsible for stating what is needed for
compliance and what is not. Some people, and unfortunately this
includes the authors, think this is a "local issue" and that the draft
does not have to address compatibility.
You mention that all you have to do is "store one additional bit of
information in your X.500 directory". To someone who wants to use an
existing database to simply work with MIME-formatted messages, it is
not a small deal to rework the database just to do this, if that is
required to be MIME/PEM compliant.
This is a big objection of mine to the current draft. I think the
ambiguity on this point - of what information the database is required
to carry for compliance - must be cleared up. It is inexcusable to
leave an implementor out in the cold in this issue.
If you only implement the RFC 1422 subset, then of course you have a
interoperability problem, but if someone is sending you a message that's
outside of your strict hierarchy, you don't *want* to interoperate with
them. After all, you've decided you only want to communicate with
entities that can be proven (up to a liability of $X million dollars)
came from a specific human being that you can sue.
If you implement the whole shebang, then you can accept messages from
both people in the strict hierarcy, *and* people who decided that a
looser, Volksmail approach is acceptable for their requirements.
What's the problem?
I think you're right that implementing only a subset prevents
interoperability. And I think that many people (including myself,
RSADSI, perhaps whoever Bob Jueneman advises, etc.) will only
implement the subset that makes sense. To reiterate, the "problem" is
that we may not have a standard if no one will be able to interoperate.
P.S. Please, everyone, let's remember that if we elevate MIME/PEM, it's
to a *proposed* *standard*. We're allowed to change proposed standards.
We're allowed to deprecate them later on, even. Vendors who ship
proposed standards as products have no standing to gripe if we change
things later on, especially if we have a good reason --- that's the
definition of proposed standard. I think we're setting bar unreasonably
high for MIME/PEM.
Maybe Ned Freed or someone who has seen several standards lifecycles
can comment. It's true that you can expect to work out a few bugs
when you move to a proposed standard. But is this true for major
issues?
- Jeff