Revision of Signed Receipts

[Dale_Moberg@xxxxxxxxxxxx]

     Comments on ietf-ediint-as1 draft :
     
     1. I agree that section 5.2.3 should be removed so that the behavior 
     of downstream EDI processing can be left configurable by the user and 
     in accordance with detailed trading policies and agreements. 
     
     2. I think that in section 5.3 the need for the X-Received-MIC 
     extension field is overkill. The integrity check has already been done 
     by the receiver when the authentication was done. 
     It is not a real part of the signing of the receipt by the receiving 
     partner. It is not needed to correlate the receipt with the original 
     message because the original-message-id-field already does that. The 
     information conveyed is not really diagnostic of a problem with the 
     transport. It is not needed for gatewaying to other message transport 
     systems, as far as I can tell. Since it could be altered by a 
     malicious mail relay, it could create confusion about the success of 
     the transmission if the sending site actually tried to check the value
     in its records, assuming such information is kept (and if not, what
     would be the point of returning it). Nevertheless, if an application 
     wanted to send back this information,the information could easily be 
     incorporated within the RFC 1894 structure within the optional 
     returned message field. (The hash value is a "part" of the original 
     message, although buried.) Or it could be made a part of the human 
     readable report. I guess I don't see what real work the return of this 
     value is thought to play. I would prefer to see explicit additional 
     disposition-values such as "authentication-verified" or 
     "integrity-verified" instead of sending back this value.
     
     3. The semantics of the disposition values needs some clarification.
     First, can more than one disposition value be returned or are these
     values intended to be mutually exclusive? (Can there be a list
     following the header or multiple headers starting "Disposition:" ?)
     It is conceivable that trading partners would agree to autoprocess 
     purchase orders even if authentication failed, for example. 
     Authentication might fail because a certificate issuer validity
     period expired, and while awaiting a reissue, the partners might 
     decide to continue processsing. Software might even offer users a
     configurable option to ignore authentication to allow trading to 
     continue during a period of merely technical or administrative 
     difficulty. In that case, a MDN should say "autoprocessed" and 
     "authentication-failed". Also, the explanation of "autoprocessed" in 
     the ietf-ediint draft differs from the explanation in the fajman 
     draft.  The fajman draft says only that the user agent successfully 
     submitted the content for some further processing. The ietf-ediint 
     draft is less cautious and says that the contents were successfully 
     processed (by the downstream applications?). I think the ietf-ediint 
     language for autoprocessed should be aligned with the fajman draft 
     with no implication about the success of subsequent processing. The 
     downstream processing of EDI already has mechanisms for acknowledging 
     EDI processing if the trading partners agree to use them.
     
     Some other things I noticed while rereading this document:
     
     4. Section 5.4.1 suggests using compression but mentions no
     applicable standards for using it. What standards within the 
     MIME RFCs would specify an interoperable approach? 
     
     5. The References should be updated to reflect the new MIME RFCs
     2045 to 2049. One thing I noticed in these new RFCs is that the CRLF 
     before a boundary marker is considered part of the boundary marker. So 
     when using a binary content-transfer-encodings within multipart/signed 
     structures within the signed-then-enveloped EDI, it appears that
     a CRLF is to be appended to the binary stream  and then the boundary
     marker appended (?). In general, because any string can possibly occur
     within a binary part (especially if compressed), it will be hard to 
     guarantee that a boundary will work unless the binary is screened 
     against the boundary before packaging. I think that the 
     content-transfer-encoding field for a binary identity transfer 
     encoding should have a mandatory parameter of the length of the binary 
     field or else some other encoding should be used. Of course, you can 
     always just hope that your marker is nowhere in the 20 MB file most of 
     the time  :-).
     
     Bye,
     
     Dale Moberg