No assumption can be made within the EC++ definition about communication methods, communication requirements and communication implementations due to the range of hardware architectures Europa is attempting to cover.
It is clear, however, that base objects within EC++ will require to communicate to allow useful parallel code to be written. For that reason, EC++ should attempt to define a communications interface which allows base objects to communicate. This can then be implemented in specific instantiations of the language in the most appropriate manner for the target architecture of that instantiation. This communications interface need not be seen by applications writers, and indeed situations may exist where it is better for it not to be available to applications writers directly - instead having language extensions/language libraries which offer a further level of abstraction, but in standardising the interface to this layer language designers can rely upon specific communications and maintain a higher level of compatibility between systems.
In defining only the interface to communications, and not the communications methods themselves (i.e. defining the call to a communication, and not how the communication actually takes place), EC++ explicitly avoids assuming any form of message passing systems, shared memory communication et all, and instead allows all of these to be implemented in terms of the interface.