Subject: RE: Cancelling Transactions and IOTP figs 10 and 11

From: David Burdett <[email-masked]>
Date: Thu, 20 May 1999 22:45:12 +0100

Roland

See comments below ... I agree with everything you say aboout figures 10 and
11. I've made the changes to diagram that you suggest.

However this discussion about Idempotency, Processing Sequence and Message
Flow, has made me realise that it doesn't cover the situation when a
transaction is cancelled by one or other of the Trading Roles. The ability
to cancel a transaction was added after this part of the specification was
written and the section on Idempotency, etc. didn't get updated.

I've also noticed that Section 7.18 that describes the Cancel block is not
quite correct since it says that only the Consumer can cancel a transaction
whereas in fact any Trading Role can cancel a transaction at any time. The
updates required to handle this and revised versions of figures 10 and 11
are below

David

SPEC CHANGES ...

Section 7.18 now reads
"The Cancel Block is used by one Trading Role to inform any other that a
transaction has been cancelled. Example usage includes:
		*	a Consumer Role informing a non-Consumer role that
it no longer plans to continue with the transaction. This will allow the
server to close down the transaction tidily without a waiting for a time-out
to occur
		*	a non-Consumer Role to inform a Consumer role that
the Transaction is being stopped. In this case, the Consumer is then
unlikely to re-send the previous message that was sent in the mistaken
understanding that the original was not received."

New section 4.4.1.6 Cancel Blocks (for server role) reads:
"If the Consumer role has sent a Cancel Block then the Consumer does not
intend to carry on with the Transaction and the Server should stop any
processing and not issue any further response blocks."

New section 4.4.2.6 Cancel Blocks (for consumer role) reads:
"If the Server role has sent a Cancel Block then the Server role does not
intend to carry on with the Transaction for the reasons indicated in the
Status Component in the Block. The Consumer should stop all processing of
the transaction and not issue any further blocks or messages."

Revised Figures 10 and 11.

 <<fig10v3.txt>>  <<fig11v3.txt>> 

> ----------
> From: 	Seidl, Roland A[SMTP:[email-masked]]
> Sent: 	20 May 1999 00:53
> To: 	David Burdett
> Subject: 	RE: IOTP  figs 10 and 11 redrafted plus some more Draft
> comments
> 
> David
>             The comments below don't change figure 10 from what I sent you
> yesterday.
> The only discomfort I feel is in leaving block 6d dangling so to speak.
> Perhaps
> there should be a pointer back to block 2, i.e
> 
>           6d. Do nothing!
>          Earlier request
>            will provide
>                      |
>                     v
>                   (2)
## Agreed ##

> If I understand you correctly, if an action request is received, which was
> previously
> received AND if the previous version of the request has been processed
> then
> send the previous response [sequence 6a->6b->6c->10].
## Correct ##

> Now if a duplicate of the action request is received while the first copy
> is still
> being processed, then it is ignored [The processing of the first copy will
> provide
> the response].  In this case (since it appears that block processing is
> carried
> out asynchronously, otherwise there wouldn't need to be a question
> regarding
> the completion or otherwise of processing a block) I would argue
> whateverfunction
> is scheduling the block processing would go and get the next block if one
> is
> available (i.e. go back to (2))
## Spot on ##

Roland thanks for your help. I've added the pointer back to step 2 in the
last version of step 2 that you sent me.

> Regards
> Roland
> 
> 
>  ----------
> >From: David Burdett
> >Subject:  RE: IOTP  figs 10 and 11 redrafted plus some more Draft
> comments
> >Date: 1999-05-20 11:26
> >
> >Roland
> >
> >See comments below.
> >
> >I've also looked at the diagrams you sent in your other email and they
> seem
> >much better. Do you want to revise them one more time in light of the
> >comments below, and then I'll include them in the spec.
> >
> >Thanks
> >
> >David
> >
> >> Is there anything that you see wrong with the way I point to/from one
> part
> >> of the diagram to the other? Would you like a different way of
> indicating
> >> this rather than
> >>
> >>    |      ?    Perhaps     |_
> >>    v                          | 9 |
> >>   (9)                          \/
> >## I prefer the approach on the left which is the one you currently are
> >using.##
> >
> >> Incidentally there is another error in the DTD.
> >> <!ATTLIST Parameter
> >>     type      PCDATA #REQUIRED>
> >>
> >> should be    "type CDATA"
> >## This part of the DTD was copied from the IOTP-DSIG DTD and is in a
> >separate spec. I guess this should be fixed in the next version of that
> >spec, then I will replace the complete section##
> >
> >> Also there was an error in the updated figure 11 you sent me. There
> >> shouldn't have
> >> been a link from the "4. Type of Block?" to the "Errors" stream.
> >##Agreed##
> >
> >> I still have a problem with figure 10!
> >> I thing the following needs to be determined to satisfy my misgivings
> >> about
> >> the "completeness" of the logic.
> >>
> >> Firstly - Under what circumstances will an "action request" be received
> >> which has been previously received?
> >##The internet can sometimes, without any intervention by anybody, result
> in
> >the same message being received twice. I think its something to do with
> the
> >Internet Protocol, if it can't (or more precisely thinks it can't) get a
> >message through to its destination by its preferred route, then it sends
> it
> >via another. In this case the *identical* message can sometimes get to
> the
> >destination two, or even more times.##
> >
> >> Secondly - There are two options as far as I see it.
> >>                       a) Do nothing, that is discard the previously
> >> received
> >> request and continue processing the next block
> >>                       b) Resend the previous response block
> >>               Under what circumstances is option a correct and in which
> is
> >> option b?
> >> ## I don't think that option (a) is *ever* correct. If you're
> processing
> a
> >> block and the identical one is received again, then:
> >*	if you haven't finished processing the original block, then you
> >should carry on processing (why stop and start again?) it which
> eventually
> >result in a response block being generated.
> >*	on the other hand, if you have finished processing the original
> >block and an identical one is received again, then the original block
> might
> >have been sent again because the response block was never received. In
> this
> >case you want to send the response again.
> >
> >Does this make sense?##
> >
> >> I guess that the answers to the first question will provide a
> resolution
> >> to
> >> the second.
> >>
> >> As far as I am concerned, if there are situations where each of the
> above
> >> options
> >> might apply, then we might need some check as to whether "Do Nothing"
> is
> >> the
> >> correct option?
> >>
> >>                 6b. Processing of Block Complete
> >>                                                |
> >>                                                |  NO
> >>                           Resend Previous Response?
> >>                             |
> >	                                                        |
> >>                             |   Yes
> |
> >> Ignore, get next block
> >>                            v
> >> v
> >>                          (6c)
> (2)
> >>
> >> Any comments?
> >## See earlier comments. However really the disagram should specify the
> >conditions which allow you to decide whether to ignore or resend if
> >duplicate block is received.##
> >
> 
> 
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************