Title: Finnish comments on Interface References and Binding Final CD ballot on CD14753 Source: Finland Date: November 6, 1997 Finland votes NO for the progression of the document FCD14753 Interface references and binding, with the following comments: 1. General -- editorial Make the uses of the fundamental terms consistent within this standard and the "Protocol support for computational interactions". For example: association, connection, binding, liaison; interface reference, interworking reference point, association end-point, connection endpoint, interworking end point. We suggest the following terms to be used for the various endpoints and interface references: - (computational) interface reference, - (engineering) interworking reference point, and - association end point. We suggest the following terms to be used for the various levels of liaisons: - (computational) binding, - (engineering) channel object, - association. 2. General -- editorial The use of viewpoint names and the relationship of this standard to the "Protocol support for computational interactions" is unfocused. For example, see page 4, sentences including words engineering and computational. 3. Clauses 1 and 9 -- editorial Expressions of the scope of this standard are contradictory. The computational viewpoint specification does not cover the lifetime of a binding as stated in clause 1. 4. Clause 7.1. -- editorial The "state machine model" given for the epochs of a binding does not include return to the first epoch by unbinding activity. 5. Clause 7.2.7, 7 -- editorial The term "initiator" is poorly used and defined. Each operation always has an initiator. Because the initiators in this standard do not have any special restriction or role, we suggest that the clause 7.2.2 is deleted. However, the fact that the initiators of some operation can reveal the obtained information to other objects, or that the initiators have obtained some necessary information from the initiators of some other operations, should be stated when the activities are discussed. A note can be generated to explain that a number of implicit roles are used to play the active agent roles here. Some sentences throughout the document need to be modified because of the change. For example, in the beginning of clause 7.1. 6. Clause 7.5. -- editorial Remove the third paragraph. All bindings can fail. 7. Clause 7.5. -- editorial Move the two examples to a new annex. The examples provide useful information, however they do not offer prescriptions. 8. Clause 8 -- editorial Figure 2 is not visible. 9. Clause 8 -- editorial Readers find the terms "actual contract" and "lifetime of interface references" confusing. 10. Clause 8.1. -- editorial The phrase "part of interface reference" contradicts with the other ideas given about the environment contract. 11. Clause 8.2. -- editorial The practical need for introducing binding types is not sufficiently presented. The practical negotiation protocols are performed on information contained in channel types, however, the binding type is a necessary abstraction level to bind the independently presented channel types together. The instantiation process involved after negotiation needs channel templates separately at each involved domain. 12. Clause 8.5.1 -- editorial Move this clause to be the last clause of 8.5. Add also an explanation of why some of the fields presented in 8.5. are not included in 8.5.1. 13. Clauses 9.2.1, 9.2.2 -- editorial Move clauses 9.2.1. and 9.2.2. to an informative annex. This protocol is one of the potential ways of binding and therefore adds understanding of the concepts. However, it is not the only protocol possible, and it also has an engineering level flavour in it. 14. Clauses 9.1, 10.1 -- editorial Join the text of 10.1. to clause 9.1. Also note that the terms "transfer of interface references" and "passing of interface references" should be unified. This merge makes untrue the claim that transfer of interface references is not within the scope of this standard (second bullet list of 9.1). 15. Clauses 9.2, 10.2, 10.3 -- editorial Joint the text of 10.2 and 10.3 to the remaining text in clause 9.2. 16. Clauses 9.2, 10 -- editorial Merge the remaining (starting) text of clause 10 to the introduction of 9.2. In the merge, note that the federated case is just a special, more complicated case of a binding establishment, but the general idea is all cases is equal. Also mention, that a pre-existing liaison is necessary for the binding factories to work together. Furthermore, make some statements of the four liaison layers found in the channel object that is further specified in the standard "Protocol support for computational interactions". 17. Clause 10 -- editorial This standard considers the bindings of computational objects from various viewpoints. The "Protocol support for computational interactions" discusses the corresponding binding between the engineering objects representing the above mentioned computational objects, and breaks it down to engineering components. After the previous changes, clause 10 is now empty. We suggest that an engineering viewpoint is given here. The engineering viewpoint is needed to give some insight of the relationship of this standard to the "Protocol support for computational interactions". However, the engineering viewpoint should not be a "complete" engineering view, but only a pointer. Suitable material for this kind of discussion is available in clauses 9.3, 9.4, and 9.5. 18. Annex C -- editorial Check the references given in annex c. 19. figure 3 -- editorial Figure is out of sync with the text.