Subject: My Comments of IOTP Spec Release4

From: Yoshiaki KAWATSURA <[email-masked]>
Date: Mon, 05 Jul 1999 17:43:36 +0900 (JST)

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.

---

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

---

3.3.2  MsgId Component
There is no description of LangPrefList and CharSetPrefList.

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

---

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

--

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?

--

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

--

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

--

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.

--

7.7.4 Currency Amount Element
Could you register "ISO4217-N" on IANA also because this is used in
the SMILE Project?

--

7.10 Payment Scheme Component
There is no description for the PaymentRef in PatSchemeData.

--

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.

--

7.15.3 Delivery Completion Codes
There is no description about the recovery possibility for
DelivCancelled and Confirmed.

--

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

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

--

7.15.1 (Page134)
Minor misspelling:
 ConsCancelbled-> ConsCancelled
--

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.

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]