[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: TRP Error Handling Spec Draft
Rik.
I agree spec finish first then in more detail. My vote is below.
David
>1. Transient Errors (lines 92 +)
>a) Should the ebXML Messaging service support the idea of Transient
>Errors?
> - Yes/No
Yes
> 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
Reliable Messaging
> c) Also if yes, which version of the spec do we include it:
> - Pre November / Post 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>
Yes
>
-----Original Message-----
From: rik drummond [mailto:rvd2@worldnet.att.net]
Sent: Monday, September 11, 2000 5:15 AM
Cc: ebXML Transport (E-mail)
Subject: RE: TRP Error Handling Spec Draft
spec finish first... then errors in greater detail... that is my vote....
best regards, rik
-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Sunday, September 10, 2000 6:40 AM
To: Burdett, David
Cc: ebXML Transport (E-mail)
Subject: Re: TRP Error Handling Spec Draft
Here's my vote.
"Burdett, David" wrote:
>
> 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
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
N/A
> c) Also if yes, which version of the spec do we include it:
> - Pre November / Post November
Regardless of the vote, it should IMHO be deferred to post Nov
version of which ever spec, although discussion may resume once
we have our november MS spec finished.
>
> 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>
Reporting errors (e.g. logging them) is most assuredly something we want
to handle. I'm not so sure that we want to send an error message reporting
an error in an error message.
>
> -----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 DT
D
> > 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
--
_/_/_/_/ _/ _/ _/ _/ 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