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

From: David Burdett <[email-masked]>
Date: Fri, 3 Sep 1999 08:52:46 -0700

Yoshiakia/Rudolf

Agree with your comments but think we need more discusion around idempotency
... see below.

David

-----Original Message-----
From: Yoshiaki KAWATSURA [mailto:[email-masked]]
Sent: Wednesday, September 01, 1999 1:10 AM
To: [email-masked]
Cc: [email-masked];
=?iso-8859-1?Q?VargaAndr=[email-masked]?=;
[email-masked]
Subject: Re: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt

Rudolf,
My comments are below.

>>>>> Wed, 1 Sep 1999 09:22:17 +0200,
	Rudolf Hornig <[email-masked]> said:

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

You are right. We should change NMTOKEN to CDATA.
##Agreed##
> ========================================================================
> 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? 

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!) ?
##
> Hope this helps a little, polishing the final version :)
> Regards, Rudi

I believe your comments are very helpful for IOTP Spec :-)
##Definitely. Thanks.##
----
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: Rudolf Hornig <[email-masked]>
Date: Mon, 6 Sep 1999 13:41:32 +0200

David and Yoshiakia,

... [Content deleted] ...

used.

Which approach do people prefer (or is there another one!) ?
##
<RH>
I would opt on #3, because:
- 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...

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

  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>

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: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 07 Sep 1999 08:09:12 -0400

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>

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

>  3. As stated above, all blocks, components, elements, etc are the same...

There should be no difference between 2 and 3.

>  original and the newly received message before comparing...

DOM HASH is explicitly designed to make comparison easy.

>  uses the same Trans and Msg ID...

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

Thanks,
Donald

---

From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 09 Sep 1999 20:55:38 +0900 (JST)

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

----

---

From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 09 Sep 1999 21:06:48 +0900 (JST)

Additionally, I think better the default is #1 but we should allow
 the request receiver sends the new(current) status for inquiry and ping
and this is a implementation dependent. The response does not guarantee 
its status is current one.

What do you think?
----