Title:  Finnish comments to the working document WD17452 (7N1313) on
        Protocol support of computational interactions

Date:   November 6, 1997
Source: Finland


We consider the overall scope and structure of the working document to
be reasonable. However, we have some practical concerns about the
scoping of the work, and the details involving other, related standards.
We also try to give our opinion on the questions explicated by the editor.

1. Is it reasonable to leave out stream interfaces? We understand, that
   the operations are better known, and therefore majority of the
   material in this standard will be about operations. However, if
   streams are excluded, is there going to be another standard later
   about them? Do we need discourage or encourage contributions for
   streams?

2. Currently the document discusses access and location transparency
   only. The reason for this seems to be OMG driven. However, ODP-RM
   defines the transparencies to be selective. Therefore, there is no
   problem in discussing other transparencies as well: GIOP/IIOP must
   first claim its conformance goals (access and location transparencies
   only), and then give the mappings between the abstract and the
   concrete operations involved to those transparencies only.

3. The concept of location transparency in this document seem to be
   vague and drifting. The ODP-RM definition should be used, and
   therefore migration and relocation transparencies should not be
   considered as part of the location transparency in any part of the
   text. In OMG terminology, there are some differences in the
   transparency names. May be we should add an annex that gives the ODP
   and OMG dictionaries and correspondences of the terms.

4. This document makes an effort to use ODP-RM Part 3 concept of signals
   for explicating properties of operations. However, the concept of
   signal is not sufficiently described in Part 3. Should we try to add
   information on signals to this document, or try using other concepts
   for discussing the detailed behaviour of operations and streams. The
   problems arise especially when discussing streams.

5. The roles of "Protocol support for computational interactions" and
   "Interface references and binding" should be explicated. Special care
   should be taken to use the same terminology on the areas where common
   concepts appear. For example: association, connection, binding,
   liaison; interface reference, interworking reference point,
   association end-point, connection endpoint, interworking end point;

6. The concept of access transparency seem to refer to presentation
   only. The ODP concept of access transparency is wider is scope.
   Therefore, we suggest replacing the name of "presentation facility"
   with the name "access facility".

7. The chapter "Service model" is not yet revealing what it tries to
   achieve. We suggest that an opening paragraph is added, that says
   something about describing the common features of all liaison layers.
   It should also say something about QoS and streams.

8. Non ISO-standard references given in 2.2. should be moved to form an annex.

9. Definition set in 3.3. is inconsistently selected. Chapters 3, 5, 6,
   7, and 8 include unnecessary repetition, usually the last description
   would do alone.

10. --

Responses to editor questions

11. Q on cover page:
   Liaisons exists potentially independent of the supported interaction,
   except the liaison between BEOs.

12. Q at 9.3.1. Take a general case where two abstract operations
   are mapped onto a single message. When a single message is received,
   it needs to trigger both abstract operations -- although logically
   only one would be wanted but we can really not say which one!

13. Q preceding clause 11. 
   We seem to be in favour of including aborts and cancels everywhere
   for consistency and we seem also to have semantics for the events as
   well.

14. Q in 11.1.3.

   Should include QoS. Relocation-only servers?

15. Q in 11.3.1. 

   Should use separate illustrations for each liaison. Why to combine
   just basic interworking and location, what happened to representation
   facility? Don't care in this phase about the mapping. In the
   mapping the messages can be joint and piggy-packed: A concrete message
   is "replicated" at receival and each abstract state machine gets
   "private copy" of the message!
   
16. Q in 12.4.1.

   The association reference can be thought as a pair of ports. On
   request, the initiator assigns its side of the reference (port it
   is going to use) and on the reply, the responder has filled in the
   other half. The "half-filled" association reference is usually enough
   for the gamblers.