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

[Yoshiaki KAWATSURA <[e-mail]>]

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.

----
Yoshiaki Kawatsura : E-mail [e-mail]
 Business & Information Systems Development Division, Hitachi,Ltd.
Voice: [phone](direct) Fax: [phone]
-----------------------------------------------------------------------
Message addressed to: [e-mail]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [e-mail]