[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: TRP Error Handling Spec Draft
Chris
Rather than continue the debate, I've tried to call out the main
issues/questions so that we can decide was a group what to do. Rik/Chris can
we have a vote on these as I think there has been enough discussion?
1. Transient Errors (lines 92 +)
a) Should the ebXML Messaging service support the idea of Transient Errors?
- Yes/No
b) If yes, should it be in the Error Handling part of the spec or in the
Reliable Messaging part of the spec?
- Error Handling/Reliable Messaging
c) Also if yes, which version of the spec do we include it:
- Pre November / Post November
2. Reporting Errors in Error Messages (lines 29+)
a) Should we report on errors found in error messages yes/no (see also
comment below marked with<db>
-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Wednesday, September 06, 2000 8:58 AM
To: Burdett, David
Cc: ebXML Transport (E-mail)
Subject: Re: TRP Error Handling Spec Draft
David,
My comments embedded below.
Cheers,
Chris
"Burdett, David" wrote:
>
> 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.<<<
It would seem to me that this is implementation specific (the interface
between the MS layer and the CPA. I could see a standardized interface
if there were a desire on the part of vendors to provide standardized
CPAs which could plug into any MS, but my belief is that each vendor
will roll their own.
<db>I agree. But this part of the spec is just enumerating the different
types of errors that can exist and not how to handle them. Do you agree that
enumerating all these errors here in the context that they are ones that the
ebXML Messaging Service as a whole has to handle is correct?</db>
>
> 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?<<<
It should be discussed in that light, yes. However, again, I think that
this complicates things considerably and blurs the distinction between
the MS and BP layers.
>
> 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?<<<
I'd simply leave it out.
<db>OK</db>
>
> 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".
I'd agree to #1, but #2 would seem overly redundant of #1 since they are
one and the same at the MS level.
<db>I don't think 2 is redundant. If you remove two and some software
generates an error message with an error in its structure then there is no
way to report the error back to the sender of the message. I still think it
should stay.</db>
>
> 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?
> <<<
Somewhat. I think we're roughly on the same page here.
>
> 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 ;)<<<
I think that we can do this as a team when we get past the editing and
publishing of the current rev of the MS spec.
<db>Sounds fine to me</db>
>
> 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?<<
You point out that most errors will be encountered in the development
of an MS/exchange and that once all of the kinks have been ironed out
that they will be quite rare. If my production system is running smoothly
and then all of a sudden cannot process messages, something is terribly
wrong
and some grey matter needs to be applied.
<db>Correct me if I'm wrong but I think you're suggesting that if you find
an error in an error message then you should stop your system. Is that
correct? If I am, then all I need to do to shut down your system is to send
you an error message that has an error in it, e.g an invalid error code. I
don't think this is robust behavior for any system.</db>
>
> 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.<<<
See my response to your other mail on the subject. DigSigs are basically
only useful as tools to ascertain the level of trust accorded to a party.
>
> 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.<<<
Agreed.
>
> 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.
If the service is down, how is the message reported?!?!?!?
<db>By running a very simple ebXML messaging service system that just sends
transient errors until the main system is back up running.</db>
> 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.
I wouldn't want to advertise to my partners that I haven't got 7x24 service.
I would just as soon harden the messages and process them later without
letting on that there might be a delay.
<db>If I claimed I was running a 7x24 service then neither would I. But not
everyone will want to run a 7x24 service. IN this case a "vacation message"
is useful.</db>
>
> 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.<<<
IMHO, this is BP specific end of the grey area spectrum;-)
>
> 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.<<<
Sure they have.
<db>This is beyond my understanding of American English. Does this mean CC
have defined an error document? yes or no?</db>
>
> 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?<<<
This then belongs in the tpa.
<db>... or the header ...</db>
>
> 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.
> <<<
I don't think that I'd advertise my logs and post them where anyone
can see them. There might be sensitive information in them! If A reports
an error to B of the nature of an invalid document and A does not
experience the same error, then the two sit down together and scratch
their respective heads to work out the problem. I don't think that
A is going to open up its proprietary software for scrutiny by an
outsider.
<db>I'm not suggesting that. It just means that if a software vendor sees an
ebXML error record then he will be able to determine exactly which bit of
the code generated it and thats all.</db>
>
> 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.<<<
a validating schema parser then. In my mind, they are the same sort of
beast. You don't parse a document against a DTD AND a schema.
<db>I agree but one implementation might validate using a DTD and another a
schema. We need an error code scheme that can work equally well with
both.</db>
>
> 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.<<<
see above, a schema validating parser would catch this.
>
>
>
>
> 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
--
_/_/_/_/ _/ _/ _/ _/ 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC