RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Rudolf Hornig <rudolf@metechnology.com> Mon, 06 September 1999 12:03 UTC
Received: from one.eListX.com (one.elistx.com [209.116.252.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11810 for <trade-archive@lists.ietf.org>; Mon, 6 Sep 1999 08:03:25 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa12141; 6 Sep 99 07:49 EDT
Received: from matavnet.hu by one.eListX.com id aa12128; 6 Sep 99 07:49 EDT
Received: (qmail 4661 invoked from network); 6 Sep 1999 13:50:43 +0200
Received: from line-212-112.dial.matav.net (HELO apps) (145.236.212.112) by mail.matav.hu with SMTP; 6 Sep 1999 13:50:43 +0200
Received: from 10.0.0.10 by apps ([10.0.0.1] running VPOP3) with SMTP; Mon, 6 Sep 1999 13:41:31 +0200
Reply-To: rudolf@metechnology.com
MMDF-Warning: Parse error in original version of preceding line at one.eListX.com
From: Rudolf Hornig <rudolf@metechnology.com>
To: 'David Burdett' <david.burdett@commerceone.com>, 'Yoshiaki KAWATSURA' <kawatura@bisd.hitachi.co.jp>
Cc: ietf-trade@lists.eListX.com
MMDF-Warning: Parse error in original version of preceding line at one.eListX.com
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Date: Mon, 06 Sep 1999 13:41:32 +0200
Message-ID: <000101bef85c$c4be7b50$0a00000a@rudolf>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <123B7EB05559D311B0D900A0C9EA3D7604F205@NEPTUNE>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-Server: VPOP3 V1.3.0b - Registered to: Me Technology
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Content-Transfer-Encoding: 7bit
David and Yoshiakia, > ======================================================================== > 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: - 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 (Rudolf@MeTechnology.com), Project Manager MeTechnology Ltd. Hungary - a Brokat Company -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ----------------------------------------------------------------------- Message addressed to: ietf-trade@lists.elistx.com Archive available at: http://www.elistx.com/archives/ietf-trade/ To (un)subscribe send a message with "subscribe" or "unsubscribe" in the body to: ietf-trade-request@lists.elistx.com
- RE: Comments on draft-ietf-trade-iotp-v1.0-protoc… David Burdett
- RE: Comments on draft-ietf-trade-iotp-v1.0-protoc… David Burdett
- RE: Comments on draft-ietf-trade-iotp-v1.0-protoc… David Burdett
- Re: Comments on draft-ietf-trade-iotp-v1.0-protoc… Yoshiaki KAWATSURA
- Re: Comments on draft-ietf-trade-iotp-v1.0-protoc… Yoshiaki KAWATSURA
- Re: Comments on draft-ietf-trade-iotp-v1.0-protoc… Donald E. Eastlake 3rd
- RE: Comments on draft-ietf-trade-iotp-v1.0-protoc… Rudolf Hornig
- RE: Comments on draft-ietf-trade-iotp-v1.0-protoc… David Burdett
- Re: Comments on draft-ietf-trade-iotp-v1.0-protoc… Yoshiaki KAWATSURA
- Comments on draft-ietf-trade-iotp-v1.0-protocol-0… Rudolf Hornig