ietf-smime
[Top] [All Lists]

Re: ESS EncapsulatedContentType

1998-03-02 08:58:44
From: Russ Housley <housley(_at_)spyrus(_dot_)com>

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,

I'm sorry to be a pest, but I am still finding it difficult to
understand this requirement.

ESS says: "A signedContentIdentifier MUST be created by the message
originator when creating a receipt request. To ensure global
uniqueness, the minimal signedContentIdentifier SHOULD contain a
concatenation of user-specific identification information (...), a
GeneralizedTime string, and a random number." Thus the
ContentIdentifier included in Receipt and ReceiptRequest uniquely
identifies the specific signed data without requiring the use of
ContentType.

Perhaps the plug-in assigned field you are discussing above is
"content hints", rather than "content identifier"?



At 01:40 PM 2/26/98 -0500, John Pawling wrote:

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.


What resource is being saved by "pointing the app in the right direction"?

If you have a pile of messages with different types (P2, P22, P772,
...) laying around when a receipt comes in, you need to scan each
message to determine whether it matches the receipt.  You could match
the content type of the receipt against each message and only compare
ContentIdentifiers if the ContentType matched, or you could always
compare ContentIdentifier and ignore ContentType.  How much disk I/O
and how many CPU cycles are you saving by doing a two stage compare
instead of just comparing a single field?  Is the miniscule savings
worth the extra complexity?

A more clever UA would just maintain a table mapping ContentIdentifiers
to messages, and would just search incoming receipts against the table
to find the message to which the receipt refers.  Including ContentType
in the Receipt is of no benefit here, it just takes up extra space.

Dave Kemp

<Prev in Thread] Current Thread [Next in Thread>