WPCI 2%.B pz W"S^11>bbu"::Dg1:11bbbbbbbbbb11gggbuuuk1Xubuukuuuk111Rb:bbXbb1bb''X'bbbb:X1bXXXX;.;g:=::m:::mmmmm::::::mm:k1mubububububXubububub11111111bbbbbbbbbuXubbkbuXmmmmumububXXXXbububububbmbbbbbb:k:k::=kmmX:uXb'b:b:b:b'bmbbbb:::uXuXuXuXk:k:k:mbbbmbuXkXkXKQmmmm^b:kbbbbmbA@mmbmmbmmmmmmm:b:mmmbbmmmmmmmmmmmmXXmmmmmmmmmmmmmmmmmmcm`m`mm`m:mmmmmm}}}mjjmmmmmmmmmmmmmmm0mm}mmmmmmmmmmmmmmmmmmmmmmm}Mmmmmmmmmmmmmjmmmtmmmmmmmmm`'mmm`mmjmlWmmmmmmmmmmmmmmmmmmmW`mmmmjmM-lveticaHelveticaCourierCourier Bold4PkCQMS PS Jet Plus /800 II QPJPII.PRSPl`D4PkCg2W_qr#|xHelveticaCourier@ ,`H1`D4PkCmQrrr r  @C2 KG@ ,`H1`D4PkCmQrrr r  @CmQrrrr  `C ` X` hp x (#%'@    x|@  3'3'Standard6'6'StandardC6QMS $=R- Recommendation X.407 < MESSAGE HANDLING SYSTEMS ABSTRACT SERVICE <DEFINITION CONVENTIONS 1  `  The establishment in various countries of telematic services and computerbased storeandforward message services in association with public data networks creates a need to produce standards to facilitate international message exchange between subscribers to such services. The CCITT, considering (a)the need for Message Handling Systems; (b)that Message Handling is a complex distributed information processing task; (c)that a means for abstractly defining such tasks is required; (d)that Recommendation X.200 defines the Reference Model of Open Systems Interconnection for CCITT applications;  x (e)that Recommendations X.208, X.217, X.218, and X.219 provide the foundation for CCITT applications; unanimously declares (1)that conventions for defining abstract services are defined in section two; (2)that techniques for the realization of abstract services so defined are discussed in section three. Table of Contents Section One Introduction 0.Introduction 1.Scope 2.References 3.Definitions 4.Abbreviations 5.Conventions 5.1ASN.1 5.2Terms Section TWO Abstract Service Definition Conventions 6.Overview 7.Abstract Models 7.1Abstract Objects 7.2Abstract Ports 7.3Abstract Services 7.4Abstract Refinements 8.Abstract Services 8.1Abstract Procedures 8.2Abstract Bind Operations 8.3Abstract Unbind Operations 8.4Abstract Operations 8.5Abstract Errors Section Three Abstract Service Realizations 9.Overview 10.OSI Realizations 10.1ROS Realizations 10.2NonROS Realizations 11.Proprietary Realizations 11.1Distributed Realizations 11.2Nondistributed Realizations Annexes AExample of Use of Abstract Service Notation A.1Assignment of Object Identifiers F-ԌA.2Refinement of Yellow Environment A.3Definition of Yellow Abstract Service A.4Refinement of Green Environment A.5Definition of Green Abstract Service A.6Refinement of Yellow System A.7Realization of Yellow System A.8Realization of Green System BReference Definition of Object Identifiers CReference Definition of Notation DDifferences Between CCITT Recommendation and ISO Standard EIndex CCITT Draft Recommendation X.407 MHS: Abstract Service Definition Conventions (Version 5, November 1987, Gloucester) Section One Introduction 0.Introduction This Recommendation is one of a set of Recommendations for Message Handling. The entire set provides a comprehensive blueprint for a Message Handling System (MHS) realized by any number of cooperating open systems. The Message Handling System made possible by these Recommendations is a complex distributed information processing task, many of whose components themselves have these characteristics. This Recommendation specifies the conventions for defining the distributed information processing tasks of Message Handling and may also be useful for other applications. The text of this Recommendation is the subject of joint CCITTISO agreement. The corresponding ISO specification is ISO 100214. 1.Scope This Recommendation specifies the conventions used to specify the distributed information processing tasks that arise in Message Handling. This Recommendation is structured as follows. Section one is this introduction. Section two specifies the conventions for defining a distributed information processing task abstractly. Section three gives principles for realizing the communication aspects of such tasks concretely, such as by Open Systems Interconnection (OSI) protocols. Annexes provide important supplemental information. There are no requirements for conformance to this Recommendation. 2.References This Recommendation cites the documents below. X.200Basic reference model (see also ISO 7498). X.208Specification of abstract syntax notation one (ASN.1) (see also H@ DD@ DISO8824). X.209Specification of basic encoding rules for abstract syntax notation one O^#KK^#K(ASN.1) (see also ISO 8825). X.217Association control: Service definition (see also ISO 8649). X.219Remote operations: Model, notation and service definition (see also L"HH"HISO90721). 3.Definitions For the purposes of this Recommendation, the definition of Annex E and below apply. This Recommendation is based upon the concepts developed in Recommendation X.200 and uses the following terms defined in it: a)abstract syntax; b)Application Layer; c)application protocol data unit (.I.ab:APDU;); d)application protocol; e)application service element (.I.ab:ASE;); f)concrete transfer syntax; g)distributed information processing task; h)layer service; i)layer; F-Ԍj)open system; k)Open Systems Interconnection (.I.ab:OSI;); and l)real open system. This Recommendation uses the following terms defined in Recommendation X.208: a)Abstract Syntax Notation One (.I.ab:ASN.1;); b)(data) type; c)(data) value; d)import; e)Integer; f)macro; g)module; h)Object Identifier; and i)tag. This Recommendation uses the following terms defined in Recommendation X.209: a)Basic Encoding Rules. This Recommendation uses the following terms defined in Recommendation X.217: a)application context (.I.ab:AC;). This Recommendation uses the following terms defined in Recommendation X.219: a)bind operation; b)error; c)linked; d)operation; e)Remote Operation Service (.I.ab:ROS;); f)Remote Operations; and g)unbind operation. 4.Abbreviations For the purposes of this Recommendation, the abbreviations of annex E apply. 5.Conventions This Recommendation uses the descriptive conventions identified below. 5.1ASN.1 This Recommendation uses for the indicated purposes the following ASN.1based descriptive conventions. a)To define the OBJECT, PORT, and REFINE macros, the ASN.1 macro notation of Recommendation X.208. b)To define the ABSTRACTBIND, UNBIND, OPERATION, and ERROR macros, the BIND, UNBIND, OPERATION, and ERROR macros of Recommendation X.219. c)To specify the abstract syntax of information objects in the example of annex A, ASN.1 itself. d)To specify various abstract models in the example of annex A, the OBJECT, PORT, and REFINE macros of clause 7. e)To specify various abstract services in the example of annex A, the ABSTRACTBIND, OPERATION, and ERROR macros of clause 8. ASN.1 appears both in the body of this Recommendation to aid the exposition and again, largely redundantly, in annexes for reference. If differences are found between the two, a specification error is indicated. Note that ASN.1 tags are implicit throughout the ASN.1 modules in the annexes; the modules are definitive in that respect. 5.2Terms Throughout this Recommendation, terms are rendered in bold when defined, in italic when referenced prior to their definitions, without emphasis upon all other occasions. Terms that are proper nouns are capitalized, generic terms are not. Section TWO Abstract Service Definition Conventions 6.Overview When faced with the job of describing and specifying a complex distributed information processing task, one is wise to begin by specifying the task in abstract, rather than concrete terms. This approach ensures that the task's functional requirements are stated independently of its concrete realization. Such separation is important, among other reasons, because each aspect of the task may admit of several concrete realizations. In a Message Transfer System comprising three message transfer agents, e.g., the first and F- second might interact using OSI communication, the second and third by proprietary means. This section specifies the conventions for abstractly describing a distributed information processing task both macroscopically and microscopically. The former description is called an abstract model, the latter an abstract service. Various formal tools for specifying abstract models and services are defined in this section. A comprehensive example of their use is given in annex A. The reader may wish to refer to that annexe.g., to its illustrationswhile reading the present section. This section covers the following topics: a)Abstract models b)Abstract services Note The formal tools mentioned above are neither a formal description language nor a substitute therefor. They are simply ASN.1 notation that supports the informal descriptive conventions this section defines. 7.Abstract Models A macroscopic description of a distributed information processing task is called an .I.gl:abstract model; (.I.gl:model;) of that task and of the environment in which it is carried out. It is based upon the concepts of abstract objects, ports, services, and refinements. (The concept of an abstract service is much more fully developed in clause 8.) 7.1Abstract Objects An .I.gl:abstract object; (.I.gl:object;) is a functional entity, one of perhaps several which interact with one another. Objects are of different types which determine their function and behavior. An object of one type, e.g., might represent a system, multiple objects of another type its users. Objects interact by means of abstract ports. An object type is specified by means of the OBJECT macro. Such a specification lists the types of abstract ports that provide access to such an object. For each assymetric port type, the specification indicates whether the ports of that type are consumer or supplier ports. .I.ma:OBJECT; MACRO ::= BEGIN TYPE NOTATION ::= "PORTS" "{" PortList "}" | empty VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) PortList ::= Port "," PortList | Port Port ::= value (PORT) PortType PortType ::= Symmetric | Asymmetric Symmetric ::= empty Asymmetric ::= Consumer | Supplier Consumer ::= "[C]" Supplier ::= "[S]" END @ HHA data value of type OBJECT is an Object Identifier that unambiguously and uniquely identifies the specified object type. Note The keyword "OBJECT" is reserved in ASN.1. Selection of a suitable replacement for use in the present context is for further study . 7.2HAbstract Ports HAn abstract port (port) is a point at which an abstract object interacts with another abstract object. Ports are of different types which determine the kinds of interactions they enable. Ports of one type, e.g., might represent the means by which a directory system is accessed, ports of another type the means by which it is administered. Port types are themselves of the following two varieties: Ha)  symmetric: All instances of a symmetric port type are identical.  x HHb)X  asymmetric: Each instance of an asymmetric port type is of one of two kinds, supplier and consumer.%  `   ` X Note A particular allocation of the terms "supplier" and "consumer" is often intuitive. One might naturally consider a file system, e.g., to present supplier ports to its users and administrators. Strictly speaking, however, the assignment of the two terms is arbitrary. HTwo objects can interact with one another by means of a port in one and a port in the other only while those ports are in contact with one another, or bound. F- The actions by means of which this state is initiated and terminated for one or more port pairs are called binding and unbinding, respectively. HTwo ports can be bound only if they match. Any two ports of the same, symmetric type match. Two ports of the same, asymmetric type match if and only if one is a supplier, the other a consumer. HA port type is specified by means of the PORT macro. Such a specification identifies the abstract operations that represent the interactions possible while two such ports are bound. If none is listed, the abstract operations shall be considered unspecified. H@  .I.ma:PORT; MACRO ::= BEGIN TYPE NOTATION ::= Operations | empty VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) Operations ::= Symmetrical | Asymmetrical Symmetrical ::= "ABSTRACT" "OPERATIONS" "{" OperationList "}" Asymmetrical ::= OneSided | TwoSided OneSided ::= Consumer | Supplier TwoSided ::= Consumer Supplier | Supplier Consumer Consumer ::= "CONSUMER" "INVOKES" "{" OperationList "}" Supplier ::= "SUPPLIER" "INVOKES" "{" OperationList "}" OperationList ::= Operation "," OperationList | Operation Operation ::= value (ABSTRACTOPERATION) END @ H HIf the port type is symmetric, both objects offer all listed abstract operations. If the port type is asymmetric, the macro distinguishes between the abstract operations an object with the consumer port offers and those an object with the supplier port offers. HA data value of type PORT is an Object Identifier that unambiguously and uniquely identifies the specified port type. 7.3HAbstract Services HAn abstract service is the set of capabilities that one object offers to another by means of one or more of its ports. The former object is called an abstract service provider (provider), the latter an abstract service user (user). Each port in question may be either symmetric or asymmetric and, if the latter, either consumer or supplier. HAn abstract service may have any number of users and providers. HWhenever the abstract service ports of a provider are bound to the matching ports of a user, an abstract association (or association is said to exist between the two objects. HAn abstract service is specified as indicated in clause 8. Note An abstract service serves much the same purpose within the Application Layer as does one of the layer services of lower OSI layers. 7.4HAbstract Refinements HAn object can be viewed in different ways at different times. On some occasions it is convenient to think of an object as atomic. This is the case, e.g., when describing how an object interacts with other objects external to it, i.e., when specifying its abstract service. On other occasions, it may be more convenient to think of an object as composite, i.e., constructed from other objects. This might be the case, e.g., when describing how an object is realized. HLike any objects, component objects have ports. Some are those visible on the "surface" of the constructed object. Others enable the component objects to interact, thus supporting the provision and use of lesser abstract services among the component objects, which cooperate to provide the overall abstract service of the constructed object. F-Ԍ HThe functional decomposition of an object into several lesser objects is called the abstract refinement (refinement) of that object. HThe technique of refinement can be applied recursively. A component object can itself be refined to reveal its internal structure. This can continue until one reaches component objects best considered atomic. HA refinement is specified by means of the REFINE macro. It identifies the object whose internal structure is being revealed and the component objects used in its construction. Each component object is characterized as either unique or recurring. The macro also indicates which ports of component objects are bound to ports of other component objects, and which are visible at the surface of the composite object. H@ .I.ma:REFINE; MACRO ::= BEGIN TYPE NOTATION ::= Object "AS" ComponentList VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) ComponentList ::= Component ComponentList | Component Component ::= ObjectSpec Ports ObjectSpec ::= Object | Object "RECURRING" Ports ::= PortSpecList | empty PortSpecList ::= PortSpec PortSpecList | PortSpec PortSpec ::= value (PORT) PortSide PortStatus PortSide ::= Consumer | Supplier | empty Consumer ::= "[C]" Supplier ::= "[S]" PortStatus ::= "VISIBLE" | "PAIRED" "WITH" ObjectList ObjectList ::= Object "," ObjectList | Object Object ::= value (OBJECT) END A data value of type REFINE is an Object Identifier. Note As with objects themselves, ports, in principle, can be viewed in different ways at different times. On some occasions, it is convenient to think of a port (pair) as atomic. However, one can imagine refining a port itself to examine how communication of this type can be provided. In this view, a port pair is itself viewed as being supported by a collection of objects. This would enhance the ability to specify communications capabilities. This "port refinement" concept is not pursued further in this version of this Recommendation. 8.Abstract Services A microscopic description of a distributed information processing task is a specification of the abstract service that defines how the task is initiated, controlled, and terminated. It is based upon the concepts of abstract bind operations, unbind operations, operations, and errors, as well as the enabling concept of abstract procedures. Note The macros defined below imply use of ASN.1 to specify arguments, results, and parameters. Any contextspecific tags, e.g., assigned in the course of the specifications, although meaningless in that context, play an important role in a ROS realization of the abstract service. 8.1Abstract Procedures An .I.gl:abstract procedure; (.I.gl:procedure;) is a task that one object carries out at another's request. The making of the request and the carrying out of the task are called the .I.gl:invocation; and .I.gl:performance; of the procedure. The objects that issue and act upon the request are called the .I.gl:invoker; and .I.gl:performer;, respectively. A procedure may (but need not) require that an invoker, upon invocation, supply to the performer a single information object of a prescribed type, which is called the procedure's .I.gl:argument;. Every performance of every procedure has an outcome, success or failure. A procedure is considered to succeed if it is carried out in full, to fail if it is terminated prematurely. A procedure may (but need not) require that the performer apprise the invoker of success. It may (but need not) further require that it supply, when reporting success, a single information object of a prescribed type, which is called the procedure's .I.gl:result;. A procedure may (but need not) require that the performer apprise the invoker of failure. It may (but need not) further require that it supply certain information when reporting failure. Note In subsequent clauses ASN.1 is prescribed as the means for specifying the F- abstract syntax of the arguments and results of procedures (as well as of the parameters of abstract errors). These uses of ASN.1 do not imply that these information objects are necessarily transported between open systems. In particular, the fact that the information objects, by virtue of their description in ASN.1 and of its Basic Encoding Rules, have concrete transfer syntaxes is immaterial in the present context. ASN.1 is simply a convenient tool for formally describing the information objects' abstract syntax. 8.2Abstract Bind Operations An .I.gl:abstract bind operation; is a procedure whose successful performance binds one or more pairs of abstract ports. The object which invokes an abstract bind operation is said to be the .I.gl:initiator;, that which performs it the .I.gl:responder;. An abstract bind operation is suitable for binding a particular set of ports of the initiator to a matching set of the responder. Where one or more ports in the set are asymmetric, the abstract bind operation may be suitable for binding to the consumer side only, the supplier side only, or to either. An abstract bind operation is a fully general procedure except that, if information is conveyed to the invoker upon failure, it is constrained to a single information object, called .I.gl:error information;. An abstract bind operation is specified by means of the ABSTRACTBIND macro whose definition is as follows: .I.ma:ABSTRACTBIND; MACRO ::= BEGIN TYPE NOTATION ::= Ports Bind VALUE NOTATION ::= value (VALUE BindType) Ports ::= "TO" "{" PortList "}" | empty PortList ::= Port "," PortList | Port Port ::= value (PORT) PortSide PortSide ::= Consumer | Supplier | empty Consumer ::= "[C]" Supplier ::= "[S]" Bind ::= type (BindType) must be a BIND type | empty END The "Ports" clause, introduced by the keyword "TO", lists the ports of a responder which this abstract bind operation will bind. If an asymmetric port is listed there, without being qualified by "[S]" or "[C]", this means that the abstract bind operation is suitable for use in binding such a port in either direction. Note that the specification of the argument, result, and/or error information is accomplished by means of an (embedded) BIND macro of Remote Operations, defined in Recommendation X.219, and it is a value of such a type that the macro returns. If none is provided, the default "BIND" is returned. Note The relationship of ABSTRACTBIND and BIND can help make trivial the ROS realization of an abstract service; see clause 10.1. An abstract service typically comprises an abstract bind operation for each type of port involved in its provision. When several port types are involved, their abstract bind operations may but need not be distinct. 8.3Abstract Unbind Operations An .I.gl:abstract unbind operation; is a procedure whose performance, successful or not, unbinds two ports. It is invoked by the object which invoked the corresponding abstract bind (i.e., the initiator) and performed by the responder. An abstract unbind operation is suitable for unbinding a particular set of ports of the initiator from a matching set of the responder. Where one or more ports in the set are asymmetric, the abstract unbind operation may be suitable for unbinding from the consumer side only, the supplier side only, or either. An abstract unbind operation is a fully general procedure except that, if information is conveyed to the invoker upon failure, it is constrained to a single information object, called .I.gl:error information;. An abstract unbind operation is specified by means of the ABSTRACTUNBIND macro whose definition is as follows: .I.ma:ABSTRACTUNBIND; MACRO ::= BEGIN TYPE NOTATION ::= Ports Unbind VALUE NOTATION ::= value (VALUE UnbindType) Ports ::= "FROM" "{" PortList "}" PortList ::= Port "," PortList | Port Port ::= value (PORT) PortSide PortSide ::= Consumer | Supplier | empty Consumer ::= "[C]" Supplier ::= "[S]" Unbind ::= type (UnbindType) | must be an UNBIND type empty END The "Ports" clause, introduced by the keyword "FROM", lists the ports of a responder from which this abstract unbind operation will unbind. If an asymmetric port is listed there, without being qualified by "[S]" or "[C]", this means that the F- abstract unbind operation is suitable for use in unbinding such a port in either direction (although the actual direction is determined by the direction in which the bind took place). Note that the specification of the argument, result, and/or error information is accomplished by means of an (embedded) UNBIND macro of Remote Operations, defined in Recommendation X.219, and it is a value of such a type that the macro returns. If none is provided, the default "UNBIND" is returned. Note The relationship of ABSTRACTUNBIND and UNBIND helps make trivial the ROS realization of an abstract service; see clause 10.1. An abstract service typically comprises an abstract unbind operation for each type of port involved in its provision. When several port types are involved, their abstract unbind operations may but need not be distinct. 8.4Abstract Operations An .I.gl:abstract operation; is a procedure that may be invoked in the context of two bound ports. Its failure has no effect upon the binding. If the ports are assymmetric, whether the invoker is the object having the consumer port, the object having the supplier port, or either is prescribed by the port. If the ports are symmetric, the invoker may be either object. Whether the ports are symmetric or asymmetric, the remaining object is the performer. An abstract operation is a fully general procedure except for the information conveyed to the invoker upon failure. An abstract operation fails when it encounters an abstract error, and the information conveyed is constrained to that required to report that abstract error. Whether failure is reported and, if so, which abstract errors can be encountered are prescribed for each abstract operation. An abstract operation is specified by means of the ABSTRACTOPERATION macro. Its definition is identical to that of the OPERATION macro of Remote Operations, specified in Recommendation X.219. .I.ma:ABSTRACTOPERATION; MACRO ::= OPERATION An abstract service comprises zero or more abstract operations for each type of port involved in its provision. When several port types are involved, they may but need not have abstract operations in common. Note The equivalence of ABSTRACTOPERATION and OPERATION helps make trivial the ROS realization of an abstract service; see clause 10.1. 8.5Abstract Errors An .I.gl:abstract error; is an exceptional condition that may arise during the performance of an abstract operation, causing it to fail. When an abstract error is reported, the performer conveys to the invoker the identity of the abstract error and possibly a single information object called its .I.gl:parameter;. Whether a parameter is returned and, if so, its type are prescribed for each abstract error. An abstract error is specified by means of the ABSTRACTERROR macro. Its definition is identical to that of the ERROR macro of Remote Operations, specified in Recommendation X.219. .I.ma:ABSTRACTERROR; MACRO ::= ERROR An abstract service comprises the zero or more abstract errors reported by its abstract operations. Note The equivalence of ABSTRACTERROR and ERROR helps make trivial the ROS realization of an abstract service; see clause 10.1. Section Three Abstract Service Realizations 9.Overview Once a distributed information processing task has been described and specified in abstract terms, the manner in which each aspect of the task is to be concretely realized must be prescribed. As suggested previously, each aspect may admit of several concrete realizations. This section specifies principles for concretely realizing abstract models and services. A .I.gl:real; x is the computer process or system, or the real open system that concretely realizes an abstract object of type x. This section covers the following topics: a)OSI realizations b)Proprietary realizations Note The aspects of an abstract model stressed here are abstract ports and their F- bindings. This is because abstract ports mark the boundary not only between abstract objects but also between the physical systems that concretely realize those abstract objects. Thus abstract ports and bindings are the parts of an abstract model that must be constructed or constructable with OSI tools if open systems interworking is to occur. 10.OSI Realizations A primary objective of CCITT Recommendations and ISO Standards is to specify how distributed information processing tasks are realized when carried out by several cooperating real open systems. In the OSI environment, objects are realized by means of application processes, with, in general, a manytomany mapping of objects to application processes. Communication among objects which are realized by application processes in different open systems is accomplished by OSI application protocols (consisting of application contexts). An application context thus realizes the binding, use, and unbinding of a number of port pairs. The specification of an application context is in terms of the coordinated operation of a number of applicationserviceelements. Realization is therefore particularly straightforward to specify if an applicationserviceelement is defined to correspond to each port whose communication is to be supported. The realization of abstract ports and bindings by means of ASEs and ACs is discussed below. Both ROS and nonROS realizations are considered. 10.1ROS Realizations The concrete realization of ports and bindings is often trivial when accomplished by means of Remote Operations. This is true because it is straightforward to define an abstract service which is such that there exists a ROSbased application protocol that is functionally identical to it. This is true in turn because the framework for the specification of abstract services is isomorphic to that for the specification of ROSbased application protocols. The correspondences behind the isomorphism are listed in Table 1/X.407. Table .T.:1/X.407 Correspondences of Abstract Services and ROSbased Protocols +++ | Aspect of | Aspect of | | Abstract Service | ROSbased Protocol | +++ | Abstract bind operation | Bind operation | | Abstract unbind operation | Unbind operation | | Abstract operation | Operation | | Abstract error | Error | +++ The correspondences of the table arise from the fact that corresponding aspects are formally specified using closelyrelated, or equivalent macros, as summarized in Table 2/X.407: Table .T.:2/X.407 Equivalent Abstract Service and ROS Macros +++ | Abstract Service Macro | ROS Macro | +++ | ABSTRACTBIND | BIND | | ABSTRACTUNBIND | UNBIND | | ABSTRACTOPERATION | OPERATION | | ABSTRACTERROR | ERROR | +++ The definition of ROSbased ASEs and ACs that concretely realize abstract ports is explored in annex A by means of an example. For the realization to be trivial, it is necessary that there be an abstract bind operation which binds all of the ports which must be paired. Note Where there is more than one port (pair) involved in the abstract service, this requires that the abstract bind operation be designed for the particular ports involved. There is (currently) no provision for the automatic synthesis of a suitable abstract bind based, e.g., upon the definitions of abstract bind operations defined for the individual ports. 10.2NonROS Realizations The concrete realization of ports and bindings is a more substantial task when attempted by means other than Remote Operations, and little can be said about the general proposition. Despite the above, the following two observations are relevant: a)The concrete realization of an abstract service as an application protocol is greatly simplified by using ASN.1 to define its APDUs. This is so because the protocol specification can simply import relevant types and values from the abstract F-  service specification. b)The concrete realization of an abstract service whose abstract operations do not report their outcomes is conceptually simple. This is so because each such abstract operation represents an interaction comprising a single APDU. From this simplest of all possible interactions, arbitrarily complex ones can be constructed. 11.Proprietary Realizations A secondary objective of CCITT Recommendations and ISO Standards is to ensure that those portions of a distributed information processing task that are carried out by proprietary means are accomplished in such a way that the intended overall functionality of the system is upheld. The realization of abstract ports and bindings by proprietary means is briefly discussed below. Both distributed and nondistributed realizations are considered. 11.1Distributed Realizations The concrete realization of ports and bindings by means of proprietary computer communication protocols is a local matter. The specification of the visible functionality embodied in the abstract service provides a guide to the implementors of the proprietary realizations, so that, where such realizations are appropriate, they may play the appropriate role in the overall task. 11.2Nondistributed Realizations The concrete realization of ports and bindings by means of mechanisms wholly within a single computer is a local matter. As with the case considered in clause 11.1, the abstract service specification serves as a guide to the implementor in ensuring that the proprietary realization can nonetheless play the appropriate role in the overall task. Annexes Annex A (to Recommendation X.407) Example of Use of Abstract Service Notation This annex is not a part of this Recommendation. This annex illustrates the use of the abstract model and service notation by means of an example. The example involves two systems, the Yellow and Green Systems, and their environments, the Yellow and Green Environments. It uses the abstract model notation to describe the environments separately (clauses A.2 and A.4) and to show how their systems are related: one is constructed from the other (clause A.6). It uses the abstract service notation to describe the capabilities of each system (clause A.3 and A.5). The example concludes by realizing the systems' ports as ACs and ASEs using the ROS notation of Recommendation X.219, as might be appropriate for OSI communication (clause A.7 and A.8). A.1Assignment of Object Identifiers The ASN.1 modules defined in this annex require the assignment of a variety of Object Identifiers. All are defined below using ASN.1. The assignments are definitive except for those for ASN.1 modules and the subject of application service definition conventions itself. The definitive assignments for the former occur in the modules themselves; other references to them appear in IMPORT clauses. The latter is fixed. ExampleObjectIdentifiers {jointisoccitt *1mhs(6) asdc(2) example(1) modules(0) objectidentifiers(0)} DEFINITIONS IMPLICIT TAGS ::= BEGIN Prologue Exports everything. IMPORTS nothing ; ID ::= OBJECT IDENTIFIER Abstract Service Definition Conventions Example (not definitive) idasdcex ID ::= {jointisoccitt mhs(6) asdc(2) example(1)} not definitive Categories idmod ID ::= {idasdcex 0} modules; not definitive idot ID ::= {idasdcex 1} object types idpt ID ::= {idasdcex 2} port types idref ID ::= {idasdcex 3} refinements idac ID ::= {idasdcex 4} application contexts idase ID ::= {idasdcex 5} application service elements idas ID ::= {idasdcex 6} abstract syntaxes Modules idmodobjectidentifiers ID ::= {idmod 0} not definitive idmodyerefinement ID ::= {idmod 1} not definitive idmodyabstractservice ID ::= {idmod 2} not definitive idmodgerefinement ID ::= {idmod 3} not definitive idmodgabstractservice ID ::= {idmod 4} not definitive idmodysrefinement ID ::= {idmod 5} not definitive idmodysrealization ID ::= {idmod 6} not definitive idmodgsrealization ID ::= {idmod 7} not definitive Object types idotyenvironment ID ::= {idot 0} idotyuser ID ::= {idot 1} idotysystem ID ::= {idot 2} idotg F- ԫenvironment ID ::= {idot 3} idotguser ID ::= {idot 4} idotgmanager ID ::= {idot 5} idotgsystem ID ::= {idot 6} idotagent ID ::= {idot 7} Port types idptyuse ID ::= {idpt 0} idptguse ID ::= {idpt 1} idptgmanagement ID ::= {idpt 2} Refinements idrefyenvironment ID ::= {idref 0} idrefgenvironment ID ::= {idref 1} idrefysystem ID ::= {idref 2} Application contexts idacyuse ID ::= {idac 0} idacguse ID ::= {idac 1} idacgmanagement ID ::= {idac 2} Application service elements idaseyuse ID ::= {idase 0} idaseguse ID ::= {idase 1} idasegmanagement ID ::= {idase 2} Abstract syntaxes idasyuse ID ::= {idas 0} idasguse ID ::= {idas 1} idasgmanagement ID ::= {idas 2} END of ExampleObjectIdentifiers A.2Refinement of Yellow Environment The Yellow Environment, depicted in Figure 1/X.407, is formally refined below using the OBJECT and REFINE macros. ++ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | ++ Figure .F.:1/X.407 The Yellow Environment As the figure indicates and the ASN.1 specification below confirms, the Yellow Environment can be modeled as an object which can be decomposed into one central object, the Yellow System, and any number of other, peripheral objects, yellow users. The Yellow System interacts with yellow users by means of its yellowuse ports. YellowEnvironmentRefinement {jointisoccitt -1mhs(6) asdc(2) example(1) modules(0) yerefinement(1)} DEFINITIONS IMPLICIT TAGS ::= BEGIN Prologue EXPORTS yellowenvironment, yellowenvironmentrefinement, yellowsystem, yellowuser; IMPORTS %1 Yellow Abstract Service L"JJ"Jyellowuse  @  FROM YellowAbstractService {jointisoccitt I!Fmhs(6) asdc(2) example(1) modules(0) yabstractservice(2)} 52 Example Object Identifiers P$NN$Nidotyenvironment, idotysystem, idotyuser, idrefyenvironment @ 1 FROM ExampleObjectIdentifiers {jointisoccitt *1mhs(6) asdc(2) example(1) modules(0) objectidentifiers(0)} "1 Abstract Service Notation N#LL#LOBJECT, REFINE @  FROM AbstractServiceNotation {jointisoccitt K!Hmhs(6) asdc(2) modules(0) notation(1)}; Yellow Environment yellowenvironment OBJECT ::= idotyenvironment Yellow Environment refinement yellowenvironmentrefinement REFINE yellowenvironment AS yellowuser RECURRING  X yellowsystem @ 1yellowuse [S] PAIRED WITH {yellowuser} ::= idrefyenvironment Component object types yellowuser OBJECT PORTS { yellowuse [C]} @ ::= idotyuser yellowsystem OBJECT PORTS { yellowuse [S]} WN'S::= idotysystem END of YellowEnvironmentRefinement A.3Definition of Yellow Abstract Service The abstract service that the Yellow System provides to its users is formally defined below using the PORT and ABSTRACTBIND, OPERATION, and ERROR macros. As the ASN.1 specification indicates, the abstract service that the Yellow System provides comprises ports of a single kind, yellowuse. Each port comprises a number of abstract operations which collectively report a number of abstract errors. The Yellow System guards its ports by means of an abstract bind operation, YellowBind, which demands that users identify themselves convincingly before further interaction occurs. An abstract unbind operation, YellowUnbind, which constitutes the finalization step required to conclude an interaction. YellowAbstractService {jointisoccitt '1mhs(6) asdc(2) example(1) modules(0) yabstractservice(2)} DEFINITIONS IMPLICIT TAGS ::= BEGIN Prologue EXPORTS Q$LAuthenticateUser, Yellowoperation1, ... yellowuse; IMPORTS ?; Example Object Identifiers idptyuse FROM ExampleObjectIdentifiers {jointisoccitt L!Hmhs(6) asdc(2) example(1) modules(0) objectidentifiers(0)} 52 Abstract Service Notation O$MM$MABSTRACTBIND, ABSTRACTERROR, ABSTRACTOPERATION, PORT FROM AbstractServiceNotation {jointisoccitt @ mhs(6) asdc(2) modules(0) notation(1)}; Port type yellowuse PORT  CONSUMER INVOKES { Yellowoperation1, ...} 885::= idptyuse Abstract F-  bind operation Credentials ::= SET { &1name [0] IA5String, I!Gpassword [1] IA5String} YellowBind ::= ABSTRACTBIND )1TO {yellowuse[S]} BIND ARGUMENT credentials Credentials !1 BINDERROR ENUMERATED { Mp#KKp#K nameorpasswordinvalid(0)} Abstract unbind operation YellowUnbind ::= ABSTRACTUNBIND FROM {yellowuse[S]} Abstract operations Yellowoperation1 ::= ABSTRACTOPERATION ARGUMENT ... RESULT ... +1ERRORS { :999yellowerror1, ...} ... Abstract errors yellowerror1 ABSTRACTERROR 11PARAMETER ... ::= 1 ... END of YellowAbstractService A.4Refinement of Green Environment The Green Environment, depicted in Figure 2/X.407, is formally refined below using the OBJECT and REFINE macros. ++ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | ++ Figure .F.:2/X.407 The Green Environment As the figure indicates and the ASN.1 specification below confirms, the Green Environment can be modeled as an object which can be decomposed into one central object, the Green System; any number of other, peripheral objects, green users; and any number of yet additional objects, green managers. The Green System interacts with green users and managers by means of its greenuse ports, and with green managers (alone) by means of its greenmanagement ports. GreenEnvironmentRefinement {jointisoccitt ,1mhs(6) asdc(2) example(1) modules(0) gerefinement(3)} DEFINITIONS IMPLICIT TAGS ::= BEGIN Prologue EXPORTS L!Hgreenenvironment, greenenvironmentrefinement, greenmanager, greensystem, greenuser; IMPORTS  Green Abstract Service "111greenuse, greenmanagement Mp#K FROM GreenAbstractService {jointisoccitt &1mhs(6) asdc(2) example(1) modules(0) gabstractservice(4)} @  Example Object Identifiers 6444idotgenvironment, idotgmanager, idrefgenvironment 111idotguser, idotgsystem,  FROM ExampleObjectIdentifiers {jointisoccitt @=mhs(6) asdc(2) example(1) modules(0) objectidentifiers(0)} -1 Abstract Service Notation N#LL#LOBJECT, REFINE  FROM AbstractServiceNotation {jointisoccitt ;v8mhs(6) asdc(2) modules(0) notation(1)}; Green Environment greenenvironment OBJECT ::= idotgenvironment Green Environment refinement greenenvironmentrefinement REFINE greenenvironment AS W&Rgreenuser RECURRING @ greenmanager RECURRING 01greensystem greenuse [S] PAIRED WITH {greenuser, greenmanager} greenmanagement [S] PAIRED WITH {greenmanager} Y'T::= idrefgenvironment Component object types greenuser OBJECT PORTS { greenuse [C]} ::= idotguser greenmanager OBJECT PORTS { greenuse [C], Mz"IIz"Igreenmanagement [C]} ::= idotgmanager greensystem OBJECT )1PORTS { greenuse [S], OT$MMT$Mgreenmanagement [S]} @ ::= idotgsystem END of GreenEnvironmentRefinement A.5Definition of Green Abstract Service The abstract service that the Green System provides to its users and managers is formally defined below using the PORT and ABSTRACTBIND, OPERATION, and ERROR macros. As the ASN.1 specification indicates, the abstract service that the Green System provides comprises ports of two kinds, greenuse and greenmanagement. A port of either kind comprises a number of abstract operations which collectively report a number of abstract errors. The Green System guards its ports by means of abstract bind operations, AuthenticateUser and AuthenticateManager, which demand that users and managers identify themselves convincingly before further interaction can occur. No abstract unbind operations are specified, indicating that no finalization step is required to conclude an interaction. GreenAbstractService {jointisoccitt &1mhs(6) asdc(2) example(1) modules(0) gabstractservice(4)} DEFINITIONS IMPLICIT TAGS ::= BEGIN Prologue EXPORTS Q$LAuthenticateManager, AuthenticateUser, greenmanagement, 9b6Greenmanagementoperation1, ... greenuse, Greenuseoperation1, ...; IMPORTS 4(1 Example Object Identifiers O$MM$Midptguse, idptgmanagement FROM ExampleObjectIdentifiers {jointisoccitt N"Jmhs(6) asdc(2) example(1) modules(0) objectidentifiers(0)} 52 Abstract Service Notation O$MM$MPORT, ABSTRACTBIND, ABSTRACTOPERATION, ABSTRACTERROR FROM AbstractServiceNotation {jointisoccitt @ mhs(6) asdc(2) modules(0) notation(1)}; Port types greenuse PORT  CONSUMER INVOKES { Greenuseoperation1, ...} ;8::= idptguse green F- ԫmanagement PORT CONSUMER INVOKES { #111greenmanagementoperation1, ...} ::= idptgmanagement Abstract bind operations Credentials ::= SET { name [0] IA5String,  password [1] IA5String} AuthenticateUser ::= ABSTRACTBIND HX EARGUMENT credentials Credentials @ BINDERROR ENUMERATED { 0111nameorpasswordinvalid(0)} AuthenticateManager ::= ABSTRACTBIND ARGUMENT credentials Credentials GCBINDERROR ENUMERATED { @ 1nameorpasswordinvalid(0), N#Lnotamanager (1)} Abstract operations Greenuseoperation1 ::= ABSTRACTOPERATION ARGUMENT ... @ RESULT ... #1ERRORS { :9greenerror1, ...} ... Greenmanagementoperation1 ::= ABSTRACTOPERATION 4(1ARGUMENT ... RESULT ... I!HERRORS { Q%PP%Pgreenerror1, ...} ... Abstract errors greenerror1 ABSTRACTERROR J FPARAMETER ... ::= 1 ... END of GreenAbstractService A.6Refinement of Yellow System The Yellow System, depicted in Figure 3/X.407, is formally refined below using the OBJECT and REFINE macros. ++ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | ++ Figure .F.:3/X.407 The Yellow System As the figure indicates and the ASN.1 specification confirms, the Yellow System, when examined closely, has components. In particular, the Yellow System comprises the Green System and green managers, augmented by objects of an as yet unseen variety, agent. An agent serves as an intermediary between the Green System and a yellow user. It might be thought of as adding value to the Green System. In any case, it is a provider of a yellowuse port and a consumer of a greenuse port. YellowSystemRefinement {jointisoccitt (1mhs(6) asdc(2) example(1) modules(0) ysrefinement(5)} DEFINITIONS IMPLICIT TAGS ::= BEGIN Prologue EXPORTS L!Hagent, yellowsystemrefinement; IMPORTS Yellow Environment Refinement DH@@H@yellowsystem, yellowuse  @  1FROM YellowEnvironmentRefinement {jointisoccitt @ mhs(6) asdc(2) example(1) modules(0) yerefinement(1)} O#L Green Environment Refinement @ 1greenmanagement, greenmanager, greensystem, greenuse @ 1 625FROM GreenEnvironmentRefinement {jointisoccitt @ mhs(6) asdc(2) example(1) modules(0) gerefinement(3)} O#L Example Object Identifiers 111idotagent, idrefysystem N#L FROM ExampleObjectIdentifiers {jointisoccitt /1mhs(6) asdc(2) example(1) modules(0) objectidentifiers(0)} @  Abstract Service Notation 5*3OBJECT, REFINE BAAAFROM AbstractServiceNotation {jointisoccitt )1mhs(6) asdc(2) modules(0) notation(1)}; Yellow System refinement yellowsystemrefinement REFINE yellowsystem AS agent RECURRING @ yellowuse [S] VISIBLE 5*3greenmanager RECURRING K"Jgreensystem greenuse [S] PAIRED WITH {agent, greenmanager} ?;greenmanagement [S] PAIRED WITH {greenmanager} 1::= idrefysystem Component object type agent OBJECT 1PORTS { 9888yellowuse [S], greenuse [C]} ::= idotagent END of YellowSystemRefinement A.7Realization of Yellow System The abstract service of the Yellow System is formally realized below, by means of ROS, using the APPLICATIONCONTEXT and APPLICATIONSERVICEELEMENT macros of Recommendation X.219. As the ASN.1 specification indicates, the abstract service that the Yellow System provides is realized as a single ASE, yellowuseASE, and a single and corresponding AC, yellowuseAC. Each abstract bind operation, abstract operation, or abstract error in the abstract service has a corresponding and equivalent bind operation, operation, or error, respectively, in its ROSbased realization. Note that Integer values are assigned to the operations; the corresponding abstract operations require and received no such values. YellowSystemRealization {jointisoccitt )1mhs(6) asdc(2) example(1) modules(0) ysrealization(6)} DEFINITIONS IMPLICIT TAGS ::= BEGIN Prologue EXPORTS MJ"IyellowuseAC, yellowuseASE; IMPORTS Yellow Abstract Service 8555Yellowoperation1, ... yellowuse, YellowBind, @ 1YellowUnbind FROM YellowAbstractService {jointisoccitt '1mhs(6) asdc(2) example(1) modules(0) yabstractservice(2)} @  Example Object Identifiers 6444idacyuse, idasyuse, idaseyuse FROM ExampleObjectIdentifiers {jointisoccitt :7mhs(6) asdc(2) example(1) F-  modules(0) objectidentifiers(0)} "1 Remote Operations APDUs L"JJ"JrOSE O8%OO8%O FROM RemoteOperationsAPDUs {jointisoccitt .1remoteoperations(4) apdus(1)} P$N Association Control @ aCSE, aCSEAS FROM AssociationControl {jointisoccitt T%Qacse(2) .I.bs:Module imports;to be supplied} -1 Remote Operations Notation Extension APPLICATIONCONTEXT, APPLICATIONSERVICEELEMENT ;F8 FROM RemoteOperationsNotationextension {jointisoccitt $1remoteoperations(4) notationextension(2)}; Application context yellowuseAC APPLICATIONCONTEXT J FAPPLICATION SERVICE ELEMENTS {aCSE} BIND YellowBind UNBIND YellowUnbind @ REMOTE OPERATIONS {rOSE} 11INITIATOR CONSUMER OF {yellowuseASE} ABSTRACT SYNTAXES {yellowuseAS, aCSEAS} ::= idacyuse Application service element yellowuseASE APPLICATIONSERVICEELEMENT <9CONSUMER INVOKES { L.#Kyellowoperation1, ...} @ ::= idaseyuse yellowoperation1 Yellowoperation1 ::= 1 ... Abstract syntax yellowuseAS OBJECT IDENTIFIER ::= idasyuse END of YellowSystemRealization A.8Realization of Green System The abstract service of the Green System is formally realized below, by means of ROS, using the APPLICATIONCONTEXT and APPLICATIONSERVICEELEMENT macros of Recommendation X.219. As the ASN.1 specification indicates, the abstract service that the Green System provides is realized as two ASEs, greenuseASE and greenmanagementASE, and two, corresponding ACs, greenuseAC and greenmanagementAC. Each abstract bind operation, abstract operation, or abstract error in the abstract service has a corresponding and equivalent bind operation, operation, or error, respectively, in its ROSbased realization. Note that Integer values are assigned to the operations; the corresponding abstract operations require and received no such values. GreenSystemRealization {jointisoccitt (1mhs(6) asdc(2) example(1) modules(0) gsrealization(7)} DEFINITIONS IMPLICIT TAGS ::= BEGIN Prologue EXPORTS MJ"IgreenmanagementAC, greenmanagementASE, greenuseAC, 31greenuseASE; IMPORTS I!G Green Abstract Service @ 1AuthenticateManager, AuthenticateUser, @ greenmanagement, Greenmanagementoperation1, ... Lh"Igreenuse, Greenuseoperation1, ... 111 FROM GreenAbstractService {jointisoccitt @ mhs(6) asdc(2) example(1) modules(0) gabstractservice(4)} T%Q Example Object Identifiers 111idacguse, idaseguse, idasguse, @ 1idacgmanagement, idasegmanagement, idasgmanagement 111 FROM ExampleObjectIdentifiers {jointisoccitt @ mhs(6) asdc(2) example(1) modules(0) objectidentifiers(0)} T%Q Remote Operations APDUs @ 1rOSE 625525 FROM RemoteOperationsAPDUs {jointisoccitt @ remoteoperations(4) apdus(1)} 75 Association Control LL#KaCSE, aCSEAS FROM AssociationControl {jointisoccitt 6 3acse(2) .I.bs:Module imports;to be supplied}  Remote Operations Notation Extension APPLICATIONCONTEXT, APPLICATIONSERVICEELEMENT @  FROM RemoteOperationsNotationextension {jointisoccitt X'Tremoteoperations(4) notationextension(2)}; Application contexts greenuseAC APPLICATIONCONTEXT @ APPLICATION SERVICE ELEMENTS {aCSE} BIND AuthenticateUser R%OUNBIND NoOperation  REMOTE OPERATIONS {rOSE} %1INITIATOR CONSUMER OF {greenuseASE} ABSTRACT SYNTAXES {greenuseAS, aCSEAS} .1::= idacguse greenmanagementAC APPLICATIONCONTEXT @ APPLICATION SERVICE ELEMENTS {aCSE} BIND AuthenticateManager Uj&QUNBIND NoOperation @ REMOTE OPERATIONS {rOSE} 11INITIATOR CONSUMER OF {greenmanagementASE} @ ABSTRACT SYNTAXES {greenmanagementAS, aCSEAS} I!F::= idacgmanagement NoOperation ::= UNBIND Application service elements greenuseASE APPLICATIONSERVICEELEMENT 1CONSUMER INVOKES { greenuseoperation1, ...} @ ::= idaseguse greenmanagementASE APPLICATIONSERVICEELEMENT CONSUMER INVOKES { 1 greenmanagementoperation1, ...} U'S::= idasegmanagement greenuseoperation1 Greenuseoperation1 ::= 1 ... greenmanagementoperation1 Greenmanagementoperation1 ::= 50 ... Abstract syntaxes greenuseAS OBJECT IDENTIFIER ::= idasguse greenmanagementAS OBJECT IDENTIFIER ::= idasgmanagement END of GreenSystemRealization Annex B (to Recommendation X.407) Reference Definition of Object Identifiers This annex is an integral part of this Recommendation. This annex defines for reference purposes various Object Identifiers cited in the ASN.1 modules of annex C. It uses ASN.1. F-ԌWith the exception of those assigned in annex A, all Object Identifiers this Recommendation assigns are assigned in this annex. The annex is definitive for all but those for ASN.1 modules and the subject of application service definition conventions itself. The definitive assignments for the former occur in the modules themselves; other references to them appear in IMPORT clauses. The latter is fixed. .I.mo:ASDCObjectIdentifiers; {jointisoccitt .1mhs(6) asdc(2) modules(0) objectidentifiers(0)} DEFINITIONS IMPLICIT TAGS ::= BEGIN Prologue Exports everything. IMPORTS nothing ; .I.ty:ID; ::= OBJECT IDENTIFIER Abstract Service Definition Conventions (not definitive) .I.va:idasdc; ID ::= {jointisoccitt mhs(6) asdc(2)} not definitive Categories .I.va:idmod; ID ::= {idasdc 0} modules; not definitive .I.va:idex; ID ::= {idasdc 1} example; not definitive Modules .I.va:idmodobjectidentifiers; ID ::= {idmod 0} not definitive .I.va:idmodnotation; ID ::= {idmod 1} not definitive END of ASDCObjectIdentifiers Annex C (to Recommendation X.407) Reference Definition of Notation This annex is an integral part of this Recommendation. This annex, a supplement to section two, defines for reference purposes the notation for specifying abstract models and services. It employs ASN.1. .I.mo:AbstractServiceNotation; {jointisoccitt 01mhs(6) asdc(2) modules(0) notation(1)} DEFINITIONS IMPLICIT TAGS ::= BEGIN Prologue EXPORTS GCABSTRACTBIND, ABSTRACTERROR, ABSTRACTOPERATION, ABSTRACTUNBIND, OBJECT, PORT, REFINE; IMPORTS Th%O Remote Operations Notation 111BIND, ERROR, OPERATION, UNBIND P$N FROM RemoteOperationNotation {jointisoccitt 01remoteoperations(4) notation(0)}; Object macro .I.ma:OBJECT; MACRO ::= BEGIN TYPE NOTATION ::= "PORTS" "{" PortList "}" | empty VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) PortList ::= Port "," PortList | Port Port ::= value (PORT) PortType PortType ::= Symmetric | Asymmetric Symmetric ::= empty Asymmetric ::= Consumer | Supplier Consumer ::= "[C]" Supplier ::= "[S]" END Port macro .I.ma:PORT; MACRO ::= BEGIN TYPE NOTATION ::= Operations | empty VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) Operations ::= Symmetrical | Asymmetrical Symmetrical ::= "ABSTRACT" "OPERATIONS" "{" OperationList "}" Asymmetrical ::= OneSided | TwoSided OneSided ::= Consumer | Supplier TwoSided ::= Consumer Supplier | Supplier Consumer Consumer ::= "CONSUMER" "INVOKES" "{" OperationList "}" Supplier ::= "SUPPLIER" "INVOKES" "{" OperationList "}" OperationList ::= Operation "," OperationList | Operation Operation ::= value (ABSTRACTOPERATION) END Refine macro .I.ma:REFINE; MACRO ::= BEGIN TYPE NOTATION ::= Object "AS" ComponentList VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) ComponentList ::= Component ComponentList | Component Component ::= ObjectSpec PortSpecList ObjectSpec ::= Object | Object "RECURRING" PortSpecList ::= PortSpec PortSpecList | PortSpec PortSpec ::= value (PORT) PortType PortStatus PortType ::= Consumer | Supplier | empty Consumer ::= "[C]" Supplier ::= "[S]" PortStatus ::= "VISIBLE" | "PAIRED" "WITH" ObjectList ObjectList ::= Object "," ObjectList | Object Object ::= value (OBJECT) END Abstract bind, unbind, operation, and error macros .I.ma:ABSTRACTBIND; MACRO ::= BEGIN TYPE NOTATION ::= Ports Bind VALUE NOTATION ::= value (VALUE BindType) Ports ::= "TO" "{" PortList "}" | empty PortList ::= Port "," PortList | Port Port ::= value (PORT) PortSide PortSide ::= Consumer | Supplier | empty Consumer ::= "[C]" Supplier ::= "[S]" Bind ::= type (BindType) must be a BIND type | empty END .I.ma:ABSTRACTUNBIND; MACRO ::= BEGIN TYPE NOTATION ::= Ports Unbind VALUE NOTATION ::= value (VALUE UnbindType) Ports ::= "FROM" "{" PortList "}" | empty PortList ::= Port "," PortList | Port Port ::= value (PORT) PortSide PortSide ::= Consumer | Supplier | empty Consumer ::= "[C]" Supplier ::= "[S]" Unbind ::= type (UnbindType) must be an UNBIND type | empty END .I.ma:ABSTRACTOPERATION; MACRO ::= OPERATION .I.ma:ABSTRACTERROR; MACRO ::= ERROR END of AbstractServiceNotation Annex D (to Recommendation X.407) Differences Between CCITT Recommendation and ISO Standard This annex is not a part of this Recommendation. This annex lists all but the purely stylistic differences between this Recommendation and F- the corresponding ISO International Standard. No differences between the two specifications exist. CCITT Draft Recommendation X.407 MHS: Abstract Service Definition Conventions (Version 5, November 1987, Gloucester) Annex E (to Recommendation X.407) Index This annex indexes this Recommendation. It gives the number(s) of the page(s) on which each item in each of several categories is defined. Its coverage of each category is exhaustive. This annex indexes items (if any) in the following categories: a)Abbreviations (ab) b)Terms (gt) c)Information items (ot) d)ASN.1 modules (mo) e)ASN.1 macros (ma) f)ASN.1 types (ty) g)ASN.1 values (va) h)Bilateral agreements (ba) i)Items for further study (fs) j)Items to be supplied (fs) .Begin Index. Abbreviations AC 2 APDU 1 ASE 2 ASN.1 2 OSI 2 ROS 2 Terms abstract bind operation 8 abstract error 10 abstract model 4 abstract object 4 abstract operation 9 abstract port 5 abstract procedure 7 abstract refinement 6 abstract service 6 abstract service provider 6 abstract service user 6 abstract unbind operation 8 argument 7 asymmetric 5 binding 5 bound 5 consumer 5 error information 8 initiator 8 invocation 7 invoker 7 match 5 model 4 object 4 parameter 10 performance 7 performer 7 port 5 procedure 7 provider 6 real 11 refinement 6 F-Ԍresponder 8 result 7 supplier 5 symmetric 5 unbinding 5 user 6 Information Items None ASN.1 Modules AbstractServiceNotation 28 ASDCObjectIdentifiers 27 ASN.1 Macros ABSTRACTBIND 8, 29 ABSTRACTERROR 10, 29 ABSTRACTOPERATION 9, 29 ABSTRACTUNBIND 9, 29 OBJECT 4, 28 PORT 5, 28 REFINE 6, 29 ASN.1 Types ID 27 ASN.1 Values idasdc 27 idex 27 idmod 27 idmodnotation 27 idmodobjectidentifiers 27 Bilateral Agreements None Items for Further Study None Items to Be Supplied Module imports 24, 25 .End Index. &3vq lE 1 h= Q d#^ 4^_] l Z& % U @ & @ & @ & B B @ ! & ! ( %   v q- K l g e c S a[ @ & @ @ & @ & @ & [  y5 w r ^ mC I hL M c  ^ [ @ @ & @ & @ & @ & @ &   v / q" ( l  g! $ b ? ]I K Xf Recommendation X.407 and ISO 100213, Information processing systems. Text CommunicationMOTISAbstract Service Definition Conventions, were developed in close collaboration and are technically aligned.