Subject: Version 1.0 updates report

From: David Burdett <[email-masked]>
Date: Thu, 21 Jan 1999 02:31:34 -0000

Since there has been some recent discussion on the list, I thought I
would provide the list with the following which shows the changes that
have been made to the IOTP specification to date. These changes have
been made to the "single document" version of the specification and are
separate to the multi-part versiobn being prepared by Kent Davidson.
It's my opinion that we should be able to retrofit these changes to
Kent's version without much difficulty.

Most of the changes that have been made are fairly minor with the
exception of change 11 which has resulted in an effective *rewriting* of
section 8 (IOTP Transactions) of the specification. Section 8 is now
much shorter and has little duplication. Note that the message flows in
the revised version have *not* changed from earlier versions except that
now an Authentication Exchange can precede any purchase, refund,
withdrawal, deposit or value exchange transaction in the same consistent
way.

Of the three outstanding changes (see below) number 6 is trivial. The
other two await input from others.

The current version of the specification is in MSWord (i.e. the pretty
version) and I will send my current working copy to anyone who sends me
an email requesting it. I am reluctant to post this version to the Trade
WG since it needs to go through a conversion process which takes about a
day.

David

OUTSTANDING CHANGES
6)	Text version diagrams. The start and end of diagrams in the ASCII
text versions of the specification are hard to identify. Recommend that
it is made clearer. For example start each diagram with a line of "dash"
characters and end it with a line of "equals" characters.
8)	Digital Signatures. The section on Digital Signatures (section 5)
needs to be updated to reflect how OTP should use the XML signatures as
defined in Richard Brown's Dsig proposal. Action: Don Eastlake
12)	Authentication Method and Authentication Response. In the
Authentication Data Component (section 6.2). Needs to be revised.
Action: Richard Brown.

COMPLETED CHANGES
1)	Packaged Content. There is a need for Packaged Content to contain
multiple items of data e.g. in the Pay Receipt Component, to support
encapsulation of SET messages. To support this propose the following
amendment to the Packaged Content element (see section 3.7.1):
a)	allow multiple occurrences of PackagedContent wherever it occurs.
This makes it a general solution
b)	add an optional Name attribute to the definition of packaged content
which can be used to identify which PackagedContent is used for which
purpose
c)	also clarify description of the Trading Role Data component (see
section 6.16) to suggest that it can contain payment protocol specific
information as well
d)	this change is backwards compatible with Version 1.0
e)	Complete
2)	The definition of the Packaged Content in the Payment Component
suggests that its use is the same as for the Packaged Content in the
Trading Role Data Component. (Raised by 'Yoshiaki Kawatsura'). Suggested
answer Trading Role Data component should be used instead of the
Packaged Content in the Payment Component since it is more general
approach to the problem which allows any two parties to exchange
information. This also means that the Packaged Content element within
the Payment Component should be removed. Complete
3)	Brand ID. SET defines its own rules for identifying Brands with the
structure, "BrandId:Product:PromotionalBrand". Since this naming
convention for Brands already exists, suggest that it is adopted by IOTP
as follows
a)	add "SET" as a valid "BrandIdDomain" for credit cards (see section
6.6.1)
b)	It is also suggested that the SCCD protocol adopts SET conventions
for identifying brands
c)	Complete
4)	Change definition of Brand ID domain to conform to IETF/IANA
conventions. The current convention for identifying Brand Id Domains
(see section 6.6.1) does not conform to IETF/IANA conventions. Suggest
that its definition is changed to comply. Also applies to other names in
IOTP Complete
5)	Registration procedure for new names. Procedures need to be defined
for the registration of new names, for example Brand Id domain. Action
Don Eastlake. Completed.
7)	Correction. CancelNetLocn attribute definition needs to added to the
XML definition given in section 6.5.2. Completed
9)	Net Locations. Change net locations in Protocol Options or Trading
Role Elements to reflect:
a)	SuccessNetLocn - per transaction - Where the Consumer goes if the
transaction is successful
b)	CancelNetLocn - per trading role - where the Consumer goes if the
Consumer cancels the transaction at some point
c)	xxxRequestLocn - where xxx is payment, delivery, etc the location to
which incoming messages with either no errors or technical errors of any
Severity are sent. This means that anybody who sends a message with
errors in it receives a message that indicates there was an error
d)	ErrorLogNetLocn - per trading role, optional -  where the Consumer
sends IOTP messages if they receive an incoming message in which they
detect a technical error with Severity of HardError or TransientError.
Could be used to send error messages to the software company or some
other organisation responsible for fixing problems in the software which
sent the incoming message.
e)	ErrorNetLocn - per trading role - where the consumer goes after
receiving or generating an Error Block with severity of HardError or
TransientError
f)	Also need to provide guidelines which indicate how the consumer
determines which redirect location to use based on where they are.
Complete
10)	Unknown Error. Add an additional error code  (see section 6.19.2)
called UnknownError to indicate that the transaction cannot complete for
some reason. This could be used to indicate an internal error of some
kind. The ErrorDesc attribute should be used to indicate the nature of
the problem. Complete.
11)	Authentication Transaction. 
a)	Standalone Authentication. Add an Auth Status message from the
authenticator to the authenticatee to indicate that success or failure
of the authenticator's validation of the Authentication Response
message.
b)	Pre authentication. Allow purchase, refund, withdrawal, deposit and
value exchange IOTP transactions to be preceded by an optional pre
authentication sequence which does an authentication request and
response and then segue's into the real transaction with a new TPO. A
failed authentication will result in an Auth Status as in the Standalone
Authentication
c)	Note that the Authentication Data Component has been removed from the
Offer Response block and the Payment Request Block, since it's purpose
is now fulfilled by either the pre-authentication or an asynchronous
standalone synchronisation of the Consumer by the Payment Handler. This
also requires remove of AuthDataRef from: the Payment Component.
Complete.
13)	Add a means of canceling a transaction where the consumer can send a
status component to the appropriate server in a cancel block. Complete
14)	Correction, Protocol Options change SenderNetLocn and
SecureSenderNetLocn to #IMPLIED from #REQUIRED since one, the other or
both may be present. Completed

>Mondex International Limited
mailto:<[email-masked]>
>US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA
>94111
Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370

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