Statement on "Provision of trading function using OSI Directory Service" ------------------------------------------------------------------------ We recommend that the document ISO/IEC DIS 13235-3 "Information Technology -- Open Distributed Processing -- ODP Trading function -- Part 3: Provision of trading function using OSI Directory Service" is progressed to a second DIS. We have the following comments to the current document. General comments: #1 The document gives more prescriptions for information contents of the service offers and trader attributes, and is more prescriptive about trading behaviour than the document "Information Technology -- Open Distributed Processing -- ODP Trading function -- Part 1: Specification. The additional prescriptions have two sources: firstly, the technology of X.500 induces some necessary choices of design; secondly, design choices that have a tutorial nature. We recommend that the second class of prescriptions is deleted. Suggestions on how this can be done are included to the detailed comments. #2 The OSI directory service supports and requires the concept of global naming. However, the ODP reference model assumes that no global naming is available, but instead, context-relative naming is assumed. The current document does not indicate how this problem is resolved. #3 Currently the trading function standard set has three individual parts and therefore we should take care that the parts do not contradict. The easiest way of avoiding mismatches is to avoid repetition between the parts. In the case of Part 1 and Part 3 this is possible. We can describe the scope of the Part 3 by defining that - the interface between a client and a trader is as it is defined in Part 1; if there is any exceptions of this, those are expressed in Part 3 when operations are described; - a trader is implemented as a pair of T-DUA and a private data storage that resides in X.500 directory; the T-DUA client interface towards X.500 is what this standard is all about; The definition must then be supplemented by - the data objects stored in X.500, - the data object stored in T-DUA, - how trading operation requests are mapped to T-DUA's request for X.500 operations, - how data and exceptions returned by x.500 are mapped to traders replies to the client. The definition of T-DUA internal computation should be kept at the same level of abstraction as in Part 1. We give an example operation description below in item 26. #4 The text should use computational language instead of giving implementation details. For example, the expression "read an entry for policy value" should be replaced with "follow the policy" (e.g., in clauses 7.4.4. and 7.5.1). #5 Throughout the text terms "client", "object", and "class" are used. However, it is usually unclear whether the terms refer to ODP concepts or X.500 concepts. #6 The type repository function standard should be referred to instead of replicating its contents. Replication leads to inconsistencies between the standards. This comment affects especially clause 8. #7 Modifications to Part 1 cause changes in this document. #8 The goal of this standard is unclear. There seems to be two possible goals: a) to specify how trading specific behaviour is mapped to X.500 services, or b) a component compositions for a trader product. If the goal is a) then usage of x.500 security features should be removed. If the goal is b) then other related functions should be discussed in the same extent. We prefer the choice a). We have in other contributions recommended that a separate security framework is produced. When that is in CD phase, this standard should be attached with an annex that shows how security function and trading is composed to an engineering object. The same strategy is applicable to other function standards too. #9 The document needs a spelling check. #10 Interfaces and operations should be described in the same order as in Part 1. Detailed comments: #11 Clause 0. Add a sentence "This standard uses ODP computational language." Also describe the problem of combining a non-ODP functionality with an ODP function. #12 Clause 2. Add a reference to the type repository function and naming framework standards. #13 Clause 5 Add a description of the standard structure (see #3) and a statement that this standard is necessarily more restrictive than Part 1 because of the technical requirements of the X.500 directory. #14 Clauses 6.2.13, and 7.2.7.6 The terms differ from those used in Part 1. The descriptions of the terms are odd. #15 Clause 6.2.21 The contents of this clause is unclear. #16 Clause 6.3. The first and last comments in the X.500 schema definition is unclear. The "interface address" is not a defined term. #17 Clause 6.4., note The last two sentences starting from "It would have been possible" seem not to belong to a standard. Remove the sentences. #18 Clause 6.4., paragraph under the note Replace "by matching or describing" with "by using operations 'query' or 'describe offer'". #19 Clause 6.4.2. ClientId is obsolete. #20 Clauses 6.4., ... When X.500 security is used, the T-DUA should not use the client's (the exporter's) authentication information. Instead the stored data should belong the the T-DUA itself, and the T-DUA should itself check by some means which exporters it accepts. In clause 6.4., remove exporter. It represents in fact here information for X.500 access control. However, this information is automatically generated to the data by the X.500 system itself, but it is initiated by an administrative operation -- it should not appear in the data definition. #21 Clause 6.5.2 Add a comment to state that this is needed because of the technical requirements of X.500. #22 Clause 6.5.6 Modify the text so that it is more apparent that we discuss only examples here. For instance, add a note. Remove "target" from "target trader". Target trader refers to wrong trader. #23 Clause 6.6. Replace "Immediately underneath" with "Immediately underneath ... in the hierarchy tree". #24 Clause 6.6., in proxyOfferEntry Remove exporter. The exporter represents only access control information and we recommend that it is not discussed in the current document (see #20). #25 Clause 7, all tables. The structure of the tables is misleading. Include operation parameters, mapping to X.500 syntax, mapping to T-DUA store and comments. X.500 Exceptions could be described with similar tables. #26 Clause 7 This item gives the example operation specification referred by item #3. Replace clause 7.3.1. with the following. "The export operation is mapped to an X.500 addEntry operation to add a new ServiceOffer entry to the X.500 Directory. The data in the Export operation is: export X.500 T-DUA comments operation representation representation parameter --------------------------------------------------------------- interface Name as is reference service type ObjectIdentifier as is service properties any (optional) as is The name of the new entry is selected by T-DUA so that it is unique amongst all service offers. Any scheme may be used. The structural object class of the new entry is ServiceOffer. The auxiliary object class name is specified by the exporter in the parameter "service type". If the service type name (auxiliary object class) is not known to the trader, the DSA returns an Update error of type objectClassViolation. The T-DUA returns an exception of UnKnownServiceType to the exporter. The service property values which may be present and must be present in the new entry are controlled by the auxiliary object class (service type identifier) of the entry. The exceptions returned from DSA are mapped to export operation terminations as described in the following table: DSA exception export operation comment termination ----------------------------------------------------------------- Update error missing missing (of type mandatory mandatory objectClassViolation) property attributes Update error (of type unknown unknown objectClassViolation) property attributes property invalid type property mismatch value attribute error property invalid (of type type property undefined- mismatch type AttributeType) If the exporter is successful, the T-DUA returns success with offerId that has X.500 RDN attribute syntax where the offerId is the RDN of the new entry. #27 Clause 7.3. Names of the trading operations and parameters are not consistent with part 1. (e.g., accept, entries in table, "name of the interface"). #28 Clause 7.3.1. paragraph 3 Replace "access control information" with "X.500 access control information". Move this paragraph to 6.1. Similar paragraph appears in all operations descriptions and should be handled similarly. #29 Clause 7.3.1., paragraph 6 Remove the end of the paragraph starting from "(The current trading standard function allows exporter to include an occasional optional property ...". #30 Clauses 7.3.1, 7.3.3., and 9. Paragraph 8 in Clause 7.3.1. and paragraph 2 in clause 9. are replicates. Also in 7.3.3 the paragraph 6 contains the same story. Put the story once in Clause 9 and move the text to a new clause before clause 7. In this way the data contents is all defined before operation definitions. #31 Clause 7.3.3., paragraph 4 "The resulting entry may violate the schema." This should not be possible according to part 1. #32 Clause 7.3.3., paragraph 5 "If the modification changes a direct property ...". Direct property is not a defined term. The change should not be possible according to part 1. #33 Clause 9, last paragraph The paragraph is not suitable for a standard.