Paul,
A couple of comments on the two drafts:
x400wrap-03:
I note that section 3.4.1 "Creating a Triple Wrapped Message With
An X.400" has been changed so that a ContentInfo
wrapping is no longer applied to the inner signed-data and
enveloped-data (end of step 3, end of step 4).
I can see that it saves me some bytes/redundancy in the encoding,
but maybe you could give me some background to this change?
I have a preference for keeping the contentInfo wrapping as:
a) it to some extent aligns with S/MIME ESS, where at each similar
stage a MIME construct is added (with a smime-type), and a generic
object (id-data) is passed to the next level of wrapping. In the
previous version the ContentInfo was the "generic" form that was
subject to the next protection operation.
b) it is simple to produce a "signed-only" version of a triple wrapped
message e.g. for forwarding, as removing outer two wrappers should give
me the appropriate form I require for a forwarded content bodypart.
c) it just appears to me to be a more generic, simpler solution.
ContentInfo encodings are what I am mostly likely to deal with e.g. in files
(although having a slightly larger encoding).
x400transport-03
In section 2.5 "Encoded Information Type Indication" it states that
"Additional values of smime-type are defined in ... [X400WRAP]."
However, x400-wrap-03 seems to defer to [TRANSPORT] for the definition
of its additional types (e.g. see last para of x400wrap-03 3.2.1).
x400wrap-03 would seem to be the right place.
In terms of the EITs, it would be much more useful if the EITs for
"wrapped X400" messages could indicate the actual X.400 content type that
is wrapped. Indicating to a UA that it will find X.400 rather than MIME
is useful but if the UA then finds EDI (or even unidentified content)
inside when expecting P22, then it hasn't really gained much.
It would be more useful if the EITs available were something like (in
smime-type notation):
signed-x400-p0
signed-x400-p2
signed-x400-p22
signed-x400-oid.<oid> (for external content types).
For X.400 EITs OIDs, you could use a OID concatenation method (as used
for ForwardedContent bodyparts) on id-eit-signedX400/id-eit-envelopedX400
for
external content types.
The main requirement I see is for a distinction between p22 and external
content types.
This provides me with more information about the internal X.400 content that
I am likely to find, and allows user agents to choose the appropriate form
for displaying the encapsulated content type.
This provides the same information as the contentHints.contentType ESS
extension, but is available to the MTS. The MTS could then act on this EIT
e.g. in a military environment, CMS wrapped P772 messages could be
identified over CMS wrapped P22 messages.
Comments?
Graeme