Subject: RE: Error Handling

From: [email-masked]
Date: Tue, 6 Jul 1999 17:40:43 +0100

Masaaki

Now I see my mistake. I've changed the relevent text in Server Logic as
you've suggested.

David

> ----------
> From: 	Masaaki Hiroya[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	27 June 1999 10:56
> To: 	[email-masked]; [email-masked]
> Subject: 	RE: Error Handling 
> 
> 
> David
> 
> At 03:04 99/6/26 +0100, [email-masked] wrote:
> > Masaaki
> > 
> > There was one question I didn't answer earlier so here it is now.
> > 
> > Your question was:
> > 
> > 	" (1) According to IOTP v1.0-03, ProcessState="ProcessError" for
> > technical errors and ProcessState="Failed" for business errors, but in
> the
> > example logic ProcessState="Failed" and CompletionCode="ProcessError"
> for
> > technical errors.  Which is correct?"
> > 
> > Currently the spec says:
> > 
> > 	*	"ProcessError. This value is only used when the Status
> > Component is being used in connection with an Inquiry Request Trading
> Block
> > (see section 8.12). It indicates there was a Technical Error (see
> section
> > 4.1) in the Request Block which is being processed or some internal
> > processing error."
> > 
		> Process Errors are *only* used in a Status Component
inside a Inquiry
> > Response Block. It indicates that the transaction being inquired upon
> had
> > resulted in an Error Block being generated either by the Consumer or the
> > IOTP server roles. You can't send the Original Error Block back as it
> would
> > indicate that there was an error in the Inquiry Request Block when in
> fact
> > it was OK.
> > 
> > Hope this helps.
> > 
> > David
> 
> I think my question wasn't appropriated, and I should have asked you more
> specifically.
> 
> I think the above sentences in the current spec. say that a Status
> Component 
> with ProcessState="ProcessError" should be generated when the transaction 
> being inquired upon had resulted in an Error Block being generated either 
> by the Consumer or the IOTP server roles.
> 
> However, the following sentences in the ProcessInquiryRequestBlock of the
> "ServerLogic.txt" you sent before say that a Status Component with 
> ProcessState="Failed" and CompletionCode="ProcessError"should be generated
> 
> when the same cases as above occur.
> 
> ----- beginning of quote -----
> ProcessInquiryRequestBlock
> ==========================
> /* This responds to an Inquiry from another party on the current state of
> a Document Exchange. */
> If the Inquiry Refers to a Ping Transaction then
>       .......
>       .......
>   If Inquiry is OK, then
>     Retrieve Status information for original Document Exchange
>       If original Document Exchange had technical errors then
>         Generate Status component with 
>           ProcessState of Failed and CompletionCode of ProcessError
>           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         Generate an ErrorBlock describing the errors in the original
> Document Exchange
>         Include generated Status Component in Inquiry Response block
>         Save Inquiry Response Block and Error Block for inclusion in
> output message
> ----- end of quote -----
> 
> This is why I asked the question.
> I think the answer is that the former one (ProcessState="ProcessError") is
> correct
> according to your reply.
> 
> Regards
> Masaaki
> 
> 
> 
> > 
> > > ----------
> > > From: 	[email-masked][SMTP:[email-masked]]
> > > Sent: 	20 June 1999 21:29
> > > To: 	[email-masked]; [email-masked]
> > > Subject: 	RE: Error Handling 
> > > 
> > > Masaaki
> > > 
> > >  I don't have time to look into all your questions right now but there
> are
> > > some answers below ...
> > > 
> > > David
> > > 
> > > > ----------
> > > > From: 	Masaaki Hiroya[SMTP:[email-masked]]
> > > > Reply To: 	[email-masked]
> > > > Sent: 	19 June 1999 19:28
> > > > To: 	[email-masked]; [email-masked]
> > > > Subject: 	RE: Error Handling 
> > > > 
> > > > 
> > > > David,
> > > > 
> > > > The example logic for the processing required at an IOTP server and
> > > > the new specification derived from it are really helpful to design
> > > > IOTP servers.
> > > > 
> > > > I have several questions about it.
> > > > 
> > > > (1)
> > > > According to IOTP v1.0-03, ProcessState="ProcessError" for technical
> > > > errors
> > > > and ProcessState="Failed" for business errors, but in the example
> logic
> > > > ProcessState="Failed" and CompletionCode="ProcessError" for
> technical
> > > > errors.  Which is correct?
> > > ## Not sure. Will check ##
> > > 
> > > > (2)
> > > > It is not explicitly described in the following sentences that the 
> > > > Payment Handler can accept a new PayReq message when transient
> > > > a business error occurs after receiving PayExch messages, 
> > > > but the following sentences indicate that it can accept 
> > > > the new PayReq message in such a case, don't they?
> > > > 
> > > > >   . Payment Request Block (Payment Handler only). Check as
> follows:
> > > > >     - if the Payment  Request Block refers  to an IOTP
> Transaction
> > > > >       that is not recognised then its OK, otherwise
> > > > >     - if the Payment Request Block refers to IOTP Transaction
> that
> > > > >       was not for a Payment then it is a Hard Error, otherwise
> > > > >     - if the  previous payment CompletedOk  OR failed  with a
> non-
> > > > >       recoverable  Completion  Code  then  it  is  a  Hard
> Error,
> > > > >       otherwise
> > > > >     - if the  previous payment is  still in progress  then it is
> a
> > > > >       Hard Error
> > > ## The Payment Handler should be able to accept a new PayReq message
> after
> > > either:
> > > *	a transient error (i.e. the Payment Handler was too busy to process
> > > the first PayReq, or
> > > *	after a "recoverable" business error. Some Completion Codes are
> > > recoverable some are not see my earlier email with revised completion
> > > codes##
> > > 
> > > > (3)
> > > > Will it be described in the client role processing which message
> > > > the client should send to the server depending on the completion
> code
> > > > when business errors occur?
> > > ## Not completely as it is dependent on the problem and what the
> options
> > > are. For example, if a Mondex Card doesn't have sufficient value then
> the
> > > options available to the Consumer include (there may be more):
> > > *	using a different card - this means you just send a new Payment
> > > Request
> > > *	loading the card with more value and then trying again - this would
> > > also need a new Payment Request
> > > *	using a different brand - this would involve a brand selection -
> > > currently this only possible if the payment is brand independent. 
> > > 
> > > Similarly if an authentication fails then the consumer can just
> re-enter a
> > > new password, for example, or use a different authentication method.##
> > > 
> > > > (4)
> > > > Are there any cases that IOTP servers receive transient errors
> > > > from IOTP clients?
> > > > As far as I think, there are no such cases, but I want to confirm it
> > > > since I couldn't find sentences which describe it explicitly.
> > > > 
> > > > If there are such cases, how do the IOTP servers behave?
> > > ## Yes, as the Consumer role might be implemented on a server which
> might
> > > be
> > > busy. In this case, the behavious will be exactly the same as for the
> > > consumer, i.e. you wait for the required time then you send the *same*
> > > message again. I've been working on the Consumer logic - nearly
> finished -
> > > and this highlighted the need. I'll be sending out an updated
> > > "serverlogic.txt" file when I send out the Consumer Logic one which
> should
> > > (I hope) be this week, although this week is very busy for me. ##
> > > 
> > > > Thank you in advance
> > > > Masaaki
> > > > 
> > > > 
> > > > At 04:10 99/6/15 +0100, David Burdett wrote:
> > > > > 
> > > > > Apologies for the delays folks but this took longer than
> anticipated.
> > > > > Particularly I found I could only really get my mind round how to
> > > handle
> > > > > idempotency by going down a level of detail and start thinking
> about
> > > the
> > > > > logic required at a server. Anyway the result is in the attached
> two
> > > > files
> > > > > which describe:
> > > > > - example logic for the procecssing required at an IOTP server
> (i.e. a
> > > > > merchant, a payment handler or a delivery handler), and
> > > > > - a replacement set of text for the IOTP specification which was
> > > > actually
> > > > > derived from the logic, but is at a higher level.
> > > > > 
> > > > > 
> > > > > I haven't started the consumer logic yet, but I think that having
> done
> > > > the
> > > > > IOTP server, it should be easier.
> > > > > 
> > > > > 
> > > > > I *really* would like peoples views on whether or not the level of
> > > > detail
> > > > > provided in the example logic is useful and if the Server Role
> > > > Processing
> > > > > description is an improvement. Also please note that it has not
> yet
> > > been
> > > > > reviewed by *anyone* so no doubt you'll find bugs ;) . Anyway I've
> > > tried
> > > > to
> > > > > make the logic reasonably complete, so please let me know what you
> > > > think.
> > > > > 
> > > > > 
> > > > > David
> > > > >  <<ServerLogic.txt>>  <<Server Role Procecssing.txt>> 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > -----
> > > > Masaaki Hiroya
> > > > Systems Development Laboratory
> > > > Hitachi, Ltd.
> > > > tel: +81-44-549-1531
> > > > fax: +81-44-549-1640
> > > > email: [email-masked]
> > > >
> -----------------------------------------------------------------------
> > > > Message addressed to: [email-masked]
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > > body to: [email-masked]
> > > > 
> > > 
> > >
> **************************************************************************
> > > ********************
> > > 
> > > This Email and any attached files are confidential and may also be
> > > privileged. 
> > > If you are not the intended recipient, please notify the postmaster
> using
> > > email 
> > > address [email-masked] or call +44 171 557 5000 and ask for the
> 
> > > IT Helpdesk.  You should not copy this email and any attached files,
> use
> > > them 
> > > for any purpose or disclose the contents to any other person; all
> copies
> > > of the 
> > > Email and associated files in your possession should be destroyed.
> > > 
> > > Mondex International Limited
> > > 47-53 Cannon Street
> > > London EC4M 5SQ
> > > United Kingdom
> > > Registered No: 3122085, England
> > > 
> > > Phone:          +44 171 557 5000
> > > Fax:            +44 171 557 5200
> > > Email:          [email-masked]
> > > WebSite:        http://www.mondexinternational.com
> > > 
> > >
> **************************************************************************
> > > *******************
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > > 
> > 
> >
> **************************************************************************
> **
> > ******************
> > 
> > This Email and any attached files are confidential and may also be 
> > privileged. 
> > If you are not the intended recipient, please notify the postmaster
> using email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> > for any purpose or disclose the contents to any other person; all copies
> of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> >
> **************************************************************************
> **
> > *****************
> > 
> 
> -----
> Masaaki Hiroya
> Systems Development Laboratory
> Hitachi, Ltd.
> tel: +81-44-549-1531
> fax: +81-44-549-1640
> email: [email-masked]
> 

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]