џWPCL ћџ2BJ|xа АH аа АА X агга ХА6p&А6p&Х аевI а Hh аааУ Уб cмˆ4 PŽТ б Fascicle VIII.7 Р-Р Rec. X.400 Ф ФPAGE1У Уб cмˆ4 PŽТ б Ф ФвееЅ† а HH аааб cмˆ4 PŽТ бPAGE22б cмˆ4 PŽТ бУ У Fascicle VIII.7 Р-Р Rec. X.400 Ѕеа H№ ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаа X Ш аУ УУУб cмˆ4 PŽТ бThe drawings contained in this Recommendation have been done in Autocad. б cмˆ4 PŽТ бФФRecommendation X.400УУб cмˆ4 PŽТ бФ Ф1жŠ† а HH ааа1)ФФб cмˆ4 PŽТ б Recommendation F.400 is identical to X.400. Šж) б cмˆ4 PŽТ бУ УФФ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH јP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСр(AСMESSAGE HANDLING SYSTEM AND SERVICE OVERVIEWФ Ф а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бС СThe establishment in various countries of telematic services and computer based store and forward messaging services in association with public networks creates a need to produce standards to facilitate international message exchange between subscribers to such services. С СThe CCITT, УУconsidering ФФС С(a)СpСthe need for message handling systems; С С(b)СpСthe need to transfer and store messages of different types; а H аС С(c)СpСthat Recommendation X.200 defines the reference model of open systems interconnection for CCITT applications; С С(d)СpСthat Recommendations X.208, X.217, X.218 and X.219 provide the foundation for CCITT applications; С С(e)СpСthat the X.500Р-РSeries Recommendations define directory systems; С С(f)СpС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; а H аС С(g)СpСthat interpersonal message is defined in Recommendation X.420 and T.330; а H аС С(h)СpСthat several FР-РSeries Recommendations describe public message handling services: F.400, F.401, F.410 and F.420; а H аС С(i)СpСthat several FР-РSeries Recommendations describe intercommunication between public message handling services and other services: F.421, F.415 and F.422, УУunanimously declares а H аФФС Сthe view that the overall system and service overview of message handling is defined in this Recommendation. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚Ср UСCONTENTS аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаPART 1 Р-Р УУIntroductionФФ 0С СУУIntroductionФФ 1С СУУScopeФФ 2С СУУReferencesФФ 3С СУУDefinitionsФФ 4С СУУAbbreviationsФФ 5С СУУConventionsФФ PART 2 Р-Р УУGeneral description of MHSФФ 6С СУУPurposeФФ 7С СУУFunctional model of MHSФФ С С7.1СpССи СDescription of the MHS model С С7.2СpССи СStructure of messages С С7.3СpССи СApplication of the MHS model С С7.4СpССи СMessage store 8С СУУMessage transfer serviceФФ С С8.1СpССи СSubmission and delivery С С8.2СpССи СTransfer С С8.3СpССи СNotifications С С8.4СpССи СUser agent С С8.5СpССи СMessage store С С8.6СpССи СAccess unit С С8.7СpССи СUse of the MTS in the provision of public services 9С СУУIPM serviceФФ С С9.1СpССи СIPM service functional model С С9.2СpССи СStructure of IPР-Рmessages С С9.3СpССи СIPР-Рnotifications 10С  СУУIntercommunication with physical delivery servicesФФ С С10.1Си ССЈ СIntroduction С С10.2Си ССЈ СOrganizational configurations 11С  СУУSpecialized accessФФ С С11.1Си ССЈ СIntroduction С С11.2Си ССЈ СTeletex access С С11.3Си ССЈ СTelex access PART 3 Р-Р УУCapabilities of MHSФФ 12С  СУУNaming and addressingФФ С С12.1Си ССЈ СIntroduction С С12.2Си ССЈ СDirectory names С С12.3Си ССЈ СO/R names С С12.4Си ССЈ СO/R addresses 13С  СУУMHS use of directoryФФ С С13.1Си ССЈ СIntroduction С С13.2Си ССЈ СFunctional model С С13.3Си ССЈ СPhysical configurations 14С  СУУDistribution lists in MHSФФ С С14.1Си ССЈ СIntroduction С С14.2Си ССЈ СProperties of a DL С С14.3Си ССЈ СSubmission С С14.4Си ССЈ СDL use of a directory С С14.5Си ССЈ СDL expansion С С14.6Си ССЈ СNesting С С14.7Си ССЈ СRecursion control С С14.8Си ССЈ СDelivery С С14.9Си ССЈ СRouting loop control С С14.10Си СNotifications С С14.11Си СDL handling policy 15С  СУУSecurity capabilities of MHSФФ С С15.1Си ССЈ СIntroduction С С15.2Си ССЈ СMHS security threats С С15.3Си ССЈ СSecurity model С С15.4Си ССЈ СMHS security features С С15.5Си ССЈ СSecurity management 16С  СУУConversion in MHSФФ 17С  СУУUse of the MHS in provision of public servicesФФ PART 4 Р-Р УУElements of serviceФФ 18С  СУУPurposeФФ 19С  СУУClassificationФФ С С19.1Си ССЈ СPurpose of classification С С19.2Си ССЈ СBasic message transfer service С С19.3Си ССЈ СMT service optional user facilities С С19.4Си ССЈ СBase MH/PD service intercommunication а H аС С19.5Си ССЈ СOptional user facilities for MH/PD service intercommunication С С19.6Си ССЈ СBase message store С С19.7Си ССЈ СMS optional user facilities С С19.8Си ССЈ СBasic interpersonal messaging service С С19.9Си ССЈ СIPM service optional user facilities УУAnnex AФФСpСР-РСи СGlossary of terms УУAnnex BФФСpСР-РСи СDefinitions of elements of service а H аУУAnnex CФФСpСР-РСи СElements of service modifications with respect to the 1984 version а H аУУAnnex DФФСpСР-РСи СDifferences between CCITT Recommendation F.400 and ISO Standard 10021Р-Р1 PART 1 Р-Р INTRODUCTION аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У0ТX ТIntroductionФ ФЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThis Recommendation is one of a set of Recommendations for message handling. The entire set provides a comprehensive specification for messageд х)д handling comprising any number of cooperating openР-Рsystems. а H аС СMessage handling systems and services enable users to exchange messages on a storeР-РandР-Рforward basis. A message submitted by one user, the originator, is conveyed by the message transfer system (MTS), the principal component of a larger message handling system (MHS), and is subsequently delivered to one or more additional users, the message's recipients. а H аС СAn MHS comprises a variety of interconnected functional entities. Message transfer agents (MTAs) cooperate to perform the storeР-РandР-Рforward message transfer function. Message stores (MSs) provide storage for messages and enable their submission, retrieval and management. User agents (UAs) help users access MHS. Access units (AUs) provide links to other communication systems and services of various kinds (e.g. other telematic services, postal services). а H аС СThis Recommendation specifies the overall system and service description of message handling capabilities. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаУ У1ТX ТScopeФ ФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThis Recommendation defines the overall system and service of an MHS and serves as a general overview of MHS. С СOther aspects of message handling systems and services are defined in other Recommendations. The layout of Recommendations defining the message handling system and services is shown in Table 1/X.400. The public services built on MHS, as well as access to and from the MHS for public services are defined in the F.400Р-РSeries of Recommendations. С СThe technical aspects of MHS are defined in the X.400Р-РSeries of Recommendations. The overall system architecture of MHS is defined in Recommendation X.402. ‚Ср SСб cмˆ4 PŽТ бTABLE 1/X.400 Ср IСУ УStructure of MHS RecommendationsФ Ф б cмˆ4 PŽТ бвЦ„H˜ ˆ˜ #Цв‡аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH(pи P Ј ˜ џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСр JСааб cмˆ4 PŽТ бName of Recommendation/Standard аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHр8џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСр UСJoint MHS аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHш@˜џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСр SСJoint support аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHhР! #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСр TСCCITT only а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџhР! #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бˆа а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ б аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСр>X ˆСCCITT Ср>X ‰СISO Ср>X ˆСCCITT аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxрџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСр>X ‰СISO аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСр>X ‡СSystem Ср>X ‡СService а а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСSystem and service overview аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСрF #–СX.400 СрF #•С10021Р-Р1 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СF.400 а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСOverall architecture аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСрF #–СX.402 СрF #•С10021Р-Р2 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСConformance testing аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСрF #–СX.403 а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСAbstract service definition СQp&RСconventions аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСрF #–СX.407 СрF #•С10021Р-Р3 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСEncoded information type СdX/eС conversion rules аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСрF #–СX.408 а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСMTS: Abstract service а а аСFH!GССGР!HСdefinition and procedures аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСрF #–СX.411 СрF #•С10021Р-Р4 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСMS:Abstract service definition аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСрF #–СX.413 СрF #•С10021Р-Р5 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСProtocol specifications аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСрF #–СX.419 СрF #•С10021Р-Р6 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСInterpersonal messaging system аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСрF #–СX.420 СрF #•С10021Р-Р7 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бTelematic access to IPMS аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСрF #–СT.330 а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСNaming and addressing for СJ(#KСpublic MH services аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СF.401 а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСThe public message transfer СO€%PСservice аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СF.410 а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСIntercommunication with Сcр.dС public physical delivery СRш&SСservices аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СF.415 а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСThe public IPM service аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СF.420 а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСIntercommunication between СN%OСIPM service and telex аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СF.421 а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бMHS:СJ(#KСIntercommunication between СN%OСIPM service and teletex аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СF.422 а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бOSI:СJ(#KСBasic reference model аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СX.200 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџШ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСFH!GС7498 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бOSI:СJ(#KСSpecification of abstract syntax СIА"JСnotation one (ASN.1) аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СX.208 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџШ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСFH!GС8824 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бOSI:СJ(#KСSpecification of basic encoding СO€%PС а а аrules for abstract syntax СM$NСnotation one (ASN.1) аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СX.209 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџШ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСFH!GС8825 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бOSI:СJ(#KСAssociation control: service СN%OСdefinition аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СX.217 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџШ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСFH!GС8649 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бOSI:СJ(#KСReliable transfer: model and СJ(#KСservice definition аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СX.218 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџШ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСFH!GС9066Р-Р1 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бOSI:СJ(#KСRemote operations: model, СM$NСnotation and service definition аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СX.219 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџШ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСFH!GС9072Р-Р1 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бOSI:СJ(#KСAssociation control: protocol СO€%PСspecification аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СX.227 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџШ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСFH!GС8650 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бOSI:СJ(#KСReliable transfer: protocol СO€%PСspecification аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СX.228 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџШ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСFH!GС9066Р-Р2 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа а а аб cмˆ4 PŽТ бвЦ‡H˜ ˆXHиP˜X а  #Цв‡а а ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ(pи P Ј ˜ а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бOSI:СJ(#KСRemote operations: protocol СO€%PСspecification аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџрHА а џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа СрF #–СX.229 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџШ ˆxра џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаСFH!GС9072Р-Р2 аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџра 8" #џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа а а а аб cмˆ4 PŽТ бˆа HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТУ У 2СјСReferencesФ ФЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThis Recommendation cites the documents listed below: а H аRecommendation F.60С СС X%СOperational provisions for the international telex service Recommendation F.69С СС X%СPlan for the telex destination codes а H аRecommendation F.72С СС X%СInternational telex storeР-РandР-Рforward Р-Р General principles and operational aspects Recommendation F.160С СС X%СGeneral operational provisions for the international public fascimile services Recommendation F.200С СС X%СTeletex service Recommendation F.300С СС X%СVideotex service а H аRecommendation F.400С СС X%СMessage handling Р-Р System and service overview (see also ISO 10021Р-Р1) а H аRecommendation F.401С СС X%СMessage handling services Р-Р Naming and addressing for public message handling services а H аRecommendation F.410С СС X%СMessage handling services Р-Р The public message transfer service а H аRecommendation F.415С СС X%СMessage handling services Р-Р Intercommunication with public physical delivery services Recommendation F.420С СС X%СMessage handling services Р-Р The public interpersonal messaging service а H аRecommendation F.421С СС X%СMessage handling services Р-Р Intercommunication between the IPM service and the С'А*СС*/СС/`4СС4И9СС9>СС>hCСtelex service а H аRecommendation F.422С СС X%СMessage handling services Р-Р Intercommunication between the IPM service and the С'А*СС*/СС/`4СС4И9СС9>СС>hCСteletex service а H аRecommendation T.61С СС X%СCharacter repertoire and coded character sets for the international teletex service Recommendation T.330С СС X%СTelematic access to IPMS а H аRecommendation U.80С СС X%СInternational teletex storeР-РandР-Рforward Р-Р Access from telex а H аRecommendation U.204С СInterworking between the telex service and the public interpersonal messaging service а H аRecommendation X.200С СReference model of open systems interconnection for CCITT applications (see also С СС X%СС%А*СС*/СС/`4СС4И9СISO 7498) а H аRecommendation X.208С СSpecification of abstract syntax notation one (ASN.1) (see also ISO 8824) а H аRecommendation X.209С СSpecification of basic encoding rules for abstract syntax notation one (ASN.1) (see also С&А*СС*/СС/`4СС4И9СС9>СС>hCСISO 8825) а H аRecommendation X.217С СAssociation control: Service definitions (see also ISO 8649) а H аRecommendation X.218С СReliable transfer model: Service definition (see also ISO/IEC 9066Р-Р1) а H аRecommendation X.219С СRemote operations model: Notation and service definition (see also ISO/IEC 9072Р-Р1) а H аRecommendation X.400С СMessage handling Р-Р System and service overview (see also ISO/IEC 10021Р-Р1) а H аRecommendation X.402С СMessage handling systems Р-Р Overall architecture (see also ISO/IEC 10021Р-Р2) Recommendation X.403С СMessage handling systems Р-Р Conformance testing а H аRecommendation X.407С СMessage handling systems Р-Р Abstract service definition conventions (see also С СС X%СС%А*СС*/СС/`4СС4И9СС9>СISO/IEC 10021Р-Р3) а H аRecommendation X.408С СMessage handling systems Р-Р Encoded information type convention rules а H аRecommendation X.411С СMessage handling systems Р-Р Message transfer system: Abstract service definition and С'А*СС*/СС/`4СС4И9СС9>СС>hCСprocedures (see also ISO/IEC 10021Р-Р4) Recommendation X.413С СMessage handling systems Р-Р Message store: Abstract service definition (see also С#X%СС%А*СС*/СС/`4СС4И9СС9>СISO/IEC 10021Р-Р5) а H аRecommendation X.419С СMessage handling systems Р-Р Protocol specifications (see also ISO/IEC 10021Р-Р6) а H аRecommendation X.420С СMessage handling systems Р-Р Interpersonal messaging systemСY0*ZС (see also ISO/IEC 10021Р-Р7) Recommendation X.500С СDirectory Р-Р Overview (see also ISO/IEC 9594Р-Р1) Recommendation X.501С СDirectory Р-Р Models (see also ISO/IEC 9594Р-Р2) а H аRecommendation X.509С СDirectory Р-Р Authentication (see also ISO/IEC 9594Р-Р8) а H аRecommendation X.511С СDirectory Р-Р Abstract service definition (see also ISO/IEC 9594Р-Р3) а H аRecommendation X.518С СDirectory Р-Р Procedures for distributed operations (see also ISO/IEC 9594Р-Р4) а H аRecommendation X.519С СDirectory Р-Р Protocol specifications (see also ISO/IEC 9594Р-Р5) а H аRecommendation X.520С СDirectory Р-Р Selected attribute types (see also ISO/IEC 9594Р-Р6) а H аRecommendation X.521С СDirectory Р-Р Selected object classes (see also ISO/IEC 9594Р-Р7) аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У3ТX ТDefinitionsФ ФЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThis Recommendation uses the terms listed below, and those defined in Annex A. а H аС СDefinitions of the elements of service applicable to MHS are contained in Annex B. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа3.1Тh  ТУУOpen systems interconnectionЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThis Recommendation uses the following terms defined in Recommendation X.200: Та ТТ№ ТС€ Сa)СpСApplication layer;ЦЦ Та ТТ№ ТС€ Сb)СpСApplicationР-Рprocess;ЦЦ Та ТТ№ ТС€ Сc)СpСOpen systems interconnection;ЦЦ Та ТТ№ ТС€ Сd)СpСOSI reference model.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа3.2Тh  ТУУDirectory systemsЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThis Recommendation uses the following terms defined in Recommendation X.500: Та ТТ№ ТС€ Сa)СpСdirectory entry;ЦЦ Та ТТ№ ТС€ Сb)СpСdirectory system agent;ЦЦ Та ТТ№ ТС€ Сc)СpСdirectory system;ЦЦ Та ТТ№ ТС€ Сd)СpСdirectory user agent.ЦЦ а H аС СThis Recommendation uses the following terms defined in Recommendation X.501: Та ТТ№ ТС€ Сe)СpСattribute;ЦЦ Та ТТ№ ТС€ Сf)СpСgroup;ЦЦ Та ТТ№ ТС€ Сg)СpСmember;ЦЦ Та ТТ№ ТС€ Сh)СpСname.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У4ТX ТAbbreviationsФ ФЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СAСpССи ССЈ СAdditional С СADMDСи ССЈ СAdministration management domain С СAUСpССи ССЈ СAccess unit С СCAСpССи ССЈ СContractual agreement С СDLСpССи ССЈ СDistribution list С СDSAСpССи СDirectory system agent С СDUAСpССи СDirectory user agent С СEСpССи ССЈ СEssential С СEITСpССи ССЈ СEncoded information type С СI/OСpССи ССЈ СInput/output С СIPСpССи ССЈ СInterpersonal С СIPMСpССи ССЈ СInterpersonal messaging С СIPMSСи ССЈ СInterpersonal messaging system С СMDСpССи ССЈ СManagement domain С СMHСpССи ССЈ СMessage handling С СMHSСpССи СMessage handling system С СMSСpССи ССЈ СMessage store С СMTСpССи ССЈ СMessage transfer С СMTAСpССи СMessage transfer agent С СMTSСpССи СMessage transfer system С СN/AСpССи ССЈ СNot applicable С СO/RСpССи ССЈ СOriginator/recipientд Д-дŒС СOSIСpССи ССЈ СOpen system interconnection С СPDСpССи ССЈ СPhysical delivery С СPDAUСи ССЈ СPhysical delivery access unit С СPDSСpССи ССЈ СPhysical delivery system С СPMСpССи ССЈ СPerР-Рmessage С СPRСpССи ССЈ СPerР-Рrecipient С СPRMDСи ССЈ СPrivate management domain С СPTLXAUСи СPublic telex access unit С СTLMAСи ССЈ СTelematic agent С СTLXAUСи ССЈ СTelex access unit С СTTXСpССи СTeletex С СUAСpССи ССЈ СUser agent аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У5ТX ТConventionsФ ФЦЦ а Hx ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СIn this Recommendation the expression Р"РAdministrationР"Р is used for shortness to indicate a telecommunication Administration, a recognized private operating agency, and, in the case of intercommunication with public delivery service, a postal Administration. а H аС СУУNoteФФ Р-Р This Recommendation is identical to Recommendation F.400. Because of the desired alignment with ISO, the conventions of ISO standards have been adopted for the structure of this text. These conventions differ from the CCITT style. The other Recommendations of the X.400Р-РSeries are in accordance with CCITT conventions. PART 2 Р-Р GENERAL DESCRIPTION OF MHS аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У6ТX ТPurposeФ ФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThis Recommendation is one of a set of Recommendations and describes the system model and elements of service of the message handling system (MHS) and services. This Recommendation overviews the capabilities of an MHS that are used by Administrations for the provision of public MH services to enable users to exchange messages on a storeР-РandР-Рforward basis. а H аС СThe message handling system is designed in accordance with the principles of the reference model of open systems interconnection (OSI reference model) for CCITT applications (Recommendation X.200) and uses the presentation layer services and services offered by other, more general, application service elements. An MHS can be constructed using any network fitting in the scope of OSI. The message transfer service provided by the MTS is application independent. An example of a standardized application is the IPM service. End systems can use the MT service for specific applications that are defined bilaterally. а H аС СMessage handling services provided by Administrations belong to the group of telematic services defined in FР-РSeries Recommendations. а H аС СVarious other telematic services and telex (Recommendations F.60, F.160, F.200, F.300, etc.), data transmission services (X.1), or physical delivery services (F.415) gain access to, and intercommunicate with, the IPM service or intercommunicate with each other, via access units. С СElements of service are the service features provided through the application processes. The elements of service are considered to be components of the services provided to users and are either elements of a basic service or they areУУ optional user facilitiesФФ, classified either asУУ essential optional user facilitiesФФ, or asУУ additional optional user facilitiesФФ. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У7ТX ТFunctional model of MHSФ ФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe MHS functional model serves as a tool to aid in the development of Recommendations for MHS, and aids in describing the basic concepts that can be depicted graphically. It comprises several different functional components that work together to provide MH services. The model can be applied to a number of different physical and organizational configurations. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа7.1Тh  ТУУDescription of the MHS modelЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СA functional view of the MHS model is shown in Figure 1/X.400. In this model, a user is either a person or a computer process. Users are either direct users (i.e. engage in message handling by direct use of MHS), or are indirect users (i.e. engage in message handling through another communication system (e.g. a physical delivery system) that is linked to MHS). A user is referred to as either an originator (when sending a message) or a recipient (when receiving a message). Message handling elements of service define the set of message types and the capabilities that enable an originator to transfer messages of those types to one or more recipients. а H аС СAn originator prepares messages with the assistance of his user agent. A user agent (UA) is an application process that interacts with the message transfer system (MTS) or a message store (MS), to submit messages on behalf of a single user. The MTS delivers the messages submitted to it, to one or more recipient UAs, access units (AUs), or MSs, and can return notifications to the originator. Functions performed solely by the UA and not standardized as part of the message handling elements of service are called local functions. A UA can accept delivery of messages directly from the MTS, or it can use the capabilities of an MS to receive delivered messages for subsequent retrieval by the UA. а H аС СThe MTS comprises a number of message transfer agents (MTAs). Operating together, in a storeР-РandР-Рforward manner, the MTAs transfer messages and deliver them to the intended recipients. С СAccess by indirect users of MHS is accomplished by AUs. Delivery to indirect users of MHS is accomplished by AUs, such as in the case of physical delivery, by the physical delivery access unit (PDAU). а H аС СThe message store (MS) is an optional general purpose capability of MHS that acts as an intermediary between the UA and the MTA. The MS is depicted in the MHS functional model shown in Figure 1/X.400. The MS is a functional entity whose primary purpose is to store and permit retrieval of delivered messages. The MS also allows for submission from, and alerting to the UA. а H аС СThe collection of UAs, MSs, AUs and MTAs is called the message handling system (MHS). ‚Ср HСб cмˆ4 PŽТ бFigure 1/X.400 Љ CCITT Љ 0100311Љ88 б cмˆ4 PŽТ б аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа7.2Тh  ТУУStructure of messagesЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe basic structure of messages conveyed by the MTS is shown in Figure 2/X.400. A message is made up of an envelope and a content. The envelope carries information that is used by the MTS when transferring the message within the MTS. The content is the piece of information that the originating UA wishes delivered to one or more recipient UAs. The MTS neither modifies or examines the content, except for conversion (see РSР 16). ‚Ср HСб cмˆ4 PŽТ бFigure 2/X.400 Љ CCITT Љ 0100580Љ88 б cмˆ4 PŽТ б аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа7.3Тh  ТУУApplication of the MHS modelЦЦ Та ТС€ HСФФ7.3.1С јСУУPhysical mappingЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СUsers access UAs for message processing purposes, for example, to create, present, or file messages. A user can interact with a UA via an input/output device or process (e.g. keyboard, display, printer, etc.). A UA can be implemented as a (set of) computer process(es) in an intelligent terminal. С СA UA and MTA can be coР-Рlocated in the same system, or a UA/MS can be implemented in physically separate systems. In the first case the UA accesses the MT elements of service by interacting directly with the MTA in the same system. In the second case, the UA/MS will communicate with the MTA via standardized protocols specified for MHS. It is also possible for an MTA to be implemented in a system without UAs or MSs. а H аС СSome possible physical configurations are shown in Figures 3/X.400 and 4/X.400. The different physical systems can be connected by means of dedicated lines or switched network connections. Та ТС€ HС‚Ср JСб cмˆ4 PŽТ бFigure 3/X.400Љ CCITT Љ 0100590ЦЦ б cмˆ4 PŽТ б Ср HСб cмˆ4 PŽТ бFigure 4/X.400 Љ CCITT Љ 0100600Љ88 б cмˆ4 PŽТ б аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС7.3.2С јСУУOrganizational mappingЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СAn Administration or organization can play various roles in providing message handling services. An organization in this context can be a company or a nonР-Рcommercial enterprise. а H аС СThe collection of at least one MTA, zero or more UAs, zero or more MSs, and zero or more AUs operated by an Administration or organization constitutes a management domain (MD). An MD managed by an Administration is called an Administration management domain (ADMD). An MD managed by an organization other than an Administration is called a private management domain (PRMD). An MD provides message handling services in accordance with the classification of elements of service as described in РSР 19. The relationships between management domains is shown in Figure 5/X.400. ‚Ср GСб cмˆ4 PŽТ бFigure 5/X.400 Љ CCITT Љ 0100321 Љ88 б cмˆ4 PŽТ б а H аС СУУNote 1ФФ Р-Р It should be recognized that the provision of support of private messaging systems by CCITT members falls within the framework of national regulations. Thus the possibilities mentioned in this paragraph may or may not be offered by an Administration which provides message handling services. In addition, the UAs depicted in Figure 5/X.400 do not imply that UAs belonging to an MD must be exclusively located in the same country as their MDs. С СУУNote 2ФФ Р-Р Direct interactions between PRMDs and internal interactions within an MD are outside the scope of this Recommendation. а H аС СУУNote 3ФФ Р-Р An Administration, in the context of CCITT, that manages an ADMD, is understood as being a member of ITU or a recognized private operating agency (RPOA), registered by a country with the ITU. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС7.3.3С јСУУAdministration management domainЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СIn one country one or more ADMDs can exist. An ADMD is characterized byд Д-д its provision of relaying functions between other management domains and а H аthe provision of message transfer service for the applications provided within the ADMD. а H аС СAn Administration can provide access for its users to the ADMD in one or more of the following ways: Та ТР-РТ№ Тusers to Administration provided UAЦЦ Та ТР-РТ№ Тprivate UA to Administration MTAЦЦ Та ТР-РТ№ Тprivate UA to Administration MSЦЦ Та ТР-РТ№ Тprivate UA to Administration MTAЦЦ Та ТР-РТ№ Тuser to Administration provided UA.ЦЦ а H аС СSee also the examples of configurations shown in Figure 3/X.400 and Figure 4/X.400. а H аС СAdministration provided UAs can exist as part of an intelligent terminal that the user can use to access MHS. They can also exist as part of Administration resident equipment being part of MHS, in which case the user obtains access to the UA via an I/O device. а H аС СIn the case of a private UA, the user has a private standР-Рalone UA which interacts with the Administration provided MTA or MS, using submission, delivery and retrieval functions. A private, standР-Рalone UA can be associated with one or more MDs, provided that the required naming conventions are preserved. С СA private MTA as part of an PRMD can access one or more ADMDs in a country, following national regulations. а H аС СAccess can also be provided by Administration provided AUs described in РSРS 10 and 11. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС7.3.4С јСУУPrivate management domainЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СAn organization other than an Administration can have one or more MTA(s), and zero or more UAs, AUs and MSs forming a PRMD which can interact with an ADMD on an MD to MD (MTA to MTA) basis. A PRMD is characterized by the provision of messaging functions within that management domain. а H аС СA PRMD is considered to exist entirely within one country. Within that country, the PRMD can have access to one or more ADMDs as shown in Figure 5/X.400. However, in the case of a specific interaction between a PRMD and an ADMD (such as when a message is transferred between MDs), the PRMD is considered to be associated only with that ADMD. A PRMD will not act as a relay between two ADMDs. С СIn the interaction between a PRMD and an ADMD, the ADMD takes responsibility for the actions of the PRMD which are related to the interaction. In addition to ensuring that the PRMD properly provides the message transfer service, the ADMD is responsible for ensuring that the accounting, logging, quality of service, uniqueness of names, and related operations of the PRMD а H аare correctly performed. As a national matter, the name of a PRMD can be either nationally unique or relative to the associated ADMD. If a PRMD is associated with more than one ADMD, the PRMD can have more than one name. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа7.4Тh  ТУУMessage storeЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СBecause UAs can be implemented on a wide variety of equipment, including personal computers, the MS can complement a UA implemented, for example, on а H аa personal computer by providing a more secure, continuously available storage mechanism to take delivery of messages on the user agent's behalf. The MS retrieval capability provides users who subscribe to an MS with basic message retrieval capabilities potentially applicable to messages of all types. Figure 6/X.400 shows the delivery, and subsequent retrieval of messages that are delivered to an MS, and the indirect submission of messages via the MS. ‚Ср HСб cмˆ4 PŽТ бFigure 6/X.400 Љ CCITT Љ 0100610Љ88 У Уб cмˆ4 PŽТ б а H аб cмˆ4 PŽТ бФ ФС СOne MS acts on behalf of only one user (one O/R address), i.e. it does not provide a common or shared MS capability to several users (see also PRMD3 of Figure 5/X.400). а H аС СWhen subscribing to an MS, all messages destined for the UA are delivered to the MS only. The UA, if on line, can receive alerts when certain messages are delivered to the MS. Messages delivered to an MS are considered delivered from the MTS perspective. С СWhen a UA submits a message through the MS, the MS is in general transparent and submits it to the MTA before confirming the success of the submission to the UA. However, the MS can expand the message if the UA requests the forwarding of messages that exist in the MS. а H аС СUsers are also provided with the capability to request the MS to forward selected messages automatically upon delivery. а H аС СThe elements of service describing the features of the MS are defined in Annex B and classified in РSР 19. Users are provided with the capability based on various criteria, to get counts and lists of messages, to fetch messages, and to delete messages, currently held in the MS. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС7.4.1С јСУУPhysical configurationsЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe MS can be physically located with respect to the MTA in a number of ways. The MS can be coР-Рlocated with the UA, coР-Рlocated with the MTA, or standР-Рalone. From an external point of view, a coР-Рlocated UA and MS are indistinguishable from a standР-Рalone UA. CoР-Рlocating the MS with the MTA offers significant advantages which will probably make it the predominant configuration. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС7.4.2С јСУУOrganizational configurationsЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СEither ADMDs or PRMDs can operate MSs. In the case of Administration supplied MSs, the subscriber either provides his own UA or makes use of an Administration supplied UA via an I/O device. In either case, all the subscriber's messages are delivered to the MS for subsequent retrieval. С СThe physical and organizational configurations described above are examples only and other equally cases can exist. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У8ТX ТMessage transfer serviceФ ФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe MTS provides the general, application independent, storeР-РandР-Рforward message transfer service. The elements of service describing the features of the MT service are defined in Annex B and classified in РSР 19. Provision of public message transfer service by Administrations is described in Recommendation F.410. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа8.1Тh  ТУУSubmission and deliveryЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe MTS provides the means by which UAs exchange messages. There are two basic interactions between MTAs and UAs and/or MSs: а H аТа ТТ№ ТС€ С1)СpСThe submission interaction is the means by which an originating UA or MS transfers to an MTA the content of a message and the submission envelope. The submission envelope contains the information that the MTS requires to provide the requested elements of service.ЦЦ а H аТа ТТ№ ТС€ С2)СpСThe delivery interaction is the means by which the MTA transfers to a recipient UA or MS the content of a message plus the delivery envelope. The delivery envelope contains information related to delivery of the message.ЦЦ а H аС СIn the submission and delivery interactions, responsibility for the message is passed between the MTA and the UA or MS. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа8.2Тh  ТУУTransferФФЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СStarting at the originator's MTA, each MTA transfers the message to another MTA until the message reaches the recipient's MTA, which then delivers it to the recipient UA or MS using the delivery interaction. С СThe transfer interaction is the means by which one MTA transfers to another MTA the content of a message plus the transfer envelope. The transfer envelope contains the information related to the operation of the MTS plus information that the MTS requires to provide elements of service requested by the originating UA. а H аС СMTAs transfer messages containing any type of binary coded information. MTAs neither interpret not alter the content of messages except when performing a conversion. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа8.3Тh  ТУУNotificationsЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СNotifications in the MT service comprise the delivery and nonР-Рdelivery notifications. When a message, or probe, cannot be delivered by the MTS, a nonР-Рdelivery notification is generated and returned to the originator in a report signifying this. In addition, an originator can specifically ask forд Д-д acknowledgement of successful delivery through use of the delivery notification element of service on submission. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа8.4Тh  ТУУUser agentФФЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe UA uses the MT service provided by the MTS. A UA is a functional entity by means of which a single direct user engages in message handling. а H аС СUAs are grouped into classes based on the type of content of messages they can handle. The MTS provides a UA with the ability to identify its class when sending messages to other UAs. UAs within a given class are referred to as cooperating UAs since they cooperate with each other to enhance the communication amongst their respective users. а H аС СУУNoteФФ Р-Р A UA can support more than one type of message content, and hence belong to several UA classes. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа8.5Тh  ТУУMessage storeФФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe message store (MS) uses the MT service provided by the MTS. An MS is a functional entity associated with a user's UA. The user can submit messages through it, and retrieve messages that have been delivered to the MS. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа8.6Тh  ТУУAccess unitФФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СAn access unit (AU) uses the MT service provided by the MTS. An AU is a functional entity associated with an MTA to provide for intercommunication between MHS and another system or service. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа8.7Тh  ТУУUse of the MTS in the provision of various servicesЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe MTS is used by application specific services for the provision of message handling services of various types. The interpersonal messaging service, described in РSР 9, is one example of this. Other services can be built on the foundation of the MTS, either with corresponding recommendations or as private applications. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У9ТX ТIPM serviceФ ФЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe interpersonal message service (IPM service) provides a user with features to assist in communicating with other IPM service users. The IPM service uses the capabilities of the MT service for sending and receiving interpersonal messages. The elements of service describing the features of the IPM service are defined in Annex B and classified in РSР 19. The provision of public interpersonal messaging service by Administrations is described in Recommendation F.420. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа9.1Тh  ТУУIPM service functional modelЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СFigure 7/X.400 shows the functional model of the IPM service. The UAs used in the IPM service (IPM-UAs) comprise a specific class of cooperating UAs. The optional access units shown (TLMA, PTLXAU) allow for teletex and telex users to intercommunicate with the IPM service. The optional access unit (TLMA) also allows for teletex users to participate in the IPM service (see also РSР 11). The optional physical delivery access unit (PDAU) allows IPM users to send messages to users outside the IPM service who have no access to MHS. The message store can optionally be used by IPM users to take delivery of messages on their behalf. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа9.2Тh  ТУУStructure of IPР-РmessagesЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe IP class of UAs create messages containing a content specific to the IPM. The specific content that is sent from one IPM UA to another is a result of an originator composing and sending a message, called an IPР-Рmessage. The structure of an IPР-Рmessage as it release to the basic message structure of MHS is shown in Figure 8/X.400. The IPР-Рmessage is conveyed with an envelope when being transferred through the MTS. а H аС СFigure 9/X.400 shows an analogy between a typical office memo, and the corresponding IPР-Рmessage structure. The IPР-Рmessage contains information (e.g., to, cc, subject) provided by the user which is transformed by the IPM UA into the heading of the IPР-Рmessage. The main information that the user wishes to communicate (the body of the memo) is contained within the body of the IPР-Рmessage. In the example shown, the body contains two types of encoded information: text and facsimile, which form what are called body parts. In general, an IPР-Рmessage body can consist of a number of body parts, each which а H аcan be of a different encoded information type, such as voice, text, facsimile and graphics. Та ТТ№ ТС€ СС€ HС‚Ср HСб cмˆ4 PŽТ бFigure 7/X.400 ЉCCITT Љ 0100341Љ88ЦЦ б cмˆ4 PŽТ бУ УФ Ф Ср HСб cмˆ4 PŽТ бFigure 8/X.400 Љ CCITT Љ 0100351Љ88 б cмˆ4 PŽТ б Ср HСб cмˆ4 PŽТ бFigure 9/X.400 Љ CCITT Љ 0100361Љ88 б cмˆ4 PŽТ б аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа9.3Тh  ТУУIPР-РnotificationsЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СIn the IPM service a user can request a notification of receipt or nonР-Рreceipt of a message by a recipient. These notifications are requested by а H аan originator and are generated as a result of some (such as reading/not reading the message) recipient action. In certain cases the nonР-Рreceipt notification is generated automatically by the recipient's UA. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У10Тр  ТIntercommunication with physical delivery servicesФ ФЦЦ 10.1Т№  ТУУIntroductionФФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe value of message handling systems can be increased by connecting them to physical delivery (PD) systems such as the traditional postal service. This will allow for the physical (e.g., hardcopy) delivery of messages originated within MHS to recipients outside of MHS, and in some cases will allow for the return of notifications from the PD service to an MHS originator. The ability for origination of messages in the PD service for submission to MHS through the PDAU is for further study. The capability of intercommunication between PD and MH services is an optional capability of MHS, and is applicable to any application such as IPM. All users of MHS will have the ability to generate messages for subsequent physical delivery. Figure 10/X.400 shows the functional model of this interworking. Provision of intercommunication between public message handling services offered by Administrations and PD services is described in Recommendation F.415. The elements of service describing the features of this intercommunication are defined in Annex B and classified in РSР 19. ‚Ср GСб cмˆ4 PŽТ бFigure 10/X.400 Љ CCITT Љ 0100371Љ88 б cмˆ4 PŽТ б а H аС СA physical delivery system is a system, operated by a management domain, that transports and delivers physical messages. A physical message is a physical object comprising a relaying envelope and its content. An example of a PDS is the postal service. An example of a physical message is a paper letter and its enclosing paper envelope. а H аС СA physical delivery access unit (PDAU) converts an MH user's message to physical form, a process called physical rendition. An example of this is the printing of a message and its automatic enclosure in a paper envelope. The PDAU passes the physically rendered message to a PDS for further relaying and eventual physical delivery. а H аС СA PDAU can be viewed as a set of UAs, each UA being identified by a postal address. To perform its functions, a PDAU must support submission (notifications) and delivery interactions with the MTS, and also cooperate with other UAs. MH/PD service intercommunication is thus provided as part of the message transfer service. а H аС СTo enable MH users to address messages, to be delivered physically by a PDS, an address form appropriate for this exists and is described in РSР 12. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа10.2Т№  ТУУOrganizational configurationsЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СPossible organizational mappings of the functional model described above are shown in Figure 11/X.400. In each model (A & B), the term PD domain denotes the domain of responsibility of an organization providing a PD service. In A, the PD domain comprises an MD and a PDS. The boundary between the PD domain and the rest of MHS is a boundary between MDs. In B, the PD domain comprises only the PDS; the PDAU is not part of the PD domain. The boundary between the PD domain and MHS lies at the point where the PDAU passes physical messages to the PDS. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У11Тр  ТSpecialized accessФ ФЦЦ 11.1Т№  ТУУIntroductionЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe functional model of MHS (Figure 1/X.400) contains access units (AUs) to allow access between MHS and other communication systems and services. The model shows a generic access unit between MHS and telematic services.д Д-дŒС СAlso shown in a physical delivery access unit to allow for physical delivery of MHS messages to recipients without the need for terminal access а H аto MHS. The access to physical delivery services is available to any application carried by the MTS, through a PDU described in РSР 10. С СOther forms of access are described below. ‚Ср GСб cмˆ4 PŽТ бFigure 11/X.400 Љ CCITT Љ 0100380Љ87 б cмˆ4 PŽТ б аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа11.2Т№  ТУУTeletex accessФФЦЦ Та ТС€ HС11.2.1С јСУУRegistered access to the IPM serviceЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe specialized access unit defined for telematic access Р-Р telematic agent (TLMA) caters specially for teletex (TTX) terminals. This TLMA provides for teletex access to the IPM service as shown in Figure 7/X.400. The technical provisions of this access are defined in Recommendation T.330. The TLMA enables users of teletex terminals to participate fully in the IPM service. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС11.2.2С јСУУNonР-Рregistered (public) access to the IPM serviceЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe specialized access unit defined for telematic access Р-Р telematic agent (TLMA) also provides for public access to the IPM service for TTX users who are not registered users of the IPM service. This is shown in Figure 7/X.400. The technical provisions of this access are defined in Recommendation T.330. The intercommunication between the IPM service and the teletex service is defined in Recommendation F.422. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа11.3Т№  ТУУTelex accessЦЦ Та ТС€ HСФФ11.3.1С јСУУRegistered access to the IPM serviceЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СA telex access unit (TLXAU) is defined in the technical Recommendations to allow the intercommunication between IPM users and telex users. To provide a service with this type of AU is a national matter. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС11.3.2С јСУУNonР-Рregistered (public) access to the IPM serviceЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СA specialized access unit is defined to allow the intercommunication between IPM users and telex users. This AU provides for public access to the IPM service for telex users who are not registered users of the IPM service, and is called a public telex access unit (PTLXAU). This is shown in Figure 7/X.400. The telex users are not subscribers to the IPM service, but use some of the features of the IPM service to pass messages to IPM users. IPM users can also send messages to telex users via this AU. The intercommunication between the IPM service and the telex service is defined in Recommendation F.421. а H аС СУУNoteФФ Р-Р Other types of access units are for further study (e.g., facsimile, videotex, etc.). Та ТС€ HСPART 3 Р-Р CAPABILITIES OF MHSЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У12Тр  ТNaming and addressingФ ФЦЦ 12.1Т№  ТУУIntroductionЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СIn an MHS, the principal entity that requires naming is the user (the originator and recipient of messages). In addition, distribution lists (DLs) have names for use in MHS. Users of MHS and DLs are identified by O/R names. O/R names are comprised of directory names and/or addresses, all of which are described in this clause. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа12.2Т№  ТУУDirectory namesЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СUsers of the MH service, and DLs, can be identified by a name, called a directory name. A directory name must be looked up in a directory to find out the corresponding O/R address. The structure and components of directory names are described in the X.500Р-РSeries of Recommendations. а H аС СA user can access a directory system directly to find out the O/R address of a user, or O/R addresses of the members of a DL (both of which are outside the scope of these Recommendations). As an alternative, a user can use the directory name and have MHS access a directory to resolve the corresponding O/R address or addresses automatically as described in РSР 14. а H аС СAn MH user or DL will not necessarily have a directory name, unless they are registered in a directory. As directories become more prevalent, it is expected that directory names will be the preferred method of identifying MHS users to each other. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа12.3Т№  ТУУO/R namesЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СEvery MH user or DL will have one or more O/R name(s). An O/R name comprises a directory name, and O/R address, or both. а H аС СEither or both components of an O/R name can be used on submission of a message. If only the directory name is present, MHS will access a directory to attempt to determine the O/R address, which it will then use to route and deliver the message. If a directory name is absent, it will use the O/R address as given. When both are given on submission, MHS will use the O/R address, but will carry the directory name and present both to the recipient. If the O/R address is invalid, it will then attempt to use the directory name as above. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа12.4Т№  ТУУO/R addressesЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СAn O/R address contains information that enables MHS to uniquely identify a user to deliver a message or return a notification to him. (The prefix Р"РO/RР"Р recognizes the fact that the user can be acting as either the originator or recipient of the message or notification in question.) С СAn O/R address is a collection of information called attributes. Recommendation X.402 specifies a set of standard attributes from which O/R addresses can be constructed. Standard attributes mean that their syntax and semantics are defined in Recommendation X.402. In addition to standard attributes, and to cater for existing messaging systems, there are domain defined attributes whose syntax and semantics are defined by management domains. С СVarious forms of O/R addresses are defined, each serving their own purpose. These forms and their purpose are as follows: а H аТа ТР-РТ№ ТУУMnemonic O/R address:ФФ Provides a userР-Рfriendly means of identifying users in the absence of a directory. It is also used for identifying a distribution list.ЦЦ а Hx аТа ТР-РТ№ ТУУTerminal O/R address:ФФ Provides a means of identifying users with terminals belonging to various networks.ЦЦ а H аТа ТР-РТ№ ТУУNumeric O/R address:ФФ Provides a means of identifying users by means of numeric keypads.ЦЦ а H аТа ТР-РТ№ ТУУPostal O/R address:ФФ Provides a means of identifying originators and recipients of physical messages.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У13Тр  ТMHS use of directoryФ ФЦЦ 13.1Т№  ТУУIntroductionФФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe directory defined by the X.500Р-РSeries of Recommendations provides capabilities useful in the use and provision of a variety of telecommunication services. This clause describes how a directory can be used in messages handling. Details can be found in other X.400 Recommendations. С СThe directory capabilities used in message handling fall into the following four categories: а H аТа ТТ№ ТС€ Сa)СpСУУUserР-Рfriendly naming:ФФ The originator or recipient of a message can be identified by means of his directory name, rather than his machine oriented O/R address. At any time MHS can obtain the latter from the former by consulting the directory.ЦЦ а H аТа ТТ№ ТС€ Сb)СpСУУDistribution lists (DLs):ФФ A group whose membership is stored in the directory can be used as a DL. The originator simply supplies the name of the list. At the DL's expansion point MHS can obtain the directory names (and then the O/R addresses) of the individual recipients by consulting the directory.ЦЦ а H аТа ТТ№ ТС€ Сc)СpСУУRecipient UA capabilities:ФФ MHS capabilities of a recipient (or originator) can be stored in his directory entry. At any time MHS can obtain (and then act upon) those capabilities by consulting the directory.ЦЦ а H аТа ТТ№ ТС€ Сd)СpСУУAuthentication:ФФ Before two MHS functional entities (two MTAs, or a UA and an MTA) communicate with one another, each establishes the identity of the other. This can be done by using authentication capabilities of MHS based on information stored in the directory.ЦЦ а Hx аС СBesides the above, one user can directly access the directory, for example, to determine the O/R address or MHS capabilities of another. The recipient's directory name is supplied to the directory, which returns the requested information.д Д-дŒаЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа13.2Т№  ТУУFunctional modelЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СBoth UAs and MTAs can use the directory. A UA can present the directory with the directory name of the intended recipient, and obtain from the directory the recipient's O/R address. The UA can then supply both the directory name and the O/R address to the MTS. Another UA can supply just the recipient's directory name to the MTS. The MTS would then itself ask the directory for the recipient's O/R address and add it to the envelope. The originating MTA normally carries out the name to O/R address look up. С СA functional model depicting the above is shown in Figure 12/X.400. ‚Ср GСб cмˆ4 PŽТ бFigure 12/X.400 Љ CCITT Љ 0100422Љ88 б cмˆ4 PŽТ б аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа13.3Т№  ТУУPhysical configurationsЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СSome possible physical configurations of the above functional model are shown in Figure 13/X.400. Where a directory user agent (DUA) and directory system agent (DSA) reside in physically separate systems, a standard directory protocol, defined in the X.500Р-РSeries of Recommendations, governs their interactions. It will often be desirable to physically coР-Рlocate a UA or MTA with a DUA/DSA. However, other physical configurations are also possible. ‚Ср GСб cмˆ4 PŽТ бFigure 13/X.400 Љ CCITT Љ 0100431Љ88 б cмˆ4 PŽТ б аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH јP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТX  ТТX јТС€  СС€ HСУ У14С   Сб cмˆ4 PŽТ бDistribution lists in MHSЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бФ Ф14.1Т№  ТУУIntroductionЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe ability to make use of a distribution list (DL) is an optional capability of MHS provided through the MT service. DL expansion allows a а H аsender to have a message transmitted to a group of recipients, by naming the group instead of having to enumerate each of the final recipients. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа14.2Т№  ТУУProperties of a DLЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe properties of a DL can be described as follows: а H аТа ТР-РТ№ ТУУDL members:ФФ Users and other DLs that will receive messages addressed to the DL.ЦЦ а H аТа ТР-РТ№ ТУУDL submit permission:ФФ A list of users and other DLs which are allowed to make use of the DL to send messages to the DL's members.ЦЦ а H аТа ТР-РТ№ ТУУDL expansion point:ФФ Each DL has an unambiguous O/R address. This O/R address identifies the expansion point, which is the domain or MTA where the names of the members of the DL are added to the recipient list. The message is transported to the expansion point before expansion as shown in Figure 14/X.400.ЦЦ а Hh аТа ТР-РТ№ ТУУDL owner:ФФ A user who is responsible for the management of a DL.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа14.3Т№  ТУУSubmissionЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СSubmission of a message to a DL is similar to the submission of a message to a user. The originator can include in the DL's O/R name, the directory name, the O/R address, or both (see РSР 12 for details). The originator need not be aware that the O/R name used is that of a DL. The originator can, however, through use of the element of service, DL expansion prohibited, prohibit the MTS from expanding a message unknowingly addressed to a DL. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа14.4Т№  ТУУDL use of a directoryЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СA directory may or may not be used to store information about the properties of a DL. Among the information that can be stored are the following: DL members, DL owner, DL submit permission and the DL expansion point. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа14.5Т№  ТУУDL expansionЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СAt the expansion point, the MTA responsible for expanding the DL will: а H аТа ТТ№ ТС€ Сa)СpСLook up the information about the DL, e.g. in the directory, using access rights granted to the MTA. (УУNoteФФ Р-Р Since this is done by the MTA at the expansion point, support of DLs in MHS does not require a globally interconnected directory).ЦЦ а H аТа ТТ№ ТС€ Сb)СpСVerify whether expansion is allowed by checking the identity of the sender against the DL's submit permission.ЦЦ а H аТа ТТ№ ТС€ Сc)СpСIf expansion is allowed, add the members of the DL to the list of recipients of the message and transmit the message to them.ЦЦ а HH а‚Ср8@Сб cмˆ4 PŽТ бFigure 14/X.400 Љ CCITT Љ 0706800Љ89 б cмˆ4 PŽТ б аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH јP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа14.6Т№  Тб cмˆ4 PŽТ бУУNestingФФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бС СA member of a DL can be another DL as shown in Figure 14/X.400. In this case the message is forwarded from the expansion point of the parent DL to the expansion point of the member DL for further expansion. Thus during each expansion, only the members of a single DL are added to the message. а H аС СDuring expansion of a nested DL, the identity of the parent DL (e.g., DL1 in Figure 14/X.400) rather than that of the message originator, is compared against the submit permission of the member DL (e.g., DL2 in Figure 14/X.400). а H аС СУУNoteФФ Р-Р DL structures can be defined which reference a particular nested DL more than once at different levels of the nesting. Submission to such a parent DL can cause a recipient to receive multiple copies of the same message. The same result can occur if a message is addressed to multiple DLs which contain a common member. Correlation of such copies can be done at the recipient's UA, and/or in the MS. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа14.7Т№  ТУУRecursion controlЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СIf a certain DL is directly or indirectly a member of itself (a situation which can validly arise), or when DLs are combined with redirection, then a message might get back to the same list and potentially circulate infinitely. This is detected by the MTS and prevented from occurring. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа14.8Т№  ТУУDeliveryФФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СOn delivery of the message, the recipient will find out that he received the message as a member of a DL, and through which DL, or chain or DLs he got the message. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа14.9Т№  ТУУRouting loop controlЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СA message can be originated in one domain/MTA, expanded in a second domain/MTA, and then sent back to a DL member in the first domain/MTA. The MTS will not treat this as a routing loop error. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС14.10С јСУУNotificationsФФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СDelivery and nonР-Рdelivery notifications can be generated both at the DL expansion point (e.g. if submit permission is denied), and at delivery to the ultimate recipient. С СWhen a message coming from a DL generates a notification, this notification is sent to the DL from which the message came. The DL will then, depending on the policy of the list, forward the notification to the owner of а H аthe list, to the DL or originator from which it got the message, or both, as shown in Figure 15/X.400. ‚Ср HСб cмˆ4 PŽТ бFigure 15/X.400 Љ CCITT 0706810Љ89 б cмˆ4 PŽТ б а H аС СУУNoteФФ Р-Р When notifications are sent to the originator after DL expansion, the originator can receive many delivery/nonР-Рdelivery notifications for one originator specified recipient (the DL itself). The originator can even receive more than one notification from an ultimate recipient, if that recipient received the message more than once via different lists. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС14.11С јСУУDL handling policyЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СAn MTA may or may not provide different policies on DL handling. Such policies will control whether notifications generated at delivery to DL members should be propagated back through the previous DL, or to the originator if no such previous DL, and/or to this list owner. If the policy is such that notifications are to be sent only to the list owner, then the originator will receive notifications if requested, only during expansion of that DL. In order to accomplish this restriction, the MTS will, while performing the expansion, reset the notification requests according to the policy for the list. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH јP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТX  ТТX јТС€  СС€ HС‚У У15С   Сб cмˆ4 PŽТ бSecurity capabilities of MHSЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бФ Ф15.1Т№  ТУУIntroductionЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe distributed nature of MHS makes it desirable that mechanisms are available to protect against various security threats that can arise. The nature of these threats and the capabilities to counter them are highlighted below. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH јP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа15.2Т№  Тб cмˆ4 PŽТ бУУMHS security threatsФФЦЦ ТX  ТТX јТС€  СС€ HСб cмˆ4 PŽТ б15.2.1С јСб cмˆ4 PŽТ бУУAccess threatsФФд Д- дЦЦŒа H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бС СInvalid user access into MHS is one of the prime security threats to the system. If invalid users can be prevented from using the system, then the subsequent security threat to the system is greatly reduced. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH јP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТX  ТТX јТС€  СС€ HС15.2.2С јСб cмˆ4 PŽТ бУУInterР-Рmessage threatsЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФб cмˆ4 PŽТ бС СInterР-Рmessage threats arise from unauthorized agents who are external to the message communication, and can manifest themselves in the following ways; а H аТа ТР-РТ№ ТУУMasquerade:ФФ A user who does not have proof of whom he is talking to can be easily misled by an imposer into revealing sensitive information.ЦЦ а H аТа ТР-РТ№ ТУУMessage modification:ФФ A genuine message which has been modified by an unauthorized agent while it was transferred through the system can mislead the message recipient.ЦЦ а H аТа ТР-РТ№ ТУУReplay:ФФ Messages whose originators and contents are genuine can be monitored by an unauthorized agent and could be recorded to be replayed to the message's intended recipient at a later date. This could be done in order to either extract more information from the intended recipient or to confuse him.ЦЦ а H аТа ТР-РТ№ ТУУTraffic analysis:ФФ Analysis of message traffic between MH users can reveal to an eavesdropper how much data (if any) is being sent between users and how often. Even if the eavesdropper cannot determine the actual contents of the messages, he can still deduce a certain amount of information from the rate of traffic flow (e.g. continuous, burst, sporadic or none).ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH јP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТX  ТТX јТС€  СС€ HС15.2.3С јСб cмˆ4 PŽТ бУУIntraР-Рmessage threatsФФЦЦ а Hр ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бС СIntraР-Рmessage threats are those performed by the actual message communication participants themselves, and can manifest themselves in the following ways: а H аТа ТР-РТ№ ТУУRepudiation of messages:ФФ One of the actual communication participants can deny involvement in the communication. This could have serious implications if financial transactions were being performed via MHS.ЦЦ а H аТа ТР-РТ№ ТУУSecurity level violation:ФФ If a management domain within MHS employs different security clearance levels (e.g. public, personal, private and company confidential) then users must be prevented from sending or receiving any messages for which they have an inadequate security clearance level if the management domain's security is not to be compromised.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH јP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТX  ТТX јТС€  СС€ HС15.2.4С јСб cмˆ4 PŽТ бУУData store threatsЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бФФС СAn MHS has a number of data stores within it that must be protected from the following threats: а H аТа ТР-РТ№ ТУУModification of routing information:ФФ Unauthorized modification of the directory's contents could lead to messages being misР-Рrouted or even lost while unauthorized modification to the deferred delivery data store or the hold for delivery data store could mislead or confuse the intended recipient.ЦЦ а H аТа ТР-РТ№ ТУУPreplay:ФФ An unauthorized agent could make a copy of a deferred delivery message and send this copy to the intended recipient while the original was still being held for delivery in the MTA. This could fool the message recipient into replying to the message originator before the originator was expecting a reply or simply mislead or confuse the original intended message recipient.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH јP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа15.3Т№  Тб cмˆ4 PŽТ бУУSecurity modelЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бФФС СSecurity features can be provided by extending the capabilities of the components in the message handling system to include various security mechanisms. С СThere are two aspects to security in message handling: secure access management and administration, and secure messaging. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС15.3.1С јСУУSecure access management and administrationЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe capabilities in this section cover the establishment of an authenticated association between adjacent components, and the setting up of security parameters for the association. This can be applied to any pair of components in the message handling system: UA/MTA, MTA/MTA, MS/MTA, etc. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС15.3.2С јСУУSecure messagingЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe capabilities in this section cover the application of security features to protect messages in the message handling system in accordance with а H аa defined security policy. This includes elements of service enabling various components to verify the origin of messages and the integrity of their content, and elements of service to prevent unauthorized disclosure of the message content. С СThe capabilities in this section cover the application of security features to protect messages directly submitted to the message transfer system by a user agent, message store, or an access unit. They do not cover the application of security features to protect communication between users and the message handling system, or MH user-toР-РMH user communication (a large part of MH userР-РtoР-РMH user communication is protected between two UAs). Thus they do not apply, for example, to communication between a remote user's terminal and its UA, or to communication between these users' terminal equipment and other users in the MHS. Security capabilities to protect MH userР-РtoР-РMH user communication are for further study. а H аС СMany of the secure messaging elements of service provide an originator to recipient capability, and require the use of user agents with security capabilities. They do not require the use of a message transfer system with security features. (As an example, content confidentiality can be applied by enciphering the message content by the originator, and deciphering by the recipient, with various security parameters transferred within the message envelope. Such a message can be transferred by an MTS which can handle the format of the content (unformatted octets), and transparently handle the security fields in the envelope.) а H аС СSome of the secure messaging elements of service involve an interaction with the message transfer system, and require the use of message transfer agents with security capabilities. (As an example, nonР-Рrepudiation of submission requires the MTA, to which the message is submitted, to contain mechanisms to generate a proof of submission field.) а H аС СSome of the secure messaging elements of service apply to the MS as well as UAs and MTAs, such as message security labelling. In general, however, the MS is transparent to security features that apply between the originators' and the recipients' UAs. а H аС СThe scope of the secure messaging elements of service is given in Table 2/X.400. This describes the elements of service in terms of which MHS component is the Р"РproviderР"Р or which is the Р"РuserР"Р of the security service. For example, probe origin authentication is provided by the originating UA, and can be used by the MTAs through which the probe passes. а H аС СThis Recommendation describes the use of security services by the UA, and the MTA. How these features are applied to access units is for further study. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH јP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа15.4Т№  Тб cмˆ4 PŽТ бУУMHS security capabilitiesЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бФФС СThe elements of service describing the security features of MHS are defined in Annex B, and classified in РSР 19. An overview of these capabilities is as follows: а Hx аТа ТР-РТ№ ТУУMessage origin authentication:ФФ Enables the recipient, or any MTA through which the message passes, to authenticate the identity of the originator of a message.ЦЦ а H аТа ТР-РТ№ ТУУReport origin authentication:ФФ Allows the originator to authenticate the origin of a delivery/nonР-Рdelivery report.ЦЦ а H аТа ТР-РТ№ ТУУProbe origin authentication:ФФ Enables any MTA through which the probe passes, to authenticate the origin of the probe.ЦЦ а H аТа ТР-РТ№ ТУУProof of delivery:ФФ Enables the originator of a message to authenticate the delivered message and its content, and the identity of the recipient(s).ЦЦ Та ТР-РТ№ ТУУProof of submission:ФФ Enables the originator of a message to authenticate that the message was submitted to the MTS forд Д- д delivery to the originally specified recipient(s).ЦЦ а H аТа ТР-РТ№ ТУУSecure access management:ФФ Provides for authentication between adjacent components, and the setting up of the security context.ЦЦ а H аТа ТР-РТ№ ТУУContent integrity:ФФ Enables the recipient to verify that the original content of a message has not been modified.ЦЦ а H аТа ТР-РТ№ ТУУContent confidentiality:ФФ Prevents the unauthorized disclosure of the content of a message to a party other than the intended recipient.ЦЦ а H аТа ТР-РТ№ ТУУMessage flow confidentiality:ФФ Allows the originator of a message to conceal the message flow through MHS.ЦЦ а H аТа ТР-РТ№ ТУУMessage sequence integrity:ФФ Allows the originator to provide to a recipient proof that the sequence of messages has been preserved.ЦЦ а H аТа ТР-РТ№ ТУУNonР-Рrepudiation of origin:ФФ Provides the recipient(s) of a message with proof of origin of the message and its content which will protect against any attempt by the originator to falsely deny sending the message or its content.ЦЦ а H аТа ТР-РТ№ ТУУNonР-Рrepudiation of delivery:ФФ Provides the originator of a message with proof of delivery of the message which will protect against any attempt by the recipient(s) to falsely deny receiving the message of its content.ЦЦ а H аТа ТР-РТ№ ТУУNonР-Рrepudiation of submission:ФФ Provides the originator of a message with proof of submission of the message, which will protect against any attempt by the MTS to falsely deny that the message was submitted for delivery to the originally specified recipient(s).ЦЦ а H аТа ТР-РТ№ ТУУMessage security labelling:ФФ Provides a capability to categorize a message, indicating its sensitivity, which determines the handling of a message in line with the security policy in force.ЦЦ а HH а‚Ср8LСб cмˆ4 PŽТ бTABLE 2/X.400 а H аСр5СУ УProvision and use of secure messaging elements of service by MHS componentsФ Ф б cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡Ср PСб cмˆ4 PŽТ бElements of service Ср TСOriginating Ср UСMTS user Ср XСMTS Ср UСRecipient Ср UСMTS user а 0 ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџpи P Ј XА`И0hР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0 аб cмˆ4 PŽТ бMessage origin authentication Ср:а ŒСP Ср:а ŒСU Ср:а ŒСU а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0 аб cмˆ4 PŽТ бReport origin authentication Ср:а ŒСU Ср:а ŒСP Ср:а ŒСР-Р а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0 аб cмˆ4 PŽТ бProbe origin authentication Ср:а ŒСP Ср:а ŒСU Ср:а ŒСР-Р а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0а аб cмˆ4 PŽТ бProof of delivery Ср:h†СU Ср:h†СР-Р Ср:h†СP а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0р аб cмˆ4 PŽТ бProof of submission Ср:рˆСU Ср:рˆСP Ср:рˆСР-Р а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0 аб cмˆ4 PŽТ бSecure access management Ср:а ŒСP Ср:а ŒСU Ср:а ŒСP а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0а аб cмˆ4 PŽТ бContent integrity Ср:h†СP Ср:h†СР-Р Ср:h†СU а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0 аб cмˆ4 PŽТ бContent confidentiality Ср:а ŒСP Ср:а ŒСР-Р Ср:а ŒСU а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0 аб cмˆ4 PŽТ бMessage flow confidentiality Ср:а ŒСP Ср:а ŒСР-Р Ср:а ŒСU а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0 аб cмˆ4 PŽТ бMessage sequence integrity Ср:а ŒСP Ср:а ŒСР-Р Ср:а ŒСU а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0 аб cмˆ4 PŽТ бNonР-Рrepudiation of origin Ср:а ŒСP Ср:а ŒСР-Р Ср:а ŒСU а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0 аб cмˆ4 PŽТ бNonР-Рrepudiation of submission Ср:а ŒСU Ср:а ŒСP Ср:а ŒСР-Р а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0 аб cмˆ4 PŽТ бNonР-Рrepudiation of delivery Ср:а ŒСU Ср:а ŒСР-Р Ср:а ŒСP а 0 аб cмˆ4 PŽТ бˆа 0 аб cмˆ4 PŽТ бвЦ„HXHјpИ0X Цв‡а 0 аб cмˆ4 PŽТ бMessage security labelling Ср:а ŒСP Ср:а ŒСU Ср:а ŒСU а 0 аб cмˆ4 PŽТ бˆа HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH8(pи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаадаб cмˆ4 PŽТ бС8 СPС pСThe MHS component is a provider of the service С8 СUС pСThe MHS component is a user of the service. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаааб cмˆ4 PŽТ б15.5Т№  ТУУSecurity managementЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СAspects of an asymmetric key management scheme to support the above features are provided by the directory system authentication framework, described in Recommendation X.509. The directory stores certified copies of public keys for MHS users which can be used to provide authentication and to facilitate key exchange for use in data confidentiality and data integrity mechanisms. The certificates can be read from the directory using the directory access protocol described in Recommendation X.519. С СRecommendations for other types of key management schemes, including symmetric encryption, to support the security features are for further study. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH јP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТX  ТТX јТС€  СС€ HС‚У У16С   Сб cмˆ4 PŽТ бConversion in MHSЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бФ ФС СThe MTS provides conversion functions to allow users to input messages in one or more encoded formats, called encoded information types (EITs), and have them delivered in other EITs to cater to users with various UA capabilities and terminal types. This capability is inherent in the MTS and increases the possibility of delivery by tailoring the message to the recipient's terminal capabilities. The EITs standardized in MHS are listed in Recommendation X.411. Conversions and the use of the elements of service relating to conversion are available for EITs not defined in Recommendation X.411, but supported by certain domains, either bilaterally between these domains or within a domain itself. а H аС СMHS users have some control over the conversion process through various elements of service as described in Annex B. These include the ability for a user to explicitly request the conversion required or as a default to let the MTS determine the need for conversion, and the type of conversion performed. Users also have the ability to request that conversion not be performed or that conversion not be performed if loss of information will result. Whenд Д- д the MTS performs conversion on a message it informs the UA to whom the message is delivered that conversion took place and what the original EITs were. а H аС СThe conversion process for IPР-Рmessages can be performed on body parts of specific types if they are present in a message. The general aspects of conversion and the specific conversion rules for conversion between different EITs are detailed in Recommendation X.408. а H аС СRecommendation X.408 deals with conversion for the following: telex, IA5 text, teletex, G3fax, G4 Class1, videotex, voice, and mixed mode. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџH јP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТX  ТТX јТС€  СС€ HС‚У У17С   Сб cмˆ4 PŽТ бUse of the MHS in provision of public servicesЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаб cмˆ4 PŽТ бФ ФС СThe message handling system is used in the provision of public MH services that are offered by Administrations for use by their subscribers. These public MH services are defined in the F.400Р-РSeries Recommendations and include: Та ТР-РТ№ Тthe public message transfer service (Rec. F.410);ЦЦ Та ТР-РТ№ Тthe public interpersonal messaging service (Rec. F.420).ЦЦ а H аС СIn addition complementary public services are offered by Administrations to allow for the intercommunication between CCITT services and the public MH services mentioned above, as follows: а H аТа ТР-РТ№ Тintercommunication with public physical delivery services (Rec. F.415).ЦЦ а H аТа ТР-РТ№ Тintercommunication between the IPM service and the telex service (Rec. F.421);ЦЦ а H аТа ТР-РТ№ Тintercommunication between the IPM service and the teletex service (Rec. F.422);ЦЦ а H аС СRecommendation F.401 describes the naming and addressing aspects for public MH services.