Subject: RE: Error Handling

From: David Burdett <[email-masked]>
Date: Tue, 1 Jun 1999 05:01:47 +0100

Masaaki

I agree with you, I think we need to represent how to handle the combination
of business and technical errors, taking into account the use of
encapsulated payment protocols, in a multi-message document exchange, more
clearly than in the current spec.

I've started working on this but I'm busy for the next couple of days and
probably won't be able to get the re-worked text out until towards the end
of this week.

David

> ----------
> From: 	Masaaki Hiroya[SMTP:[email-masked]]
> Sent: 	31 May 1999 06:26
> To: 	David Burdett; Ietf Trade WG
> Subject: 	RE: Error Handling
> 
> 
> I have an addtional comment on the last mail I sent about
> transient business error handling. 
> 
> Transient business errors may occur during PayExch message processing
> after PayReq messages are processed normally: for example,
> 
> In SET, AuthReq messages are sent to the SET payment gateway by the SET
> merchant server connected to the IOTP Payment Handler server after 
> the Payment Handler receives PReq messages included in PayExch 
> messages from the Consumer.
> 
> If an AuthRes message with AuthCode=Declined is returned as a response
> from the SET payment gateway, the SET payment bridge may return a 
> business error to the IOTP Payment Handler.
> 
> Therefore, I think it is necessary to describe which message the IOTP 
> client should send to the server and which messages should not stored
> by the server, depending on the completion code.
> 
> The IOTP client should send the new message defined below or abort
> the transaction when business errors occur.
> 
> For example,
> Offer Exchange
> "AuthError": AuthResp message
> 
> Payment Exchange
> "BrandNotSupp" : PayReq message
> "CurrNotSupp" : PayReq message
> "AuthError" : PayReq message
> "InsuffFunds" : PayReq message
> "InstrumentBrandInvalid" : PayReq message
> "InstNotValid" : PayReq message
> "BadInstrument" : PayReq message
> 
> The IOTP servers should not store the following messages and
> the new messages can be processed as if they had never been received
> before when business transient errors occur.
> 
> For example,
> Offer Exchange Phase
> "AuthError": received AuthResp message
> 
> Payment Exchange Phase
> "BrandNotSupp" : received PayReq and PayExch messages
> "CurrNotSupp" : received PayReq and PayExch messages
> "AuthError" : received PayReq and PayExch messages
> "InsuffFunds" : received PayReq and PayExch messages
> "InstrumentBrandInvalid" : receivedPayReq and PayExch messages
> "InstNotValid" : received PayReq and PayExch messages
> "BadInstrument" : received PayReq and PayExch messages
> 
> Any comments?
> 
> If I misunderstand the specifications about transient 
> business errors, please let me know.
> 
> Massaki
> 
> 
> At 02:45 99/05/28 +0900, Masaaki Hiroya wrote:
> > 
> > I have additional questions regarding transient business errors.
> > 
> > In 4.4.1.9 of the IOTP specification and your previous mail,
> > >"If any of the previous steps resulted in an error being detected and
> an
> > > Error Component being created then generate an Error Block (step 9)
> > > containing the Error Components that describe the error(s).
> > > 
> > > Unless the error is a "Transient Error", the Error Component(s) and
> the
> > > previous Request or Exchange block that caused the Error Components to
> be
> > > generated should be stored so that it can be reused if the action
> request
> > > is
> > > received again (step 6a).
> > > 
> > > "Transient Errors" are not stored so that if the original Request or
> > > Exchange Block is received again, then it can be processed as if it
> had
> > > never been received before."
> > 
> > The above sentences seem descriptions about how to handle technical
> errors,
> > but is the last sentence applicable to the transient business errors? 
> > 
> > If so, do the transient (payment) business errors occur only while the 
> > server entities process received PayReq messages but not received
> PayExch 
> > messages?
> > 
> > In this case, when the server entities receive PayExch messages, PayReq
> > messages should have been processed normally, so I think that the server
> > entities reject new PayReq messages including new payment brands and 
> > protocols selected by the Consumers.
> > 
> > Otherwise, is it allowed to receive new PayReq messages even after 
> > processing original PayReq messages normally and sending back
> > PayExch messages to the client? 
> > If so, the business errors may occur during processing PayExch messages.
> > 
> > In this case, it is necessary to define which message should be send
> > by the client and be waited for by the server depending on each
> completion
> > code when a transient business error occurs.  For example,
> > if the "insufficient funds" business error occurs, the Consumer client
> > should send a new PayReq message including a new payment brand and 
> > protocol in it or a cancel message to the Payment Handler server, and
> > the Payment Handler server should wait for them. 
> > 
> > I think it is better to add how to handle business errors to Fig.10
> > and Fig.11 in the IOTP specification, which show Server Role Processing
> > Sequence and Client Role Processing Sequence respectively.
> > 
> > I would like to make clear the differences between transient technical 
> > errors and transient business errors in detail regarding the Server
> > Role bahavior and the Client Role behavior.
> > 
> > Thank you in advance
> > Masaaki
> > 
> > 
> > At 20:43 99/5/26 +0100, David Burdett wrote:
> > > In my last email on Error Handling it said in the description of
> Payment
> > > Completion codes that:
> > > 
> > > > If the Payment is Brand Independent, then recovery may be possible
> for
> > > > some values of the Completion Code, by the Consumer selecting a
> differ
> ent
> > > > payment brand. Note that this might involve a different Payment
> Handler.
> > > > The codes to which this applies are: BrandNotSupp, PaymtCancelled,
> > > > InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument and
> > > > Unspecified.
> > > > 
> > > 	Recovery from Payments associated with Brand Dependent purchases is
> > > not possible, since the Offer is dependent on a the entries selected
> from
> > > the Brand List. A changed selection will invalidate the Offer
> Response.
> > > 
> > > This is not quite correct. It should have said ...
> > > 
> > > > If the Payment is Brand Independent, then recovery may be possible
> for
> > > > some values of the Completion Code, by the Consumer selecting either
> a
> > > > different payment brand or a different payment instrument for the
> same
> > > > brand. Note that this might involve a different Payment Handler. The
> c
> odes
> > > > to which this applies are: BrandNotSupp, PaymtCancelled,
> InsuffFunds,
> > > > InstBrandInvalid, InstNotValid, BadInstrument and Unspecified.
> > > > 
> > > 	Recovery from Payments associated with Brand Dependent purchases is
> > > only possible, if the Brand Selection component sent by the Merchant
> to 
> the
> > > Consumer does not change. In practice this means that the same Brand,
> > > Protocol Amount and PayProtocol elements must be used. All that can
> change
> > > is the Payment Instrument. Any other change will invalidate the
> Merchant's
> > > Offer as a changed selection will invalidate the Offer Response.
> > > 
> > > > ----------
> > > > From: 	David Burdett[SMTP:[email-masked]]
> > > > Sent: 	25 May 1999 14:05
> > > > To: 	Ietf Trade WG; [email-masked]
> > > > Subject: 	RE: Error Handling
> > > > 
> > > > Most of Masaaki's questions are to do with "Transient Errors" and
> how to
> > > > handle them. I think that Transient Errors can be caused by either
> > > > business
> > > > or technical reasons. For example:
> > > > *	if a server that is handling a payment (e.g. a SET server,
> or a SCCD
> > > > server) is busy, even if the IOTP server is not, then the valid
> response
> > > > might be to tell the consumer to retry re-send exactly the same
> message
> > > > some
> > > > time later. This is a transient technical error.
> > > > *	on the other hand if the payment instrument is not usable,
> for
> > > > example there are insufficient funds on a credit card, then the
> consumer
> > > > needs to select a different payment instrument. This is a transient
> > > > business
> > > > error since the transaction can continue with a different payment
> > > > instrument.
> > > > 
> > > > This is consistent with the current defintions of the two types of
> err
> or.
> > > > *	"technical errors" which are independent of the meaning of
> the IOTP
> > > > Message, and
> > > > *	"business errors" which indicate that there is a problem
> specific to
> > > > the process (e.g. payment or delivery) which is being carried out
> > > > 
> > > > Therefore I think that these two types of "transient" error need
> handl
> ing
> > > > differently with:
> > > > *	"transient technical errors" being handled by sending an
> Error
> > > > Component to the the other Trading Role which results in the
> > > > re-transmission
> > > > of the original message at some slightly later point in time, and 
> > > > *	"transient business errors" where a "response" message is
> sent which
> > > > allows the other role, e.g. a Consumer, to retry with, for example,
> > > > another
> > > > payment instrument
> > > > 
> > > > Below are detailed changes to the IOTP spec, and responses to
> Masaaki's
> > > > individual questions.
> > > > 
> > > > David
> > > > 
> > > > CHANGES TO THE SPEC
> > > > 
> > > > NEW SECTION - TRANSIENT TECHNICAL ERRORS
> > > > Add a new section on "Transient Technical Errors" after the section
> > > > 4.3.3.2
> > > > on "Block and Component Consistency Checks" that says:
> > > > 
> > > > "If the block passes the "Block Level Attribute and Element Checks"
> and
> > > > the
> > > > "Block and Component Consistency Checks" then it is processed either
> by
> > > > the
> > > > IOTP Aware application or perhaps by some "back-end" system such as
> a
> > > > payment server. During this processing some temporary failure may
> occur
> > > > that
> > > > can potentially be recovered by the other trading role
> re-transmitting
> , at
> > > > some slightly later time, the original message that they sent. 
> > > > 
> > > > In this case the other role is informed of the Transient Error by
> send
> ing
> > > > them an Error Component (see section 6.19) with the Severity
> Attribute
>  set
> > > > to TransientError and the MinRetrySecs attribute set to some value
> > > > suitable
> > > > for the Transport Mechanism being used (see appropriate Transport
> > > > Supplement).
> > > > 
> > > > Note that transient technical errors can be sent by any of the
> Trading
> > > > Roles
> > > > involved in transaction."
> > > > 
> > > > UPDATED SECTION - BLOCK BUSINESS ERRORS
> > > > Clarify the section on Block Business Errors (section 4.3.3.3) to
> read
>  ...
> > > > 
> > > > "If a business error occurs in a process such as a Payment or a
> Delive
> ry,
> > > > then the appropriate type of response block is returned containing a
> > > > Status
> > > > Component (see section 6.14) with the ProcessState attribute set to
> Fa
> iled
> > > > and the CompletionCode indicating the nature of the problem.
> > > > 
> > > > Some business errors may be "transient" in that the Consumer role
> may be
> > > > able to recover and complete the transaction in some other way. For
> > > > example
> > > > if the Credit Card that a consumer provided had insufficient funds
> for a
> > > > purchase, then the Consumer may recover by using a different credit
> ca
> rd.
> > > > 
> > > > Recovery from "transient" business errors is dependent on the
> > > > CompletionCode. See the definition of the Status Component for what
> is
> > > > possible.
> > > > 
> > > > Note that no Error Component or Error Block is generated for
> business
> > > > errors."
> > > > 
> > > > REVISED COMPLETION CODES FOR STATUS COMPONENT
> > > > Change the defintion of the CompletionCode attribute in the Status
> > > > component
> > > > to read ...
> > > > 
> > > > 	"Indicates how the process completed. Valid values for the
> > > > CompletionCode are given below together with the conditions when it
> must
> > > > be
> > > > present and indications on when recovery from failures are
> possible."
> > > > 
> > > > Update sections 6.14.1 to 6.14.4 to indicate where recovery from
> trans
> ient
> > > > business errors are possible, as follows:
> > > > 
> > > > 6.14.1 Offer Completion Codes
> > > > The Completion Code is only required if the ProcessState attribute
> is 
> set
> > > > to
> > > > Failed. The following table contains the valid values for the
> > > > CompletionCode
> > > > that may be used and indicates whether or not recovery might be
> possib
> le.
> > > > It
> > > > is recommended that the StatusDesc attribute is used to provide
> further
> > > > explanation where appropriate.
> > > > *	Value		Description	
> > > > *	"AuthError"	Authentication Error. The check of the
> > > > Authentication Response which was carried out has failed. Recovery
> may
>  be
> > > > possible by the Consumer re-submitting a new Authentication Response
> B
> lock
> > > > with corrected information.	
> > > > *	"ConsCancelled"	Consumer Cancelled. The Consumer decides to
> cancel
> > > > the transaction for some reason. This code is only valid in a Status
> > > > Component contained in a Cancel Block or an Inquiry Response Block.
> No
> > > > recovery possible.	
> > > > *	"MerchCancelled"	Offer Cancelled. The Merchant
> declines to
> > > > generate an offer for some reason and cancels the transaction. This
> code
> > > > is
> > > > only valid in a Status Component contained in a Cancel Block or an
> Inq
> uiry
> > > > Response Block. No recovery possible.	
> > > > *	"Unspecified"	Unspecified error. There is some unknown
> problem or
> > > > error which does not fall into one of the other CompletionCodes. No
> > > > recovery
> > > > possible	
> > > > 
> > > > 6.14.2 Payment Completion Codes
> > > > The CompletionCode is only required if the ProcessState attribute is
> set
> > > > to
> > > > Failed. The following table contains the valid values for the
> > > > CompletionCode
> > > > that may be used and indicates where recovery may be possible. It is
> > > > recommended that the StatusDesc attribute is used by individual
> payment
> > > > schemes to provide further explanation where appropriate.
> > > > *	Value		Description	
> > > > *	"BrandNotSupp"	Brand not supported. The payment brand is
> not
> > > > supported by the Payment Handler. See below for recovery options.
> 
> > > > *	"CurrNotSupp"	Currency not supported. The currency in
> which the
> > > > payment is to be made is not supported by either the Payment
> Instrumen
> t or
> > > > the Payment Handler. If the payment is Brand Independent, then the
> > > > Consumer
> > > > may recover by selecting a different currency, if available, or a
> > > > different
> > > > brand. Note that this may involve a different Payment Handler.	
> > > > *	"ConsCancelled"	Consumer Cancelled. The Consumer decides to
> cancel
> > > > the payment for some reason. This code is only valid in a Status
> Compo
> nent
> > > > contained in a Cancel Block or an Inquiry Response Block. Recovery
> is 
> not
> > > > possible.	
> > > > *	"PaymtCancelled"	Payment Cancelled. The Payment
> Handler
> > > > declines to complete the payment for some reason and cancels the
> > > > transaction. This code is only valid in a Status Component contained
> i
> n a
> > > > Cancel Block or an Inquiry Response Block. See below for recovery
> opti
> ons.
> > > > 
> > > > *	"AuthError"	Authentication Error. The Payment Scheme
> specific
> > > > authentication check which was carried out has failed. Recovery may
> be
> > > > possible. See the payment scheme supplement to determine what is
> allow
> ed.
> > > > 
> > > > *	"InsuffFunds"	Insufficient funds. There are insufficient
> funds
> > > > available for the payment to be made. See below for recovery
> options.	
> > > > *	"InstBrandInvalid"	Payment Instrument not valid for
> Brand. A
> > > > Payment Instrument is being used which does not correspond with the
> Br
> and
> > > > selected. For example a Visa credit card is being used when
> MasterCard
>  was
> > > > selected as the Brand. See below for recovery options.	
> > > > *	"InstNotValid"	Payment instrument not valid for trade. The
> Payment
> > > > Instrument cannot be used for the proposed type of trade, for some
> rea
> son.
> > > > See below for recovery options.	
> > > > *	"BadInstrument"	Bad instrument. There is a problem with the
> Payment
> > > > Instrument being used which means that it is unable to be used for
> the
> > > > payment. See below for recovery options.	
> > > > *	"Unspecified"	Unspecified error. There is some unknown
> problem or
> > > > error which does not fall into one of the other CompletionCodes. The
> > > > StatusDesc attribute should provide the explanation of the cause.
> See
> > > > below
> > > > for recovery options.	
> > > > 
> > > > If the Payment is Brand Independent, then recovery may be possible
> for
> > > > some
> > > > values of the Completion Code, by the Consumer selecting a different
> > > > payment
> > > > brand. Note that this might involve a different Payment Handler. The
> c
> odes
> > > > to which this applies are: BrandNotSupp, PaymtCancelled,
> InsuffFunds,
> > > > InstBrandInvalid, InstNotValid, BadInstrument and Unspecified.
> > > > 
> > > > Recovery from Payments associated with Brand Dependent purchases is
> not
> > > > possible, since the Offer is dependent on a the entries selected
> from 
> the
> > > > Brand List. A changed selection will invalidate the Offer Response.
> > > > 
> > > > 6.14.3 Delivery Completion Codes
> > > > The following table contains the valid values for the CompletionCode
> > > > attribute for a Delivery. It is recommended that the StatusDesc
> attrib
> ute
> > > > is
> > > > used to provide further explanation where appropriate.
> > > > *	Value		Description	
> > > > *	"BackOrdered"	Back Ordered. The goods to be delivered are
> on order
> > > > but they have not yet been received. Shipping will be arranged when
> they
> > > > are
> > > > received. This is only valid if ProcessState is CompletedOk.
> Recovery is
> > > > not
> > > > possible.	
> > > > *	"PermNotAvail"	Permanently Not Available. The goods are
> permanently
> > > > unavailable and cannot be re-ordered. This is only valid if
> ProcessState
> > > > is
> > > > Failed. Recovery is not possible.	
> > > > *	"TempNotAvail"	Temporarily Not Available. The goods are
> temporarily
> > > > unavailable and may become available if they can be ordered. This is
> o
> nly
> > > > valid if ProcessState is CompletedOk. Recovery is not possible.	
> > > > *	"ShipPending"	Shipping Pending. The goods are available
> and are
> > > > scheduled for shipping but they have not yet been shipped. This is
> only
> > > > valid if ProcessState is CompletedOk. Recovery is not possible.	
> > > > *	"Shipped"	Goods Shipped. The goods have been shipped.
> > > > Confirmation of delivery is awaited. This is only valid if
> ProcessStat
> e is
> > > > CompletedOk. Recovery is not possible.	
> > > > *	"ShippedNoConf"	Shipped - No Delivery Confirmation. The
> goods have
> > > > been shipped but it is not possible to confirm delivery of the
> goods. 
> This
> > > > is only valid if ProcessState is CompletedOk. Recovery is not
> possible.
> > > > 
> > > > *	"ConsCancelled"	Consumer Cancelled. The Consumer decides to
> cancel
> > > > the delivery for some reason. This code is only valid in a Status
> > > > Component
> > > > contained in a Cancel Block or an Inquiry Response Block. Recovery
> is 
> not
> > > > possible.	
> > > > *	"DelivCancelled"	Delivery Cancelled. The Delivery
> Handler
> > > > declines to complete the Delivery for some reason and cancels the
> > > > transaction. This code is only valid in a Status Component contained
> i
> n a
> > > > Cancel Block or an Inquiry Response Block. 	
> > > > *	"Confirmed"	Confirmed. All goods have been delivered and
> > > > confirmation of their delivery has been received. This is only valid
> if
> > > > ProcessState is CompletedOk. 	
> > > > *	"Unspecified"	Unspecified error. There is some unknown
> problem or
> > > > error which does not fall into one of the other CompletionCodes. The
> > > > StatusDesc attribute should provide the explanation of the cause.
> Reco
> very
> > > > is not possible.	
> > > > 
> > > > 	[Note]	Recovery from failed, or partially completed
> deliveries is
> > > > not possible. The Consumer should use the Transaction Status Inquiry
> > > > Transaction (see section 9.2.1) to determine up-to-date information
> on
>  the
> > > > current state.
> > > > 	[Note End]	
> > > > 
> > > > 6.14.4 Authentication Completion Codes
> > > > The Completion Code is only required if the ProcessState attribute
> is 
> set
> > > > to
> > > > Failed. The following table contains the valid values for the
> > > > CompletionCode
> > > > that may be used. It is recommended that the StatusDesc attribute is
> u
> sed
> > > > to
> > > > provide further explanation where appropriate.
> > > > *	Value	Description	
> > > > *	"AutEeCancel"	Authenticatee Cancel. The organisation being
> > > > authenticated declines to be authenticated for some reason. This
> could
>  be,
> > > > for example because the signature on an Authentication Request was
> inv
> alid
> > > > or the Authenticator was not known or acceptable to the
> Authenticatee.
> > > > Recovery is not possible.	
> > > > *	"AutOrCancel"	Authenticator Cancel. The organisation
> requesting
> > > > authentication declines to validate the Authentication Response
> received
> > > > for
> > > > some reason and cancels the transaction. Recovery is not possible.
> 
> > > > *	"NoAuthData"	Authentication Request Not Available. The
> > > > Authenticatee does not have the data that must be provided so that
> they
> > > > may
> > > > be successfully authenticated. For example a password may have been
> > > > forgotten, the Authenticatee has not yet become a member, or a smart
> c
> ard
> > > > token is not present. Recovery is not possible	
> > > > *	"AuthFailed"	Authentication Failed. The Authenticator
> checked the
> > > > Authentication Response but the authentication failed for some
> reason.
>  For
> > > > example a password may have been incorrect. Recovery may be possible
> by
> > > > the
> > > > Authenticatee re-sending a revised Authentication Response with
> correc
> ted
> > > > data.	
> > > > *	"TradRolesIncon"	Trading Roles Inconsistent. The
> Trading
> > > > Roles contained within the TradingRoleList attribute of the
> Authentica
> tion
> > > > Request Component are inconsistent with the Trading Role which the
> > > > Authenticatee is taking in the IOTP Transaction or is able to take.
> > > > Examples
> > > > of inconsistencies include: asking a PaymentHandler for
> DeliveryHandler
> > > > information asking a Consumer for Merchant information Recovery may
> be
> > > > possible by the Authenticator re-sending a revised Authentication
> Requ
> est
> > > > Block with corrected information.	
> > > > *	"Unspecified"	Unspecified error. There is some unknown
> problem or
> > > > error which does not fall into one of the other CompletionCodes.
> Recov
> ery
> > > > is
> > > > not possible.	
> > > > 
> > > > Comments on questions below ...
> > > > > ----------
> > > > > From: 	Masaaki Hiroya[SMTP:[email-masked]]
> > > > > Reply To: 	[email-masked]
> > > > > Sent: 	23 May 1999 00:59
> > > > > To: 	[email-masked]
> > > > > Subject: 	Error Handling
> > > > > 
> > > > > David and Werner
> > > > > 
> > > > > I have some questions about error handling.
> > > > > 
> > > > > [Question 1]
> > > > > The business error handling described in IOTP Payment API
> Supplement
> > > > > v1.0.1a
> > > > > is inconsistent with the one described in IOTP specification
> v1.0-03.
> > > > > 
> > > > > In 4.3.3.3 Block Business Errors in the IOTP specification, there
> is
>  a 
> > > > > description as follows:
> > > > > "If a business error occurs in a process such as a Payment or a
> > > > >  Delivery, then the appropriate type of response block is
> returned. 
> The
> > > > >  Status Component (see section 6.14) within that response block
> > > > >  indicates the error and its severity. No Error Component or Error
> B
> lock
> > > > >  is generated for business errors."
> > > > > 
> > > > > In 8.5.2 Intermediate Failures in the Payment API Supplement,
> there 
> is a
> > > > > description as follows:
> > > > > "Transient Error: Failures, that might be resolved by the
> retransmis
> sion
> > > > > of 
> > > > > the appropriate IOTP message, belong to this class. 
> > > > > ......
> > > > > The behavior of the IOTP Application Core and IOTP Payment Bridge
> does
> > > > not
> > > > > depend on any further classification of this failure
> > > > > (technical/business)."
> > > > > 
> > > > > In Fig.31 in 8.5.2, an business error with severity
> "TransientError"
>  is 
> > > > > notified from the Payment Handler to the Consumer by using an
> Error
> > > > > message.
> > > > > 
> > > > > Which should be used, ErrorBlk and Error Component or PayRespBlk
> and
> > > > > Status
> > > > > Component in the case of business errors with "TransientError"
> sever
> ity?
> > > > >  
> > > > > If the Status Component should be used in any business error, it
> is
> > > > > necessary
> > > > > to add a "Severity" attribute to the Status Component, since there
> i
> s no
> > > > 
> > > > > "Severity" attribute in the Status Component defined in 6.14 of
> the 
> IOTP
> > > > 
> > > > > specification.
> > > > ## Should be answered by earlier comments ##
> > > > 
> > > > > [Question 2]
> > > > > This is a confirmation rather than a question.
> > > > > After the Consumer receives the PayResp message with Severity
> "Trans
> ient
> > > > > Error", the Consumer sends the retrying PayExch message in order
> to
> > > > > continue
> > > > > the transaction, doesn't it?
> > > > > I think the answer is "yes" since there is the Server Role
> descripti
> on 
> > > > > in 4.4.1.9 of the IOTP specification as follows:
> > > > >   "Transient Errors" are not stored so that if the original
> Response
> > > > >   Block is received again, then it can be processed as if it had
> never
> > > > >   been received before.
> > > > > (In the above sentence, I think that "the original Response Block"
> > > > should 
> > > > >  be "the original Request Block" because the Server Role receives
> > > > request
> > > > >  blocks.)
> > > > > ## Also answered by earlier comments and correct 4.4.1.9 to read
> ...
> > > > "If any of the previous steps resulted in an error being detected
> and an
> > > > Error Component being created then generate an Error Block (step 9)
> > > > containing the Error Components that describe the error(s).
> > > > 
> > > > Unless the error is a "Transient Error", the Error Component(s) and
> the
> > > > previous Request or Exchange block that caused the Error Components
> to
>  be
> > > > generated should be stored so that it can be reused if the action
> requ
> est
> > > > is
> > > > received again (step 6a).
> > > > 
> > > > "Transient Errors" are not stored so that if the original Request or
> > > > Exchange Block is received again, then it can be processed as if it
> had
> > > > never been received before."
> > > > >  ##
> > > > > 
> > > > > [Question 3]
> > > > > Additional Confirmation.  It is allowed to set different values
> from
>  the
> > > > > original request message to the retrying request message in the
> case
>  of
> > > > > business errors with "TransientError" severity, isn't it?
> > > > > I think the answer should be "yes" since in the case of
> "Insufficient
> > > > > Fund"
> > > > > the Consumer may replace the e-cash card and then retry the
> transact
> ion
> > > > > so PaySchemeData in the original may be different from the one in
> the
> > > > > retrying message.
> > > > > 
> > > > > The reason why I am confused is there is a description in 4.4.2.8
> of
> > > > > IOTP specification as follows:
> > > > >   "Transient errors may be used to provide a manual or automatic
> > > > >   resending (step 8b) of a block previously stored or
> alternatively 
> may
> > > > >   result in transaction cancellation."
> > > > ## Answered by earlier comments ##
> > > > 
> > > > > [Question 4]
> > > > > Some errors are not easy to classify as technical errors or
> business
> > > > > errors.
> > > > > If the payment server such as the SET Merchant connected to IOTP
> Pay
> ment
> > > > > Handler server through its payment bridge has an internel
> processing
> > > > > error,
> > > > > is it a technical error or a business error with an completion
> code of
> > > > > "BadInstrument"?  If the SET Merchant server doesn't respond to
> the
> > > > > request
> > > > > from the payment bridge of the Payment Handler, is it a technical
> er
> ror
> > > > or
> > > > > a business error with "BadInstrument" completion code?
> > > > ## Answered by earlier comments ##
> > > > 
> > > > > [Question 5]
> > > > > Accoring to the IOTP specification, PayReceipt Component is
> mandator
> y in
> > > > 
> > > > > PayRespBlk and it is required to use PayRespBlk in the case of
> busin
> ess 
> > > > > errors, 
> > > > > But I think most payment schemes doesn't generate payment receipts
> w
> hen
> > > > > errors
> > > > > occur.  Taking it into consideration, the PayReceipt should be
> optio
> nal
> > > > in
> > > > > the 
> > > > > PayRespBlk.  What do you think about it?
> > > > ## I agree, Pay Receipt Component is only required if the Status
> compo
> nent
> > > > is "Completed OK".
> > > > 
> > > > The DTD is changed from ...
> > > > 
> > > > <!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?,
> > > >      PaymentNote?, TradingRoleData*) >
> > > > 
> > > > ... to ...
> > > > 
> > > > <!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
> > > >      PaymentNote?, TradingRoleData*) >
> > > > 
> > > > ... and the description of the PayReceipt in the Pay Response Block
> is
> > > > changed to ...
> > > > 
> > > > 	"Contains payment scheme specific data which can be used to
> verify
> > > > the payment occurred. See section 7.10 Payment Receipt Component. It
> m
> ust
> > > > be
> > > > present if the ProcessState attribute of the Status Component is set
> to
> > > > CompletedOk. PayReceipt is optional for other values as specified by
> the
> > > > appropriate Payment Scheme supplement."
> > > > 
> > > > 
> > > > > Regards
> > > > > Masaaki
> > > > > -----
> > > > > Masaaki Hiroya
> > > > > Systems Development Laboratory
> > > > > Hitachi, Ltd.
> > > > > tel: +81-44-959-0874
> > > > > fax: +81-44-959-0856
> > > > > 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
> us
> ing
> > > > 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
> usin
> g 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]
> > > 
> > -----
> > Masaaki Hiroya
> > Systems Development Laboratory
> > Hitachi, Ltd.
> > tel: +81-44-959-0874
> > fax: +81-44-959-0856
> > 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]
> >  
> -----
> Masaaki Hiroya
> Systems Development Laboratory
> Hitachi, Ltd.
> email: [email-masked]
> tel: +81-44-966-9111(ext.3552)
> fax: +81-44-966-1796
> -----------------------------------------------------------------------
> 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]

---

From: David Burdett <[email-masked]>
Date: Tue, 15 Jun 1999 04:10:44 +0100

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>> 

> Sent: 	31 May 1999 21:01
> To: 	Ietf Trade WG; Masaaki Hiroya

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200

---

From: Michael Zeff <[email-masked]>
Date: Tue, 15 Jun 1999 16:09:54 +1200

David,

We are just about to start implementing an IOTP server and the Server Logic
text is exactly what we were looking for.
I certainly found the server role processing description an improvement.

Mike Zeff
Internet Product Specialist
CLEAR Communications Ltd.
Auckland, New Zealand
ph:  +64-9-9124695
fax: +64-9-9125008
http://www.clear.net.nz

-----Original Message-----
From: David Burdett [mailto:[email-masked]]
Sent: Tuesday, 15 June 1999 15:11
To: Ietf Trade WG; Masaaki Hiroya
Subject: RE: Error Handling

David

> > > > WebSite:        http://www.mondexinternational.com

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

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.

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200

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

---

From: [email-masked]
Date: Thu, 17 Jun 1999 04:17:34 +0100

That's good news. I'm glad you found it useful.

I'm working on the consumer role equivalent ... and what do you know ... a
lot of it is the same.

Anyway, as I said in my original email, this is just a design and has not
been reviewed by anyone else, so if you identify ANY problems PLEASE post
them to the list.

David

> ----------
> From: 	Michael Zeff[SMTP:[email-masked]]
> Sent: 	14 June 1999 21:09
> To: 	Ietf Trade WG
> > > > > > then the appropriate type of response block is returned
> containing
> > a
> > > > > > Status
> > > > > > The CompletionCode is only required if the ProcessState
> attribute
> > is
> > > set
> > > > > > to
> > > > > > that may be used and indicates where recovery may be possible.
> It
> > is
> > > > > > unavailable and may become available if they can be ordered.
> This
> > is
> > > o
> > > nly
> > > > > > that may be used. It is recommended that the StatusDesc
> attribute
> > is
> > > u
> > > sed
> > > > > > to
> Request
> > > > > > the payment occurred. See section 7.10 Payment Receipt
> Component.
> > It
> > > m
> > > ust
> > > > > > be
> > > > > > CompletedOk. PayReceipt is optional for other values as
> specified
> > by
> > > the
> > > > > > > Archive available at:
> http://www.elistx.com/archives/ietf-trade/
> using

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200

---

From: Masaaki Hiroya <[email-masked]>
Date: Sun, 20 Jun 1999 11:28:37 +0900

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?

(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

(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?

(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?

Thank you in advance
Masaaki

-----
Masaaki Hiroya
tel: +81-44-549-1531
fax: +81-44-549-1640

---

From: [email-masked]
Date: Mon, 21 Jun 1999 05:29:55 +0100

Masaaki

 I don't have time to look into all your questions right now but there are
some answers below ...

David

> Sent: 	19 June 1999 19:28
> To: 	[email-masked]; [email-masked]
## Not sure. Will check ##

> >     - if the  previous payment is  still in progress  then it is  a
## 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##

> 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.##

> 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. ##

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200

---

From: [email-masked]
Date: Sat, 26 Jun 1999 03:04:12 +0100

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

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	20 June 1999 21:29
> To: 	[email-masked]; [email-masked]
> > > reviewed by *anyone* so no doubt you'll find bugs ;) . Anyway I've
> tried
> > to

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200

---

From: Masaaki Hiroya <[email-masked]>
Date: Mon, 28 Jun 1999 02:56:19 +0900

David

> indicate that there was an error in the Inquiry Request Block when in fact

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

-----
Masaaki Hiroya