[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 Success Codes
I agree also. Using the Unix slogan for this behavior, "A system for grown ups". Scott Hinkelman, Senior Software Engineer XML Industry Enablement IBM e-business Standards Strategy 512-823-8097 (TL 793-8097) (Cell: 512-940-0519) srh@us.ibm.com, Fax: 512-838-1074 "Burdett, David" <david.burdett@commerceone.com> on 07/30/2001 12:13:54 PM To: "'christopher ferris'" <chris.ferris@east.sun.com>, David Fischer <david@drummondgroup.com> cc: ebXML Msg <ebxml-msg@lists.oasis-open.org> Subject: RE: T2 Success Codes I agree with Chris. The fact that a message was returned with no errors, indicates that the original message was received, validated - as far as the MSH can - and no problems were found. David -----Original Message----- From: christopher ferris [mailto:chris.ferris@east.sun.com] Sent: Monday, July 30, 2001 8:32 AM To: David Fischer Cc: Burdett, David; ebXML Msg Subject: Re: T2 Success Codes This isn't a clear requiremnent (to communicate the nature of successes). The fact that a message is acknowledged means something specific for purposes of effecting reliable messaging, not application or any other manner of MSH functionality successes. Cheers, Chris David Fischer wrote: > > That's intesting because IMO such things as signature verification are MSH > level. In fact we have error codes indicating security failures thus we should > have success codes indicating security success. I very much agree that there > are many successes which will be application level. > > Regards, > > David Fischer > Drummond Group. > > -----Original Message----- > From: christopher ferris [mailto:chris.ferris@east.sun.com] > Sent: Monday, July 30, 2001 6:34 AM > To: David Fischer > Cc: David Burdett; ebXML Msg > Subject: Re: T2 Success Codes > > David, > > We did not define success codes. If anything, these would be > application level codes, not MSH-level codes. > > Now, in the BPSS specification, there are a number of message > patterns defined, which have specific messages/signals associated > with these message patterns. These aren't defined *intentionally* > by the MS specification. These are defined by the BP specification > because they aren't necessary to the core processing of the MSH. > > Cheers, > > Chris > > > David Fischer wrote: > > > > I don't see any Success Codes or a place to put them. There should be a way > to put different > > success codes in both the Acknowledgement and the DeliveryReceipt elements. > There may be several > > different kinds of success like Processed/PassedOn or Processed/Dispatched or > > Processed/SignatureVerified or Processed/DecryptSuccess or.... These could be > the value of the > > element or they could be in a sub-element. > > > > It is probably not sufficient to just get an Acknowledgement back without the > granularity of > > different success codes. I don't want to have to create an entirely separate > bodypart just to put > > in a success code? > > > > Regards, > > > > David Fischer > > Drummond Group. ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC