CEPT T CD 09-01 E-1988 Protocol for Interpersonal Messaging between Transfer Agent Accessing the Public Message Handling Service《接入公共消息处理业务的传输代理间人际消息发送协议》.pdf

1、CEPT T/CD*OS-OL*E 6 I 2326434 O004406 3 09-01 Page E 1 Recommendation T/CD 09-01 (Odense 1986, revised Copenhagen 1987) PROTOCOL FOR INTERPERSONAL MESSAGING BETWEEN MESSAGE TRANSFER AGENTS ACCESSING THE PUBLIC MESSAGE HANDLING SERVICE Recommendation proposed by Working Group T/WG 10 “Terminal equipm

2、ent” (TE) Text of the Recommendation adopted by the “Telecommtinications” Commission: “The Conference of European Post and Telecommunications Administrations, considering - the work undertaken within CEPT with the view to harmonising international telecommunication services as well - that Message Ha

3、ndling services are being implemented or will be implemented in the future, - that CCITT Recommendations X.400, X.401, X.408, X.409, X.410, X.411, X.420 describe various aspects of - that TD/MHS has studied the requirements for a functional standard as requested by CCH in 1985 and under as equipment

4、, Message Handling, question CD 7, recommends to the members of the CEPT, which intend to introduce the Message Handling service, to apply the following specification.” Note. It should be noted that this Recommendation may be revised from time to time. Edition of February 10, 1988 7 I I - _ _- - .-

5、- -. -_I_- a separate classification is given for origination and reception. The following classes are recognised: SUPPORT = S This means: i) that the service provider makes the service element available to the service user; i;) that the service user gives adequate support to the user of the MHS to

6、invoke the service element or make information associated with the service element available. Support for Origination means : i) that the service provider makes the service element available to the service user for invocation; ii) that the service user gives adequate support to the user of the MHS t

7、o invoke the service element or make information associated with the service element available. Support for Reception means : i) that the service provider makes infoimation associated with the service element available to the service user. Note that a service element can only carry information from

8、originator to recipient if (1) the service element is available to the originator and (2) the service element is available to the recipient and (3) all intermediate steps carry the information. This means that the service provider is not required to make the service element available to the service

9、user. However, the service provider should not regard the occurrence of the corresponding protocol elements as an error, and should be able to relay such elements. This means that although the standards allow this service element, this functional standard does not use it. This means that the service

10、 element is not applicable at this point (origination or reception point). 4.1.1. Definition of Service ClassiJication NON-SUPPORT N NOTUSED = NU NOT APPLICABLE = NA 4.1.2. Definition of Protocol ClassiJication The classification of protocol elements defines characteristics of their occurrence in PD

11、Us and on the ability of equipment to manipulate them. The classification of each protocol element is relative with respect to its containing element. UNSUPPORTED = X These elements may be generated, but no specific processing should be expected in a relaying or delivering domain. A relaying domain

12、must at least relay the semantics of the element. The absence of these elements should not be assumed, in a relaying or delivering domain, to convey any significance. SUPPORTED = H These elements may be generated. However, implementations are not required to be able to generate these elements. Appro

13、priate actions shall be taken in a relaying or delivering domain. GENERATABLE = G Implementations must be able to generate and handle these protocol elements, although they are not necessarily present in all PDUs generated by implementations of this functional standard. Appropriate actions shall be

14、taken in a relaying or delivering domain. Conditions for generation are indicated in the functional standard. REQUIRED = R Implementations of this functional standard must always generate this protocol element. However, its absence cannot be regarded as a protocol violation as other MHS implementati

15、on may not require this protocol element. Appropriate actions shall be taken in a relaying or delivering domain. Edition of February IO, 1988 I T/CD 09-01 E Page 7 MANDATORY = M Must occur in each PDU as given in the reference standards; absence is a protocol violation. Appropriate actions shall be

16、taken in a relaying or delivering domain. 5. ABBREVIATIONS The following list of abbreviations are used in this Functional Standard in addition to some of those from the reference documents: CEN Comit Europen de Normalisation CENELEC chars characters Fax Facsimile ffS for further study ref reference

17、 std standard TSDU Transport Service Data Unit The following list of abbreviations are used in the reference documents, some of these abbreviations are also used in this functional standard: Comit Europen de Normalisation Electrotechnique A ADMD AE APDU BNF BS CCITT CR DCS DIF E EOC FF FIF FS G3 G3

18、Fax HT IA IA5 ID IGS ITA IPM IPMS LSB MSB LF MD MH MHS MPDU MT MTA MTL MTAE MTS NA NDN cc IM-UAPDU Il0 Edition of February LO, 1988 Additional Optional User Facility Administration Management Domain Application Entity Application Protocol Data Unit Backus-Naur Form Backspace courtesy copy Internatio

19、nal Telegraph and Telephone Consultative Committee Carriage Return Digital Command Signal Document Interchange Format . Essential Optional User Facility End-of-contents Form Feed Facsimile Information Field Further Study Group 3 Group 3 Facsimile Horizontal Tabulation International Alphabet Internat

20、ional Alphabet No. 5 Identifier/Identification Identify Graphic Subrepertoire IF-message User Agent Protocol Data Unit International Telegraph Alphabet Input/Output Interpersonal Messaging Interpersonal Messaging System Least Significant Bit Most Significant Bit Line Feed Management Domain Message H

21、andling Message Handling System Message Protocol Data Unit Message Transfer Message Transfer Agent Message Transfer Layer Message Transfer Agent Entity Message Transfer System Not Applicable Non-delivery Notification -. I CEPT T/CD*Qq-Q1*E 86 = 232b414 0004413 O E T/CD 09-01 E Page 8 NSDU OPDU os1 P

22、I P2 P3 Pc PDU PRMD PFS PLD PLU Pt RLF RTS SDE SFD SGR SHS SMPDU SP SPDU SR-UAPDU SSDU SUB svs TDF TIF TIFO TIF 1 TLX TTX TPDU TSAP UA UAE UAL UAPDU UTC VT O/R Network Service Data Unit Operation Protocol Data Unit Originator/Recipient Open Systems Interconnection Message Transfer Protocol Interpers

23、onal Messaging Protocol Submission and Delivery Protocol Family of Content Protocols Protocol Data Unit Private Management Domain Page Format Selection Partial Line Down Partial Line Up Family of Interactive Terminal to System Protocols Reverse Line Feed Reliable Transfer Server Submission and Deliv

24、ery Entity Simple Formattable Document Type Select Graphic Rendition Select Horizontal Spacing Service Message Protocol Data Unit Space Session Protocol Data Unit Status Report User Agent Protocol Data Unit Session Service Data Unit Substitute Character Select Vertical Spacing Time Differential Fact

25、or Text Interchange Format Text Interchange Format 0 Text Interchange Format 1 Telex Type Teletex Type Transport Protocol Data Unit Transport Service Access Point User Agent User Agent Entity User Agent Layer User Agent Protocol Data Unit Universal Co-ordinated Time Vertical Tabulation 6. SCENARIO D

26、ESCRIPTION This Functional Standard describes services of and communications between: MTAEs (Message Transfer Agent Entities using P1 protocol) and UAEs (User Agent Entities using P2 protocol) of which at least one of the MTAEs belongs to an ADiMD: see Figure 1 (T/CD 09-01). For the overall protocol

27、 structure of this Functional Standard refer to Figure 2 (T/CD 09-01). End User Services and local UA functions are not part of this Functional Standard, neither are the protocols and interfaces used for interaction between the users and their UAs, nor between UAs and non-collocated MTAs. An ADMD th

28、at implements this Functional Standard must relay all the protocol elements of the Functional Standard ENV 41 201 (function A/321 i). Relaying of other protocol elements is outside the scope of this Functional Standard. The formats (e.g. document format) interchanged between users of this Functional

29、 Standard are not a part of this Functional Standard, though reference is made ot appropriate Q/- Functions. Edition of February 10, 1988 CEPT T/CD*OS-OL*E 86 232b414 O04434 2 = - T/CD 09-01 E Page 9 DOMAIN Y Public DOMAIN Z Private or Public MTA- - - - UA GA UA A/3 1 1 Notes: (I) Domain Y may optio

30、nally contain UAs. (2) A relaying domain only provides the message transfer service as described in clause 8. Figure 1 (T/CD 09-01). Interconnection using A/311. I User Agent Layer X.420 I Message Transfer Agent Layer X.411 1 Reliable Transfer Server X.410 Presentation Layer See Note (3) Session Lay

31、er X.225 Note: (3) X.410 defines a minimum presentation layer for use by the RTS. Figure 2 (T/CD 09-01). Model of Functional Standard A/311. 7. USER AGENT LAYER (UAL) This classification is based on p.4011 classification for service elements and specifies support for the Basic IPM services and the E

32、ssential IPM Optional user facilities in p.4011. No support is required for the Additional user facilities. 7.1. Functional Standard Classification for the User Agent Layer This clause of the Functional Standard defines the required support for services and protocol elements for interpersonal messag

33、ing. The classification scheme is described in clause 4. 7.2. UA Service Table 1 (T/CD 09-01) indicates the support for UA-service elements required by this Functional Standard, using the classification in clause 4.1.1. Distinction is made between “Support for Origination” and “Support for Reception

34、”. Table 2 (T/CD 09-01) indicates the service elements which originate from the Message Transfer Service and are made available to the UA service. O Edition of February 10, 1988 ” 1 CEPT T/CD*09-01*E 6 e 2326434 0004435 4 T/CD 09-01 E Page 10 Element IP-message Identification Typed Body Blind Copy R

35、ecipient Indication Non-receipt Notification Receipt Notification Auto-forwarded Indication Originator Indication Authorizing Users Indication Primary and Copy Recipients Indication Expiry Date Indication Cross referencing Indication Importance Indication Obsoleting Indication Sensitivity Indication

36、 Subject Indication Replying IP-message Indication Reply Request Indication Forwarded IP-message Indication Body Part Encryption Indication Multi-part Body Element Origination S S N N N N S N S N N N N N S S N N N N Reception Table 1 (T/CD 09-01). Support for UA Service Elements. Access Management C

37、ontent Type Indication Converted Indication Delivery Time Stamp Indication Message Identification Non-delivery Notification Original Encoded Information Type Indication Registered Encoded Information Types Submission Time Stamp Indication Alternate Recipient Allowed Deferred Delivery Deferred Delive

38、ry Cancellation Delivery Notification Disclosure of Other Recipients Grade of Delivery Selection Multi-destination Delivery Prevention of Non-delivery Notification Return of Contents Conversion Prohibition Explicit Conversion Implicit Conversion Probe Alternate Recipient Assignment Hold for Delivery

39、 Origination NU (1) S NA NA S S S NA S N N (1) N (1) S N S S N N S N N N NA NA S S S N N S S S S S S S S S S S S S S S Reception Notes: (i) Originator domain local matter. (2) Recipient domain local matter. Table 2 (T/CD 09-01. Support for UA Service Elements originating from the MTS. Edition of Feb

40、ruary 10, 1988 CEPT T/CD*OS-OL*E 8b 232b4L4 OOOY4Lb b = T/CD 09-01 E Page 11 7.3. Protocol P2 Table 3 (T/CD 09-01) classifies the support and length restrictions for the protocol elements of P2 required by this Functional Standard, using the classification in section 5.1.2. Element UAPDU IM-UAPDU SR

41、-UAPDU IM-UAPDU Heading Body Heading IPMessageid originator authorizingusers primar y Recipients copy Recipients blindcopy Recipien inReplyTo obsoletes crossReferences subject expiryDate replyBy replyToUsers importance sensitivity autoforwarded IPMessageid ORName Printablestring ORDescriptor ORName

42、freeFonnName telephoneNumber ORDescriptor reportRequest reply Request Recipient o Edition of February 10, 1988 Class G X M M M R H G G H G H H G H H H H H H H M H H H M X H Restrictions At least primaryRecipients or copyRecipients or - blindCopyRecipients must be present. Max. 128 chars, graphic sub

43、set only. T.61 encoding means that more than 256 octets may be required. Max. 64 chars. Max. 64 chars, graphic subset only. One of the elements ORName or freeFormName must be present. T.61 encod- ing means that at most 128 octets may be required. Max. 32 chars. Support for all bits defned in this el

44、ement: X. _- Comments Generated to transfer an IP-message. Status report can only be issued if specifically requested in the original message. In this case the subsequent SR-UAPDU should be regarded as H. Generated if primary (secondary) Recipients are indicated. Generated when ReplyingIPMessage is

45、invoked. Generated when Subject indi- cation is invoked. Recipient UA may choose to present either or both of ORName and freeFormName. Punctuation is allowed. .CEPT T/CD*BS-OL*E 86 H 232b4L4 0004437 8 E T/CD 09-01 E Page 12 Element Body BodyPart nonReceipt SR-UAPDU receipt reported actualRecipient i

46、ntendedliecipient converted NonReceiptInformation reason nonReceiptQualifier comments returned ReceiptInformation receipt typeOfReceipt SupplementaryInformation Class M H H H M R H X M H H X M H X Restrictions I Comments See 1.4. At least one of the elements nonReceipt and receipt must be present. M

47、ax. 256 chars. This element can only be present if specifically reques- ted in the original message. In this case it shall be regarded as H. Max. 64 chars. Table 3 (T/CD 09-01). P2-Protocol Elements. 7.4. Body Parts All body parts with identifiers in the range O up to and including 30 should be rela

48、yed. The values in the range O through 11 should identify Body Parts types named in this Functional Standard, the values 12 through 30 are reserved for future definition. The value 14 is reserved for “unidentified”. In addition the following categories of body types may be used between cooperating u

49、ser agents: - IA5 text 41211, 41212 - TTX (T.61) - TIF.0 QI1 13, 41221 - TIF.l QI1 14, QI222 - G3 Fax - Videotex 4/24 1 - Voice - Encrypted - Nationally defined A non-delivery notification should be returned if the message could not be delivered on account of the body type contained in it. All MDs should support IAS. In addition all ADMDs should support the reception of Teletex for delivery to its own UAEs. If an implementation supports a particular Body Part type for reception, it should also be able to support that Body Part type for reception if this is part of a For