I support John on this one. I have an additional reason. The content type
helps ensure the proper binding. The content identifier may be defined in
a content-specific manner. o, two messages with different content types
could be assigned the same content identifier by the plug-ins that deal
with those content types. In this case, content type and content
identifier may be necessary to uniquely identify the message that
corresponds to the receipt.
Russ
At 01:40 PM 2/26/98 -0500, John Pawling wrote:
All,
IMHO, the Receipt contentType does serve a purpose and I believe that it
should be retained. It indicates the contentType of the message that
requested the signed receipt. If the app is managing multiple flavors of
contents, then this field will point the app in the right direction to find
the message that matches the Receipt signedContentIdentifier.
For example, lets say that CMS/ESS was being used in conjunction with X.400.
The content types could be P2, P22, P772, etc. The Receipt contentType
field will indicate which flavor of message that it needs to locate to
validate the signed receipt.
In summary, I believe that it would be short-sighted to remove the Receipt
contentType.
- John Pawling
At 11:08 AM 2/26/98 -0500, David P. Kemp wrote:
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
I respectfully disagree with Dave that contentType should be removed from
the Receipt content syntax. It is included in the signed receipt to
assist
the application that must validate the signed receipt with the process of
identifying the original message (or hash of the message) that
requested the
signed receipt. The original message (or hash of the message) is required
to validate the signed receipt. The Receipt contentType will
especially be
valuable to apps that must manage contents of multiple types.
Therefore, I
believe that contentType should be retained and that it should be
changed to
a mandatory field which will always contain the value copied from the
signedData encapContentInfo eContentType field of the message
requesting the
signed receipt.
I don't object to keeping contentType in Receipt if it serves a purpose.
However, I still don't understand what the purpose is. Currently, the
eContentType field of the innermost signed data will *always* contain
id-data, no? If Russ' proposal to define 4 additional OIDs for X.411
builtin message types, or my (as yet unproposed) proposal to define
a single id-data-x411 OID for X.411 messages is adopted, there will
be at most a few eContentType values. In practice, a single user
is not likely to have both S/MIME and X.411 original messages awaiting
receipts, so the contentType field in the Receipt will be totally
useless in distinguishing which message the receipt applies to.
At best, it could only help distinguish between S/MIME and X.411 messages.
Even then (if there were multiple content types), what is the purpose
of including contentType in the Receipt? The Receipt
signedContentIdentifier uniquely identifies the message to which the
receipt applies, so the UA only needs to validate the receipt against
that single message.
What am I missing?