Re: TRP Error Handling Spec Draft

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

David,

Some comments on the error handling draft.

Cheers,

Chris

line 15 -
The MS does need to handle communication protocol
specific errors obliquely. By that, I mean that the
MS hands off the message to a protocol adaptor which
handles the error *directly* and then possibly reports
an error back to the MS. It would seem to me that the
MS itself should have a consistent set of errors
which a CPA (communication protocol adaptor) would
report back after receiving a protocol specific error
of some sort (e.g. UndeliverableError, DeliveryFailedError, etc.)

line 22 -
I'm not sure that I follow. Is this an internal error of some
sort? If so, isn't this out of scope as implementation specific
detail?

line 25 - 
This isn't an error, it is an alarm, is it not? Also, it would
seem to me to be implementation specific as to how it were handled
within the RM aspect of the MS.

line 30 -
This would be in the TPA, would it not?
Also, I think that the wording needs to be made more clear.
Something like:
	When a MS detects an error in the structure or composition of the
	MIME envelope/package or in the parsing or processing of the ebXMLHeader
	document of a received ebXML Message, an ebXML Error Message must
	be generated and delivered to the Party which sent the Message in error.

lines 51 - 55
I think that we need not go there (enumerating all possible communication
protocol errors for all protocols!). Rather, I think that we should take
a more "generic" approach and identify the generic errors which would
need to be handled to which a CPA implementer should map the protocol
specific error conditions. For example:
	Undeliverable (host unresolvable, connection refused, etc.)
	Unauthorized (self explanitory)
	IOError (socket disconnected, etc.)
Trying to map each and every possible error condition of each of the
commonly discussed protocols is beyond our scope. We need to leave
something for the implementers to do;-)

lines 57-59
reporting errors on errors seems a bit much. If an ebXML MS Error cannot
be processed, something is really wrong somewhere. This sounds like a
case where you dump out the message to a log, shut the service down and 
start scratching your head to figure out what's wrong. I'm not convinced
that there is merit in reporting an error on an ebXML Error message. It only
leads to complicated and circular logic right out of Dr. Suess.

line 66
I don't think that we need to include the errorURL in the header if
it is in the TPA (which it is in the current draft) This opens up the
DoS attack scenario I raised in Brussels where I direct all of the errors
reported on MY messages to YOU and send messages to everyone on the
planet... You wouldn't like that;-)

lines 80-82
It would seem to me that an error reported on a message which requires
RM could be treated as an acknowledgment from the perspective of
the RM sub-system depending upon the nature of the error. In some
cases, a retry might resolve the problem (say if all the bits didn't
make it across or something) whereas in other cases, a retry would be
inadvisable because the message was malformed or incomplete in which 
case RM should treat the message as having been delivered and the error
reported (logged or escalated or both).

line 92 section 2.2.3
this seems to me to be a business process specific message. I can see
the merits (kind of like a vacation message) but it seems that this
is something which the business process needs to know how to handle
and thus must be explicitly called for in the BPM...

lines 120-122
I think that the error message needs to be defined in terms of CC.
I imagine that there is some "base class" of error message format
which could be extended according to the context with attributes/elements
pertinent to the business "application", etc.

lines 172-175
My discomfort with this concept is increasing!

lines 179-187
This seems more appropriate for the system log than for the
error message. What is the recipient of the error supposed to
do with this information? In short, it seems unnecessary.

lines 311-313
If an XML document is parsed with a validating parser, then this
error seems superfluous/redundant as the validating parser will
find the document invalid. (e.g. if the ebXMLHeader is parsed
with a validating parser against the ebXMLHeader DTD or Schema)

lines 308-310
I think that the same comment applies. If an element is missing, then
the document is invalid (but may be well formed).

















	
	




David Burdett wrote:
> 
> 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
> 
>   ----------------------------------------------------------------------------------------------------
>                                             Name: ebXML TRP Error Handling draft 01.doc
>    ebXML TRP Error Handling draft 01.doc    Type: Microsoft Word Document (application/msword)
>                                         Encoding: base64
> 
>                                             Name: ebXML TRP Error Handling draft 01.pdf
>    ebXML TRP Error Handling draft 01.pdf    Type: Acrobat (application/pdf)
>                                         Encoding: base64

-- 
    _/_/_/_/ _/    _/ _/    _/ 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