At 09:33 AM 2/3/98 -0500, David P. Kemp wrote:
SHOULD gives developers a guideline, which is better than nothing. The
specs contain lots of non-MUST information that nonetheless enhances
interoperability.
OTOH, if that section is removed, developers will still know by folklore
what they need to do to achieve interoperability. I prefer standards
to be explicit, rather than making developers join the club and learn
the secret handshake.
I agree fully. However, that's not the case here. Note that the first three
steps have already failed, so the sender didn't include a set of capabilities
and in fact has never sent an encrypted message to the recipient. Saying
"SHOULD use RC2/40" will not guarantee interoperability because lots of
recipients will have clients that don't include RC2/40 due to its weakness.
Looking at the lack of information we have about the recipient at that point,
I'd say any "SHOULD" is overstated.
The "problems with PKIX" have nothing to do with defining OIDs and
specifying parameter syntax.
They do: the S/MIME team is waiting for the PKIX specs to finish and don't
know
absolutely what the specs will say.
Including DH definitions in S/MIME by value
instead of by reference may be convenient, but you must be absolutely
sure that you don't introduce inconsistencies.
Precisely why I'm hesitant to do it by value.
I think referencing
PKIX Part 1, when it gets an RFC number, is preferable.
But will possibly delay us unless PKIX part 1 finishes soon. Thus my question
to this group about what we want to do. I'm leaning slightly towards "refer to
PKIX", but want Russ to have other text ready in case of delays, which have so
far appeared quite regularly in the PKIX work.
--Paul Hoffman, Director
--Internet Mail Consortium