_ Fascicle VIII.7 Ñ Rec. X.420 Fascicle VIII.7 Ñ Rec. X.420 _ The drawings contained in this recommendation have been done in autocad Recommendation X.420 MESSAGE HANDLING SYSTEMS: INTERPERSONAL MESSAGING SYSTEM1) (MalagaÑTorremolinos, 1984; amended at Melbourne, 1988 ) The establishment in various countries of telematic services and computerÑbased storeÑandÑforward 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) the need to transfer and store messages of different types; (c) that Recommendation X.200 defines the reference model of open systems interconnection for CCITT applications; (d) that Recommendations X.208, X.217, X.218 and X.219 provide the foundation for CCITT applications; (e) that the X.500Ñseries Recommendations define directory systems; (f) that message handling systems are defined in a series of Recommendations X.400, X.402, X.403, X.407, X.408, X.411, X.413, and X.419; (g) that interpersonal messaging is defined in Recommendations X.420 and T.330, unanimously declares (1) that the abstract information objects users exchange in interpersonal messaging are defined in Section 2; (2) that the abstract service offered to users in interpersonal messaging is defined in Section 3; (3) that how that abstract service is provided is specified in Section 4. TABLE OF CONTENTS SECTION 1 Ñ Introduction 0 Introduction 1 Scope 2 References 3 Definitions 4 Abbreviations 5 Conventions 5.1 ASN.1 5.2 Grade 5.3 Terms SECTION 2 Ñ Abstract information objects 6 Overview 7 Interpersonal messages 7.1 Heading fields component types 7.2 Heading fields 7.3 Body part types 8 Interpersonal notifications 8.1 Common fields 8.2 NonÑreceipt fields 8.3 Receipt fields SECTION 3 Ñ Abstract service definition 9 Overview 10 Primary object types 10.1 Interpersonal messaging system user 10.2 Interpersonal messaging system 11 Primary port types 11.1 Origination 11.2 Reception 11.3 Management 12 Abstract operations 12.1 Origination abstract operations 12.2 Reception abstract operations 12.3 Management abstract operations 13 Abstract errors 13.1 Subscription error 13.2 Recipient improperly specified 14 Other capabilities SECTION 4 Ñ Abstract service provision 15 Overview 16 Secondary object types 16.1 Interpersonal messaging system user agent 16.2 Interpersonal messaging system message store 16.3 Telematic agent 16.4 Telex access unit 16.5 Physical delivery access unit 16.6 Message transfer system 17 Secondary port types 17.1 Submission 17.2 Delivery 17.3 Retrieval 17.4 Administration 17.5 Import 17.6 Export 18 User agent operation 18.1 State variables 18.2 Performance of origination operations 18.3 Performance of management operations 18.4 Invocation of reception operations 18.5 Internal procedures 19 Message store operation 19.1 Creation of information objects 19.2 Maintenance of attributes 19.3 Notification of nonÑreceipt 19.4 AutoÑforwarding 20 Message contents 20.1 Content 20.2 Content type 20.3 Content length 20.4 Encoded information types 21 Port realization 22 Conformance 22.1 Originating versus reception 22.2 Statement requirements 22.3 Static requirements 22.4 Dynamic requirements Annex A Ñ Heading extensions Annex B Ñ Extended body part types Annex C Ñ Message store attributes Annex D Ñ Reference definition of object identifiers Annex E Ñ Reference definition of abstract information objects Annex F Ñ Reference definition of functional objects Annex G Ñ Reference definition of abstract service Annex H Ñ Reference definition of heading extensions Annex I Ñ Reference definition of extended body part types Annex J Ñ Reference definition of message store attributes Annex K Ñ Reference definition of upper bounds Annex L Ñ Support of the interpersonal messaging service Annex M Ñ Differences between CCITT Recommendation and ISO Standard Annex N Ñ Summary of changes to 1984 specification SECTION 1 Ñ 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 cooperation open systems. The purpose of an MHS is to enable users to exchange messages on a storeÑandÑforward basis. A message submitted on behalf of one user, the originator, is conveyed by the message transfer system (MTS) and subsequently delivered to the agents of one or more additional users, the recipients. Access units (AUs) link the MTS to communication systems of other kinds (e.g., postal systems). A user is assisted in the preparation, storage, and display of messages by a user agen (UA). Optionally, it is assisted in the storage of messages by a message store (MS). The MTS comprises a number of message transfer agents (MTAs) which collectively perform the storeÑandÑforward message transfer function. This Recommendation defines the message handling application called interpersonal messaging, specifying in the process the message content type and associated procedures known as P2. The text of this Recommendation is the subject of joint CCITTÑISO agreement. The corresponding ISO/IEC specification is ISO 10021Ñ7. 1 Scope This Recommendation defines interpersonal messaging, a form of message handling tailored for ordinary interpersonal business or private correspondence. This Recommendation is one of a series on message handling. Recommendation X.402 constitutes the introduction to the series and identifies the other documents in it. The architectural basis and foundation for message handling are defined in still other Recommendations. Recommendation X.402 identifies those documents as well. This Recommendation is structured as follows. Section 1 is this introduction. Section 2 defines the kinds of information objects exchanged in interpersonal messaging. Section 3 defines de associated abstract service. Section 4 specifies how it is provided. Annexes provide important supplemental information. The requirements for conformance to this Recommendation are given in ¤ 22. 2 References This Recommendation cites Recommendation X.402, many of the documents it cites, and those below. ISO Standard 639.2 Code for the representation of names of languages. Recommendation T.4 Standardization of Group 3 facsimile apparatus for document transmission. Recommendation T.30 Procedures for document facsimile transmission in the general switched telephone network. Recommendation T.100 International information exchange for interactive videotex. Recommendation T.101 International interworking for videotex services. Recommendation T.330 Telematic access to IPMS. Recommendation X.420 (1984) Message handling systems: Interpersonal messaging user agent layer. X.400Ñseries implementor's guide, Version 6, 6 November 1987. 3 Definitions For the purposes of this Recommendation, the definitions of Recommendation X.402 apply. 4 Abbreviations For the purposes of this Recommendation, the abbreviations of Recommendation X.402 apply. 5 Conventions This Recommendation uses the descriptive conventions identified below. 5.1 ASN.1 This Recommendation uses for the indicated purposes the following ASN.1Ñbased descriptive conventions: a)to define the information objects of interpersonal messaging, and other data types and values of all kinds, ASN.1 itself; b)to define the functional objects of interpersonal messaging, the OBJECT and REFINE macros of Recommendation X.407; c)to define the abstract service of interpersonal messaging, the PORT and ABSTRACTÑOPERATION and ÑERROR macros of Recommendation X.407; d)to define the heading extensions, the HEADINGÑEXTENSION macro of ¤ 7.2.17; e)to define extended body part types, the EXTENDEDÑBODYÑPARTÑTYPE macro of ¤ 7.3.12; f)to define MS attributes, the ATTRIBUTE macro of Recommendation X.500. The various uses of the ASN.1 notation are summarized in Table 1/X.420. With the two exceptions evident from the table, whenever ASN.1 is employed, it appears both in the body of the Recommendation to aid the exposition, and again, largely redundantly, in an Annex for reference. TABLE 1/X.420 Uses of the ASN.1 notation Subject matter Reference Exposition Object identifiers Ñ Annex D Abstract information Section 2 Annex E objects Functional objects ¤¤ 10, Annex F 11, 16 Abstract service ¤¤ 12Ñ13 Annex G Heading extensions Annex A Annex H Extended body part Annex B Annex I types Message store Annex C Annex J attributes Upper bounds Ñ Annex K If differences are found between the ASN.1 used in the exposition and that supplied for reference, a specification error is indicated. Note that ASN.1 tags are implicit throughout the ASN.1 module the Annex defines; the module is definitive in that respect. Note 1 Ñ The use of ASN.1 to describe a class or piece of information does not in itself imply that that information is transported between open systems. The fact that the information, by virtue of its description in ASN.1 and of ASN.1's basic encoding rules, has a concrete transfer syntax may be immaterial. Information actually conveyed between systems is designated as such by its inclusion in an application protocol. Note 2 Ñ The use of the ABSTRACTÑOPERATION and ÑERROR macros, derived from the correspondingly named macros of remote operations, does not imply that the abstract operations and errors are invoked and reported across the boundary between open systems. The fact that the abstract operations and errors, by virtue of their description using these macros and with minimal additional specification, actually could be invoked via ROS is immaterial in the present context. 5.2 Grade This Recommendation uses the concept of grade as developed in Recommendation X.402. 5.3 Terms 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 2 Ñ ABSTRACT INFORMATION OBJECTS 6 Overview This section abstractly describes the information objects that users exchange in interpersonal messaging. They are of two kinds, interpersonal messages (IPMs) and interpersonal notifications (IPNs). One of the latter acknowledges a user's receipt of one of the former. InformationObject ::= CHOICE { ipm [0] IPM, ipn [1] IPN } This section covers the following topics: a)interpersonal messages; b)interpersonal notifications. Note 1 Ñ The use, throughout this section, of words such as ÒoriginatorÓ and ÒrecipientÓ anticipates the fact that IPMs and IPNs are conveyed between users as the contents of messages (see ¤ 20). These words, therefore, refer to the roles users and DLs play in such transmittals. Note 2 Ñ An IPM may appear (see ¤ 7.3.8) in the body of another IPM which itself is conveyed as the content of a message. The words ÒoriginatorÓ and ÒrecipientÓ shall be understood in the context of an IPM's conveyance as the (entire) content of a message, not as a component of the body of another IPM so conveyed. Note 3 Ñ An IPM or IPN makes various assertions about its own transmittal (e.g., who originates the message containing it). Furthermore, an IPN makes assertions about the transmittal of the IPM to which it responds. All of these assertions are unverified. 7 Interpersonal messages An interpersonal message (IPM) is a member of the primary class of information object conveyed between users in interpersonal messaging. IPM ::= SEQUENCE { headingHeading, body Body } It has the following components: a)heading: A set of heading fields (or fields), each an information item that gives a characteristic of the IPM (e.g., its importance); b)body: A sequence of body parts, each an information object that the IPM is intended to convey between users (e.g., a document). Body ::= SEQUENCE OF BodyPart The structure of an IPM is depicted in Figure 1/X.420. This paragraph defines and describes the most prominent heading field component types and the defined heading fields and body part types. Note Ñ An IPM may be likened to a business memo. In fact, the terms ÒheadingÓ and ÒbodyÓ appeal to that analogy. Fig. 1/X.420/T0705270-88 = 7 cm 7.1 Heading field component types Information items of several kinds appear throughout the heading. These heading field component types ÑÑIPM identifier, recipient specifier, and O/R descriptorÑÑ are defined and described below. 7.1.1IPM identifier An IPM identifier is an information item that unambiguously and uniquely identifies an IPM, distinguishing it from all other IPMs ever conveyed by any user. IPMIdentifier ::= [APPLICATION 11] SET { user ORAddress OPTIONAL, userÑrelativeÑidentifier LocalIPMIdentifier } An IPM identifier has the following components: a)user (O): Identifies the user who originates the IPM. One of the user's O/R addresses. This component's omission is discouraged; b)userÑrelativeÑidentifier (M): Uniquely and unambiguously identifies the IPM, distinguishing it from all other IPMs that the user who is identified by the user component originates. A printable string of from zero to a prescribed number of characters (see Annex K). A length of zero is discouraged. LocalIPMIdentifier ::= PrintableString (SIZE (0. .ubÑlocalÑipmÑidentifier)) Note Ñ The Ò11Ó in IPMIdentifier is the only ASN.1 applicationÑwide tag this Recommendation assigns. 7.1.2Recipient specifier A recipient specifier is an information item that identifies a (preferred) recipient of an IPM and that may make certain requests of him. RecipientSpecifier ::= SET { recipient [0] ORDescriptor, notificationÑrequests [1] NotificationRequests DEFAULT { }, replyÑrequested [2] BOOLEAN DEFAULT FALSE } A recipient specifier has the following components: a)recipient (M): Identifies the preferred recipient in question. An O/R descriptor. If the notificationÑrequests or replyÑrequested component makes a request of the preferred recipient, the formalÑname component of the O/R descriptor above shall be present. b)notificationÑrequests (D no values): May make certain requests of the preferred recipient denoted by the recipient component. NotificationRequests ::= BIT STRING { rn (0), nrn (1), ipmÑreturn (2) } This component may assume any of the following values simultaneously, except tha the value rn shall not be selected unless the value nrn is selected: i)rn: A receipt notification is requested in the circumstances prescribed in ¤ 8. ii) nrn: A nonÑreceipt notification is requested in the circumstances prescribed in ¤ 8. iii)ipmÑreturn: It is requested that the IPM be returned in any nonÑreceipt notification. c)replyÑrequested (D false): Indicates whether a reply is requested of the preferred recipient denoted by the recipient component. A Boolean. A reply is one IPM sent in response to another. A user may reply to an IPM even though no reply is requested of him and, indeed, even if he is not among the IPM's preferred recipients. Furthermore, a user of whom a reply is requested may refrain from replying. 7.1.3O/R descriptor An O/R descriptor is an information item that identifies a user or DL. ORDescriptor ::= SET { formalÑname ORName OPTIONAL, freeÑformÑname [0] FreeFormName OPTIONAL, telephoneÑnumber [1] TelephoneNumber OPTIONAL } An O/R descriptor has the following components: a)formalÑname (C): Identifies the user or DL in question. One of its O/R names. This conditional component shall be present if (but not only if) one or more of the following criteria are satisfied: i)The freeÑformÑname component is absent. ii) The O/R descriptor appears in the reply recipients heading field. iii)The O/R descriptor is the recipient component of a recipient specifier and the conditions stated in item 2 of ¤ 7.1.2 are satisfied. b)freeÑformÑname (O): Identifies the user or DL in question. A telex string of from zero to a prescribed number of characters (see Annex K), chosen from the graphic subset of the teletex string character set. A length of zero is discouraged. FreeFormName ::= TeletexString (SIZE (0. .ubÑfreeÑformÑname)) c)telephoneÑnumber (O): Provides the telephone number of the user or DL in question. A printable string of from zero to a prescribed number of characters (see Annex K), chosen from the graphical subset of the printable string character set. A length of zero is discouraged. TelephoneNumber ::= PrintableString (SIZE (0. .ubÑtelephoneÑnumber)) Note Ñ One or more O/R descriptors may appear in each of the following heading fields: originator, authorizing users, primary recipients, copy recipients, blind copy recipients, and reply recipients. In addition, and O/R descriptor may appear in the following notification fields (see ¤ 8): IPN originator and IPM preferred recipient. 7.2 Heading fields The fields that appear in the heading of an IPM are defined and described below. Heading ::= SET { thisÑIPM ThisIPMField, originator [0] OriginatorField OPTIONAL, authorizingÑusers [1] AuthorizingUsersField OPTIONAL, primaryÑrecipients [2] PrimaryRecipientsField DEFAULT { }, copyÑrecipients [3] CopyRecipientsField DEFAULT { }, blindÑcopyÑrecipients [4] BlindCopyRecipientsField OPTIONAL, repliedÑtoÑIPM [5] RepliedToIPMField OPTIONAL, obsoletedÑIPMs [6] ObsoletedIPMsField DEFAULT { }, relatedÑIPMs [7] RelatedIPMsField DEFAULT { }, subject [8] EXPLICIT SubjectField OPTIONAL, expiryÑtime [9] ExpiryTimeField OPTIONAL, replyÑtime [10] ReplyTimeField OPTIONAL, replyÑrecipients [11] ReplyRecipientsField OPTIONAL, importance [12] ImportanceField DEFAULT normal, sensitivity [13] SensitivityField OPTIONAL, autoÑforwarded [14] AutoForwardedField DEFAULT FALSE, extensions [15] ExtensionsField DEFAULT { } } Some fields have components and thus are composite, rather than indivisible. A field component is called a subÑfield. 7.2.1This IPM The this IPM heading field (M) identifies the IPM. It comprises an IPM identifier. ThisIPMField ::= IPMIdentifier 7.2.2Originator The originator heading field (O) identifies the IPM's originator. It comprises an O/R descriptor. OriginatorField ::= ORDescriptor 7.2.3Authorizing users The authorizing users heading field (C) identifies the zero or more users who are the IPM's authorizing users. It comprises a sequence of subÑfields, each an O/R descriptor, one for each such user. AuthorizingUsersField ::= SEQUENCE OF AuthorizingUsersSubfield AuthorizingUsersSubfield ::= ORDescriptor An authorizing user is a user who, either individually or in concert with others, authorizes the origination of an IPM. The word ÒauthorizesÓ above is not precisely defined by this Recommendation; it is given meaning by users. This conditional field shall be present if, and only if, the authorizing users are other than the IPM's originator alone. Note Ñ Suppose, for example, that a manager instructs his secretary to originate an IPM on his behalf. In this case, the secretary, the IPM's originator, might consider the manager the authorizing user. 7.2.4Primary recipients The primary recipients heading field (D not subfields i.e., elements) identifies the zero or more users and DLs who are the Òprimary recipientsÓ of the IPM. It also identifies the responses the authorizing users ask of each of those users and of each member of those DLs. It comprises a Sequence of subÑfields, each a recipient specifier, one for each primary recipient. PrimaryRecipientsField ::= SEQUENCE OF PrimaryRecipientsSubfield PrimaryRecipientsSubfield ::= RecipientSpecifier The phrase Òprimary recipientsÓ above is not precisely defined by this Recommendation; it is given meaning by users. Note Ñ The primary recipients, e.g., might be those users and those DLs whose members are expected to act upon the IPM. 7.2.5Copy recipients The copy recipients heading field (D no subfields i.e., elements) identifies the zero or more users and DLs who are the Òcopy recipientsÓ of the IPM. It also identifies the responses the authorizing users ask of each of those users and of each member of those DLs. It comprises a sequence of subÑfields, each a recipient specifier, one for each copy recipient. CopyRecipientsField ::= SEQUENCE OF CopyRecipientsSubfield CopyRecipientsSubfield ::= RecipientSpecifier The phrase Òcopy recipientsÓ above is not precisely defined by this Recommendation; it is given meaning by users. Note Ñ The copy recipients, for example, might be those users to whom, and those DLs to whose members the IPM is conveyed for information. 7.2.6Blind copy recipients The blind copy recipients heading field (C) identifies zero or more users and DLs who are intended blind copy ÒrecipientsÓ of the IPM. It also identifies the responses the authorizing users ask of each of those users and of each member of those DLs. It comprises a sequence of subÑfields, each a recipient specifier, one for each blind copy recipient. BlindCopyRecipientsField ::= SEQUENCE OF BlindCopyRecipientsSubfield BlindCopyRecipientsSubfield ::= RecipientSpecifier The phrase Òcopy recipientsÓ above has the same meaning as in ¤ 7.2.5. A blind copy recipient is one whose role as such is disclosed to neither primary nor copy recipients. In the instance of an IPM intended for a blind copy recipient, this conditional field shall be present and identify that user or DL. Whether it shall also identify the other blind copy recipients is a local matter. In the instance of the IPM intended for a primary or copy recipient, the field shall be absent or identify no users or DLs. 7.2.7RepliedÑto IPM The repliedÑto IPM heading field (C) identifies the IPM to which the present IPM is a reply. It comprises an IPM identifier. RepliedToIPMField ::= IPMIdentifier This conditional field shall be present if, and only if, the IPM is a reply. Note Ñ In the context of forwarding, care should be taken to distinguish between the forwarding IPM and the forwarded IPM. This field should identify whichever of these two IPMs to which the reply responds. 7.2.8Obsoleted IPMs The obsoleted IPMs heading field (D no subfields i.e., elements) identifies zero or more IPMs that the authorizing users of the present IPM consider it to obsolete. It comprises a sequence of subÑfields, each an IPM identifier, one for each IPM. ObsoletedIPMsField ::= SEQUENCE OF ObsoletedIPMsSubfield ObsoletedIPMsSubfield ::= IPMIdentifier Note Ñ In the context of forwarding, care should be taken to distinguish between the forwarding IPM and the forwarded IPM. This field should identify whichever of these two IPMs the present IPM obsoletes. 7.2.9Related IPMs The related IPMs heading field (D no subfields i.e., elements) identifies zero or more IPMs that the authorizing users of the present IPM consider related to it. It comprises a sequence of subÑfields, each an IPM identifier, one for each IPM. RelatedIPMsField ::= SEQUENCE OF RelatedIPMsSubfield RelatedIPMsSubfield ::= IPMIdentifier The word ÒrelatedÓ above is not precisely defined by this Recommendation; it is given meaning by users. Note 1 Ñ A related IPM, e.g., might be one discussed in the body of the present IPM. Note 2 Ñ In the context of forwarding, care should be taken to distinguish between the forwarding IPM and the forwarded IPM. This field should identify whichever of these two IPMs is related to the present IPM. 7.2.10 Subject The subject heading field (O) identifies the subject of the IPM. It comprises a teletex string of from zero to a prescribed number of characters (see Annex K), chosen from the graphic subset of the teletex string character set. A length of zero is discouraged. SubjectField ::= TeletexString (SIZE (0. .ubÑsubjectÑfield)) 7.2.11 Expiry time The expiry time heading field (O) identifies when the authorizing users consider the IPM to lose its validity. It comprises a date and time. ExpiryTimeField ::= Time 7.2.12 Reply time The reply time heading field (O) identifies by when the authorizing users request (but do not demand) that any replies to the present IPM be originated. It comprises a date and time. ReplyTimeField ::= Time 7.2.13 Reply recipients The reply recipients heading field (C) identifies zero or more users and DLs whom the authorizing users request (but do not demand) be among the preferred recipients of any replies to the present IPM. It comprises a sequence of subÑfields, each an O/R descriptor, one for each user or DL. ReplyRecipientsField ::= SEQUENCE OF ReplyRecipientsSubfield ReplyRecipientsSubfield ::= ORDescriptor This conditional field shall be present if, and only if, the desired reply recipients are other than the originator of the present IPM alone. Note Ñ If this field is present and identifies several users and DLs, the originator may include himself among them. If he elects not to do so, he will not be considered among the desired reply recipients. 7.2.14 Importance The importance heading field (D normal) identifies the importance that the authorizing users attach to the IPM. It may assume any one of the following values: low, normal, or high. ImportanceField ::= ENUMERATED { low (0), normal (1), high (2) } The values above are not defined by this Recommendation; they are given meaning by users. 7.2.15 Sensitivity The sensitivity heading field (C) identifies the sensitivity that the authorizing users attribute to the IPM. SensitivityField ::= ENUMERATED { personal (1), private (2), companyÑconfidential (3) } This field may assume any one of the following values: a)personal: The IPM is conveyed to its preferred recipients as individuals, rather than in their professional capacities. b)private: The IPM should be conveyed to no one other than its preferred recipients. c)companyÑconfidential: The IPM contains information that should be handled according to companyÑspecific procedures. The conditional field shall be present if, and only, if the IPM is sensitive. 7.2.16 AutoÑforwarded The autoÑforwarded heading field (D false) indicates whether the IPM is the result of autoÑforwarding. It is a Boolean. AutoForwardedField ::= BOOLEAN 7.2.17 Extensions The extensions heading field (D no extensions, i.e., members) conveys information accommodated by no other heading field. It comprises a Set of zero or more heading extensions (or extensions), each conveying one such information item. ExtensionsField ::= SET OF HeadingExtension HeadingExtension ::= SEQUENCE { type OBJECT IDENTIFIER, value ANY DEFINED BY type DEFAULT NULL NULL } Each extension has the following components: a)type (M): Identifies the semantics and restricts the abstract syntax of the value component. An object identifier. b)value (D null): An information item whose abstrct syntax is restricted only by the type component. An Any. The type components of all the extensions in the extensions field shall differ. Not every defined extension need appear in the field. All extensions are defined in Annex A. Thus, each extension's type component shall have one of the values given in that Annex. An extension whose type component has another value shall be ignored. Every extension is defined by means of the following macro. HEADINGÑEXTENSION MACRO ::= BEGIN TYPE NOTATION ::= ÒVALUEÓ type | empty VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) END An instance of the macro's type notation identifies the data type to which the extension's value component shall be restricted. If no type is identified explicitly, null is implied. An instance of the macro's value notation identifies the object identifier that shall appear as the extension's type component. Note Ñ Future versions of this Recommendation may define additional extensions. Furthermore, future versions are likely to add to the heading only by means of this field. 7.3 Body part types The types of body parts that may appear in the body of an IPM are defined and described below: BodyPart ::= CHOICE { ia5Ñtext [0] IA5TextBodyPart, voice [2] VoiceBodyPart, g3Ñfacsimile [3] G3FacsimileBodyPart, g4Ñclass1 [4] G4Class1BodyPart, teletex [5] TeletexBodyPart, videotex [6] VideotexBodyPart, encrypted [8] EncryptedBodyPart, message [9] MessageBodyPart, mixedÑmode [11] MixedModeBodyPart, bilaterallyÑdefined [14] BilaterallyDefinedBodyPart, nationallyÑdefined [7] NationallyDefinedBodyPart, externallyÑdefined [15] ExternallyDefinedBodyPart } Body parts of some of the types defined below have two components, parameters and data. The parameters component (M) comprises a sequence of information items that describe the information object the body part represents and that typically are format and control parameters. The data component (M) is the information object itself. Note 1 Ñ In Recommendation X.420 (1984), contextÑspecific tags 1 and 10 denote telex and simple formattable document body parts, respectively, which are no longer defined. These tags, therefore, are avoided in BodyPart. Note 2 Ñ Under some circumstances, an IPM may be subjected to conversion while in transit between users. Such a transmittal event may alter a body part's type. 7.3.1IA5 text An IA5 text body part represents IA5 text. It has parameters and data components. IA5TextBodyPart ::= SEQUENCE { parameters IA5TextParameters, data IA5TextData } IA5TextParameters ::= SET { repertoire [0] Repertoire DEFAULT ia5 } IA5TextData ::= IA5String The parameters component comprises the following parameters: a)repertoire (D IA5): Identifies the character set to which the data component is constrained. Repertoire ::= ENUMERATED { ita2 (2), ia5 (5) } This parameter may assume one of the following values: i)ITA2: The data component shall be limited to ITA2 (i.e., telex) character set. ii) IA5: The data component may draw upon the full IA5 character set. The data component is the text, an IA5 string. It may contain lines of any length. Whenever the component is rendered (e.g., displayed to or printed for a user), all (rather than only a part) of the text must be communicated (e.g., lines may be folded but shall not be truncated). Note Ñ Many terminals have a maximum line length of 80 characters. Therefore, lines that do not exceed that length are most likely to be satisfactorily rendered (e.g., are most likely to avoid being folded). 7.3.2Voice A voice body part represents speech. It has parameter and data components. VoiceBodyPart ::= SEQUENCE { parameters VoiceParameters, data VoiceData } VoiceParameters ::= SET ÑÑ for further study VoiceData ::= BIT STRING ÑÑ for further study The parameters of such a body part, and the digitized speech encoding technique that those parameters might identify and parameterize, are for further study. The data component is the speech, a bit string. 7.3.3G3 facsimile A G3 facsimile body part represents Group 3 facsimile images. It has parameters and data components. G3FacsimileBodyPart ::= SEQUENCE { parameters G3FacsimileParameters, data G3FacsimileData } G3FacsimileParameters ::= SET { numberÑofÑpages [0] INTEGER OPTIONAL, nonÑbasicÑparameters [1] G3FascimileNonBasicParameters OPTIONAL } G3FacsimileData ::= SEQUENCE OF BIT STRING The parameters component comprises the following parameters: a)numberÑofÑpages (O): Identifies the number of pages of Group 3 facsimile data present in the data component. A nonÑnegative integer. b)nonÑbasicÑparameters (C): Identifies the nonÑbasic parameters (NBPs) for Group 3 facsimile that characterize the data component. A G3 NBPs descriptor. This conditional parameter shall be present if (but not only if) the body contains two or more G3 facsimile body parts. The data component is the facsimile images, a sequence of bit strings, each encoding a single page of GroupÊ3 facsimile data as dictated by Recommendations T.4 and T.30. Note 1 Ñ The numberÑofÑpages component identifies the number of elements in the sequence that constitutes the data component and is thus redundant. Note 2 Ñ If the body comprises a single such body part, its NBPs may (but need not) be conveyed by means of the envelope of the message that contains the IPM. 7.3.4G4 Class 1 A G4 Class 1 body part represents a finalÑform of document of the sort that is processable by Group 4 Class 1 facsimile terminals. It comprises a sequence of protocol elements which describe the document's layout structure. G4Class1BodyPart ::= SEQUENCE OF ProtocolElement 7.3.5Teletex A teletex body part represents a teletex document. It has parameters and data components. TeletexBodyPart ::= SEQUENCE { parameters TeletexParameters, data TeletexData } TeletexParameters ::= SET { numberÑofÑpages [0] INTEGER OPTIONAL, telexÑcompatible [1] BOOLEAN DEFAULT FALSE, nonÑbasicÑparameters [2] TeletexNonBasicParameters OPTIONAL } TeletexData ::= SEQUENCE OF TeletexString The parameters component comprises the following parameters: a)numberÑofÑpages (O): Identifies the number of pages of teletex text present in the data component. A nonÑnegative integer. b)telexÑcompatible (D false): Indicates whether the document in the data component is telexÑcompatible. A Boolean. If this parameter has the value true, every teletex string in the data component shall be restricted to the ITA2 character set. No line shall exceed 69 characters in length. c)nonÑbasic parameters (C): Identifies the NBPs for teletex that characterize the data component. A teletex NBPs descriptor. This conditional parameter shall be present if (but not only if) the body contains two or more teletex body parts. The data component is the document, a sequence of teletex strings, each of which encodes one of its pages. Note 1 Ñ The numberÑofÑpages component identifies the number of elements in the sequence that constitutes the data components and is thus redundant. Note 2 Ñ If the body comprises a single such body part, its NBPs may (but need not) be conveyed by means of the envelope of the message that contains the IPM. 7.3.6Videotex A videotex body part represents videotex data. It has parameters and data components. VideotexBodyPart ::= SEQUENCE { parameters VideotexParameters, data VideotexData } VideotexParameters ::= SET { syntax [0] VideotexSyntax OPTIONAL } VideotexData ::= VideotexString The parameters component comprises the following parameters: a)syntax (O): Identifies the syntax of the data component. In the parameter's absence, the syntax shall be considered unspecified. VideotexSyntax ::= INTEGER { ids (0), dataÑsyntax1 (1), dataÑsyntax2 (2), dataÑsyntax3 (3) } This parameter may assume any one of the following values, each of which denotes as follows one of the videotex syntaxes defined in Recommendations T.100 and T.101: i)ids: The IDS syntax. ii) dataÑsyntax1: Data syntax 1. iii)dataÑsyntax2: Data syntax 2. iv) dataÑsyntax3: Data syntax 3. The data component is the videotex data, a videotex string. It shall conform to the videotex syntax denoted by the syntax parameter. 7.3.7Encrypted An encrypted body part represents the result of encrypting a body part of a type defined by this Recommendation. It has parameters and data components. EncryptedBodyPart ::= SEQUENCE { parameters EncryptedParameters, data EncryptedData } EncryptedParameters ::= SET ÑÑ for further study EncryptedData ::= BIT STRING ÑÑ for further study The parameters of such a body part, and the encryption technique that those parameters might identify and parameterize, are for further study. The data component is the encrypted body part, a bit string. The bits of the bit string shall encrypt a data value of (ASN.1) type BodyPart encoded in accordance with the basic encoding rules of Recommendation X.209. 7.3.8Message A message body part represents an IPM and, optionally, its delivery envelope. It has parameters and data components. MessageBodyPart ::= SEQUENCE { parameters MessageParameters, data MessageData } MessageParameters ::= SET { deliveryÑtime [0] MessageDeliveryTime OPTIONAL, deliveryÑenvelope [1] OtherMessageDeliveryFields OPTIONAL } MessageData ::= IPM The parameters component comprises the following parameters: a)deliveryÑtime (O): The date and time the IPM was delivered. The presence of this component in the absence of the deliveryÑenvelope component is discouraged. b)deliveryÑenvelope (O): The IPM's other message delivery fields. The presence of this component in the absence of the deliveryÑtime component is discouraged. The data component is the IPM. Including one IPM in another as described in the present clause is called forwarding that IPM. The enclosing IPM is called the forwarding IPM, the enclosed IPM the forwarded IPM. Note 1 Ñ The possible future inclusion of a message identifier in the parameters component is for further study. Its present omission provides compatibility with Recommendation X.420 (1984). Note 2 Ñ That the IPM and purported delivery envelope of a message body part are, in any sense, genuine is unverified. 7.3.9MixedÑmode A mixedÑmode body part represents a finalÑform document of the sort that is processable by mixedÑmode Teletex terminals and Group 4 Classes 2 and 3 facsimile terminals. It comprises a sequence of protocol elements which describe the document's layout structure. MixedModeBodyPart ::= SEQUENCE OF ProtocolElement 7.3.10 Bilaterally defined A bilaterally defined body part represents an information object whose semantics and abstract syntax are bilaterally agreed by the IPM's originator and all of its potential recipients. It comprises an OctetString. BilaterallyDefinedBodyPart ::= OCTET STRING Note Ñ The use of this body parts is discouraged. It predates the externally defined body part type and is retained for backward compatibility with Recommendation X.420 (1984). The externally defined body part type provides the same capabilities and more, its use is preferred, e.g., because such use clearly distinguishes between the body parts defined by one community of users and those defined by another. 7.3.11 Nationally defined A nationally defined body part represents an information object whose semantics and abstract syntax are nationally defined by a country whose identity is bilaterally agreed by the IPM's originator and all of its potential recipients. It comprises an Any. NationallyDefinedBodyPart ::= ANY Note 1 Ñ This body part is intended for use in domestic communication where the country in question is implicitly that of the originator and all of the potential recipients. Note 2 Ñ The use of this body part type is discouraged. It predates the externally defined body part type and is retained for backward compatibility with Recommendation X.420 (1984). The externally defined body part type provides the same capabilities and more, and its use is preferred, e.g., because such use clearly distinguishes between the body parts defined by one country and those defined by another. 7.3.12 Externally defined An externally defined body part represents an information object whose semantics and abstract syntax are denoted by an object identifier which the body part carries. It has parameters and data components. ExternalDefinedBodyPart ::= SEQUENCE { parameters [0] ExternallyDefinedParameters OPTIONAL data ExternallyDefinedData } ExternallyDefinedParameters ::= EXTERNAL ExternallyDefinedData ::= EXTERNAL The parameters and data components are externals (see ¤ 32 of Recommendation X.208). Their directÑreference components shall be present, their indirectÑreference and dataÑvalueÑdescriptor components absent. On the basis of the externally defined body part type, all body part types are divided into two important classes as follows: a)basic: Said of any body part type except externally defined. Denoted by an integer (an ASN.1 contextÑspecific tag). All basic body part types are defined in this Recommendation. b)extended: Some of the externally defined body part type restricted to any one value of the directÑreference component of the data component of such a body part. Denoted by an object identifier. Some (but not necessarily all) extended body part types are defined in Annex B of this Recommendation. Every extended body part type this Recommendation defines is defined by means of the following macro. Every extended body part type defined elsewhere shall be so defined as well. EXTENDEDÑBODYÑPARTÑTYPE MACRO ::= BEGIN TYPE NOTATION ::= Parameters Data VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) Paramaters ::= ÒPARAMETERSÓ type ÒIDENTIFIEDÓ ÒBYÓ value (OBJECT IDENTIFIER) | empty Data ::= ÒDATAÓ type END An instance of the macro's type notation defines, by means of its PARAMETERS clause, the type of the data value that is represented by the parameters component of such an (externally defined) body part (an external), and the object identifier that appears in the directÑreference component of this parameters component. The omission of the parameters component is implied by the omission of this clause. An instance of the type notation also defines, by means of its DATA clause, the type of the data value that is represented by the data component of such a body part (an external). An instance of the macro's value notation defines the object identifier that appears as the directÑreference component of the data component of such an (externally defined) body part. The object identifier identifies the encoding rules for the body part. Those body parts whose types this Recommendation defines shall be encoded using ASN.1 basic encoding rules. Note 1 Ñ This body part enables the exchange of information objects of all kinds, each unambiguously and uniquely identified. This identification relies upon the directÑreference component mentioned above, which is an object identifier. object identifiers are easily obtained, e.g., by national bodies and private organizations. Note 2 Ñ If an externally defined body part has a parameters component, the object identifier in its directÑreference component is allocated at the same time and by the same naming authority as that in the directÑreference component of the data component. Note 3 Ñ Like body parts of other types, an externally defined body part may be subjected to conversion. However, specification of the conversion algorithms may be outside the scope of Recommendation X.408. Note 4 Ñ The basic body part exists for purely historical reasons, predating the externally defined body part type. 8 Interpersonal notifications An interpersonal notification (IPN) is a member of a secondary class of information object conveyed between users in interpersonal messaging. IPN ::= SET { ÑÑ commonÑfields ÑÑ COMPONENTS OF CommonFields, choice [0] CHOICE { nonÑreceiptÑfields [0] NonReceiptFields, receiptÑfields [1] ReceiptFields } } An IPN may take either of the following forms: a)nonÑreceipt notification (NRN): An IPN that reports its originator's failure to receive, to accept, or his delay in receiving, an IPM. NRN ::= IPN ÑÑ with nonÑreceiptÑfields chosen b)receipt notification (RN): An IPN that reports its originator's receipt, or his expected and arranged future receipt, of an IPM. RN ::= IPN ÑÑ with receiptÑfields chosen The IPM to which an IPN refers is called the subject IPM. Only a UA to which the subject IPM is actually delivered shall originate an IPN relating to it, and it shall originate at most one such IPN which shall be conveyed to the subject IPM's originator alone. An actual recipient shall originate an IPN only in accordance with the notificationÑrequests component of the subject recipient specifier. The subject recipient specifier is that recipient specifier in the subject IPM's heading as a result of which the subject IPM is delivered to that user. The subject recipient specifier is determined by examining the sequence of recipient specifiers that constitute the subject IPM's primary, copy and blind copy recipients heading fields. The fields are examined in the order in which they are mentioned in the preceding sentence. Within each field, the specifiers are examined in the order in which they appear there. The subject recipient specifier is the first one found whose recipient component has as its value an O/R descriptor whose formalÑname component is present and has as its value either an O/R name of the preferred recipient as a result of which the subject IPM was delivered to the user on whose behalf the examination is performed or, if the IPM reached the user because of his membership in a DL, an O/R name appearing in the message's DL expansion history (see ¤ 8.3.1.1.1.7 of Recommendation X.411). An IPN comprises a set of information items called notification fields (or fields), each of which is of one of the following classes: a)common field: A notification field applicable to both NRNs and RNs. b)nonÑreceipt field: A notification field applicable to NRNs alone. c)receipt field: A notification field applicable to RNs alone. The structure of an IPN is depicted in Figure 2/X.420. The fields, in each of the above classes, that may appear in an IPN are defined and described below. 8.1 Common fields The common fields are defined and described below. CommonFields ::= SET { subjectÑipm SubjectIPMField, ipnÑoriginator [1]IPNOriginatorField OPTIONAL, ipmÑpreferredÑrecipient[2]IPMPreferredRecipientField OPTIONAL, conversionÑeits ConversionEITsField OPTIONAL } 8.1.1Subject IPM The subject IPM common field (M) identifies the subject IPM. It comprises an IPM identifier. SubjectIPMField ::= IPMIdentifier 8.1.2IPN originator The IPN originator common field (O) identifies the IPN's originator. It comprises an O/R descriptor. IPNOriginatorField ::= ORDescriptor If the IPN's originator is a preferred recipient of the subject IPM, the O/R descriptor above shall be precisely that which is the value of the recipient component of the subject recipient specifier. Fig. 2/X.420/T0705281-89 8cm 8.1.3IPM preferred recipient the IPM preferred recipient common field (C) identifies the preferred recipient of the subject IPM who gives rise to its delivery to the IPN's originator (an alternate, (DL) member, or substitute recipient). It comprises an O/R descriptor. IPMPreferredRecipientField ::= ORDescriptor The O/R descriptor above shall be precisely that which is the value of the recipient component of the subject recipient specifier. This conditional field shall be present if, and only if, it would identify a user other than the IPN's originator or a DL. 8.1.4Conversion EITs The conversion EITs common field (C) identifies the EITs of the subject IPM upon delivery to the IPN's originator. It comprises an EITs descriptor. ConversionEITsField ::= EncodedInformationTypes This conditional field shall be present if, and only if, the IPM was subjected to conversion for delivery to the IPN's originator. 8.2 NonÑreceipt fields The nonÑreceipt fields are defined and described below. NonReceiptFields ::= SET { nonÑreceiptÑreason [0]NonReceiptReasonField, discardÑreason [1]DiscardReasonField OPTIONAL, autoÑforwardÑcomment [2]AutoForwardCommentField OPTIONAL, returnedÑipm [3] ReturnedIPMField OPTIONAL } 8.2.1NonÑreceipt reason The nonÑreceipt reason nonÑreceipt field (M) indicates why the NRN's originator has not received the subject IPM (even though it was delivered to him). NonReceiptReasonField ::= ENUMERATED { ipmÑdiscarded (0), ipmÑautoÑforwarded (1) } This field may assume one of the following values: a)ipmÑdiscarded: The IPM was discarded. This case is further illumined by the discard reason field. b)ipmÑautoÑforwarded: The IPM was autoÑforwarded. This case is further illumined by the autoÑforward comment field. 8.2.2Discard reason The discard reason nonÑreceipt field (C) indicates why the subject IPM was discarded (subsequent to its delivery to the NRN's originator and prior to its receipt). DiscardReasonField ::= ENUMERATED { ipmÑexpired (0), ipmÑobsoleted (1), userÑsubscriptionÑterminated (2) } This field may assume any one of the following values: a)ipmÑexpired: autoÑdiscard was in effect, expired IPMs were being discarded, and the time identified by the subject IPM's expiry time heading field had arrived. b)ipmÑobsoleted: autoÑdiscard was in effect, obsolete IPMs were being discarded, and the obsoleted IPMs heading field of another IPM, delivered to the NRN's originator, identified the subject IPM. c)userÑsubscriptionÑterminated: The interpersonal messaging subscription of the NRN's originator was terminated. This conditional field shall be present only if the nonÑreceipt reason field has the value ipmÑdiscarded. 8.2.3AutoÑforward comment The autoÑforward comment nonÑreceipt field (C) is information preÑsupplied for this purpose by the NRN's originator. It comprises a printable string of from zero to a prescribed number of characters (see Annex K), chosen from the printable string character set. A length of zero is discouraged. AutoForwardCommentField ::= AutoForwardComment AutoForwardComment ::= PrintableString (SIZE (0. .ubÑautoÑforwardÑcomment)) The value of this field shall be precisely the autoÑforwardÑcomment argument of the change autoÑforwarding abstract operation as a result of which the subject IPM was autoÑforwarded. This conditional field shall be present if, and only if, the nonÑreceipt reason field has the value ipmÑautoÑforwarded and the autoÑforwardÑcomment argument above was supplied. 8.2.4Returned IPM The returned IPM nonÑreceipt field (C) is precisely the subject IPM. ReturnedIPMField ::= IPM This conditional field shall be present if, and only if, ipmÑreturn is among the values of the notificationÑrequests component of the subject recipient specifier and the subject IPM was not subjected to conversion for delivery to the NRN's originator. 8.3 Receipt fields The receipt fields are defined and described below. ReceiptFields ::= SET { receiptÑtime [0] ReceiptTimeField, acknowledgmentÑmode [1] AcknowledgmentModeField DEFAULT manual, supplÑreceiptÑinfo [2] SupplReceiptInfoField DEFAULT ÒÓ } 8.3.1Receipt time The receipt time receipt field (M) identifies when the RN's originator received the subject IPM. It comprises a date and time. ReceiptTimeField ::= Time 8.3.2Acknowledgment mode The acknowledgment mode receipt field (D manual) identifies the manner in which the RN was originated. AcknowledgmentModeField ::= ENUMERATED { manual (0), automatic (1) } This field may assume any one of the following values: a)manual: The RN was originated by means of the originate RN abstract operation. b)automatic: The RN was originated as a result of autoÑacknowledgment. 8.3.3Suppl receipt info The suppl receipt info receipt field (O) gives supplementary information about the receipt of the subject IPM by the RN's originator. It comprises a printable string of from zero to a prescribed number of characters (see Recommendation X.411), chosen from the printable string character set. SupplReceiptInfoField ::= SupplementaryInformation SECTION 3 Ñ ABSTRACT SERVICE DEFINITION 9 Overview This section defines the abstract service that characterizes interpersonal messaging, and describes the environment in which service is supplied and consumed. It does both using the abstract service definition conventions of Recommendation X.407. This section covers the following topics: a)primary object types, b)primary port types, c)abstract operations, d)abstract errors, e)other capabilities. 10 Primary object types The environment in which interpersonal messaging takes place can be modelled as an abstract object which is hereafter referred to as the interpersonal messaging environment (IPME). ipme OBJECT ::= idÑotÑipme When refined (i.e., functionally decomposed), the IPME can be seen to comprise lesser objects which interact by means of ports. ipmeÑrefinement REFINE ipme AS ipms origination [S] PAIRED WITH ipmsÑuser reception [S] PAIRED WITH ipmsÑuser management [S] PAIRED WITH ipmsÑuser ipmsÑuserÑRECURRING ::= idÑrefÑprimary The lesser objects are referred to as the primary objects of interpersonal messaging. They include a single, central object, the interpersonal messaging system (IPMS), and numerous peripheral objects called interpersonal messaging system users (IPMS users). The structure of the IPME is depicted in Figure 3/X.420. The primary object types are defined and described below. The types of ports by means of which they interact are discussed in ¤ 11. Fig. 3/X.420/T0705290-88 6cm 10.1 Interpersonal messaging system user An interpersonal messaging system user (IPMS user) is a user that engaged in interpersonal messaging. An IPMS user originates, receives, or both originates and receives information objects of the types defined in ¤ 2. ipmsÑuser OBJECT PORTS { origination [C], reception [C], management [C] } ::= idÑotÑipmsÑuser The IPME comprises any number of of IPMS users. Note 1 Ñ As its name suggests, interpersonal messaging is typically an activity of people. Often, therefore, this Recommendation uses personal pronouns (e.g., ÒheÓ) to refer to IPMS users. This practice, however, is not intended to preclude other, atypical uses of interpersonal messaging in which IPMS users are not people. Note 2 Ñ For brevity, the term ÒuserÓ is used throughout the rest of this Recommendation with the meaning of ÒIPMS userÓ. 10.2 Interpersonal messaging system The interpersonal messaging system (IPMS) is the object by means of which all users communicate with one another in interpersonal messaging. ipms OBJECT PORTS { origination [S], reception [S], management [S] } ::= idÑotÑipms The IPME comprises exactly one IPMS. 11 Primary port types The primary objects of interpersonal messaging are joined to and interact with one another by means of ports. These ports, which the IPMS supplies, are referred to as the primary ports of interpersonal messaging. They are of the three types defined below. Note Ñ In ¤ 16 to follow, the IPMS is decomposed into still lesser objects, among which is the MTS. This fact is anticipated in the present paragraph by the inclusion of certain MTS capabilities in the IPMS abstract service. 11.1 Origination An origination port is the means by which a single user conveys to the IPMS messages containing information objects of the types defined in section two. Through such a port the user originates interpersonal messages and receipt notifications. In addition, the user may originate probes through such a port. The IPMS supplies one origination port to each user (with the exception of indirect users served by PDAUs; see ¤ 16.5). 11.2 Reception A reception port is the means by which the IPMS conveys to a single user messages containing information objects of the types defined in section two. Through such a port the user receives interpersonal messages and interpersonal notifications. In addition, the user may receive reports through such a port. The IPMS supplies one reception port to each user. 11.3 Management A management port is the means by which a single user changes information about himself on file with the IPMS. By means of such a port the user enables and disables autoÑdiscard, Ñacknowledgment, and Ñforwarding. The IPMS supplies one management to each user (with the exception of indirect users served by PDAUs; see ¤ 16.5). 12 Abstract operations The IPMS abstract service is the set of capabilities that the IPMS provides to each user by means of one origination, one reception, and one management port. Those capabilities are modelled as abstract operations, which may encounter abstract errors when invoked. The abstract operations available at origination, reception, and management ports, respectively, are defined and described below. The abstract errors they may provoke are the subject of ¤ 13. Note 1 Ñ The IPMS abstract service involves neither abstract bind nor abstract unbind operations. Note 2 Ñ The IPMS authenticates (i.e., establishes the identity of) the typical user before offering the IPMS abstract service to him. By this means it can verify, for example, that the user is an IPMS subscriber. Authentication, where required, is implicit (rather than explicit) in the definition of the IPMS abstract service. Note 3 Ñ The purpose of the IPMS abstract service definition is not to prescribe the user interfaces of implementations of portions of the IPMS, but rather to clarify the meaning and intended use of the information objects of section two. A user interface need not provide commands in oneÑtoÑone correspondence to the service's abstract operations, nor indeed even divide the labor between the user and the IPMS as the service does. Note 4 Ñ In ¤ 16 to follow, the IPMS is decomposed into objects among which is the MTS. The present paragraph reflects this fact by its inclusion of various MTSÑdefined information items in the IPMS abstract service. 12.1 Origination abstract operations The abstract operations available at an origination port are invoked by the user and performed by the IPMS. origination PORT CONSUMER INVOKES { OriginateProbe, OriginateIPM, OriginateRN } ::= idÑptÑorigination 12.1.1 Originate probe The originate probe abstract operation originates a probe concerning (a class of) messages whose contents are IPMs. OriginateProbe ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] ProbeSubmissionEnvelope, content [1] IPM } RESULT SET { submissionÑidentifier [0] ProbeSubmissionIdentifier, submissionÑtime [1] ProbeSubmissionTime } ERRORS { SubscriptionError, RecipientImproperlySpecified } This abstract operation has the following arguments: a)envelope (M): A probe submission envelope, whose makeup the MTS abstract service defines. The UA supplies all but the following envelope components, which the user provides: i)The desired perÑmessage options (i.e., perÑmessage indicators and extensions). ii) The O/R names of the preferred recipients and the perÑrecipient options (i.e., originator report request, explicit conversion, and extensions) desired for each. b)content (M): An instance of the class of IPM whose deliverability is to be probed. This abstract operation has the following results: 1)submissionÑidentifier (M): The probe submission identifier the MTS assigns to probe. 2)submissionÑtime (M): The date and time the probe was directly submitted. 12.1.2 Originate IPM The originate IPM abstract operation originates a message whose content is an IPM. OriginateIPM ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] MessageSubmissionEnvelope, content [1] IPM } RESULT SET { submissionÑidentifier [0] MessageSubmissionIdentifier, submissionÑtime [1] MessageSubmissionTime } ERRORS { SubscriptionError, RecipientImproperlySpecified } This abstract operation has the following arguments: a)envelope (M): A message submission envelope, whose makeup the MTS abstract service defines. The UA supplies all but the following envelope components, which the user provides: i)The desired perÑmessage options (i.e., priority, perÑmessage indicators, deferred delivery time, and extensions). ii) The O/R names of the preferred recipients and the perÑrecipient options (i.e., originator report request, explicit conversion, and extensions) desired for each. b)content (M): The IPM being originated. Its autoÑforwarded heading field shall be absent or have the value false. This abstract operation has the following results: 1)submissionÑidentifier (M): The message submission identifier the MTS assigns to the submission. 2)submissionÑtime (M): The date and time the message was directly submitted. 12.1.3 Originate RN The originate RN abstract operation originates a message whose content is RN. OriginateRN ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] MessageSubmissionEnvelope, content [1] RN } RESULT SET { submissionÑidentifier [0] MessageSubmissionIdentifier, submissionÑtime [1] MessageSubmissionTime } ERRORS { SubscriptionError, RecipientImproperlySpecified } An RN shall be originated only by an actual recipient of the subject IPM of whom an RN is requested by means of the notificationÑrequests component of the subject IPM's subject recipient specifier. The user shall not have previously originated an RN in response to the subject IPM, by means of either the present abstract operation or autoÑacknowledgment. This abstract operation has the following arguments: a)envelope (M): A message submission envelope, whose makeup the MTS abstract service defines. The UA supplies all but the following envelope components, which the user provides: i)The desired perÑmessage options (i.e., priority, perÑmessage indicators, and extensions). Implicit conversion shall be prohibited, priority that of the subject IPM. ii) The O/R names of the preferred recipients and the perÑrecipient options (i.e., explicit conversion and extensions) desired for each. Reports shall not be requested. b)content (M): The RN being originated. This abstract operation has the following results: 1)submissionÑidentifier (M): The message submission identifier the MTS assigns to the submission. 2)submissionÑtime (M): The date and time the message was directly submitted. 12.2 Reception abstract operatons The abstract operations available at a reception port are invoked by the IPMS and performed by the user. reception PORT SUPPLIER INVOKES { ReceiveReport, ReceiveIPM, ReceiveRN, ReceiveNRN } ::= idÑptÑreception Note 1 Ñ As abstractly defined, the IPMS provides no storage for received messages because whether or not it does so for a particular user has no impact upon that user's ability to communicate with other users. Thus the provision of storage is a local matter. Note 2 Ñ Elaborating upon the above, the receive IPM abstract operation, e.g. expels an IPM from the IPMS because its purpose is to clarify the meaning of the receipt transmittal step. In contrast, the capabilities of a user to whom storage for received messages is provided might include a ÒDisplay IPMÓ command that enables the user to view the delivered (and perhaps already received) IPM whose IPM identifier he specifies, and that allows him to do so any number of times by repeatedly invoking the command. The first, but not subsequent uses of the command to view a particular IPM represents the concrete realization of the receive IPM abstract operation in such an implementation. 12.2.1 Receive report The receive report abstract operation receives a report. ReceiveReport ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] ReportDeliveryEnvelope, undeliveredÑobject [1] InformationObject OPTIONAL } RESULT ERRORS { } The report received may concern any of the following previously originated by the report's recipients: a)A probe concerning a message whose content was an IPM that was originated with the originate probe abstract operation. b)A message whose content was an NRN originated as a result of autoÑdiscard or autoÑforward. c)A message whose content was an RN that was originated with the originate RN abstract operations by autoÑacknowledgment. d)A message whose content was an IMP that was originated with the originate IPM abstract operation or by autoÑforwarding. This abstract operation has the following arguments: 1)envelope (M): A report delivery envelope, whose makeup the MTS abstract service defines. 2)undeliveredÑobject (C): The content of the message whose status is being reported. An IPM or IPN. If the report was provoked by a previous originate probe abstract operation invocation, this conditional agreement shall be absent. If the report was provoked by a previous originate IPM abstract operation invocation, the argument shall be present if, and only if, content return was requestd. Otherwise (i.e., if the report was provoked by an IPN), the argument shall be absent. This abstract operation has no results. 12.2.2 Receive IPM The receive IPM abstract operation receives a message whose content is an IPM. ReceiveIPM ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] MessageDeliveryEnvelope, content [1] IPM } RESULT ERRORS { } This abstract operation has the following arguments: a)envelope (M): The message's delivery envelope. b)content (M): The IPM that is the message's content. This abstract operation has no results. 12.2.3 Receive RN The receive RN abstract operation receives a message whose content is an RN. The RN is provoked by an IPM originated with the originate IPM abstract operation. ReceiveRN ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] MessageDeliveryEnvelope, content [1] RN } RESULT ERRORS { } This abstract operation has the following arguments: a)envelope (M): The message's delivery envelope. b)content (M): The RN that is the message's content. This abstract operation has no results. 12.2.4 Receive NRN The receive NRN abstract operation receives a message whose content is an NRN. The NRN is provoked by an IPM originated with the originate IPM abstract operation. ReceiveNRN ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] MessageDeliveryEnvelope, content [1] NRN } RESULT ERRORS { } This abstract operation has the following arguments: a)envelope (M): The message's delivery envelope. b)content (M): The NRN that is the message's content. This abstract operation has no results. 12.3 Management abstract operations The abstract operations available at a management port are invoked by the user and performed by the IPMS. management PORT CONSUMER INVOKES { ChangeAutoDiscard, ChangeAutoAcknowledgment, ChangeAutoForwarding } ::= idÑptÑmanagement 12.3.1 Change autoÑdiscard The change autoÑdiscard abstract operation enables or disables autoÑdiscard, the automatic discard by the IPMS of expired or obsolete IPMs delivered to, but not yet received by the user. ChangeAutoDiscard; ::= ABSTRACTÑOPERATION ARGUMENT SET { autoÑdiscardÑexpiredÑIPMs [0] BOOLEAN, autoÑdiscardÑobsoleteÑIPMs [1] BOOLEAN } RESULT ERRORS { } When it autoÑdiscards an IPM, the IPMS originates an NRN on the user's behalf if, and only if, one was requested of him by means of the notificationÑrequests component of the subject recipient specifier. This abstract operation has the following arguments: a)autoÑdiscardÑexpiredÑIPMs (M): Whether or not expired IPMs are to be autoÑdiscarded. A Boolean. b)autoÑdiscardÑobsoleteÑIPMs (M): Whether or not obsolete IPMs are to be autoÑdiscarded. A Boolean. This abstract operation has no results. 12.3.2 Change autoÑacknowledgment The change autoÑacknowledgment abstract operation enables or disables autoÑacknowledgment, the automatic origination of RNs by the IPMS on the user's behalf. Such origination occurs upon delivery of IPMs that request RNs of the user by means of the notificationÑrequests components of their subject recipient specifiers. ChangeAutoAcknowledgment ::= ABSTRACTÑOPERATION ARGUMENT SET { autoÑacknowledgeÑIPMs [0] BOOLEAN, autoÑacknowledgeÑsupplÑreceiptÑinfo [1] SupplementaryInformation OPTIONAL } RESULT ERRORS { SubscriptionError } This abstract operation has the following arguments: a)autoÑacknowledgeÑIPMs (M): Whether or not IPMs are to be autoÑacknowledged. A Boolean. b)autoÑacknowledgeÑsupplÑreceiptÑinfo (C): The suppl receipt info receipt field of each RN provoked by autoÑacknowledgment. This conditional argument shall be present if, and only if, the autoÑacknowledgeÑIPMs argument has the value true. This abstract operation has no results. 12.3.3 Change autoÑforwarding The change autoÑforwarding abstract operation enables or disables autoÑforwarding, the automatic forwarding of IPMs by the IPMS to preÑspecified users or DLs. Such forwarding occurs upon delivery of the IPMs. ChangeAutoForwarding ::= ABSTRACTÑOPERATION ARGUMENT SET { autoÑforwardÑIPMs [0] BOOLEAN, autoÑforwardÑrecipients [1] SEQUENCE OF ORName OPTIONAL, autoÑforwardÑheading [2] Heading OPTIONAL, autoÑforwardÑcomment [3] AutoForwardComment OPTIONAL } RESULT ERRORS { SubscriptionError, RecipientImproperlySpecified } The body of each IPM the IPMS originates as a result of autoÑforwarding comprises a single body part of type message. The content of the message represented by that body part is the forwarded IPM. When it autoÑforwards an IPMS, the IPMS originates an NRN on the user's behalf if, and only if, one was requested of him by means of the notificationÑrequests component of the subject recipient specifier. This abstract operation has the following arguments: a)autoÑforwardÑIPMs (M): Whether or not IPMs are to be autoÑforwarded. A Boolean. b)autoÑforwardÑrecipients (C): The users or DLs to which IPMs are to be autoÑforwarded. A sequence of O/R names. This conditional argument shall be present if, and only if, the autoÑforwardÑIPMs argument has the value true. c)autoÑforwardÑheading (C): The heading that is to be used for each forwarding IPM. Its autoÑforwarded heading field shall have the value true. This conditional argument shall be present if, and only if, the autoÑforwardÑIPMs argument has the value true. d)autoÑforwardÑcomment (C): The value that is to be supplied as the autoÑforward comment nonÑreceipt field of each NRN conveyed to the originator of an autoÑforwarded IPM. The conditional argument shall be present if, and only if, the autoÑforwardÑIPMs argument has the value true. This abstract operation has no results. Note Ñ This abstract operation is intended to define the essence of autoÑforwarding, sophisticated autoÑforwarding capabilities, e.g., like those of an MS. 13 Abstract errors The abstract errors that may be reported in response to the invocation of the abstract operations available at origination, reception, and management ports are defined and described below or as part of the MTS abstract service definition. Note Ñ The set of abstract errors represented below is intended to be illustrative, rather than exhaustive. 13.1 Subscription error The subscription error abstract error reports that the user has not subscribed to one or more of the elements of service implicit in his invocation of the abstract operation whose performance is aborted. SubscriptionError ::= ABSTRACTÑERROR PARAMETER SET { problem [0] SubscriptionProblem } This abstract error has the following parameters: a)problem (M): The subscriptionÑrelated problem encountered. SubscriptionProblem ::= ENUMERATED { ipmsÑeosÑnotÑsubscribed(0), mtsÑeosÑnotÑsubscribed (1) } This parameter may assume any one of the following values: i)IPMSÑeosÑnotÑsubscribed: An IPMS element of service is not subscribed. ii) MTSÑeosÑnotÑsubscribed: An MTS element of service is not subscribed. 13.2 Recipient improperly specified The recipient improperly specified abstract error reports that one or more of the O/R names supplied as arguments of the abstract operation whose performance is aborted, or as components of its arguments, are invalid. This abstract error is defined by the MTS abstract service. 14 Other capabilities In addition to the capabilities embodied in the IMPS abstract service, defined above, the IPMS shall transparently extend to each use the other MS and MTS capabilities identified below. (The enumeration of these capabilities necessarily anticipates the fact, stated in ¤ 16, that MSs and the MTS are among the IPMS' component parts.) The following additional capabilities shall be provided: a)Submission: Capabilities of the MS' or MTS' submission port not embodied in the IPMS abstract service e.g., the ability to cancel delivery of a previously originated message whose content is an IPM (but not an RN), if deferred delivery was selected. b)Delivery: Capabilities of the MTS' delivery port not embodied in the IPMS abstract service, e.g., the ability to temporarily control the kinds of information objects the MTS conveys to the user's UA. c)Administration: The capabilities of the MS's or MTS's administration port. d)Retrieval: The capabilities of the MS' retrieval port. In addition to the above and as a local matter, the IPMS may provide to users additional capabilities neither defined nor limited by this Recommendation. Among such capabilities are those of the directory. Note Ñ The required capabilities of this clause are excluded from the formal definition of the IPMS abstract service for purely pragmatic reasons, in particular, because their inclusion would largely and needlessly reproduce the definitions of the MS and MTS abstract operations upon which the capabilities are based. SECTION 4 Ñ ABSTRACT SERVICE PROVISION 15 Overview This section specifies how the IPMS provides the IPMS abstract service to users. This section covers the following topics: a)secondary object types, b)secondary port types, c)user agent operation, d)message store operation, e)message contents, f)port realization, g)conformance. 16 Secondary object types The IPMS can be modeled as comprising lesser objects which interact with one another by means of (additional) ports. ipmsÑrefinement REFINE ipms AS mTS submission [S] PAIRED WITH ipmsÑua, ipmsÑms delivery [S] PAIRED WITH ipmsÑua, ipmsÑms administration [S] PAIRED WITH ipmsÑua, ipmsÑms ipmsÑua RECURRING origination [S] VISIBLE reception [S] VISIBLE management [S] VISIBLE ipmsÑms RECURRING submission [S] PAIRED WITH ipmsÑua retrieval [S] PAIRED WITH ipmsÑua administration [S] PAIRED WITH ipmsÑua tlma RECURRING origination [S] VISIBLE reception [S] VISIBLE management [S] VISIBLE tlxau RECURRING origination [S] VISIBLE reception [S] VISIBLE management [S] VISIBLE pdau RECURRING reception [S] VISIBLE ::= idÑrefÑsecondary These lesser objects are referred to as the secondary objects of interpersonal messaging. They include a single, central object, the MTS, and numerous peripheral objects: interpersonal messaging system user agents (IPMS UAs), interpersonal messaging system message stores (IPMS MSs), telematic agents (TLMAs), telex access units (TLXAUs), and PDAUs. The structure of the IPMS is depicted in Figure 4/X.420. As shown by Figure 4/X.420, IPMS UAs, TLMAs, TLXAUs, and PDAUs are the instruments by means of which the IPMS provides the IPMS abstract service to users. The secondary object types are defined and described below. The types of ports by means of which they interact are discussed in ¤ 17. Note 1 Ñ The refinement above encompasses all possible interconnection of all possible objects. It ignores the possible absence of objects of a particular type (e.g., PDAU), and specific logical configurations of the IPMS MS. The latter are identified in Recommendation X.402. Note 2 Ñ Recommendation T.330 effectively extends the abstract service of Interpersonal Messaging by its definition of a miscellanea port, which is not shown in the figure. See the note in ¤ 16.3. Note 3 Ñ The MTS supplies import and export ports. However, since those ports are not formally defined (in Recommedation X.411), they are not included in the formal refinement above. 16.1 Interpersonal messaging system user agent An interpersonal messaging system user agent (IPMS UA) is a UA tailored so as to better assist a single user to engage in interpersonal messaging. It helps him originate, receive, or both originate and receive messages containing information objects of the types defined in section two. ipmsÑus OBJECT PORTS { origination [S], reception [S], management [S], submission [C], delivery [C], retrieval [C], administration [C] } ::= idÑotÑipmsÑua Fig. 4/X.420/T0705300-88 8cm The IPMS comprises any number of IPMS UAs. Note Ñ For brevity, the term ÒUAÓ is used throughout the rest of this Recommendation with the meaning of ÒIPMS UAÓ. 16.2 Interpersonal messaging system message store An interpersonal messaging system message store (IPMS MS) is an MS tailored so as to better assist a single UA engage in interpersonal messaging. It helps it submit, take delivery of, or both submit and take delivery of messages containing information objects of the types defined in Section 2. ipmsÑms OBJECT PORTS { submission [S], retrieval [S], administration [S], submission [C], delivery [C], administration [C] } ::= idÑotÑipmsÑms The IPMS comprises any number of IPMS MSs. Note Ñ For brevity, the term ÒMSÓ is used throughout the rest of this Recommendation with the meaning of ÒIPMS MSÓ. 16.3 Telematic agent A telematic agent (TLMA) is an AU that helps a single indirect user engage in interpersonal messaging from a telematic terminal, along with that terminal and the network that joins the two. A TLMA helps the user originate, receive, or both originate and receive messages containing information objects of the types defined in Section 2. tlma OBJECT PORTS { origination [S], reception [S], management [S], miscellanea [S] } ::= idÑotÑtlma The IPMS comprises any number of TLMAs. Note 1 ÑA TLMA consumes import and export ports. However, since those ports are not formally defined (in Recommendation X.411), they are not included in the formal definition of TLMA above. Note 2 Ñ A TLMA's miscellanea port is defined in Recommendation T.330. It is not part of the IPMS abstract service in its most general form, which is the subject of this Recommendation. Rather it embodies capabilities available only to a TLMA user. For this reason, it is not considered further here and is not included in the formal refinement of the IPMS found in ¤ 16. 16.4 Telex access unit A telex access unit (TLXAU) is an AU that helps any number of indirect users engage in interpersonal messaging from telex terminals. It helps them originate, receive, or both originate and receive messages containing information objects of the types defined in section two. tlxau OBJECT PORTS { origination [S], reception [S], management [S] } ::= idÑotÑtlxau The IPMS comprises any number of TLXAUs. Note Ñ A TLXAU consumes import and export defined (in Recommendation X.411) they are not included in the formal definition of TLXAU above. 16.5 Physical delivery access unit In the present context, a PDAU helps any number of indirect users engage in interpersonal messaging by means of a PDS. It helps them receive (but not originate) messages containing information objects of the types defined in section two. pdau OBJECT PORTS { reception [S] } ::= idÑotÑpdau The IPMS comprises any number of PDAUs. Note Ñ A PDAU consumes import and export ports. However, since those ports are not formally defined (in Recommendation X.411), they are not included in the formal definition of PDAU above. 16.6 Message transfer system In the present context, the MTS conveys information objects of the types defined in Section 2 between UAs, MSs, TLMAs, and AUs. The IPMS comprises a single MTS. 17 Secondary port types The secondary objects of interpersonal messaging are joined to and interact with one another by means of ports. These ports, which MSs and the MTS supply, are referred to as the secondary ports of interpersonal messaging. They are of the types identified below. The capabilities embodied in one submission, one retrieval, and one administration port constitute the MS abstract service. They are defined in Recommendation X.413. The capabilities embodied in one submission, one delivery, and one administration port constitute the MTS abstract service. They are defined in Recommendation X.411. Note Ñ By means of the abstract bind operation which guards its ports, an MS or the MTS typically authenticates another secondary object before offering its abstract service to that object. 17.1 Submission In the present context, a submission port is the mean by which a UA (directly or indirectly) or an MS (directly) submits probes concerning and messages containing information objects of the types defined in section two. An MS supplies one submission port to its UA. The MTS supplies one submission port to each UA configured without an MS and to each MS. 17.2 Delivery In the present context, a delivery port is the means by which a UA or MS takes delivery of reports concerning and messages containing information objects of the types defined in Section 2. The MTS supplies one delivery port each UA configured without an MS and to each MS. 17.3 Retrieval In the present context, a retrieval port is the means by which a UA retrieves reports concerning and messages containing information objects of the types defined in Section 2. An MS supplies one retrieval port to its UA. 17.4 Administration In the present context, an administration port is the means by which a UA changes information about itself or its user on file with its MS, or a UA or MS changes such information on file with the MTS. An MS supplies one administration port to its UA. The MTS supplies one administration port to each UA configured without an MS and to each MS. 17.5 Import In the present context, an import port is the means by which the MTS imports reports concerning and messages containing information objects of the types defined in Section 2. The MTS supplies one import port to each AU (or TLMA). 17.6 Export In the present context, an export port is the means by which the MTS exports probes concerning and messages containing information objects of the types defined in Section 2. The MTS supplies one export port to each AU (or TLMA). 18 User agent operation A UA must employ the MTS in a particular way in order to (correctly) provide the IPMS abstract service to its user. If the user is equipped with an MS, the latter contributes to the provision of the abstract service and, therefore, is subject to the same rules. The rules that govern the operation of a UA (and MS) are the subject of the present clause. The operation of a TLMA or AU is beyond the scope of this Recommendation. Note 1 Ñ It is for historical reasons that the Recommendation that defines the IPMS abstract service also specifies how a UA (and MS), but not a TLMA or AU, provides it. Note 2 Ñ The purpose of this clause is not to dictate or constrain the implementation of a real UA unnecessarily, but rather to clarify the meaning and intended effect of the IPMS abstract service. 18.1 State variables The operation of a UA is described below with the aid of state variables. A state variable is an information item whose value records the results of the UA's past interactions with its user and influences future interactions. State variables are common to (i.e., shared by) the UA's origination, reception, and management ports. The UA maintains each state variable continuously, i.e., throughout its user's IPMS subscription. Each Boolean state variable is assigned the value false when the subscription commences. The initial values of other state variables are immaterial and therefore unspecified. The UA alters its state variables when performing or invoking abstract operations. It consults them in determining how to perform, or whether or how to invoke abstract operations. Their values (if any) transcend the binding and unbinding of ports. Note Ñ State variables are pedagogic devices not intended to constrain the implementation of a real UA unnecessarily. In particular, a UA need not maintin runÑtime data structures corresponding to the state variables if the behaviour required of it can be assured in another way. 18.2 Performance of origination operations A UA shall perform the abstract operations it makes available at its origination port as prescribed below. The UA alters none of its state variables in the performance of these particular operations. In the performance of these operations, the UA invokes the following abstract operations of the MTS abstract service (which, for the remainder of this paragraph, are unqualified as to their source): a)probe submission, b)message submission. Note Ñ In response to the invocation of these abstract operations, a UA reports abstract errors as appropriate. Specification of the precise circumstances under which each abstract error should be reported is beyon the scope of this Recommendation. 18.2.1 Originate probe A UA shall perform the originate probe abstract operation by invoking probe submission with the arguments indicated below, and by returning to its user the results indicated below. The arguments of probe submission shall be as follows: a)Envelope: The components of this argument that constitute perÑprobe fields shall be as follows; i)OriginatorÑname: The O/R name of the UA's user. ii) ContentÑtype, contentÑlength, and originalÑencodedÑinformationÑtypes: Determined from originate probe's content argument as specified in ¤¤ 20.2 to 20.4. iii)ContentÑidentifier: Specified or omitted as a local matter. The components of this argument that constitute perÑrecipient fields shall be as specified by originate probe's envelope argument. The result of originate probe shall be as follows: 1)SubmissionÑidentifier: Probe submission's probeÑsubmissionÑidentifier result. 2)SubmissionÑtime: Probe submission's probeÑsubmissionÑtime result. Note 1 Ñ The UA shall ignore all properties of originate probe's content argument other than those mentioned above. Note 2 Ñ How the UA employs probe submission's contentÑidentifier result is a local matter. 18.2.2 Originate IPM A UA shall perform the originate IPM abstract operation by invoking message submission with the arguments indicated below, and by returning to its user the results indicated below. The arguments of message submission shall be as follows: a)Envelope: The components of this argument that constitute perÑmessage fields shall be as follows; those not explicitly mentioned below shall be as specified by originate IPM's envelope argument: i)OriginatorÑname: The O/R name of the UA's user. ii) ContentÑtype and originalÑencodedÑinformationÑtypes: Determined from originate IPM's content argument as specified in ¤¤ 20.4 and 20.4, respectively. iii)ContentÑidentifier: Specified or omitted as a local matter. The components of this argument that constitute perÑrecipient fields shall be as specified by originate IPM's envelope argument. b)Content: Determined from originate IPM's content argument (identified as an IPM) as specified in ¤Ê20.1. If the blind copy recipients heading field of the IPM identifies one or more users and DLS, the UA shall invoke message submission multiple times, upon each occasion varying the heading field so as to comply with the information hiding requirements of ¤ 7.2.6. The results of originate IPMS shall be as follows: 1)SubmissionÑidentifier: Message submission's messageÑsubmissionÑidentifier result. 2)SubmissionÑtime: Message submission's messageÑsubmissionÑtime result. Note 1 Ñ How the UA employs message submission's contentÑidentifier result is a local matter. Note 2 Ñ The inclusion of message submission's extensions result among originate IPM's results in proper and for further study. 18.2.3 Originate RN A UA shall perform the originate RN abstract operation by invoking message submission with the arguments indicated below, and by returning to its user the results indicated below. The arguments of message submission shall be as follows: a)Envelope: The components of this argument that constitute perÑmessage fields shall be as follows; those not explicitly mentioned below shall be as specified by originate RN's envelope argument: i)OriginatorÑname: The O/R name of the UA's user. ii) ContentÑtype and originalÑencodedÑinformationÑtypes: Determined from the RN as specified in ¤¤ 20.2 and 20.4, respectively. iii)ContentÑidentifier: Specified or omitted as a local matter. iv) DeferredÑdeliveryÑtime: Omitted. The components of this argument that constitute perÑrecipient fields shall be as specified by originate RN's envelope argument. b)Content: Determined from originate RN's content argument (identified as an RN) as specified in ¤ 20.1. The result of originate RN shall be as follows: 1)SubmissionÑidentifier: Message submission's messageÑsubmissionÑidentifier result. 2)SubmissionÑtime: Message submission's messageÑsubmissionÑtime result. Note 1 Ñ How the UA employs message submission's contentÑidentifier result is a local matter. Note 2 Ñ The inclusion of message submission's extensions result among originate RN's results is proper and for further study. 18.3 Performance of management operations A UA shall perform the abstract operations it makes available at its management port as specified below. The UA alters one or more of its state variables (see below) in the performance of each operation. Note Ñ In response to the invocation of these abstract operations, a UA reports abstract errors as appropriate. Specification of the precise circumstances under which each abstract error should be repeated is beyond the scope of this Recommendation. 18.3.1 Change autoÑdiscard To assist it in providing this abstract operation, a UA maintains the following state variables: a)AutoÑdiscardÑexpiredÑIPMs: A Boolean that indicates whether or not autoÑdiscard is in effect for expired IPMs. b)AutoÑdiscardÑobsoleteÑIPMs: A Boolean that indicates whether or not autoÑdiscard is in effect for obsolete IPMs. A UA shall perform the change autoÑdiscard abstract operation by recording the values of the autoÑdiscardÑexpiredÑIPMs and autoÑdiscardÑobsoleteÑIPMs arguments in the correspondingly named state variables. 18.3.2 Change autoÑacknowledgment To assist it in providing this abstract operation, a UA maintains the following state variables: a)autoÑacknowledgeÑIPMs: A Boolean that indicates whether or not autoÑacknowledgment is in effect. b)autoÑacknowledgeÑsupplÑreceiptÑinfo: The suppl receipt info field of each RN provoked by autoÑacknowledgment. A UA shall perform the change autoÑacknowledgment abstract operation by recording the value of the autoÑacknowledgeÑIPMs argument in the correspondingly named state variable. If the value is true, it also shall record the value of the AutoÑacknowledgeÑsupplÑreceiptÑinfo argument in the correspondingly named state variable. 18.3.3 Change autoÑforwarding To assist it in providing this abstract operation, a UA maintains the following state variables: a)autoÑforwardÑIPMs: A Boolean that indicates whether or not autoÑforwarding is in effect. b)autoÑforwardÑrecipients: A sequence of O/R names that identify the users and DLs to which IPMs are being autoÑforwarded. c)autoÑforwardÑheading: The heading of each forwarding IPM provoked by autoÑforwarding. Its autoÑforwarded field has the value true. d)autoÑforwardÑcomment: The autoÑforward comment nonÑreceipt field of each NRN conveyed to the originator of an autoÑforwarded IPM. A UA shall perform the change autoÑforwarding abstract operation by recording the value of the autoÑforwardÑIPMs argument in the correspondingly named state variable. If the value is true, it also shall record the values of the autoÑforwardÑrecipients, autoÑforwardÑheading, and autoÑforwardÑcomment arguments in the correspondingly named state variables. 18.4 Invocation of reception operations A UA shall invoke that abstract operations available at its reception port as specified below. The UA alters none of its state variables in connection with its invocation of these operations. The UA invokes these operations in response to the MTS' invocation of the following abstract operations of the MTS abstract service (which, for the remainder of this paragraph, are unqualified as to their source): a)report delivery, b)message delivery. Note Ñ The abstract operation of a reception port report no errors. 18.4.1Receive report Whenever the MTS invokes report delivery at a UA's delivery port, the UA shall invoke the receive report abstract operation with the following arguments: a)Envelope: Report delivery's envelope argument. b)UndeliveredÑobject: Determined from report delivery's returnedÑcontent argument as specified in ¤Ê20.1. Note Ñ How the UA employs the contentÑidentifier component of report delivery's envelope argument is a local matter. 18.4.2 Receive IPM Whenever the MTS invokes message delivery at a UA's delivery port, and its content argument encodes an IPM as specified in ¤ 20.1, the UA shall invoke the receive IPM abstract operation with the following arguments, provided that the message is subject to neither autoÑforwarding nor autoÑdiscard (see ¤ 18.5): a)Envelope: Message delivery's envelope argument. b)Content: Determined from message delivery's content argument as specified in ¤ 20.1 (but no longer marked as an IPM). 18.4.3 Receive RN Whenever the MTS invokes message delivery at a UA's delivery port, and its content argument encodes in RN as specified in ¤ 20.1, the UA shall invoke the receive RN abstract operation with the following arguments: a)Envelope: Message delivery's envelope argument. b)Content: Determined from message delivery's content argument as specified in ¤ 20.1 (but no longer marked as an RN). 18.4.4 Receive NRN Whenever the MTS invokes message delivery at a UA's delivery port, and its content argument encodes an NRN as specified in ¤ 20.1, the UA shall invoke the receive NRN abstract operation with the following arguments: a)Envelope: Message delivery's envelope argument. b)Content: Determined from message delivery's content argument as specified in ¤ 20.1 (but no longer marked as an NRN). 18.5 Internal procedures A UA shall perform as specified below the internal procedures of autoÑdiscard, Ñacknowledgment, and Ñforwarding in ultimate fulfilment of the abstract operations available at its management port. The procedures involve the following abstract operations of the MTS abstract service (which, for the remainder of this paragraph, are unqualified as to their source): a)message submission, b)message delivery. As implied by the above, in the course of the procedures, the UA has occasion to invoke message submission. What it does with the results of this abstract operation is a local matter. The UA shall consider as a candidate for each procedure individually every message for which all of the following conditions hold: a)The MTS has conveyed the message to the UA by invoking message delivery at the UA's delivery port. b)The UA has not conveyed the message to the user by invoking receive IPM at the user's reception port. c)The message contains an IPM (rather than an IPN). Note Ñ With reference to item b) above, the message might be detained in the UA, e.g., as might be typical, because of the user's unavailability. 18.5.1 AutoÑdiscard The UA shall subject to autoÑdiscard each candidate message with respect to whose content either of the following conditions holds: a)The autoÑdiscardÑexpiresÑIPMs state variable has the value true and the date and time denoted by the IPM's expiry time field have past. b)The autoÑdiscardÑobsoleteÑIPMs state variable has the value true and another candidate IPM identifies the present candidate IPM by means of its obsoleted IPMs heading field. The UA shall autoÑdiscard each such message as follows. 18.5.1.1 Discard of IPM The UA shall discard the IPM, so as to never convey it to the user. 18.5.1.2 Construction of NRN The UA shall construct an NRN if, and only if, one is requested by means of the notificationÑrequests component of the IPM's subject recipient specifier. The NRN shall have the common fields prescribed for autoÑacknowledgment (see ¤ 18.5.2.1). The NRN shall have the following receipt fields: a)NonÑreceipt reason: The value ipmÑdiscarded. b)Discard reason: The value impÑexpired or ipmÑobsoleted, whichever applies. If both apply, either value may be specified. c)AutoÑforward comment: Omitted. d)Returned IPM: If the IPM's return is requested by means of the notificationÑrequests component of its subject recipient specifier, and the convertedÑencodedÑinformationÑtypes component of message delivery's envelope argument is absent, IPM. Omitted otherwise. 18.5.1.3 Submission of NRN The UA shall submit the NRN (if any) above by invoking message submission. Its envelope argument shall be as prescribed for autoÑacknowledgment (see ¤ 18.5.2.2), its content argument determined from the NRN as specified in ¤ 20.1. 18.5.2 AutoÑacknowledgment The UA shall subject to autoÑacknowledgment each candidate message with respect to whose content the following condition holds: a)The autoÑacknowledgment state variable has the value true and the IPM requests an RN of the UA's user by means of the notificationÑrequests component of the IPM's subject recipient specifier. The UA shall autoÑacknowledge each such message as follows. 18.5.2.1 Construction of RN The UA shall contruct an RN. The RN shall have the following common fields: a)Subject IPM: The IPM's This IPM heading field. b)IPN originator: Specified or omitted as a local matter (but, of course, in accordance with ¤ 8.1.2). c)IPM preferred recipient: The recipient component of the IPM's subject recipient specifier, unless its formalÑname component is the O/R name of the UA's user, in which case the field shall be omitted. d)Conversion EITs: ConvertedÑencodedÑinformationÑtypes component of message delivery's envelope argument. The RN shall have the following receipt field: a)Receipt time: The current date and time. b)Aknowledgment mode: The value automatic. c)Suppl receipt info: The autoÑacknowledgeÑsupplÑreceiptÑinfo state variable. 18.5.2.2 Submission of RN The UA shall submit the RN above by invoking message submission with the following arguments: a)Envelope: The components of this argument shall be as prescribed for performance of the originate RN abstract operation with the following exceptions: i)Priority: As specified by message delivery's envelope argument. ii) PerÑmessageÑindicators: A local matter, except that conversionÑprohibited shall be among the values specified. iii)PerÑrecipientÑfields: A single field whose recipientÑname component shall be the originatorÑname component of message delivery's envelope argument. Reports shall not be requested. b)Content: Determined from the RN as specified in ¤ 20.1. 18.5.3 AutoÑforwarding The UA shall subject to autoÑforwarding every candidate message, provided that the autoÑforwardÑIPMs state variable has the value true. The UA shall autoÑforward each such message as follows. 18.5.3.1 Prevention of loops The UA shall suppress autoÑforwarding if, and only if, the IPM to be forwarded itself contains a forwarding IPM that the UA previously created. AutoÑforwarding shall be suppressed whether the forwarding IPM appears (directly) in a message bodypart of the IPM to be forwarded, or (nested) in a message body part of the IPM that appears in such a body part. The UA shall consider itself to have created the forwarding IPM above (whose autoÑforwarded heading fields has the value true ) if, and only if, the originatorÑname component of the IPM's parameters component matches the O/R name of the UA's user. Note Ñ AutoÑforwarding an IPM of the kind described above would constitute an autoÑforwarding ÒloopÓ. 18.5.3.2 Construction of IPM The UA shall construct a forwarding IPM whose heading is the autoÑforwardÑheading state variable (its autoÑforwarded field having the value true) and whose body comprises a single body part of type message. The message body part shall have the following components: a)Parameters: The envelope argument of message delivery. b)Data: The IPM to be forwarded. 18.5.3.3 Submission of IPM The UA shall submit the IPM it constructed above by invoking message submission with the following arguments: a)Envelope: The components of this argument shall be as follows: i)OriginatorÑname: The O/R name of the UA's user. ii) ContentÑtype and originalÑencodedÑinformationÑtypes: Determined from the IPM as specified in ¤¤ 20.2 and 20.4. iii)ContentÑidentifier: Specified or omitted as a local matter. iv) Priority: As specified by message delivery's envelope argument. v)PerÑmessageÑindicators and extensions: A local matter. vi) DeferredÑdeliveryÑtime: Omitted. vii)PerÑrecipientÑfields: Their recipientÑname components shall be the O/R names that make up the autoÑforwardÑrecipients state variable. Their other components are a local matter. b)Content: Determined from the IPM as specified in ¤ 20.1. 18.5.3.4 Construction of NRN The UA shall construct an NRN if, and only if, one is requested by means of the notificationÑrequests component of the forwarded IPM's subject recipient specifier. The NRN shall have the common fields prescribed for the performance of autoÑacknowledgment. The NRN shall have the following receipt fields: a)NonÑreceipt reason: The value ipmÑautoÑforwarded. b)Discard reason: Omitted. c)AutoÑforward comment: The autoÑforwardÑcomment state variable. d)Returned IPM: If the IPM's return is requested by means of the notificationÑrequests component of its subject recipient specifier, and the convertedÑencodedÑinformation types component of message delivery's envelope argument is absent, the IPM. Omitted otherwise. 18.5.3.5 Submission of NRN The UA shall submit the NRN (if any) above by invoking message submission. Message submission's envelope argument shall be as prescribed for autoÑacknowledgment, its content argument determined from the NRN as specified in ¤ 20.1. 19 Message store operation An MS must perform certain interpersonal messagingÑspecific functions to qualify as an IPMS MS and thus distinguish itself from a generic MS. These functions are the subject of the present paragraph. 19.1 Creation of information objects An IPMS shall satisfy the following requirements related to the information objects it maintains: a)The MS shall maintain a separate information object for each (message containing an) IPM or IPN that is delivered to it. b)The MS shall maintain as a separate information object not only each (message containing a) forwarding IPM (pursuant to Item a)) but also each (message containing a) forwarded IPM (recursively). c)The MS shall assign sequence numbers depthÑfirst to the messages in the hierarchy formed by a forwarding IPM and its forwarded IPMs. Example Ñ If IPM A contains IPMs B and C among its body parts, and if IPM B contains IPMS D and E among its body parts, sequence numbers will be assigned to the IPMs in the following order: A, B, D, E, and C. 19.2 Maintenance of attributes An IPMS MS shall satisfy the following requirements related to MS attributes: a)For each IPM or IPN it holds, the MS shall support the attributes of Annex C as specified therein. b)For each IPM it holds, the MS shall give the following messages to the defined values of the MSÑstatus attribute: i)new: No attribute values have been conveyed to the UA. ii) listed: At least one attribute value has been conveyed to the UA, and at least one body part has not been conveyed. iii)processed: All body parts have been conveyed to the UA. c)For each IPN it holds, the MS shall give the following meanings to the defined values of the MSÑstatus attribute: i)new: No attribute values have been conveyed to the UA. ii) listed: At least one attribute value has been conveyed to the UA, and at least one attribute other than Returned IPM has not been conveyed. iii)processed: All attributes, with the possible exception of returned IPM, have been conveyed to the UA. d)The MSÑstatus attribute shall reflect the state of affairs prior to an abstract operation invocation that alters its value. e)The contentÑtype attribute of each (message containing an) IPM or IPN that is delivered to the MS shall have the value idÑmctÑp2Ñ1984 or idÑmctÑp2Ñ1988 (see Annex D), as appropriate, depending upon the content type of the delivered message (see ¤ 20.2). 19.3 Notification of nonÑreceipt When it discards an IPM while performing the delete abstract operation of the MS abstract service, the MS shall submit a NRN if one is requested and the IPM's MSÑstatus attribute has the value listed. 19.4 AutoÑforwarding An IPMS MS shall perform the autoÑforward action of Recommendation X.413 as specified in ¤ 18.5.3. It makes use of the otherÑparameters component of the autoÑforwardÑregistration argument of the register MS abstract operation of the MS abstract service. The data type of the otherÑparameters component is defined as follows: Forwarded Info ::= SET { autoÑforwardingÑcomment [0] AutoForwardComment OPTIONAL, coverÑnote [1] IA5TextBodyPart OPTIONAL, thisÑipmÑprefix [2] PrintableString (SIZE (1. .ubÑipmÑidentifierÑsuffix)) OPTIONAL } In addition, the MS shall satisfy the following requirements: a)Submit an NRN even if it retains a copy of the forwarded IPM. b)Draw the NRN's autoÑforward comment field, if any, from the otherÑparameters component. c)Draw the coverÑnote, if any, to be included with the forwarded IPM, from the otherÑparameters component. d)Prefix the userÑrelativeÑidentifier component of this IPM field of the forwarding IPM's heading with, if present, thisÑipmÑprefix. Note Ñ An (IPMS) MS performs neither autoÑdiscard nor autoÑacknowledgment, except possibly as a local matter. 19.5 Manual forwarding An IPMS shall support the manual forwarding of a message using the forwardingÑrequest extension of Recommedation X.413, as specified in ¤ 6.6. The IPMS MS user may submit an IPM, including heading and body, using the message submission operation, and identify by using the forwardingÑrequest extension a message that is already in the MS, and to be combined with the submitted message body for forwarding to the message's recipient. The submitted message body and the forwarded message are then combined by inserting the forwarded message as a message body part into the submitted message body. 20 Message contents As has already been seen, various secondary objects (e.g., UAs) have occasion to convey the information objects of section two as the contents of messages, as well as to convey probes concerning such messages. This paragraph specifies precisely how they shall do this. The rules governing the transmittal of such messages and probes, and the semantics and abstract and transfer syntaxes of their contents, are called the interpersonal messaging protocol (P2). Note Ñ The name ÒP2Ó reflects the historical fact that this was the second message handling protocol to be developed. 20.1 Content A secondary object that submits a message containing an IPM or IPN shall supply as the octets of the octet string that constitutes the content of the message the result of encoding the InformationObject of section two in accordance with the basic encoding rules of Recommendation X.209. 20.2 Content type A secondary object that submits a message containing an IPM or IPN shall select its content type as follows. If the IPM or IPN satisfies all of the following constraints, the Integer 2 shall be specified: i)The heading (of an IPM) lacks the extensions field. ii) The body (of an IPM) lacks externally defined body parts. iii) The parameters element of any videotex body part: . . . of (an IPM) lacks the syntax member. iv) Every component of the IPM or IPN that is a value of a data type defined as part of the MTS abstract service meets the constraints of Recommendation X.411 (1984). The types in question are those listed in the IMPORTS clause of the ASN.1 module defined in Annex E. The constraints in question are detailed in an annex of Recommendation X.419. v)The data element of any message body part (of an IPM) satisfies these same constraints (recursively). Otherwise, the Integer 22 shall be specified. Note 1 Ñ The message content protocol (here) denoted by the Integer 2 is identical to that specified by Recommendation X.420 (1984) (as clarified by Version 6 of the X.400Ñseries Implementor's Guide), except that the simple formattable document body part type, defined in the latter, is omitted from the former. Note 2 Ñ The Integer 2 is favoured, above, over the Integer 22 to foster interworking between systems conforming to this Recommendation and systems conforming (only) to Recommendation X.420 (1984). Note 3 Ñ The MTS does not convert between message content protocols. Thus it does not convert between P2 as defined by this Recommendation alone (and denoted by the Integer 22) and P2 as defined by both this Recommendation and Recommendation X.420 (1984) (and denoted by the Integer 2). 20.3 Content length A secondary object that submits a probe concerning a message containing an IPM or IPN shall specify as the length of the message's content the size in octets of the encoding of the instance in question of the InformationObject of Section 2 (a choice of an IPM or an IPN) when the basic encoding rules of Recommendation X.209 are followed. If those rules permit several (e.g., both primitive and constructed) encodings of that InformationObject, the content length may reflect any one of them. 20.4 Encoded information types A secondary object that submits a message containing an IPM or IPN shall specify the basic encoded information type (EITs) and nonÑbasic parameters (NBPs) of the message as follows. In the case of an IPN, the basic EITs shall be unspecified. In the case of an IPM, the basic EITs and NBPs shall be specified in accordance with the following rules: a)Multiple body parts: The basic EITs (if any) and NBPs (if any) of the message shall comprise the logical union of the basic EITs and NBPs of the IPM's individual body parts, respectively. b)(Forwarded) message body part: The basic EITs (if any) and NBPs (if any) of a message body part shall be those of the forwarded message. c)Externally defined body part: An externally defined body part whose extended type corresponds to a basic type (see Annex B) shall be treated in the manner prescribed for the basic type. Any other extended body part shall be handled as follows. If there corresponds to the type one or more externally defined EITs, they shall be specified. Otherwise, the undefined EIT shall be indicatd. In either case, no NBPs shall be specified. d)Basic body part: The basic EITs (if any) and NBPs (if any) of an individual body part of type other than message and externally defined shall depend upon that body part type as specified in Table 2/X.420. A body part type for which the table specifies no basic EITs shall result in the setting of no bits in the basic EITs bit string. e)Encrypted body part : The effect of an encrypted body part upon the basic EITs and NBPs to be specified is for further study. TABLE 2/X.420 Interpersonal messaging basic EITs and NBPs Body part type Basic EIT NBPs IA5 text IA5 text Ñ Voice Voice Ñ G3 facsimile G3 G3 facsimile facsimile G4 class 1 G4 class 1 G4 class 1/mixedÑmode Teletex Teletex Teletex Videotex Videotex Ñ Encrypted Message (see text) (see text) MixedÑmode MixedÑmode G4 class 1/mixedÑmode Bilaterally Undefined Ñ defined Nationally Undefined Ñ defined Externally (see text) (see text) defined 21 Port realization How an MS or the MTS concretely realizes the secondary ports it supplies is specified in Recommenda-tionÊX.419. How a UA, TLMA, or AU concretely realizes the primary ports it supplies is beyond the scope of this Recommendation. Note 1 Ñ A UA's user interface is a local matter. A wide variety of interfaces involving, e.g., a wide variety of input/output devices are possible. Note 2 Ñ A TLMA's realization of its primary ports is specified by Recommendation T.330. Note 3 Ñ An AU provides its primary ports by means of the particular communication system to which that AU provides access. 22 Conformance The requirements a secondary object (excluding the MTS) and its implementor shall meet when the latter claims the former's conformance to this Recommendation are identified below. A number of the conformance requirements distinguish between support upon origination and support upon reception. 22.1 Origination versus reception A UA, TLMA or AU shall be said to support upon origination a particular heading field, heading extension, basic body part type, or extended body part type if, and only if, it accepts, preserves, and emits, in full accord with this Recommendation, that particular heading field or extension, or body parts of that particular basic or extended type, whenever a user calls upon it to convey an IPM containing them to the MTS or the user's MS (the latter only in the case of a UA). A UA, TLMA, or AU shall be said to support upon reception a particular heading field, heading extension, basic body part type, or extended body part type if, and only if, it accepts, preserves, and emits, in full accord with this Recommendation, that particular heading field or extension, or body parts of that particular basic or extended type, whenever the MTS or a user's MS (the latter only in the case of a UA) calls upon it to convey to the user an IPM containing them. Note Ñ In point of fact, a PDAU supports nothing upon origination because it is not a supplier of the origination port. 22.2 Statement requirements The implementor of an IPMS, UA, IPMS MS, TLMA, or AU shall state the following. For each item below he shall make separate statements concerning conformance upon origination and conformance upon reception: a)The heading fields and heading extensions for which he claims conformance. b)The basic and extended body part types for which he claims conformance. c)In the case of an IPMS UA or IPMS MS, the interpersonal messagingÑspecific MS attributes for which it claims conformance. 22.3 Static requirements An IPMS UA, IPMS MS, TLMA or AU shall satisfy the following static requirements: a)An IPMS UA, IPMS MS, TLMA, or AU shall implement the heading fields and heading extensions, and the basic and extended body part types for which conformance is claimed. b)An IPMS UA or IPMS MS shall support the interpersonal messagingÑspecific MS attributes for which conformance is claimed, but including as a minimum those designated mandatory in Annex C. c)An IPMS UA, IPMS MS, TLMA, or AU shall concretely realize its abstract ports as specified in ¤ 21. d)An IPMS UA or IPMS MS shall be able to both submit and accept delivery of messages of both of the content types of ¤ 20.2. A TLMA or AU shall be able to both import and export such messages. 22.4 Dynamic requirements An IPMS UA, IPMS MS, TLMA, or AU shall satisfy the following dynamic requirements: a)An IPMS UA or IPMS MS shall follow the rules of operation specified in ¤ 18 or ¤ 19, respectively. b)An IPMS UA, IPMS MS, TLMA, or AU shall submit and accept delivery of messages whose contents are as specified in ¤ 20. c)An IPMS UA, IPMS MS, TLMA, or AU shall register with the MTS its ability to accept delivery of messages of both of the content types of ¤ 20.2. ANNEX A (to Recommendation X.420) Heading extensions This Annex is an integral part of this Recommendation. This Annex defines all (presently defined) heading extensions. A.1 Incomplete copy The incomplete copy heading extension, by its presence, indicates that one of more body parts or heading fields are absent from the body of (the present instance of) the IPM. The extension comprises a null (by default). IncompleteÑcopy HEADINGÑEXTENSION ::= idÑhexÑincomplete copy If this extension is absent from the extension heading field, all body parts shall be considered present. A.2 Languages The languages heading extension identifies the languages used in the composition of the IPM's subject heading field and body. The extension comprises a set of zero or more printable strings, each one of the twoÑcharacter language codes identified by ISO 639.2. languages HEADINGÑEXTENSION VALUE SET OF Language ::= idÑhexÑlanguages Language ::= PrintableString (SIZE (2. .2)) If this extension is absent from the extensions heading field or no languages are indicated, the languages shall be considered unspecified. ANNEX B (to Recommendation X.420) Extended body part types This Annex is an integral part of this Recommendation. For each basic body part type, this Recommendation defines as follows an equivalent extended body part type. ia5ÑtextÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS IA5TextParameters IDENTIFIED BY idÑepÑia5Ñtext DATA IA5TextData ::= idÑetÑia5Ñtext voiceÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS VoiceParameters IDENTIFIED BY idÑepÑvoice DATA VoiceData ::= idÑetÑvoice g3ÑfacsimileÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS G3FacsimileParameters IDENTIFIED BY idÑepÑg3Ñfacsimile DATA G3FacsimileData ::= idÑetÑg3Ñfacsimile g4Ñclass1ÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE DATA G4ClassBodyPart ::= idÑetÑg4Ñclass1 teletexÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS TeletexParameters IDENTIFIED BY idÑepÑteletex DATA TeletexData ::= idÑetÑteletex videotexÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS VideotexParameters IDENTIFIED BY idÑepÑvideotex DATA VideotexData ::= idÑetÑvideotex encryptedÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS EncryptedParameters IDENTIFIED BY idÑepÑencrypted DATA EncryptedData ::= idÑetÑencrypted messageÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS MessageParameters IDENTIFIED BY idÑepÑmessage DATA MessageData ::= idÑetÑmessage mixedÑmodeÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE DATA MixedModeBodyPart ::= idÑetÑmixedÑmode bilaterallyÑdefinedÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE DATA BilaterallyDefinedBodyPart ::= idÑetÑbilaterallyÑdefined nationallyÑdefinedÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE DATA NationallyDefinedBodyPart ::= idÑetÑnationallyÑdefined ANNEX C (to Recommendation X.420) Message store attributes This Annex is an integral part of this Recommendation. As described in Recommendation X.413, an MS maintains and provides access to certain attributes (e.g., the importance) of each information object it holds. An attribute comprises a type and, depending upon the type, one or more values. Attributes that may assume several values simultaneously (all pertaining to one object) are termed multiÑvalued; those that may assume just one value, singleÑvalued. Some attributes pertain to information objects of all kinds, others only to those of certain kinds (e.g., those of Section 2). This Annex defines the MS attributes specific to interpersonal messaging. All of the attributes defined in this Annex, except those corresponding to extended body part types (which cannot be enumerated; see ¤ C.3.6), are listed alphabetically, for reference, in the first column of Table CÑ1/X.420. This Table records their presence in a delivered message entry. None of them appears in either a delivered report entry or a returned content entry. See Recommendation X.413 for an elaboration of the Table's legend. C.1 Summary attributes Some attributes summarize an interpersonal messaging information object. These attributes are defined and described below. C.1.1IPM entry type The IPM entry type attribute identifies an information object's type. ipmÑentryÑtype ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IPMEntryType MATCHES FOR EQUALITY SINGLE VALUE ::= idÑsatÑipmÑentryÑtype IPMEntryType ::= ENUMERATED { ipm(0), rn(1), nrn(2) } This attribute may assume any one of the following values: a)ipm: The information object is an IPN. b)rn: The information object is an RN. c)nrn: The information object is an NRN. An MS that supports this attribute shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPM or IPN. TABLE CÑ1/X.420 Summary of MS attributes P Attribute V L NRN RN L S IPM Acknowledgement S O Ñ Ñ M Y Y mode Authorizing M O C Ñ Ñ Y N users AutoÑforward S O Ñ C Ñ Y N comment AutoÑforwarded S O C Ñ Ñ Y Y Bilaterally M O C Ñ Ñ N N defined body parts Blind copy M O C Ñ Ñ Y N recipients Body S M M Ñ Ñ N N Conversion EITs M O Ñ C C Y N Copy recipients M O C Ñ Ñ Y N Discard reason S O Ñ C Ñ Y Y Encrypted body M O C Ñ Ñ N N parts Encrypted data M O C Ñ Ñ N N Encrypted M O C Ñ Ñ N N parameters Expiry time S O C Ñ Ñ Y N Extended body M O C Ñ Ñ Y Y part types G3 facsimile M O C Ñ Ñ N N body parts G3 facsimile M O C Ñ Ñ N N data G3 facsimile M O C Ñ Ñ N N parameters G4 class 1 body M O C Ñ Ñ N N parts Heading S M M Ñ Ñ N N IA5 text body M O C Ñ Ñ N N parts IA5 text data M O C Ñ Ñ N N IA5 text M O C Ñ Ñ N N parameters Importance S O C Ñ Ñ Y Y Incomplete copy S O C Ñ Ñ Y N IPM entry type S M M M M Y Y IPM preferred S O Ñ C C Y N recipient IPM synopsis S O M Ñ Ñ N N IPM originator S O Ñ C C Y N Languages M O C Ñ Ñ Y N Message body M O C Ñ Ñ N N parts Message data M O C Ñ Ñ N N Message M O C Ñ Ñ N N parameters MixedÑmode body M O C Ñ Ñ N N parts Nationally M O C Ñ Ñ N N defined body parts NonÑreceipt S O Ñ M Ñ Y Y reason NRN requestors M O C Ñ Ñ Y N Obsoleted IPMs M O C Ñ Ñ Y N Originator S O C Ñ Ñ Y N TABLE CÑ1/X.420 (cont.) P Attribute V L IPM NRN RN L S Primary M O C Ñ Ñ Y N recipients Receipt time S O Ñ Ñ M Y N Related IPMs M O C Ñ Ñ Y N RepliedÑto IPM S O C Ñ Ñ Y N Reply recipients M O C Ñ Ñ Y N Reply requestors M O C Ñ Ñ Y N Reply time S O C Ñ Ñ Y N Returned IPM S O Ñ C Ñ Y N RN requestors M O C Ñ Ñ Y N Sensitivity S O C Ñ Ñ Y Y Subject S O C Ñ Ñ Y N Subject IPM S M Ñ M M Y N Suppl. receipt S O Ñ Ñ C Y N info Teletex body M O C Ñ Ñ N N parts Teletex data M O C Ñ Ñ N N Teletex M O C Ñ Ñ N N parameters This IPM S M M Ñ Ñ Y N Videotex body M O C Ñ Ñ N N parts Videotex data M O C Ñ Ñ N N Videotex M O C Ñ Ñ N N parameters Voice body parts M O C Ñ Ñ N N Voice data M O C Ñ Ñ N N Voice parameters M O C Ñ Ñ N N V Single/multi valued L Support level by MS and access UA P Presence in delivered message entry L Available for List, alert S Available for summarize C.1.2IPM synopsis The IPM synopsis attribute gives the structure, characteristics, size and processing status of an IPM at the granularity of individual body parts. ipmÑsynopsis ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IPMSynopsis SINGLE VALUE ::= idÑsatÑipmÑsynopsis The synopsis of an IPM comprises a synopsis of each of its body parts. The synopses appear in the order in which the body parts appear. IPMSynopsis ::= SEQUENCE OF BodyPartSynopsis The synopsis of a body part takes either of two forms depending upon whether the body part is of type message. This enables the synopsis of a forwarding IPM to encompass the body parts of each forwarded IPM (recursively), as well as those of the forwarding IPM itself. BodyPartSynopsis ::= CHOICE { message[0] MessageBodyPartSynopsis nonÑmessage [1] NonMessageBodyPartSynopsis } MessageBodyPartSynopsis ::= SEQUENCE { number [0] SequenceNumber, synopsis [1] IPMSynopsis } NonMessageBodyPartSynopsis ::= SEQUENCE { type [0] OBJECT IDENTIFIER, parameters [1] ExternallyDefinedParameters, size [2] INTEGER, processed [3] BOOLEAN DEFAULT FALSE } The synopsis of a message body part has the following components: a)Number (M): The sequence number that the MS assigns to the entry that the message body part represents. b)Synopsis (M): The synopsis of the IPM that forms the content of the message that the body part represents. The synopsis of a body part of type other than message has the following components. For purposes of this synopsis, the body part is considered to be of type externally defined, whether or not (see Annex B) it was so conveyed to the MS: a)Type (M): The body part's extended type, i.e., the directÑreference component of the body part's data component. An object identifier. b)Parameters (M): The body part's format and control parameters, i.e., the body part's parameters component. An Any. c)Size (M): The size in octets of the encoding of the Encoding component of the body part's Data component when the basic encoding rules of Recommendation X.209 are followed. If those rules permit several (e.g., both primitive and constructed) encodings of the component, the size may reflect any one of them. An Integer. d)Processed (D false): An indication of whether or not the body part has been conveyed to the UA by means of the MS' list or fetch abstract operation. A Boolean. An MS that supports this attribute shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPM. Note Ñ As a consequence of its variability, the value of the size component should be considered only an estimate of the body part's size. C.2 Heading attributes Some attributes are derived from the heading of an IPM. These attributes are defined and described below. C.2.1Heading The heading attribute is the (entire) heading of an IPM. heading ATTRIBUTE WITH ATTRIBUTEÑSYNTAX Heading SINGLE VALUE ::= idÑhatÑheading An MS that supports this attribute shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPM. C.2.2Heading analyses Some attributes have as their values O/R descriptors selected after analysis of the heading. They identify the ÒprimaryÓ, ÒcopyÓ, and blind ÒcopyÓ recipients of an IPM of whom an RN, NRN, or reply is requested. rnÑrequestors ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ORDescriptor MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑrnÑrequestors nrnÑrequestors ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ORDescriptor MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑnrnÑrequestors replyÑrequestors ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ORDescriptor MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑreplyÑrequestors An MS that supports one of these attributes shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPM whose heading requests, of at least one user, or DL, an RN, NRN, or reply, respectively. It shall maintain one attribute value for every recipient specifier in the IPM's primary, copy, or blind copy recipients field whose notificationÑrequests component includes the value rn (in the case of the first attribute) or nrn (in the case of the second, or whose ReplyÑrequested component signifies, by either its presence or its absence, that a reply is requested (in the case of the third). The value shall be the recipient's specifier's recipient component. C.2.3Heading fields Some attributes bear the names of heading fields and have those fields as their values. The ordering for the expiry time and reply time attributes is increasing chronological order. thisÑipm ATTRIBUTE WITH ATTRIBUTEÑSYNTAX This IPMField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑthisÑipm originator ATTRIBUTE WITH ATTRIBUTEÑSYNTAX OriginatorField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑoriginator repliedÑtoÑIPM ATTRIBUTE WITH ATTRIBUTEÑSYNTAX RepliedToIPMField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑrepliedÑtoÑIPM subject ATTRIBUTE WITH ATTRIBUTEÑSYNTAX SubjectField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= idÑhatÑsubject expiryÑtime ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ExpiryTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= idÑhatÑexpiryÑtime replyÑtime ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ReplyTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= idÑhatÑreplyÑtime importance ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ImportanceField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑimportance sensitivity ATTRIBUTE WITH ATTRIBUTEÑSYNTAX SensitivityField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑsensitivity autoÑforwarded ATTRIBUTE WITH ATTRIBUTEÑSYNTAX AutoForwardedField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑautoÑforwarded An MS that supports one of these attributes shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPM whose heading contains the field whose name the attribute bears. C.2.4Heading subÑfields Some attributes bear the names of heading fields and have subÑfields of those fields as their values. authorizingÑusers ATTRIBUTE WITH ATTRIBUTEÑSYNTAX AuthorizingUsersSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑauthorizingÑusers primaryÑrecipients; ATTRIBUTE WITH ATTRIBUTEÑSYNTAX PrimaryRecipientsSubField MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑprimaryÑrecipients copyÑrecipients ATTRIBUTE WITH ATTRIBUTEÑSYNTAX CopyRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑcopyÑrecipients blindÑcopyÑrecipients ATTRIBUTE WITH ATTRIBUTEÑSYNTAX BlindCopyRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑblindÑcopyÑrecipients obsoletedÑIPMs ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ObsoletedIPMsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑobsoletedÑIPMs relatedÑIPMs ATTRIBUTE WITH ATTRIBUTEÑSYNTAX RelatedIPMsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑrelatedÑIPMs replyÑrecipients ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ReplyRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑreplyÑrecipients An MS that supports one of these attributes shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPM whose heading contains the field whose name the attribute bears. It shall maintain one attribute value for each subÑfield. C.2.5Heading extensions Some attributes bear the names of heading extensions and have as their values the values of those extensions or a part thereof. incompleteÑcopy ATTRIBUTE WITH ATTRIBUTEÑSYNTAX incompleteCopyExtensionValue MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑincompleteÑcopy languages ATTRIBUTE WITH ATTRIBUTEÑSYNTAX Language MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑlanguages An MS that supports one of these attributes shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPM whose heading contains the extension whose name the attribute bears. In the case of the language attribute, the MS shall maintain one attribute value for each language the extension identifies. C.3 Body attributes Some attributes are derived from the body of an IPM. These attributes are defined and described below. C.3.1Body The body attribute is the (entire) body of an IPM. body ATTRIBUTE WITH ATTRIBUTEÑSYNTAX Body SINGLE VALUE ::= idÑbatÑbody An MS that supports this attribute shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPM. C.3.2Basic body parts Some attributes bear the names of basic body part types and have, with one exception, such body parts as their values. An MS holds each forwarded IPM (i.e., each message body part) as an information object in its own right, separate from the forwarding IPM. That information object, of course, is a message whose content is an IPM. The message body parts attribute below, therefore, has as its values the sequence numbers the MS assigns to these messages. ia5ÑtextÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IA5TextBodyPart MULTI VALUE ::= idÑbatÑia5ÑtextÑbodyÑparts voiceÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX VoiceBodyPart MULTI VALUE ::= idÑbatÑvoiceÑbodyÑparts g3ÑfacsimileÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX G3FacsimileBodyPart MULTI VALUE ::= idÑbatÑg3ÑfacsimileÑbodyÑparts g4Ñclass1ÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX G4Class1BodyPart MULTI VALUE ::= idÑbatÑg4Ñclass1ÑbodyÑparts teletexÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX TeletexBodyPart MULTI VALUE ::= idÑbatÑteletexÑbodyÑparts videotexÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX VideotexBodyPart MULTI VALUE ::= idÑbatÑvideotexÑbodyÑparts encryptedÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX EncryptedBodyPart MULTI VALUE ::= idÑbatÑencryptedÑbodyÑparts messageÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX SequenceNumber MULTI VALUE ::= idÑbatÑmessageÑbodyÑparts mixedÑmodeÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX MixedModeBodyPart MULTI VALUE ::= idÑbatÑmixedÑmodeÑbodyÑparts bilaterallyÑdefinedÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX BilaterallyDefinedBodyPart MULTI VALUE ::= idÑbatÑbilaterallyÑdefinedÑbodyÑparts nationallyÑdefinedÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX NationallyDefinedBodyPart MULTI VALUE ::= idÑbatÑnationallyÑdefinedÑbodyÑparts An MS that supports one of these attributes shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPM whose body contains one or more body parts of the type whose name the attribute bears. It shall maintain one attribute value for each such body part. C.3.3Basic body part parameters components Some attributes bear the names of basic body part types and have the parameters components of such body parts as their values. ia5ÑtextÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IA5TextParameters MULTI VALUE ::= idÑbatÑia5ÑtextÑparameters voiceÑtextÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IA5VoiceParameters MULTI VALUE ::= idÑbatÑvoiceÑparameters g3ÑfacsimileÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX G3FacsimileParameters MULTI VALUE ::= idÑbatÑg3ÑfacsimileÑparameters teletexÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX TeletexParameters MULTI VALUE ::= idÑbatÑteletexÑparameters videotexÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX VideotexParameters MULTI VALUE ::= idÑbatÑvideotexÑparameters encryptedÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX EncryptedParameters MULTI VALUE ::= idÑbatÑencryptedÑparameters messageÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX MessageParameters MULTI VALUE ::= idÑbatÑmessageÑparameters An MS that supports one of these attributes shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPM whose body contains one or more body parts of the type whose name the attribute bears. It shall maintain one attribute value for each such body part. C.3.4Basic body part data components Some attributes bear the names of basic body part types and have the data components of such body parts as their values. ia5ÑtextÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IA5TextData MULTI VALUE ::= idÑbatÑia5ÑtextÑdata voiceÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX VoiceData MULTI VALUE ::= idÑbatÑvoiceÑdata g3ÑfacsimileÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX G3FacsimileData MULTI VALUE ::= idÑbatÑg3ÑfacsimileÑdata teletexÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX TeletexData MULTI VALUE ::= idÑbatÑteletexÑdata videotexÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX VideotexData MULTI VALUE ::= idÑbatÑvideotexÑdata encryptedÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX EncryptedData MULTI VALUE ::= idÑbatÑencryptedÑdata messageÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX MessageData MULTI VALUE ::= idÑbatÑmessageÑdata An MS that supports one of these attributes shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPM whose body contains one or more body parts of the type whose name the attribute bears. It shall maintain one attribute for each such body part. C.3.5Extended body part types The extended body part types attribute identifies the extended body part types represented in an IPM. extendedÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX OBJECT IDENTIFIER MATCHES FOR EQUALITY MULTI VALUE ::= idÑbatÑextendedÑbodyÑparts An MS that supports this attribute shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPM whose body contains one or more externally defined body parts. It shall maintain one attribute value for every such type present. The value shall denote the type as specified in ¤ 7.3.12. Note Ñ Each value of this attribute corresponds to one of the attributes described in ¤ C.3.6 below. C.3.6Extended body parts Some attributes, unnamed, have as their values the encoding components (see ¤ 7.3.12) of the ASN.1 externals that constitute the data components of externally defined body parts. To each extended body part type there correspond two attributes. The first attribute is denoted by the object identifier that is the directÑreference component (again, see ¤ 7.3.12) of the external that constitutes the data component of a body part of that type. The content of this first attribute is that data component. The second attribute is denoted by the object identifier that is the directÑreference component of the external that constitutes the parameters component of a body part of that type. The content of this second attribute is that parameters component. An MS that supports one of these body parts shall maintain both attributes for an information object that it holds if, and only if, that object is a message whose content is an IPM whose body contains one or more body parts of the type that corresponds to that attribute. It shall maintain one value of each attribute for each such body part. Note 1 Ñ The extended body part attributes cannot be enumerated in practice because the extended body part types cannot be so enumerated. Note 2 Ñ The extended body part types attribute (see ¤ C.3.5) determines the extended body part attributes for a particular IPM. C.4 Notification attributes Some attributes are derived from an IPN. These attributes are defined and described below. C.4.1Common fields Some attributes that bear the names of common fields and have those fields as their values. subjectÑipm ATTRIBUTE WITH ATTRIBUTEÑSYNTAX SubjectIPMField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= idÑnatÑsubjectÑipm ipnÑoriginator ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IPNOriginatorField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑnatÑipnÑoriginator ipnÑpreferredÑrecipient ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IPMPreferredRecipientField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑnatÑipmÑpreferredÑrecipient conversionÑeits ATTRIBUTE WITH ATTRIBUTEÑSYNTAX MSÑEITs MATCHES FOR EQUALITY MULTI VALUE ::= idÑnatÑconversionÑeits An MS that supports one of these attributes shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an IPN that contains the field whose name the attribute bears. C.4.2NonÑreceipt fields Some attributes bear the names of nonÑreceipt fields and have those fields as their values. nonÑreceiptÑreason ATTRIBUTE WITH ATTRIBUTEÑSYNTAX NonReceiptReasonField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑnatÑnonÑreceiptÑreason discardÑreason ATTRIBUTE WITH ATTRIBUTEÑSYNTAX DiscardReasonField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑnatÑdiscardÑreason autoÑforwardÑcomment ATTRIBUTE WITH ATTRIBUTEÑSYNTAX AutoForwardCommentField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= idÑnatÑautoÑforwardÑcomment returnedÑIPM ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ReturnedIPMField SINGLE VALUE ::= idÑnatÑreturnedÑipm An MS that supports one of these attributes shall maintain it for an information that it holds if, and only if, that object is a message whose content is an NRN that contains the field whose name the attribute bears. C.4.3Receipt fields Some attributes bear the names of receipt fields and have those fields as their values. The ordering for the receipt time attribute is increasing chronological order. receiptÑtime ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ReceiptTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= idÑnatÑreceiptÑtime acknowledgment ATTRIBUTE WITH ATTRIBUTEÑSYNTAX AcknowledgmentModeField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑnatÑacknowledgmentÑmode supplÑreceiptÑinfo ATTRIBUTE WITH ATTRIBUTEÑSYNTAX SupplReceiptInfoField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= idÑnatÑsupplÑreceiptÑinfo An MS that supports one of these attributes shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an RN that contains the field whose name the attribute bears. ANNEX D (to Recommendation X.420) 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 subsequent Annexes. It uses ASN.1. 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 IPMS application itself. The definitive assignments for the former occur in the modules themselves; other references to them appear in IMPORT clauses. The latter is fixed. IMPSObjectIdentifiers {jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) objectÑidentifiers(0)} DEFINITIONS IMPLICIT TAGS ::= BEGIN ÑÑ Prologue ÑÑ Exports everything. IMPORTS ÑÑ nothing ÑÑ; ID ::= OBJECT IDENTIFIER ÑÑ Interpersonal Messaging (not definitive) idÑipms ID ::= {jointÑisoÑccitt mhsÑmotis(6) ipms(1)} Ñ Ñnot definitive ÑÑ Categories idÑmod ID ::= { idÑipms 0 } ÑÑ modules; not definitive idÑot ID ::= { idÑipms 1 } ÑÑ object types idÑpt ID ::= { idÑipms 2 } ÑÑ port types idÑref ID ::= { idÑipms 3 } ÑÑ refinements idÑet ID ::= { idÑipms 4 } ÑÑ extended body part types idÑhex ID ::= { idÑipms 5 } ÑÑ heading extensions idÑsat ID ::= { idÑipms 6 } ÑÑ summary attributes idÑhat ID ::= { idÑipms 7 } ÑÑ heading attributes idÑbat ID ::= { idÑipms 8 } ÑÑ body attributes idÑnat ID ::= { idÑipms 9 } ÑÑ notification attributes idÑmct ID ::= { idÑipms 10 } ÑÑ message content types idÑep ID ::= { idÑipms 11 } ÑÑ extended body part parameters ÑÑ Modules idÑmodÑobjectÑidentifiers ID ::= { idÑmod 0 } ÑÑ not definitive idÑmodÑfunctionalÑobjects ID ::= { idÑmod 1 } ÑÑ not definitive idÑmodÑinformationÑobjects ID ::= { idÑmod 2 } ÑÑ not definitive idÑmodÑabstractÑservice ID ::= { idÑmod 3 } ÑÑ not definitive idÑmodÑheadingÑextensions ID ::= { idÑmod 6 } ÑÑ not definitive idÑmodÑextendedÑbodyÑpartÑtypes ID ::= { idÑmod 7 } ÑÑ not definitive idÑmodÑmessageÑstoreÑattributes ID ::= { idÑmod 8 } ÑÑ not definitive idÑmodÑupperÑbounds ID ::= { idÑmod 10 } ÑÑ not definitive ÑÑ Object types idÑotÑipme ID ::= { idÑot 0 } idÑotÑipmsÑuser ID ::= { idÑot 1 } idÑotÑipms ID ::= { idÑot 2 } idÑotÑipmsÑua ID ::= { idÑot 3 } idÑotÑipmsÑms ID ::= { idÑot 4 } idÑotÑtlma ID ::= { idÑot 5 } idÑotÑtlxau ID ::= { idÑot 6 } idÑotÑpdau ID ::= { idÑot 7 } ÑÑ Port types idÑptÑorigination ID ::= { idÑpt 0 } idÑptÑreception ID ::= { idÑpt 1 } idÑptÑmanagement ID ::= { idÑpt 2 } ÑÑ Refinements idÑrefÑprimary ID ::= { idÑref 0 } idÑrefÑsecondary ID ::= { idÑref 1 } ÑÑ Extended body part types idÑetÑia5Ñtext ID ::= { idÑet 0 } idÑetÑvoice ID ::= { idÑet 1 } idÑetÑg3Ñfacsimile ID ::= { idÑet 2 } idÑetÑg4Ñclass1 ID ::= { idÑet 3 } idÑetÑteletex ID ::= { idÑet 4 } idÑetÑvideotex ID ::= { idÑet 5 } idÑetÑencrypted ID ::= { idÑet 6 } idÑetÑmessage ID ::= { idÑet 7 } idÑetÑmixedÑmode ID ::= { idÑet 8 } idÑetÑbilaterallyÑdefined ID ::= { idÑet 9 } idÑetÑnationallyÑdefined ID ::= { idÑet 10 } ÑÑ Heading extensions idÑhexÑincompleteÑcopy ID ::= { idÑhex 0 } idÑhexÑlanguages ID ::= { idÑhex 1 } ÑÑ Summary attributes idÑsatÑipmÑentryÑtype ID ::= { idÑsat 0 } idÑsatÑipmÑsynopsis ID ::= { idÑsat 1 } ÑÑ Heading attributes idÑhatÑheading ID ::= { idÑhat 0 } idÑhatÑthisÑipm ID ::= { idÑhat 1 } idÑhatÑoriginator ID ::= { idÑhat 2 } idÑhatÑrepliedÑtoÑIPM ID ::= { idÑhat 3 } idÑhatÑsubject ID ::= { idÑhat 4 } idÑhatÑexpiryÑtime ID ::= { idÑhat 5 } idÑhatÑreplyÑtime ID ::= { idÑhat 6 } idÑhatÑimportance ID ::= { idÑhat 7 } idÑhatÑsensitivity ID ::= { idÑhat 8 } idÑhatÑautoÑforwarded ID ::= { idÑhat 9 } idÑhatÑauthorizingÑusers ID ::= { idÑhat 10 } idÑhatÑprimaryÑrecipients ID ::= { idÑhat 11 } idÑhatÑcopyÑrecipients ID ::= { idÑhat 12 } idÑhatÑblindÑcopyÑrecipients ID ::= { idÑhat 13 } idÑhatÑobsoletedÑIPMs ID ::= { idÑhat 14 } idÑhatÑrelatedÑIPMs ID ::= { idÑhat 15 } idÑhatÑreplyÑrecipients ID ::= { idÑhat 16 } idÑhatÑincompleteÑcopy ID ::= { idÑhat 17 } idÑhatÑlanguages ID ::= { idÑhat 18 } idÑhatÑrnÑrequestors ID ::= { idÑhat 19 } idÑhatÑnrnÑrequestors ID ::= { idÑhat 20 } idÑhatÑreplyÑrequestors ID ::= { idÑhat 21 } ÑÑ Body attributes idÑbatÑbody ID ::= { idÑbat 0 } idÑbatÑia5ÑtextÑbodyÑparts ID ::= { idÑbat 1 } idÑbatÑvoiceÑbodyÑparts ID ::= { idÑbat 2 } idÑbatÑg3ÑfacsimileÑbodyÑparts ID ::= { idÑbat 3 } idÑbatÑg4Ñclass1ÑbodyÑparts ID ::= { idÑbat 4 } idÑbatÑteletexÑbodyÑparts ID ::= { idÑbat 5 } idÑbatÑvideotexÑbodyÑparts ID ::= { idÑbat 6 } idÑbatÑencryptedÑbodyÑparts ID ::= { idÑbat 7 } idÑbatÑmessageÑbodyÑparts ID ::= { idÑbat 8 } idÑbatÑmixedÑmodeÑbodyÑparts ID ::= { idÑbat 9 } idÑbatÑbilaterallyÑdefinedÑbodyÑparts ID ::= { idÑbat 10 } idÑbatÑnationallyÑdefinedÑbodyÑparts ID ::= { idÑbat 11 } idÑbatÑextendedÑbodyÑpartÑtypes ID ::= { idÑbat 12 } idÑbatÑia5ÑtextÑparameters ID ::= { idÑbat 13 } idÑbatÑvoiceÑparameters ID ::= { idÑbat 14 } idÑbatÑg3ÑfacsimileÑparameters ID ::= { idÑbat 15 } idÑbatÑteletexÑparameters ID ::= { idÑbat 16 } idÑbatÑvideotexÑparameters ID ::= { idÑbat 17 } idÑbatÑencryptedÑparameters ID ::= { idÑbat 18 } idÑbatÑmessageÑparameters ID ::= { idÑbat 19 } idÑbatÑia5ÑtextÑdata ID ::= { idÑbat 20 } idÑbatÑvoiceÑdata ID ::= { idÑbat 21 } idÑbatÑg3ÑfacsimileÑdata ID ::= { idÑbat 22 } idÑbatÑteletexÑdata ID ::= { idÑbat 23 } idÑbatÑvideotexÑdata ID ::= { idÑbat 24 } idÑbatÑencryptedÑdata ID ::= { idÑbat 25 } idÑbatÑmessageÑdata ID ::= { idÑbat 26 } ÑÑ Notification attributes idÑnatÑsubjectÑipm ID ::= { idÑnat 0 } idÑnatÑipnÑoriginator ID ::= { idÑnat 1 } idÑnatÑipmÑpreferredÑrecipient ID ::= { idÑnat 2 } idÑnatÑconversionÑeits ID ::= { idÑnat 3 } idÑnatÑnonÑreceiptÑreason ID ::= { idÑnat 4 } idÑnatÑdiscardÑreason ID ::= { idÑnat 5 } idÑnatÑautoÑforwardÑcomment ID ::= { idÑnat 6 } idÑnatÑreturnedÑipm ID ::= { idÑnat 7 } idÑnatÑreceiptÑtime ID ::= { idÑnat 8 } idÑnatÑacknowledgmentÑmode ID ::= { idÑnat 9 } idÑnatÑsupplÑreceiptÑinfo ID ::= { idÑnat 10 } ÑÑ Message content types (for use by MS only) idÑmctÑp2Ñ1984 ID ::= { idÑmct 0 } ÑÑ P2 1984 idÑmctÑp2Ñ1988 ID ::= { idÑmct 1 } ÑÑ P2 1988 ÑÑ Extended body part parameters idÑepÑia5Ñtext ID ::= { idÑep 0 } idÑepÑvoice ID ::= { idÑep 1 } idÑepÑg3Ñfacsimile ID ::= { idÑep 2 } idÑepÑteletex ID ::= { idÑep 4 } idÑepÑvideotex ID ::= { idÑep 5 } idÑepÑencrypted ID ::= { idÑep 6 } idÑepÑmessage ID ::= { idÑep 7 } END ÑÑ of IPMSObjectIdentifiers ANNEX E (to Recommendation X.420) Reference definition of abstract information objects This Annex is an integral part of this Recommendation. This Annex, a supplement to Section 2, defines for reference purposes the abstract information objects of interpersonal messaging. IPMSInformationObjects {jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) informationÑobjects(2) } DEFINITIONS IMPLICIT TAGS ::= BEGIN ÑÑ Prologue ÑÑ Exports everything. IMPORTS ÑÑ IPMS upper bounds ubÑautoÑforwardÑcomment, ubÑfreeÑformÑname, ubÑipmÑidentifierÑsuffix, ubÑlocalÑimpÑidentifier, ubÑsubjectÑfield, ubÑtelephoneÑnumber ÑÑÑÑ FROM IPMSUpperBounds { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) upperÑbounds(10) } ÑÑ DTAM ProtocolElement ÑÑÑÑ FROM dTAM ÑÑÑ MTS abstract service EncodedInformationTypes, G3FacsimileNonBasicParameters, MessageDeliveryTime, ORAddress, ORName, OtherMessageDeliveryFields, SupplementaryInformation, TeletexNonBasicParameters, ÑÑÑÑ FROM MTSAbstractService { jointÑisoÑccitt mhsÑmotis(6) mts(3) modules(0) mtsÑabstractÑservice(1) }; Time ::= UTCTime ÑÑ Information object InformationObject ::= CHOICE { ipm [0] IPM, ipn [1] IPN } ÑÑ IPM IPM ::= SEQUENCE { headingHeading, body Body } ÑÑ Heading Heading ::= SET { thisÑIPM ThisIPMField, originator [0] OriginatorField OPTIONAL, authorizingÑusers [1] AuthorizingUsersField OPTIONAL, primaryÑrecipients [2] PrimaryRecipientsField DEFAULT { }, copyÑrecipients [3] CopyRecipientsField DEFAULT { }, blindÑcopyÑrecipients [4] BlindCopyRecipientsField OPTIONAL, repliedÑtoÑIPM [5] RepliedToIPMField OPTIONAL, obsoletedÑIPMs [6] ObsoletedIPMsField DEFAULT { }, relatedÑIPMs [7] RelatedIPMsField DEFAULT { }, subject [8] EXPLICIT SubjectField OPTIONAL, expiryÑtime [9] ExpiryTimeField OPTIONAL, replyÑtime [10] ReplyTimeField OPTIONAL, replyÑrecipients [11] ReplyRecipientsField OPTIONAL, importance [12] ImportanceField DEFAULT normal, sensitivity [13] SensitivityField OPTIONAL, autoÑforwarded [14] AutoForwardedField DEFAULT FALSE, extensions [15] ExtensionsField DEFAULT { } } ÑÑ Heading component types IPMIdentifier ::= [APPLICATION 11] SET { user ORAddress OPTIONAL, userÑrelativeÑidentifier LocalIPMIdentifier } LocalIPMIdentifier ::= PrintableString (SIZE (0. .ubÑlocalÑipmÑidentifier)) RecipientSpecifier ::= SET { recipient [0] ORDescriptor, notificationÑrequests [1] NotificationRequests DEFAULT { }, replyÑrequested [2] BOOLEAN DEFAULT FALSE } NotificationRequests ::= BIT STRING { rn(0), nrn(1), ipmÑreturn(2) } ORDescriptor ::= SET { formalÑname ORName OPTIONAL, freeÑformÑname [0] FreeFormName OPTIONAL, telephoneÑnumber [1] TelephoneNumber OPTIONAL } FreeFormName ::= TeletexString (SIZE (0. .ubÑfreeÑformÑname)) TelephoneNumber ::= PrintableString (SIZE (0. .ubÑtelephoneÑnumber)) ÑÑ This IPM heading field This IPMField ::= IPMIdentifier ÑÑ Originator heading field OriginatorField ::= ORDescriptor ÑÑ Authorizing users heading field AuthorizingdUsersField ::= SEQUENCE OF AuthorizingUsersSubfield AuthorizingUsersSubfield ::= ORDescriptor ÑÑ Primary recipients heading field PrimaryRecipientsField ::= SEQUENCE OF PrimaryRecipientsSubfield PrimaryRecipientsSubfield ::= RecipientSpecifier ÑÑ Copy recipients heading field CopyRecipientsField ::= SEQUENCE OF CopyRecipientsSubfield CopyRecipientsSubfield ::= RecipientSpecifier ÑÑ Blind copy recipients heading field BlindCopyRecipientsField ::= SEQUENCE OF BlindCopyRecipientsSubfield BlindCopyRecipientsSubfield ::= RecipientSpecifier ÑÑ RepliedÑto IPM heading field RepliedToIPMField ::= IPMIdentifier ÑÑ Obsoleted IPMs heading field ObsoletedIPMsField ::= SEQUENCE OF ObsoletedIPMsSubfield ObsoletedIPMsSubfield ::= IPMIdentifier ÑÑ Related IPMs heading field RelatedIPMsField ::= SEQUENCE OF RelatedIPMsSubfield RelatedIPMsSubfield ::= IPMIdentifier ÑÑ Subfield heading field SubjectField ::= TeletexString (SIZE (0. .ubÑsubjectÑfield)) ÑÑ Expiry time heading field ExpiryÑTimeField ::= Time ÑÑ Reply time heading field ReplyTimeField ::= Time ÑÑ Reply recipient heading field ReplyRecipientsField ::= SEQUENCE OF ReplyRecipientsSubfield ReplyRecipientsSubfield ::= ORDescriptor ÑÑ Importance heading field ImportanceField ::= ENUMERATED { low (0), normal (1), high (2) } ÑÑ Sensitivity heading field SensitivityField ::= ENUMERATED { personal (1), private (2), companyÑconfidential (3) } ÑÑ AutoÑforwarded heading field AutoForwardedField ::= BOOLEAN ÑÑ Extensions heading field ExtensionsField ::= SET OF HeadingExtension HeadingExtension ::= SEQUENCE { type OBJECT IDENTIFIER, value ANY DEFINED BY type DEFAULT NULL NULL } HEADINGÑEXTENSION MACRO ::= BEGIN TYPE NOTATION ::= ÒVALUEÓ type | empty VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) END ÑÑ Body Body ::= SEQUENCE OF BodyPart BodyPart ::= CHOICE { ia5Ñtext [0] IA5TextBodyPart, voice [2] VoiceBodyPart, g3Ñfacsimile [3] G3FacsimileBodyPart, g4Ñclass1 [4] G4Class1BodyPart, teletex [5] TeletexBodyPart, videotex [6] VideotexBodyPart, encrypted [8] EncryptedBodyPart, message [9] MessageBodyPart, mixedÑmode [11] MixedModeBodyPart, bilaterallyÑdefined [14] BilaterallyDefinedBodyPart, nationallyÑdefined [7] NationallyDefinedBodyPart, externallyÑdefined [15] ExternallyDefinedBodyPart } ÑÑ IA5 text body part IA5TextBodyPart ::= SEQUENCE { parameters IA5TextParameters, data IA5TextData } IA5TextParameters ::= SET { repertoire [0] Repertoire DEFAULT ia5 } IA5TextData ::= IA5String Repertoire ::= ENUMERATED { ita2(2), ia5 (5) } ÑÑ Voice body part VoiceBodyPart ::= SEQUENCE { parameters VoiceParameters, data VoiceData } VoiceParameters ::= SET ÑÑ for further study VoiceData ::= BIT STRING ÑÑ for further study ÑÑ G3 Facsimile body part G3FacsimileBodyPart ::= SEQUENCE { parameters G3FacsimileParameters, data G3FacsimileData } G3FacsimileParameters ::= SET { numberÑofÑpages [0] INTEGER OPTIONAL, nonÑbasicÑparameters [1] G3FacsimileNonBasicParameters OPTIONAL } G3FacsimileData ::= SEQUENCE OF BIT STRING ÑÑ G4 class 1 and mixedÑmode body parts G4Class1BodyPart ::= SEQUENCE OF ProtocolElement MixedModeBodyPart ::= SEQUENCE OF ProtocolElement ÑÑ Telex body part TeletexBodyPart ::= SEQUENCE { parameters TeletexParameters, data TeletexData } TeletexParameters ::= SET { numberÑofÑpages [0] INTEGER OPTIONAL, telexÑcompatible [1] BOOLEAN DEFAULT FALSE, nonÑbasicÑparameters [2] TeletexNonBasicParameters OPTIONAL } TeletexData ::= SEQUENCE OF TeletexString ÑÑ Videotex body part VideotexBodyPart ::= SEQUENCE { parameters VideotexParameters, data VideotexData } VideotexParameters ::= SET { syntax [0] VideotexSyntax OPTIONAL VideotexSyntax ::= INTEGER ids (0), dataÑsyntax1 (1), dataÑsyntax2 (2), dataÑsyntax3 (3) } VideotexData ::= VideotexString ÑÑ Encrypted body part EncryptedBodyPart ::= SEQUENCE { parameters EncryptedParameters, data EncryptedData } EncryptedParameters ::= SET ÑÑ for further study EncryptedData ::= BIT STRING ÑÑ for further study ÑÑ Message body part MessageBodyPart ::= SEQUENCE { parameters MessageParameters, data MessageData } MessageParameters ::= SET { deliveryÑtime [0] MessageDeliveryTime OPTIONAL deliveryÑenvelope[1] OtherMessageDeliveryFields OPTIONAL } MessageData ::= IPM ÑÑ Bilaterally defined body part BilaterallyDefinedBodyPart ::= OCTET STRING ÑÑ Nationally defined body part NationallyDefinedBodyPart ::= ANY ÑÑ Externally defined body part ExternallyDefinedBodyPart ::= SEQUENCE { parameters [0] ExternallyDefinedParameters OPTIONAL, data ExternallyDefinedData } ExternallyDefinedParameters ::= EXTERNAL ExternallyDefinedData ::= EXTERNAL EXTENDEDÑBODYÑPARTÑTYPE MACRO ::= BEGIN TYPE NOTATION ::= Parameters Data VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) Parameters ::= ÒPARAMETERSÓ type ÒIDENTIFIEDÓ ÒBYÓ value (OBJECT IDENTIFIER) | empty Data ::= ÒDATAÓ type END ÑÑ IPN IPN ::= SET { ÑÑ commonÑfields ÑÑ COMPONENTS OF CommonFields, choice [0] CHOICE { nonÑreceiptÑfields [0] NonReceiptFields, receiptÑfields [1] ReceiptFields } } RN ::= IPN ÑÑ with receiptÑfields chosen NRN ::= IPN ÑÑ with nonÑreceiptÑfields chosen CommonFields ::= SET { subjectÑipn SubjectIPNFields, ipnÑoriginator [1] IPNOriginatorField OPTIONAL, ipnÑpreferredÑrecipient [2] IPNPreferredRecipientField OPTIONAL, conversionÑeits ConversionEITsField OPTIONAL } NonReceiptFields ::= SET { nonÑreceiptÑreason [0] NonReceiptReasonField, discardÑreason [1] DiscardReasonField OPTIONAL, autoÑforwardÑcomment [2] AutoForwardCommentField OPTIONAL, returnedÑipm [3] ReturnedIPNField OPTIONAL } ReceiptFields ::= SET { receiptÑtime [0] RecipientTimeField, acknowledgmentÑmode [1] AcknowledgementModeField DEFAULT manual, supplÑreceiptÑinfo [2] SupplReceiptInfoField DEFAULT Ò Ó } ÑÑ Common fields SubjectIPMField ::= IPMIdentifier IPMOriginatorField ::= ORDescriptor IPMPreferredRecipientField ::= ORDescriptor ConversionEITsField ::= EncodedInformationTypes ÑÑ NonÑreceipt fields NonReceiptReasonField ::= ENUMERATED { ipmÑdiscarded (0), ipmÑautoÑforwarded (1) } DiscardReasonField ::= ENUMERATED { ipmÑexpired (0), ipmÑobsoleted (1), userÑsubscriptionÑterminated (2) } AutoForwardCommentField ::= AutoForwardComment AutoForwardComment ::= PrintableString (SIZE (0. .ubÑautoÑforwardÑcomment)) ReturnedIPMField ::= IPM ÑÑ Receipt fields ReceiptTimeField ::= Time AcknowledgmentModeField ::= ENUMERATED { manual (0), automatic (1) } SupplReceiptInfoField/::= SupplementaryInformation ÑÑ Message store realization ForwardedInfo ::= SET { autoÑforwardingÑcomment [0] AutoForwardComment OPTIONAL, coverÑnote [1] IA5TextBodyPart OPTIONAL, thisÑipmÑprefix [2] PrintableString (SIZE (1. .ubÑipmÑidentifierÑsuffix)) OPTIONAL } END ÑÑ of IPMSInformationObjects ANNEX F (to Recommendation X.420) Reference definition of functional objects This Annex is an integral part of this Recommendation. This Annex, a supplement to ¤¤ 10, 11 and 16, defined for reference purposes the functional objects of interpersonal messaging. It uses the OBJECT and REFINE macros of Recommendation X.407. IPMFunctionalObjects { jointÑisoÑccitt mhsÑmotis(6) modules(0) functionalÑobjects(1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN ÑÑ Prologue ÑÑ Exports everything. IMPORTS ÑÑ IPMS abstract service management, origination, reception ÑÑÑÑ FROM IPMSAbstractService { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) abstractÑservice(3) } ÑÑ IPMS object identifiers idÑotÑipme, idÑotÑipms, idÑotÑipmsÑms, idÑotÑipmsÑua, idÑotÑipmsÑuser, idÑotÑpdau, idÑotÑtima, idÑotÑtlxau, idÑrefÑprimary, idÑrefÑsecondary ÑÑÑÑ FROM IPMSObjectIdentifiers { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) objectÑidentifiers(0) } TLMA abstract service miscellanea ÑÑÑÑ FROM TLMAAbsService { ccitt recommendation(0) t(20) 330 tlmaabsservice(0) } ÑÑ MS abstract service retrieval ÑÑÑÑ FROM MSAbstractService { jointÑisoÑccitt mhsÑmotis(6) ms(4) modules(0) abstractÑservice(1) } ÑÑ MTS abstract service administration, delivery, mTS, submission ÑÑÑÑ FROM MTSAbstractService { jointÑisoÑccitt mhsÑmotis(6) mts(3) modules(0) mtsÑabstractÑservice(1) } ÑÑ Abstract service definition conventions OBJECT, REFINE ÑÑÑÑ FROM AbstractServiceNotation { jointÑisoÑccitt mhsÑmotis(6) asdc(2) modules(0) notation(1) } ÑÑ ÒRootÓ object type ipme OBJECT ::= idÑotÑipme ÑÑ Primary refinement ipmeÑrefinement REFINE ipme AS ipms origination [S] PAIRED WITH ipmsÑuser reception [S] PAIRED WITH ipmsÑuser management [S] PAIRED WITH ipmsÑuser ipmsÑuser RECURRING ::= idÑrefÑprimary ÑÑ Primary object types ipmsÑuser OBJECT PORTS { origination [C], reception [C], management [C] } ::= idÑotÑipmsÑuser ipms OBJECT PORTS } origination [S], reception [S], management [S] } ::= idÑotÑipms ÑÑ Secondary refinement ipmsÑrefinement REFINE ipms AS mTS submission [S] PAIRED WITH ipmsÑua, ipmsÑms delivery [S] PAIRED WITH ipmsÑua, ipmsÑms administration [S] PAIRED WITH ipmsÑua, ipmsÑms ipmsÑua RECURRING origination [S] VISIBLE reception [S] VISIBLE management [S] VISIBLE ipmsÑms RECURRING submission [S] PAIRED WITH ipmsÑua retrieval [S] PAIRED WITH ipmsÑua administration [S] PAIRED WITH ipmsÑua tlma RECURRING origination [S] VISIBLE reception [S] VISIBLE management [S] VISIBLE tlxau RECURRING origination [S] VISIBLE reception [S] VISIBLE management [S] VISIBLE pdau RECURRING reception [S] VISIBLE ::= idÑrefÑsecondary ÑÑ Secondary objects ipmsÑua OBJECT PORTS { origination [S], reception [S], management [S], submission [C], delivery [C], retrieval [C], administration [C] } ::= idÑotÑipmsÑua ipmsÑms OBJECT PORTS { submission [S], retrieval [S], administration [S], submission [C], delivery [C], administration [C] } ::= idÑotÑipmsÑms tlma OBJECT PORTS { origination [S], reception [S], management [S], miscellanea [S] } ::= idÑotÑtlma tlxau OBJECT PORTS { origination [S], reception [S], management [S] } ::= idÑotÑtlxau pdau OBJECT PORTS { reception [S] ::= idÑotÑpdau END ÑÑ of IPMSFunctionalObjects ANNEX G (to Recommendation X.420) Reference definition of abstract service This Annex is an integral part of this Recommendation. This Annex, a supplement to ¤¤ 12 and 13, defines for reference purposes the IPMS abstract service. It uses the PORT and ABSTRACTÑOPERATION and ÑERROR macros of Recommendation X.407. IPMSAbstractService { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) abstractÑservice(3) } DEFINITIONS IMPLICIT TAGS ::= BEGIN ÑÑ Prologue ÑÑ Exports everything. IMPORTS ÑÑ IPMS information objects AutoForwardComment, Heading, IPM, NRN, RN ÑÑÑÑ FROM IPMSInformationObjects { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) informationÑobjects(2) } ÑÑ IPMS object identifiers idÑptÑmanagement, idÑptÑorigination, idÑptÑreception ÑÑÑÑ FROM IPMSObjectsIdentifiers { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) objectsÑidentifiers(0) } ÑÑ MTS abstract service MessageDeliveryEnvelope, MessageSubmissionEnvelope, MessageSubmissionIdentifier, MessageSubmissionTime, ProbeSubmissionEnvelope, ProbeSubmissionIdentifier, ProbeSubmissionTime, RecipientImproperlySpecified, ReportDeliveryEnvelope, ÑÑÑÑ FROM MTSAbstractService { jointÑisoÑccitt mhsÑmotis(6) mts(3) modules(0) mtsÑabstractÑservice(1) } ÑÑ Abstract service definition conventions ABSTRACTÑERROR, ABSTRACTÑOPERATION, PORT ÑÑÑÑ FROM AbstractServiceNotation { jointÑisoÑccitt mhsÑmotis(6) asdc(2) modules(0) notation(1) }; Time ::= UTCTime ÑÑ Ports origination PORT CONSUMER INVOKES { OriginateProbe, OriginateIPM, OriginateRN } ::= idÑptÑorigination reception PORT SUPPLIER INVOKES { ReceiveReport, ReceiveIPM, ReceiveRN, ReceiveNRN } ::= idÑptÑreception management PORT CONSUMER INVOKES { ChangeAutoDiscard, ChangeAutoAcknowledgment, ChangeAutoForwarding } ::= idÑptÑmanagement ÑÑ Origination abstract operations OriginateProbe ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] ProbeSubmissionEnvelope, content [1] IPM } RESULT SET { submissionÑidentifier [0] ProbeSubmissionIdentifier, submissionÑtime [1] ProbeSubmissionTime } ERRORS { SubscriptionError, RecipientImproperlySpecified } OriginateIPM ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] MessageSubmissionEnvelope, content [1] IPM } RESULT SET { submissionÑidentifier [0] MessageSubmissionIdentifier, submissionÑtime [1] MessageSubmissionTime } ERROR { SubscriptionError, RecipientImproperlySpecified } OriginateRN ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] MessageSubmissionEnvelope, content [1] RN } RESULT SET { submissionÑidentifier [0] MessageSubmissionIdentifier, submissionÑtime [1] MessageSubmissionTime } ERROR { SubscriptionError, RecipientImproperlySpecified } ÑÑ Reception abstract operations ReceiptReport ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] ReportDeliveryEnvelope, undeliveredÑobject [1] InformationObject OPTIONAL } RESULT ERRORS { } ReceiveIPM ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] MessageDeliveryEnvelope, content [1] IPM } RESULT ERRORS { } ReceiveRN ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] MessageDeliveryEnvelope, content [1] RN } RESULT ERRORS { } ReceiveNRN ::= ABSTRACTÑOPERATION ARGUMENT SET { envelope [0] MessageDeliveryEnvelope, content [1] NRN } RESULT ERRORS { } ÑÑ Management abstract operations ChangeAutoDiscard ::= ABSTRACTÑOPERATION ARGUMENT SET { autoÑdiscardÑexpiredÑIPMs [0] BOOLEAN, autoÑdiscardÑobsoleteÑIPMs [1] BOOLEAN } RESULT ERRORS { } ChangeAutoAcknowledgement ::= ABSTRACTÑOPERATION ARGUMENT SET { autoÑacknowledgeÑIPMs [0] BOOLEAN, autoÑacknowledgeÑsupplÑreceiptÑinfo [1] SupplementaryInformation } RESULT ERRORS { SubscriptionError } ChangeAutoForwarding ::= ABSTRACTÑOPERATION ARGUMENT SET { autoÑforwardÑIPMs [0] BOOLEAN, autoÑforwardÑrecipients [1] SEQUENCE OF ORName OPTIONAL, autoÑforwardÑheading [2] Heading OPTIONAL, autoÑforwardÑcomment [3] AutoForwardComment OPTIONAL } RESULT ERRORS { SubscriptionError, RecipientImproperlySpecified } ÑÑ Abstract errors SubscriptionError ::= ABSTRACTÑERROR PARAMETER SET { problem [0] SubscriptionProblem } SubscriptionProblem ::= ENUMERATED { ipmsÑeosÑnotÑsubscribed (0), mtsÑeosÑnotÑsubscribed (1) } END ÑÑ of IPMSAbstractService ANNEX H (to Recommendation X.420) Reference definition of heading extensions This Annex is an integral part of this Recommendation. This Annex, a supplement to Annex A, defines for reference purposes the heading extensions defined for interpersonal messaging. It uses the HEADINGÑEXTENSION macro of ¤ 12.2.17. IPMSHeadingExtensions { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) headingÑextensions(6) } DEFINITIONS IMPLICIT TAGS ::= BEGIN ÑÑ Prologue ÑÑ Exports everything. IMPORTS ÑÑ IPMS information objects HEADINGÑEXTENSION ÑÑÑÑ FROM IPMSInformationObjects { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) informationÑobjects(2) }; ÑÑ IPMS object identifiers idÑhexÑincompleteÑcopy, idÑhexÑlanguages ÑÑÑÑ FROM IPMSObjectsIdentifiers { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) objectsÑidentifiers(0) }; ÑÑ Incomplete copy Incomplete copy HEADINGÑEXTENSION ::= idÑhexÑincompleteÑcopy IncompleteCopy::= NULL ÑÑ Languages languages HEADINGÑEXTENSION VALUE SET OF Language ::= idÑhexÑlanguages Language ::= PrintableString (SIZE (2. .2)) END ÑÑ of IPMSHeadingExtensions ANNEX I (to Recommendation X.420) Reference definition of extended body part types This Annex is an integral part of this Recommendation. This Annex, a supplement to Annex B, defines for reference purposes certain extended body part types. IPMSExtendedBodyPartTypes {jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) extendedÑbodyÑpartÑtypes(7)} DEFINITIONS IMPLICIT TAGS ::= BEGIN ÑÑ Prologue ÑÑ Exports everything. IMPORTS ÑÑ IPMS information objects BilaterallyDefinedBodyPart, EncryptedData, EncryptedParameters, EXTENDEDÑBODYÑPARTÑTYPE, G3FacsimileData, G3FacsimileParameters, G4Class1BodyPart, IA5TextData, IA5TextParameters, MessageData, MessageParameters, MixedModeBodyPart, NationallyDefinedBodyPart,TeletexData, TeletexParameters, VideotexData, VideotexParameters, VoiceData, VoiceParameters ÑÑÑÑ FROM IPMSInformationObjects {jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) informationÑobjects(2)} ÑÑ IPMS object identifiers idÑepÑencrypted, idÑepÑg3Ñfacsimile, idÑepÑia5Ñtext, idÑepÑmessage, idÑepÑteletex, idÑepÑvideotex, idÑepÑvoice, idÑetÑbilaterallyÑdefined, idÑetÑencrypted, idÑetÑg3Ñfacsimile, idÑetÑg4Ñclass1, idÑetÑia5Ñtext, idÑetÑmessage, idÑetÑmixedÑmode, idÑetÑnationallyÑdefined, idÑetÑteletex, idÑetÑvideotex, idÑetÑvoice ÑÑÑÑ FROM IPMSObjectsIdentifiers {jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) objectsÑidentifiers(0)} ÑÑ Extended IA5 text body part ia5ÑtextÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS IA5TextParameters IDENTIFIED BY idÑepÑia5Ñtext DATA IA5TextData ::= idÑetÑia5Ñtext ÑÑ Extended voice body part voiceÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS VoiceParameters IDENTIFIED BY idÑepÑvoice DATA VoiceData ::= idÑetÑvoice ÑÑ Extended G3 facsimile body part g3ÑfacsimileÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS G3FacsimileParameters IDENTIFIED BY idÑepÑg3Ñfacsimile DATA G3FacsimileData ::= idÑetÑg3Ñfacsimile ÑÑ Extended G4 class 1 body part g4Ñclass1ÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE DATA G4Class1BodyPart ::= idÑetÑg4Ñclass1 ÑÑ Extended teletex body part teletexÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS TeletexParameters IDENTIFIED BY idÑepÑteletex DATA TeletexData ::= idÑetÑteletex ÑÑ Extended videotex body part videotexÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS VideotexParameters IDENTIFIED BY idÑepÑvideotex DATA VideotexData ::= idÑetÑvideotex ÑÑ Extended encrypted body part encryptedÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS EncryptedParameters IDENTIFIED BY idÑepÑencrypted DATA EncryptedData ::= idÑetÑencrypted ÑÑ Extended message body part messageÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE PARAMETERS MessageParameters IDENTIFIED BY idÑepÑmessage DATA MessageData ::= idÑetÑmessage ÑÑ Extended mixedÑmode body part mixedÑmodeÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE DATA MixedModeBodyPart ::= idÑetÑmixedÑmode ÑÑ Extended bilaterally defined body part bilaterallyÑdefinedÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE DATA BilaterallyDefinedBodyPart ::Ñ idÑetÑbilaterallyÑdefined ÑÑ Extended nationally defined body part nationallyÑdefinedÑbodyÑpart EXTENDEDÑBODYÑPARTÑTYPE DATA NationallyDefinedBodyPart ::Ñ idÑetÑnationallyÑdefined END ÑÑ of IPMSExtendedBodyPartTypes ANNEX J (to Recommendation X.420) Reference definition of message store attributes This Annex is an integral part of this Recommendation. This Annex, a supplement to Annex C, defines for reference purposes the MS attributes specific to interpersonal messaging. It uses the ATTRIBUTE macro of Recommendation X.500. IPMSMessageStoreAttributes { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) messageÑstoreÑattributes(8) } DEFINITIONS IMPLICIT TAGS ::= BEGIN ÑÑ Prologue ÑÑ Exports everything. IMPORTS ÑÑ IPMS heading extensions IncompleteCopy, Language ÑÑÑÑ FROM IPMSHeadingExtensions { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) headingÑextensions(6) } ÑÑ IPMS information objects AcknowledgmentModeField, AuthorizingUsersSubfield, AutoForwardCommentField, AutoForwardedField, BilaterallyDefinedBodyPart, BlindCopyRecipientsSubfield, Body, ConversionEITsField, CopyRecipientsSubfield, DiscardReasonField, EncryptedBodyPart, EncryptedData, EncryptedParameters, ExpiryTimeField, ExternallyDefinedParameters, G3FacsimileBodyPart, G3FacsimileData, G3FacsimileParameters, G4Class1BodyPart, Heading, IA5TextBodyPart, IA5TextData, IA5TextParameters, ImportanceField, IPMPreferredRecipientField, IPNOriginatorField, MessageBodyPart, MessageData, MessageParameters, MixedModeBodyPart, NationallyDefinedBodyPart, NonReceiptReasonField, ObsoletedIPMsSubfield, ORDescriptor, OriginatorField, PrimaryRecipientsSubfield, ReceiptTimeField, RelatedIPMsSubfield, RepliedToIPMField, ReplyRecipientsSubfield, ReplyTimeField, ReturnedIPMField, SensitivityField, SubjectField, SubjectIPMField, SupplReceiptInfoField, TeletexBodyPart, TeletexData, TeletexParameters, ThisIPMField, VideotexBodyPart, VideotexData, VideotexParameters, VoiceBodyPart, VoiceData, VoiceParameters ÑÑÑÑ FROM IPMSInformationObjects { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) informationÑobjects(2) } ÑÑ IPMS object identifiers idÑbatÑbilaterallyÑdefinedÑbodyÑparts, idÑbatÑbody, idÑbatÑencryptedÑbodyÑparts, idÑbatÑencryptedÑdata, idÑbatÑencryptedÑparameters, idÑbatÑextendedÑbodyÑpartÑtypes, idÑbatÑg3ÑfacsimileÑbodyÑparts, idÑbatÑg3ÑfacsimileÑdata, idÑbatÑg3ÑfacsimileÑparameters, idÑbatÑg4Ñclass1ÑbodyÑparts, idÑbatÑia5ÑtextÑbodyÑparts, idÑbatÑia5ÑtextÑdata, idÑbatÑia5ÑtextÑparameters, idÑbatÑmessageÑbodyÑparts, idÑbatÑmessageÑdata, idÑbatÑmessageÑparameters, idÑbatÑmixedÑmodeÑbodyÑparts, idÑbatÑnationallyÑdefinedÑbodyÑparts, idÑbatÑteletexÑbodyÑparts, idÑbatÑteletexÑdata, idÑbatÑteletexÑparameters, idÑbatÑvideotexÑbodyÑparts, idÑbatÑvideotexÑdata, idÑbatÑvideotexÑparameters, idÑbatÑvoiceÑbodyÑparts, idÑbatÑvoiceÑdata, idÑbatÑvoiceÑparameters, idÑhatÑauthorizingÑusers, idÑhatÑautoÑforwarded, idÑhatÑblindÑcopyÑrecipients, idÑhatÑcopyÑrecipients, idÑhatÑexpiryÑtime, idÑhatÑheading, idÑhatÑimportance, idÑhatÑincompleteÑcopy, idÑhatÑlanguages, idÑhatÑnrnÑrequestors, idÑhatÑobsoletedÑIPMs, idÑhatÑoriginator, idÑhatÑprimaryÑrecipients, idÑhatÑrelatedÑIPMs, idÑhatÑrepliedÑtoÑIPM, idÑhatÑreplyÑrecipients, idÑhatÑreplyÑrequestors, idÑhatÑreplyÑtime idÑhatÑrnÑrequestors, idÑhatÑsensitivity, idÑhatÑsubject, idÑhatÑthisÑipm, idÑnatÑacknowledgmentÑmode, idÑnatÑautoÑforwardÑcomment, idÑnatÑconversionÑeits, idÑnatÑdiscardÑreason, idÑnatÑipmÑpreferredÑrecipient, idÑnatÑipnÑoriginator, idÑnatÑnonÑreceiptÑreason, idÑnatÑreceiptÑtime, idÑnatÑreturnedÑipm, idÑnatÑsubjectÑipm, idÑnatÑsupplÑreceiptÑinfo, idÑsatÑipmÑentryÑtype, idÑsatÑipmÑsynopsis ÑÑÑÑ FROM IPMSObjectIdentifiers { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) objectÑidentifiers(0) } ÑÑ MS abstract service MSÑEITs, SequenceNumber ÑÑÑÑ FROM MSAbstractService { jointÑisoÑccitt mhsÑmotis(6) ms(4) modules(0) abstractÑservice(1) } ÑÑ MTS abstract service EncodedInformationTypes ÑÑÑÑ FROM MTSAbstractService { jointÑisoÑccitt mhsÑmotis(6) mts(3) modules(0) mtsÑabstractÑservice(1) }; ÑÑ Directory information framework ATTRIBUTE ÑÑÑÑ FROM InformationFramework { jointÑisoÑccitt ds(5) modules(1) informationFramework(1) }; Time ::= UTCTime ÑÑ SUMMARY ATTRIBUTES ÑÑ IPM entry type ipmÑentryÑtype ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IPMEntryType MATCHES FOR EQUALITY SINGLE VALUE ::= idÑsatÑipmÑentryÑtype IPMEntryType ::= ENUMERATED { ipm (0), rn (1), nrn (2) } ÑÑ IPM synopsis ipmÑsynopsis ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IPMSynopsis SINGLE VALUE ::= idÑsatÑipmÑsynopsis IPMSynopsis ::= SEQUENCE OF BodyPartSynopsis BodyPartSynopsis ::= CHOICE { messsage [0] MessageBodyPartSynopsis, nonÑmesssage [1] NonMessageBodyPartSynopsis } MessageBodyPartSynopsis ::= SEQUENCE { number [0] SequenceNumber, synopsis [1] IPMSynopsis } NonMessageBodyPartSynopsis ::= SEQUENCE { type [0] OBJECT IDENTIFIER, parameters [1] ExternallyDefinedParameters, size [2] INTEGER, processed [3] BOOLEAN DEFAULT FALSE } ÑÑ HEADING ATTRIBUTES ÑÑ Heading heading ATTRIBUTE WITH ATTRIBUTEÑSYNTAX Heading SINGLE VALUE ::= idÑhatÑheading ÑÑ Heading analyses rnÑrequestors ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ORDescriptor MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑrnÑrequestors nrnÑrequestors ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ORDescriptor MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑnrnÑrequestors replyÑrequestors ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ORDescriptor MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑreplyÑrequestors ÑÑ Heading fields thisÑipm ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ThisIPMField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑthisÑipm originator ATTRIBUTE WITH ATTRIBUTEÑSYNTAX OriginatorField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑoriginator repliedÑtoÑIPM ATTRIBUTE WITH ATTRIBUTEÑSYNTAX RepliedToIPMField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑrepliedÑtoÑIPM subject ATTRIBUTE WITH ATTRIBUTEÑSYNTAX SubjectField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= idÑhatÑsubject expiryÑtime ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ExpiryTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= idÑhatÑexpiryÑtime replyÑtime ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ReplyTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= idÑhatÑreplyÑtime importance ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ImportanceField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑimportance sensitivity ATTRIBUTE WITH ATTRIBUTEÑSYNTAX SensitivityField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑsensitivity autoÑforwarded ATTRIBUTE WITH ATTRIBUTEÑSYNTAX AutoForwardedField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑautoÑforward ÑÑ Heading subÑfields authorizingÑusers ATTRIBUTE WITH ATTRIBUTEÑSYNTAX AuthorizingÑUsersSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑauthorizingÑusers primaryÑrecipients ATTRIBUTE WITH ATTRIBUTEÑSYNTAX PrimaryRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑprimaryÑrecipients copyÑrecipients ATTRIBUTE WITH ATTRIBUTEÑSYNTAX CopyRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑcopyÑrecipients blindÑcopyÑrecipients ATTRIBUTE WITH ATTRIBUTEÑSYNTAX BlindCopyRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑblindÑcopyÑrecipients obsoletedÑIPMs ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ObsoletedIPMsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑobsoletedÑIPMs relatedÑIPMs ATTRIBUTE WITH ATTRIBUTEÑSYNTAX RelatedIPMsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑrelatedÑIPMs replyÑrecipients ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ReplyRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑreplyÑrecipients ÑÑ Heading extensions incompleteÑcopy ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IncompleteCopy MATCHES FOR EQUALITY SINGLE VALUE ::= idÑhatÑincompleteÑcopy languages ATTRIBUTE WITH ATTRIBUTEÑSYNTAX Language MATCHES FOR EQUALITY MULTI VALUE ::= idÑhatÑlanguages ÑÑ BODY ATTRIBUTES ÑÑ Body body ATTRIBUTE WITH ATTRIBUTEÑSYNTAX Body SINGLE VALUE ::= idÑbatÑbody ÑÑ Basic body parts ia5ÑtextÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IA5TextBodyParts MULTI VALUE ::= idÑbatÑia5ÑtextÑbodyÑparts voiceÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX VoiceBodyPart MULTI VALUE ::= idÑbatÑvoiceÑbodyÑparts g3ÑfacsimileÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX G3FacsimileBodyPart MULTI VALUE ::= idÑbatÑg3ÑfacsimileÑbodyÑparts g4Ñclass1ÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX G4Class1BodyPart MULTI VALUE ::= idÑbatÑg4Ñclass1ÑbodyÑparts teletexÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX TeletexBodyPart MULTI VALUE ::= idÑbatÑteletexÑbodyÑparts videotexÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX VideotexBodyPart MULTI VALUE ::= idÑbatÑvideotexÑbodyÑparts encryptedÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX EncryptedBodyPart MULTI VALUE ::= idÑbatÑencryptedÑbodyÑparts messageÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX SequenceNumber MULTI VALUE ::= idÑbatÑmessageÑbodyÑparts mixedÑmodeÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX MixedModeBodyPart MULTI VALUE ::= idÑbatÑmixedÑmodeÑbodyÑparts bilaterallyÑdefinedÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX BilaterallyDefinedBodyPart MULTI VALUE ::= idÑbatÑbilaterallyÑdefinedÑbodyÑparts nationallyÑdefinedÑbodyÑparts ATTRIBUTE WITH ATTRIBUTEÑSYNTAX NationallyDefinedBodyPart MULTI VALUE ::= idÑbatÑnationallyÑdefinedÑbodyÑparts ÑÑ Basic body part parameters component ia5ÑtextÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IA5TextParameters MULTI VALUE ::= idÑbatÑia5ÑtextÑparameters voiceÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX VoiceParameters MULTI VALUE ::= idÑbatÑvoiceÑparameters g3ÑfacsimileÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX G3FacsimileParameters MULTI VALUE ::= idÑbatÑg3ÑfacsimileÑparameters teletexÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX TeletexParameters MULTI VALUE ::= idÑbatÑteletexÑparameters videotexÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX VideotexParameters MULTI VALUE ::= idÑbatÑvideotexÑparameters encryptedÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX EncryptedParameters MULTI VALUE ::= idÑbatÑencryptedÑparameters messageÑparameters ATTRIBUTE WITH ATTRIBUTEÑSYNTAX MessageParameters MULTI VALUE ::= idÑbatÑmessageÑparameters ÑÑ Basic body part data components ia5ÑtextÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IA5TextData MULTI VALUE ::= idÑbatÑia5ÑtextÑdata voiceÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX VoiceÑData MULTI VALUE ::= idÑbatÑvoiceÑdata g3ÑfacsimileÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX G3FacsimileData MULTI VALUE ::= idÑbatÑg3ÑfacsimileÑdata teletexÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX TeletexData MULTI VALUE ::= idÑbatÑteletexÑdata videotexÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX VideotexData MULTI VALUE ::= idÑbatÑvideotexÑdata encryptedÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX EncryptedData MULTI VALUE ::= idÑbatÑencryptedÑdata messageÑdata ATTRIBUTE WITH ATTRIBUTEÑSYNTAX MessageData MULTI VALUE ::= idÑbatÑmessageÑdata ÑÑ Extended body part types extendedÑbodyÑpartÑtypes ATTRIBUTE WITH ATTRIBUTEÑSYNTAX OBJECT IDENTIFIER MATCHES FOR EQUALITY MULTI VALUE ::= idÑbatÑextendedÑbodyÑpartÑtypes ÑÑ Extended body parts ÑÑ (These attributes cannot be enumerated. See ¤ C.3.6) ÑÑ NOTIFICATION ATTRIBUTES ÑÑ Common fields subjectÑipm ATTRIBUTE WITH ATTRIBUTEÑSYNTAX SubjectIPMField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= idÑnatÑsubjectÑipm ipnÑoriginator ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IPNOriginatorField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑnatÑipnÑoriginator ipmÑpreferredÑrecipient ATTRIBUTE WITH ATTRIBUTEÑSYNTAX IPMPreferredRecipientField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑnatÑipmÑpreferredÑrecipient conversionÑeits ATTRIBUTE WITH ATTRIBUTEÑSYNTAX MSÑEITs MATCHES FOR EQUALITY MULTI VALUE ::= idÑnatÑconversionÑeits ÑÑ NonÑreceipt fields nonÑreceiptÑreason ATTRIBUTE WITH ATTRIBUTEÑSYNTAX NonReceiptReasonField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑnatÑnonÑreceiptÑreason discardÑreason ATTRIBUTE WITH ATTRIBUTEÑSYNTAX DiscardReasonField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑnatÑdiscardÑreason autoÑforwardÑcomment ATTRIBUTE WITH ATTRIBUTEÑSYNTAX AutoForwardCommentField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= idÑnatÑautoÑforwardÑcomment returnedÑipm ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ReturnedIPMField SINGLE VALUE ::= idÑnatÑreturnedÑIPM ÑÑ Receipt fields receiptÑtime ATTRIBUTE WITH ATTRIBUTEÑSYNTAX ReceiptTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= idÑnatÑreceiptÑtime acknowledgmentÑmode ATTRIBUTE WITH ATTRIBUTEÑSYNTAX AcknowledgmentModeField MATCHES FOR EQUALITY SINGLE VALUE ::= idÑnatÑacknowledgmentÑmode supplÑreceiptÑinfo ATTRIBUTE WITH ATTRIBUTEÑSYNTAX SupplReceiptInfoField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= idÑnatÑsupplÑreceiptÑinfo END ÑÑ of IPMSMessagesStoreAttributes ANNEX K (to Recommendation X.420) Reference definition of upper bounds This Annex is an integral part of this Recommendation but is not a part of the corresponding ISO International Standard. This Annex defines for reference purposes the upper bounds of various variableÑlength information items whose abstract syntaxes are defined in the ASN.1 modules of prior annexes. IPMSUpperBounds { jointÑisoÑccitt mhsÑmotis(6) ipms(1) modules(0) upperÑbounds(10) } DEFINITIONS IMPLICIT TAGS ::= BEGIN ÑÑ Prologue ÑÑ Exports everything. IMPORTS ÑÑ nothing ÑÑ; ÑÑ Upper bounds ubÑautoÑforwardÑcomment INTEGER ::= 256 ubÑfreeÑformÑname INTEGER ::= 64 ubÑipmÑidentifierÑsuffix INTEGER ::= 2 ubÑlocalÑipmÑidentifier INTEGER ::= 64 ubÑsubjectÑfield INTEGER ::= 128 ubÑtelephoneÑnumber INTEGER ::= 32 END ÑÑ of IPMSUpperBounds ANNEX L (to Recommendation X.420) Support of the interpersonal messaging service This Annex is an integral part of this Recommendation. The interpersonal messaging service which the IPMS provides to users is defined, in nonÑtechnical terms, in Recommendation X.400. The service comprises a number of elements of service (IPM EOS), each representing one aspect of the service, and each defined in one or two paragraphs of prose. The present Annex indicates in detail how the present, more technical specification realizes each IPM EOS. Equivalently, it identifies the aspects of the specification a UA, e.g., must implement for it to be said to support a particular IPM EOS. Associated with each IPM EOS are one or more information items that may appear as IPM components. The information item associated with the sensitivity indication IPM EOS, e.g., is the sensitivity heading field. A UA, TLMA, or AU shall be said to support a particular IPM EOS upon origination or reception if, and only if, it supports upon origination or reception (see ¤ 22.1) the information items associated with that IPM EOS. Note 1 Ñ The task of realizing an IPM EOS may fall, in principle, upon any of the secondary objects that result from the refinement of the IPMS. In the present context, however, it is assumed that the MTS and every MS, by virtue of their applicationÑindependence, support every IPMÑEOS, and that they do so without having made special provision for any of them. Note 2 Ñ As described in ¤ 14, a UA makes available to its user many of the capabilities that its MS offers. These capabilities realize the elements of the message retrieval service which is defined in Recommendation X.400. The correspondence between the elements of that service and the associated technical capabilities is given in Recommendation X.413. Note 3 Ñ As described in ¤ 14, a UA makes available to its user many of the capabilities that the MTS offers. These capabilities realize the elements of the message transfer service which is defined in Recommendation X.400. The correspondence between the elements of that service and the associated technical capabilities is given in Recommendation X.411. L.1 Support of recipient specifier components Some IPM EOS are realized by means of recipient specifier components. The IPM EOS in this category are listed in the first column of Table LÑ1/X.420. The second and third columns identify the recipient specifier component, and the particular value of that component, that are the information items associated with each listed IPM EOS. TABLE LÑ1/X.420 Support of recipient specifier components Element of service Recipient Value specifier component NonÑreceipt nrn notification request NotificationÑre quests Receipt notification rn request indication NotificationÑre quests Reply request true indication ReplyÑrequested (see also Table LÑ2/X.420) Note 1 Ñ Recipient specifiers appear as subÑfields of the Primary Recipients, Copy Recipients, and Blind Copy Recipients heading fields. Note 2 Ñ Every IPM EOS except Reply Request Indication falls into exactly one category. The Reply Request Indication IPM EOS falls into two categories, as indicated in the Table. L.2 Support of heading fields Some IPM EOS are realized by means of heading fields. The IPM EOS in this category are listed in the first column of Table LÑ2/X.420. The second column identifies the heading fields that are the information items associated with each listed IPM EOS. In the case of the extension field, the second column also identifies, in parentheses, the relevant heading extension. L.3 Support of body aspects Some IPM EOS are realized by means of aspects of the body. The IPM EOS in this category are listed in the first column of Table LÑ3/X.420. The second column identifies the body aspect that is the information item associated with each listed IPM EOS. TABLE LÑ2/X.420 Support of heading fields Element of service Heading field Authorizing users Authorizing users indication AutoÑforwarded AutoÑforwarded indication Blind copy recipient Blind copy recipients indication CrossÑreferencing Related IPMs indication Expiry date indication Expiry time Importance indication Importance IPÑmessage This IPM identification Incomplete copy Extensions (incomplete indication copy) Language indication Extensions (languages) Obsoleting indication Obsoleted IPMs Originator indication Originator Primary and Primary recipients copy recipients Copy recipients indication Reply request Reply time indication (see also Table LÑ3/X.420) Reply recipients Replying IPÑmessage RepliedÑto IPM indication Sensitivity indication Sensitivity Subject indication Subject Note Ñ Every IPM EOS except Reply Request Indication falls into exactly one category. The Reply Request Indication IMP EOS falls into two categories, as indicated in the Table. TABLE LÑ3/X.420 Support of body aspects Element of service Body aspect Body part Encrypted body encryption part indication Forwarded Message body part IPÑmessage indication MultiÑpart body Body with two or more parts Typed body Body (itself) Note Ñ Support of the Typed Body IPM EOS is intrinsic to any implementation of any secondary object. ANNEX M 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 the corresponding ISO International Standard. The following are the differences that exist: a)The ISO International Standard corresponding to this Recommendation defines a general text body part, while this Recommendation does not. b)The upper bounds of Annex K are an integral part of this Recommendation but are not a part of the corresponding ISO International Standard. c)The CCITT text on subject recipient specifier in ¤ 8 states that it may contain either Òan O/R name of the preferred recipientÓ or Òan O/R name appearing in the message's DL expansion historyÓ. The ISO Standard has excluded this second possibility. ANNEX N Summary of changes to 1984 specification This Annex is not a part of this Recommendation. Editorially, this Recommendation differs substantially from Recommendation X.420 (1984). Technically, however, the differences are few. The present Annex lists the technical changes. It is intended as an aid to an implementor of Recommendation X.420 (1984), enabling him to see at a glance how his implementation might be affected by the 1988 specification. The following, and only the following, substantive changes relevant to interworking between 1984 and 1988 UAs, MSs, TLMAs, and AUs are embodied in the present specification. All but the first are changes to the format of the information objects now defined in the ASN.1 module, IPMSInformationObjects: a)The content type assigned to P2 has changed. Formerly identified by the integer 2, P2 now is identified by either the integer 2 or 22, depending upon the functionality employed in a particular instance of communication by means of the MTS (see ¤ 20.2.). b)The omission of the user members of IPMIdentifier is now denigrated. c)The extensions member has been added to heading. Its grade is optional. d)The telex and simple formattable document body part types have been abandoned. (The former had been identified but not defined.) e)The syntax member has been added to VideotexParameters. Its grade is optional. f)The presence of the deliveryÑtime member of the MessageParameters in the absence of its deliveryÑenvelope member, or viceÑversa, is now denigrated. g)The bilaterallyÑdefined and externallyÑdefined alternatives have been added to BodyPart. h)The following protocol elements, defined in Recommendation X.411 and incorporated in protocol elements of this Recommendation by reference, have changed: i)ORName ii) ORAddress iii)MessageDeliveryEnvelope iv) EncodedInformationTypes v)SupplementaryInformation. i)Specifying a value of zero length of any of the following data types is now denigrated: i)LocalIPMIdentifier ii) FreeFormName iii)TelephoneNumber iv) SubjectField v)AutoForwardComment. j)Upper bounds have been imposed upon certain variableÑlength protocol elements. Note Ñ The upper bounds imposed are those found in ¤ 4.3 of Version 6 of the X.400Ñseries Implementor's Guide. _______________________________ 1) Recommendation X.420 and ISO 10021Ñ7 [Information Processing Systems Ñ Text Communication Ñ MOTIS Ñ Interpersonal Messaging System] were developed in close collaboration and are technically aligned, except for the differences.