PEM WG Meeting Minutes
- A new field, "Content-Domain" will be added to the PEM
header. This field will be used to specify the type of content which
has been protected by PEM and thus what "UA" should be invoked after
PEM processing has been effected upon a received message. This
provides a facility for future carriage of data type other than
simple, RFC 822 mail, e.g., MIME, X.400, etc. This field must appear
exactly once in the message, immediately after Proc-Type. The initial
parameter value permitted for this field is "RFC-822" and will be so
specified in RFC 1115bis.
...
In recognition of this approach to
accommodating MIME, RFC 1113bis will be revised to make explicit that
it is a specification of core PEM functions plus use of PEM with RFC
822 mail, and that subsequent RFCs will address use of the core PEM
functions with other mail systems, e.g., MIME, X.400, etc.
Steve-
I'm wondering whether or not RFC1115bis is the best place to specify
the values for the new Content-Domain field.
Given the statement above that RFC1113bis will specify "core PEM
functions plus use of PEM with RFC 822 mail, and that subsequent RFCs
will address use of the core PEM functions with other mail systems", it
does not seem at all unreasonable that RFC 1113bis specify the
"RFC-822" value for the Content-Domain field, and that the subsequent
RFCs specify their own values for this field.
This approach would obviate the need to update and reissue RFF1115bis
each time PEM was integrated with another mail system. Also, this
approach would maintain the current scope of RFC 1115bis, which (in
theory need not be, but in practice) is limited to *cryptographic*
algorithms, modes and identifiers.
I'm not necessarily opposed to expanding the scope of RFC 1115bis if
that's the right thing to do, but at this point it doesn't seem
necessary and it would make for a bit more work now as well as into the
future.
-DB