[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 Success Codes
Chris makes an argument against not putting success codes in the
Acknowledgement. I will be happy if we only put success codes in
DeliveryReceipt. I understand the objection to Acknowledgement.
As for Scott's "A system for grownups"? HTTP has 7 different success codes.
Does that mean it is not a system for grownups?
David.
-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Monday, July 30, 2001 3:31 PM
To: Burdett, David
Cc: 'christopher ferris'; David Fischer; ebXML Msg
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