!standard E.4 (20) 00-04-11 AI95-00082/03 !standard E.5 (24) !class binding interpretation 95-07-27 !status Corrigendum 2000 99-07-08 !status WG9 approved 95-06-14 !status ARG approved (subject to editorial review) 10-0-0 95-11-01 !status received 95-07-27 !qualifier Clarification !subject The PCS may be defined by the user !summary An implementation that conforms to Annex E, and that supports pragma Remote_Call_Interface (which is not required -- see E.2.3(20)) must allow the user to compile a body for System.RPC, and to compile children of System.RPC. Such an implementation must implement remote subprogram calls using (only) the facilities of System.RPC; the generated code is not allowed to depend on special properties of one particular implementation of System.RPC, but must work for any correct implementation of System.RPC. !question A(4) says: The implementation may restrict the replacement of language-defined compilation units. The implementation may restrict children of language-defined library units (other than Standard). Is this intended to apply to the body of System.RPC, or its children? (No.) May an implementation require that a particular version of System.RPC be used? (No.) !recommendation (See summary.) !wording (See corrigendum.) !discussion The intent is that the PCS be implemented by the user, or by a third party vendor -- it need not be implemented by the Ada compiler vendor. Hence, it is important that the user be able to provide a body, and child units, for System.RPC. This requires: (1) The Ada compiler vendor must allow users to compile the body and children of System.RPC, despite A(4). (2) The Ada compiler must generate code that will work properly with any correct implementation of the PCS; thus, the generated code must use the defined interface, and only that interface, and not depend on details of a particular PCS implementation. Thus, it would be correct for a validation test to provide a PCS implementation, and require the implementation to use that PCS in tests. !corrigendum E.05(24) @dinsa The implementation of the RPC-receiver shall be reentrant, thereby allowing concurrent calls on it from the PCS to service concurrent remote subprogram calls into the partition. @dinss An implementation shall not restrict the replacement of the body of System.RPC. An implementation shall not restrict children of System.RPC. The related implementation permissions in the introduction to Annex A do not apply. If the implementation of System.RPC is provided by the user, an implementation shall support remote subprogram calls as specified. !ACATS test Tests CXE5002 and CXE5003 use this capability. !appendix !section E.4(20) !subject vendor-supplied PCS !reference RM95-E.4(20) !from Dan Eilers 95-07-24 !reference as: 95-5232.a Dan Eilers 95-7-24>> !discussion This question was raised at the Jun 8,9 1994 ACVC review meeting, (not by me), but is forwarded here for tracking purposes. If a vendor supplies a PCS, is the vendor allowed to use that PCS for all ACVC testing (possibly because the vendor's code-generation somehow relies on it), or is the vendor required to use the ACVC-supplied PCS for certain ACVC tests? (the latter?) **************************************************************** !section E.5(27) !subject PCS supplied by third-party !reference RM95-A(4) !reference RM95-E.5(27) !from Dan Eilers 95-07-24 !reference as: 95-5232.b Dan Eilers 95-7-24>> !discussion This question was raised at the Jun 8,9 1994 ACVC review meeting, (not by me), but is forwarded here for tracking purposes. If a vendor doesn't supply a body for System.RPC (as permitted by E.5(27)), and doesn't allow replacement of System.RPC (as permitted by A(4)) with an ACVC-supplied body, can this vendor validate Annex E? (no?) **************************************************************** !section E.4(20) !subject vendor-supplied PCS !reference RM95-E.4(20) !reference RM95-A(4) !reference RM95-E.5(27) !reference 95-5232.b Dan Eilers 95-7-24 !reference 95-5232.a Dan Eilers 95-7-24 !from Erhard Ploedereder !reference as: 95-5235.a Erhard Ploedereder 95-7-26>> !discussion > If a vendor supplies a PCS, is the vendor allowed to use that PCS > for all ACVC testing (possibly because the vendor's code-generation > somehow relies on it), or is the vendor required to use the ACVC-supplied > PCS for certain ACVC tests? (the latter?) > If a vendor doesn't supply a body for System.RPC (as permitted > by E.5(27)), and doesn't allow replacement of System.RPC (as > permitted by A(4)) with an ACVC-supplied body, can this vendor > validate Annex E? (no?) My opinion, as reflected in the minutes of the ACVC reviewer meeting: if an implementation provides a PCS and allows it to be replaced, all of the tests should be applicable; if it doesn't allow replacement, then some tests will be inapplicable; if it doesn't provide a PCS, then it must accept a replacement (and all tests will be applicable). (To actually check the pragma All_Calls_Remote, a replacement of the PCS by a ACVC-provided one seems necessary; hence the above possibility of inapplicable tests, if the implementation doesn't allow replacement.) On the second question, a definite "no". Presumably this is a rethorical question in the first place, akin to "is a restriction to 10-line compilation units allowed?". **************************************************************** !section E.4(20) !subject vendor-supplied PCS !reference RM95-E.4(20) !reference 95-5232.a Dan Eilers 95-7-24 !from Anthony Gargaro 95-7-26 !reference as: 95-5236.a Anthony Gargaro 95-7-26>> !discussion > This question was raised at the Jun 8,9 1994 ACVC review meeting, > (not by me), but is forwarded here for tracking purposes. > If a vendor supplies a PCS, is the vendor allowed to use that PCS > for all ACVC testing (possibly because the vendor's code-generation > somehow relies on it), or is the vendor required to use the ACVC-supplied > PCS for certain ACVC tests? (the latter?) There was some discussion of this issue at the last International Real-Time Ada Issues Workshop in Santa Barbara. It seems that the most sensible approach is the following (and which I believe was acceptable to those at the workshop participating in the discussion). If an Ada implementation is presented for validation together with a PCS, then it may be validated providing that it passes the Annex E ACVC tests with that PCS. If an Ada implementation is presented for validation without a PCS then, it may be validated providing that it passes the Annex E ACVC tests with the ACVC-supplied PCS (as proposed by Richard Powers). In each case the validation will specify the conditions under which the implementation was validated. The advantage of this approach is that it provides the motivation for compiler vendors to support Annex E while not stifling the implementation permissions allowed for enhanced feature support. **************************************************************** !section E.4(20) !subject vendor-supplied PCS !reference RM95-E.4(20) !reference 95-5232.a Dan Eilers 95-7-24 !from Bob Duff !reference as: 95-5237.a Robert A Duff 95-7-26>> !discussion > This question was raised at the Jun 8,9 1994 ACVC review meeting, > (not by me), but is forwarded here for tracking purposes. > > If a vendor supplies a PCS, is the vendor allowed to use that PCS > for all ACVC testing (possibly because the vendor's code-generation > somehow relies on it), or is the vendor required to use the ACVC-supplied > PCS for certain ACVC tests? (the latter?) The latter makes more sense to me. The whole point of this part of the language design is to allow people to plug in their own, or third-party, versions of the PCS. So the code-generation should not rely on some particular PCS. **************************************************************** !section E.5(27) !subject PCS supplied by third-party !reference RM95-A(4) !reference RM95-E.5(27) !reference 95-5232.b Dan Eilers 95-7-24 !from Bob Duff !reference as: 95-5237.b Robert A Duff 95-7-26>> !discussion > This question was raised at the Jun 8,9 1994 ACVC review meeting, > (not by me), but is forwarded here for tracking purposes. > > If a vendor doesn't supply a body for System.RPC (as permitted > by E.5(27)), and doesn't allow replacement of System.RPC (as > permitted by A(4)) with an ACVC-supplied body, can this vendor > validate Annex E? (no?) A(4) should be interpreted as not applying to System.RPC -- clearly, the vendor can't forbid replacement of System.RPC. - Bob **************************************************************** !section E.5(27) !subject PCS supplied by third-party !reference RM95-A(4) !reference RM95-E.5(27) !reference RM95-E.2.3(20) !reference 95-5232.b Dan Eilers 95-7-24 !from Anthony Gargaro 95-7-27 !reference as: 95-5238.a Anthony Gargaro 95-7-27>> !discussion > This question was raised at the Jun 8,9 1994 ACVC review meeting, > (not by me), but is forwarded here for tracking purposes. > If a vendor doesn't supply a body for System.RPC (as permitted > by E.5(27)), and doesn't allow replacement of System.RPC (as > permitted by A(4)) with an ACVC-supplied body, can this vendor > validate Annex E? (no?) Since support for the Remote_Call_Interface pragma is optional E.2.3(20), it seems that an implementation may validate Annex E under the conditions cited above. **************************************************************** !section E.4(20) !subject vendor-supplied PCS !reference RM95-E.4(20) !reference 95-5232.a Dan Eilers 95-7-24 !reference 95-5237.a Robert A Duff 95-7-26 !from Anthony Gargaro 95-7-27 !reference as: 95-5240.a Anthony Gargaro 95-7-27>> !discussion >> This question was raised at the Jun 8,9 1994 ACVC review meeting, >> (not by me), but is forwarded here for tracking purposes. >> >> If a vendor supplies a PCS, is the vendor allowed to use that PCS >> for all ACVC testing (possibly because the vendor's code-generation >> somehow relies on it), or is the vendor required to use the ACVC-supplied >> PCS for certain ACVC tests? (the latter?) > The latter makes more sense to me. The whole point of this part of the > language design is to allow people to plug in their own, or third-party, > versions of the PCS. So the code-generation should not rely on some > particular PCS. It is more accurate to say that the purpose of System.RPC is to allow implementations to permit third-party versions of the PCS in the absence of an implementation-provided PCS. > So the code-generation should not rely on some particular PCS. However, this should not be mandated by the ACVC tests. For example, child packages of System.RPC are permitted by E.5(26) and may be referenced to implement features of Annex E. Furthermore, these packages may use unspecified declarations in the private part of System.RPC. Thus, attempting to enforce such a rule in the ACVC tests seems beyond what is required by the Annex. **************************************************************** !section E.4(20) !subject vendor-supplied PCS !reference RM95-E.4(20) !reference 95-5232.a Dan Eilers 95-7-24 !reference 95-5237.a Robert A Duff 95-7-26 !reference 95-5240.a Anthony Gargaro 95-7-27 !from Tucker Taft 95-7-27 !reference as: 95-5241.a Tucker Taft 95-7-27>> !discussion > >> This question was raised at the Jun 8,9 1994 ACVC review meeting, > >> (not by me), but is forwarded here for tracking purposes. > >> > >> If a vendor supplies a PCS, is the vendor allowed to use that PCS > >> for all ACVC testing (possibly because the vendor's code-generation > >> somehow relies on it), or is the vendor required to use the ACVC-supplied > >> PCS for certain ACVC tests? (the latter?) > > > The latter makes more sense to me. The whole point of this part of the > > language design is to allow people to plug in their own, or third-party, > > versions of the PCS. So the code-generation should not rely on some > > particular PCS. > > It is more accurate to say that the purpose of System.RPC is to allow > implementations to permit third-party versions of the PCS in the absence of an > implementation-provided PCS. The intent is that the user should *always* be able to provide their own implementation of System.RPC. It totally defeats the purpose of having this standard interface if you are forced to use the compiler vendor's own implementation of it. > > So the code-generation should not rely on some particular PCS. > > However, this should not be mandated by the ACVC tests. For example, child > packages of System.RPC are permitted by E.5(26) and may be referenced to > implement features of Annex E. I don't agree. Where does the RM allow such a dependence on features outside of System.RPC for standard Annex E capabilities? The intent was that an implementor of a PCS could provide extra capabilities, not that a compiler could require extra capabilities. Compare E.5(1) with E.5(26). E.5(1) is a hard requirement to use the System.RPC interface to implement remote subprogram calls. E.5(26) is simply allowing the supplier of a PCS (not a compiler) to provide extra stuff for the user's benefit (not the compiler's benefit). These are very different things. > ... Furthermore, these packages may use unspecified > declarations in the private part of System.RPC. Thus, attempting to enforce > such a rule in the ACVC tests seems beyond what is required by the Annex. I don't agree. I believe a compiler should be required to work with whatever kind of "null" PCS that accompanies the ACVC suite. Otherwise, the definition of the standard System.RPC interface is a complete waste. -Tuck **************************************************************** !section E.4(20) !subject vendor-supplied PCS !reference RM95-E.4(20) !reference 95-5232.a Dan Eilers 95-7-24 !reference 95-5237.a Robert A Duff 95-7-26 !reference 95-5240.a Anthony Gargaro 95-7-27 !reference 95-5241.a Tucker Taft 95-7-27 !from Anthony Gargaro 95-7-28 !reference as: 95-5242.a Anthony Gargaro 95-7-28>> !discussion > I don't agree. Where does the RM allow such a dependence on features > outside of System.RPC for standard Annex E capabilities? The Annex neither allows nor disallows such a dependence. > Compare E.5(1) with E.5(26). E.5(1) is a hard requirement to use the > System.RPC interface to implement remote subprogram calls. E.5(1) states that a conforming implementation shall use the RPC interface; it does not require that a conforming implementation shall only use the RPC interface. > E.5(26) is simply allowing the supplier of a PCS (not a compiler) > to provide extra stuff for the user's benefit (not the compiler's benefit). > These are very different things. E.5(26) is an implementation permission and may be read as applying to either the compiler/PCS implementor or the PCS implementor. If it is restricted to the PCS implementor, then E.5(27) is somewhat difficult to interpret. > I don't agree. I believe a compiler should be required to work > with whatever kind of "null" PCS that accompanies the ACVC suite. This position may harm innovation by compiler implementations that provide a PCS. It serves no purpose to enforce this perceived compliance. Presumably, innovative implementations wishing to compete in the interchangeable PCS market will have a mode whereby they can be validated using the ACVC-supplied PCS. The important consideration is not to preclude an innovative implementation from validation. > Otherwise, the definition of the standard System.RPC interface > is a complete waste. I disagree. It provides exactly what is required to motivate compiler implementors to support the Annex without having to incur the cost of developing a PCS. **************************************************************** !section A(4) !subject PCS supplied by third-party !reference RM95-A(4) !reference RM95-E.5(27) !reference RM95-E.2.3(20) !reference 95-5232.b Dan Eilers 95-7-24 !reference 95-5238.a Anthony Gargaro 95-7-27 !from Bob Duff !reference as: 95-5243.a Robert A Duff 95-7-28>> !discussion > > This question was raised at the Jun 8,9 1994 ACVC review meeting, > > (not by me), but is forwarded here for tracking purposes. > > > If a vendor doesn't supply a body for System.RPC (as permitted > > by E.5(27)), and doesn't allow replacement of System.RPC (as > > permitted by A(4)) with an ACVC-supplied body, can this vendor > > validate Annex E? (no?) > > Since support for the Remote_Call_Interface pragma is optional E.2.3(20), it > seems that an implementation may validate Annex E under the conditions cited > above. True. (We should never have given in to the political pressure that caused us to add this permission. It makes "Conformance to Annex E" a rather useless concept. Too late to worry about that, though.) However, if the implementation *does* support R_C_I, then I think it has to do so in the standard way, which requires using the standard System.RPC interface, not relying on some vendor-supplied version of System.RPC. An implementation can of course have an *option* to rely on implementation-defined stuff. - Bob **************************************************************** !section E.4(20) !subject vendor-supplied PCS !reference RM95-E.4(20) !reference 95-5232.a Dan Eilers 95-7-24 !reference 95-5237.a Robert A Duff 95-7-26 !reference 95-5240.a Anthony Gargaro 95-7-27>> !from Ted Baker 95-7-28 !reference as: 95-5244.a Ted Baker 95-7-28>> !discussion | > The latter makes more sense to me. The whole point of this part of the | > language design is to allow people to plug in their own, or third-party, | > versions of the PCS. So the code-generation should not rely on some | > particular PCS. | It is more accurate to say that the purpose of System.RPC is to allow | implementations to permit third-party versions of the PCS in the absence of an | implementation-provided PCS. | However, this should not be mandated by the ACVC tests. For example, child | packages of System.RPC are permitted by E.5(26) and may be referenced to | implement features of Annex E. Furthermore, these packages may use unspecified | declarations in the private part of System.RPC. Thus, attempting to enforce | such a rule in the ACVC tests seems beyond what is required by the Annex. This sounds wrong to me. I thought the main selling point of the Ada support for distribution is that it is an "open" system. If you give in on this, you lose credibility. **************************************************************** !section E.4(20) !subject vendor-supplied PCS !reference RM95-E.4(20) !reference 95-5232.a Dan Eilers 95-7-24 !reference 95-5237.a Robert A Duff 95-7-26 !reference 95-5240.a Anthony Gargaro 95-7-27 !reference 95-5241.a Tucker Taft 95-7-27 !reference 95-5242.a Anthony Gargaro 95-7-28 !from Tucker Taft 95-7-28 !reference as: 95-5245.a Tucker Taft 95-7-28>> !discussion > > I don't agree. Where does the RM allow such a dependence on features > > outside of System.RPC for standard Annex E capabilities? > > The Annex neither allows nor disallows such a dependence. > > > Compare E.5(1) with E.5(26). E.5(1) is a hard requirement to use the > > System.RPC interface to implement remote subprogram calls. > > E.5(1) states that a conforming implementation shall use the RPC interface; it > does not require that a conforming implementation shall only use the RPC > interface. My understanding of the intent has always been that the compiler-generated stubs must not depend on anything outside the RPC interface. I believe you are playing word games here by claiming that "shall use the RPC interface" means "may but need not use the RPC interface." What possible force does this requirement have if we allow compiler-generated stubs to have arbitrary dependence on proprietary interfaces in order to implement RPC? > ... I believe a compiler should be required to work > > with whatever kind of "null" PCS that accompanies the ACVC suite. > > This position may harm innovation by compiler implementations that provide a > PCS. It serves no purpose to enforce this perceived compliance. Presumably, > innovative implementations wishing to compete in the interchangeable PCS > market will have a mode whereby they can be validated using the ACVC-supplied > PCS. The important consideration is not to preclude an innovative > implementation from validation. This does not harm innovation. The E.5(1) requirement in my view is that the compiler must work using any conforming implementation of System.RPC. It is allowed to work faster or more efficiently using some proprietary interfaces if desired, but that should be under control of a pragma, switch, etc. In the "standard" mode, it should use the System.RPC interfaces only. Otherwise E.5(1) means nothing. From the very beginning we emphasized the importance of the user being in charge of the actual communication protocols. The theory is that communication architectures vary all over the map, and there is no way the compiler vendor could provide solutions that handled all interesting communication architectures. Hence, we defined a standard interface which allowed the user to replace the PCS. -Tuck **************************************************************** !section A(4) !subject vendor-supplied PCS !reference RM95-A(4) !reference RM95-E.4(20) !reference RM95-E.5(1) !reference RM95-E.5(26) !reference RM95-E.5(27) !reference RM95-E.2.3(20) !reference 95-5232.a Dan Eilers 95-7-24 !reference 95-5232.b Dan Eilers 95-7-24 !reference 95-5235.a Erhard Ploedereder 95-7-26 !reference 95-5236.a Anthony Gargaro 95-7-26 !reference 95-5237.a Robert A Duff 95-7-26 !reference 95-5237.b Robert A Duff 95-7-26 !reference 95-5238.a Anthony Gargaro 95-7-27 !reference 95-5240.a Anthony Gargaro 95-7-27 !reference 95-5241.a Tucker Taft 95-7-27 !from Offer Pazy 95-7-29 !reference as: 95-5246.a Offer Pazy 95-7-29>> !discussion > ... and doesn't allow replacement of System.RPC (as > permitted by A(4)) with an ACVC-supplied body > A(4) should be interpreted as not applying to System.RPC -- clearly, the > vendor can't forbid replacement of System.RPC. I agree. I think the DS annnex should require that System.RPC must be replaceable. This is consistent with the approach to the annexes in that they can further restrict implementation permissions given in the core. As to teh general question, I fully agree with Bob and Tucker on this. The whole idea of the annex was to support open systems in the sense that users will be able to insert their own communication component, otherwise supporting the annex is not very useful. Remember that a likely scenario is that distributed systems will be constructed from partitions compiled by different compilers. Since we don't standardize on the message format, the only hook for the user is to code the PCS. Also, it is unlikely that the ACVC will test the annex in a real network environment, and it is not likely that vendors wil support many possible configurations, so again the only practical solution is to have third-party PCS. That was the whole motivation behind the annex. We certainly don't want to repeat the situation with early 83 ACVC's wherr the tests allowed delays to never actually expire and to IO to be implemented by raising a Use_Error (I'm not talking of course about embedded systems). Finally, as Tucker pointed out, it was never intended that the generated code will use specialized, private hooks (or child packages) to implement the basic RPC as defined by the annex. The child packages are intended for user-visible extentions, not the generated code. Child packages are mentioned in the annex not as a way for the implementation to use private intefaces (all semantics must be implemented using PCS itself), but rather to emphasize that *additional* feature should be placed in a separate place and not clutter System.PCS itself. To summarize I would suggest that implementations are either tested with the ACVC-supplied PCS or if they want to do it with their own PCS, this should work "against" an ACVC-supplied node so that conformance could be checked. Offer Pazy 31 Robinwood Ave. Boston, MA. 02130 USA (617)522-5988 pazy@world.std.com **************************************************************** !section E.4(20) !subject vendor-supplied PCS !reference RM95-E.4(20) !reference 95-5232.a Dan Eilers 95-7-24 !reference 95-5237.a Robert A Duff 95-7-26 !reference 95-5240.a Anthony Gargaro 95-7-27 !reference 95-5241.a Tucker Taft 95-7-27 !reference as: 95-5242.a Anthony Gargaro 95-7-28 !from Offer Pazy 95-7-29 !reference as: 95-5247.a Offer Pazy 95-7-29>> !discussion > The Annex neither allows nor disallows such a dependence. > E.5(1) states that a conforming implementation shall use the RPC interface > does not require that a conforming implementation shall only use the RPC > interface. I don't believe that this is a corerct reading of the words. The annex says: "Shall use the package to implement RPC". We are not (yet) at the stage of legally defending rules, but there is no confusion with respect to the intention and the rules. I don't think that implying that such ambiguity exists is beneficial at this point. > E.5(26) is an implementation permission and may be read as applying to eit > the compiler/PCS implementor or the PCS implementor. If it is restricted t > the PCS implementor, then E.5(27) is somewhat difficult to interpret. On the contrary, if you say that the permission to add children is for the compiler vendor then it does not make sense for it not to provide a body. We did face a wording problem with the annex since we were talking about potentially two entities, a compiler-vendor and a third-party (or a user), but I belive thatthe rule is that "implementation" by itself is the compilation system and when we mean otherwise, we say so. For example, in (26), we say "The PCS is allowed to have", not "the implementation is ..." > > I don't agree. I believe a compiler should be required to work > > with whatever kind of "null" PCS that accompanies the ACVC suite. > > This position may harm innovation by compiler implementations that provide > PCS. It serves no purpose to enforce this perceived compliance. Presumably > innovative implementations wishing to compete in the interchangeable PCS > market will have a mode whereby they can be validated using the ACVC-suppl > PCS. The important consideration is not to preclude an innovative > implementation from validation. But then again, this goes contrary to the whole motivation of the annex. The whole idea wa sthat we don't expect compiler vendors to be the *main* force behind innovation, experimentation and rich support of PCSs. If that was the goal, we didn't have to have a PCS. The compiler just provides a mimimum support and the real comm work is expected to come from elsewhere. This is where we shoudl ensure open interface and room for innovation. Of course, a compiler vendor may provide wonderful PCSs, but that was not the motivation of the annex approach. Offer Pazy 31 Robinwood Ave. Boston, MA. 02130 USA (617)522-5988 pazy@world.std.com **************************************************************** !section E.4(20) !subject vendor-supplied PCS !reference RM95-E.4(20) !reference 95-5232.a Dan Eilers 95-7-24 !reference 95-5237.a Robert A Duff 95-7-26 !reference 95-5240.a Anthony Gargaro 95-7-27 !reference 95-5241.a Tucker Taft 95-7-27 !reference 95-5242.a Anthony Gargaro 95-7-28 !reference 95-5245.a Tucker Taft 95-7-28 !from Anthony Gargaro 95-7-29 !reference as: 95-5248.a Anthony Gargaro 95-7-29>> !discussion > My understanding of the intent has always been that the compiler-generated > stubs must not depend on anything outside the RPC interface. I agree but my understanding is (or was) that the RPC interface does not exclude the child packages mentioned in E.5(26) for an implementation-provided PCS. > I believe you are playing word games here by claiming that "shall use > the RPC interface" means "may but need not use the RPC interface." Well, those are not quite my words. All I have said is that because the word "only" is missing then it is arguable that an implementation is disallowed from using additional interfaces provided in child packages. > It is allowed to work faster or more efficiently using some > proprietary interfaces if desired, but that should be under > control of a pragma, switch, etc. In the "standard" mode, it > should use the System.RPC interfaces only. Otherwise E.5(1) > means nothing. Then it seems you would allow an implementation to be validated that used additional interfaces providing that there is a mode whereby it can be validated using only the System.RPC interface.. Again, my only concern is not to exclude a compiler implementation that takes advantage of what I consider is a legitimate implementation permission in E.5(26) from validation. Can we agree on this point? **************************************************************** !from Randy Brukardt 99-7-8 !discussion The discussion above makes it clear that wording is needed to disallow an implementation from depending on facilities outside of System.RPC for implementing the communication needed for remote subprogram calls. This very hard to word. I tried variations of: An implementation shall not use facilities other than those defined by System.RPC to implement remote subprogram calls. but this makes it sound like internal library routines (for marshalling, perhaps) cannot be used. Therefore, I settled on a straightforward statement of what must be supported: An implementation shall support remote subprogram calls using an implementation of System.RPC provided by the user. An implementation which cheats in a visible way would violate this; and any other "cheating" isn't our business, anyway. ****************************************************************