RE: TRP Error Handling Spec Draft

["Burdett, David" <david.burdett@commerceone.com>]

Responses in line marked with >>>

David

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Thursday, August 31, 2000 4:15 PM
To: David Burdett
Cc: ebXML Transport (E-mail)
Subject: Re: TRP Error Handling Spec Draft


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.)
>>>I agree, although what you describe is all part of the Service Interfaces
between the various components of the ebXML Messaging Service. What this
point is trying to suggest is that, if a communication error occurred, but
the message was still readable sufficiently so that you knew where to send
an error message, then you should send them an error message. Alternatively
do you think that communication protocol errors should not be reported. I'd
appreciate your views.<<<

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?
>>>In a sense yes. However reporting transient errors does is useful from a
reliable messaging perspective as described later. I also think that this
type of thing should probably be in the reliable messaging spec. It's just
that in IOTP, it was in the error handling spec. Where do you think this
should go? Do you think it should be included as part of reliable
messaging?<<<

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.
>>>It's included for completeness but then the spec immediately identifies
that it is out of scope of this section. Is that OK?<<<

line 30 -
This would be in the TPA, would it not?
>>>It could, but then I think it would introduce something to negotiate that
you don't need to. I therefore think it should be in the specification.<<<

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.
>>>
This is simpler, I agree, but it can lead into an infinite loop in that if
there is an error in a "message reporting an error" then, according to your
rule, it should result in another error message being generated. However
this could also be in error in which case you could loop. What the text is
trying to describe is a way of breaking this loop. I've clarified the text
to read ...
##When an ebXML messaging service 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
unless the following conditions are true:
1. the message in error has a Message Type of Error, and
2. the message in error is reporting an error in another "message that is
reporting an error".

The purpose of these last two conditions is to avoid a potential infinite
looping where there are errors in the ebXML Error Message.##

Is this clearer?
<<<

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;-)
>>> Chris. You are absolutely right !! Can you help with a prescriptive
complete list of the generic error conditions that we need ;)<<<

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.
>>>You're right it's complex. On the other hand, shutting down the service,
if you are in production mode, is not something you should normally do
because you had an error. It could also provide another DoS attack. I've put
in some clarification earlier. Is this now OK?<<

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;-)
>>>You bet I woudln't !! However there is a worse denial of service attack
that you could do which you can't avoid without digital signatures - see my
other email. I also think that the error URL could go in the TPA or the
partner profile that could be included in the message header. However this
is later work.<<<

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).
>>>I agree. I think though that this needs to be included in the reliable
messaging spec.<<<

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...
>>>There are a couple of issues here:
1. You may want to bring down the ebXML Messaging Service, e.g. for backups
or for upgrades to software. At this time you don't want people to send you
messages that you can't respond to. You therefore need this for the ebXML
Messaging Service layer.
2. You also need "vacation messages" for each business process. In this
case, you can use the same mechanism it's just that the business service
specifies when it should be sent.

Either way I think it is worth while having in the TRP spec, although it is
in the "grey area" between messaging and business process.<<<

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.
>>>Xpath allows you to point to anywhere in a document. Since the ebXML
header and an XML "business document" are both basically XML documents, we
should be able to use the same mechanism for reporting errors in both. The
down side of this is that we are making a dependency on what TRP is doing
with CC. My understanding is that Core Components hasn't quite got round to
thinking about this yet.<<<

lines 172-175
My discomfort with this concept is increasing!
>>> I think that if we want to report Transient erors then probably
"MinRetrySecs" should be held elsewhere in the header or another document
that is covered by the RM spec. Is this where you are heading?<<<

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.
>>>
An error can be generated because:
1. There is an error in a document.
2. The software checking a document is in error and reporting a problem when
there isn't one.

Putting this information in the message addresses the second class of
problem. If the information is kept in the log of the sender, the company
that is running the software that has the problem, won't know what exactly
is causing the problem. It is also quite easy to add these things in if it
is done at design time, but much harder later. We also can't specify in our
spec that this information should be logged. I suggest no change.
<<<

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)
>>>The problem is that you could have a document that conforms to the DTD
but not to the Schema. If you are checking the document against only a DTD
then you would need to do the other checks using the ebXML Messaging
software. A classic example of this is a URL which in a DTD is just a string
but in a schema has a structue that can be validated.Another example would
be numeric values that are also just strings in a DTD. Suggest no change.<<<

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).
>>>Not necessarily since you could have an optional element (in a DTD/Schema
sense) but must be present because of the presence of some other element. I
don't think we will be able to completely avoid this type of
cross-checking.<<<
















	
	




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