From ietf-trade-owner@one.eListX.com Tue Jun 1 00:24:14 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11223
for ; Tue, 1 Jun 1999 00:24:14 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa09460; 1 Jun 99 00:04 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa09448;
1 Jun 99 00:03 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_3753_5a79_b9e2;
Tue, 01 Jun 1999 04:58:49 +0100
Message-Id:
From: David Burdett
To: Ietf Trade WG ,
Masaaki Hiroya
Subject: RE: Error Handling
Date: Tue, 1 Jun 1999 05:01:47 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
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:hiroya@sdl.hitachi.co.jp]
> 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:David.Burdett@mondex.com]
> > > > Sent: 25 May 1999 14:05
> > > > To: Ietf Trade WG; hiroya@sdl.hitachi.co.jp
> > > > 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:hiroya@sdl.hitachi.co.jp]
> > > > > Reply To: hiroya@sdl.hitachi.co.jp
> > > > > Sent: 23 May 1999 00:59
> > > > > To: ietf-trade@elistx.com
> > > > > 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 ...
> > > >
> > > > > > > PaymentNote?, TradingRoleData*) >
> > > >
> > > > ... to ...
> > > >
> > > > > > > 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: hiroya@sdl.hitachi.co.jp
> > > > >
> --------------------------------------------------------------------
> ---
> > > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> the
> > > > > body to: ietf-trade-request@lists.elistx.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
> us
> ing
> > > > email
> > > > address postmaster@mondex.com 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: postmaster@mondex.com
> > > > WebSite: http://www.mondexinternational.com
> > > >
> > > >
> **********************************************************************
> ****
> > > > *******************
> > > >
> -----------------------------------------------------------------------
> > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > > body to: ietf-trade-request@lists.elistx.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
> usin
> g email
> > > address postmaster@mondex.com 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: postmaster@mondex.com
> > > WebSite: http://www.mondexinternational.com
> > >
> > >
> ************************************************************************
> ****
> > > *****************
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: ietf-trade@lists.elistx.com
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: ietf-trade-request@lists.elistx.com
> > >
> > -----
> > Masaaki Hiroya
> > Systems Development Laboratory
> > Hitachi, Ltd.
> > tel: +81-44-959-0874
> > fax: +81-44-959-0856
> > email: hiroya@sdl.hitachi.co.jp
> > -----------------------------------------------------------------------
> > Message addressed to: ietf-trade@lists.elistx.com
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: ietf-trade-request@lists.elistx.com
> >
> -----
> Masaaki Hiroya
> Systems Development Laboratory
> Hitachi, Ltd.
> email: hiroya@sdl.hitachi.co.jp
> tel: +81-44-966-9111(ext.3552)
> fax: +81-44-966-1796
> -----------------------------------------------------------------------
> Message addressed to: ietf-trade@lists.elistx.com
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Tue Jun 1 03:19:00 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24932
for ; Tue, 1 Jun 1999 03:19:00 -0400 (EDT)
Received: by one.eListX.com id aa09985; 1 Jun 99 03:17 EDT
Received: from one.elistx.com by one.eListX.com id aa09787; 1 Jun 99 02:39 EDT
Received: from shell.ziplink.net by one.eListX.com id aa09759;
1 Jun 99 02:39 EDT
Received: from localhost (densmore@localhost)
by shell.ziplink.net (8.9.1/8.9.1) with SMTP id CAA29015;
Tue, 1 Jun 1999 02:40:22 -0400 (EDT)
Date: Tue, 1 Jun 1999 02:40:22 -0400 (EDT)
From: Bill Densmore
Reply-To: Bill Densmore
To: densmore@ziplink.net
Subject: REMINDER: Two weeks left until IIPC roundtable summit (fwd)
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
For those interested in information payments, rights management and
personalization . . . .
DETAILS: http://www.iipc.net/email.html
+----------------------------------------------------------------------+
| Bill Densmore -- President CLICKSHARE SERVICE CORP. |
| 75 Water St., P.O. Box 266 densmore@clickshare.com |
| Williamstown MA 01267 USA 413 458-8001 |
| Making the market for digital information http://www.clickshare.com |
+----------------------------------------------------------------------+
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Tue Jun 1 13:23:30 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03523
for ; Tue, 1 Jun 1999 13:23:29 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa14954; 1 Jun 99 13:05 EDT
Received: from web702.mail.yahoo.com by one.eListX.com id aa14942;
1 Jun 99 13:04 EDT
Message-ID: <19990601170929.9618.rocketmail@web702.mail.yahoo.com>
Received: from [194.214.201.233] by web702.mail.yahoo.com; Tue, 01 Jun 1999 19:09:29 CEST
Date: Tue, 1 Jun 1999 19:09:29 +0200 (CEST)
From: Pvd
Subject: IOTP toolkit
To: ietf-trade@elistx.com
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Content-Transfer-Encoding: 8bit
Hi,
I'm looking for a java package or toolkit for an IOTP development. Maybe
could you help me !
Regards.
Vincent PHAM
France.
___________________________________________________________
Do You Yahoo!?
Votre e-mail @yahoo.fr gratuit sur http://courrier.yahoo.fr
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Wed Jun 2 18:03:05 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11569
for ; Wed, 2 Jun 1999 18:03:04 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa24907; 2 Jun 99 17:44 EDT
Received: from portal1.visa.com by one.eListX.com id aa24895; 2 Jun 99 17:42 EDT
Received: by portal1.visa.com id OAA17818
(InterLock SMTP Gateway 4.2 for ietf-trade@elistx.com);
Wed, 2 Jun 1999 14:43:25 -0700
Received: by portal1.visa.com (Protected-side Proxy Mail Agent-1);
Wed, 2 Jun 1999 14:43:25 -0700
Message-Id: <7BD626A8132BD211B1F60001FA6A2C5801BEF380@sw720x030.visa.com>
From: "Lewis, Tony"
To: Ietf Trade WG
Subject: RE: Initial IOTP Brand Ids
Date: Wed, 2 Jun 1999 14:43:21 -0700
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
The following is a list of the contents of the subjectName organizationName
field used for each of the current SET brands:
American Express
Dankort
JCB
Maestro
MasterCard
NICOS
VISA
Tony
> ----------
> From: David Burdett[SMTP:David.Burdett@MONDEX.com]
> Sent: Thursday, May 27, 1999 10:44 AM
> To: Lewis, Tony; Yoshiaki KAWATSURA
> Cc: Ietf Trade WG
> Subject: RE: Initial IOTP Brand Ids
>
> Yoshiaki raises an interesting point. Brand names such as Visa,
> MasterCard,
> JCB, etc, are actually owned by their respective companies. Can we, in the
> IETF Trade WG, just define what these Brands' BrandIds for IOTP will be
> without getting their permission first?
>
> One approach might be to go through SETCo and get blanket permission to
> adopt SETCo's BrandIds in order to save the companies having to
> individually
> register them through IANA later.
>
> Thoughts?
>
> David
>
> > ----------
> > From: Yoshiaki KAWATSURA[SMTP:kawatura@bisd.hitachi.co.jp]
> > Sent: 26 May 1999 22:56
> > To: tlewis@visa.com
> > Cc: ietf-trade@elistx.com; kawatura@bisd.hitachi.co.jp
> > Subject: RE: Initial IOTP Brand Ids
> >
> > Hello,
> >
> > >>>>> Wed, 26 May 1999 16:54:57 -0700,
> > "Lewis, Tony" said:
> >
> > > The list of brands who have requested a SET object identifier (the
> list
> > you
> > > found in Book 3) is not the same as the list of brands who have
> > requested a
> > > SET brand certificate.
> > Absolutely.
> >
> > But basically I think IOTP Brand ID registration should be requested by
> > each brand-owner. There is no problem if the JCB Card registers
> > "JCB_Card" as the IOTP Brand ID, not "JCB".
> >
> > Furthermore, there is no problem if the UC Card registers
> > "Visa_UC" as the IOTP Brand ID, not same as the SET brand(in this
> > case, "Visa" brand is used as the SET Brand. In this case, the Brand
> > Element
> > is became as follows.
> >
> > > BrandId='Visa_UC'
> > BrandName='UC Visa Card'
> > BrandLogoNetLocn='http://otplogos.uccard.com'
> > ProtocolAmountRefs='xxx xxx'>
> > > ProtocolId='SETv1.0'
> > ProtocolBrandId='Visa' />
> >
> >
> > As this case we can discount for each the dual brand (even if the
> > promotional brand).
> >
> > P.S.
> > We have to be able to check the consistency between IOTP brand and
> > payment scheme specific brand because there are defined separately.
> > We have to have the table of relationship between them in the
> > Payment Bridge....
> >
> > ----
> > Yoshiaki Kawatsura : E-mail kawatura@bisd.hitachi.co.jp
> > Business & Information Systems Development Division, Hitachi,Ltd.
> > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> >
> > > I will try to get you a list of those brands.
> > >
> > > Tony
> > > > ----------
> > > > From: David Burdett[SMTP:David.Burdett@mondex.com]
> > > > Sent: Wednesday, May 26, 1999 12:43 PM
> > > > To: Ietf Trade WG
> > > > Subject: Initial IOTP Brand Ids
> > > >
> > > > We need to build a list of IOTP Brand Ids for inclusion in the IOTP
> > spec.
> > > >
> > > > The initial list I have developed is as follows:
> > > > * from SET Book 3 Formal Protocol Definition:
> > > > - "IATA"
> > > > - "Diners"
> > > > - "AmericanExpress"
> > > > - "JCB"
> > > > - "Visa"
> > > > - "MasterCard"
> > > > - "Novus"
> > > >
> > > > * none SET brand ids:
> > > > - "Mondex"
> > > > - "Maestro"
> > > > - "GeldKarte"
> > > >
> > > > It would be good if the initial list is reasonably comprehensive and
> > > > accurate so if anyone wants more Brand Ids added (or any taken off
> !!)
> > > > then
> > > > please let me know. Also do you think we need to specify a contact
> or
> > > > "owner" of the Brand as SET does.
> > > >
> > > > Additional brands can, of course, be added later using IANA
> > procedures.
> > > >
> > > > David
> > > >
> > > > > mailto:
> > > > > Mondex International, US Advanced Technology Office
> > > > > 111 Pine St, 6th Floor, San Francisco, CA 94111
> > > > > Tel/Voicemail: +1 415 645 6973 Fax: +1 415 956 9370
> > > > >
> > > >
> > > >
> >
> **************************************************************************
> > > > ********************
> > > >
> > > > 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 postmaster@mondex.com 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: postmaster@mondex.com
> > > > WebSite: http://www.mondexinternational.com
> > > >
> > > >
> >
> **************************************************************************
> > > > *******************
> > > >
> > -----------------------------------------------------------------------
> > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > > body to: ietf-trade-request@lists.elistx.com
> > > >
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: ietf-trade@lists.elistx.com
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: ietf-trade-request@lists.elistx.com
> > >
> > -----------------------------------------------------------------------
> > Message addressed to: ietf-trade@lists.elistx.com
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
> WebSite: http://www.mondexinternational.com
>
> **************************************************************************
> *******************
>
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Wed Jun 2 18:36:56 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11907
for ; Wed, 2 Jun 1999 18:36:56 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa25110; 2 Jun 99 18:17 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa25098;
2 Jun 99 18:17 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_3755_aca8_775c;
Wed, 02 Jun 1999 23:14:00 +0100
Message-Id:
From: David Burdett
To: Ietf Trade WG , Pvd
Subject: RE: IOTP toolkit
Date: Wed, 2 Jun 1999 23:15:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
> I've come across this from Xenosys Coroporation which shows their
> intention to provide a Java based toolkit for IOTP. I don't know anything
> else about it or Xenosys though.
>
http://www.livebiz.com/jotp/body.html
David
> ----------
> From: Pvd[SMTP:pvd_2000@yahoo.fr]
> Sent: 01 June 1999 10:09
> To: ietf-trade@elistx.com
> Subject: IOTP toolkit
>
> Hi,
>
> I'm looking for a java package or toolkit for an IOTP development.
> Maybe
> could you help me !
>
> Regards.
> Vincent PHAM
> France.
>
> ___________________________________________________________
> Do You Yahoo!?
> Votre e-mail @yahoo.fr gratuit sur http://courrier.yahoo.fr
>
> -----------------------------------------------------------------------
> Message addressed to: ietf-trade@lists.elistx.com
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Wed Jun 2 21:11:21 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12943
for ; Wed, 2 Jun 1999 21:11:21 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa26215; 2 Jun 99 20:51 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id ab26191;
2 Jun 99 20:50 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_3755_d0a6_7ad1;
Thu, 03 Jun 1999 01:47:34 +0100
Message-Id:
From: David Burdett
To: Yoshiaki KAWATSURA
Cc: Ietf Trade WG
Subject: RE: OECD PDA Tag
Date: Thu, 3 Jun 1999 01:49:32 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Yoshiaki has pointed out a problem with the accessing the OECD tag web site
as a password is required. What you need to do is first register with the
OECD by at http://www.oecd.org/daf/fa/e_com/e_rego.htm ... the OECD will
then send you back by email your user password in a few days. You should
then be able access the web site.
BTW another joint meeting of the Professional Data Assessment, Consumption
Tax and Tecnology "Tags" was held on Monday/Tuesday this week at Palo Alto.
No doubt the minutes of this meeting will be placed in due course on the
public web site.
David
> ----------
> From: Yoshiaki KAWATSURA[SMTP:kawatura@bisd.hitachi.co.jp]
> Sent: 30 May 1999 04:15
> To: David.Burdett@mondex.com
> Cc: kawatura@bisd.hitachi.co.jp
> Subject: Re: OECD PDA Tag
>
> David,
> It seems to me both pages of this web site are private because
> authentication is needed....
>
> --
> Yoshiaki Kawatsura Hitachi, Ltd.
>
> >>>>> Sat, 29 May 1999 18:55:27 +0100,
> David Burdett said:
>
> > The summary of the OECD Professional Data Assessment Tag meeting held in
> > Washington in April is available on the public side of the OECD web site
> at
> > ...
> >
> >
> >
> http://appli1.oecd.org/daf/TaxandEl.nsf/ae6ab2df50d9aa54c12567460045d5c8/c
> 53
> > 6ae18ca96227ec125677f0058ce98?OpenDocument
> >
> > ... although you might find it easier to get there by going to the forum
> > home page first at ...
> >
> > http://appli1.oecd.org/daf/taxandel.nsf
> >
> > David
>
**********************************************************************************************
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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Wed Jun 2 21:14:15 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12986
for ; Wed, 2 Jun 1999 21:14:14 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa26211; 2 Jun 99 20:51 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa26191;
2 Jun 99 20:50 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_3755_d0a7_7ad3;
Thu, 03 Jun 1999 01:47:35 +0100
Message-Id:
From: David Burdett
To: Ietf Trade WG , Tony Lewis
Subject: RE: Initial IOTP Brand Ids
Date: Thu, 3 Jun 1999 01:49:31 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Tony
Thanks for the updated lists. I've used it to update the "BrandId"
defintions inside the "IANA Considerations" chapter which now reads:
The following values for BrandIds have been taken from [SET]
Book 3. Formal Protocol Definition:
"Amex" - American Express
"Dankort" - Dankort
"JCB" - JCB
"Maestro" - Maestro
"MasterCard" - MasterCard
"NICOS" - NICOS
"VISA" - Visa
In addition the following Brand Id values are defined:
"Mondex"
"GeldKarte"
New values of BrandId must be announced to the IETF Trade
mailing list and, if there are no objections within three weeks, are
allocated on a "first come first served" basis.
If anyone has any comments please let me know.
David
> ----------
> From: Lewis, Tony[SMTP:tlewis@visa.com]
> Sent: 02 June 1999 14:43
> To: Ietf Trade WG
> Subject: RE: Initial IOTP Brand Ids
>
> The following is a list of the contents of the subjectName
> organizationName
> field used for each of the current SET brands:
>
> American Express
> Dankort
> JCB
> Maestro
> MasterCard
> NICOS
> VISA
>
> Tony
> > ----------
> > From: David Burdett[SMTP:David.Burdett@MONDEX.com]
> > Sent: Thursday, May 27, 1999 10:44 AM
> > To: Lewis, Tony; Yoshiaki KAWATSURA
> > Cc: Ietf Trade WG
> > Subject: RE: Initial IOTP Brand Ids
> >
> > Yoshiaki raises an interesting point. Brand names such as Visa,
> > MasterCard,
> > JCB, etc, are actually owned by their respective companies. Can we, in
> the
> > IETF Trade WG, just define what these Brands' BrandIds for IOTP will be
> > without getting their permission first?
> >
> > One approach might be to go through SETCo and get blanket permission to
> > adopt SETCo's BrandIds in order to save the companies having to
> > individually
> > register them through IANA later.
> >
> > Thoughts?
> >
> > David
> >
> > > ----------
> > > From: Yoshiaki KAWATSURA[SMTP:kawatura@bisd.hitachi.co.jp]
> > > Sent: 26 May 1999 22:56
> > > To: tlewis@visa.com
> > > Cc: ietf-trade@elistx.com; kawatura@bisd.hitachi.co.jp
> > > Subject: RE: Initial IOTP Brand Ids
> > >
> > > Hello,
> > >
> > > >>>>> Wed, 26 May 1999 16:54:57 -0700,
> > > "Lewis, Tony" said:
> > >
> > > > The list of brands who have requested a SET object identifier (the
> > list
> > > you
> > > > found in Book 3) is not the same as the list of brands who have
> > > requested a
> > > > SET brand certificate.
> > > Absolutely.
> > >
> > > But basically I think IOTP Brand ID registration should be requested
> by
> > > each brand-owner. There is no problem if the JCB Card registers
> > > "JCB_Card" as the IOTP Brand ID, not "JCB".
> > >
> > > Furthermore, there is no problem if the UC Card registers
> > > "Visa_UC" as the IOTP Brand ID, not same as the SET brand(in this
> > > case, "Visa" brand is used as the SET Brand. In this case, the Brand
> > > Element
> > > is became as follows.
> > >
> > > > > BrandId='Visa_UC'
> > > BrandName='UC Visa Card'
> > > BrandLogoNetLocn='http://otplogos.uccard.com'
> > > ProtocolAmountRefs='xxx xxx'>
> > > > > ProtocolId='SETv1.0'
> > > ProtocolBrandId='Visa' />
> > >
> > >
> > > As this case we can discount for each the dual brand (even if the
> > > promotional brand).
> > >
> > > P.S.
> > > We have to be able to check the consistency between IOTP brand and
> > > payment scheme specific brand because there are defined separately.
> > > We have to have the table of relationship between them in the
> > > Payment Bridge....
> > >
> > > ----
> > > Yoshiaki Kawatsura : E-mail kawatura@bisd.hitachi.co.jp
> > > Business & Information Systems Development Division, Hitachi,Ltd.
> > > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> > >
> > > > I will try to get you a list of those brands.
> > > >
> > > > Tony
> > > > > ----------
> > > > > From: David Burdett[SMTP:David.Burdett@mondex.com]
> > > > > Sent: Wednesday, May 26, 1999 12:43 PM
> > > > > To: Ietf Trade WG
> > > > > Subject: Initial IOTP Brand Ids
> > > > >
> > > > > We need to build a list of IOTP Brand Ids for inclusion in the
> IOTP
> > > spec.
> > > > >
> > > > > The initial list I have developed is as follows:
> > > > > * from SET Book 3 Formal Protocol Definition:
> > > > > - "IATA"
> > > > > - "Diners"
> > > > > - "AmericanExpress"
> > > > > - "JCB"
> > > > > - "Visa"
> > > > > - "MasterCard"
> > > > > - "Novus"
> > > > >
> > > > > * none SET brand ids:
> > > > > - "Mondex"
> > > > > - "Maestro"
> > > > > - "GeldKarte"
> > > > >
> > > > > It would be good if the initial list is reasonably comprehensive
> and
> > > > > accurate so if anyone wants more Brand Ids added (or any taken off
> > !!)
> > > > > then
> > > > > please let me know. Also do you think we need to specify a contact
> > or
> > > > > "owner" of the Brand as SET does.
> > > > >
> > > > > Additional brands can, of course, be added later using IANA
> > > procedures.
> > > > >
> > > > > David
> > > > >
> > > > > > mailto:
> > > > > > Mondex International, US Advanced Technology Office
> > > > > > 111 Pine St, 6th Floor, San Francisco, CA 94111
> > > > > > Tel/Voicemail: +1 415 645 6973 Fax: +1 415 956 9370
> > > > > >
> > > > >
> > > > >
> > >
> >
> **************************************************************************
> > > > > ********************
> > > > >
> > > > > 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 postmaster@mondex.com 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: postmaster@mondex.com
> > > > > WebSite: http://www.mondexinternational.com
> > > > >
> > > > >
> > >
> >
> **************************************************************************
> > > > > *******************
> > > > >
> > >
> -----------------------------------------------------------------------
> > > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> > > the
> > > > > body to: ietf-trade-request@lists.elistx.com
> > > > >
> > > >
> > -----------------------------------------------------------------------
> > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > > body to: ietf-trade-request@lists.elistx.com
> > > >
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: ietf-trade@lists.elistx.com
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
> > WebSite: http://www.mondexinternational.com
> >
> >
> **************************************************************************
> > *******************
> >
> -----------------------------------------------------------------------
> Message addressed to: ietf-trade@lists.elistx.com
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Wed Jun 2 22:18:40 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14371
for ; Wed, 2 Jun 1999 22:18:39 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa26499; 2 Jun 99 22:01 EDT
Received: from differential.com by one.eListX.com id aa26487; 2 Jun 99 22:01 EDT
Received: from dracula (stopper.corp.differential.com [63.67.66.10])
by differential.com (8.9.3/8.9.3) with SMTP id TAA12486
for ; Wed, 2 Jun 1999 19:02:59 -0700 (PDT)
Message-Id: <4.0.1.19990602184613.00e306b0@differential.com>
X-Sender: dbunny@differential.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1
Date: Wed, 02 Jun 1999 19:03:22 -0700
To: ietf-trade@elistx.com
From: "Kent M. Davidson"
Subject: draft-ietf-trade-iotp-v1.0-dsig-01.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
I've made some minor edits to the 1.0 DSIG document for IOTP based on suggestions from the list. I've submitted the original to Donald who will publish it in a form for all to view shortly. This is more of a publication for those who made comments and want to know the resolution.
Changes in draft-ietf-trade-iotp-v1.0-dsig-01.txt:
- Fixed typo "Sigantures" -> "Signatures"
- Updated file name to reflect revision
- Section 4.3.2: , added end quote (Kawatsura)
- Section 6: Updated example to "quote" correctly, minor errors (Kawatsura)
- Section 3.2: Removed reference to Resource element, fixed example (Kawatsura)
- Section 4.2, and 7: exchange the order between Signature Component and Certificate
Component (Kawatsura)
- Changed Attributes? -> Attribute*, removed Attributes section (Kawatsura)
- Updated author's address at end of document
- Removed 4.3.5 Attributes, shifted 4.3.6-4.3.8 numbers
- Updated DTD to comply with parsing engines
- Resolution on required algorithms: Suggestions to change requirement to "should", also remove "MD5". No change, language updated to say "MUST". Don't want to remove MD5 as it is the most standard digest used and most widely available algorithm.
- Added language to 4.3.1 to augment: Sign the manifest element itself, Description of signing.
-Kent.
_____________________________________________________________
Kent M. Davidson
VP Engineering
Differential, Inc.
http://www.differential.com
main (650)426-1100
fax (650)426-1101
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Thu Jun 3 12:16:33 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07888
for ; Thu, 3 Jun 1999 12:16:29 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa28819; 3 Jun 99 11:56 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa28807;
3 Jun 99 11:54 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_3756_a476_c262;
Thu, 03 Jun 1999 16:51:18 +0100
Message-Id:
From: David Burdett
To: Ietf Trade WG , Tony Lewis
Subject: RE: Initial IOTP Brand Ids
Date: Thu, 3 Jun 1999 16:53:29 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
I should have checked what I'd written ;( The initial words that describe
BrandId in IANA considerations should/will be ...
"The following list of initial BrandIds have been taken from those
organisations that have applied for SET certificates as at 1st June 1999:"
David
> ----------
> From: David Burdett[SMTP:David.Burdett@mondex.com]
> Sent: 02 June 1999 17:49
> To: Ietf Trade WG; Tony Lewis
> Subject: RE: Initial IOTP Brand Ids
>
> Tony
>
> Thanks for the updated lists. I've used it to update the "BrandId"
> defintions inside the "IANA Considerations" chapter which now reads:
>
> The following values for BrandIds have been taken from [SET]
> Book 3. Formal Protocol Definition:
>
> "Amex" - American Express
> "Dankort" - Dankort
> "JCB" - JCB
> "Maestro" - Maestro
> "MasterCard" - MasterCard
> "NICOS" - NICOS
> "VISA" - Visa
>
> In addition the following Brand Id values are defined:
> "Mondex"
> "GeldKarte"
>
> New values of BrandId must be announced to the IETF Trade
> mailing list and, if there are no objections within three weeks, are
> allocated on a "first come first served" basis.
>
> If anyone has any comments please let me know.
>
> David
>
> > ----------
> > From: Lewis, Tony[SMTP:tlewis@visa.com]
> > Sent: 02 June 1999 14:43
> > To: Ietf Trade WG
> > Subject: RE: Initial IOTP Brand Ids
> >
> > The following is a list of the contents of the subjectName
> > organizationName
> > field used for each of the current SET brands:
> >
> > American Express
> > Dankort
> > JCB
> > Maestro
> > MasterCard
> > NICOS
> > VISA
> >
> > Tony
> > > ----------
> > > From: David Burdett[SMTP:David.Burdett@MONDEX.com]
> > > Sent: Thursday, May 27, 1999 10:44 AM
> > > To: Lewis, Tony; Yoshiaki KAWATSURA
> > > Cc: Ietf Trade WG
> > > Subject: RE: Initial IOTP Brand Ids
> > >
> > > Yoshiaki raises an interesting point. Brand names such as Visa,
> > > MasterCard,
> > > JCB, etc, are actually owned by their respective companies. Can we, in
> > the
> > > IETF Trade WG, just define what these Brands' BrandIds for IOTP will
> be
> > > without getting their permission first?
> > >
> > > One approach might be to go through SETCo and get blanket permission
> to
> > > adopt SETCo's BrandIds in order to save the companies having to
> > > individually
> > > register them through IANA later.
> > >
> > > Thoughts?
> > >
> > > David
> > >
> > > > ----------
> > > > From: Yoshiaki KAWATSURA[SMTP:kawatura@bisd.hitachi.co.jp]
> > > > Sent: 26 May 1999 22:56
> > > > To: tlewis@visa.com
> > > > Cc: ietf-trade@elistx.com; kawatura@bisd.hitachi.co.jp
> > > > Subject: RE: Initial IOTP Brand Ids
> > > >
> > > > Hello,
> > > >
> > > > >>>>> Wed, 26 May 1999 16:54:57 -0700,
> > > > "Lewis, Tony" said:
> > > >
> > > > > The list of brands who have requested a SET object identifier (the
> > > list
> > > > you
> > > > > found in Book 3) is not the same as the list of brands who have
> > > > requested a
> > > > > SET brand certificate.
> > > > Absolutely.
> > > >
> > > > But basically I think IOTP Brand ID registration should be requested
> > by
> > > > each brand-owner. There is no problem if the JCB Card registers
> > > > "JCB_Card" as the IOTP Brand ID, not "JCB".
> > > >
> > > > Furthermore, there is no problem if the UC Card registers
> > > > "Visa_UC" as the IOTP Brand ID, not same as the SET brand(in this
> > > > case, "Visa" brand is used as the SET Brand. In this case, the Brand
> > > > Element
> > > > is became as follows.
> > > >
> > > > > > > BrandId='Visa_UC'
> > > > BrandName='UC Visa Card'
> > > > BrandLogoNetLocn='http://otplogos.uccard.com'
> > > > ProtocolAmountRefs='xxx xxx'>
> > > > > > > ProtocolId='SETv1.0'
> > > > ProtocolBrandId='Visa' />
> > > >
> > > >
> > > > As this case we can discount for each the dual brand (even if the
> > > > promotional brand).
> > > >
> > > > P.S.
> > > > We have to be able to check the consistency between IOTP brand and
> > > > payment scheme specific brand because there are defined separately.
> > > > We have to have the table of relationship between them in the
> > > > Payment Bridge....
> > > >
> > > > ----
> > > > Yoshiaki Kawatsura : E-mail kawatura@bisd.hitachi.co.jp
> > > > Business & Information Systems Development Division, Hitachi,Ltd.
> > > > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> > > >
> > > > > I will try to get you a list of those brands.
> > > > >
> > > > > Tony
> > > > > > ----------
> > > > > > From: David Burdett[SMTP:David.Burdett@mondex.com]
> > > > > > Sent: Wednesday, May 26, 1999 12:43 PM
> > > > > > To: Ietf Trade WG
> > > > > > Subject: Initial IOTP Brand Ids
> > > > > >
> > > > > > We need to build a list of IOTP Brand Ids for inclusion in the
> > IOTP
> > > > spec.
> > > > > >
> > > > > > The initial list I have developed is as follows:
> > > > > > * from SET Book 3 Formal Protocol Definition:
> > > > > > - "IATA"
> > > > > > - "Diners"
> > > > > > - "AmericanExpress"
> > > > > > - "JCB"
> > > > > > - "Visa"
> > > > > > - "MasterCard"
> > > > > > - "Novus"
> > > > > >
> > > > > > * none SET brand ids:
> > > > > > - "Mondex"
> > > > > > - "Maestro"
> > > > > > - "GeldKarte"
> > > > > >
> > > > > > It would be good if the initial list is reasonably comprehensive
> > and
> > > > > > accurate so if anyone wants more Brand Ids added (or any taken
> off
> > > !!)
> > > > > > then
> > > > > > please let me know. Also do you think we need to specify a
> contact
> > > or
> > > > > > "owner" of the Brand as SET does.
> > > > > >
> > > > > > Additional brands can, of course, be added later using IANA
> > > > procedures.
> > > > > >
> > > > > > David
> > > > > >
> > > > > > > mailto:
> > > > > > > Mondex International, US Advanced Technology Office
> > > > > > > 111 Pine St, 6th Floor, San Francisco, CA 94111
> > > > > > > Tel/Voicemail: +1 415 645 6973 Fax: +1 415 956 9370
> > > > > > >
> > > > > >
> > > > > >
> > > >
> > >
> >
> **************************************************************************
> > > > > > ********************
> > > > > >
> > > > > > 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 postmaster@mondex.com 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: postmaster@mondex.com
> > > > > > WebSite: http://www.mondexinternational.com
> > > > > >
> > > > > >
> > > >
> > >
> >
> **************************************************************************
> > > > > > *******************
> > > > > >
> > > >
> > -----------------------------------------------------------------------
> > > > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > > To (un)subscribe send a message with "subscribe" or
> "unsubscribe"
> > in
> > > > the
> > > > > > body to: ietf-trade-request@lists.elistx.com
> > > > > >
> > > > >
> > >
> -----------------------------------------------------------------------
> > > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> > > the
> > > > > body to: ietf-trade-request@lists.elistx.com
> > > > >
> > > >
> > -----------------------------------------------------------------------
> > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > > body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
> > > WebSite: http://www.mondexinternational.com
> > >
> > >
> >
> **************************************************************************
> > > *******************
> > >
> > -----------------------------------------------------------------------
> > Message addressed to: ietf-trade@lists.elistx.com
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
> WebSite: http://www.mondexinternational.com
>
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: ietf-trade@lists.elistx.com
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Tue Jun 8 20:43:06 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04032
for ; Tue, 8 Jun 1999 20:43:06 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa01088; 8 Jun 99 20:28 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa01076;
8 Jun 99 20:27 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_375d_b436_7783;
Wed, 09 Jun 1999 01:24:22 +0100
Message-Id:
From: David Burdett
To: Ietf Trade WG
Subject: Fundamental Errors in IOTP Messages
Date: Wed, 9 Jun 1999 01:26:31 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
There are some instances where an IOTP message is so badly damaged that it
cannot be sensibly processed. Yet, we still want to return an error
component that identifies where the error has occured. Currently the
defintion of the error component does not support this as it requires that
the Id of the IotpMsg in error be present which can only be extracted if the
message is reasonably OK.
Changes apply to the Error Location element:
- IotpMsgRef Attribute, and
- the AttName Attribute
Details below with some examples.
David
IOTPMSGREF Attribute
=================
Therefore I propose that we change Error Location so that the IotpMsgRef is
Implied rather than Required. We can then, for example, handle severe errors
as follows:
ATTNAME attribute
===============
We can also usefully slightly change the defintion of the ATTNAME attribute
from
"If the error is associated with the value of an attribute, then this is the
name of that attribute. In this case the PackagedContent of the Error
Component should contain the value of the attribute."
... to ...
If the error is associated with an attribute, then this contains the name of
that attribute. If the value of the attribute is in error or inconsistent
then the PackagedContent of the Error Component should contain the value of
the attribute.
EXAMPLE
The following illustrate the usage:
1. XML not well formed
... copy of input message ...
2. XML not valid
... copy of input message ...
3. IotpTransId cannot be found
... copy of input message ...
> mailto:
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973 Fax: +1 415 956 9370
>
**********************************************************************************************
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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Tue Jun 8 20:45:26 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04036
for ; Tue, 8 Jun 1999 20:43:06 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa01102; 8 Jun 99 20:28 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa01090;
8 Jun 99 20:27 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_375d_b441_778f;
Wed, 09 Jun 1999 01:24:33 +0100
Message-Id:
From: David Burdett
To: Ietf Trade WG
Subject: Digitally Signing Inquiry Requests
Date: Wed, 9 Jun 1999 01:26:33 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Looking through the Transaction Status Inquiry part of the spec says ...
IOTP aware software that supports the Consumer Trading Role may not:
* digitally sign a response if requested, since it may
not have the capability, or
* respond to an Inquiry Request at all since it may
not be on-line, or may consider that the request is not reasonable since,
for example, the Request was not digitally signed.
However the rest of the transaction doesn't include any references to
digital signatures. Therefore propose to add the relevant text to allow
signatures on Inquiry Requests. Specifically ...
1. Adding Signature Block to the lists of blocks at the start of the section
2. Adding Signature Block to the Message containing the Inquiry Request
Block (see revised message flow below)
3. Adding processing rules for the Signature Block - see below.
4. Also added the following:
[Note] Inquiries on Baseline Ping IOTP Transactions (see section
9.2.2) are ignored.
[Note End]
SIGNATURE BLOCK
If a signature block is present on the message containing the Inquiry
Request Block then it may be checked to determine if the Inquiry Request is
authorised.
Inquiry Response Blocks should only be generated if the Transaction is
authorised.
[Note] Determining if an Inquiry Request is authorised is at user
discretion. For example, if the original transaction was processed over a
secure link then it may be reasonable to presume that if the sender of the
Inquiry knows the Transaction Id component of the original message
(including for example the timestamp) then the inquiry is likely to be
genuine.
Checking for a digital signature is an optional
additional check that may be used.
[Note End]
REVISED MESSAGE FLOW
View in fixed font ...
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
1st Role
| 2nd Role
STEP | |
1. The first role decides to inquire on an IOTP
Transaction by, for example, clicking on the inquiry
button of an IOTP Aware Application. This will then
generate an Inquiry Request Block and send it to the
appropriate Trading Role.
1 --> 2 INQUIRY REQUEST. IotpMsg: TransRef Block; Signature
Block (optional); Inquiry Request Block
2. The Trading Role checks the digital signature (if
present). If the recipient wants to respond then the
Trading Role checks the transaction status of the
transaction that is being inquired upon by using the
IotpTransId in the Transaction ID Component of the
Transaction Reference Block, then generates the
appropriate Inquiry Response Block, sends the message
back to the 1st Role and stops
1 <-- 2 INQUIRY RESPONSE. IotpMsg: TransRef Block; Inquiry
Response Block
3. First role checks the Inquiry Response Block and takes
whatever action is appropriate or perhaps stops. This
may include displaying status information to the end
user.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> mailto:
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973 Fax: +1 415 956 9370
>
**********************************************************************************************
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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Wed Jun 9 02:06:46 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20530
for ; Wed, 9 Jun 1999 02:06:45 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa03133; 9 Jun 99 01:51 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa03121;
9 Jun 99 01:51 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_375e_0039_7c55;
Wed, 09 Jun 1999 06:48:41 +0100
Message-Id:
From: David Burdett
To: Ietf Trade WG
Subject: Problems with Status Type and Error Codes
Date: Wed, 9 Jun 1999 06:50:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
The Status Component is used in a Status Inquiry Transaction to report on
the status of an Iotp Transaction by a server. Currently this requires that
the StatusType attribute in the component is specified as either
Authentication, Offer, Payment or Delivery. Yet it is possible that an Input
Message is received by a server where the IotpTransId can be identified but
the document exchange cannot due to an error in the input message.
As it currently stands the Status Inquiry Transaction can't validly report
this type of error. Proposed change is as follows:
1. Add a new StatusType value of "Undefined" to be used when the type of
document exchange can't be recognised.
2. Change the ElRef attribute that points to data that describes the type of
exchange from Required to Implied and make it optional if the StatusType is
Undefined.
David
> mailto:
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973 Fax: +1 415 956 9370
>
**********************************************************************************************
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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Wed Jun 9 04:08:01 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21731
for ; Wed, 9 Jun 1999 04:08:00 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa03786; 9 Jun 99 03:55 EDT
Received: from hitpro.hitachi.co.jp by one.eListX.com id aa03774;
9 Jun 99 03:54 EDT
Received: from bisdgw.bisd.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id RAA19532; Wed, 9 Jun 1999 17:03:35 +0900 (JST)
Received: from bisdmail.bisd.hitachi.co.jp
by bisdgw.bisd.hitachi.co.jp (8.9.3+3.2W/3.7W-bisdgw) with ESMTP id QAA20872;
Wed, 9 Jun 1999 16:56:26 +0900 (JST)
(envelope-from kawatura@ecd.bisd.hitachi.co.jp)
Received: from localhost
by bisdmail.bisd.hitachi.co.jp (8.9.3/3.7W-bisdmail) with ESMTP id QAA00149;
Wed, 9 Jun 1999 16:56:25 +0900 (JST)
(envelope-from kawatura@ecd.bisd.hitachi.co.jp)
Message-Id: <199906090756.QAA00149@bisdmail.bisd.hitachi.co.jp>
To: David.Burdett@mondex.com
Cc: ietf-trade@elistx.com
Cc: kawatura@bisd.hitachi.co.jp
Subject: Minor Change Requests for the TradingRole Element.
From: Yoshiaki KAWATSURA
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 09 Jun 1999 16:56:25 +0900 (JST)
X-Dispatcher: imput version 980905(IM100)
Lines: 50
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Content-Transfer-Encoding: 7bit
David,
The current specification(6.5.2) describes about the CancelNetLocn and
ErrorNetLocn in TradingRole element as follows:
--
CancelNetLocn:
This attribute:
o must not be present when TradingRole is set to Consumer role,
o must be present when TradingRole is set to Merchant,
PaymentHandler or DeliveryHandler.
ErrorNetLocn
This attribute:
o must not be present when TradingRole is set to Consumer role,
o must be present when TradingRole is set to Merchant,
PaymentHandler or DeliveryHandler.
--
I think the DelivTo role also must not be present at both Locations.
Additionaly, the current DTD definition of TradingRole is as follows:
I think this should be changed as follows:
Regards,
----
Yoshiaki Kawatsura : E-mail kawatura@bisd.hitachi.co.jp
Business & Information Systems Development Division, Hitachi,Ltd.
Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Wed Jun 9 17:19:02 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03815
for ; Wed, 9 Jun 1999 17:19:01 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa10195; 9 Jun 99 17:03 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa10183;
9 Jun 99 17:02 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_375e_d5ac_cd89;
Wed, 09 Jun 1999 21:59:24 +0100
Message-Id:
From: David Burdett
To: Yoshiaki KAWATSURA
Cc: Ietf Trade WG
Subject: RE: Minor Change Requests for the TradingRole Element.
Date: Wed, 9 Jun 1999 22:01:31 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Yoshiaki
I agreee with your comments. Changes will be made to the DTD and to the
write up in the specification.
Note that the defintion of the TradingRole element is now ...
Note especially that IotpMsgIdPrefix is now in TradingRole rather than the
Organisation component. See Chris Smith's email dated 21 May, titled
"Implementation Results and IOTP Items -OrgID / Role / Prefix" for the
reason.
David
> ----------
> From: Yoshiaki KAWATSURA[SMTP:kawatura@bisd.hitachi.co.jp]
> Sent: 09 June 1999 00:56
> To: David.Burdett@mondex.com
> Cc: ietf-trade@elistx.com; kawatura@bisd.hitachi.co.jp
> Subject: Minor Change Requests for the TradingRole Element.
>
> David,
>
> The current specification(6.5.2) describes about the CancelNetLocn and
> ErrorNetLocn in TradingRole element as follows:
>
> --
> CancelNetLocn:
> This attribute:
> o must not be present when TradingRole is set to Consumer role,
> o must be present when TradingRole is set to Merchant,
> PaymentHandler or DeliveryHandler.
>
> ErrorNetLocn
> This attribute:
> o must not be present when TradingRole is set to Consumer role,
> o must be present when TradingRole is set to Merchant,
> PaymentHandler or DeliveryHandler.
> --
>
> I think the DelivTo role also must not be present at both Locations.
>
>
> Additionaly, the current DTD definition of TradingRole is as follows:
>
>
> ID ID #REQUIRED
> TradingRole NMTOKEN #REQUIRED
> CancelNetLocn CDATA #REQUIRED
> ErrorNetLocn CDATA #REQUIRED
> ErrorLogNetLocn CDATA #IMPLIED >
>
> I think this should be changed as follows:
>
>
> ID ID #REQUIRED
> TradingRole NMTOKEN #REQUIRED
> CancelNetLocn CDATA #IMPLIED
> ~~~~~~~~
> ErrorNetLocn CDATA #IMPLIED
> ~~~~~~~~
> ErrorLogNetLocn CDATA #IMPLIED >
>
> Regards,
>
> ----
> Yoshiaki Kawatsura : E-mail kawatura@bisd.hitachi.co.jp
> Business & Information Systems Development Division, Hitachi,Ltd.
> Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> -----------------------------------------------------------------------
> Message addressed to: ietf-trade@lists.elistx.com
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Fri Jun 11 22:18:23 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10471
for ; Fri, 11 Jun 1999 22:18:23 -0400 (EDT)
Received: by one.eListX.com id aa11962; 11 Jun 99 22:11 EDT
Received: from one.elistx.com by one.eListX.com id aa11766; 11 Jun 99 21:50 EDT
Received: from proxy3.ba.best.com by one.eListX.com id aa11741;
11 Jun 99 21:49 EDT
Received: from C980732-D (dynamic19.pm01.santa-cruz.best.com [209.157.50.19])
by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id SAA27771
for ; Fri, 11 Jun 1999 18:49:48 -0700 (PDT)
Message-ID: <001f01beb476$707b1e10$20330118@C980732-D.frmt1.sfba.home.com>
From: Zia Khan
To: ietf-trade@elistx.com
MMDF-Warning: Parse error in original version of preceding line at one.eListX.com
Subject: Electronic Commerce Modeling Language (ECML)?
Date: Fri, 11 Jun 1999 18:53:58 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Content-Transfer-Encoding: 7bit
Does any body have details on this announcement:
http://www.news.com/News/Item/0,4,37712,00.html?st.ne.fd.gif.k
What are the differences between ECML and IOTP?
--------------------------------------------------------------------
Zia Khan, Member LiveBiz Team
Xenosys Corporation, 258 Java Drive, Sunnyvale, CA 94089
Phone: 408.744.0309 Fax: 408.744.9007
e-mail: zia@xenosys.com WWW: http://www.livebiz.com
Developers of LiveBusiness Foundation Classes for Java
--------------------------------------------------------------------
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Sat Jun 12 01:17:13 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14543
for ; Sat, 12 Jun 1999 01:17:12 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa14842; 12 Jun 99 01:05 EDT
Received: from [209.94.126.195] by one.eListX.com id aa14830;
12 Jun 99 01:04 EDT
Received: from localhost (localhost [127.0.0.1])
by torque.pothole.com (8.8.2/8.8.8) with SMTP id BAA11978;
Sat, 12 Jun 1999 01:07:00 -0400 (EDT)
Message-Id: <199906120507.BAA11978@torque.pothole.com>
X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol
To: Zia Khan
cc: ietf-trade@elistx.com
Subject: Re: Electronic Commerce Modeling Language (ECML)?
In-reply-to: Your message of "Fri, 11 Jun 1999 18:53:58 PDT."
<001f01beb476$707b1e10$20330118@C980732-D.frmt1.sfba.home.com>
Date: Sat, 12 Jun 1999 01:06:59 -0400
From: "Donald E. Eastlake 3rd"
X-Mts: smtp
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
The story says that information will be released Monday. Why not wait
until them to get the official word?
Thanks,
Donlad
From: Zia Khan
Message-ID: <001f01beb476$707b1e10$20330118@C980732-D.frmt1.sfba.home.com>
To: ietf-trade@elistx.com
Date: Fri, 11 Jun 1999 18:53:58 -0700
>Does any body have details on this announcement:
>
>http://www.news.com/News/Item/0,4,37712,00.html?st.ne.fd.gif.k
>
>What are the differences between ECML and IOTP?
>--------------------------------------------------------------------
>Zia Khan, Member LiveBiz Team
>Xenosys Corporation, 258 Java Drive, Sunnyvale, CA 94089
>Phone: 408.744.0309 Fax: 408.744.9007
>e-mail: zia@xenosys.com WWW: http://www.livebiz.com
>Developers of LiveBusiness Foundation Classes for Java
>--------------------------------------------------------------------
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Mon Jun 14 10:11:17 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15478
for ; Mon, 14 Jun 1999 10:11:16 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa25463; 14 Jun 99 09:53 EDT
Received: from firewall.globeset.com by one.eListX.com id aa25451;
14 Jun 99 09:51 EDT
Received: from earth.globeset.com (earth.globeset.com [10.1.1.5])
by firewall.globeset.com (8.9.3/8.9.3) with ESMTP id IAA12723;
Mon, 14 Jun 1999 08:54:02 -0500 (CDT)
Received: from artemis (artemis.globeset.com [10.1.192.11])
by earth.globeset.com (8.9.3/8.9.3) with SMTP id IAA09455;
Mon, 14 Jun 1999 08:54:01 -0500 (CDT)
Reply-To: rdbrown@globeset.com
MMDF-Warning: Parse error in original version of preceding line at one.eListX.com
From: "Richard D. Brown"
To: "'Zia Khan'" , ietf-trade@elistx.com
MMDF-Warning: Parse error in original version of preceding line at one.eListX.com
Subject: RE: Electronic Commerce Modeling Language (ECML)?
Date: Mon, 14 Jun 1999 08:52:19 -0500
Message-ID: <005001beb66d$1f26a770$0bc0010a@artemis.globeset.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <001f01beb476$707b1e10$20330118@C980732-D.frmt1.sfba.home.com>
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Content-Transfer-Encoding: 7bit
Zia,
You can find more information about ECML at http://www.ecml.org.
As you will notice, ECML consists before all of normalizing a set of
attribute names that could be recognized and automatically populated by a
user agent upon receipt of a form. On the other hand, IOTP defines a
protocol for negotiation, payment, and delivery between a merchant and a
buyer agent.
Sincerely,
Richard D. Brown
Software Architect, R&D
GlobeSet, Inc. Austin, TX - U.S.
> -----Original Message-----
> From: ietf-trade-owner@lists.eListX.com
> [mailto:ietf-trade-owner@lists.eListX.com]On Behalf Of Zia Khan
> Sent: Friday, June 11, 1999 8:54 PM
> To: ietf-trade@elistx.com
> Subject: Electronic Commerce Modeling Language (ECML)?
>
>
> Does any body have details on this announcement:
>
> http://www.news.com/News/Item/0,4,37712,00.html?st.ne.fd.gif.k
>
> What are the differences between ECML and IOTP?
> --------------------------------------------------------------------
> Zia Khan, Member LiveBiz Team
> Xenosys Corporation, 258 Java Drive, Sunnyvale, CA 94089
> Phone: 408.744.0309 Fax: 408.744.9007
> e-mail: zia@xenosys.com WWW: http://www.livebiz.com
> Developers of LiveBusiness Foundation Classes for Java
> --------------------------------------------------------------
> ------
>
> --------------------------------------------------------------
> ---------
> Message addressed to: ietf-trade@lists.elistx.com
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or
> "unsubscribe" in the
> body to: ietf-trade-request@lists.elistx.com
>
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Mon Jun 14 23:40:28 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29287
for ; Mon, 14 Jun 1999 23:40:26 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa00818; 14 Jun 99 23:12 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa00791;
14 Jun 99 23:11 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_3765_c3a9_ea6c;
Tue, 15 Jun 1999 04:08:25 +0100
Message-Id:
From: David Burdett
To: Ietf Trade WG ,
Masaaki Hiroya
Subject: RE: Error Handling
Date: Tue, 15 Jun 1999 04:10:44 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01BEB6DC.AB3FD460"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01BEB6DC.AB3FD460
Content-Type: text/plain;
charset="iso-8859-1"
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
<> <>
> ----------
> From: David Burdett[SMTP:David.Burdett@mondex.com]
> Sent: 31 May 1999 21:01
> To: Ietf Trade WG; Masaaki Hiroya
> Subject: RE: Error Handling
>
> 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:hiroya@sdl.hitachi.co.jp]
> > 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:David.Burdett@mondex.com]
> > > > > Sent: 25 May 1999 14:05
> > > > > To: Ietf Trade WG; hiroya@sdl.hitachi.co.jp
> > > > > 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:hiroya@sdl.hitachi.co.jp]
> > > > > > Reply To: hiroya@sdl.hitachi.co.jp
> > > > > > Sent: 23 May 1999 00:59
> > > > > > To: ietf-trade@elistx.com
> > > > > > 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 ...
> > > > >
> > > > > > > > > PaymentNote?, TradingRoleData*) >
> > > > >
> > > > > ... to ...
> > > > >
> > > > > > > > > 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: hiroya@sdl.hitachi.co.jp
> > > > > >
> > --------------------------------------------------------------------
> > ---
> > > > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > > To (un)subscribe send a message with "subscribe" or
> "unsubscribe"
> > in
> > the
> > > > > > body to: ietf-trade-request@lists.elistx.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
> > us
> > ing
> > > > > email
> > > > > address postmaster@mondex.com 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: postmaster@mondex.com
> > > > > WebSite: http://www.mondexinternational.com
> > > > >
> > > > >
> > **********************************************************************
> > ****
> > > > > *******************
> > > > >
> > -----------------------------------------------------------------------
> > > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> > the
> > > > > body to: ietf-trade-request@lists.elistx.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
> > usin
> > g email
> > > > address postmaster@mondex.com 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: postmaster@mondex.com
> > > > WebSite: http://www.mondexinternational.com
> > > >
> > > >
> > ************************************************************************
> > ****
> > > > *****************
> > > >
> > -----------------------------------------------------------------------
> > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > > body to: ietf-trade-request@lists.elistx.com
> > > >
> > > -----
> > > Masaaki Hiroya
> > > Systems Development Laboratory
> > > Hitachi, Ltd.
> > > tel: +81-44-959-0874
> > > fax: +81-44-959-0856
> > > email: hiroya@sdl.hitachi.co.jp
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: ietf-trade@lists.elistx.com
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: ietf-trade-request@lists.elistx.com
> > >
> > -----
> > Masaaki Hiroya
> > Systems Development Laboratory
> > Hitachi, Ltd.
> > email: hiroya@sdl.hitachi.co.jp
> > tel: +81-44-966-9111(ext.3552)
> > fax: +81-44-966-1796
> > -----------------------------------------------------------------------
> > Message addressed to: ietf-trade@lists.elistx.com
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
> WebSite: http://www.mondexinternational.com
>
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: ietf-trade@lists.elistx.com
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
------_=_NextPart_000_01BEB6DC.AB3FD460
Content-Type: text/plain;
name="ServerLogic.txt"
Content-Disposition: attachment;
filename="ServerLogic.txt"
Content-Transfer-Encoding: quoted-printable
/*
This file contains the logic required by an IOTP server. Specifically a =
server that supports one or more of the Merchant, Payment Handler or =
Delivery Handler Roles. Much of the logic is common to all the roles =
including:
- handling or generating Ping, Inquiry and Authentication Requests
- idempotency and duplicate message handling.
- checking the standard parts of messages
- generating output messages
- etc.
Where logic only applies to a specific role this is identified.
Developed by David Burdett. Mondex International. June 1999
*/
/**********************************************************************
TOP LEVEL SERVER PROCESSING
**********************************************************************/
IotpServer
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* The top level IotpServer processes are triggered by other processes =
or servers external to the IotpServer. The top level processes are:
- start a Ping Transaction
- start an Inquiry Transaction
- start an Authentication Transaction
- start a Purchase/Refund/Withdrawal/Deposit/ValueExchange - Merchant =
Role only
- process an input message that has been received from another role, =
and
- check for timeouts on IotpTransactions where no response has been =
received.
*/
Case ProcessType
CaseEntry StartPingTransaction
Do StartPingTransaction
CaseEntry StartInquiryTransaction
Do StartInquiryTransaction
CaseEntry StartAuthenticationTransaction
Do StartAuthenticationTransaction
CaseEntry NewIotpTransaction
Do StartNewPayRelatedTransaction
CaseEntry InputMessage
Do ProcessInputMessage
CaseEntry Timeout
Do CheckForTimeouts
EndCase
=0C/********************************************************************=
**
INPUT MESSAGE PROCESSING
**********************************************************************/
ProcessInputMessage
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* This processes an IOTP input message received from another role. It =
handles duplicate messages and servers too busy to process an incoming =
message. The process should be single threaded to avoid starting =
unecessary threads when two or more identical messages arrive in quick =
sucession. If a non-duplicate input message is found then it is =
processed.*/
Check that the input message is is well formedXML
If it is well formed then
Attempt to extract the IotpTransId from the Input Message
If the IotpTransId can be extracted then
If Transaction Recognised then
/* IotpTransId was either sent in an earlier output message or =
received in an earlier input message */
Check if "Identical" input message for IotpTransId has been received =
before
/* all blocks, components, elements, attribute values and element =
content are the same*/
If Identical input message received before then
Set DuplicateMessage to true
Check processing state of previous identical input message
If ProcessState of InputMessage is InProgress then
/* Do nothing as previous identical message curently being =
processed will produce response if any */
Else /* resend message previously sent */
If previous input message resulted in an output message then
Retrieve stored output message resulting from earlier identical =
input message
Do SendPhysicalOutputMessage
EndIf
Endif
Else /* Message not received before */
Set DuplicateMessage to false
Endif
Else /* New IotpTransId */
Set InputMessage DocExchStatus to: StatusType - Undefined, =
ProcessState - NotYetStarted
/* The InputMessage DocExchStatus is used to record the progress =
and/or completion of Input Messages that contain an IotpTransId that =
has not been received before. This status is used to generate Status =
Components when the document exchange completes of if there is a =
Transaction Inquiry. */
Set DuplicateMessage to false
End If
If DuplicateMessage is false then
If Processes that handle input messages are too busy to accept =
another message, then
Generate Error Component with Transient Error
Do SendOutputMessage
Else
If previous messages did not contain or result in Hard Errors and =
the Transaction has not been cancelled by either the Consumer or the =
Trading Role
Save Input Message /*Only save input messages if they are going to =
be processed */
Set ProcessState of InputMessage to InProgress
Do ProcessNonDuplicateInputMessage
Set ProcessState of InputMessage to CompletedOk
EndIf
EndIf
EndIf
Else /* can't extract IotpTransId */
Do GenerateTransactionIdComponent
Generate Error Component with Severity - HardError and ErrorCode - =
AttMissing
Do SendOutputMessage
EndIf
Else /* Xml not well formed */
Do GenerateTransactionIdComponent
Generate Error Component with Severity - HardError and ErrorCode - =
XmlNotWellFrmd
Place Input Message in Packaged Content of ErrorComponent
Do SendOutputMessage
EndIf
ProcessNonDuplicateInputMessage
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
/* Process an input message that is an original or a resend after a =
transient error */
Do ValidateInputMessage
If TransientErrors then
Generate Error Component with Transient Error
Delete Saved Input Message
Do SendOutputMessage
Else
If No HardErrors in Input Message then /* Warnings are OK */
If Input Message contains an Error Block with at least one Error =
Component with Severity of HardError then
Do HardErrorInInputMessage
ElseIf Input Message contains a Cancel Block
Do CancelTransaction
ElseIf Input message contains Ping Request Block
Set ProcessState to InProgress
Do ProcessPingRequestBlock
ElseIf Input message contains Ping Response Block
Do ProcessPingResponseBlock
ElseIf Input message contains Inquiry Request Block
Set ProcessState to InProgress
Do ProcessInquiryRequestBlock
ElseIf Input message contains Inquiry ResponseBlock
Do ProcessInquiryResponseBlock
ElseIf Input Message contains Authentication Request Block
Set ProcessState to InProgress
Do ProcessAuthenticationRequestBlock
ElseIf Input message contains Authentication Response Block /* =
Merchant Role Only */
Do ProcessAuthenticationResponseBlock
ElseIf Input Message contains Authentication Status Block
Do ProcessAuthenticationStatusBlock
ElseIf Input message contains TPOSelection Block /* Merchant Role =
Only */
Do ProcessTpoSelectionBlock
ElseIf Input message contains a Payment Request Block /* Payment =
Handler Role Only */
Set ProcessState to InProgress
Do ProcessPaymentRequest
ElseIf Input message contains a Payment Exchange Block /* Payment =
Handler Role Only */
Do ProcessPaymentExchange
ElseIf Input message contains a DeliveryRequest /* Delivery Handler =
Role only /*
Set ProcessState to InProgress
Do ProcessDeliveryRequest
EndIf
Else /* Input message contains hard errors */
Generate Error Block
Set DocExchStatus to: StatusType - Undefined, ProcessState =3D =
Failed, Completion Code =3D InMsgHardError
/* There is potentially a different DocExchStatus for each =
IotpTransId and StatusType
Do SendOutputMessage
EndIf
EndIf
/**********************************************************************
RETRY/TIMEOUT HANDLING
**********************************************************************/
CheckForTimeouts
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* This process checks for transactions where no response has been =
received and either re-sends the last message or sets the Document =
Exchange Stateus to Failed with a timeout. The process should be =
started periodically at a suitable time interval. */
While DocumentExchanges Exist where
- the ProcessState is InProgress and
- the time by which a response should have been received has passed =
then
If the Maximum RetryCount is not yet reached then
Retrieve the last message sent
Resend the output message
Increment the retry count
Else /* the no of retries limit has been reached */
Set DocExchStatus to ProcessState - Failed, Completion Code - =
TimedOut - NEW Completion Code
Endif
Wend
=0C/********************************************************************=
**
INPUT MESSAGE VALIDATION
**********************************************************************/
ValidateInputMessage
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Do CheckForMessageLevelErrors
Save any Error Components for inclusion in Output Message
If No HardErrors then
Do CheckForBlockLevelErrors
Save any Error Components for inclusion in Output Message
If No HardErrors then
If encapsulated protocol message then
Do CheckEncapsulatedMessage /* May generate transient errors */
Save any Error Components for inclusion in Output Message
Endif
Do CheckMessageBlockSequenceErrors
Endif
EndIf
CheckForMessageLevelErrors
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Check the XML is valid
Check Elements and Content of the TransRefBlock
If a Signature Block is present
Check the Digital Signature. This includes:
- checking that the signature value is correctly calculated
- checking that the hash values in the digest are correctly calculated =
where possible
Endif
Generate Error Components for any problems found
CheckForBlockLevelErrors
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
For each block:
- check the attributes and element content contain valid values
- check the attributes and elements are consistent within the block
Check the combination of blocks are valid
Check the attrbutes and elements are consistent between blocks
/* Note. The above check includes checking that the presence of a block =
is valid for a particular transaction type */
If a digital signature is present then
Check that the correct blocks have been signed /* transaction and =
message dependent */
EndIf
Generate Error Components for any problems found
CheckEncapsulatedMessage
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
/*May generate additional transient errors because server processing =
encapsulated message (e.g. a payment server) is busy */
If possible for the type of encapsulated message, check that the =
encapsulated message is valid
If a separate server is used to validate the Encapsulated message and =
it's too busy, then generate a Transient Error
CheckMessageBlockSequenceErrors
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
/* Check that the blocks in the message are valid at this point in a =
transaction (transaction dependent) */
If Input Message contains an Error Block then
If ErrorBlocks have not been received from the same sender for the =
same IotpTransaction before then
/* The above check should stop looping caused by finding errors in =
error blocks */
If the Error Block doesn't refer to a message that was previously =
sent to the sender of the Input message then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D ElUnexpected
- ErrorLocation component that points to the Error Block in the =
Input Message, and
- Error Description that says "Reported Error refers to a message =
that this server did not send to you"
EndIf
EndIf
EndIf
If Input Message contains a Cancel Block
If a Cancel block not been received from the same sender for the same =
IotpTransaction before then
If the Cancel Block doesn't refer to an Iotp Transaction where the =
sender has been sent messages before then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D ElUnexpected
- ErrorLocation component that points to the Cancel Block in the =
Input Message, and
- Error Description that says "Transaction cancellation refers to a =
transaction not known to this server."
EndIf
EndIf
ElseIf Input message contains an Inquiry Request Block or an Inquiry =
Response Block then
If the Inquiry Request or Inquiry Response doesn't refer to an =
IotpTransaction that is recognised by the Iotp Server then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D AttValNotRecog
- ErrorLocation component that points to the IotpTransId Attribute, =
and
- Error Description that says "Transaction inquiry refers to a =
transaction not known to this server."
EndIf
ElseIf Input Message contains Authentication Request Block
If the Authentication Request Block refers to a transaction that is =
recognised by the Iotp Server then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D AttValIllegal
- ErrorLocation component that points to the IotpTransId Attribute, =
and
- Error Description that says "Authentication request with this =
transaction reference is illegal."
EndIf
ElseIf Input message contains Authentication Response Block /* Merchant =
Role Only */
If the Authentication Response doesn't refer to an IotpTransaction =
that is recognised by the Iotp Server then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D AttValNotRecog
- ErrorLocation component that points to the IotpTransId Attribute, =
and
- Error Description that says "Authentication Response refers to a =
transaction not known to this server."
ElseIf the Authentication Response doesn't refer to an IotpTransaction =
where an Authentication Request had previously been sent then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D ElUnexpected
- ErrorLocation component that points to the Authentication Response =
element, and
- Error Description that says "Message Sequence Error:Authentication =
Response unexpectedly."
ElseIf an Authentication Response for the same IotpTransaction had =
been received before then
If the previous AuthenticationResponse resulted in a successful =
authentication then
Generate an ErrorComponent with
- Severity =3D Warning,
- Error Code =3D ElUnexpected
- ErrorLocation component that points to the Authentication Response =
element, and
- Error Description that says "Duplicate: Successful Authentication =
Response received before."
EndIf
EndIf
ElseIf Input Message contains Authentication Status Block
If the Authentication Status doesn't refer to an IotpTransaction that =
is recognised by the Iotp Server then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D AttValNotRecog
- ErrorLocation component that points to the IotpTransId Attribute, =
and
- Error Description that says "Authentication Status refers to a =
transaction not known to this server."
ElseIf the Authentication Status doesn't refer to an IotpTransaction =
where an Authentication Response had previously been sent then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D ElUnexpected
- ErrorLocation component that points to the Authentication Status =
element, and
- Error Description that says "Message Sequence Error: Authentication =
Status received unexpectedly."
ElseIf an Authentication Status for the same IotpTransaction had been =
received before then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D ElUnexpected
- ErrorLocation component that points to the Authentication Status =
element, and
- Error Description that says "Duplicate: Successful Authentication =
Status received before."
EndIf
ElseIf Input message contains TPOSelection Block /* Merchant Role Only =
*/
If the TPO Selection Block doesn't refer to an IotpTransaction that is =
recognised by the Iotp Server then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D AttValNotRecog
- ErrorLocation component that points to the IotpTransId Attribute, =
and
- Error Description that says "TPO Selection Block refers to a =
transaction not known to this server."
ElseIf the TPO Selection Block refers to an IotpTransaction where a =
TPO Block and OfferResponse had previously been sent then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D ElUnexpected
- ErrorLocation component that points to the TPO Selection block, and
- Error Description that says "Message Sequence Error: TPO Selection =
Block received unexpectedly."
ElseIf the TPO Selection Block doesn't refer to an IotpTransaction =
where a TPO Block only (i.e. without an Offer Response) had previously =
been sent then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D ElUnexpected
- ErrorLocation component that points to the TPO Selection block, and
- Error Description that says "Message Sequence Error: TPO Selection =
Block received unexpectedly."
ElseIf a TPO Selection Block for the same TPO Block has been received =
before then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D ElUnexpected
- ErrorLocation component that points to the TPO Selection block, and
- Error Description that says "Duplicate: TPO Selection Block =
received before."
EndIf
ElseIf Input message contains a Payment Request Block /* Payment =
Handler Role Only */
If the Payment Request Block refers to an IotpTransaction that is =
recognised by the Iotp Server then
If the Payment Request Block refers to IotpTransaction that was not =
for a Payment then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D AttValNotRecog
- ErrorLocation component that points to the IotpTransId Attribute, =
and
- Error Description that says "Payment request refers to a =
transaction not known to this server."
ElseIf the previous payment CompletedOk OR failed with a =
non-recoverable Completion Code then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D ElUnexpected
- ErrorLocation component that points to the PaymentRequest, and
- Error Description that says "Message Sequence Error: Payment =
Request received unexpectedly"
ElseIf the previous payment is still in progress then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D ElUnexpected
- ErrorLocation component that points to the PaymentRequest, and
- Error Description that says "Duplicate: Payment Request received =
before."
EndIf
EndIf
ElseIf Input message contains a Payment Exchange Block /* Payment =
Handler Role Only */
If the Payment Exchange Block doesn't refer to an IotpTransaction that =
is recognised by the Iotp Server then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D AttValNotRecog
- ErrorLocation component that points to the IotpTransId Attribute, =
and
- Error Description that says "Payment Exchange refers to a =
transaction not known to this server."
ElseIf the Payment Exchange doesn't refer to an IotpTransaction where =
a Payment Exchange had previously been sent then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D ElUnexpected
- ErrorLocation component that points to the Payment Exchange Block =
element, and
- Error Description that says "Message Sequence Error: Payment =
Exchange received unexpectedly."
EndIf
ElseIf Input message contains a DeliveryRequest /* Delivery Handler =
Role only /*
If the Delivery Request Block refers to an IotpTransaction that is =
recognised by the Iotp Server then
Generate an ErrorComponent with
- Severity =3D HardError,
- Error Code =3D AttValNotRecog
- ErrorLocation component that points to the IotpTransId Attribute, =
and
- Error Description that says "Duplicate:Delivery Request received =
before."
EndIf
ElseIf Input message contains a Ping Request Block or a Ping Response =
Block then
Do nothing. No checks required, Ping requests and responses are valid =
at any time.
EndIf
HardErrorInInputMessage
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* A hard error indicates sender found fatal errors in message =
previously sent */
Set ProcessState/CompletionCode of Current Document Exchange =
(Authentication, Offer, Payment or Delivery) to Failed/ConsGenError - =
NEW Consumer Generated Error Condition
Log HardErrorMessage for later consideration
CancelTransaction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* A cancel block indicates sender no longer wants to continue with the =
document exchange */
Set ProcessState/CompletionCode of Current Document Exchange to =
Failed/ConsCancelled
Log Cancelling of the Transaction
=0C/********************************************************************=
**
INQUIRY TRANSACTION
**********************************************************************/
StartInquiryTransaction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* This process enables an Iotp Server to start an Inquiry. It may be =
used, for example, to inquire on another Iotp Server, for example a =
Merchant Server could Inquire on a Payment Handler or Delivery Handler =
and vice versa. Iotp Servers may also inquire upon Consumers.*/
Retrieve information about the IotpTransaction and Process (Offer, =
Payment, etc) that is being inquired about
Depending on the type of the inquiry also retrieve any encapsulated =
message /* e.g. a payment message */
Generate Inquiry Request Block
If digital signature required then
Identify blocks/components to be digitally signed
Identify the signature algorithm and certificate to be used
EndIf
Set DocExchStatus to: StatusType - Inquiry, ProcessState - InProgress
Do SendOutputMessage
ProcessInquiryRequestBlock
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
/* 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
/* Do nothing - ignore as Inquiries on Ping Transactions aren't useful =
*/
Set InputMessage DocExchStatus to: StatusType - Inquiry, ProcessState =
- IllegalReq
Else
Set InputMessage DocExchStatus for Inquiry to: StatusType - Inquiry, =
ProcessState - InProgress
Check if the sender of the inquiry request is allowed to make =
inquiries
/* For example a Merchant should only be able to inquire upon Payments =
for which the Merchant had made an offer. The exact rules of what =
quesries are allowed is dependent on the privacy policies of the =
IotpServer owner or operator. Signatures can be used to test the =
authenticity of inquiries if they are present. */
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
Else /* No technical errors in original transaction */
Generate Status component and Inquiry Response block from =
information on original Document Exchange
Save Inquiry Response Block for inclusion in output message
Endif
Set InputMessage DocExchStatus to: StatusType - Inquiry, ProcessState =
- CompletedOk
Else
Generate Status component with ProcessState of Failed and =
CompletionCode of UnAuthReq - NEW completion code
Include generated Status Component in Inquiry Response block
Save Inquiry Response Block for inclusion in output message
Set InputMessage DocExchStatus to: StatusType - Inquiry, ProcessState =
- UnAuthReq
Endif
Do SendOutputMessage
Endif
ProcessInquiryResponseBlock
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
/* This process handles the response generated as a result of an =
Inquiry Request sent by the IotpServer to another role. See =
StartInquiryTransaction. */
Use information in the Inquiry Response Block to update status =
information about the transaction
Set DocExchStatus to: StatusType - Inquiry, ProcessState - CompletedOk
=0C/********************************************************************=
**
PING TRANSACTION/MESSAGES
**********************************************************************/
StartPingTransaction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* This process starts a Ping Transaction where the Iotp Server sends a =
Ping Request to another trading role.*/
Do GenerateTransactionIdComponent
Generate other blocks/components required /* i.e. Ping Request Block */
If digital signature required then
Identify blocks/components to be digitally signed
Identify the signature algorithm and certificate to be used
EndIf
Set DocExchStatus of Ping Transaction to: StatusType - Ping, =
ProcessState - InProgress
Do SendOutputMessage
ProcessPingRequestBlock
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* This process responds to a PingRequest sent to the IotpServer by =
another trading role. */
/* The process that handles PingRequests should ideally operate in a =
separate IotpServer to the IotpServer that handles the processing of =
other Input Messages. Otherwise, the "Ping" Server will not be able to =
report that the main IotpServer is down or busy. */
Generate a Ping Response Block
Set Input Message DocExchStatus of Ping Transaction to: StatusType - =
Ping, ProcessState - InProgress
If a digital signature is present in the Input Message then
Identify blocks/components to be digitally signed
Identify the signature algorithm and certificate to be used
/* For example, if the sender of the PingRequest is recognised by the =
receiver then whatever signature algorithm and certificate have been =
agreed should be used. If the sender is not recognised then a signature =
based on a PKI infrastructure is likely to be appropriate, where it =
likely that the receiver of the PingResponse will be able to check the =
signature. */
Endif
Do SendOutputMessage
Set Input Message DocExchStatus of Ping Transaction to: StatusType - =
Ping, ProcessState - CompletedOk
ProcessPingResponseBlock
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
/* This process handles the response generated as a result of a Ping =
Request sent by the IotpServer to another role. See =
StartPingTransaction. */
Use information in the Ping Response Block to update status information =
about the transaction.
Set DocExchStatus to: StatusType - Ping, ProcessState - CompletedOk
=0C/********************************************************************=
**
AUTHENTICATION TRANSACTION/MESSAGES
**********************************************************************/
StartAuthenticationTransaction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
/* This process starts an Authentication Transaction where the Iotp =
Server sends an Authentication Request to another trading role. For =
eample a Merchant could send an Authentication Request to a Consumer. =
*/
Do GenerateTransactionIdComponent
Do GenerateProtocolOptionsComponent /* For Authentication */
Do GenerateOrganisationComponent /* Authenticator */
Do GenerateTpoBlock /* For Authentication */
Create a TPO Block from the components
Save TpoBlock and AuthenticationRequestBlock for inclusion in =
OutputMessage
If digital signature required on AuthenticationRequestBlock then
Identify blocks/components to be digitally signed
Identify the signature algorithm and certificate to be used
EndIf
Set Authentication DocExchStatus to: StatusType - Authentication, =
ProcessState - InProgress
Do SendOutputMessage
ProcessAuthenticationRequestBlock
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* This process handles an AuthenticationRequest sent to the IotpServer =
by another trading role. */
Set Input Message DocExchStatus to: StatusType - Authentication, =
ProcessState - InProgress
Check Credentials (Organisation Components and signature (if present)) =
to determine if Authenticator is acceptable
If Credentials are OK then /* Normal behaviour for an Iotp Server is to =
accept authentication by anyone */
If TradingRoleInfo Request is present then
If TradingRoleList attribute contains Trading Roles that can be =
responded to then
Generate Org Components for requested trading roles
Else
Set Input Message DocExchStatus to: StatusType - Authentication, =
ProcessState - Failed, CompletionCode - TradeRolesIncon
Generate Status Component and Cancel Block
Save Cancel Block for inclusion in Output Message
EndIf
EndIf
If Cancel Block not generated then
If Authentication Request Block present then
Select the authentication algorithm to use
If no usable authentication algorithm then
Set Input Message DocExchStatus to: StatusType - Authentication, =
ProcessState - Failed, CompletionCode - NoAuthReq
Generate Status Component and Cancel Block
Save Cancel Block for inclusion in Output Message
Else
Generate an Authentication Response Component
If selected Authentication algorithm involves digital signatures =
then
Identify blocks/components to be digitally signed
Identify the signature algorithm and certificate to be used
EndIf
EndIf
EndIf
EndIf
If Organisation Components or Authentication Response Components =
generated then
Generate Authentication Response Block
Save Authentication Response Block for inclusion in output message
EndIf
Else /* Credentials not OK */
Set Input Message DocExchStatus to: StatusType - Authentication, =
ProcessState - Failed, CompletionCode - AutEeCancel
Generate Status Component and Cancel Block
Save Cancel Block for inclusion in Output Message
EndIf
Do SendOutputMessage
ProcessAuthenticationResponseBlock
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* This process handles the response generated as a result of an =
Authentication Request sent by the IotpServer to another role. See =
StartAuthenticationTransaction. */
Check the Authentication Response Block against the information sent in =
the Authentication Request Block
If Authenticator declines to proceed further with the Authentication =
then
Set Authentication DocExchStatus to: StatusType - Authentication, =
ProcessState - Failed, CompletionCode - AutOrCancel
Do GenerateAuthenticationStatusBlock
Else
If Authentication Response Block is OK then
Set Authentication DocExchStatus to: StatusType - Authentication, =
ProcessState - CompletedOk
Do GenerateAuthenticationStatusBlock
If the Authentication Response is part of a =
Purchase/Refund/Withdrawal/Deposit/Value Exchange then
Set Offer DocExchStatus to: StatusType - Offer, ProcessState - =
InProgress
Do GenerateOfferTpoBlock
Save TPO Block for inclusion in OutputMessage
If the Authentication Response is part of a Brand Independent Offer =
Exchange then
Do GenerateOfferResponseBlock
EndIf
EndIf
Else /* Authentication Failed */
Set Authentication DocExchStatus to: StatusType - Authentication, =
ProcessState - Failed, CompletionCode - AuthFailed
Generate a Status Component and Authentication Response Block
Save AuthenticationResponseBlock for inclusion in OutputMessage
EndIf
EndIf
Do SendOutputMessage
ProcessAuthenticationStatusBlock
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
/* This process handles an Authentication Status block received after =
sending an Authentication Response to another Trading Role */
/* Note that for a server role, an Authentication Status Block only =
occurs as part of an Authentication Transaction. Therefore there is no =
follow on procesing */
Set Input Message DocExchStatus to ProcessState contained in Status =
Component in Authentication Status Block in Input Message
GenerateAuthenticationStatusBlock
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* Common process to generate an Authentication Status Block */
Generate a Status Component from the Authentication DocExchStatus
Generate an Authentication Status Block
Save AuthenticationStatusBlock for inclusion in Output Message
If an Authentication Status Signature is required then
Identify blocks/components to be digitally signed
Identify the signature algorithm and certificate to be used
EndIf
=0C/********************************************************************=
**
START PAYMENT RELATED TRANSACTIONS/MESSAGES
**********************************************************************/
StartNewPayRelatedTransaction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
/* This process starts a =
Purchase/Refund/Withdrawal/Deposit/ValueExchange. Applies to Merchant =
Role only */
Do GenerateTransactionIdComponent
Do GenerateOfferTpoBlock
If a Brand Independent Payment then
Do GenerateOfferResponseBlock
EndIf
Set DocExchStatus of Pay Related transaction to: StatusType - Offer, =
ProcessState - InProgress
Do SendOutputMessage
/**********************************************************************
OFFER MESSAGES
**********************************************************************/
/* The Offer Messages apply to the Merchant Trading Role only */
GenerateOfferTpoBlock
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* Generates a TPO Block for inclusion in an Offer Response */
Do GenerateProtocolOptionsComponent
Do GenerateOrganisationComponent(s) /* Merchant, Consumer, DelivTo?, =
PaymentHandler+, DeliveryHandler? */
Do GenerateBrandList
Create a TPO Block from the components
Save TPO Block for inclusion in OutputMessage
If digital signature required then
Identify blocks/components to be digitally signed
Identify the signature algorithm and certificate to be used
EndIf
GenerateOfferResponseBlock
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Do GenerateOrderDescriptionComponent
Do GeneratePaymentComponent(s) /* One or two depending on the =
Transaction */
Do GenerateDeliveryComponent /* If required */
Create an Offer Response Block from the components
Save OfferResponseBlock for inclusion in OutputMessage
If an Offer Response Signature is required then
Identify blocks/components to be digitally signed
Identify the signature algorithm and certificate to be used
EndIf
ProcessTpoSelectionBlock
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Check the TpoSelectionBlock
If Merchant decides to cancel the transaction then
Generate a Status Component and CancelBlock
Save Cancel Block for inclusion in output message
Else
Do GenerateOfferResponseBlock
EndIf
Do SendOutputMessage
=0C/********************************************************************=
**
PAYMENT MESSAGES
**********************************************************************/
/* The Payment Messages apply to the Payment Handler Trading Role only =
*/
/* The descriptions in this section should be read in conjunction with =
the "Payment API Calls" section of the IOTP Supplement titled
"Architecture and Payment API" */
ProcessPaymentRequest
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* This process handles a payment request sent by a Consumer role to =
the Payment Handler */
Set Payment DocExchStatus StatusType - Payment, ProcessState - =
InProgress
Check that Payment Request is correctly authorised by a Merchant (and =
optionally another payment handler for Value Exchange transctions) that =
are recognised by the Payment Handler by checking the credentials of =
the merchant specifically the Organisation component and Offer Response =
signature
If Credentials are OK then
Determine the Brand and Payment Protocol to use
Call the appropriate payment software to "Start the Payment at the =
Payment Handler" passing the appropriate payment/brand/protocol =
information as specified in the payment supplement
If the call to the payment software completed OK then
If there are PaymentSchemePackagedContent elements to be sent to the =
consumer, then
Do GeneratePaymentSchemeComponent
EndIf
If the continuation status is set to continue then
Do GeneratePaymentExchangeBlock
Save Payment Exchange Block for inclusion in Output Message
Else /* continuation status is set to 'end' */
Do GeneratePaymentStatusComponent
If Payment Receipt required then
Do GeneratePaymentReceiptComponent /* See "Inquire Process State" =
*/
EndIf
If Payment Note required then
Do GeneratePaymentNote
EndIf
If Trading Role Data Required then
Do GenerateTradingRoleDataComponent
EndIf
Do GeneratePaymentResponseBlock
Save Payment Response Block for inclusion in Output Message
Set Payment DocExchStatus StatusType - Payment, ProcessState to an =
appropriate completion state that corresponds with the completion state =
of the payment software
EndIf
Else /* Payment Software generated an error */
Generate an Error Component with ProcessState - HardError, =
CompletionCode - EncapProtErr
Set Payment DocExchStatus StatusType - Payment, ProcessState - Failed
EndIf
Else /* Credentials not OK */
Set Payment DocExchStatus to: StatusType - Payment, ProcessState - =
Failed, CompletionCode - PaymtCancelled
Generate Status Component and Cancel Block
Save Cancel Block for inclusion in Output Message
EndIf
Do SendOutputMessage
ProcessPaymentExchange
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* This process handles a payment exchange message sent by a Consumer =
role to the Payment Handler */
Set Payment DocExchStatus StatusType - Payment, ProcessState - =
InProgress
Call the appropriate payment software to "Continue the Payment Process" =
passing the appropriate specific information contained in the package =
content of the payment scheme component
If the call to the payment software completed OK then
If there are PaymentSchemePackagedContent elements to be sent to the =
consumer, then
Do GeneratePaymentSchemeComponent
EndIf
If the continuation status is set to continue then
Do GeneratePaymentExchangeBlock
Save Payment Exchange Block for inclusion in Output Message
Else /* continuation status is set to 'end' */
Do GeneratePaymentStatusComponent
If Payment Receipt required then
Do GeneratePaymentReceiptComponent
EndIf
If Payment Note required then
Do GeneratePaymentNote
EndIf
If Trading Role Data Required then
Do GenerateTradingRoleDataComponent
EndIf
Do GeneratePaymentResponseBlock
Save Payment Response Block for inclusion in Output Message
EndIf
Set Payment DocExchStatus StatusType - Payment, ProcessState - Failed
Else /* Payment Software generated an error */
Generate an Error Component with ProcessState - HardError, =
CompletionCode - EncapProtErr
Set Payment DocExchStatus StatusType - Payment, ProcessState - Failed
EndIf
Do SendOutputMessage
=0C/********************************************************************=
**
DELIVERY MESSAGES
**********************************************************************/
/* The Delivery Messages apply to the Delivery Handler Trading Role =
only */
ProcessDeliveryRequest
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
/* This process handles a delivery request sent by a Consumer role to =
the Delveriy Handler */
Set Delivery DocExchStatus StatusType - Delivery, ProcessState - =
InProgress
Check that Delivery Request is correctly authorised by a Merchant and =
Payment Handler that are recognised by the Delivery Handler by checking =
the credentials of the merchant specifically the Merchant and Payment =
Handler Organisation component, the Offer Response Signature and the =
Payment Response signature
If Credentials are OK then
Generate a Delivery Note Component using the information contained in =
the Order Description, Delivery and Trading Role Data Components
Generate a Delivery Response Block
Set Delivery DocExchStatus StatusType - Delivery, ProcessState - =
whatever state is appropriate depending on the ability to fullfil the =
request
Save the Delivery Response Block for inclusion in Output Message
Else /* Credentials not OK */
Set Delivery DocExchStatus to: StatusType - Delivery, ProcessState - =
Failed, CompletionCode - DelivCancelled
Generate Status Component and Cancel Block
Save Cancel Block for inclusion in Output Message
EndIf
Do SendOutputMessage
=0C/********************************************************************=
**
COMMON PROCESSES
**********************************************************************/
GenerateTpoBlock
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Generate ProtocolOptionsComponent
If transaction is payment related then
Generate Protocol Options Component
EndIf
Generate Organisation Blocks for parties involved in the transaction /* =
Transaction Dependent */
GenerateTransactionIdComponent
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
/* This generation of the IOTP TransId should be single threaded to =
ensure that duplicate IotpTransIds are not generated */
Generate a New TransactionId Component
SendOutputMessage
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Generate New Message Id Component
Generate Transaction Reference Block using saved Transaction Id =
Component
If Error Components have been generated then
Generate an Error Block
EndIf
If any of the Error Components have a ProcessState of Transient Error =
then
Set ProcessState to Failed/TransientError - NEW
Assemble Output Message from stored blocks
Else
Generate Digital Signature blocks from blocks/components that need to =
be signed using identified signature algorithm and certificate
Assemble Output Message from stored blocks
Save output message for later retrieval
EndIf
Do SendPhysicalOutputMessage
SendPhysicalOutputMessage
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
If the transport mechanism for the output message is working then
If a response to the output message is expected then /* Process not =
complete and no fatal errors */
Set time by which response message should be received /* Transport =
and encapsulated protocol dependent*/
Set max retry count
EndIf
Send the generated or retrieved message
Else
Save the generated message for sending later when the transport =
mechanism is working again
EndIf
------_=_NextPart_000_01BEB6DC.AB3FD460
Content-Type: text/plain;
name="Server Role Procecssing.txt"
Content-Disposition: attachment;
filename="Server Role Procecssing.txt"
Content-Transfer-Encoding: quoted-printable
4.5 Server Role Processing Sequence
"Server roles" are any Trading Role which is not the Consumer
role. They are "Server roles" since they typically receive a
request which they must service and then produce a response.
However server roles can also initiate transactions. More
specifically Server Roles must be able to:
. Initiate a transaction. These are be divided into:
- payment related transactions and
- infrastructure transactions
. Accept and process a message received from another role. This
includes:
- identifying if the message belongs to a transaction that has
been received before
- handling duplicate messages
- generating Transient errors if the servers that process the
input message are too busy to handle it
- processing the message if it is error free, authorised and,
if appropriate, producing a response to send back to the
other role
. Re-transmit messages if a response was expected but has not
been received in a reasonable time
More detail is provided below.
4.5.1 Initiating Transactions
Server Roles may initiate a variety of different types of
transaction. Specifically:
. an Inquiry Transaction (see section 9.2.1)
. a Ping Transaction (see section 9.2.2)
. an Authentication Transaction (see section 9.1.6)
. a Payment Related Transaction such as:a Deposit (see section
9.1.7)
- a Purchase (see section 9.1.8)
- a Refund (see section 9.1.9)
- a Withdrawal (see section 9.1.10)
- a Value Exchange (see section 9.1.11)
4.5.2 Processing Input Messages
Processing input messages involves the following:
. checking that the structure and identity of the message
. checking for and handling duplicate messages
. processing non-duplicate original messages which includes:
- checking for errors, then if no errors are found
- processing the message to produce an output message if
appropriate
Each of these is discussed in more detail below.
4.5.2.1 Checking Structure and Message Identity
It is critical to check that the message is "well formed" XML and
that the transaction identifier (IotpTransId attribute on the
TransId Component) within the IOTP message can be successfully
identified since an IotpTransId will be needed to generate a
response.
If the input message is not well formed then generate an Error
Component with a Severity of HardError and ErrorCode of
XmlNotWellFrmd.
If the message is well formed but the IotpTransId cannot be
identified then generate an ErrorComponent with:
. a Severity of HardError and an ErrorCode of AttMissing,
. one PackagedContent containing the original Input Message, and
. the second PackagedContent containing "IotpTransId" - the
missing attribute.
Insert the Error Component inside an Error Block with a new
TransactionId component with a new IotpTransId and return it to
the sender of the original message.
4.5.2.2 Checking/Handling Duplicate Messages
If the input message can be identified as potentially a valid
input message then check to see if an "identical" input message
has been received before. Identical means that all blocks,
components, elements, attribute values and element content in the
input message are the same.
If an identical message has been received before then check to
see if the processing of the previous message has completed.
If processing has not completed then do nothing as the processing
of the previous message will result in a response if required.
Otherwise, if processing has completed and resulted in an output
message then retrieve the last message that was sent and send it
again.
If the message is not a duplicate then it should be processed.
4.5.2.3 Processing Non-Duplicate Message
Once it's been established that the message is not a duplicate,
then it can be processed. This involves:
. checking that a server is available to handle the message,
generating a Transient Error if it is not
. checking the Transaction is Not Already in error or cancelled
. validating the input message. This includes:
- checking for message level errors
- checking for block level errors
- checking any encapsulated data
- checking for errors in the sequence that blocks have been
received
. generating error components for any errors that result
. if no hard errors result, then processing the message and
generating an output message, if required, for return to the
sender of the Input Message
[Note] This approach to handling of duplicate input messages
means, if absolutely "Identical" messages are
received then absolutely "identical" messages are
returned. This also applies to Inquiry and Ping
transactions when in reality the state of a
transaction or the processing ability of the servers
may have changed. If up-to-date status of
transactions or servers is required, then an IOTP
transaction with a new IotpTransId must be used.
[Note End]
Each of the above steps is discussed below.
Checking a Server is Available
The process that is handling the input message should check that
the rest of the system is not so busy that a response in a
reasonable time cannot be produced.
If the server is too busy, then it should generate an Error
Component with a transient error and send it back to the sender
of the Input Message requesting that the original message be
resent after an appropriate period of time.
[Note] Some servers may occasionally become very busy due to
unexpected increases in workload. This approach
allows short peaks in workloads to be handled by
delaying the input of messages by asking the sender
of the message to resubmit later.
[Note End]
Checking the Transaction is Not Already in Error or Cancelled
Check that:
. previous messages received or sent did not contain or result in
Hard Errors, and
. the Transaction has not been cancelled by either the Consumer
or the Server Trading Role
If it has then, ignore the message. A transaction with hard
errors or that has been cancelled, cannot be restarted.
Validating the Input Message
If the transaction is still OK then check for message level
errors. This involves:
. checking the XML is valid
. checking that the Elements, attributes and content of the
Transaction Reference Block are without errors and conform to
this specification
. checking the digital signature which involves:
- checking that the Signature value is correctly calculated,
and
- the hash values in the digests are correctly calculated
where the source of the hash value is available.
Checking for block level errors involves:
. checking within each block (apart from the Transaction
Reference Block) that:
- the attributes, elements and element contents are valid
- the values of the attributes, elements and element contents
are consistent within the block
. checking that the combination of blocks are valid
. checking that the values of the attribute, elements and element
contents are consistent between the blocks in the input message
and blocks in earlier messages either sent or received. This
includes checking that the presence of a block is valid for a
particular transaction type
If the message contains any encapsulated data, then if possible
check the encapsulated data for errors using additional software
to check the data where appropriate.
Errors in the sequence that blocks arrive depends on the block.
Blocks where checking for sequence is required are:
. Error and Cancel Blocks. If an Error or Cancel Block refers to
an IOTP transaction that is not recognised then it is a Hard
Error. Do not return an error if Error or Cancel Blocks have
been received for the IOTP Transaction before to avoid looping.
Note that Error Blocks should be sent to the ErrorLogNetLocn
and may be analysed there.
. Inquiry Request and Response Blocks. If an Inquiry Request or
an Inquiry Response Block refers to an IOTP transaction that is
not recognised then it is a Hard Error
. Authentication Request Block. If an Authentication Request
Block refers to an IOTP transaction that is recognised it is a
Hard Error
. Authentication Response Block. Check as follows
- if an Authentication Response Block does not refer to an
IOTP transaction that is recognised it is a Hard Error,
otherwise
- if the Authentication Response Block doesn't refer to an
Authentication Request that had been previously sent then it
is a Hard Error, otherwise
- if an Authentication Response for the same IOTP transaction
has been received before and the Authentication was
successful then it is a Hard Error.
. Authentication Status Block. Check as follows:
- if an Authentication Status Block does not refer to an IOTP
transaction that is recognised it is a Hard Error, otherwise
- if the Authentication Status Block doesn't refer to an
Authentication Response that had been previously sent then
it is a Hard Error, otherwise
- if an Authentication Status for the same IOTP transaction
has been received before then it is a Warning Error
. TPO Selection Block (Merchant only). Check as follows:
- if the TPO Selection Block doesn't refer to an IOTP
Transaction that is recognised then it is a Hard Error,
otherwise
- if the TPO Selection Block refers to an IOTP Transaction
where a TPO Block and Offer Response (in one message) had
previously been sent then it is a Hard Error, otherwise
- if the TPO Selection Block does not refer to an IOTP
Transaction where a TPO Block only (i.e. without an Offer
Response) had previously been sent then it is a Hard Error,
otherwise
- if a TPO Selection Block for the same TPO Block has been
received before then it is a Hard Error
. 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
. Payment Exchange Block (Payment Handler only). Check as
follows:
- if the Payment Exchange Block doesn't refer to an IOTP
Transaction that is recognised then it is a Hard Error,
otherwise
- if the Payment Exchange doesn't refer to an IOTP Transaction
where a Payment Exchange had previously been sent then it a
Hard Error
. Delivery Request (Delivery Handler Only). If the Delivery
Request Block refers to an IOTP Transaction that is recognised
by the Server then it is a Hard Error
If any Error Components have been generated then collect them
into an Error Block for sending to the sender of the Input
message.
[Note] The above checking on the sequence of Authentication
Responses and Payment Requests supports the Consumer
re-submitting a repeat action request since the
previous one failed, for example
o because they did not know the correct response
(e.g. a password) on an authentication or,
o they were unable to pay as there were insufficient
funds on a credit card
[Note End]
Process the Error Free Input Message
If the input message passes the previous checks then it can be
processed to produce an output message if required. Note that:
. Inquiry Requests on Ping Transactions should be ignored
. Processing of encapsulated messages (e.g. Payment Protocol
Messages) may result in additional transient errors
. a digital signature can only safely be generated once all the
blocks and components have been generated and it is known which
elements in the message need to be signed.
If an output message is generated then it should be saved so that
it can be resent as required if an identical input message is
received again. Note that output messages that contain transient
errors are not saved so that they can be processed afresh when
the input message is received again.
4.5.3 Retransmitting Messages
The server should periodically check for transactions where a
message is expected in return but none has been received after a
time that is dependent on factors such as:
. the Transport Mechanism being used;
. the time required to process encapsulated messages (e.g.
Payment messages) and
. whether or not human input is required.
If no message has been received the original message should be
resent. This should occur up to a maximum number of times
dependent on the reliability of the Transport Mechanism being
used.
If no response is received after the required time then the
Transaction should be "timed out". In this case, the
------_=_NextPart_000_01BEB6DC.AB3FD460--
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Tue Jun 15 00:40:42 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29774
for ; Tue, 15 Jun 1999 00:40:41 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa01120; 15 Jun 99 00:23 EDT
Received: from hitpro.hitachi.co.jp by one.eListX.com id aa01108;
15 Jun 99 00:23 EDT
Received: from bisdgw.bisd.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id NAA27741; Tue, 15 Jun 1999 13:34:46 +0900 (JST)
Received: from bisdmail.bisd.hitachi.co.jp
by bisdgw.bisd.hitachi.co.jp (8.9.3+3.2W/3.7W-bisdgw) with ESMTP id NAA21922
for ; Tue, 15 Jun 1999 13:25:43 +0900 (JST)
(envelope-from andrew@sdl.hitachi.co.jp)
Received: from tamagoyaki.otpnet.org
by bisdmail.bisd.hitachi.co.jp (8.9.3/3.7W-bisdmail) with SMTP id NAA24995
for ; Tue, 15 Jun 1999 13:25:43 +0900 (JST)
(envelope-from andrew@sdl.hitachi.co.jp)
Received: by tamagoyaki.otpnet.org with Microsoft Mail
id <01BEB732.51A3F520@tamagoyaki.otpnet.org>; Tue, 15 Jun 1999 13:23:55 +0900
Message-ID: <01BEB732.51A3F520@tamagoyaki.otpnet.org>
From: Andrew Drapp
To: "ietf-trade@elistx.com"
Subject: RE: Electronic Commerce Modeling Language (ECML)?
Date: Tue, 15 Jun 1999 13:23:54 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Content-Transfer-Encoding: 7bit
> What are the differences between ECML and IOTP?
I took a quick look at the web page provided bye Richard Brown
http://www.ecml.org and noticed that the specification is being handed
over to the IETF, and the first draft was written up (formatted) by Donald
Eastlake. After reading the specification, I don't really understand all the
brouhaha regarding ECML recently, both Wired and C|Net have articles
on ECML and a e-card wallet using ECML.
One funny thing is the way John McGuire, CEO of Trintech, must have been
misquoted in the Wired article:
"Our e-card looks like what you have in
your wallet but is totally secure because
the customer must enter a password
when making a purchase."
(Article found at: http://www.wired.com/news/news/business/story/20178.html)
I wonder what he really said.
Regards,
Andrew Drapp
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Tue Jun 15 01:52:54 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06407
for ; Tue, 15 Jun 1999 01:52:54 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa01345; 15 Jun 99 01:37 EDT
Received: from mail1.gte.net by one.eListX.com id aa01333; 15 Jun 99 01:37 EDT
Received: from computer (bg-tc-ppp453.monmouth.com [209.191.61.202])
by mail1.gte.net with SMTP
for ; id AAA14446
Tue, 15 Jun 1999 00:39:52 -0500 (CDT)
Message-ID: <002801beb6f2$25e10f80$ca3dbfd1@computer>
From: "Milton M. Anderson"
To: ietf-trade@elistx.com
MMDF-Warning: Parse error in original version of preceding line at one.eListX.com
Subject: Re: Electronic Commerce Modeling Language (ECML)?
Date: Tue, 15 Jun 1999 01:44:23 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3115.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Content-Transfer-Encoding: 7bit
Shouldn't telephone numbers be formatted as specified in? --
ITU-T Recommendation E.164
Title : The international public telecommunication numbering plan
Date of adoption : 05/1997
How are hyphenated last names handled?
Milt
-----Original Message-----
From: Richard D. Brown
To: 'Zia Khan' ; ietf-trade@elistx.com
Date: Monday, June 14, 1999 10:01 AM
Subject: RE: Electronic Commerce Modeling Language (ECML)?
>Zia,
>
>You can find more information about ECML at http://www.ecml.org.
>
>As you will notice, ECML consists before all of normalizing a set of
>attribute names that could be recognized and automatically populated by a
>user agent upon receipt of a form. On the other hand, IOTP defines a
>protocol for negotiation, payment, and delivery between a merchant and a
>buyer agent.
>
>Sincerely,
>
>Richard D. Brown
>Software Architect, R&D
>GlobeSet, Inc. Austin, TX - U.S.
>
>
>> -----Original Message-----
>> From: ietf-trade-owner@lists.eListX.com
>> [mailto:ietf-trade-owner@lists.eListX.com]On Behalf Of Zia Khan
>> Sent: Friday, June 11, 1999 8:54 PM
>> To: ietf-trade@elistx.com
>> Subject: Electronic Commerce Modeling Language (ECML)?
>>
>>
>> Does any body have details on this announcement:
>>
>> http://www.news.com/News/Item/0,4,37712,00.html?st.ne.fd.gif.k
>>
>> What are the differences between ECML and IOTP?
>> --------------------------------------------------------------------
>> Zia Khan, Member LiveBiz Team
>> Xenosys Corporation, 258 Java Drive, Sunnyvale, CA 94089
>> Phone: 408.744.0309 Fax: 408.744.9007
>> e-mail: zia@xenosys.com WWW: http://www.livebiz.com
>> Developers of LiveBusiness Foundation Classes for Java
>> --------------------------------------------------------------
>> ------
>>
>> --------------------------------------------------------------
>> ---------
>> Message addressed to: ietf-trade@lists.elistx.com
>> Archive available at: http://www.elistx.com/archives/ietf-trade/
>> To (un)subscribe send a message with "subscribe" or
>> "unsubscribe" in the
>> body to: ietf-trade-request@lists.elistx.com
>>
>
>-----------------------------------------------------------------------
>Message addressed to: ietf-trade@lists.elistx.com
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: ietf-trade-request@lists.elistx.com
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Tue Jun 15 09:20:56 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17082
for ; Tue, 15 Jun 1999 09:20:55 -0400 (EDT)
Received: by one.eListX.com id aa05234; 15 Jun 99 09:17 EDT
Received: from one.elistx.com by one.eListX.com id aa05181; 15 Jun 99 08:49 EDT
Received: from [209.94.126.195] by one.eListX.com id aa05169;
15 Jun 99 08:48 EDT
Received: from localhost (localhost [127.0.0.1])
by torque.pothole.com (8.8.2/8.8.8) with SMTP id IAA15356
for ietf-trade@elistx.com; Tue, 15 Jun 1999 08:50:50 -0400 (EDT)
Message-Id: <199906151250.IAA15356@torque.pothole.com>
X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol
To: "ietf-trade@elistx.com"
Subject: Re: Electronic Commerce Modeling Language (ECML)?
In-reply-to: Your message of "Tue, 15 Jun 1999 13:23:54 +0900."
<01BEB732.51A3F520@tamagoyaki.otpnet.org>
Date: Tue, 15 Jun 1999 08:50:50 -0400
From: "Donald E. Eastlake 3rd"
X-Mts: smtp
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
From: Andrew Drapp
Message-ID: <01BEB732.51A3F520@tamagoyaki.otpnet.org>
To: "ietf-trade@elistx.com"
Date: Tue, 15 Jun 1999 13:23:54 +0900
>> What are the differences between ECML and IOTP?
>
>I took a quick look at the web page provided bye Richard Brown
>http://www.ecml.org and noticed that the specification is being handed
>over to the IETF, and the first draft was written up (formatted) by Donald
>Eastlake. After reading the specification, I don't really understand all the
>brouhaha regarding ECML recently, both Wired and C|Net have articles
>on ECML and a e-card wallet using ECML.
Sorry I didn't post something yesterday but was in transit. You will
notice that the Internet-Draft is not in any working group and that
the boilerplate at the front withholds the right to create derivative
works. The Wallet/Merchant Standards Alliance is just using the IETF
as a publication channel, not (yet) turning change control over to the
IETF.
Thanks,
Donald
(responding as an individual, not as chair of the TRADE WG)
>One funny thing is the way John McGuire, CEO of Trintech, must have been
>misquoted in the Wired article:
>
>"Our e-card looks like what you have in
>your wallet but is totally secure because
>the customer must enter a password
>when making a purchase."
>
>(Article found at: http://www.wired.com/news/news/business/story/20178.html)
>
>I wonder what he really said.
>
>Regards,
>
>Andrew Drapp
>
>-----------------------------------------------------------------------
>Message addressed to: ietf-trade@lists.elistx.com
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: ietf-trade-request@lists.elistx.com
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Tue Jun 15 15:23:53 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27463
for ; Tue, 15 Jun 1999 15:23:52 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa08839; 15 Jun 99 15:10 EDT
Received: from [209.94.126.195] by one.eListX.com id aa08820;
15 Jun 99 15:09 EDT
Received: from localhost (localhost [127.0.0.1])
by torque.pothole.com (8.8.2/8.8.8) with SMTP id PAA15947
for ietf-trade@elistx.com; Tue, 15 Jun 1999 15:10:54 -0400 (EDT)
Message-Id: <199906151910.PAA15947@torque.pothole.com>
X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol
To: ietf-trade@elistx.com
Subject: Re: Electronic Commerce Modeling Language (ECML)?
In-reply-to: Your message of "Tue, 15 Jun 1999 01:44:23 EDT."
<002801beb6f2$25e10f80$ca3dbfd1@computer>
Date: Tue, 15 Jun 1999 15:10:54 -0400
From: "Donald E. Eastlake 3rd"
X-Mts: smtp
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Milt,
For the most part, ECML v1 is geared to represent data as it is typed
in by users. Sure, there are some constraints on date and the like
but some of that is frequently input via pull down menus anyway...
On phone numbers, would it work to tell users thay have to follow the
ITU standard on type in? Is there an effective algorithm to convert
whatever they type in to an ITU conformant number? I'm pretty
doubtful...
Oh hyphenated last names, what is the issue?
Thanks,
Donald
From: "Milton M. Anderson"
Message-ID: <002801beb6f2$25e10f80$ca3dbfd1@computer>
To: ietf-trade@elistx.com
Date: Tue, 15 Jun 1999 01:44:23 -0400
>Shouldn't telephone numbers be formatted as specified in? --
>
>ITU-T Recommendation E.164
>Title : The international public telecommunication numbering plan
>Date of adoption : 05/1997
>
>How are hyphenated last names handled?
>
>Milt
>
>-----Original Message-----
>From: Richard D. Brown
>To: 'Zia Khan' ; ietf-trade@elistx.com
>Date: Monday, June 14, 1999 10:01 AM
>Subject: RE: Electronic Commerce Modeling Language (ECML)?
>
>
>>Zia,
>>
>>You can find more information about ECML at http://www.ecml.org.
>>
>>As you will notice, ECML consists before all of normalizing a set of
>>attribute names that could be recognized and automatically populated by a
>>user agent upon receipt of a form. On the other hand, IOTP defines a
>>protocol for negotiation, payment, and delivery between a merchant and a
>>buyer agent.
>>
>>Sincerely,
>>
>>Richard D. Brown
>>Software Architect, R&D
>>GlobeSet, Inc. Austin, TX - U.S.
>>
>>
>>> -----Original Message-----
>>> From: ietf-trade-owner@lists.eListX.com
>>> [mailto:ietf-trade-owner@lists.eListX.com]On Behalf Of Zia Khan
>>> Sent: Friday, June 11, 1999 8:54 PM
>>> To: ietf-trade@elistx.com
>>> Subject: Electronic Commerce Modeling Language (ECML)?
>>>
>>>
>>> Does any body have details on this announcement:
>>>
>>> http://www.news.com/News/Item/0,4,37712,00.html?st.ne.fd.gif.k
>>>
>>> What are the differences between ECML and IOTP?
>>> --------------------------------------------------------------------
>>> Zia Khan, Member LiveBiz Team
>>> Xenosys Corporation, 258 Java Drive, Sunnyvale, CA 94089
>>> Phone: 408.744.0309 Fax: 408.744.9007
>>> e-mail: zia@xenosys.com WWW: http://www.livebiz.com
>>> Developers of LiveBusiness Foundation Classes for Java
>>> --------------------------------------------------------------
>>> ------
>>>
>>> --------------------------------------------------------------
>>> ---------
>>> Message addressed to: ietf-trade@lists.elistx.com
>>> Archive available at: http://www.elistx.com/archives/ietf-trade/
>>> To (un)subscribe send a message with "subscribe" or
>>> "unsubscribe" in the
>>> body to: ietf-trade-request@lists.elistx.com
>>>
>>
>>-----------------------------------------------------------------------
>>Message addressed to: ietf-trade@lists.elistx.com
>>Archive available at: http://www.elistx.com/archives/ietf-trade/
>>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>>body to: ietf-trade-request@lists.elistx.com
>
>-----------------------------------------------------------------------
>Message addressed to: ietf-trade@lists.elistx.com
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: ietf-trade-request@lists.elistx.com
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Tue Jun 15 15:42:30 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28001
for ; Tue, 15 Jun 1999 15:42:30 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa08891; 15 Jun 99 15:20 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa08879;
15 Jun 99 15:20 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_3766_a6d4_3c07;
Tue, 15 Jun 1999 20:17:40 +0100
Message-Id:
From: David Burdett
To: Ietf Trade WG ,
"Milton M. Anderson"
Subject: RE: Electronic Commerce Modeling Language (ECML)?
Date: Tue, 15 Jun 1999 20:20:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Milton
I notice you can download this from
http://www.itu.int/plweb-cgi/fastweb?getdoc+view1+itudoc+9614+1++E.164, but
they want a 20 Swiss Franc fee. If you look at the table of contents it
covers far more than we need. Do you know of anywhere that you can get just
the number convention in a form that could be expressed as a DTD?
David
> ----------
> From: Milton M. Anderson[SMTP:miltonma@gte.net]
> Sent: 14 June 1999 22:44
> To: ietf-trade@elistx.com
> Subject: Re: Electronic Commerce Modeling Language (ECML)?
>
> Shouldn't telephone numbers be formatted as specified in? --
>
> ITU-T Recommendation E.164
> Title : The international public telecommunication numbering plan
> Date of adoption : 05/1997
>
> How are hyphenated last names handled?
>
> Milt
>
> -----Original Message-----
> From: Richard D. Brown
> To: 'Zia Khan' ; ietf-trade@elistx.com
>
> Date: Monday, June 14, 1999 10:01 AM
> Subject: RE: Electronic Commerce Modeling Language (ECML)?
>
>
> >Zia,
> >
> >You can find more information about ECML at http://www.ecml.org.
> >
> >As you will notice, ECML consists before all of normalizing a set of
> >attribute names that could be recognized and automatically populated by a
> >user agent upon receipt of a form. On the other hand, IOTP defines a
> >protocol for negotiation, payment, and delivery between a merchant and a
> >buyer agent.
> >
> >Sincerely,
> >
> >Richard D. Brown
> >Software Architect, R&D
> >GlobeSet, Inc. Austin, TX - U.S.
> >
> >
> >> -----Original Message-----
> >> From: ietf-trade-owner@lists.eListX.com
> >> [mailto:ietf-trade-owner@lists.eListX.com]On Behalf Of Zia Khan
> >> Sent: Friday, June 11, 1999 8:54 PM
> >> To: ietf-trade@elistx.com
> >> Subject: Electronic Commerce Modeling Language (ECML)?
> >>
> >>
> >> Does any body have details on this announcement:
> >>
> >> http://www.news.com/News/Item/0,4,37712,00.html?st.ne.fd.gif.k
> >>
> >> What are the differences between ECML and IOTP?
> >> --------------------------------------------------------------------
> >> Zia Khan, Member LiveBiz Team
> >> Xenosys Corporation, 258 Java Drive, Sunnyvale, CA 94089
> >> Phone: 408.744.0309 Fax: 408.744.9007
> >> e-mail: zia@xenosys.com WWW: http://www.livebiz.com
> >> Developers of LiveBusiness Foundation Classes for Java
> >> --------------------------------------------------------------
> >> ------
> >>
> >> --------------------------------------------------------------
> >> ---------
> >> Message addressed to: ietf-trade@lists.elistx.com
> >> Archive available at: http://www.elistx.com/archives/ietf-trade/
> >> To (un)subscribe send a message with "subscribe" or
> >> "unsubscribe" in the
> >> body to: ietf-trade-request@lists.elistx.com
> >>
> >
> >-----------------------------------------------------------------------
> >Message addressed to: ietf-trade@lists.elistx.com
> >Archive available at: http://www.elistx.com/archives/ietf-trade/
> >To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> >body to: ietf-trade-request@lists.elistx.com
>
> -----------------------------------------------------------------------
> Message addressed to: ietf-trade@lists.elistx.com
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Wed Jun 16 02:35:43 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21512
for ; Wed, 16 Jun 1999 02:35:42 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa18220; 16 Jun 99 02:22 EDT
Received: from mail.cybersource.com by one.eListX.com id aa16023;
15 Jun 99 19:39 EDT
Received: from warakurna (warakurna.cybersource.com [10.2.5.23])
by mail.cybersource.com (8.9.1/8.9.1) with SMTP id QAA04831
for ; Tue, 15 Jun 1999 16:41:55 -0700 (PDT)
Message-Id: <4.1.19990615163741.009841e0@pop3.cybersource.com>
X-Sender: jeaton@pop3.cybersource.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 15 Jun 1999 16:40:20 -0700
To: ietf-trade@lists.eListX.com
From: Jason Eaton
Subject: SCMP Discussion List
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Simple Commerce Messaging Protocol ( SCMP )
SCMP is a general purpose commerce messaging protocol based on S/MIME.
There is a new mail list for discussion of the SCMP draft (
draft-arnold-scmp-03.txt ). Paul Hoffman at IMC has generously agreed to
host the list. To subscribe, send a message to "ietf-scmp-request@imc.org"
with the word "subscribe" in the body of the message.
Thanks.
Jason Eaton CyberSource Corporation
Phone 408.260.6044 Security Engineering Manager
jeaton@cybersource.com http://www.cybersource.com
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Wed Jun 16 10:18:31 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26202
for ; Wed, 16 Jun 1999 10:18:30 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa20499; 16 Jun 99 09:47 EDT
Received: from fep4-orange.clear.net.nz by one.eListX.com id aa20487;
16 Jun 99 09:46 EDT
Received: from clear.co.nz (maggie.clear.co.nz [10.1.12.14]) by fep4-orange.clear.net.nz (1.5/1.2) with ESMTP id QAA02688; Tue, 15 Jun 1999 16:09:18 +1200 (NZST)
Received: from falcon.clear.co.nz (falcon.mars.clear.co.nz [172.30.55.50])
by clear.co.nz (8.8.5/8.8.5) with ESMTP id QAA27968
for ; Tue, 15 Jun 1999 16:09:17 +1200 (NZST)
Received: by falcon.mars.clear.co.nz with Internet Mail Service (5.5.2448.0)
id ; Tue, 15 Jun 1999 16:08:47 +1200
Message-ID:
From: Michael Zeff
To: Ietf Trade WG
Subject: RE: Error Handling
Date: Tue, 15 Jun 1999 16:09:54 +1200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
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:David.Burdett@mondex.com]
Sent: Tuesday, 15 June 1999 15:11
To: Ietf Trade WG; Masaaki Hiroya
Subject: RE: Error Handling
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
<> <>
> ----------
> From: David Burdett[SMTP:David.Burdett@mondex.com]
> Sent: 31 May 1999 21:01
> To: Ietf Trade WG; Masaaki Hiroya
> Subject: RE: Error Handling
>
> 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:hiroya@sdl.hitachi.co.jp]
> > 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:David.Burdett@mondex.com]
> > > > > Sent: 25 May 1999 14:05
> > > > > To: Ietf Trade WG; hiroya@sdl.hitachi.co.jp
> > > > > 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:hiroya@sdl.hitachi.co.jp]
> > > > > > Reply To: hiroya@sdl.hitachi.co.jp
> > > > > > Sent: 23 May 1999 00:59
> > > > > > To: ietf-trade@elistx.com
> > > > > > 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 ...
> > > > >
> > > > > > > > > PaymentNote?, TradingRoleData*) >
> > > > >
> > > > > ... to ...
> > > > >
> > > > > > > > > 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: hiroya@sdl.hitachi.co.jp
> > > > > >
> > --------------------------------------------------------------------
> > ---
> > > > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > > To (un)subscribe send a message with "subscribe" or
> "unsubscribe"
> > in
> > the
> > > > > > body to: ietf-trade-request@lists.elistx.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
> > us
> > ing
> > > > > email
> > > > > address postmaster@mondex.com 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: postmaster@mondex.com
> > > > > WebSite: http://www.mondexinternational.com
> > > > >
> > > > >
> > **********************************************************************
> > ****
> > > > > *******************
> > > > >
> > -----------------------------------------------------------------------
> > > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> > the
> > > > > body to: ietf-trade-request@lists.elistx.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
> > usin
> > g email
> > > > address postmaster@mondex.com 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: postmaster@mondex.com
> > > > WebSite: http://www.mondexinternational.com
> > > >
> > > >
> > ************************************************************************
> > ****
> > > > *****************
> > > >
> > -----------------------------------------------------------------------
> > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > > body to: ietf-trade-request@lists.elistx.com
> > > >
> > > -----
> > > Masaaki Hiroya
> > > Systems Development Laboratory
> > > Hitachi, Ltd.
> > > tel: +81-44-959-0874
> > > fax: +81-44-959-0856
> > > email: hiroya@sdl.hitachi.co.jp
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: ietf-trade@lists.elistx.com
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: ietf-trade-request@lists.elistx.com
> > >
> > -----
> > Masaaki Hiroya
> > Systems Development Laboratory
> > Hitachi, Ltd.
> > email: hiroya@sdl.hitachi.co.jp
> > tel: +81-44-966-9111(ext.3552)
> > fax: +81-44-966-1796
> > -----------------------------------------------------------------------
> > Message addressed to: ietf-trade@lists.elistx.com
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
> WebSite: http://www.mondexinternational.com
>
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: ietf-trade@lists.elistx.com
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
****************************************************************************
*****************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Wed Jun 16 23:20:25 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08223
for ; Wed, 16 Jun 1999 23:20:25 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa23716; 16 Jun 99 23:00 EDT
Received: from hitpro.hitachi.co.jp by one.eListX.com id aa23704;
16 Jun 99 22:59 EDT
Received: from bisdgw.bisd.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id MAA08768; Thu, 17 Jun 1999 12:11:16 +0900 (JST)
Received: from bisdmail.bisd.hitachi.co.jp
by bisdgw.bisd.hitachi.co.jp (8.9.3+3.2W/3.7W-bisdgw) with ESMTP id MAA15249
for ; Thu, 17 Jun 1999 12:01:35 +0900 (JST)
(envelope-from andrew@sdl.hitachi.co.jp)
Received: from tamagoyaki.otpnet.org
by bisdmail.bisd.hitachi.co.jp (8.9.3/3.7W-bisdmail) with SMTP id MAA29149
for ; Thu, 17 Jun 1999 12:01:34 +0900 (JST)
(envelope-from andrew@sdl.hitachi.co.jp)
Received: by tamagoyaki.otpnet.org with Microsoft Mail
id <01BEB8B8.E58144A0@tamagoyaki.otpnet.org>; Thu, 17 Jun 1999 11:59:47 +0900
Message-ID: <01BEB8B8.E58144A0@tamagoyaki.otpnet.org>
From: Andrew Drapp
To: "'Ietf Trade WG'"
Subject: ConsumerDeliveryId
Date: Thu, 17 Jun 1999 11:59:46 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Content-Transfer-Encoding: 7bit
In section 6.2, the ConsumerDeliveryId is
described as follows:
---
An identifier specified by the Consumer which,
if returned by the Delivery Handler in another
Delivery Component, or by other means, will
enable the Consumer to identify which Delivery
is being referred to.
---
This is a bit confusing. The first time the
ConsumerDeliveryId is used is in the Offer Response
Block, so I assume that it is defined by the
Merchant. What exactly is meant by "specified"?
Would replacing "specified" with "used" clarify
or change the meaning?
Furthermore, should this Id be unique within
the IOTP transaction, or globally unique?
Regards,
Andrew
--
Andrew Drapp
andrew@sdl.hitachi.co.jp
Systems Development Laboratory, Hitachi Ltd.
Ozenji 1099, Asao, Kawasaki, 215-0013 JAPAN
TEL:+81-44-966-9111 FAX:+81-44-966-1796
PGP Fingerprint: 84D8 3D19 018E 9385 6581 0081 C89C D2AD F06A 565F
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Wed Jun 16 23:51:58 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08877
for ; Wed, 16 Jun 1999 23:51:57 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa24008; 16 Jun 99 23:18 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa23996;
16 Jun 99 23:18 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_3768_684d_9ee1;
Thu, 17 Jun 1999 04:15:25 +0100
Message-Id:
From: David.Burdett@mondex.com
To: ietf-trade@elistx.com, michael.zeff@clear.co.nz
Subject: RE: Error Handling
Date: Thu, 17 Jun 1999 04:17:34 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
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:michael.zeff@clear.co.nz]
> Sent: 14 June 1999 21:09
> To: Ietf Trade WG
> Subject: RE: Error Handling
>
> 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:David.Burdett@mondex.com]
> Sent: Tuesday, 15 June 1999 15:11
> To: Ietf Trade WG; Masaaki Hiroya
> Subject: RE: Error Handling
>
>
> 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
> <> <>
>
> > ----------
> > From: David Burdett[SMTP:David.Burdett@mondex.com]
> > Sent: 31 May 1999 21:01
> > To: Ietf Trade WG; Masaaki Hiroya
> > Subject: RE: Error Handling
> >
> > 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:hiroya@sdl.hitachi.co.jp]
> > > 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:David.Burdett@mondex.com]
> > > > > > Sent: 25 May 1999 14:05
> > > > > > To: Ietf Trade WG; hiroya@sdl.hitachi.co.jp
> > > > > > 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:hiroya@sdl.hitachi.co.jp]
> > > > > > > Reply To: hiroya@sdl.hitachi.co.jp
> > > > > > > Sent: 23 May 1999 00:59
> > > > > > > To: ietf-trade@elistx.com
> > > > > > > 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 ...
> > > > > >
> > > > > > > > > > > PaymentNote?, TradingRoleData*) >
> > > > > >
> > > > > > ... to ...
> > > > > >
> > > > > > > > > > > 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: hiroya@sdl.hitachi.co.jp
> > > > > > >
> > > --------------------------------------------------------------------
> > > ---
> > > > > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > > > > Archive available at:
> http://www.elistx.com/archives/ietf-trade/
> > > > > > > To (un)subscribe send a message with "subscribe" or
> > "unsubscribe"
> > > in
> > > the
> > > > > > > body to: ietf-trade-request@lists.elistx.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
> > > us
> > > ing
> > > > > > email
> > > > > > address postmaster@mondex.com 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: postmaster@mondex.com
> > > > > > WebSite: http://www.mondexinternational.com
> > > > > >
> > > > > >
> > > **********************************************************************
> > > ****
> > > > > > *******************
> > > > > >
> > >
> -----------------------------------------------------------------------
> > > > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > > To (un)subscribe send a message with "subscribe" or
> "unsubscribe"
> > in
> > > the
> > > > > > body to: ietf-trade-request@lists.elistx.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
> > > usin
> > > g email
> > > > > address postmaster@mondex.com 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: postmaster@mondex.com
> > > > > WebSite: http://www.mondexinternational.com
> > > > >
> > > > >
> > >
> ************************************************************************
> > > ****
> > > > > *****************
> > > > >
> > >
> -----------------------------------------------------------------------
> > > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> > > the
> > > > > body to: ietf-trade-request@lists.elistx.com
> > > > >
> > > > -----
> > > > Masaaki Hiroya
> > > > Systems Development Laboratory
> > > > Hitachi, Ltd.
> > > > tel: +81-44-959-0874
> > > > fax: +81-44-959-0856
> > > > email: hiroya@sdl.hitachi.co.jp
> > > >
> > -----------------------------------------------------------------------
> > > > Message addressed to: ietf-trade@lists.elistx.com
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > > body to: ietf-trade-request@lists.elistx.com
> > > >
> > > -----
> > > Masaaki Hiroya
> > > Systems Development Laboratory
> > > Hitachi, Ltd.
> > > email: hiroya@sdl.hitachi.co.jp
> > > tel: +81-44-966-9111(ext.3552)
> > > fax: +81-44-966-1796
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: ietf-trade@lists.elistx.com
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
> > WebSite: http://www.mondexinternational.com
> >
> >
> **************************************************************************
> > *******************
> > -----------------------------------------------------------------------
> > Message addressed to: ietf-trade@lists.elistx.com
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
> WebSite: http://www.mondexinternational.com
>
> **************************************************************************
> **
> *****************
> -----------------------------------------------------------------------
> Message addressed to: ietf-trade@lists.elistx.com
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Thu Jun 17 09:57:45 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28075
for ; Thu, 17 Jun 1999 09:57:42 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa26365; 17 Jun 99 09:39 EDT
Received: from smtp-out-001.wanadoo.fr by one.eListX.com id aa21609;
16 Jun 99 11:45 EDT
Received: from villosa.wanadoo.fr [193.252.19.122] by wanadoo.fr
for
Paris Wed, 16 Jun 1999 17:47:43 +0200 (MET DST)
Received: from checkflow.com (164.138.108.144) by villosa.wanadoo.fr; 16 Jun 1999 17:47:37 +0200
Message-ID: <3767D4E8.C00BD733@checkflow.com>
Date: Wed, 16 Jun 1999 17:46:33 +0000
From: "serge.piasek"
Organization: COMMUNICATION INTERACTIVE
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-trade@elistx.com
Subject: ECML GOAL (our vision)
Content-Type: multipart/mixed;
boundary="------------4488EA44A467A3A99273DD9C"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
This is a multi-part message in MIME format.
--------------4488EA44A467A3A99273DD9C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
Today, U consider ecml as a list of field for credit card/delivery
infos.
We think that this is the 1st step to a normalization of e commerce
transaction, so you should be carefull, you see only what they want to
showU, the top of the iceberg...
BR
Serge Piasek
--------------4488EA44A467A3A99273DD9C
Content-Type: text/x-vcard; charset=us-ascii;
name="serge.piasek.vcf"
Content-Description: Card for serge.piasek
Content-Disposition: attachment;
filename="serge.piasek.vcf"
Content-Transfer-Encoding: 7bit
begin:vcard
n:Piasek;Serge
tel;cell:(33 6) 62 04 95 22
tel;fax:(33 1) 42 88 42 73
tel;work:(33 1) 44 61 99 22
x-mozilla-html:TRUE
url:http://www.checkflow.com
org:COMMUNICATION INTERACTIVE;DIRECTION GENERALE
adr:;;25 Rue du Temple;Paris;;75004;France
version:2.1
email;internet:serge.piasek@checkflow.com
title:PDG
fn:Serge Piasek
end:vcard
--------------4488EA44A467A3A99273DD9C--
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Thu Jun 17 21:25:10 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04017
for ; Thu, 17 Jun 1999 21:25:09 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa28664; 17 Jun 99 21:08 EDT
Received: from [209.94.126.195] by one.eListX.com id aa28652;
17 Jun 99 21:07 EDT
Received: from localhost (localhost [127.0.0.1])
by torque.pothole.com (8.8.2/8.8.8) with SMTP id VAA20251
for ietf-trade@elistx.com; Thu, 17 Jun 1999 21:10:11 -0400 (EDT)
Message-Id: <199906180110.VAA20251@torque.pothole.com>
X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol
To: ietf-trade@elistx.com
Subject: Re: ECML GOAL (our vision)
In-reply-to: Your message of "Wed, 16 Jun 1999 17:46:33 -0000."
<3767D4E8.C00BD733@checkflow.com>
Date: Thu, 17 Jun 1999 21:10:11 -0400
From: "Donald E. Eastlake 3rd"
X-Mts: smtp
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
I'm not sure what you are worrying about. I'm the primary IBM
representative to the alliance that produced ECML v1. While the
alliance is certainly considering extensions, as of today, I can
assure you there is no iceburg.
Donald
From: "serge.piasek"
Message-ID: <3767D4E8.C00BD733@checkflow.com>
Date: Wed, 16 Jun 1999 17:46:33 +0000
Organization: COMMUNICATION INTERACTIVE
To: ietf-trade@elistx.com
>Hi,
>
>Today, U consider ecml as a list of field for credit card/delivery
>infos.
>
>We think that this is the 1st step to a normalization of e commerce
>transaction, so you should be carefull, you see only what they want to
>showU, the top of the iceberg...
>
>BR
>
>Serge Piasek
>
>--------------4488EA44A467A3A99273DD9C
>Content-Type: text/x-vcard; charset=us-ascii;
> name="serge.piasek.vcf"
>Content-Transfer-Encoding: 7bit
>Content-Description: Card for serge.piasek
>Content-Disposition: attachment;
> filename="serge.piasek.vcf"
>
>begin:vcard
>n:Piasek;Serge
>tel;cell:(33 6) 62 04 95 22
>tel;fax:(33 1) 42 88 42 73
>tel;work:(33 1) 44 61 99 22
>x-mozilla-html:TRUE
>url:http://www.checkflow.com
>org:COMMUNICATION INTERACTIVE;DIRECTION GENERALE
>adr:;;25 Rue du Temple;Paris;;75004;France
>version:2.1
>email;internet:serge.piasek@checkflow.com
>title:PDG
>fn:Serge Piasek
>end:vcard
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Sat Jun 19 22:42:01 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26719
for ; Sat, 19 Jun 1999 22:42:01 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa16390; 19 Jun 99 22:29 EDT
Received: from hitpro.hitachi.co.jp by one.eListX.com id aa16378;
19 Jun 99 22:28 EDT
Received: from hsdlgw92.sdl.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id LAA06951; Sun, 20 Jun 1999 11:41:27 +0900 (JST)
Received: from maila.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.9.3/3.7W98102618) id LAA11810; Sun, 20 Jun 1999 11:30:50 +0900 (JST)
Received: from toro ([133.144.6.40])
by maila.sdl.hitachi.co.jp (8.9.1/3.7W98100211) with SMTP id LAA01964;
Sun, 20 Jun 1999 11:30:49 +0900 (JST)
Message-Id: <4.1-J.19990620081144.01409a70@sdl99a.sdl.hitachi.co.jp>
X-Sender: hiroya@sdl99a.sdl.hitachi.co.jp
Reply-To: hiroya@sdl.hitachi.co.jp
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1-J
Date: Sun, 20 Jun 1999 11:28:37 +0900
To: David.Burdett@mondex.com, ietf-trade@elistx.com
From: Masaaki Hiroya
Subject: RE: Error Handling
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
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
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
> <> <>
>
-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
tel: +81-44-549-1531
fax: +81-44-549-1640
email: hiroya@sdl.hitachi.co.jp
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Sat Jun 19 23:51:40 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27320
for ; Sat, 19 Jun 1999 23:51:40 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa16567; 19 Jun 99 23:39 EDT
Received: from [209.94.126.195] by one.eListX.com id aa16555;
19 Jun 99 23:39 EDT
Received: from localhost (localhost [127.0.0.1])
by torque.pothole.com (8.8.2/8.8.8) with SMTP id XAA29142;
Sat, 19 Jun 1999 23:41:41 -0400 (EDT)
Message-Id: <199906200341.XAA29142@torque.pothole.com>
X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol
To: "serge.piasek"
cc: ietf-trade@elistx.com
Subject: Re: ECML extensions
In-reply-to: Your message of "Fri, 18 Jun 1999 08:13:27 -0000."
<3769F197.76004E0B@checkflow.com>
Date: Sat, 19 Jun 1999 23:41:41 -0400
From: "Donald E. Eastlake 3rd"
X-Mts: smtp
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
What is being considered for extenions of ECML is not a big secret.
See which is linked off the ecml.org
home page.
Donald
From: "serge.piasek"
Message-ID: <3769F197.76004E0B@checkflow.com>
Date: Fri, 18 Jun 1999 08:13:27 +0000
Organization: COMMUNICATION INTERACTIVE
To: dee3@torque.pothole.com
>Thank U for your response.
>
>You are talking about extensions, can you be more precise ?
>
>BR.
>
>Serge Piasek
>
>_____________________________________________________
>
>L'integrite de ce message n'etant pas assuree sur Internet,
>COMMUNICATION
>INTERACTIVE ne peut etre tenue responsable de son contenu.
>Si vous n'etes pas destinataire de ce message, merci de le detruire et
>d'avertir l'expediteur.
>
>-------------------------------------------------------------------------------
>The integrity of this message cannot be guaranteed on the Internet.
>COMMUNICATION INTERACTIVE can not therefore be considered responsible
>for the contents.
>If you are not the intended recipient of this message, then please
>delete
>it and notify the sender.
>________________________________________________________________________________
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Mon Jun 21 00:47:19 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18512
for ; Mon, 21 Jun 1999 00:47:18 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa19228; 21 Jun 99 00:32 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa19213;
21 Jun 99 00:30 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_376d_bf37_48f1;
Mon, 21 Jun 1999 05:27:35 +0100
Message-Id:
From: David.Burdett@mondex.com
To: ietf-trade@elistx.com, hiroya@sdl.hitachi.co.jp
Subject: RE: Error Handling
Date: Mon, 21 Jun 1999 05:29:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
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:hiroya@sdl.hitachi.co.jp]
> Reply To: hiroya@sdl.hitachi.co.jp
> Sent: 19 June 1999 19:28
> To: David.Burdett@mondex.com; ietf-trade@elistx.com
> 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
> > <> <>
> >
>
>
>
> -----
> Masaaki Hiroya
> Systems Development Laboratory
> Hitachi, Ltd.
> tel: +81-44-549-1531
> fax: +81-44-549-1640
> email: hiroya@sdl.hitachi.co.jp
> -----------------------------------------------------------------------
> Message addressed to: ietf-trade@lists.elistx.com
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Thu Jun 24 19:40:06 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24809
for ; Thu, 24 Jun 1999 19:40:04 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa28535; 24 Jun 99 19:20 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa28522;
24 Jun 99 19:19 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_3772_bc7e_91d9;
Fri, 25 Jun 1999 00:17:18 +0100
Message-Id:
From: David.Burdett@mondex.com
To: ietf-trade@elistx.com
Subject: XML Messaging Draft Charter
Date: Fri, 25 Jun 1999 00:18:45 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01BEBE97.E847A0A0"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01BEBE97.E847A0A0
Content-Type: text/plain;
charset="iso-8859-1"
In the last IETF meeting, in Minneapolis, I gave a presentation on "XML
Messaging" which suggested extracting from IOTP the ideas it contained on
handling messages so that they could form a separate standard that would
have wider applicability. During the meeting this was thought a good idea.
The attached HTML document (and plain text below) contain an *initial* draft
for a charter for an XML Messaging working group that might be formed to
develop the standard. Please note that:
* it IS a draft - comments ARE welcome
* I do not presume that a working group will be formed - that is the
decision of the IESG
However I would like to start informal discussion on the idea. So any
comments are really welcome, particularly from groups, not necessarily
within the IETF, that might make use of XML Messaging. It is important that
the requirements of a good cross-section of potential users of XML messaging
are included in this work.
I also suggest, with the chair's permission, that ideas on what to do in the
area of "XML Messaging" is discussed during the Trade WG meetiing at the
next IETF meeting in Oslo on July 14.
Regards
David Burdett
Draft charter as HTML ...
<>
... and as text ...
====================================
XML MESSAGING (XMLMSG)
Chair(s):
[TBD]
[Applications/Transport] Area Director(s):
TBD
[This potentially could be either the Applications Area or Transport Area or
joint in both areas.]
Area Advisor:
[TBD]
Mailing Lists:
General Discussions: ietf-xmlmsg@xxx
To Subscribe: [TBD]
Archive: [TBD]
Description of Working Group:
Purpose
The Extensible Mark-Up Language (XML) (see
http://www.w3.org/TR/1998/REC-xml-19980210) is becoming popular as the basis
for Internet protocols such as IOTP and RosettaNet. Other existing protocols
also state an intention to migrate to XML such as OFX and FSML. [please
suggest other appropriate standards]
Many of these protocols have common requirements which are independent of
the purpose of the protocols, the information they are carrying or the
processes that these protocols initiate and control.
The purpose of the XMLMSG working group is to develop standard approaches to
common requirements for these protocols so that solutions may benefit from
re-usability of software components and enhanced interoperability.
The list of requirements is described below under three headings:
1) Common XML Message Elements
2) Document Exchange Architecture
3) Common Document Exchanges
Common XML Message Elements
The following are to be considered as common XML Message elements:
1) Standard Message Header. These elements will identify, describe and
classify the XML documents that make up the messages in the protocol
2) Packaged Data. An XML element that can be used to encapsulate any
arbitrary data, for example binary data, or other XML documents, inside an
XML document
3) Message Error Data. These elements specify the nature and position of
errors found in an XML document that has been received
4) Signature Data. These elements apply digital signatures to the data in
the message. The intention is that this will use the results of the joint
W3C/IETF XMLDSIG working group
5) Status Data. These elements describe the success or failure of a process
which the protocol is used to initiate.
6) XML Message Structure. This element will describe how the other Common
XML Message elements can be combined to form a basic XML document for a
protocol message that can be used to "wrap" data which is domain specific.
The intention is not to duplicate the effort of others. For example, if W3C
standardizes the packaging of arbitrary data, then this working group would
use the results of their work.
Document Exchange Architecture
This will define how to use the Common XML Message Elements to exchange
documents between the parties involved in the protocol. Specifically the
following areas will be considered.
1) Simple Document Exchange. This will describe how to carry out a Document
Exchange consisting of Request Messages and Response Messages that:
a) Initiate a process on a remote system. This will describe how to
use a message that conforms to the XML Message Structure to request the
initiation of a process at a remote location, and
b) Receive the results of a process. This will describe how to
construct a message using the XML Message Structure that responds to the
request and describes the success, or failure, of the process
2) Combining Document Exchanges. This will describe how to combine two or
more Simple Document Exchanges between two or more organizations into higher
level processes for greater functionality
3) Process Authorization. This will describe how to determine if the XML
document that forms a request message is authorized and therefore the
requested document exchange should be carried out, particularly when
authorization is dependent on the successful completion of an earlier
document exchange
4) Problem Reporting. How to report errors found in messages so that the
problems in systems that caused the error can be resolved
5) Idempotency. This will describe standard approaches towards handling
duplicate messages and data that has been received.
6) Restarts and Recovery. If a document exchange fails this will describe
standard approaches towards recovering from the failure.
Common Document Exchanges
These are common Document Exchanges that use the Document Exchange
structure described above to implement commonly used functionality:
1) Process Inquiry. This will describe a Document Exchange that can be used
to inquire on the current status of any other process that is supported by a
protocol based on XML Messaging.
2) Ping Transaction. This will describe a Document Exchange that can be used
to determine if the servers and systems that are supporting a protocol based
on XML Messaging are available and functioning.
3) Authentication. This will describe a Document Exchange that can be used
to discover information about and authenticate another system or user of the
protocol.
Development Approach
Three documents are to be developed that correspond to each of the three
groupings above. While some work will proceed in parallel on all three
groups, they are expected to be advanced for standardization in the order
listed above
Goals and Milestones:
To be completed.
**********************************************************************************************
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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
------_=_NextPart_000_01BEBE97.E847A0A0
Content-Type: text/html;
name="XML Messaging Charter - draft.htm"
Content-Disposition: attachment;
filename="XML Messaging Charter - draft.htm"
Content-Transfer-Encoding: quoted-printable
Normal Template
XML MESSAGING (XMLMSG)
Chair(s):
[TBD]
[Applications/Transport] =
Area Director(s):
TBD
[This potentially could be either the =
Applications Area or Transport Area or joint in both areas.]
Area Advisor:
[TBD]
Mailing Lists:
General =
Discussions: ietf-xmlmsg@xxx
To Subscribe: [TBD]
Archive: [TBD]
Description of Working =
Group:
Purpose
The Extensible Mark-Up =
Language (XML) (see http://www.w3.org/TR/1998/REC-xml-19980210) is =
becoming popular as the basis for Internet protocols such as IOTP and =
RosettaNet. Other existing protocols also state an intention to migrate =
to XML such as OFX and FSML. [please suggest other appropriate =
standards]
Many of these protocols have common requirements which are =
independent of the purpose of the protocols, the information they are =
carrying or the processes that these protocols initiate and =
control.
The purpose of the XMLMSG working group is to develop standard =
approaches to common requirements for these protocols so that solutions =
may benefit from re-usability of software components and enhanced =
interoperability.
The list of requirements is described below under three =
headings:
1) Common XML Message Elements
2) Document Exchange Architecture
3) Common Document Exchanges
Common XML Message =
Elements
The following are to be =
considered as common XML Message elements:
- Standard Message Header. These elements will =
identify, describe and classify the XML documents that make up the =
messages in the protocol
Packaged Data. An XML element that can be used =
to encapsulate any arbitrary data, for example binary data, or other =
XML documents, inside an XML document
Message Error Data. These elements specify the =
nature and position of errors found in an XML document that has been =
received
Signature Data. These elements apply digital =
signatures to the data in the message. The intention is that this will =
use the results of the joint W3C/IETF XMLDSIG working group
Status Data. These elements describe the =
success or failure of a process which the protocol is used to =
initiate.
XML Message Structure. This element will =
describe how the other Common XML Message elements can be combined to =
form a basic XML document for a protocol message that can be used to =
"wrap" data which is domain specific.
The intention is not to duplicate the effort of =
others. For example, if W3C standardizes the packaging of arbitrary =
data, then this working group would use the results of their work.
Document Exchange =
Architecture
This will define how to use =
the Common XML Message Elements to exchange documents between the =
parties involved in the protocol. Specifically the following areas will =
be considered.
- Simple Document Exchange. This will describe =
how to carry out a Document Exchange consisting of Request Messages and =
Response Messages that:
- Initiate a process on a remote system. This =
will describe how to use a message that conforms to the XML Message =
Structure to request the initiation of a process at a remote location, =
and
- Receive the results of a process. This will =
describe how to construct a message using the XML Message Structure =
that responds to the request and describes the success, or failure, of =
the process
- Combining Document Exchanges. This will =
describe how to combine two or more Simple Document Exchanges between =
two or more organizations into higher level processes for greater =
functionality
- Process Authorization. This will describe how =
to determine if the XML document that forms a request message is =
authorized and therefore the requested document exchange should be =
carried out, particularly when authorization is dependent on the =
successful completion of an earlier document exchange
- Problem Reporting. How to report errors found =
in messages so that the problems in systems that caused the error can =
be resolved
- Idempotency. This will describe standard =
approaches towards handling duplicate messages and data that has been =
received.
- Restarts and Recovery. If a document exchange =
fails this will describe standard approaches towards recovering from =
the failure.
Common Document =
Exchanges
These are common Document =
Exchanges that use the Document Exchange structure described above to =
implement commonly used functionality:
- Process Inquiry. This will describe a Document =
Exchange that can be used to inquire on the current status of any other =
process that is supported by a protocol based on XML =
Messaging.
- Ping Transaction. This will describe a =
Document Exchange that can be used to determine if the servers and =
systems that are supporting a protocol based on XML Messaging are =
available and functioning.
- Authentication. This will describe a Document =
Exchange that can be used to discover information about and =
authenticate another system or user of the protocol.
Development Approach
Three documents are to be =
developed that correspond to each of the three groupings above. While =
some work will proceed in parallel on all three groups, they are =
expected to be advanced for standardization in the order listed =
above
Goals and Milestones:
To be completed.
------_=_NextPart_000_01BEBE97.E847A0A0--
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Fri Jun 25 11:14:02 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23762
for ; Fri, 25 Jun 1999 11:14:02 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa09681; 25 Jun 99 10:51 EDT
Received: from [206.47.239.92] by one.eListX.com id aa09669; 25 Jun 99 10:50 EDT
Received: id KAA07031; Fri, 25 Jun 1999 10:37:47 -0400
Received: by gateway id ; Fri, 25 Jun 1999 10:36:12 -0400
From: "Marchewka, Andrew"
To: ietf-trade@elistx.com
Subject: XML Messaging Draft Charter
Date: Fri, 25 Jun 1999 09:09:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01BEBF18.11831078"
Message-ID: <9906251050.aa09669@one.eListX.com>
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01BEBF18.11831078
Content-Type: text/plain;
charset="iso-8859-1"
Dave,
Attached is some info about another use of XML ... for smart card
application development...
Andrew Marchewka
CIBC
======================================
Dear DML subscribers
To stimulate your smart card neurons, I thought I'd open a discussion
thread on today's press release on SmartX Framework
(http://biz.yahoo.com/bw/990621/ca_gemplus_1.html). I've heard good
things about it and based on the comments of IBM, Sun and Microsoft,
they seem to agree. Its my understanding that this technology allows
developers to work on the business/application issues and use XML
libraries for the card specific details (MPCOS, ME2000, JavaCard,
Smart Card for Windows, TB100, etc.).
I believe application developers, especially those entering the
industry from the personal computer industry, will embrace this
technology as it allows them to focus on the application development
instead of the card operating system.
What do you think?
I've posted part of the press release below and if you really want to
study what SmartX is, go to http://www.smartxml.com for a tutorial and
FAQ.
SmartX separates application development from the complexity of smart
card device management, a breakthrough that for the first time allows
easy implementation of the same application on different types or
generations of smart card. Based on the eXtensible Markup Language
(XML) standard, smartX allows developers to write smart card
applications independent of manufacturer-specific card management
protocols, essentially enabling them to write ``virtual smart card
objects'' that are platform (card and terminal) independent.
Charles Cagliostro
SCIA Board
______________________________
Forward Header
__________________________________
Subject: XML Messaging Draft Charter
Author: "David.Burdett@mondex.com"
[SMTP:David.Burdett@mondex.com] at
NA01
Date: 24/06/99 7:18 PM
In the last IETF meeting, in
Minneapolis, I gave a presentation on
"XML Messaging" which suggested
extracting from IOTP the ideas it
contained on handling messages so
that they could form a separate
standard that would have wider
applicability. During the meeting
this was thought a good idea.
The attached HTML document (and plain
text below) contain an *initial*
draft for a charter for an XML
Messaging working group that might be
formed to develop the standard.
Please note that:
* it IS a draft - comments ARE
welcome
* I do not presume that a working
group will be formed - that is the
decision of the IESG
However I would like to start
informal discussion on the idea. So
any comments are really welcome,
particularly from groups, not
necessarily within the IETF, that
might make use of XML Messaging. It
is important that the requirements of
a good cross-section of potential
users of XML messaging are included
in this work.
I also suggest, with the chair's
permission, that ideas on what to do
in the area of "XML Messaging" is
discussed during the Trade WG
meetiing at the next IETF meeting in
Oslo on July 14.
Regards
David Burdett
Draft charter as HTML ...
<>
... and as text ...
====================================
XML MESSAGING (XMLMSG)
Chair(s):
[TBD]
[Applications/Transport] Area Director(s):
TBD
[This potentially could be either the Applications Area or Transport Area or
joint in both areas.]
Area Advisor:
[TBD]
Mailing Lists:
General Discussions: ietf-xmlmsg@xxx
To Subscribe: [TBD]
Archive: [TBD]
Description of Working Group:
Purpose
The Extensible Mark-Up Language (XML) (see
http://www.w3.org/TR/1998/REC-xml-19980210) is becoming popular as the basis
for Internet protocols such as IOTP and RosettaNet. Other existing protocols
also state an intention to migrate to XML such as OFX and FSML. [please
suggest other appropriate standards]
Many of these protocols have common requirements which are independent of
the purpose of the protocols, the information they are carrying or the
processes that these protocols initiate and control.
The purpose of the XMLMSG working group is to develop standard approaches to
common requirements for these protocols so that solutions may benefit from
re-usability of software components and enhanced interoperability.
The list of requirements is described below under three headings:
1) Common XML Message Elements
2) Document Exchange Architecture
3) Common Document Exchanges
Common XML Message Elements
The following are to be considered as common XML Message elements:
1) Standard Message Header. These elements will identify, describe and
classify the XML documents that make up the messages in the protocol
2) Packaged Data. An XML element that can be used to encapsulate any
arbitrary data, for example binary data, or other XML documents, inside an
XML document
3) Message Error Data. These elements specify the nature and position of
errors found in an XML document that has been received
4) Signature Data. These elements apply digital signatures to the data in
the message. The intention is that this will use the results of the joint
W3C/IETF XMLDSIG working group
5) Status Data. These elements describe the success or failure of a process
which the protocol is used to initiate.
6) XML Message Structure. This element will describe how the other Common
XML Message elements can be combined to form a basic XML document for a
protocol message that can be used to "wrap" data which is domain specific.
The intention is not to duplicate the effort of others. For example, if W3C
standardizes the packaging of arbitrary data, then this working group would
use the results of their work.
Document Exchange Architecture
This will define how to use the Common XML Message Elements to exchange
documents between the parties involved in the protocol. Specifically the
following areas will be considered.
1) Simple Document Exchange. This will describe how to carry out a Document
Exchange consisting of Request Messages and Response Messages that:
a) Initiate a process on a remote system. This will describe how to
use a message that conforms to the XML Message Structure to request the
initiation of a process at a remote location, and
b) Receive the results of a process. This will describe how to
construct a message using the XML Message Structure that responds to the
request and describes the success, or failure, of the process
2) Combining Document Exchanges. This will describe how to combine two or
more Simple Document Exchanges between two or more organizations into higher
level processes for greater functionality
3) Process Authorization. This will describe how to determine if the XML
document that forms a request message is authorized and therefore the
requested document exchange should be carried out, particularly when
authorization is dependent on the successful completion of an earlier
document exchange
4) Problem Reporting. How to report errors found in messages so that the
problems in systems that caused the error can be resolved
5) Idempotency. This will describe standard approaches towards handling
duplicate messages and data that has been received.
6) Restarts and Recovery. If a document exchange fails this will describe
standard approaches towards recovering from the failure.
Common Document Exchanges
These are common Document Exchanges that use the Document Exchange
structure described above to implement commonly used functionality:
1) Process Inquiry. This will describe a Document Exchange that can be used
to inquire on the current status of any other process that is supported by a
protocol based on XML Messaging.
2) Ping Transaction. This will describe a Document Exchange that can be used
to determine if the servers and systems that are supporting a protocol based
on XML Messaging are available and functioning.
3) Authentication. This will describe a Document Exchange that can be used
to discover information about and authenticate another system or user of the
protocol.
Development Approach
Three documents are to be developed that correspond to each of the three
groupings above. While some work will proceed in parallel on all three
groups, they are expected to be advanced for standardization in the order
listed above
Goals and Milestones:
To be completed.
****************************************************************************
****
**************
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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
****************************************************************************
****
*************
------_=_NextPart_000_01BEBF18.11831078
Content-Type: application/octet-stream;
name="XMLMESSA.HTM"
Content-Disposition: attachment;
filename="XMLMESSA.HTM"
Content-Transfer-Encoding: quoted-printable
Normal Template
XML MESSAGING (XMLMSG)
Chair(s):
[TBD]
[Applications/Transport] =
Area Director(s):
TBD
[This potentially could be either the =
Applications Area or Transport Area or joint in both areas.]
Area Advisor:
[TBD]
Mailing Lists:
General =
Discussions: ietf-xmlmsg@xxx
To Subscribe: [TBD]
Archive: [TBD]
Description of Working =
Group:
Purpose
The Extensible Mark-Up =
Language (XML) (see http://www.w3.org/TR/1998/REC-xml-19980210) is =
becoming popular as the basis for Internet protocols such as IOTP and =
RosettaNet. Other existing protocols also state an intention to migrate =
to XML such as OFX and FSML. [please suggest other appropriate =
standards]
Many of these protocols have common requirements which are =
independent of the purpose of the protocols, the information they are =
carrying or the processes that these protocols initiate and =
control.
The purpose of the XMLMSG working group is to develop standard =
approaches to common requirements for these protocols so that solutions =
may benefit from re-usability of software components and enhanced =
interoperability.
The list of requirements is described below under three =
headings:
1) Common XML Message Elements
2) Document Exchange Architecture
3) Common Document Exchanges
Common XML Message =
Elements
The following are to be =
considered as common XML Message elements:
- Standard Message Header. These elements will =
identify, describe and classify the XML documents that make up the =
messages in the protocol
- Packaged Data. An XML element that can be used =
to encapsulate any arbitrary data, for example binary data, or other =
XML documents, inside an XML document
- Message Error Data. These elements specify the =
nature and position of errors found in an XML document that has been =
received
- Signature Data. These elements apply digital =
signatures to the data in the message. The intention is that this will =
use the results of the joint W3C/IETF XMLDSIG working group
- Status Data. These elements describe the =
success or failure of a process which the protocol is used to =
initiate.
- XML Message Structure. This element will =
describe how the other Common XML Message elements can be combined to =
form a basic XML document for a protocol message that can be used to =
"wrap" data which is domain specific.
The intention is not to duplicate the effort of =
others. For example, if W3C standardizes the packaging of arbitrary =
data, then this working group would use the results of their work.
Document Exchange =
Architecture
This will define how to use =
the Common XML Message Elements to exchange documents between the =
parties involved in the protocol. Specifically the following areas will =
be considered.
- Simple Document Exchange. This will describe =
how to carry out a Document Exchange consisting of Request Messages and =
Response Messages that:
- Initiate a process on a remote system. This =
will describe how to use a message that conforms to the XML Message =
Structure to request the initiation of a process at a remote location, =
and
- Receive the results of a process. This will =
describe how to construct a message using the XML Message Structure =
that responds to the request and describes the success, or failure, of =
the process
- Combining Document Exchanges. This will =
describe how to combine two or more Simple Document Exchanges between =
two or more organizations into higher level processes for greater =
functionality
- Process Authorization. This will describe how =
to determine if the XML document that forms a request message is =
authorized and therefore the requested document exchange should be =
carried out, particularly when authorization is dependent on the =
successful completion of an earlier document exchange
- Problem Reporting. How to report errors found =
in messages so that the problems in systems that caused the error can =
be resolved
- Idempotency. This will describe standard =
approaches towards handling duplicate messages and data that has been =
received.
- Restarts and Recovery. If a document exchange =
fails this will describe standard approaches towards recovering from =
the failure.
Common Document =
Exchanges
These are common Document =
Exchanges that use the Document Exchange structure described above to =
implement commonly used functionality:
- Process Inquiry. This will describe a Document =
Exchange that can be used to inquire on the current status of any other =
process that is supported by a protocol based on XML =
Messaging.
- Ping Transaction. This will describe a =
Document Exchange that can be used to determine if the servers and =
systems that are supporting a protocol based on XML Messaging are =
available and functioning.
- Authentication. This will describe a Document =
Exchange that can be used to discover information about and =
authenticate another system or user of the protocol.
Development Approach
Three documents are to be =
developed that correspond to each of the three groupings above. While =
some work will proceed in parallel on all three groups, they are =
expected to be advanced for standardization in the order listed =
above
Goals and Milestones:
To be completed.
------_=_NextPart_000_01BEBF18.11831078--
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Fri Jun 25 15:44:21 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02628
for ; Fri, 25 Jun 1999 15:44:20 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa12267; 25 Jun 99 15:28 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa12255;
25 Jun 99 15:27 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_3773_d7c2_d837;
Fri, 25 Jun 1999 20:25:54 +0100
Message-Id:
From: David.Burdett@mondex.com
To: ietf-trade@elistx.com
Subject: RE: XML Messaging Draft Charter
Date: Fri, 25 Jun 1999 20:27:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Andrew
Thanks for providing the information. I've had a quick look at SML (smartX
Markup Language) and what it seems to be is a way for applications running
on a system to send messages created using XML to a smart card driver
without having to understand the machine/operating system specific APIs to
use.
I don't think it's addressing the same area as XML Messaging which focusses
primarily on how two (or more) systems attached to the internet can invoke
(and manage, respond to, etc.) processes remotely using XML messages.
Thanks
David
> ----------
> From: Marchewka, Andrew[SMTP:Andrew.Marchewka@cibc.com]
> Sent: 25 June 1999 06:09
> To: ietf-trade@elistx.com
> Subject: XML Messaging Draft Charter
>
> <>
> Dave,
>
> Attached is some info about another use of XML ... for smart card
> application development...
>
> Andrew Marchewka
>
> CIBC
>
> ======================================
>
> Dear DML subscribers
>
> To stimulate your smart card neurons, I thought I'd open a discussion
>
> thread on today's press release on SmartX Framework
> (http://biz.yahoo.com/bw/990621/ca_gemplus_1.html). I've heard good
> things about it and based on the comments of IBM, Sun and Microsoft,
> they seem to agree. Its my understanding that this technology allows
>
> developers to work on the business/application issues and use XML
> libraries for the card specific details (MPCOS, ME2000, JavaCard,
> Smart Card for Windows, TB100, etc.).
>
> I believe application developers, especially those entering the
> industry from the personal computer industry, will embrace this
> technology as it allows them to focus on the application development
> instead of the card operating system.
>
> What do you think?
>
>
> I've posted part of the press release below and if you really want to
>
> study what SmartX is, go to http://www.smartxml.com for a tutorial
> and
> FAQ.
>
> SmartX separates application development from the complexity of smart
>
> card device management, a breakthrough that for the first time allows
>
> easy implementation of the same application on different types or
> generations of smart card. Based on the eXtensible Markup Language
> (XML) standard, smartX allows developers to write smart card
> applications independent of manufacturer-specific card management
> protocols, essentially enabling them to write ``virtual smart card
> objects'' that are platform (card and terminal) independent.
>
>
> Charles Cagliostro
> SCIA Board
>
>
> ______________________________
> Forward Header
> __________________________________
> Subject: XML Messaging Draft Charter
> Author: "David.Burdett@mondex.com"
> [SMTP:David.Burdett@mondex.com] at
> NA01
> Date: 24/06/99 7:18 PM
>
>
> In the last IETF meeting, in
> Minneapolis, I gave a presentation on
> "XML Messaging" which suggested
> extracting from IOTP the ideas it
> contained on handling messages so
> that they could form a separate
> standard that would have wider
> applicability. During the meeting
> this was thought a good idea.
>
> The attached HTML document (and plain
> text below) contain an *initial*
> draft for a charter for an XML
> Messaging working group that might be
> formed to develop the standard.
> Please note that:
> * it IS a draft - comments ARE
> welcome
> * I do not presume that a working
> group will be formed - that is the
> decision of the IESG
>
> However I would like to start
> informal discussion on the idea. So
> any comments are really welcome,
> particularly from groups, not
> necessarily within the IETF, that
> might make use of XML Messaging. It
> is important that the requirements of
> a good cross-section of potential
> users of XML messaging are included
> in this work.
>
> I also suggest, with the chair's
> permission, that ideas on what to do
> in the area of "XML Messaging" is
> discussed during the Trade WG
> meetiing at the next IETF meeting in
> Oslo on July 14.
>
> Regards
>
> David Burdett
>
> Draft charter as HTML ...
> <>
>
> ... and as text ...
> ====================================
> XML MESSAGING (XMLMSG)
>
> Chair(s):
>
> [TBD]
>
> [Applications/Transport] Area Director(s):
>
> TBD
>
> [This potentially could be either the Applications Area or Transport Area
> or
>
> joint in both areas.]
>
> Area Advisor:
>
> [TBD]
>
> Mailing Lists:
>
> General Discussions: ietf-xmlmsg@xxx
> To Subscribe: [TBD]
> Archive: [TBD]
>
> Description of Working Group:
>
> Purpose
>
> The Extensible Mark-Up Language (XML) (see
> http://www.w3.org/TR/1998/REC-xml-19980210) is becoming popular as the
> basis
>
> for Internet protocols such as IOTP and RosettaNet. Other existing
> protocols
>
> also state an intention to migrate to XML such as OFX and FSML. [please
> suggest other appropriate standards]
>
> Many of these protocols have common requirements which are independent of
> the purpose of the protocols, the information they are carrying or the
> processes that these protocols initiate and control.
>
> The purpose of the XMLMSG working group is to develop standard approaches
> to
>
> common requirements for these protocols so that solutions may benefit from
>
> re-usability of software components and enhanced interoperability.
>
> The list of requirements is described below under three headings:
> 1) Common XML Message Elements
> 2) Document Exchange Architecture
> 3) Common Document Exchanges
>
> Common XML Message Elements
>
> The following are to be considered as common XML Message elements:
> 1) Standard Message Header. These elements will identify, describe and
> classify the XML documents that make up the messages in the protocol
> 2) Packaged Data. An XML element that can be used to encapsulate any
> arbitrary data, for example binary data, or other XML documents, inside an
>
> XML document
> 3) Message Error Data. These elements specify the nature and position of
> errors found in an XML document that has been received
> 4) Signature Data. These elements apply digital signatures to the data in
> the message. The intention is that this will use the results of the joint
> W3C/IETF XMLDSIG working group
> 5) Status Data. These elements describe the success or failure of a
> process
> which the protocol is used to initiate.
> 6) XML Message Structure. This element will describe how the other Common
> XML Message elements can be combined to form a basic XML document for a
> protocol message that can be used to "wrap" data which is domain specific.
>
> The intention is not to duplicate the effort of others. For example, if
> W3C
>
> standardizes the packaging of arbitrary data, then this working group
> would
> use the results of their work.
>
> Document Exchange Architecture
>
> This will define how to use the Common XML Message Elements to exchange
> documents between the parties involved in the protocol. Specifically the
> following areas will be considered.
> 1) Simple Document Exchange. This will describe how to carry out a
> Document
> Exchange consisting of Request Messages and Response Messages that:
> a) Initiate a process on a remote system. This will describe how to
> use a message that conforms to the XML Message Structure to request the
> initiation of a process at a remote location, and
> b) Receive the results of a process. This will describe how to
> construct a message using the XML Message Structure that responds to the
> request and describes the success, or failure, of the process
> 2) Combining Document Exchanges. This will describe how to combine two or
> more Simple Document Exchanges between two or more organizations into
> higher
>
> level processes for greater functionality
> 3) Process Authorization. This will describe how to determine if the XML
> document that forms a request message is authorized and therefore the
> requested document exchange should be carried out, particularly when
> authorization is dependent on the successful completion of an earlier
> document exchange
> 4) Problem Reporting. How to report errors found in messages so that the
> problems in systems that caused the error can be resolved
> 5) Idempotency. This will describe standard approaches towards handling
> duplicate messages and data that has been received.
> 6) Restarts and Recovery. If a document exchange fails this will describe
> standard approaches towards recovering from the failure.
>
> Common Document Exchanges
>
> These are common Document Exchanges that use the Document Exchange
> structure described above to implement commonly used functionality:
> 1) Process Inquiry. This will describe a Document Exchange that can be
> used
> to inquire on the current status of any other process that is supported by
> a
>
> protocol based on XML Messaging.
> 2) Ping Transaction. This will describe a Document Exchange that can be
> used
>
> to determine if the servers and systems that are supporting a protocol
> based
>
> on XML Messaging are available and functioning.
> 3) Authentication. This will describe a Document Exchange that can be used
>
> to discover information about and authenticate another system or user of
> the
>
> protocol.
>
> Development Approach
>
> Three documents are to be developed that correspond to each of the three
> groupings above. While some work will proceed in parallel on all three
> groups, they are expected to be advanced for standardization in the order
> listed above
>
> Goals and Milestones:
>
> To be completed.
>
>
>
> **************************************************************************
> **
> ****
> **************
>
> 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 postmaster@mondex.com 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: postmaster@mondex.com
> 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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Fri Jun 25 22:21:18 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11152
for ; Fri, 25 Jun 1999 22:21:17 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa16613; 25 Jun 99 22:05 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa16589;
25 Jun 99 22:04 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_3774_34c2_de2b;
Sat, 26 Jun 1999 03:02:42 +0100
Message-Id:
From: David.Burdett@mondex.com
To: ietf-trade@elistx.com, hiroya@sdl.hitachi.co.jp
Subject: RE: Error Handling
Date: Sat, 26 Jun 1999 03:04:12 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
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: David.Burdett@mondex.com[SMTP:David.Burdett@mondex.com]
> Sent: 20 June 1999 21:29
> To: ietf-trade@elistx.com; hiroya@sdl.hitachi.co.jp
> 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:hiroya@sdl.hitachi.co.jp]
> > Reply To: hiroya@sdl.hitachi.co.jp
> > Sent: 19 June 1999 19:28
> > To: David.Burdett@mondex.com; ietf-trade@elistx.com
> > 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
> > > <> <>
> > >
> >
> >
> >
> > -----
> > Masaaki Hiroya
> > Systems Development Laboratory
> > Hitachi, Ltd.
> > tel: +81-44-549-1531
> > fax: +81-44-549-1640
> > email: hiroya@sdl.hitachi.co.jp
> > -----------------------------------------------------------------------
> > Message addressed to: ietf-trade@lists.elistx.com
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
> WebSite: http://www.mondexinternational.com
>
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: ietf-trade@lists.elistx.com
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: ietf-trade-request@lists.elistx.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 postmaster@mondex.com 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: postmaster@mondex.com
WebSite: http://www.mondexinternational.com
*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com
From ietf-trade-owner@one.eListX.com Fri Jun 25 22:48:55 1999
Received: from one.eListX.com (one.elistx.com [209.116.252.130])
by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12600
for ; Fri, 25 Jun 1999 22:48:53 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa16573; 25 Jun 99 22:05 EDT
Received: from mondex1fd.mondex.com by one.eListX.com id aa16558;
25 Jun 99 22:04 EDT
Received: from MONDEX1FD [62.172.111.130]
(HELO localhost)
by mondex1fd.mondex.com (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_0050_3774_34ba_de18;
Sat, 26 Jun 1999 03:02:34 +0100
Message-Id:
From: David.Burdett@mondex.com
To: ietf-trade@elistx.com
Subject: IOTP Error Handling
Date: Sat, 26 Jun 1999 03:04:09 +0100
X-Mailer: Internet Mail Service (5.5.2448.0)
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
I've finished re-working the IOTP Error handling and attach:
1. The new text for Chapter 4
2. A new "ConsumerLogic" file which shows the logic required for the
Consumer role in a similar way to ServerLogic.
3. An updated ServerLogic.txt file which contains some, mainly minor,
revisions. There is a list of comments at the start of the file that shows
what changes have been made.
As before the ConsumerLogic and ServerLogic files are drafts, so if there
are any comments please let me know.
Finally I'm now close to finalising the next "04" version of the IOTP
specification. All that is left to do is to revise the signature handling to
reflect the changes in Kent Davidsons last draft. This should not take long
and I'll be sending the revised copy to Don Eastlake, probably early next
week.
David
<> <> <>
begin 600 IOTP Error Handling.txt
M#0H-"@T*("!);G1E7!E2D@=VAI8V@@:7,-"B`@("`@("`@
M(&)E:6YG(&-A2!C86X@869F96-T(&%N>2!A='1E;7!T(&%T($E/5%`-"B`@8V]M;75N
M:6-A=&EO;BX@5'EP:6-A;&QY('1H97D@87)E(&AA;F1L960@:6X@82!S=&%N
M9&%R9"!F87-H:6]N('=I=&@@80T*("!L:6UI=&5D(&YU;6)E6EN9R!T:&4@=')A;G-M:7-S:6]N
M+"!O<@T*#0H@("`@("!O(&-A;F-E;&QI;F<@=&AE('1R86YS86-T:6]N+@T*
M#0H@(%=H96X@8V]M;75N:6-A=&EO;G,@87)E(&]P97)A=&EN9R!S=69F:6-I
M96YT;'D@=V5L;"P@82!T96-H;FEC86P@97)R;W(-"B`@:7,@:6YD:6-A=&5D
M(&)Y(&%N($5R2!W:&EC
M:"!D971E8W1E9"!T:&4@97)R;W(@:6X-"B`@86X@24]44"!M97-S86=E('1O
M('1H92!P87)T>2!W:&EC:"!S96YT('1H92!E2(-"B`@8V]R2!A&%M<&QE+"!A;@T*("!O9F9E6UE;G0@97)R;W(@8G5T#0H@(&UA:V5S(&YO('-E;G-E
M(&9O2!E2!C86X-"B`@9&5C:61E
M('=H870@=&\@9&\@;F5X="X@1F]R(&5X86UP;&4L(&EF('1H92!E6UE;G0@'!L:6-I="!T2!A;F0L
M(&%F=&5R('-O;64@;G5M8F5R(&]F(&%U=&]M871I8R!R971R:65S+"!T;PT*
M("!I;F9O7-T96T@2!S:&]U;&0@9V5N
M97)A;&QY(&)E(&QO9V=E9`T*("!A;F0@:68@875T;VUA=&EC(')E8V]V97)Y
M(&ES('5N2!B92!I9VYO2P@=&AE#0H@(&]V97)A;&P@;65S2!#:&5C:W,N#0H-"B`@5&AE($)L;V-K($QE=F5L($%T=')I8G5T
M92`F($5L96UE;G0@8VAE8VMS(&%R93H-"@T*("`@("`@;R!C:&5C:VEN9R!T
M:&%T(&5A8V@@871T0T*("`@("`@("!R=6QE2!#:&5C:W,@8V]N2!#:&5C:W,B('1H96X@:70@:7,@<')O8V5S2!T:&4@24]44"!!=V%R92!A<'!L:6-A=&EO;B!O7-T96T@6UE;G0@2!T:&4@;W1H97(@
M=')A9&EN9R!R;VQE(')E+0T*("!T0T*("!S96YD:6YG('1H96T@86X@17)R
M;W(@0V]M<&]N96YT("AS964@0T*("!!='1R:6)U=&4@6UE;G0-"B`@<')O=&]C;VP@8F5I;F<@=7-E9"`H&%M<&QE(&EF('1H
M92!#2!A(&-O;6)I;F%T:6]N
M(&]F(&)L;V-K2!I;B!F
M=71U2!O
M9B!C;VUB:6YA=&EO;G,@;V8@2X@1F]R
M(&5X86UP;&4L(&$@8W5S=&]M97(@<&%Y:6YG(&9O2!T:&4@9G5L;"!A;6]U;G0@;VYL>2!O;F-E+B!-
M;W-T(&YE='=O2!A('!A0T*("!A8V-E<'1A8FQE+@T*#0H-"B`@-"XU(%-E
M2!397)V97(@4F]L97,@;75S
M="!B90T*("!A8FQE('1O.@T*#0H@("`@("!O($EN:71I871E(&$@=')A;G-A
M8W1I;VX@*'-E92!S96-T:6]N(#0N-2XQ*2X@5&AE6UE;G0@6EN9R!I9B!T:&4@;65S2!T;R!H86YD;&4@:70-"B`@("`@("`M('!R;V-E'!E8W1E
M9"!B=70@:&%S(&YO=`T*("`@("`@("!B965N(')E8V5I=F5D(&EN(&$@2!O9B!D:69F97)E;G0@='EP97,@;V8@=')A
M;G-A8W1I;VXN#0H@(%-P96-I9FEC86QL>3H-"@T*("`@("`@;R!A;B!);G%U
M:7)Y(%1R86YS86-T:6]N("AS964@2!O9B!(87)D17)R;W(@86YD(&%N($5R2!A('9A
M;&ED(&EN<'5T#0H@(&UE2!I;B!E2!E2`B:61E;G1I8V%L(B!M97-S86=E2!A;F0@4&EN9R!T2!T:&%T(&$@2!D96QA>6EN9R!T:&4@:6YP=70@
M;V8-"B`@("`@("`@("`@;65S2!C86QC=6QA=&5D+"!A;F0-"B`@("`@("`M
M('1H92!H87-H('9A;'5E7!E#0H-"B`@268@=&AE(&UE2!297%U97-T#0H@("`@
M("`@(&]R(&%N($EN<75I2!S96YT('1H96X@
M:70-"B`@("`@("`@(&ES(&$@2&%R9"!%0T*("`@("`@("`@
M8F5E;B!S96YT('1H96X@:70@:7,@82!(87)D($5R6UE;G0@4F5Q
M=65S="!";&]C:R`H4&%Y;65N="!(86YD;&5R(&]N;'DI+B!#:&5C:R!A6UE;G0@4F5Q
M=65S="!";&]C:R!R969E6UE;G0@0V]M<&QE=&5D3VL@3U(@
M9F%I;&5D('=I=&@@82!N;VXM#0H@("`@("`@("!R96-O=F5R86)L92!#;VUP
M;&5T:6]N($-O9&4@=&AE;B!I="!I6UE;G0@:7,@&-H86YG92!";&]C:R`H4&%Y;65N="!(
M86YD;&5R(&]N;'DI+B!#:&5C:R!A6UE;G0@17AC:&%N9V4@0FQO8VL@9&]E2!297%U97-T("A$96QI=F5R>2!(86YD;&5R($]N;'DI
M+B!)9B!T:&4@1&5L:79E2!%6UE;G0@
M4F5Q=65S=',@2!D:60@;F]T(&MN;W<@
M=&AE(&-O2!M97-S
M86=E2!B92!G96YE0T*
M#0H@(#0N-2XT(%)E=')A;G-M:71T:6YG($UE2!O9B!T:&4@5')A;G-P;W)T($UE8VAA;FES;2!B
M96EN9R!U2!R96-O=F5R960-"B`@("`@("`@;&%T97(L(&]R#0H-"B`@("`@(&\@
M5&EM961/=71.;U)C=G(@:68@=&AE('1R86YS86-T:6]N(&ES(&YO;BUR96-O
M=F5R86)L90T*#0H-"B`@-"XV($-L:65N="!2;VQE(%!R;V-E&%M
M<&QE+`T*("`@("`@("`@("!M87D@=&%K92!O;B!T:&4@5')A9&EN9R!2;VQE
M(&]F(&$@0V]N6UE;G0@6EN9R!I9B!T:&4@;65S0T*("`@("`@("!T:&4@57-E'!E8W1E9"!B=70@:&%S(&YO=`T*("`@("`@("!B965N(')E
M8V5I=F5D(&EN(&$@2!4&-E<'0@:6X@=&AE(&%R96$@;V8@8VAE8VMI;F<@9F]R#0H@($5R2!I9B!R=6YN:6YG(&]N(&$@2!297%U97-T(&%N9"!297-P;VYS92!";&]C:W,L#0H-"B`@("`@
M(&\@075T:&5N=&EC871I;VX@4F5Q=65S="P@4F5S<&]N2!T:&4@0V]N7-T96T@=&AE;B!T:&5R92!I&-H86YG92!"
M;&]C:RX@0VAE8VL@87,@9F]L;&]W&-H86YG92!D;V5S;B=T(')E9F5R('1O(&%N($E/5%`@5')A
M;G-A8W1I;VX-"B`@("`@("`@('=H97)E(&5I=&AE6UE;G0@4F5Q
M=65S="!O6UE;G0@17AC:&%N9V4@8FQO8VL@=V%S#0H@("`@("`@
M("!M;W-T(')E8V5N=&QY('-E;G0@=&AE;B!T:&5R92!I6UE;G0@4F5S<&]N7-T96T-"B`@("`@("`@('1H96X@=&AE6UE;G0@4F5Q=65S="!O6UE;G0@17AC:&%N9V4@8FQO8VL@=V%S#0H@("`@("`@("!M;W-T(')E8V5N
M=&QY('-E;G0@=&AE;B!T:&5R92!I2!S96YT('1H96X@=&AE7-T96T@87,@82!R97-U
M;'0@;V8@86X@97AT97)N86P@"!);G1E7!E#0I#87-E16YT51R86YS86-T:6]N#0H)1&\@4W1A
M2!3=&%R=$%U=&AE;G1I
M8V%T:6]N5')A;G-A8W1I;VX-"@E$;R!3=&%R=$%U=&AE;G1I8V%T:6]N5')A
M;G-A8W1I;VX-"D-A2!#86YC96Q42!I;G-T86YC97,@
M<')O8V5S2!T;R!P&-H86YG92!C;VUP;&5T
M97,@;V8@:68@=&AE2!T;R!A8V-E<'0@86YO=&AE2!E:71H97(@=&AE($-O;G-U;65R(&]R('1H92!42!S879E(&EN<'5T
M(&UE2!297-P;VYS94)L;V-K#0H)"0E$;R!05)E6UE;G0-"@D)"45N9$EF#0H)"45L2`J+PT*"0D)1&\@4')O8V5S6UE;G0@17AC
M:&%N9V4@0FQO8VL-"@D)"41O(%!R;V-E2!A="!A('-U
M:71A8FQE('1I;64@:6YT97)V86PN("HO#0I7:&EL92!$;V-U;65N=$5X8VAA
M;F=E&ES="!W:&5R90T*"2T)=&AE(%!R;V-E2!C
M;W5N=`T*"45L2!I2!N;W0@<&]S
M&-H4W1A='5S('1O(%!R;V-E2!%2!C86QC=6QA=&5D('=H97)E('!O2!P2`J+PT*268@<&]S7!E(&]F(&5N8V%P2!F:6YD:6YG(&5R
M'!E8W1E9`T*"0D)"2T@17)R;W),;V-A=&EO;B!C;VUP;VYE;G0@=&AA
M="!P;VEN=',@=&\@=&AE($5R2!297%U97-T(&]R($EN<75I2!R969E7-T96TN(@T*"45N9$EF
M#0I%;'-E268@26YP=70@365S'!E8W1E9"XB#0H)"45N9&EF#0H)"4EF
M(&EN<'5T($UE2`]($AA'!E8W1E9`T*"0D)+2!%'!E8W1E
M9"XB#0H)"45N9&EF#0H)"4EF('1H92!!=71H96YT:6-A=&EO;B!297%U97-T
M($)L;V-K(&ES(&EN2!T:&4@0V]N2!N;W0@8F4@<')E'!E8W1E9`T*"0D)"2T@17)R;W),;V-A=&EO;B!C;VUP;VYE
M;G0@=&AA="!P;VEN=',@=&\@=&AE($%U=&AE;G1I8V%T:6]N(%-T871U7,@
M(DUE7-T96T@=&AE;@T*"0D)1V5N97)A=&4@
M86X@17)R;W)#;VUP;VYE;G0@=VET:`T*"0D)+2!3979E2`]($AA7,@
M(E103R!";&]C:R!W:71H('1H:7,@=')A;G-A8W1I;VX@2!T:&4@0V]N2`]($AA
M7,@(D%U=&AE;G1I8V%T:6]N(%)E2`]($AA'!E8W1E9`T*"0D)+2!%2XB#0H)"45N9$EF#0H)
M16YD268-"D5L&-H
M86YG92!";&]C:R!D;V5S;B=T(')E9F5R('1O(&%N($EO='!47-T96T@=&AE;@T*"0E'96YE6UE;G0@4F5Q=65S="!O6UE;G0@17AC:&%N9V4@8FQO
M8VL@=V%S(&UO2`]($AA6UE;G0@
M17AC:&%N9V4@0FQO8VL@96QE;65N="P@86YD#0H)"2T@17)R;W(@1&5S8W)I
M<'1I;VX@=&AA="!S87ES(")-97-S86=E(%-E<75E;F-E($5R2XB#0H)16YD268-
M"D5L6UE;G0@4F5S<&]N7-T96TN(@T*
M"45L'!E8W1E9`T*"0DM($5R2!297-P;VYS92!";&]C:R!D;V5S;B=T(')E9F5R('1O
M(&%N($EO='!47-T96T@=&AE;@T*"0E'96YE2!297-P;VYS92!R969E7-T96TN(@T*"45L&-H86YG92!B;&]C:R!W87,@;6]S="!R96-E;G1L>2!S96YT
M('1H96X-"@D)1V5N97)A=&4@86X@17)R;W)#;VUP;VYE;G0@=VET:`T*"0DM
M(%-E=F5R:71Y(#T@2&%R9$5R2!297-P;VYS92!R96-E:79E9"!U
M;F5X<&5C=&5D;'DN(@T*"45N9$EF#0I%;F1)9@T*#0H-"B\J*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ#0H@("`@("`@("`@("`@("`@("`@("!(04Y$3$4@
M15)23U(@04Y$($-!3D-%3"!"3$]#2U,-"BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHO#0I(87)D17)R;W));DEN<'5T365S6UE;G0@;W(@1&5L:79E7-T96T@=&\@2X@270@;6%Y(&)E('5S960@=&\@
M:6YQ=6ER92!O;B!A;B!);W1P(%-E6UE;G0@2&%N9&QE2!(86YD;&5R+B`J+PT*4F5T6UE;G0L(&5T8RD@=&AA="!I7!E(&]F('1H92!I;G%U:7)Y(&%L2!S:6=N960-
M"@E)9&5N=&EF>2!T:&4@&-H4W1A='5S('1O
M.B!3=&%T=7-4>7!E("T@26YQ=6ER>2P@4')O8V5S2!2969E&-H4W1A='5S('1O.B!3=&%T=7-4>7!E("T@
M26YQ=6ER>2P@4')O8V5S&%M
M<&QE(&$@365R8VAA;G0@2!P
M;VQI8VEE2!I&-H86YG90T*"0D)26YC;'5D92!G
M96YE2!297-P
M;VYS92!";&]C:R!F;W(@:6YC;'5S:6]N(&EN(&]U='!U="!M97-S86=E#0H)
M"45N9&EF#0H)"5-E="!);G!U=$UE2!297-P;VYS92!B;&]C:PT*"0E3879E($EN<75I5)E2!297-P;VYS92!";&]C:R!T;R!U<&1A=&4@2!S:6=N960-
M"@E)9&5N=&EF>2!T:&4@&-H4W1A='5S(&]F
M(%!I;F<@5')A;G-A8W1I;VX@=&\Z(%-T871U2!T;R!B92!A<'!R;W!R:6%T92P@=VAE7-T96T@
M6UE;G0@2&%N;&5R
M+B`J+PT*1&\@1V5N97)A=&542!C:&5C
M:VEN9R!C&-H4W1A='5S('1O.B!3=&%T=7-4>7!E("T@075T:&5N
M=&EC871I;VXL(%!R;V-E2`O*B!S
M964@4')O8V5S&-H4W1A='5S('1O.B!3=&%T=7-4
M>7!E("T@075T:&5N=&EC871I;VXL(%!R;V-E&-H4W1A='5S('1O(%!R;V-E&-H4W1A='5S('1O('-T871U
M2!S:6=N960-"@E)9&5N=&EF>2!T:&4@6UE;G0-"CT]/3T]
M/3T]/3T]/3T]/3T]/3T]#0I3970@3V9F97(@1&]C17AC:%-T871U7!E("T@3V9F97(L(%!R;V-E7!E("T@3V9F97(L(%!R;V-E6UE;G1297%U97-T
M#0I)9B!A(%!A>6UE;G1297%U97-T0FQO8VL@:&%S(&)E96X@9V5N97)A=&5D
M('1H96X-"@E3970@3V9F97(@1&]C17AC:%-T871U7!E("T@
M3V9F97(L(%!R;V-E6UE
M;G0@1&]C17AC:%-T871U7!E("T@4&%Y;65N="P@4')O8V5S
M6UE;G0@2&%N9&QE2!B92!C87)R
M:65D(&]U="!A=71O;6%T:6-A;&QY('5S:6YG(&$@6UE;G0@*B\-"@E#6UE;G1297%U97-T0FQO8VL-"CT]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/0T*26YV:71E('1H92!#;VYS=6UE2!$971A:6QS#0HO
M*B!.;W1E('1H92!C:&5C:VEN9R!B>2!T:&4@8V]N6UE;G0@:7,@8F5I;F<@;6%D92!T:&5N
M('1H92!#;VYS=6UE6UE;G0@4F5Q=65S="!";&]C:R!F;W(@:6YC;'5S:6]N(&EN($]U='!U="!-
M97-S86=E#0I%;'-E#0H)1&\@1V5N97)A=&5#86YC96Q";&]C:R`O*B!06UE;G0@05!)(B`J+PT*#0I06UE;G0@97AC:&%N9V4@;65S6UE;G0@6UE;G0@4V]F='=A6UE;G0@1&]C17AC:%-T
M871U7!E("T@4&%Y;65N="P@4')O8V5S6UE;G0@
M4F5S<&]N6UE;G0@:7,@0V]M<&QE=&5D3VL@3U(@1F%I;&5D($%.1"!T
M:&4@0V]M<&QE=&EO;B!#;V1E(&EN9&EC871E6UE;G0@4W1A='5S(&%N9"P@:68@<')E6UE
M;G0@4F5C96EP="!A;F0O;W(@4&%Y;65N="!.;W1E#0H)+RH@3F]T92!T:&%T
M(")I;F9O&%M<&QE.@T*"0DM"6EF(&ET(&ES(&$@65D+`T*"0DM
M"6EF(&ET(&ES(&$@;6EC65D(&]N;'D@:68@=&AE6UE;G0@1&]C17AC:%-T871U6UE;G0@4W1A='5S(&%N9"P@:68@<')E
M6UE;G0@4F5C96EP="!A;F0O;W(@4&%Y;65N="!.;W1E
M(&%N9"!!2!W86YT('1O('1R
M>2!A9V%I;B(@8V]U;&0@8F4@:6UP;&5M96YT960@8GD@9&ES<&QA>6EN9R!A
M('-C2!A9V%I;B!T:&5N#0H)"41E=&5R;6EN92!W:&%T(")4
M6UE;G0@<')O9'5C=`T*
M"0DM"6QO861I;F<@86X@96QE8W1R;VYI8R!C87-H('!A>6UE;G0@<')O9'5C
M="!W:71H(&UO2!T:&]U9V@@=&AE(')E2!O9B!A;F]T:&5R(&)R86YD*2P@
M;W(@6UE;G0@87,@=&AE(&-O;G1E;G0@;V8@=&AE($]F
M9F5R(%)E2!A9V%I;B`J
M+PT*"0E3970@4&%Y;65N="!$;V-%>&-H4W1A='5S('1O('1H92!R97-U;'0@
M8V]N=&%I;F5D(&EN('1H92!3=&%T=7,@0V]M<&]N96YT#0H)16YD268-"D5N
M9$EF#0H-"@T*#"\J*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ#0H@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@1$5,259%4ED@34534T%'15,-"BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHO#0H-"E!R;V-E5)E2!R97-P;VYS92!S96YT(&)Y(&$@1&5L:79E
M2!297-P;VYS92!-97-S86=E#0I);F9O2!F86EL960@=&AE;B!S:&]W:6YG('-T871U6EN9R!W:&%T979E4YO=&4@*B\-"DQO9R!T:&4@2!46UE;G0O
M1&5L:79E7-I
M8V%L3W5T<'5T365S'!E8W1E9"!T:&5N("\J(%!R;V-E"!R971R>2!C;W5N=`T*"45N9$EF#0H)4V5N9"!T
M:&4@9V5N97)A=&5D(&]R(')E=')I979E9"!M97-S86=E#0I%;'-E#0H)4V%V
M92!T:&4@9V5N97)A=&5D(&UE