Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt

From: David Burdett <[email-masked]>
Date: Thu, 9 Sep 1999 09:15:55 -0700

Yoshiaki/Don/Rudolf.

See comments below marked with &&

David

-----Original Message-----
From: Yoshiaki KAWATSURA [mailto:[email-masked]]
Sent: Thursday, September 09, 1999 4:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt 

David,Don and Rudolf:
========================================================================
> >> 4.5.2.3 Processing Non-Duplicate Message
> >> ...
> >... [Content deleted] ...
> >
> >I believe that idempotency is not required for Ping and Inquiry
> >transaction. Additionaly I believe we do not need to use new
> >IotpTransId , we use the same as the IotpTransId of a Purchase
> >Transaction whenever Inquiry transaction is used.
> >
> >##The part of the spec that says in the Note ...
> >>             ... then an IOTP transaction with a new IotpTransId must be
> >used.
> >... is wrong. It should read ...
> >>             ... then an IOTP transaction with a new value for the ID
> >attribute of the MsgId component must be used.
> >
> >I also agree that idempotency is not really required for inquiry and ping
> >transactions. To my mind the question is, what is going to be simpler to
> >implement? I think we have three possible approaches:
> >1. Cache every transaction and have have the same approach to every
> >transaction (this is what the spec says now), or
> >2. Cache the messages we want to and not the others (i.e. don't cache
ping &
> >inquiry), or
> >3. Leave to an implementation decision, i.e. if you do send the identical
> >message you might get the identical response back but then you might get
an
> >updated one.
> >
> >Option 1 could be simpler to implement in that you have a standard
message
> >content unware process that says "Have I received this before ... yes ...
so
> >I'll resend the last message if its available". As long as inquiries and
> >pings are relatively infrequent then the overhead in storage and
processing
> >should be relatively small.
> >
> >Option 2 would allow people to re-use inquiry requests (but why would you
> >want to?) and would save on what you had to cache but would require that
the
> >content of the message would have to be understood before idempotency
> >processing could occu. FOr example it would require processing along the
> >lines of "What kind of message is it? If it's a Ping or an Inquiry then
I'll
> >process it afresh otherwise I'll resend the last message I sent if one is
> >available."
> >
> >Option 3 would mean that if you really always wanted to be sure of
getting
> >up-to-date information then you would have to adopt approach 1 since
> >behaviour of systems/servers in this area would not be predictable.
> >
> >Which approach do people prefer (or is there another one!) ?
> >##
> ><RH>
> >I would opt on #3, because:
> 
> I think consistency of behaviour is quite important.  Messages may get
> duplicated not just because they are questions being asked again but
> also because of tranmission path quirks.  Packets get duplicated,
> messages that were queues can get re-sent, etc.  Even for long
> messages where they won't fit into a packet, consider the SMTP
> transport and email getting duplicated.  It is even possible for the
> message to be duplicated and then the two responses, which could be
> different due to a change in state, could be re-ordered...
> 	Since we need indempotency sometimes, I think #1 is simplest
> behaviour by providing it all the time.
> 

I think #2 is best because the Consumer always should be able to 
get the current status in the ping and inquiry transaction.
I think there is no meaning if the consumer did not get the current
status.

&&On this point I agree with Don. I think option one is best because it's
consistent and completely independent of the content of the message. This
means that idempotency can be handled at the message "envelope" rather than
the message "content" level. I agree that it is pretty meaningless to get an
old status but there is a simple answer just use a different Message Id and
you will get the up-to-date picture. If the spec says that this is what you
need to do to get an up-to-date picture then it is simple to implement, I
would have thought, at application design time.

So I've added further clarification to the "Transaction Reference Block"
section within section 9.2.1 Baseline Transaction Status Inquiry IOTP
Transaction ...

If up-to-date status information is required then the MsgId Component, and
in particular the ID attribute for the MsgId Component must be different
from any other IOTP Message that has been sent by the Trading Role. This is
required because of the way that Idempotency is handled by IOTP (see section
4.5.2.2 Checking/Handling Duplicate Messages).
@@
----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business & Information Systems Development Division, Hitachi,Ltd.
Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
-----------------------------------------------------------------------
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]
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

---

From: David Burdett <[email-masked]>
Date: Thu, 9 Sep 1999 09:33:46 -0700

See comments marked with &&

David

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:[email-masked]]
Sent: Tuesday, September 07, 1999 5:09 AM
To: [email-masked]
Subject: Re: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt 

From:  Rudolf Hornig <[email-masked]>
To:  "'David Burdett'" <[email-masked]>,
            "'Yoshiaki KAWATSURA'" <[email-masked]>
Cc:  [email-masked]
Date:  Mon, 6 Sep 1999 13:41:32 +0200
Message-ID:  <000101bef85c$c4be7b50$0a00000a@rudolf>
In-Reply-To:  <123B7EB05559D311B0D900A0C9EA3D7604F205@NEPTUNE>

>David and Yoshiakia,
>2. Cache the messages we want to and not the others (i.e. don't cache ping
&
>message you might get the identical response back but then you might get an
>updated one.
>
>Option 1 could be simpler to implement in that you have a standard message
so
>pings are relatively infrequent then the overhead in storage and processing
the
I'll
>Option 3 would mean that if you really always wanted to be sure of getting

&& Agreed see other email&&

>- The resource requirement on doing inquiry and ping transactions
>  higly depends on the implementation and the actual usage of
>  the server. I can imagine scenarios where serving these transactions
>  cost a lot of resources: Using low quality network service (lots of 
>  retransmissions) with Pings requesting signature checking and Inquiries
>  not served locally rather routed to other Existing Payment Systems.
>  In this case Ping/Inquiry idempotency would be a benefit....
>  On the other hand if these transactions doesn't cost too much, but there
>  is a lot of them without too much retransmission, avoiding message 
>  idempotency on these transactions, could spare some computing time and a 
>  lot of database space.
>
>  I would let the implementor decide wheter or not to support msg 
>  idempotency, on this two transaction type. The role, which is sending the
>  ping/inquiry request should generate new msg id, if she wants up to date
>  information...
>
>  An additional question about the meaning of "identical":
><IOTP-DRAFT>
>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.
></IOTP-DRAFT>
>
>  I could imagine 3 definitions for the term "identical"
>  1. The message's IotpTransId and MsgId is the same as the previous.
>  2. The message's content is exactly the same (doing a hash on it
>     produces the same hash value as for the previous message)
>  3. As stated above, all blocks, components, elements, etc are the same...

There should be no difference between 2 and 3.

>  It is quite hard to implement the #3 case as we have to parse the whole
>  message and also the previous msg from the idempotency and compare
>  them on an element/element base. The problem is that not all the elements
>  have an ID attribute, which means that the two message cannot be 
>  compared easyly. For example the two messages are the same except
>  two PackagedContenet element in the same Component where their order
>  has changed... Ok, this is not a real life example I admit...:)
>  So doing an element/element comparation is not easyly implementable
>  and also quite resource consuming, because you have to parse both the
>  original and the newly received message before comparing...

DOM HASH is explicitly designed to make comparison easy.

>  Doing a hash or full comparation on the messages is OK, however I would
>  suggest that a message, with the same IotpTransId and MsgIg should be
>  treated as the same message regardless of their content. It is the
>  senders responsibility, not to alter anything in the message if she
>  uses the same Trans and Msg ID...
>  
></RH>

While I think that is reasonable, doing a hash is a pretty cheap operation
and enables you to compare the entire message quite easily.

&& This one is a close call to my mind. Firstly I'm not really comfortable
with the idea of just checking the IotpTransId and the MsgId as it could be
too easy for someone to guess just these items and therefore get a message
they were not authorised to get. On the other hand checking the whole
message without doing a DOM-hash or giving some hint on how to do it could
lead to inconsistent results. A compromise alternative might be to require
that the Trans Ref Block was the same since it includes additional
information (e.g. timestamp) that would be hard for someone to guess, but
then there could still be problems because of the way the comparison is
made. So as a compromise I will include the following as a note in section
4.5.2.2 Checking/Handling Duplicate Messages ...

 [Note] The recommended way of checking for identical messages is to check
for equal values of their [DOM-HASH]
 [Note End] 

Thanks,
Donald

>Regards, Rudolf
>
>PS: David, could you check also my original
>"Comments on draft-ietf-trade-iotp-v1.0-protocol-05" mail
>as you acknoledged only some of the comments...
>(They are mostly tipos however:)
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Rudolf Hornig ([email-masked]), Project Manager 
>MeTechnology Ltd. Hungary - a Brokat Company
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

---

From: David Burdett <[email-masked]>
Date: Thu, 9 Sep 1999 10:31:45 -0700

I never completely responded to this email so see comments marked below with
a ##.

David

-----Original Message-----
From: Rudolf Hornig [mailto:[email-masked]]
Sent: Wednesday, September 01, 1999 12:22 AM
To: IOTP Trade List (E-mail)
Cc: =?iso-8859-1?Q?Varga_Andr=E1s?=@metechnology.com
Subject: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt

Here comes some comments on the lates IOTP draft:

========================================================================
2.2.1 Offer Exchange
...
     C <-- M OFFER RESPONSE. Components: Organisation(s) (Consumer,
             DeliverTo, Merchant, Payment Handler, Customer Care); Order;
             Pay Amount; Delivery; Optional Offer Response Signature that
             signs other components

RH> "Pay Amount" should be "Paymnet".
RH> Status and TradingRoleData are missing, and also from the following
RH> list.
##Fixed##
========================================================================
2.2.2 Payment Exchange
...
     C --> M        Component: Brand List Selection

 4.                 Merchant checks Brand Selection, creates a Payment
                    Amount information, optionally signs it to authorise
                    payment and sends it to the Consumer

     C <-- M        Component: Pay Amount; Organisation(s) (Merchant and
                    Payment Handler); Optional Offer Response Signature
                    that signs other components

 5.                 Consumer checks the Payment Amount information and if
                    OK requests that the payment starts by sending
                    information to the Payment Handler

     C --------> P  PAYMENT REQUEST. Components: Pay Amount; Organisations
                    (Merchant and Payment Handler); Optional Offer
                    Response Signature that signs other components; Pay
                    Scheme

 6.                 Payment Handler checks information including optional
                    signature and if OK starts exchanging Pay Scheme
                    components for selected payment brand and payment
                    protocol

     C <-------> P  PAYMENT EXCHANGE. Component: Pay Scheme

 7.                 Eventually payment protocol messages finish so Payment
                    Handler sends Pay Receipt and optional signature to
                    the Consumer as proof of payment

     C <-------> P  PAYMENT RESPONSE. Components: Pay Receipt; Payment
                    Note; Optional Offer Response Signature; Optional
                    Payment Receipt Signature that binds the payment to
                    the Offer
RH> - in general: "Payment Amount" -> "Payment"
RH>               "Pay Scheme" -> "PaySchemeData"
RH> - in 5. There are missing components like: Status; BrandList;
RH>   BrandSelection; TradingRoleData
RH> - in 7. Missing components: Status; PaySchemeData; TradingRoleData;
RH> - These components are also missing from the list following Figure 3
##Fixed##
========================================================================
2.2.3 Delivery Exchange
...
     C --------> D  DELIVERY REQUEST. Components: Delivery, Organisations:
                    (Merchant, Delivery Handler, DelivTo); Order, Optional
                    Offer Response Signature, Optional Payment Receipt
                    Signature (from Payment Exchange)
RH> Missing: Status; ConsumerDeliveryData; TradingRoledData

 4.                 Delivery Handler checks information and authorisation.
                    Starts or schedules delivery and creates and then
                    sends a delivery not tot the Consumer which can
RH> sends a delivery NOTE TO the Consumer
...
     C <-------- D  DELIVERY RESPONSE. Components: Delivery Note, Optional
                    Delivery Response Signature
RH> Missing: Status
RH> These components are also missing from the list following Figure 4
##Fixed##
========================================================================
2.3 Scope of Baseline IOTP
RH> Because the Inquiry and Ping transactions could be initiated
RH> by any trading role, in the "supported Roles/Transaction table" 
RH> I would mention, that a Consumer should only be able to send
RH> Inquiry and Ping transaction. Serving these transactions is 
RH> not a requirement as the Consumer role is represented by an
RH> HTTP client (according to the http supplement)
##Changed MUST to MAY for consumer role##
========================================================================
3.3.1 Transaction Id Component
...
 IotpTransId        Contains data which uniquely identifies the IOTP
                    Transaction. It must conform to the rules for
                    Message Ids in [RFC 822].

RH> I'm not sure about this, but [RFC 822] defines the message id
RH> as: <some.string@shost>, however NMTOKEN doesn't allow a '@'
RH> character...
##Changed NMTOKEN to CDATA##
========================================================================
3.6.1 Extra XML Elements
...
 In order to ensure that documents containing "IOTP:Critical" are valid,
 it is declared as part of the DTD for the extra element as:

 IOTP:Critical     (True | False ) 'True'

RH> Haven't found it in the actual DTD.
RH> This means it SHOULD BE DECLARED as part of the extended DTD ?
##YES!##
========================================================================
4.5.2.3 Processing Non-Duplicate 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]                  
RH> However in "9.2.1 Baseline Transaction Status Inquiry IOTP Transaction:"
...
 TRANSACTION REFERENCE BLOCK

 A Trading Role making an inquiry must use the identical Transaction Id
                                               ^^^^^^^^^
 Component (see section 3.3.1) that was in the original transaction. The
...

RH> The two requirements are inconsistent as far as I see.
RH> BTW. Is it really required for IOTP to cache all the Ping and
RH> Inquery transactions ??? (They do not change anything in the server)
RH> If idempotency is required, I would suggest using a new message ID
RH> with the same IotpTransId, but this case every trading role have
RH> to maintain it's last MessageID, which is not nice at all...
RH> Or perhaps changing the TimeStamp of the MessageID comp. is enough
RH> to force the server to give back fresh information ???? (ugly also)
RH> Maybe a trading role wants to inquery a 
RH> transaction a week later, and the last used message id for
RH> this transaction is not present... Any hint on this? 
##Resolved with other emails##
========================================================================
4.6.2.1 Check for Errors in Block Sequence
...
 o Offer Response Block. Check as follows:
   - if the Offer Response Block is not part of an IOTP Transaction that
     is recognised by the Consumer role then there is a Hard Error,
     otherwise
RH> During brand independent purchase without authentication,
RH> OfferResponse (with TPO) is the first message received by the 
RH> Consumer.
## Fixed by adding initial test that says ...
"- if the Offer Response Block is part of a Brand Independent Offer Exchange
(see section 9.1.2.2) then there is no sequence checking as it is part of
the first message received, otherwise "
##
========================================================================
7.11 Payment Receipt Component
...
 Note that either the *PayReceiptRefs* attribute, the PackagedContent
 element, or both must be present.
RH> change to: PayReceiptNameRefs attribute...
##Fixed##
========================================================================
9.1 Authentication and Payment Related IOTP Transactions
...
 o Brand Independent Offer. This is also an Offer Trading Exchange.
   However, in this instance, the content of the Offer Response does
   depend on the Brand selected.
RH> Change to: does not depend on the Brand selected.
##Fixed##
========================================================================
9.1.2.1 Brand Dependent Offer Document Exchange
...
 On receiving an Offer Response IOTP Message (see below) the Consumer may
 either:

 o generate and send the next IOTP Message in the IOTP transaction and
   send it to the required Trading Role. This is dependent on the IOTP
   Transaction, or
 o indicate failure to continue with the IOTP Transaction by sending a
   Cancel Block back to the Consumer containing a Status Component with a
                            ^^^^^^^^
   StatusType of Offer, a ProcessState of Failed and the CompletionCode
   (see section 7.16.4) set to either: ConsCancelled or Unspecified.
RH> Change to: Merchant
##Fixed##
========================================================================
9.1.4.3 Delivery Response IOTP Message
...
 The Delivery Response IOTP Message contains a Delivery Response Block
 and an options Signature Block.
        ^^^^^^^
RH> Change: optional
##Fixed##
========================================================================
11.1.1 Definition of Payment Instrument
...
 All Payment Instruments have a number, typically an account number, by
                         ^^^^^^^^^^^^^ 
 which the Payment Instrument can be identified.
RH> I'm not sure, but there are some payment protocols, which
RH> enable anonym payment (GeldKarte ???). Is this applys also
RH> for these instruments ???
## Changed All to Most##
========================================================================
Hope this helps a little, polishing the final version :)
Regards, Rudi