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

From: David Burdett <[email-masked]>
Date: Mon, 17 May 1999 20:06:22 +0100

Seidl

Apologies for the delay in getting back to you but I was at CardTech
SecurTech in Chicago all last week. Answers to your questions are included
below, marked with a ##.

I've also copied this reply to the Trade WG.

David

> ----------
> From: 	Seidl, Roland A[SMTP:[email-masked]]
> Sent: 	05 May 1999 19:26
> To: 	'SMTP:[email-masked]'
> Subject: 	Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt
> 
> I am just starting to look at this draft and there are a number of
> comments
> I would like to offer.
> 
> 1) Fig. 3 has three Signature(offer) components, one in the Consumer side
> (step 5),
>     one in the Merchant side (step 4), and a third in the Payment Handler
> (step 7).
> 
> This is confusing. The text refers to an "Offer Response Signature" -
> there is no such
> labelled component in the diagram. [This refers to the Signature(Offer) of
> the
> Merchant???]. In step 7, the Signature(offer) is presumably a copy of the
> Consumer
> Signatuer(Offer).
> 
> I suggest that unless these signatures are copies which are passed from
> one
> message to the next they should have distinct labels in the diagram
## The the "Offer" signature in the diagram has been relabeled "Offer
Response". They are all copies of the original created by the Merchant.##

> 2) Similar comment for fig. 4
##Changed in similar way to above.##

> 3) Figure 8 has errors. There is a missing 2 from TransID comp., should be
> M1.2.
>  The second 'Trading block' should have identifiers M1.9 through M1.13,
> which are
> distinct from those of the first 'Trading block'.
## Both fixed##

> Similarly for fig. 9
## Also fixed##

> 4) TPO Block is mentioned in 3.11.1, 4.4.2.9, Fig. 13, 6.1, 6.16, 6.17.2
> and 6.17.5
> before TPO Trading Block is defined in 7.1. There should be a forward
> reference to
> section 7.1 at least in the first occurrence of TPO blokc in 3.11.1
## Forward references added ##

> 5) Page 71 'Cancelling a complete should' -- this should read
>      'Cancelling a complete transaction should'
## Corrected ##

> 6) Section 3.11.1 mentions SenderNetLocn, SecureSenderNetLocn,
> CancelNetLocn.
> Could these and other similar references be collected in an appendix which
> indicates
> the role associated with these 'Net' locations and the purpose assigned to
> each.
## Included forward reference to ProtocolOptionsComponent which describes
what these attributes are used for.##

> 7) Figure 10. is so cluttered (the fault of having to use a 'text' based
> diagram) that it
> is difficult to comprehend. This could be alleviated by splitting the
> diagram, so that
> there are seperate portioins for each of the 'Type of Block' paths (or
> possibly
> split into pairs).
## Sounds like a good idea ... do you want to have a go at doing a revised
diagram ? ##

> I am not convinced that the diagram logic 6a -> 6b -> 6d -> 6e is correct!
> Surely it should be 6a -> 6b -> 6d -> 6c.
> 
> Why is 'Processing of Block Complete' checked after 'Request Received
> Before'?
> Surely you need to wait for block processing to be completed before
> checking to
> see if the request has been received previously? If it is NOT necessary to
> wait for
> block processing completion to determine if a request has been received
> previously
> the why not truncate processing and go straight to step 6c
## I see your point. Hopefully the revised diagram below answers your
question ? (View in a fixed font)
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

                            -------------
                           |    Input    |
                           | IOTP Message|
                            -------------
                                  |
                                  v
                           1. Check for transport -------------->
                           or message level errors   Errors      |
                                      |OK                        |
                                      v                          |
   11. Generate output <-------2. More Blocks <----------------- + -
         message               No    to process?                 |  |
            |                        |Yes                        |  |
            v                         v                          |  |
      -------------           3. Check Block OK ---------------> |  |
     |    Output   |                 |               Errors      |  |
     | IOTP Message|                 |Checks OK                  |  |
      -------------                  v                           |  |
                    ---------4. Type of  Block ? -------         |  |
                   |           |           |            |        |  |
      ---------Status       Action   Encapsulating     Error     |  |
     |         Request      Request      Block         Block     |  |
     |                         |           |             |       |  |
     |                         v           v             v       |  |
     |                 6a. Action     7. Process     8.Error     |  |
     |                  Request -    encapsulated     Block ?    |  |
     |                  received      message and       |        |  |
     |                   before?--     generate --      v        |  |
     |                   |        |     response   |   STOP   ---   |
     |                   |Yes     |No        OK|   |         |      |
     |                   v        v            |   |Errors   v      |
     |       6b. Processing 6e. Process Action |   ------> 9. Gen   |
     |          of Block    Request & generate-+--------->Error     |
     |        Complete ?-     response block-  | Errors   Block &   |
     |           |       |                   | |           store    |
     |           |       |                   | |            |       |
     |           |Yes    |No           Ok or | |            |       |
     |           |        ---        Warning |  --------    |       |
     v           v           v               v          |   |       |
5. Generate  6c. Retrieve  6d. Do nothing 6f. Store     |   |       |
   Status     and resend    as earlier    request &     |   |       |
  Response     previous    request will   response      |   |       |
   Block        Block    provide response   block       |   |       |
     |            |                           |         v   v       |
      ---------------------------------------------- 10. Add block--
                                                     to output
                                                     message

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
##

> 8) Figure 11. Output from block 7. [OK] doesn't obviously go anywhere
> [This is a
> problem of splitting diagram across page]. There are 7 lines exiting
> bottom of page,
> but only 6 entering top of next. I assume that 6b[OK] -> 6c. Now does 7 ->
> 10 as for
> figure 10. or as the text implies 7 -> 6d (presumably via 6c). There also
> appears to
> be a missing link from block 10 back to 2. This diagram would also be
> improved
> by splitting it in someway (as for fig 10)
## Points noted. The original diagram had some miss-aligned characters. This
has now been fixed (see new diagram below). Also do you want to have a go at
a new version of this diagram as well?##
## Corrected diagram ...
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

                            -------------
                           |    Input    |
                           | IOTP Message|
                            -------------
                                  |
                                  v
                           1. Check for transport -->
                           or message level errors   |Errors
                                      |OK            |
                                      v              |
11.Blocks to be sent?<---------2. More Blocks <----------------------
             |    |No       No    to process?       |                ^
          Yes|    v                   |Yes          |                |
             v   STOP                 v             |                |
      12. Generate            3. Check Block OK --->|                |
     output message                  |              |Errors          |
          |                          |Checks OK     |                |
          v                          v              |                |
    -------------   ------  4. Type of  Block ? ----|                |
   |    Output   | |        |    |           |      |                | 
   | IOTP Message| |    ----     |           |      |                |
    -------------  |   |         |           |      |                |
       ------------    |         |           |      |                |
      |              --          |           |      |                |
      v             v            v           v      |                |
    Status       Action    Encapsulating  Error     |                |
   Request      Response       Block      Block     |                |
     |             |             |          |       |                |
     |             v             v          v       |                |
     |       6a. Action   7. Process 8a.Error Block---- > Transient  |
     |        Response  encapsulated     severity ? |       Error    |
     |        received     message      |Hard Error |      (retry)   |
     |        before ?         |  |         |       |         |      |
     |       Yes|   |No      Ok|  |         v       |       WAIT     |
     |      (Ig-|   |          |  |       STOP      |         |      |
     |      nore|)  v          |  |                 v         v      |
     |          | 6b. Process  |   -------> 9. Generate      8b.     |
     |          |    Action    |  Errors    Error Block    Retrieve  |
     |          |   Response --+---------->  & store      and resend |
     |          |     Block    |  Errors          |        previous  |
     |          |       |Ok    |                  |        Block(s)  |
     |          |       v      v                  |          |       |
     |          |         6c. New                 |          |       |
     |          |         request                 |          |       |
     |          |        required?                |          |       |
     |          |     No|    |Yes  6d. Generate   |          |       |
     |          |       |     ----> Request       |          |       |
     |          |       |          Block & Store  v          v       |
     v          |       |              |           10. Add Block to  |
      ----------+-------+------------------------>  output message ->|
                v       v                                            |
                 --------------------------------------------------->

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

> I notice from the archives that in response to one e-mail concerning the
> diagrams,
> you made mention of a 'Word' version, and the problems of conversion
> between
> these and a text format. I suggest the publication of a link to the 'Word'
> document
> might be extremely useful for people trying to read the text draft.
## Nice idea but, the "text" version is now the "master". It is also a lot
of work to keep two sets of diagrams in step. If someone wants to volunteer
to do "pretty" diagrams, I'll send them a word version of the text spec
(complete with text diagrams) so that they can provide an alternative
version.##

> That's as far as I've gotten so far. I hope these comments are of some
> use. I will
> forward any others (if there are any) after I have progressed further
> throught the
> document
## Thanks##

> Regards
> Roland SEIDL
> Telstra Research
> Phone: + 61 3 9253 6161
> Fax:      +61 3 9253 6485
> [email-masked]
> 

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

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

*********************************************************************************************
-----------------------------------------------------------------------
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]