[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Messaging Spec v1.092
right, I'm not advocating that the practice be used, but that it not be precluded, that's all. Cheers, Chris Ralph Berwanger wrote: > Chris, > I agree with the technique. I can even make a convincing > argument for including the capability. I would think that if a message > originator requested a signed receipt and did not elect to sign the > original document that the orignator would have a facility to validate > the signature value returned in the receipt. > I have a significant collection of legacy data and I am having > trouble processing this discussion in light of many previous debates, to > include those with members of the ABA and some elements of the Federal > Government. My issue boils down to, "I am concerned about the > perceptions it may spawn." This may not be sufficient enough reason to > vote against supporting the capability. I can remember early > discussions regarding dis-embodies signatures and the number of people > asking, "who would ever do that?" > > Ralph > > -----Original Message----- > From: Christopher Ferris [mailto:chris.ferris@sun.com] > Sent: Friday, January 04, 2002 8:40 AM > To: Ralph Berwanger > Cc: David Fischer; Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail) > Subject: Re: [ebxml-msg] Messaging Spec v1.092 > > > Ralph, > > Right, but if I'm not mistaken, the receipient sends > a signed receipt before it receives the original signed > digest. The distinction is that while the process involves > signatures in both directions, the implementation details > are such that from the perspective of the MSH, the original > message is *not* signed and the receipt (ack) *is* signed. > > Cheers, > > Chris > > Ralph Berwanger wrote: > > >>Chris, your example is sort of correct . It is a case where >> > signatures > >>are sent independent of the document being signed. The exact process >> > is > >>not important, what is important is that the banks are sending a >>signature for the original documents--independent of the original >>documents. This is one of the defined uses of the EDIFACT AUTACK >>message. This business process was driven by the high cost of >>telecommunications services and the business hours of bank officials. >>But you see, there is a signature related to the original message and >>that is the point. The business case does not expect a signed >> > response > >>to a non-signed message. >> >>Ralph Berwanger >> >>-----Original Message----- >>From: Christopher Ferris [mailto:chris.ferris@sun.com] >>Sent: Friday, January 04, 2002 8:21 AM >>To: Ralph Berwanger >>Cc: David Fischer; Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail) >>Subject: Re: [ebxml-msg] Messaging Spec v1.092 >> >> >>Actually, I agree with David. It may seem that it isn't >>secure, but in fact, it can be. I believe that I've heard >>of a banking application that doesn't sign individual >>messages, but *does* calculate a digest for each which is >>stored before the message is sent. The recipient then also >>calculates the digest and sends a signed receipt (equivalent) >>over the calculated digest which the original sender then >>compares with the original digest (as well as validating >>the signature certificates, etc.). At the end of the >>day, the original sender then sends a signed message >>that contains information that indicates whether any >>of the digests mismatched and *then* the recipient can >>process the batch it received knowing that they were >>securely received intact and untampered. >> >>Cheers, >> >>Chris >> >>Ralph Berwanger wrote: >> >> >> >>>David, >>> >>> I must disagree with you on item 9. It makes NO sense to return a >>> >>> >>>signed receipt for a document that did not contain an original >>>signature. I know that the intent is to provide the message >>> >>> >>originator >> >> >>>with some sense of security; however, it is not really achieved and it >>> >>> >>>may in fact provide them a false sense of security. They may assume >>> >>> >>that >> >> >>>the signed receipt makes a legal statement that it cannot make. This >>> >>> >>is >> >> >>>not a technical issue, it is a legal and business issue--we will do >>> >>> >>the >> >> >>>community a disservice if we support signed receipts for unsigned >>>messages.I have been around this argument many times with the same >>>findings. >>> >>> >>> >>>Ralph Berwanger >>> >>> -----Original Message----- >>> From: David Fischer [mailto:david@drummondgroup.com] >>> Sent: Thursday, January 03, 2002 7:48 PM >>> To: Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail) >>> Subject: RE: [ebxml-msg] Messaging Spec v1.092 >>> >>> Comments inline. >>> >>> >>> >>> Ian, >>> >>> We still have a couple of unresolved issues -- most notably the >>> signature problem Sanjay pointed out. There is also the issue >>> >>> >>(item >> >> >>> 6 below) that SyncReply does not work with Intermediate >>> Acknowledgments. We are supposed to start voting tomorrow. What >>> shall we do? If you would like, I can go ahead and post as >>> >>> >>version >> >> >>> 1.093? >>> >>> >>> >>> I want to thank everyone for all the help on editing/reviewing the >>> specification. I think this is a much better spec than v1.0. >>> >>> >>That >> >> >>> said, I will also say I plan to vote *no* on this spec for two >>> reasons: 1) Our charter was to create a v1.1 spec with "fixes and >>> clarifications only" which we have failed to do (if we >>> could name this spec v2.0, as the RegRep team did, then this >>> objection would go away), and 2) Our original charter was to >>> create a set of "orthogonal ebXML specifications" which we have >>> failed to do (we have tightly coupled Messaging with CPPA). I >>> >>> >>would >> >> >>> like to urge everyone to consider a version number of v2.0 since >>> v1.1 has the connotation of backward compatibility which we >>> certainly have not achieved. Our next version could then be v3.0? >>> >>> >>> >>> Please let me know what you want to do. >>> >>> >>> >>> David. >>> >>> -----Original Message----- >>> From: Arvola Chan [mailto:arvola@tibco.com] >>> Sent: Wednesday, January 02, 2002 2:34 PM >>> To: David Fischer; ebXML Msg >>> Subject: Re: [ebxml-msg] Messaging Spec v1.092 >>> >>> David: >>> >>> >>> >>> Here are some belated editorial comments. I hope they can be >>> fixed without too much trouble: >>> >>> 1. Line 18: Don't we have to wait for a calendar quarter >>> boundary before the spec can be presented to the OASIS >>> membership for consideration as an OASIS specification? >>> >>> >>> <df>Fixed -- this means we will submit on April Fools >>> >>> >>Day >> >> >>> ;-) >>> We still don't have anything under the *This >>> Version* heading</df> >>> 2. Line 311: The reference to [ebREQ] cannot be found among >>> the Non-Normative References (see line 2761). >>> <df>Added Reference</df> >>> 3. LIne 896: The permissible values for >>> >>> >>duplicateElimination >> >> >>> in the CPA are perMessage, never, and always. Therefore, >>> replace "set to false" with "set to never" on line 897. >>> Note: this is with respect to the 1.1 CPP/A spec. Do we >>> need to add a reference to the forthcoming 1.1 CPP/A >>> >>> >>spec? >> >> >>> <df>done</df> >>> 4. Line 1384: The schema says that this is a REQUIRED >>> attribute. It must be set to the value >>> "http://schemas.xmlsoap.org/soap/actor/next >>> <http://schemas.xmlsoap.org/soap/actor/next>". It is >>> somewhat different from being declared as a FIXED >>> attribute in the schema. Line 1384 seems to suggest the >>> latter. Excerpts from the SOAP 1.1 spec: "The SOAP actor >>> global attribute can be used to indicate the recipient >>> >>> >>of >> >> >>> a header element. The value of the SOAP actor attribute >>> >>> >>is >> >> >>> a URI. The special URI >>> "http://schemas.xmlsoap.org/soap/actor/next" indicates >>> that the header element is intended for the very first >>> SOAP application that processes the message. This is >>> similar to the hop-by-hop scope model represented by the >>> Connection header field in HTTP. Omitting the SOAP actor >>> attribute indicates that the recipient is the ultimate >>> destination of the SOAP message. This attribute MUST >>> appear in the SOAP message instance in order to be >>> effective (see section 3 >>> <http://www.w3.org/TR/SOAP/#_Toc478383492> and 4.2.1 >>> <http://www.w3.org/TR/SOAP/#_Toc478383498>)." >>> <df>Changed "fixed" to "REQUIRED"</df> >>> 5. Line 1389: CPP/A attribute names start with a lower >>> >>> >>case. >> >> >>> SyncReplyMode should be globally repaced with >>> >>> >>syncReplyMode. >> >> >>> <df>done</df> >>> 6. Line 1412: I like to point out that a SyncReply element >>> >>> >>is >> >> >>> not compatible with an AckRequested element that is >>> targeted at the next MSH. >>> <df>No resolution yet.</df> >>> 7. Line 1491: I think an errorCode of Inconsistent should >>> >>> >>be >> >> >>> accompanied by a severity of Error rather than warning. >>> Didn't we decide that inconsistency between the CPA and >>> the message header must always result in an error being >>> returned? >>> <df>This might not be an inconsistency with the CPA >>> (perMessage). If we say this must be an Error then we >>> must also say the To Party MSH MUST NOT deliver to the >>> Application. IMO This needs to be a Warning.</df> >>> 8. 1502: The statement "An Error Message MUST NOT contain >>> >>> >>an >> >> >>> AckRequested element" is not correct and should be >>> >>> >>struck >> >> >>> out. Please see >>> >>> >>> >>http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00231.html >>(Resolution >> >> >>> of issues in the issues database), IssueId 73, and/or >>> >>> >>> >>http://lists.oasis-open.org/archives/ebxml-msg/200111/doc00004.doc, >> >> >>> Issue 73. >>> <df>We have gone back and forth on this several times. >>> >>> >>I >> >> >>> think the latest was to change to *no Ack on Error*. If >>> we go back to *no Error on Ack* then I need to go back >>> through the spec and make several changes. See >>> *[ebxml-msg] Ack on Error, or Error on Ack* thread >>> starting 12/10/01.</df> >>> 9. Line 1557: I think it is inconsistent to ask for a >>> >>> >>signed >> >> >>> Acknowledgment if the original message is not signed. >>> <df>Why? I agree it sounds strange but I can't think of >>> any reason it would be inconsistent. Someone might want >>> NRR but there is no reason to sign.</df> >>> 10. Line 1579: It will be useful to point out that >>> >>> >>parameters >> >> >>> that are not found in the message header are to be >>> obtained from the CPA. >>> <df>??? It already says this?</df> >>> 11. Line 1584: Replace "value of duplicateElimination in the >>> CPA is false" with "value of duplicateElimination in the >>> CPA is never". >>> <df>done</df> >>> 12. Line 1591: I think it may be problematical for the >>> recipient to do duplicate elimination when no >>> DuplicateElimination element is present. What happens if >>> SyncReply is present and AckRequested is not present. If >>> the incoming message is not passed on to the >>> >>> >>application, >> >> >>> should any reply be returned to the sender? >>> <df>Resolved between Arvola and Doug</df> >>> 13. Line 1602: It will be useful to point out that the >>> >>> >>Retries >> >> >>> parameter comes from the CPA. >>> <df>done</df> >>> 14. Line 1605: It will be useful to point out that the >>> RetryInterval parameter comes from the CPA. >>> <df> done </df> >>> 15. Line 1616: It will be useful to point out that the >>> PersistDuration parameter comes from the CPA. >>> <df> done </df> >>> 16. Line 1625: As mentioned earlier, SyncReplyMode should be >>> spelt as syncReplyMode. Also, I just noticed the >>> >>> >>following >> >> >>> statement in the 1.0 CPP/A spec. "If the delivery >>> >>> >>channel >> >> >>> identifies a transport protocol that has no synchronous >>> capabilities (such as SMTP) and the Characteristics >>> element has a syncReplyMode attribute with a value other >>> than "none", a response SHALL contain the same content >>> >>> >>as >> >> >>> if the transport protocol did support synchronous >>> responses." which contradicts the statement on line >>> >>> >>1625: >> >> >>> "The SyncReplyMode parameter from the CPA is used only >>> >>> >>if >> >> >>> the data communications protocol is synchronous (e.g. >>> >>> >>HTTP)." >> >> >>> <df> Resolved </df> >>> 17. Line 1646: The sentence is missing a closing period. >>> <df> done </df> >>> 18. Line 1678: This seems to contradict the statement on >>> >>> >>line >> >> >>> 1589. >>> <df> deleted </df> >>> 19. Line 1684: There is an invalid reference to section 0. >>> <df> deleted </df> >>> 20. Line 1733 and line 1738: These two bullet points assume >>> that syncReplyMode in the CPA is not used with an >>> asynchronous communication channel. This is in conflict >>> with the 1.0 CPP/A spec statement quoted in item 15 >>> >>> >>above. >> >> >>> I think this is a minor technical issue that may require >>> some discussion. >>> <df> Resolved </df> >>> 21. Line 1772: Since one MSH is not allowed to place more >>> >>> >>than >> >> >>> one AckRequested element in the SOAP Header (according >>> >>> >>to >> >> >>> line 1469), this matrix represents what an intermediary >>> MSH or the To Party MSH may receive, not what the From >>> Party MSH may send. >>> <df> Does this mean 1468/9 is wrong? It already says >>> *SHOULD* so maybe no change is needed.</df> >>> 22. Line 2098: I think the statement "The Receiving MSH MUST >>> NOT send an Acknowledgment Message until the message has >>> been delivered to the Next MSH" is not correct. This >>> >>> >>does >> >> >>> not correspond to store and forward behavior (see line >>> 2043). The Receiving MSH cannot know for sure that the >>> message has been delivered to the Next MSH until it >>> receives an Acknowledgment from the latter. The >>> >>> >>prescribed >> >> >>> behavior defeats the purpose of intermediate >>> >>> >>Acknowledgments. >> >> >>> <df> What would be more correct? Should it say *The >>> Receiving MSH MUST NOT send an Acknowledgment Message >>> until the message has been persisted?* Actually, I >>> >>> >>don't >> >> >>> see a problem as it is. What should I do? </df> >>> 23. Line 2619: This comment seems unnecessary. Would it >>> constitute an unrecognized MIME header? >>> <df> Yes, this is unnecessary. No this is not illegal. >>> Everything between the first blank line and the first >>> boundary is ignored. It is common for vendors to put >>> advertising info in this space -- identify the product >>> >>> >>or >> >> >>> vendor software producing this message. </df> >>> >>> Regards, >>> >>> -Arvola >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: "David Fischer" <david@drummondgroup.com >>> <mailto:david@drummondgroup.com>> >>> >>> To: "ebXML Msg" <ebxml-msg@lists.oasis-open.org >>> <mailto:ebxml-msg@lists.oasis-open.org>> >>> >>> Sent: Thursday, December 20, 2001 7:25 PM >>> >>> Subject: [ebxml-msg] Messaging Spec v1.092 >>> >>> >>> > This is the spec as it stands now. I think everyone's >>> comments are included >>> > (I'm mad at Doug for sending pages and pages of very good >>> comments AT THE LAST >>> > MINUTE ;-) >>> > >>> > Please get any last minute comments to me quickly. Please >>> >>> >>no >> >> >>> large changes at >>> > this point. >>> > >>> > Ian, I still need to resolve the copyright issue. Also, we >>> need to decide on >>> > the problem Sanjay described (I added the change as hidden >>> text if anyone wants >>> > to look at it). >>> > >>> > If anyone needs this in PDF, please let me know. >>> > >>> > Regards, >>> > >>> > David Fischer >>> > Drummond Group >>> > ebXML-MS Editor. >>> > >>> >>> >>> >> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC