Re: TRP Error Handling Spec Draft

[Christopher Ferris <chris.ferris@east.sun.com>]

Marty/David,

See below.

Chris

David Burdett wrote:
> 
> I think it is best if it goes in the header, since not recognizing the TPA
> id might be the error you are trying to report ;)
> 
> David
> 
> -----Original Message-----
> From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
> Sent: Wednesday, August 30, 2000 8:04 AM
> To: David Burdett
> Cc: ebXML Transport (E-mail)
> Subject: RE: TRP Error Handling Spec Draft
> 
> David,
> 
> When I got down to the end of my comments, it occurred to me that if the
> specification defined the format and content of the error information but
> limited itself to saying that the information should be logged such that
> both parties could have access to it, that would be a good thing. I think I
> was more worried about how to fit the error messages into the protocol,
> where they should be directed to, etc., than about the contents of the
> messages.
> 
> ErrorLogLocn could go in the ebxml header, to define the location to which
> a message about an error detected by a recipient should be sent.
> Alternatively, it could go in the partner profile and TPA.  I guess in this
> case, the ebxml header makes more sense since it isn't an item that
> requires agreement.

This establishes a nice DoS attack potential which is why I firmly
believe that it IS something which you want to agree to in advance
between the parties.

> 
> Regards,
> Marty
> 
> ****************************************************************************
> *********
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> ****************************************************************************
> *********
> 
> David Burdett <david.burdett@commerceone.com> on 08/28/2000 05:27:23 PM
> 
> To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> cc:
> Subject:  RE: TRP Error Handling Spec Draft
> 
> Marty
> 
> We do want to keep it simple, however the S/390 environment where
> everything
> was under IBM's control is different from the ebXML envronment where the
> operating environment will by much more anarchical. So let's look at some
> of
> the issues ...
> 
> 1. Development by many different vendors - if a vendor is not told what
> errors his software is generating he won't fix them at all or not until
> much
> later.
> 2. Used by SME's and the mega-corporation - this means that we need a way
> for SME's to easily report their problems and get them fixed.
> 
> We actually thought about this when developing IOTP and one of the things
> we
> included was an "ErrorLogNetLocn" (see below) for an extract from the spec.
> The ideas was that you could specify a URL where errors found in the
> messages sent by a company could be sent to that company so that could fix
> them. In theory, this log location should only occur during testing as all
> software as we know is bug free in production ;)
> 
> David
> ==============
> Extract from IOTP spoec ...
> ErrorLogNetLocn     Optional. This contains the net location that Consumers
> should send IOTP Messages that contain Error Blocks with an Error Component
> with the Severity attribute set to either:
> o HardError,
> o Warning but the Consumer decides to not continue with the transaction
> o TransientError and the transaction has subsequently timed out.
> This attribute:
> o must not be present when TradingRole is set to Consumer role,
> o must be present when TradingRole is set to Merchant, PaymentHandler or
> DeliveryHandler.
> The content of this attribute is dependent on the Transport Mechanism see
> the Transport Mechanism Supplement.
> The ErrorLogNetLocn can be used to send error messages to the software
> company or some other Organisation responsible for fixing problems in the
> software which sent the incoming message. See section 7.21.1 Error
> Processing Guidelines for more details.
> 
> -----Original Message-----
> From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
> Sent: Sunday, August 27, 2000 3:40 PM
> To: David Burdett
> Cc: ebXML Transport (E-mail)
> Subject: Re: TRP Error Handling Spec Draft
> 
> This proposal is well thought-out and well described.
> 
> My concerns mainly relate to the KISS principle.  Is this a level of
> complexity and detail that is really needed?  An alternative at the far
> other end of the spectrum is to simply log everything and rely on
> out-of-band communications for the messaging service instance which
> received the message in error to notify the messaging service instance
> which sent it.
> 
> When I was working with the IBM Poughkeepsie architecture team on the S/390
> fiber optic channels, we accumulated a long list of errors which we wanted
> reported in a response message.  The I/O engineers then informed us that
> they were not going to analyze all this information.  Rather, they would
> log the error condition and take the most drastic recovery action (called
> connection recovery) whatever the error condition.  The recovery action is
> simply to terminate the logical and physical connections between the
> channel and I/O device and let software retry. The principle they were
> operating on was KISS.  They said that ecovery function is the most
> difficult to test and debug.
> 
> 2.1.2 Types of errors
> 
> Line 21 (2nd bullet, 3rd subbullet):  Please add "of a previously sent
> message" to the end of the line.
> 
> Following line 21:  What about a category of "an error in a document which
> is reporting an error"?
> 
> 2.1.3 When to Generate Error Messages
> 
> Line 30 (1st para.):   Please change "message in error" to "received
> message".
> 
> Line 30 (1st para.):  Please change "a URL to send the message" to "an
> address to send the message".  If the communication protocol is other than
> HTTP, the address won't be a URL.
> 
> NOTE:  The IBM tpaML proposal covers only retries of transport timeout
> errors and business-level errors.  Business-level errors are reported to
> the sending application using <ExceptionResponse> and a corresponding
> action at the other partner which receives the exception response.
> 
> NOTE:  It is not clear where the errors covered in the error-handling
> proposal should be reported to.  They are conditions presumably caused by
> the sending message service instance and detected by the receiving message
> service instance.  We will need to define some kind of "catcher" for the
> error messages and define what the catcher is supposed to do.
> 
> 2.2 .1 Communication Protocol Errors
> 
> Line 55 (Editor's note): The KISS principle applies here.  I suggest
> retrying communication-level errors at the communication level and
> reporting all unrecoverable conditions to one place rather than defining a
> unique recovery for each communication-level error.  Aside from simplifying
> the implementation, it will avoid the need to track the other standards for
> additional error codes.  I speculate that the function to which these
> conditions are reported will simply log them and process all of them the
> same way.
> 
> 2.2.2.1  Identifying the Error Reporting Location
> 
> 1st paragraph, line 63:  Please change "a URL" to "a communication
> address".  The communication protocol will not necessarily be HTTP.
> 
> Line 65, by reference:  The TPAId is always in the ebXML message header
> 
> Line 66, by value:  Please replace "the URL" by "the communication
> address".
> 
> Line 66, by value:  A header error will make the value of such a tag
> untrustworthy.  I suggest that we limit ourselves to "by reference" and
> "implicitly".
> 
> Line 74-76 ("Even if the message in error..."): Determining the error
> reporting location is not a problem with either "by reference" or
> "implicitly".
> 
> 2.2.2.2  Error Reporting Location is Identified
> 
> Line 80-82 (Editor note): For communication errors, replacing an
> acknowledgment message by an error message is OK (example:  HTTP). If the
> message is sent at the messaging service level, it is not clear where the
> error message should go.  Possibilities are:
> 
>    All the way to the application (e.g. the exception response message in
>    tpaML).
>    Some messaging service management function that we haven't yet
>    considered.  I believe that this is the preferable approach for errors
>    in the header and envelope.
> 
> 2.2.2.3  Error Reporting Location not Identified
> 
> Line 84-86 (1st para.):  This is reporting the error at the transport
> level.
> 
> Line 87, editor's note:  Specifying rules to apply to each transport
> requires defining the layer of function that invokes the transport
> protocol.
> 
> Lines 90-91 (If a suitable return address is not identified):  This is my
> preferred approach for error processing in general.  If we define a
> messaging service management function, then the error information could be
> sent to the management function at the sender and logged there, as well as
> being logged at the recipient messaging service management function.
> 
> 2.2.3 Transient Errors
> 
> Line 92 (title):  Please change the title to "Recoverable Errors"  and use
> the term "Recoverable"  instead of "transient" throughout.  "Recoverable"
> means that retry is recommended.  "Transient" means that the error did not
> recur, which can only be known after the retry succeeds.
> 
> Lines 105-106 ("If the ebXML messaging Services is unable to respond..."):
> If the messaging service is unable to respond within the timeout period, it
> is probably unable to send the message which says it is unable to respond.
> 
> Line 107 (determining the timeout period):  The TPA is one place to specify
> the timeouts.
> 
> 2.3.2  ebXML Error Document
> 
> Lines 136-137 (Editor's note, list item 2): Since correcting the errors
> will require human intervention, logging the error condition should be
> sufficient.  As noted above, the sender needs to be notified of the error
> condition.  This notification could be outside the scope of the
> specification.  Alternatively, the error message structure defined here
> could be used for that purpose as long as it is sent to a management
> function at the sender and does not require executing a protocol to
> evaluate the error message as part of the exchange of messages between the
> parties.
> 
> Line 139-40 (list item 4):  I completely agree.
> 
> 2.3.5 ebXML Error Document Type Definition
> 
> Lines 256-258 (Editor's note): Standard practice that I am familiar with is
> to terminate the operation on the first error detected and report only that
> error.
> 
> 2.4.2  Non-XML Document ERrors
> 
> Lines 330 (MsgTooLarge), 332 (MIMEError), 333 (MimePartMiss), and 336
> (MimePartUnx):  These conditions appear to be application-level errors.
> These could be reported directly to the sending application using a
> mechanism like <ExceptionResponse> as defined in the tpaML proposal.
> 
> Regards,
> Marty
> ****************************************************************************
> 
> *********
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> ****************************************************************************
> 
> *********
> 
> David Burdett <david.burdett@commerceone.com> on 08/18/2000 08:17:19 PM
> 
> To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> cc:
> Subject:  TRP Error Handling Spec Draft
> 
> Folks
> 
> I attach some light reading for the weekend. Alternatively called, the TRP
> Error Handling draft spec version 01 ;)
> 
> David
>  <<ebXML TRP Error Handling draft 01.doc>>  <<ebXML TRP Error Handling
> draft
> 01.pdf>>
> 
> Product Management, CommerceOne
> 4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
> Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903