[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?!?!?!?
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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