[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
Hey, I don't mind answering a rhetorical question :-) Please see below. ----- Original Message ----- From: "David Fischer" <david@drummondgroup.com> To: "Christopher Ferris" <chris.ferris@sun.com> Cc: "CPPA" <ebxml-cppa@lists.oasis-open.org> Sent: Monday, October 22, 2001 11:59 AM Subject: RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001 > OK Chris, ebXML-MS v1.0 section 6 (see also ebXML Requirements sec 7.6). The > functions defined for MS are: Header Processing, Header Parsing, Security, RM, > Packaging, Error. . . > > The name of the group is Transport Routing and Packaging. Since Signatures have > to be applied after Packaging then Signatures MUST be a function of the MSH. > Since we are performing Packaging, we also must be performing UnPackaging. > There is nothing preventing the Application from seeing the all the headers but > that is not our model. If the MSH is doing the Header Processing/Parsing, why > would the headers be passed to the Application (rhetorical question). > > It is the function of the MSH to perform NRR. If the Application wants to > duplicate that functionality, I guess it conceivably could, but why (another > rhetorical question). TW: Because, I believe, business people will care about business documents exchanged by business applications. Messages exchanged by MSH implementations are technical details. I imagine that lawyers (Jamie?) might agree to accountability as soon as message receipt is confirmed by the receiving party's MSH, but that alone doesn't meet the business need. > Regards, > > David. > > -----Original Message----- > From: Christopher Ferris [mailto:chris.ferris@sun.com] > Sent: Monday, October 22, 2001 8:20 AM > To: David Fischer > Cc: CPPA > Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001 > > > David, > > Please see my comments below. > > Cheers, > > Chris > > David Fischer wrote: > > > Sorry I missed the meeting, it didn't make it onto my calendar. > > > > > > > > Comments: > > > > > > > > If end-to-end, signed Acknowledgment is requested, it provides NRR -- in > > the same way DeliveryReceipt does. NRR cannot be provided at the > > BPSS/Application level since MSH does not pass the entire message and > > thus the Application cannot generate the required Digest(s). > > > Says who? Nothing in the specification prevents the entire unadulterated > message from being passed to the "application". The "application" can > most certainly do NRR. Please keep in mind that many believe that ONLY > the "application" can do NRR. > > > > > > > > > > Since the MSH does not do any application parsing, any Business Level > > receipts cannot be done at the MSH level. While the Application cannot > > do NRR, it can/must provide anything along the lines of "Message > > verified/being processed" (i.e. Delivery Receipt). The Application > > would pass this signal to the MSH with a flag which says "sign this". > > While it would not be illegal for the Application to send a > > signed/encrypted payload to the MSH (would this be S/MIME?), it is not > > within our model to do so. > > > There's nothing in the spec that says that MSH functionality (and I > don't necessarily consider signing to be a function of an MSH mind you) > cannot be made available to higher levels of software. > > > > > > > > > > An Acknowledgment can be requested separately from Reliable Messaging > > although the only difference is duplicateElimination. > > > > > > > > I thing/agree that MSH signals should be returned synchronously for > > HTTP. This should be the default. Maybe we don't need a flag, just > > make this a requirement (Why would this ever be done asynchronously for > > HTTP?) I think I agree with Dale. This should match the transport > > method (sync for HTTP, async for SMTP) and should not change per message. > > > I agree that the MSH "signals" should be returned synchronously > on the HTTP response in the HTTP binding. > > > > > > > > > > Regards, > > > > > > > > David Fischer > > > > Drummond Group. > > > > > > > > -----Original Message----- > > From: Tony Weida [mailto:rweida@hotmail.com] > > Sent: Saturday, October 20, 2001 5:05 PM > > To: CPPA > > Subject: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001 > > > > Draft minutes of the October 18 teleconference are attached. Please > > send me any additions or corrections. > > > > > > > > Cheers, > > > > Tony Weida > > > > Independent CPPA Fan :-) > > > > > > > ---------------------------------------------------------------- > 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