Subject: RE: My Comments of IOTP Spec Release4

From: [email-masked]
Date: Wed, 28 Jul 1999 03:40:12 +0100

Yoshiaki

Appologies for the delay in responding but since my return from the IETF in
Oslo I've had no time to look at this. Anyway here goes ... comments marked
with ##

David
PS Having worked through all these you have been very thorough. Thanks.
> ----------
> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> Sent: 	05 July 1999 01:43
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	My Comments of IOTP Spec Release4
> 
> David,
> My comments of the IOTP Specification Release4 as follows:
> 
> ---
> 1.6 Document Structure (Page 14 )
> DigiCash is the company name so please change to eCash.
## agreed ... but Digicash was actually in section 1.5 Scope of Document##

> ---
> 
> 3.1.1 (Page34) 
> Minor misspelling:
>  |  |-Certificate Comp. < Certificate Component (0ptional) Used to chec
>                                                  ^
> Please change from integer "0" to Alphabet "O".
##Noted##

> ---
> 
> 3.3.2  MsgId Component
> There is no description of LangPrefList and CharSetPrefList.
## Added as follows
LangPrefList ...
	Optional list of Language codes that conform to [XML] Language
Identification. It is used by the sender to indicate, in preference
sequence, the languages that the receiver of the message ideally should use
when generating a response. There is no obligation on the receiver to
respond using one of the indicated languages, but using one of the languages
is likely to provide an improved user experience.

CharSetPrefList ...
	Optional list of Character Set identifiers that conform to [XML]
Characters. It is used by the sender to indicate, in preference sequence,
the character sets that the receiver of the message ideally should use when
generating a response. There is no obligation on the receiver to respond
using one of the character sets indicated, but using one of the character
sets is likely to provide an improved user experience.

Also added the following explanation to Section 3.8 Identifiying Languages
as follows ...
A sender of a message, typically a Consumer can indicate a preference for a
language, and a character set by specifying a list of preferred
languages/character sets in a Message Id Component (see section 3.3.2). Note
that there is no obligation on the receiver of such a message to respond
using one of the listed languages/character sets as they may not have the
technology to be able to do it. It also means that the ability to handle
these lists is not a requirement for conformance to this specification.
However the ability to respond, for example using one of the stated
languages/character sets is likely to provide a better user experience.

These attributes were added to meet and indicated requirement of SET version
2.0. Apologies for not discussing it on the list ... no doubt if anyone has
any contrary views you'll let me know.
##

> --
> 3.4.1 Trading Role Element
> There is no definition the IotpMsgIdPrefix for DelivTo.
> DelivTo Trading Role does not use this because DelivTo does not
> send the IOTP Message. But IotpMsgIdPrefix is mandatory.
> Should we set "C" as the Consumer?
##Yes ... clarified spec and suggested "C" for the DelivTo role as a
guideline##

> ---
> 
> 3.6.1 Extra XML Elements
> IOTP:Critical (True|False) #TRUE
> should be changed to
> IOTP:Critical (True|False) 'True' 
##Corrected##

> --
> 
> 4.5.2.1 Checking Structure and Message Identity
> -- Start
>   If the message is well formed but the IotpTransId cannot be identifie
>   then generate an ErrorComponent with:
> 
>       o a Severity of HardError and an ErrorCode of AttMissing,
> 
>       o one PackagedContent containing the original Input Message,
>         and
> 
>       o 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.
> --End
> I have two questions.
> 
> Question 1. If we include two PackagedContent Components in Error
> Component, we have to decide the both Name element(s) so that Consumer
> side OAC recognizes them and handles.
> 
> Question 2. This is the only case that the Original Input Message is
> included in the Packaged Content of Error Component isn't it?
	## See other email##
> --
> 
> 4.5.2.3 Processing Non-Duplicate Message
> Please add the description of the transient error as follows:
> Current:
>       o 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
> New:
>       o if no hard error and transient error result, 
>         then processing the message and
>         generating an output message, if required, for return to
>         the sender of the Input Message
##Agreed. Exact new wording as follows:
	"o if neither hard errors nor transient errors result, then
processing the message and generating an output message, if required, for
return to the sender of the Input Message"

	Also changed ServerLogic.txt and ConsumerLogic.txt files.
##

> --
> 
> 4.5.3 Cancelling a Transaction
> In 4.5.3,
> --Start
>       o if the IotpTransId refers to Inquiry Transaction or a Ping
>         Transaction then fail the request, otherwise
> --End
> 
> We use the same IotpTransId, which is used in the Payment
> Transaction, whenever the Inquiry Transaction is processed. So we
> should revise the above description as follows:
> 
>       o if the IotpTransId refers to a Ping
>         Transaction then fail the request, otherwise
##Disagree. What I intended, but perhaps didn't make clear, was that that
this process is used to generate a cancel block to be sent to the other
party. For example, if a Payment Handler decides to cancel a transaction for
some business reason, then there needs to be a way for the cancellation to
be communicated to the IOTP Server for the Payment Handler so that it can
generate the Cancel Block. So if clarified this section as follows.

This process is used to cancel a transaction running on an IOTP server. It
is initiated by some other process as a result of an external request from
another system or server that is being run by the same Trading Role. The
processing required is as follows:
*	if the IotpTransId of the transaction to be cancelled is not
recognised, or complete then fail the request, otherwise
*	if the IotpTransId refers to an Inquiry Transaction or a Ping
Transaction then fail the request, otherwise
*	determine which Document Exchange to cancel and generate a Cancel
Block and send it to the other party
	[Note]	Cancelling a transaction on an IOTP server typically arises
for a business reason. For example a merchant may have attempted
authentication several times without success and as a result decides to
cancel the transaction. Therefore the process that decides to take this
action needs to send a message from the process/server that made the
business decision to the IOTP server with the instruction that the IOTP
transaction should be cancelled.
	[Note End]	 
##

> --
> 
> 7.4 Trading Role Information Request Component
> In 7.4,
> 
> -- Start
>       o a Merchant requesting that a Consumer provides Organization
>         Components for the Consumer and DelivTo Trading Roles
> -- End
> 
> We get only one Trading Role when we use TradingRoleList because 
> TradingRoleList defines as NMTOKEN. So I suggest to change from
> NMTOKEN to NMTOKENS.
##Agreed##

> --
> 
> 7.7.4 Currency Amount Element
> Could you register "ISO4217-N" on IANA also because this is used in
> the SMILE Project?
##See separate email.##

> --
> 
> 7.10 Payment Scheme Component
> There is no description for the PaymentRef in PatSchemeData.
## Added definition as follows:
	An Element Reference (see section 3.5) to the Payment Component (see
section 7.9) to which this Pay Scheme Data Component relates. It is required
unless the Pay Scheme Data is part of an Transaction Inquiry Status
Transaction (see section 9.2.1).
##

> --
> 
> 7.10 Payment Scheme Component
> The PaymentRef Element is not used when Inquiry transaction is
> processed.  I suggest the PaymentRef changes from #REQUIRED to
> #IMPLIED and we should add the note that the PaymentRef must use in
> the Payment Transaction but does not use in the Inquiry Transaction.
##Agreed. For details see previous comment##

> --
> 
> 7.15.3 Delivery Completion Codes
> There is no description about the recovery possibility for
> DelivCancelled and Confirmed.
##They should both be "Recovery is not possible."##

> --
> 
> 9.2.1 Baseline Transaction Status Inquiry IOTP Transaction
> In 6.1.3:
> --Start
>       o Transaction Status Inquiry. The Inquiry Response Block may
>         be digitally signed to attest to the authenticity of the
>         response
> --End
> 
> 
> But there is no description about the signature of Inquiry Response
> Message
>  in 9.2.1 (and in 7.18 also.)
##Agreed.
Added definitions for Inquiry Reuest Signature and Inqiuiry Reponse
Signature as follows:
	7.18.7	Inquiry Request Signature Component
	If the Inquiry Request is being signed (see section 9.2.1) the
Manifest Element of the Inquiry Request Signature Component should contain
Digest elements of Inquiry Type Component, and if present, the Payment
Scheme Component

	7.18.8	Inquiry Response Signature Component
	If the Inquiry Response is being signed (see section 9.2.1) the
Manifest Element of the Inquiry Response Signature Component should contain
Digest elements of the Trading Response Block and the Status Component.

... and in section 9.2.1 ...
SIGNATURE BLOCK (INQUIRY REQUEST)
	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.

	If present, the Inquiry Request Signature Block (see section 8.12)
contains the following components:
	o one Signature Component (see section 7.18)
	o one or more Certificate Components, if required.

	Inquiry Response Blocks should only be generated if the Transaction
is authorised.

	[Note] 
	Digital signatures on an Inquiry Request is only likely to occur if
the recipient of the request expects the Inquiry Request to be signed. In
this version of IOTP this will require some kind of pre-existing agreement.
This means that:
	o Consumers are unlikely to generate requests with signatures,
although it is not an error if they do
	o the other trading roles may agree that digital signatures are
required. For example a Payment Handler may require that an Inquiry Request
is digitally signed by the Merchant so that they can check that the request
is valid.

	On the other hand if the original transaction to which the Inquiry
relates was carried out over a secure channel (e.g. [SSL]) then it is
probably 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.

	 [Note End] 

... and ...
	SIGNATURE BLOCK (INQUIRY RESPONSE)
	If a signature block is present on the message containing the
Inquiry Response Block then it may be checked by the receiver of the block
to determine if the Inquiry Response is valid.

	If present, the Inquiry Response Signature Block (see section 8.13)
contains the following components:
	o one Signature Component (see section 7.18)
	o one or more Certificate Components, if required.

	 [Note] 
	Digital signatures on an Inquiry Response is only likely to occur if
the recipient of the response expects the Inquiry Request to be signed. In
this version of IOTP this will require some kind of pre-existing agreement.
This means that:
	o Consumers are unlikely to generate responses with signatures,
although it is not an error if they do
	o the other trading roles may agree that digital signatures are
required. For example a Merchant may require that an Inquiry Response is
digitally signed by the Payment Handler so that they can check that the
request response is valid.
	 [Note End] 

... also changed message flow for Transaction Status Inquiry to show
optional signature on Inquiry Response.

##

> Additional, 
> In 9.2.1: 
> -- Start
>      1 --> 2 INQUIRY REQUEST. IotpMsg: TransRef Block; Signature Block
>              (optional); Inquiry Request Block
> -- End
> 
> I could not find the description where the Consumer has to sign in 9.2.1
> (and in 7.18 also.)
## It is unlikely that the consumer will have to sign. See Notes on
Signature Block (Inquiry Response) and Signature Block (Inquiry Request).
##

> --
> 
> 7.15.1 (Page134)
> Minor misspelling:
>  ConsCancelbled-> ConsCancelled
## Changed ##
> --
> 
> Other:
> 
> The current IOTP Spec has not reflected the brand new IOTP-DSIG Draft
> yet.  My thought is that we should split off the description of DSIG
> as much as possible in order to avoid consistency
## In principle they need to be separate, but I don't think so for this
version. I plan to update the IOTP spec to reflect the new dsig draft
shortly. ##

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

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

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

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

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

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

---

From: Yoshiaki KAWATSURA <[email-masked]>
Date: Wed, 28 Jul 1999 16:54:17 +0900 (JST)

David,
I will send some comments for your mails in this week because I have to
discuss with my coleagues except for Cancelling a Transaction.

--
For 4.5.3
> *	if the IotpTransId refers to an Inquiry Transaction or a Ping
I wanna make sure.
Do the descriptions of "the request" above mean "external request from
another system"?

If so, I do not understand why you disagreed.
In the current IOTP, the Consumer generates new IotpTransId 
whenever the Consumer generates the Ping Message. 
But the Consumer uses the IotpTransId corresponding with the Purchase
Transaction which Consumer wants to inquire, so the Consumer does not
create new IotpTransId.

After all, the IotpTransId also refers to an Purchase Transaction if
IotpTransId refers to an Inquiry Transaction.

>>>>> Wed, 28 Jul 1999 03:40:12 +0100,

---

From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 29 Jul 1999 23:57:23 +0900 (JST)

David,
Sound good to me for the following issues.
Thanks,
--
Yoshiaki Kawatsura