From comp@komp.ace.nl Fri Jan 15 16:44:56 1993 Received: from sun4nl.nluug.nl by dkuug.dk with SMTP id AA06949 (5.65c8/IDA-1.4.4j for ); Fri, 15 Jan 1993 16:44:56 +0100 Received: from ace by sun4nl.nluug.nl via EUnet id AA23236 (5.65b/CWI-3.3); Fri, 15 Jan 1993 16:44:58 +0100 Received: from ace.ace.nl ([194.0.2.40]) by netnog.ace.nl with SMTP id AA19001 (1.14/890.1); Fri, 15 Jan 93 15:30:43 +0100 (MET) X-Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. +31 20 6646416 (phone) +31 20 6750389 (fax) 11702 (ace nl) (telex) Received: from komp.ace.nl ([192.1.2.90]) by ace.ace.nl with SMTP id AA16910 (1.14/2.17); Fri, 15 Jan 93 16:26:22 +0100 (MET) Received: by komp.ace.nl with SMTP id AA14614 (1.10/2.17); Fri, 15 Jan 93 16:29:45 +0100 (MET) To: Mark Hamilton , Dave Robinson Cc: sc22wg11@dkuug.dk Subject: WG11/N353: Liaison statement to SC21/WG8/RPC Date: Fri, 15 Jan 93 16:29:28 N Message-Id: <14542.727111768@komp> From: Willem Wakker X-Charset: ASCII X-Char-Esc: 29 To: David Robinson JTC1/SC21/WG8 RPC Rapporteur From: Willem Wakker JTC1/SC22/WG11 Convenor Subject: Liaison statement on Alignment of LIPC and RPC standards SC22/WG11 appreciated the effort made by SC21/WG8/RPC in scheduling their interim meeting to be co-located with the WG11 meeting in Paris. Due to this scheduling, a number of joint sessions were possible, with the result that the WG11 documents now going to SC22 ballot can be more closely aligned with the RPC Parts 1 and 2, useful technical work on all of the related standards projects was performed, and most of the alignment problems have been resolved. During these sessions, a number of alignment issues were identified which the RPC group asked to receive in a formal liaison statement. This document is that liaison statement. Except as noted below, all of these comments were accepted by the RPC experts in attendance at the joint sessions, but we recognize that they may or may not be formally accepted in the RPC editing meeting. Considerable time was spent understanding the model of procedure context, in both the local and RPC case. The results of this discussion are captured in the model in the new LIPC draft, and we would appreciate comments from the RPC Group on this model and its relevance to RPC as well as LIPC. The model was drafted with input and agreement from the RPC experts at the joint sessions. We look forward to your responses. --------------------------------------------------------------------- Comments on Part 1 --------------------------------------------------------------------- Item 1.1: Change "calling procedure" to "caller". Type: Editorial. Ref: 3.5.3 and all occurrences. Change the term "calling procedure" to "caller". The text correctly defines a procedure to be closed, and be entered from and return control to an external source. The calling entity may be difficult or impossible to describe this way, and does not need to be a "procedure" for the rest of the LIPC/RPC concepts to apply. This requires the definition in 3.5.3 to be replaced by something like: caller: an entity or sequence of instructions which invokes a procedure. Replace "calling procedure" by "caller" and the phrase "calling and called procedures" by "caller and the called procedure" in all occurrences. Item 1.2: Improve definition of "procedure return" Type: E Ref: 3.5.5 The definition of "procedure return" seems circular. The important aspect is that this is where control is returned to the caller. The notion of "specific termination" is an added feature - the generic concept does not require the possibility that there is more than one. We suggest the following: procedure return: The act of returning control to the caller, with a specific termination. Item 1.3: Correct definition of "formal parameter". Type: E Ref: 3.5.9 An interface specification is NOT the "definition of a procedure", which lies in the domain of programming languages. And the term "identification" is ambiguous, in that it leads to arguments about "how" it identifies (by name or by position) rather than "what" it identifies. The syntax in Part 2 refers to a formal parameter as a "declaration", which is correct. We suggest the following: formal parameter: the declaration of a parameter (value) to be passed to or returned from a procedure when it is called. Item 1.4: Emphasize "passing" of "actual parameter". Type: E Ref: 3.5.10 The given definition puts the emphasis on the programming language concept of substitution during execution. For LIPC/RPC, this notion is out of scope, and the emphasis should be on the calling mechanism. (An intentional departure from ISO 2382 is appropriate here.) We suggest: actual parameter: A value communicated between a caller and a called procedure via a procedure call. Item 1.5: Generalize definition of "termination". Type: E Ref: 3.5.14 The definition of termination should be refined to the LIPC/RPC notion, making it clear that terminations are both an indication of "how" the procedure is returning (normally, or with a particular "predefined response"), and a set (possibly empty) of return values, which are predeclared, but not "predefined". We suggest the following: termination: A pre-defined state and a corresponding collection of values supplied by the called procedure on a procedure return. Item 1.6: Add "procedure image" and "procedure closure". Type: E Ref: 3.5.21 During the discussions, a "new" model of procedure calling and some associated terminology was proposed. This new model is being drafted, and is included in the balloted draft of LIPC. The joint discussions corrected the definitions of these terms in the LIPC, and we believe these terms are useful to the definition of the RPC Model as well. We suggest: a. Add: procedure image: A representation of a value of a particular procedure type, which embodies a particular set of instructions to be performed when the procedure is called. b. Use "procedure image" to replace the current RPC term "procedure body instance", which is undefined. c. Revise 3.5.21 to read: procedure closure: The object which represents the pair of a procedure image and a particular execution context for that procedure. Item 1.7: Remove "RPC" from terms which are shared with LIPC. Type: E Ref: 3.5.9, 3.5.10, 3.5.14, 3.5.15, 3.5.16, 3.5.17, 3.5.30 The LIPC definitions of the terms in the above clauses are now identical, except for occurrences of the word "remote" or "RPC". Alignment will be facilitated by removal of those words in the RPC definitions. Item 1.8: LIPC vs. RPC terms Type: E Ref: 3.5.17, 3.5.18, 3.5.19, 3.5.22, 3.5.29 The terms "interface-type", "interface-type definition", "IDN" "interface instance" and "interface-type identifier" are also terms in the LIPC, with the same generic meaning. In each case, the RPC meaning is restricted by requirements of the "remote"-ness. Somehow this relationship should be stated. We suggest RPC include the "general" definitions and then define the RPC specializations, using the form: RPC xxx: A xxx (in) which ... Item 1.9: Interface-reference. Type: E Ref: 3.5.28, 3.5.31 3.5.28 defines "RPC interface reference", while 3.5.31 refers to "interface-reference" without "RPC". They should be changed to match. The term "interface-reference" does not appear in LIPC, so removing "RPC" would not be a problem, but it does appear to be an RPC-specific notion. Item 1.10: Marshalling and Unmarshalling Type: E Ref: 3.5.32, 3.5.33 The terms "marshalling" and "unmarshalling" are defined more generally in LIPC. Presumably, the notion "message" here means APDU. Here repeating the LIPC definition and adding an RPC-specific phrase within, or at the end of, the definition is preferred. E.g.: marshalling: the process of collecting actual parameters, possibly converting them and assembling them (into a RPC message) for transfer. unmarshalling: the process of disassembling the parameters transferred (in a RPC message), and possibly converting them, for use by the called procedure on invocation or the caller on return. Item 1.11: Clarify the "RPC client" notion. Type: E Ref: 3.5.35 In the definition of "RPC client", it is not at all clear that "initiates ... a sequence of remote procedure calls" was intended to distinguish "top-level" calls from "callback" calls. If this is indeed what was intended, it should be stated explicitly. We suggest: RPC client: A component in a distributed application which initiates a non-callback remote procedure call. See also Item 1.16 below. Item 1.12: Remove references to "computational semantics". Type: E Ref: 3.5.37, 5. The use of "computational semantics" in the RPC draft is gratuitous and subject to much argument in the SC22 community. There is no standard "computational model" to which the RPC can relate, nor is it clear that all ISO languages have the same one. The RPC model presents a semantic view of procedure calls which can be mapped to many programming language models. Delete the definition in 3.5.37, and the first sentence of the second paragraph of clause 5, which appears to be the only use. Item 1.13: Use LIPC Terms for Parameter-Passing. Type: E Ref: 5.6. LIPC defines four parameter passing styles, two, or possibly three, of which are clearly the ones intended by the wording in subclause 5.6 of Part 1. In the interest of aligning the RPC and LIPC Standards, RPC should use the parameter-passing terminology defined in LIPC, rather than attempting to word around a definition. "Value Sent on Initiation" is a value passed to the called- procedure at the time of the call. "Value Returned on Termination" is a value passed to the caller at the time of return, whether normal or some termination. "Value Sent on Request" is a value passed to the called- procedure when some "out-of-band" request is made, e.g. when an aliased pointer is dereferenced. "Value Returned when Available" is a value returned to the caller by some "out-of-band" request, e.g. when an assignment is made through an aliased pointer or a registered event is triggered. It is not clear whether either of the latter two is actually supported by RPC. It is clear (and a requirement of the LIPC) that the first two must be. Item 1.14: Alignment of the Termination Model. Type: Note Ref: 5.12 RPC and SYSTEM terminations are subdivisions of LIPC's (new) 'mechanism' class of terminations. It is quite reasonable for RPC to split this class into RPC-defined and generated terminations and terminations defined and generated by other providers in the joint environment. Marshalling errors are NOT RPC-specific terminations. There may be RPC-specific marshalling errors, but there may also be language-specific marshalling errors which are visible to an RPC user. Item 1.15: Alignment of Cancel. Type: E Ref: 5.13 Cancel, as currently defined by RPC, is not required in LIPC, and it is not clear that LIPC should provide for it. The example given in 5.13 does not seem to have an LIPC analog - in LIPC the conceptual single thread of control is what is interrupted. Except for the unusual (RPC) situation in which the conceptual single thread of control is implemented by two actual threads on separate hosts, Cancel is only meaningful for "asynchronous" calls (in which there are conceptually multiple threads of control). At this time, LIPC describes "asynchronous calling" as out of scope, since it is a property of the call, not of the interface, and is only supported by a few programming languages (Modula2, Ada, and PL/I). RPC Part 1 is also totally silent on the subject of "asynchronous calls". Thus Cancel is part of the RPC service model, but not a part of the procedure-call model. It should be described within RPC as a separate function provided by the RPC 'server' (although all the providers implementating the procedure calling function may be involved). Item 1.16: The Procedure Call Context Type: m Ref: 5.5, 5.8 It is clear that the initiation of a client call creates something and that something is, in a larger sense, what an "interface reference" refers to. Specifically, LIPC introduces the notion of a "call context", which is conceptually created at the time of the (primary) call and is the (shared) context in which the called procedure is executed. Among other things, the call context contains the actual parameter values and other values accessible through them. The execution of a called-procedure in an interface instance depends on both the call context and the more static execution context. It is specifically, the "call context" which distinguishes a primary call from a callback. Regardless of direction of the callback, the callback creates a call-context for the called procedure which is derived from the call context of the primary (client) call. By comparison, a primary call derives its call context solely from the (shared) execution context and the parameters of the call. We suggest that RPC could benefit from the use of the call context notion in explaining the "interface reference" and the "client call" and "callback" concepts. Item 1.17: RPC calls cannot be completely transparent. Type: Note. Ref: 5. It is NOT the case that a remote procedure call can be made generally indistinguishable from a local (language-independent) call. a. The absence of a truly shared execution context in the RPC case will necessarily create limitations on the handling of locally sharable objects such as files and pointer spaces. b. In the callback situation, there may be a detectable difference in the "call context" which could cause a number of anomalous results. Consider the case where a procedure 'Sue' calls (remotely) a procedure 'Mary', which in turns makes a callback to a procedure 'Sam' (using a reference supplied explicitly or implicitly by Sue). The callback rules require Sam to behave as if it were called by 'Sue' in terms of its procedure context! It does not behave as if it were called by a local 'Mary', if the intermediate Mary context affects the execution of Sam. Note that these limitations do not affect the wide applicability of RPC, but they do affect the degree to which it is "transparent". Note also that some programming languages may be sufficiently restrictive as to prevent these cases from occurring, and some LIPC implementations may have the same effects. The difference is that in the RPC case, the situation requires this behaviour, while the language and LIPC implementations can, but need not, behave differently. Item 1.18: Use "implementation-defined" and "implementation-dependent" Type: m Ref: 5. The following terms have been in use in ISO language standards for the last 10 years and make an important distinction in requirements: "Implementation-defined" describes a capability, such as default character-set, or an event, such as data conversion error, which must be supported/provided/detected by all implementations, but whose details will vary from one implementation to another. Each implementation is required to document the details of its handling of implementation-defined features. "Implementation-dependent" describes a capability, such as Cancel, or event, such as an invalid combination of parameters, which may be supported/provided/detected, but not necessarily in all cases, and is very much dependent on the details of the implementation. Such capabilities or events need not be documented in detail - they are considered to be "defined" as whatever the compiler or library does. These terms are also used in the LIPC. We believe that the RPC conformance clauses would benefit from their use where appropriate. The SC22 definitions, with "provider" substituted for "language processor" are: implementation-defined: Possibly differing between providers, but defined for any particular provider. implementation-dependent: Possibly differing between providers, and not necessarily defined for any particular provider. --------------------------------------------------------------------- Comments on Part 2 --------------------------------------------------------------------- Item 2.1: Form of the Grammar in Part 2. Type: m Ref: 7. An agreement was reached among the experts at the joint meeting on meta-syntax for the IDN grammars in LID, LIPC and RPC. We agreed the following: - use some end-of-production marker in all productions. - put non-terminals in italics in text references. - put all terminals in double-quotes (") in text references. - within non-terminal identifiers, use hyphen and not underscore to separate multiple words. It was agreed that LIPC will use the meta-notation conventions currently in LID. We strongly recommend that RPC use the same conventions. (We jointly considered and rejected use of BS 6143, because it is not in common use anywhere and is cumbersome.) Item 2.2: Reserved Words. Type: m Ref: 8.1. The joint discussions included the question of whether all terminal keywords should be "reserved", i.e. disallowed as identifiers. WG11 does not object to this, but the LI standards would reserve many more words immediately if all currently incorporated datatype names are reserved, and we have every reason to expect that additional standard datatypes will evolve in the future. We suggest that only the keywords which MUST be distinguishable from identifiers should be reserved. That is, it is not necessary to reserve words which appear where an identifier is permitted, unless either the semantics of the keyword are entirely different from those of any identifier or the syntax which follows the keyword could not follow an identifier. In particular, type-specifiers of the form: [ ( ) ] do not require reserved words, since the syntax does not depend on whether the type-identifier is predefined or user-defined. The pre-defined type-identifiers (e.g. integer, character, etc.) should be considered to be in the name space of type references, and the uniqueness rules of Part2, subclause 10.1.1 applied. Note that the datatypes of the parameter values, if any, can be determined (by lookup of the type-identifier) before they are scanned, although that should not be necessary to achieve a correct syntactic parse. The predefined datatype generators (pointer, procedure, choice, record, array, and table in LIPC), on the other hand, introduce special syntax and therefore should be reserved words, in order to simplify the construction of parsers. The LIPC generators set, sequence and bag, and user-defined generators should not be reserved words, since they can be treated (with a minor syntax change) as part of the type-reference name space. This avoids alignment problems resulting from a larger reserved-word list. With the current grammar, the reserved words then should be: array, begin, choice, client?, default, end, excluding*, from, import, in, inout, interface, new*, of, out, plus*, pointer, procedure, raises, range*, record, restricted?, returns, selecting*, server?, size, subtype*, table*, termination, to, type, unaliased?, value. where * indicates a keyword which appears only in the LIPC, and ? indicates a keyword which may only appear in the RPC. (This list will undoubtedly change as comments on the three standards are resolved.) Item 2.3: Extensions aka Annotations. Type: m Ref: 8.7 The differences between the RPC extensions and LIPC annotations were discussed. The following was agreed, and is suggested: a. The square-brackets ([,]) are in the IRV of ISO 646, although they are reserved for national use. They should (continue to) be used for annotation delimiters, instead of the clumsy %( and )% which suddenly appeared in this draft of the RPC. If it is desired to avoid national use characters, the "pointy brackets" (<,>) could be used, but at the same time the "curly brackets" ({,}) (also national-use characters) used in OSI object-identifier values should be changed as well. b. RPC could use the text from LID, subclause 7.4, last paragraph to address the editor's note at the end of RPC's subclause 8.7. c. The meaning of the "extension" syntax is to annotate a particular grammatical element with additional information for a particular purpose, so the construct should be called an "annotation". It is possible that any of RPC, LIPC, LID or language-mapping standards may need (now or in the future) to define some such "annotations" (e.g. for marshalling instructions), and thus the term "extension", which implies "non-standard", is inappropriate. d. We agree that object-identifier, with suitable explanation about abbreviations, is sufficient as a "source". It is desirable to omit the braces from the value syntax (ref. LID 7.4). Item 2.4: Interface-identifiers. Type: Note. Ref: 9.1 LIPC allows interface identifiers to be object identifiers or simple identifiers to accomodate both RPC and local mechanisms. This means that, as in much of the LI Datatypes syntax, the RPC syntax for interface-identifier is a restriction of the "global" IDN. Item 2.5: Type declarations. Type: Note Ref: 9.5 In 2nd CD LI Datatypes, type and generator declarations have been modified so that the RPC type-declaration is a proper subset. Item 2.6: Character datatypes. Type: M Ref: 9.5.1.8 WG11 agrees with the spirit of the RPC changes to the character datatype, but disagrees with several details. First, a character (or character string) can only come from one reference repertoire, if any sense is going to made of either its encoding or its abstract value. Therefore, the RPC notion of repertoire list is inaccurate. The list must be a list of subsets of a single reference repertoire, so that, among other things, overlaps can be handled (how many different SPACE characters are there?) and a consistent encoding can be determined. Second, hard-coding a few values of the "repertoire-identifier" datatype in the grammar is a bad precedent, because implementations will inevitably define their own extensions in the same way. The object-identifier mechanism used for other such name spaces is a much better method of resolving the unambiguous extensible naming problem. In fact, the question of exactly which character sets will be supported by ALL implementations is more of an ISP issue than an application-layer standard issue, and use of object-identifier allows that decision to be deferred. Third, special syntax for the ISO 10646 case is undesirable, because it makes the character-type syntax unusual, which in turn affects type-declaration and reserved words. We suggest that this case can be handled by the following assumption: { iso standard 10646 collection(0) } is considered an object-identifier "inadvertently registered" by ISO 10646, which is itself the register. To satisfy purists, the syntax could read: object-identifier-value = "{" object-id-components-list "}" | collection-identifier . collection-identifier = "{ iso standard 10646 collection" collection-name "}". We suggest incorporating the following syntax from LID (2cd) and using or paraphrasing the accompanying text: character-type = "character" [ "(" repertoire-list ")" ] . repertoire-list = repertoire-identifier { "," repertoire-identifier } . repertoire-identifier = value-expression . "The value-expression for a repertoire-identifier shall designate a value of the object-identifier datatype, and that value shall refer to a character-set. All repertoire-identifiers in the repertoire-list shall designate subsets of a single reference character-set. When repertoire-list is not specified, it shall have a default value. The means for specification of the default is outside the scope of this draft International Standard. "The value space of a character datatype comprises exactly the members of the character-sets identified by the repertoire-list. In cases where the character-sets identified by the individual repertoire-identifiers have members in common, the value space of the character datatype contains only the distinct members." To satisfy ease-of-use concerns for RPC/LIPC, the "latin", "greek", "cyrillic", "japanese" identifiers can be (implicitly or explicitly) declared in value-declarations, such as: value latin: object_identifier = { iso standard 8859 1 }; This also serves to provide a "good example" for extensions. Item 2.7: Syntax bug for char_type. Type: m Ref: 9.5.1.3 The production for should be: ::= character of ( ) Omission of the parentheses causes to be ambiguous whenever there is more than one in it. We also recommend deletion of the keyword "of". Item 2.8: Interface-reference. Type: Note. Ref: 9.5.1.8 It is our understanding that "interface-reference" is an RPC-specific datatype, which does not appear to generalize to the LIPC context (or any other). "interface-reference" therefore will not appear in LI Datatypes nor LIPC. Item 2.9: Choice-type and Select-type alignment. Type: M Ref: 9.5.2.2 In spite of agreement in Arles on what in general was wanted for the choice-type, there are now significant differences between the RPC syntax and model and the LID/LIPC syntax and model. The model of the choice-type is still a subject of debate in both RPC and WG11, so further discussion is needed to achieve alignment. a. RPC changed the name of the datatype to select-type, for reasons which are unclear. (The term choice-type has been in use in both standards up until now.) The keyword "SELECT" would be a minor problem for users of either, since they also both contain the keyword "SELECTING". Moreover, the keyword CHOICE is that used in ASN.1 to name what is conceptually the same datatype. b. RPC describes the "discriminant" field as a value-reference, intending to obtain the tag-type via the object referred to. This syntax permits (whether intentionally or not) the discriminant to be a constant value, since a value reference could be a value- identifier or a value of an enumerated type or a formal datatype parameter. While this is technically not a problem, we assume that the intent was that the discriminant be what LID calls a "dependent-value", i.e. a reference to another argument or field. LID/LIPC require the type-specifier for the tag-type here, not a reference to a particular value thereof, because the tag-type is a component of the datatype, while a particular value of the tag-type is at best a component of a particular value of the choice-type. c. RPC requires the alternatives to have both selection values () and , except for void. The LID/LIPC does not provide for field-names. WG11 does not object to this syntax, if the motivation for the names could be described. d. LID/LIPC modified the syntax to force the default-alternative to be last, in order to satisfy a liaison request from SC22 WG17. It is believed that this simplifies mapping to some languages. We request that RPC do the same. Item 2.10: Require alternatives to cover the tag-type. Type: m Ref: 9.5.2.2 It should be stated that if a default alternative is not present, that the supplied alternative subtypes must completely cover the value space of the discriminant. Otherwise, there are situations in which the choice value is undefined. Item 2.11: Termination Parameters Type: m Ref: 9.7 or 10.1 Any formal relationship (based on names, etc.) between termination parameters and "normal" arguments of a procedure (-type) makes it impossible to define standard terminations without risk of accidental association with user-defined parameters. The following requirement should be added to 9.7 or 10.1: Parameters in terminations are distinct semantically from each other and from ALL OTHER output or input/output parameters in the interaction model. That is, there shall not be any formal relationship between arguments in a termination-list and arguments in a procedure argument-list. (There may be implicit relationships for specific terminations, i.e. the definition of a termination may specify that the 3rd parameter of the termination will have the same value as the second input argument or as would have been supplied to the first output argument on a normal termination.) Item 2.12: Unaliased Pointers. Type: m Ref: 9.5.2.4 The notion "unaliased" does not describe the pointer datatype itself, nor any generic property of or limitation on values of the type. Rather, it describes a state of the execution context at the time of a particular call on a procedure. Declaring a pointer "unaliased" means that the actual pointer value passed for this formal parameter is guaranteed at the time of the call not to name a "box" which is accessible by any other means available to the called procedure, including (but not restricted to!) other values of pointer type passed as, or through, other arguments to the same procedure. It is neither necessary nor sufficient to require that there be no other instance of that particular pointer "label" anywhere within the caller's execution context, if that is what "not statically or dynamically aliased with any other pointer" means. There is no problem with the caller having copies of the pointer value in multiple places; it is only necessary that the called procedure not have access to any of them. On the other hand, it is not sufficient that the label isn't duplicated anywhere. For example, if the pointer value refers to a component of an array or record and the entire aggregate is referenced by (or through) another pointer argument, the "labels" may be different, but simultaneous access is possible. Even worse is the possibility that the called procedure can callback a client procedure that uses name space access to the same "box" in the client execution context. In RPC, the context shared between the two open systems only includes the arguments; but in LIPC, and therefore in RPC callback cases, the context shared between two procedures on the same open system may include some form of "global variable" as well. Thus, like "in" and "out", "unaliased" is a property attached to a procedure parameter that goes beyond its datatype to refer to a state of the shared context. (See WG11 Nxxx - the Box and Context model.) For this reason, LI Datatypes will not include "unaliased", but LIPC will. The syntax is acceptable, but the definition should be revised to something like: "in" and "unaliased" means that any actual pointer value passed in this position is guaranteed at the time of the call not to name a "box" which is accessible by any other means to the called procedure, including any procedure the called procedure may reference. "out" and "unaliased" means that any actual pointer value passed in this position is guaranteed at the time of the return not to name a "box" which is accessible by any other means to the caller. Item 2.13: Restricted Pointers. Type: m Ref: 9.5.2.4 WG11 is uncertain what "restricted" is intended to mean. The limitation on the value space of restricted pointer values is handled by the LI Datatypes syntax "excluding(null)". Does "restricted" mean exactly "unaliased, excluding(null)"? If so, why is it stated that restricted pointers "can be supported efficiently"? It appears that they should be neither more nor less efficient than unaliased pointers. We suspect that almost all uses of "restricted pointer" are artifacts of implementation. Some programming languages, such as C, do not provide for the manipulation of values record-types or array-types as a unit, and do not permit them to be passed by value or returned as the principal result. As a consequence the programmer is required to manipulate "pointer to (R)" for what is conceptually just "R". The IDN user should declare such a parameter to be of type "R" and let the C mapping (and marshalling) handle the fact that the corresponding C datatype in the program will be R* (pointer to (R)). By the same token, many compilers optimize the passing of an array or record value in an implementation which passes the address of the first cell and lets the compiled subprogram manipulate the value via the (implicit) pointer. Clearly this is an issue for the marshalling routines for RPC, but it should not enter into the IDN, except possibly as an annotation. Finally, there is the case in which the user, for purposes of efficient storage management, builds a (tree) structure with pointers, even though each node logically "contains" all nodes subordinate to it. (This is again a language limitation: in LISP the programmer manipulates the subordinate nodes as "contained", while the compiler builds the pointer structure.) The contained datatype then logically has the form: Choice(T, Void) or Set of (T), but the implementation has the form: Pointer to (T). This is an interesting and debatable case, but it could NOT be a use of "restricted" because the efficiency and the success of the mechanism depend on allowing some values of the pointer to be "null". Item 2.14: Value-expressions. Type: m Ref: 9.4, 10.3 In the three CDs, the language generated by the RPC syntax and the language generated by the LIPC/LID syntax with respect to "value-expression" () are different in minor ways, and the formal syntaxes do not much resemble one another. The LIPC/LID syntax should be expanded to permit interface-identifier :: value-identifier, in order to allow the RPC language to be a proper subset, but this alone will not resolve the significant differences in syntactic approach. Some intermediate level of common syntax should be sought. Item 2.15: Object-identifier Type: m Ref: 9.4, 9.5 For reasons which are not clear, RPC does not permit the datatype Object-Identifier to be the datatype of any parameter, nor does it permit a value-declaration to name a value of object-identifier-type. The modifications to character-type make the latter feature desirable, and type-declarations for character-types might use object-identifier values as parameters, necessitating the former. Moreover, it is reasonable to suppose that RPC applications may have other reasons for manipulating the object-identifier datatype, since it is a commonly occurring datatype in ASN.1. We suggest: a. add the alternative "| " to the production for primitive-type. And add a section describing the type to 9.5.1, with the production: object-identifier-type = "object_identifier" . b. add the alternative "| " to the production for value-expression, and replace all occurrences of with . (The reason for the last is to avoid ambiguity of the term "object-identifier" and to be consistent with other LIPC/RPC naming. Every other xxx-identifier produces .) c. move the syntax and definition of object-identifier from 9.9 to 9.4. d. correct the production for object-id-component. The second alternative should be " ..." and not just "". That is, ASN.1 permits a "digit-string" or "number" here. ----------------------------------------------------------------- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Willem Wakker email: cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ACE Associated Computer Experts bv ...!mcsun!ace!willemw van Eeghenstraat 100 tel: +31 20 6646416 1071 GL Amsterdam fax: +31 20 6750389 The Netherlands tx: 11702 (ace nl) eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee