RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
David Burdett <david.burdett@commerceone.com> Thu, 09 September 1999 16:48 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 MAA05121 for <trade-archive@odin.ietf.org>; Thu, 9 Sep 1999 12:48:30 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa19851; 9 Sep 99 12:17 EDT
Received: from mail.commerceone.com by one.eListX.com id aa19839; 9 Sep 99 12:17 EDT
Received: by ip5-19.5.20.172.in-addr.arpa with Internet Mail Service (5.5.2448.0) id <R4XGVY45>; Thu, 9 Sep 1999 09:15:46 -0700
Message-ID: <123B7EB05559D311B0D900A0C9EA3D7604F234@NEPTUNE>
From: David Burdett <david.burdett@commerceone.com>
To: 'Yoshiaki KAWATSURA' <kawatura@bisd.hitachi.co.jp>, ietf-trade@lists.eListX.com
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Date: Thu, 09 Sep 1999 09:15:55 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Yoshiaki/Don/Rudolf. See comments below marked with && David -----Original Message----- From: Yoshiaki KAWATSURA [mailto:kawatura@bisd.hitachi.co.jp] Sent: Thursday, September 09, 1999 4:56 AM To: ietf-trade@lists.eListX.com Cc: kawatura@bisd.hitachi.co.jp 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 kawatura@bisd.hitachi.co.jp Business & Information Systems Development Division, Hitachi,Ltd. Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721 ----------------------------------------------------------------------- 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 ----------------------------------------------------------------------- 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