idnits 2.17.1 draft-rfced-info-banan-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 68 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 554: '...EMSD-P through ESRO MUST use UDP [6] port number 642 (esro-emsdp)....' RFC 2119 keyword, line 574: '... form of Length encoding MUST be used,...' RFC 2119 keyword, line 576: '... Length encoding MUST be used whenever...' RFC 2119 keyword, line 581: '... "Constructed", MUST always be encode...' RFC 2119 keyword, line 586: '...ding Type of "0" MUST be used in ESRO ...' (63 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1533 has weird spacing: '...e types defin...' == Line 2470 has weird spacing: '...mal" is assum...' == Line 3215 has weird spacing: '...e types defin...' == Line 3349 has weird spacing: '...mal" is assum...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The EMSD-UA MUST not refuse performing the deliver ES-OPERATION unless the delivery would violate the deliveryControl restrictions then in force. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1998) is 9326 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0' is mentioned on line 3455, but not defined -- Looks like a reference, but probably isn't: 'APPLICATION 2' on line 3160 -- Looks like a reference, but probably isn't: 'APPLICATION 3' on line 3161 -- Looks like a reference, but probably isn't: 'APPLICATION 4' on line 3230 -- Looks like a reference, but probably isn't: 'APPLICATION 5' on line 3232 -- Looks like a reference, but probably isn't: 'APPLICATION 0' on line 1610 -- Looks like a reference, but probably isn't: 'APPLICATION 1' on line 3284 == Missing Reference: '7' is mentioned on line 3395, but not defined == Missing Reference: '8' is mentioned on line 3401, but not defined == Missing Reference: '9' is mentioned on line 3408, but not defined ** Obsolete normative reference: RFC 1327 (ref. '3') (Obsoleted by RFC 2156) Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES JULY 1999 INTERNET DRAFT 3 Network Working Group M. Banan 4 I/D Neda Communications, Inc. 5 Category: Informational 6 October 1998 8 Neda's 9 Efficient Mail Submission and Delivery (EMSD) 10 Protocol Specification Version 1.3 11 13 File: 14 /usr/release/doc/nedaPublic/dataCom/emsd/emsdRfcs/emsdp-rfc/emsdp.ttytex,v 15 Document Revision: 1.23 16 Document Date: 1999/01/15 21:20:33 18 Status of This Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet- 28 Drafts as reference material or to cite them other than as 29 "work in progress." 31 To view the entire list of current Internet-Drafts, please check 32 the "1id-abstracts.txt" listing contained in the Internet-Drafts 33 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 34 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 35 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 36 (US West Coast). 38 Distribution of this document is unlimited. 40 ABSTRACT 42 This document specifies the protocol and format encodings for 43 Efficient Mail Submission and Delivery (EMSD). EMSD is a messaging 44 protocol that is highly optimized for submission and delivery of short 45 Internet mail messages. EMSD is designed to be a companion to 46 existing Internet mail protocols. 48 This specification narrowly focuses on submission and delivery of 49 short mail messages with a clear emphasis on efficiency. EMSD is 50 designed specifically with wireless network (e.g., CDPD, Wireless-IP, 51 Mobile-IP) usage in mind. EMSD is designed to be a natural 52 enhancement to the mainstream of Internet mail protocols when 53 efficiency in mail submission and mail delivery are important. As 54 such, EMSD is anticipated to become an initial basis for convergence 55 of Internet Mail and IP-based Two-Way Paging. 57 The reliability requirement for message submission and message 58 delivery in EMSD are the same as existing email protocols. EMSD 59 protocol accomplishes reliable connectionless mail submission and 60 delivery services on top of Efficient Short Remote Operations (ESRO) 61 protocols as specified in RFC-2188 [1]. 63 Most existing Internet mail protocols are not efficient. Most 64 existing Internet mail protocols are designed with simplicity and 65 continuity with SMTP traditions as two primary requirements. EMSD is 66 designed with efficiency as a primary requirement. 68 The early use of EMSD in the wireless environment is manifested as 69 IP-based Two-Way Paging services. The efficiency of this protocol 70 also presents significant benefits for large centrally operated 71 Internet mail service providers. 73 Contents 75 1 PRELIMINARIES 5 76 1.1 Internet Mail Submission and Delivery . . . . 5 77 1.2 Relationship Of EMSD To Other Mail Protocols . . . 5 78 1.3 EMSD Requirements and Goals . . . . . . . 7 79 1.4 Anticipated Uses Of EMSD . . . . . . . . 8 80 1.5 Definitions of Terms Used in this Specification . . 8 81 1.6 Conventions Used In This Specification . . . . 9 82 1.7 About This Specification . . . . . . . . 10 84 2 EFFICIENT MAIL SUBMISSION AND DELIVERY OVERVIEW 10 86 3 EFFICIENT MAIL SUBMISSION AND DELIVERY PROTOCOL 11 87 3.1 Use Of Lower Layers . . . . . . . . . 13 88 3.1.1 Use of ESROS . . . . . . . . . 13 89 3.1.2 Use Of UDP . . . . . . . . . . 13 90 3.1.3 Encoding Rules . . . . . . . . . 14 91 3.1.4 Presentation Context . . . . . . . 14 92 3.2 EMSD-UA Invoked Operations . . . . . . . 14 93 3.2.1 submit . . . . . . . . . . . 15 94 3.2.2 deliveryControl . . . . . . . . 17 95 3.2.3 deliveryVerify . . . . . . . . . 22 96 3.3 EMSD-SA Invoked Operations . . . . . . . 24 97 3.3.1 deliver . . . . . . . . . . 24 98 3.3.2 submissionControl . . . . . . . . 26 99 3.3.3 submissionVerify . . . . . . . . 29 100 3.4 EMSD Common Information Objects . . . . . . 31 101 3.4.1 SecurityElements . . . . . . . . 31 102 3.4.2 Message Segmentation and Reassembly . . . 31 103 3.4.3 Common Errors . . . . . . . . . 34 104 3.4.4 ContentType . . . . . . . . . 36 105 3.4.5 EMSDMessageId . . . . . . . . . 37 106 3.4.6 EMSDAddress . . . . . . . . . 37 107 3.4.7 DateTime . . . . . . . . . . 38 108 3.4.8 AsciiPrintableString . . . . . . . 38 109 3.4.9 ProtocolVersionNumber . . . . . . . 38 110 3.5 Submission and Delivery Procedures . . . . . 39 112 4 DUPLICATE OPERATION DETECTION SUPPORT 41 113 4.1 Duplicate Operation Detection Support Overview . . 41 114 4.1.1 Operation Value . . . . . . . . 42 115 4.1.2 Operation Instance Identifier . . . . . 42 117 5 EMSD PROCEDURE FOR OPERATIONS 44 118 5.1 MTS Behavior . . . . . . . . . . . 44 119 5.1.1 MTS Performer . . . . . . . . . 45 120 5.1.2 Message-submission . . . . . . . . 45 121 5.1.3 Delivery-control . . . . . . . . 47 122 5.1.4 Delivery-verify . . . . . . . . 47 123 5.1.5 MTS Invoker . . . . . . . . . 48 125 5.2 UA Behavior . . . . . . . . . . . 50 126 5.2.1 UA Performer . . . . . . . . . 51 127 5.2.2 UA Invoker . . . . . . . . . . 54 129 6 EMSD FORMAT STANDARDS 55 130 6.1 Format Standard Overview . . . . . . . . 55 131 6.2 Interpersonal Messages . . . . . . . . 56 132 6.2.1 Heading fields . . . . . . . . . 56 133 6.2.2 Body part types . . . . . . . . 62 135 7 ACKNOWLEDGMENTS 63 137 8 SECURITY CONSIDERATIONS 63 139 9 AUTHOR'S ADDRESS 63 141 A EMSD-P ASN.1 MODULE 64 143 B EMSD-IPM ASN.1 MODULE 74 145 C RATIONALE FOR KEY DESIGN DECISIONS 78 146 C.1 Deviation From The SMTP Model . . . . . . 78 147 C.1.1 Comparison of SMTP and EMSD Efficiency . . . 78 148 C.2 Use of ESRO Instead of TCP . . . . . . . 79 149 C.3 Use Of Remote Procedure Call (RPC) Model . . . . 80 150 C.4 Use Of ASN.1 . . . . . . . . . . . 80 152 D FURTHER DEVELOPMENT 80 153 1 PRELIMINARIES 155 Mail in the Internet was not a well-planned enterprise, but instead 156 arose in more of an "organic" way. 158 This introductory section is not intended to be a reference model and 159 concept vocabulary for mail in the Internet. Instead, it only 160 provides the necessary preliminaries for the concepts and terms that 161 are essential to this specification. 163 1.1 Internet Mail Submission and Delivery 165 For the purposes of this specification, mail submission is the process 166 of putting mail into the mail transfer system (MTS). 168 For the purposes of this specification, mail delivery is the process 169 of the MTS putting mail into a user's final mail-box. 171 Throughout the Internet, presently most of mail submission and 172 delivery is done through SMTP. 174 SMTP was defined as a message *transfer* protocol, that is, a means to 175 route (if needed) and deliver mail by putting finished (complete) 176 messages in a mail-box. Originally, users connected to servers from 177 terminals, and all processing occurred on the server. Now, a 178 split-MUA (Mail User Agent) model is common, with MUA functionality 179 occurring on both the user's own system and the server. 181 In the split-MUA model, getting the messages to the user is 182 accomplished through access to a mail-box on the server through such 183 protocols as POP and IMAP. In the split-MUA model, user's access to 184 its message is a "Message Pull" paradigm where the user is required to 185 poll his mailbox. Proper message delivery based on a "Message Push" 186 paradigm is presently not supported. The EMSD protocol addresses this 187 shortcoming with an emphasis on efficiency. 189 In the split-MUA model, message submission is often accomplished 190 through SMTP. SMTP is widely used as a message *submission* protocol. 191 Widespread use of SMTP for submission is a reality, regardless of 192 whether this is good or bad. EMSD protocol provides an alternative 193 mechanism for message submission which emphasizes efficiency. 195 1.2 Relationship Of EMSD To Other Mail Protocols 197 Various Internet mail protocols facilitate accomplishment of various 198 functions in mail processing. 200 Figure 1, categorizes the capabilities of SMTP, IMAP, POP and EMSD 201 based on the following functions: 203 +------------------+------+-------+-----+------+ 204 | Protocols| SMTP | IMAP | POP | EMSD | 205 |Functions | | | | | 206 |------------------|------|-------|-----|------| 207 |Submission | XX | | | XXX | 208 |------------------|------|-------|-----|------| 209 |Delivery | XXX | | | XXX | 210 |------------------|------|-------|-----|------| 211 |Relay (Routing) | XXX | | | | 212 |------------------|------|-------|-----|------| 213 |Retrieval | | XXX | XXX | XX | 214 |------------------|------|-------|-----|------| 215 |Mailbox Access | | XXX | X | | 216 |------------------|------|-------|-----|------| 217 |Mailbox Synch. | | XXX | | | 218 +------------------+------+-------+-----+------+ 220 Figure 1: Messaging Protocols vs. Supported Functions 222 o Mail Submission 224 o Mail Delivery 226 o Mail Routing (Relay) 228 o Mail Retrieval 230 o Mail-box Access 232 o Mail-box Synchronization 234 In Figure 1, the number of "X"es in each box denotes the extent to 235 which a particular function is supported by a particular protocol. 237 Figure 1 clearly shows that combinations of these protocols can be 238 used to complement each other in providing rich functionality to the 239 user. For example, a user interested in highly mobile messaging 240 functionalities can use EMSD for "submission and delivery of time 241 critical and important messages" and use IMAP for comprehensive access 242 to his/her mail-box. 244 For mail submission and delivery of short messages EMSD is up to 5 245 times more efficient than SMTP both in terms of the number of packets 246 transmitted and in terms of number of bytes transmitted. Even with 247 PIPELINING and other possible optimizations of SMTP, EMSD is up to 3 248 times more efficient than SMTP both in terms of the number of packets 249 transmitted and in terms of number of bytes transmitted. Various 250 efficiency studies comparing EMSD with SMTP, POP and IMAP are 251 available. See Section C.1.1 for more information about comparison of 252 SMTP and EMSD's efficiency. 254 1.3 EMSD Requirements and Goals 256 The requirements and goals driving design of EMSD protocol are 257 enumerated below. 259 1. Provide for submission of short mail messages with the same level 260 of functionality (or higher) that the existing Internet mail 261 protocols provide. 263 2. Provide for delivery of short mail messages with the same level of 264 functionality (or higher) that the existing Internet mail 265 protocols provide. 267 3. Function as an extension of the existing mainstream Internet mail. 269 4. Minimize the number of transmissions. 271 5. Minimize the number of bytes transmitted. 273 6. Be quick: minimize latency of message submission and delivery. 275 7. Provide the same level of reliability (or higher) that the 276 existing email protocols provide. 278 8. Accommodate varying sizes of messages: the size of a message may 279 determine how the system deals with the message, but the system 280 must accommodate it. 282 9. Be power efficient and respect mobile platform resources: 283 including memory and CPU levels, as well as battery power 284 longevity (i.e. client-light and server-heavy). 286 10. Highly extendible: different users will demand different options, 287 so the solution cannot require every feature to be a part of every 288 message. Likewise, usage will emerge that is not currently 289 recognized as a requirement. The solution must be extendible 290 enough to handle new, emerging requirements. 292 11. Secure: provide the same level of security (or higher) that the 293 existing email protocols provide. Content confidentiality, 294 originator/recipient authentication and message integrity must be 295 available options to users. 297 12. Easy to implement: Re-use existing technology as much as 298 possible. 300 1.4 Anticipated Uses Of EMSD 302 Any network and network operator which has significant bandwidth and 303 capacity limitations can benefit from the use of EMSD. Any network 304 user who must bear high costs for measured network usage can benefit 305 from the use of EMSD. 307 Initial uses of EMSD is anticipated to be primarily over IP-based 308 wireless networks to provide two-way paging services. 310 EMSD can also function as an adjunct to Mail Access Protocols for 311 "Mail Notification Services". 313 Considering: 315 o that most wireless networks shall converge toward being IP-based; 317 o that two-way paging is the main proven application in most 318 wide-area wireless networks; 320 o that two-way paging industry and the Internet Email industry can 321 and should converge based on a set of open protocols that address 322 the efficiency requirements adequately; 324 o that existing Internet email protocols are not bandwidth 325 efficient; 327 o that existing Internet email protocols do not properly support the 328 "push" model of delivery of urgent messages, 330 the EMSD protocol is designed to facilitate the convergence of 331 IP-based two-way paging and Internet email. 333 Mail submission and delivery take place at the edges of the network. 334 More than one mail submission and delivery protocols which address 335 requirements specific to a particular user's environment are likely to 336 be developed. Such diversity on the edges of the network is desirable 337 and with the right protocols, this diversity does not adversely impact 338 the integrity of the mail transfer system. EMSD is the initial basis 339 for the mail submission and delivery protocol to be used when the 340 user's environment demands efficiency. 342 1.5 Definitions of Terms Used in this Specification 344 The following informal definitions and acronyms are intended to help 345 describe EMSD model described in this specification. 347 Efficient Mail Submission and Delivery Protocol (EMSD-P): The protocol 348 used to transfer messages between the EMSD - Server Agent (e.g., a 349 Message Center) and the EMSD - User Agent (e.g., a Two-Way Pager), 350 see Figure 2. 351 Message Transfer Agent (MTA) 353 Message Transfer Service (MTS) 355 Message Routing Service (MRS): Collection of MTAs responsible for mail 356 routing. 357 Message User Agent (MUA) 359 Efficient Mail Submission Server Agent (EMS-SA): An Application 360 Process which conforms to this protocol specification and accepts 361 mail from an EMS-UA and transfers it towards its recipients. 363 Efficient Mail Delivery Server Agent (EMD-SA): An Application Process 364 which conforms to this protocol specification and delivers mail to 365 an EMD-UA. 366 Efficient Mail Submission and Delivery Server Agent (EMSD-SA): An 367 Application Process which incorporates both EMS-SA and EMD-SA 368 capabilities. 370 Efficient Mail Submission User Agent (EMS-UA): An Application Process 371 which conforms to this protocol specification and submits mail to 372 EMS-SA. 374 Efficient Mail Delivery User Agent (EMD-UA): An Application Process 375 which conforms to this protocol specification and accepts delivery 376 of mail from EMD-SA. 377 Efficient Mail Submission and Delivery User Agent (EMSD-UA): An 378 Application Process which incorporates both EMS-UA and EMD-UA 379 capabilities. 381 1.6 Conventions Used In This Specification 383 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in 384 this specification are to be interpreted as defined in [2]. 386 This specification uses the ES-OPERATION notation defined in Efficient 387 Short Remote Operations (ESRO) protocols as specified in RFC-2188 [1]. 389 Operations and information objects are typically described using the 390 ES-OPERATION and ASN.1 notations in the relevant sections of the 391 specification. 393 The complete machine verifiable ASN.1 modules are also compiled in one 394 place in Appendix A and Appendix B. 396 1.7 About This Specification 398 This protocol specification constitutes a point-of-record. It 399 documents information exchanges and behaviors of existing 400 implementations. It is a basis for implementation of efficient mail 401 submission and delivery user agents and servers. 403 This specification has been developed entirely outside of IETF. It has 404 had the benefit of review by many outside of IETF. Much has been 405 learned from existing implementations of this protocol. A number of 406 deficiencies and areas of improvement have been identified and are 407 documented in this specification. 409 This protocol specification is being submitted on October 23, 1998 for 410 timely publication as an Informational RFC. 412 Future development and enhancements to this protocol may take place 413 inside of IETF. 415 2 EFFICIENT MAIL SUBMISSION AND DELIVERY OVERVIEW 417 This section offers a high level view of the Efficient Mail Submission 418 and Delivery Protocol and Format Standards (EMSD-P&FS). 420 The EMSD-P&FS are used to transfer messages between the EMSD - Server 421 Agent (e.g., a Message Center) and the EMSD - User Agent (e.g., a 422 Two-Way Pager), see Figure 2. 424 This specification defines the protocols between an EMSD - User Agent 425 (EMSD-UA) and an EMSD - Server Agent (EMSD-SA). The EMSD - P&FS 426 consist of two independent components: 428 1. EMSD Format Standard (EMSD-FS). 430 EMSD-FS is a non-textual form of compact encoding of Internet mail 431 (RFC-822) messages which facilitates efficient transfer of 432 messages. EMSD-FS is used in conjunction with the EMSD-P but is 433 not a general replacement for RFC-822. EMSD-FS defines a method 434 of representation of short interpersonal messages. It defines the 435 "Content" encoding (Header + Body). Although EMSD-FS contains 436 end-to-end information its scope is purely point-to-point. 437 EMSD-FS relies on EMSD-P (see 2 below) for the transfer of the 438 content to its recipients. 440 This is described in the section entitled EMSD Format Standards. 442 2. Efficient Mail Submission and Delivery Protocol (EMSD-P). 444 EMSD-P is responsible for wrapping an EMSD-FS message (see 1 445 above) in a point-to-point envelope and submitting or delivering 446 it. EMSD-P relies on the services of Efficient Short Remote 447 Operation Services (ESROS) as specified in RFC-2188 [1] for 448 transporting the point-to-point envelope. Some of the services of 449 EMSD-P include: message originator authentication and optional 450 message segmentation and reassembly. The EMSD-P is expressed in 451 terms of abstract services using the ESROS notation. This is 452 described in the section entitled Efficient Mail Submission and 453 Delivery Protocol. 455 It is important to recognize that EMSD-P and EMSD-FS are not 456 end-to-end, but focus on the point-to-point transfer of messages. The 457 two points being EMSD-SA and EMSD-UA. EMSD-P function as elements of 458 the Internet mail environment, which provide end-to-end (EMSD-User to 459 any other Messaging Originator or Recipient) services. 461 Figure 2 illustrates how the EMSD-P&FS defines the communication 462 between a specific EMSD-UA and a specific EMSD-SA. The Message 463 Transfer System may include a number of EMSD-SAs. Each EMSD-SA may 464 have any number of EMSD-UAs with which it communicates. 466 The Efficient Mail Submission and Delivery Services use the Efficient 467 Short Remote Operation Services (ESROS). They also use the Duplicate 468 Operation Detection Support Functions as described in the section 469 entitled Duplicate Operation Detection Support Functions. These 470 functions guarantee that an operation is performed no more than once. 472 3 EFFICIENT MAIL SUBMISSION AND DELIVERY PROTOCOL 474 EM Submission is the process of transferring a message from EMSD-UA to 475 EMSD-SA. EM Delivery is the process of transferring a message from 476 EMSD-SA to EMSD-UA. 478 The Message-submission service enables an EMSD-UA to submit a message 479 to the EMSD-SA for transfer and delivery to one or more recipients. 480 The Message-submission Service comprises of the submit operation -- 481 invoked by the EMSD-UA -- and possibly the submitVerify operation -- 482 invoked by the EMSD-SA. 484 The Message-delivery service enables the EMSD-SA to deliver a message 485 to an EMSD-UA. The Message-delivery Service comprises of the deliver 486 operation -- invoked by the EMSD-SA -- and possibly the deliverVerify 487 operation -- invoked by the EMSD-UA. 489 EMSD-UA uses the following services: 491 o Message-submission 493 +---------------------------------------------+ 494 | MTS | 495 | | 496 | +-------------------------+ | 497 | | MRS | | 498 | | +---+ +---+ | | 499 | | | | | M | | +---+ | 500 | | | |<-------->| T |<----------->| | | 501 | | | | | A | | | | | +---+ 502 | | | | +---+ | | E | | | E | 503 | | | | | | M | | | M | 504 | | | M | | | S | | EMSD-P&FS | S | 505 | | | T |<-------------------------->| D |<---------------->| D | 506 | | | A | | | - | | | - | 507 | | | | +---+ | | S | | | U | 508 | | | | | M | | | A | | | A | 509 | | | |<-------->| T |<----------->| | | +---+ 510 | | | | | A | | | | | 511 | | +---+ +---+ | +---+ | 512 | | | | 513 | +-------------------------+ | 514 | | 515 | | 516 +---------------------------------------------+ 518 Figure 2: Efficient Mail Submission and Delivery Protocol 520 o Delivery-control (the deliveryControl operation). 522 EMSD-SA uses the following services: 524 o Message-delivery 526 o Submission-control (the submissionControl operation). 528 This specification expresses information objects using ASN.1 [X.208]. 530 This specification expresses Remote Operations based on the model of 531 ESROS as specified in Efficient Short Remote Operations (RFC-2188) 532 [1]. The ES-OPERATION notation of (RFC-2188) is used throughout this 533 specification to define specific operations. 535 This specification uses the Duplicate Operation Detection Support 536 functions as specified in Section 4. 538 3.1 Use Of Lower Layers 540 3.1.1 Use of ESROS 542 ESRO protocol, as specified in (RFC-2188 [1]), provides reliable 543 connectionless remote operation services on top of UDP [6] with 544 minimum overhead. ESRO protocol supports segmentation and reassembly, 545 concatenation and separation. 547 ESRO Services (2-Way and 3-Way handshake) shall be used by the EMSD-P. 549 ESRO Service Access Point (SAP) selectors used by EMSD-P are 550 enumerated in the protocol. 552 3.1.2 Use Of UDP 554 EMSD-P through ESRO MUST use UDP [6] port number 642 (esro-emsdp). 556 Note that specification of Service Access Points (SAP) for EMSD-P 557 include the UDP Port Number specification in addition to ESRO SAP 558 selector specifications. In other words, EMSD-P's use of ESRO SAPs 559 does not preclude use of the same SAP selectors by other protocols 560 which use a UDP port other than port 642. Such usage of ESRO is a 561 design characteristic of ESRO which results into bandwidth efficiency 562 and is not a scalability limitation. 564 3.1.3 Encoding Rules 566 Use of Basic Encoding Rules (BER) [5] is mandatory for both EMSD 567 Format Standards and EMSD Protocol. 569 In order to minimize data transfer, the following restrictions shall 570 be maintained in the formatting of EMSD PDUs: 572 o Specifically, when ASN.1 Basic Encoding Rules are being used: 574 A. Only the "Definite" form of Length encoding MUST be used, 576 B. The "Short" form of Length encoding MUST be used whenever 577 possible (i.e. when the Length is less than 128), and 579 C. OCTET STRING and BIT STRING values, and any other native ASN.1 580 types which may be encoded as either "Primitive" or 581 "Constructed", MUST always be encoded as "Primitive" and MUST 582 never be "Constructed". 584 3.1.4 Presentation Context 586 Parameter Encoding Type of "0" MUST be used in ESRO Protocol to 587 identify Basic Encoding Rules for operation arguments. 589 3.2 EMSD-UA Invoked Operations 591 The following operations are invoked by EMSD-UA: 593 a. submit 595 b. deliveryControl 597 c. deliveryVerify 599 The submit operation uses the duplication detection functional unit 600 while deliveryControl and deliveryVerify don't use the duplication 601 detection. 603 The complete definition of these operations follows. 605 3.2.1 submit 607 The submit ES-OPERATION enables an EMSD-UA to submit a message to the 608 EMSD-SA for transfer and delivery to one or more recipients. 610 submit ES-OPERATION 612 ARGUMENT SubmitArgument 613 RESULT SubmitResult 614 ERRORS 615 { 616 submissionControlViolated, 617 securityError, 618 resourceError, 619 protocolViolation, 620 messageError 621 } ::= 33; 623 Duplicate operation detection is necessary for this operation. 625 The successful completion of the ES-OPERATION signifies that the 626 EMSD-SA has accepted responsibility for the message (but not that it 627 has delivered it to its intended recipients). 629 The disruption of the ES-OPERATION by an error signifies that the 630 EMSD-SA cannot assume responsibility for the message. 632 Arguments 634 This operation's arguments are: 636 SubmitArgument ::= SEQUENCE 637 { 638 -- Security features 639 security [0] IMPLICIT SecurityElement OPTIONAL, 641 -- Segmentation features for efficient transport 642 segment-info SegmentInfo OPTIONAL, 644 -- Content type of the message 645 content-type ContentType, 647 -- 648 -- THE CONTENT -- 649 -- 650 -- The submission content 651 content ANY DEFINED BY content-type 652 }; 654 The fields are: 656 Security 658 See Section 3.4.1, "SecurityElements". 660 Segment-info 662 See Section 3.4.2, "Message Segmentation and Reassembly". 664 Content-type 666 This argument identifies the type of the content of the message. It 667 identifies the abstract syntax and the encoding rules used. 669 Content 671 This argument contains the information the message is intended to 672 convey to the recipient(s). It shall be generated by the originator 673 of the message. 675 Results 677 This operation's results are: 679 SubmitResult ::= SEQUENCE 681 { 682 -- Permanent identifier for this message. 683 -- Also contains the message submission time. 684 -- See comment regarding assignment of message identifiers, 685 -- at the definition of EMSDLocalMessageId. 687 message-id EMSDLocalMessageId 689 }; 691 The fields are: 693 Message-id 695 This result contains an EMSD-SA-identifier that uniquely and 696 unambiguously identifies the message-submission. It shall be 697 generated by the EMSD-SA. 699 Errors 701 See Section 3.4.3. 703 3.2.2 deliveryControl 705 The deliveryControl ES-OPERATION enables the EMSD-UA to temporarily 706 limit the operations that the EMSD-SA may invoke, and the messages 707 that the EMSD-SA may deliver to the EMSD-UA via the Message delivery 708 ES-OPERATION. 710 deliveryControl ES-OPERATION 711 ARGUMENT DeliveryControlArgument 712 RESULT DeliveryControlResult 713 ERRORS 714 { 715 securityError, 716 resourceError, 717 protocolViolation 718 } ::= 2; 720 The duplicate operation detection is not required for this operation. 722 The EMSD-SA shall hold until a later time, rather than abandon, 723 ES-OPERATIONS and messages that are presently suspended. 725 The successful completion of the ES-OPERATION signifies that the 726 specified controls are now in force. 728 The ES-OPERATION returns an indication of any ES-OPERATIONS that the 729 EMSD-SA would invoke, or any message types that the EMSD-SA would 730 deliver, were it not for the prevailing controls. 732 Arguments 734 This operation's arguments are: 736 DeliveryControlArgument ::= SEQUENCE 737 { 738 -- Request an addition of or removal of a set of restrictions 740 restrict [0] IMPLICIT Restrict DEFAULT update, 742 -- Which operations are to be placed in the restriction set 743 permissible-operations [1] IMPLICIT Operations OPTIONAL, 745 -- What maximum content length should be allowed 746 permissible-max-content-length 748 [2] IMPLICIT INTEGER 749 (0..ub-content-length) OPTIONAL, 751 -- What is the lowest priority message which may be delivered 752 permissible-lowest-priority 754 [3] IMPLICIT ENUMERATED 755 { 756 non-urgent (0), 757 normal (1), 758 urgent (2) 759 } OPTIONAL, 761 -- Security features 762 security [4] IMPLICIT SecurityElement 763 OPTIONAL, 765 -- User Feature selection 766 user-features [5] IMPLICIT OCTET STRING 767 OPTIONAL 768 }; 770 Restrict 772 This argument indicates whether the controls on ES-OPERATIONS are to 773 be updated or removed. It may be generated by the EMSD-UA. 775 This argument may have one of the following values: 777 o update: The other arguments update the prevailing controls; 778 o remove: All temporary controls are to be removed 780 In the absence of this argument, the default update shall be assumed. 782 Permissible-operations 784 This argument indicates the ES-OPERATIONS that the EMSD-SA may invoke 785 on the EMSD-UA. It may be generated by the EMSD-UA. 787 This argument may have the value allowed or prohibited for each of the 788 following: 790 o message-delivery: The EMSD-SA may/may not invoke the deliver 791 ES-OPERATIONS; and 793 o Other ES-OPERATIONS are not subject to controls, and may be 794 invoked at any time. 796 In the absence of this argument, the ES-OPERATIONS that the EMSD-SA 797 may invoke on the EMSD-UA are unchanged. 799 Permissible-max-content-length 801 This argument contains the content-length, in octets, of the 802 longest-content message that the EMSD-SA shall deliver to the EMSD-UA 803 via the deliver ES-OPERATIONS. It may be generated by the EMSD-UA. 805 In the absence of this argument, the 806 permissible-maximum-content-length of a message that the EMSD-SA may 807 deliver to the EMSD-UA is unchanged. 809 Permissible-lowest-priority 811 This argument contains the priority of the lowest priority message 812 that the EMSD-SA shall deliver to the EMSD-UA via the deliver 813 ES-OPERATIONS. It may be generated by the EMSD-UA. 815 This argument may have one of the following values of the priority 816 argument of the submit ES-OPERATIONS: normal, non-urgent or urgent. 818 In the absence of this argument, the priority of the lowest priority 819 message that the EMSD-SA shall deliver to the EMSD-UA is unchanged. 821 Security 823 See Section 3.4.1, "SecurityElements". 825 User-features 827 This argument contains information that allows the EMSD-UA to convey 828 to MTS the feature set that the user is capable of supporting. This 829 argument will be defined when the setConfiguration and 830 getConfiguration operations are defined. 832 Results 834 DeliveryControlResult ::= SEQUENCE 835 { 836 -- Operation types queued at the EMSD-SA due to existing 837 -- restrictions. 838 waiting-operations [0] IMPLICIT Operations DEFAULT { }, 840 -- Types of messages queued at the EMSD-SA due to 841 -- existing restrictions 842 waiting-messages [1] IMPLICIT WaitingMessages 843 DEFAULT { }, 845 -- Content Types of messages queued at the EMSD-SA 846 waiting-content-types SEQUENCE SIZE (0..ub-content-types) OF 847 ContentType DEFAULT { } 849 }; 851 Restrict ::= ENUMERATED 852 { 853 update (1), 854 remove (2) 855 }; 857 Operations ::= BIT STRING 858 { 859 submission (0), 860 delivery (1) 861 }; 863 WaitingMessages ::= BIT STRING 864 { 865 long-content (0), 866 low-priority (1) 868 }; 870 Waiting-operations 872 This result indicates the ES-OPERATIONS being held by the EMSD-SA, and 873 that the EMSD-SA would invoke on the EMSD-UA if it were not for the 874 prevailing controls. It may be generated by the EMSD-SA. 876 This result may have the value holding or not-holding for each of the 877 following: 879 o message-delivery: The EMSD-SA is/is not holding messages, and 880 would invoke the deliver ES-OPERATIONS on the EMSD-UA if it were 881 not for the prevailing controls. 883 In the absence of this result, it may be assumed that the EMSD-SA is 884 not holding any messages for delivery due to the prevailing controls. 886 Waiting-messages 888 This result indicates the kind of messages the EMSD-SA is holding for 889 delivery to the EMSD-UA, and would deliver via the deliver 890 ES-OPERATIONS, if it were not for the prevailing controls. It may be 891 generated by the EMSD-SA. 893 This result may have one or more of the following values: 895 o long-content: The EMSD-SA has messages held for delivery to the 896 EMSD-UA which exceed the permissible maximum-content-length 897 control currently in force; 899 o low-priority: The EMSD-SA has messages held for delivery to the 900 EMSD-UA of a lower priority than the permissible-lowest-priority 901 control currently in force; 903 In the absence of this result, it may be assumed that the EMSD-SA is 904 not holding any messages for delivery to the EMSD-UA due to the 905 permissible-maximum-content- length, permissible-lowest-priority or 906 permissible-security context controls currently in force. 908 Errors 910 See Section 3.4.3. 912 3.2.3 deliveryVerify 914 The deliveryVerify ES-OPERATIONS enables the EMSD-UA to verify 915 delivery of a message when it receives FAILURE.indication for deliver 916 ES-OPERATIONS. 918 deliveryVerify ES-OPERATION 920 ARGUMENT DeliveryVerifyArgument 921 RESULT DeliveryVerifyResult 922 ERRORS 923 { 924 verifyError, 925 resourceError, 926 protocolViolation 927 } ::= 5; 929 The duplicate operation detection is not required for this operation. 931 Arguments 933 This operation's arguments are: 935 DeliveryVerifyArgument ::= SEQUENCE 937 { 938 -- Identifier of this message. This is the same identifier that 939 -- was provided to the originator in the Submission Result. 940 -- See comment regarding assignment of message identifiers, 941 -- at the definition of EMSDMessageId. 942 message-id EMSDMessageId 943 }; 945 Message-id 947 This argument contains an EMSD-SA-identifier that distinguishes the 948 message from all other messages. It shall be generated by the 949 EMSD-SA, and shall have the same value as the 950 message-submission-identifier supplied to the originator of the 951 message when the message was submitted. 953 Results 955 DeliveryVerifyResult ::= SEQUENCE 956 { 957 status DeliveryStatus 958 }; 960 DeliveryStatus ::= ENUMERATED 961 { 962 no-report-is-sent-out (1), 963 delivery-report-is-sent-out (2), 964 non-delivery-report-is-sent-out (3) 965 }; 967 No-report-is-sent-out 969 This result indicates that EMSD-SA has received the delivery verify 970 and no report is sent out (either because it has not been requested or 971 EMSD-SA has problems and can not send it out). 973 Delivery-report-is-sent-out 975 This result indicates that EMSD-SA has received the delivery verify 976 and has sent the delivery report out. 978 Non-Delivery-report-is-sent-out 980 This result indicates that EMSD-SA has received the delivery verify 981 but it has already sent out a non-Delivery report. This should not 982 happen in normal cases but a wrong user profile on EMSD-SA side can 983 result in this outcome. 985 Errors 987 See Section 3.4.3. 989 3.3 EMSD-SA Invoked Operations 991 This section defines the operations invoked by the EMSD-SA: 993 a. deliver; 995 b. submissionControl; 997 c. submissionVerify. 999 The deliver operation uses 3-Way handshake service of ESROS. This 1000 operation always uses the duplication detection functional unit. 1002 The submissionControl and submissionVerify operations use 2-Way 1003 handshake service of ESROS without duplication detection. 1005 3.3.1 deliver 1007 The deliver ES-OPERATIONS enables the EMSD-SA to deliver a message to 1008 an EMSD-UA. 1010 deliver ES-OPERATION 1012 ARGUMENT DeliverArgument 1013 RESULT NULL 1014 ERRORS 1015 { 1016 deliveryControlViolated, 1017 securityError, 1018 resourceError, 1019 protocolViolation, 1020 messageError 1021 } ::= 35; 1023 The EMSD-UA MUST not refuse performing the deliver ES-OPERATION unless 1024 the delivery would violate the deliveryControl restrictions then in 1025 force. 1027 Arguments 1029 This operation's arguments are: 1031 DeliverArgument ::= SEQUENCE 1032 { 1033 -- Identifier of this message. This is the same identifier that 1034 -- was provided to the originator in the Submission Result. 1035 -- See comment regarding assignment of message identifiers, 1036 -- at the definition of EMSDMessageId. 1037 message-id EMSDMessageId, 1039 -- Time the message was delivered to the recipient by EMSD-SA 1040 message-delivery-time DateTime, 1042 -- Time EMSD-SA originally took responsibility for processing 1043 -- of this message. This field shall be omitted if the message-id 1044 -- contains an EMSDLocalMessageId, because that field contains 1045 -- the submission time within it. 1046 message-submission-time [0] IMPLICIT DateTime OPTIONAL, 1048 -- Security features 1049 security [1] IMPLICIT SecurityElement OPTIONAL, 1051 -- SegContentTypementation features for efficient transport 1052 segment-info SegmentInfo OPTIONAL, 1054 -- The type of the content 1055 content-type ContentType, 1057 -- 1058 -- THE CONTENT -- 1059 -- 1061 -- The submitted (and now being delivered) content 1062 content ANY DEFINED BY content-type 1063 }; 1065 message-id 1067 This argument contains an EMSD-SA-identifier that distinguishes the 1068 message from all other messages. When within the EMSD, it MUST be 1069 generated by the EMSD-SA, and MUST have the same value as the 1070 message-submission-identifier supplied to the originator of the 1071 message when the message was submitted. 1073 Message-delivery-time 1075 This argument contains the Time at which delivery occurs and at which 1076 the EMSD-SA is relinquishing responsibility for the message. It shall 1077 be generated by the EMSD-SA. 1079 Results 1081 This operation returns an empty result as indication of success. 1083 Errors 1085 See Section 3.4.3. 1087 3.3.2 submissionControl 1089 submissionControl ES-OPERATION 1090 ARGUMENT SubmissionControlArgument 1091 RESULT SubmissionControlResult 1092 ERRORS 1093 { 1094 securityError, 1095 resourceError, 1096 protocolViolation 1097 } ::= 4; 1099 The submissionControl ES-OPERATIONS enables the EMSD-SA to temporarily 1100 limit the operations that the EMSD-UA may invoke, and the messages 1101 that the EMSD-UA may submit to the EMSD-SA via the submit 1102 ES-OPERATIONS. 1104 The duplicate operation detection is not required for this operation. 1106 The EMSD-UA should hold until a later time, rather than abandon, 1107 ES-OPERATIONS and messages that are presently suspended. 1109 The successful completion of the ES-OPERATIONS signifies that the 1110 specified controls are now in force. These controls supersede any 1111 previously in force, and remain in effect until the association is 1112 released or the EMSD-SA re-invokes the submissionControl 1113 ES-OPERATIONS. 1115 The ES-OPERATIONS returns an indication of any ES-OPERATIONS that the 1116 EMSD-UA would invoke were it not for the prevailing controls. 1118 Arguments 1120 This operation's arguments are: 1122 SubmissionControlArgument ::= SEQUENCE 1123 { 1124 -- Request an addition of or removal of a set of restrictions 1125 restrict [0] IMPLICIT Restrict DEFAULT update, 1127 -- Which operations are to be placed in the restriction set 1128 permissible-operations [1] IMPLICIT Operations OPTIONAL, 1130 -- What maximum content length should be allowed 1131 permissible-max-content-length 1132 [2] IMPLICIT INTEGER 1133 (0..ub-content-length) OPTIONAL, 1135 -- Security features 1136 security [3] IMPLICIT SecurityElement 1137 OPTIONAL 1138 }; 1140 Restrict 1142 This argument indicates whether the controls on ES-OPERATIONS are to 1143 be updated or removed. It may be generated by the EMSD-SA. 1145 This argument may have one of the following values: 1147 o update: The other arguments update the prevailing controls; 1149 o remove: All temporary controls are to be removed 1151 In the absence of this argument, the default update shall be assumed. 1153 Permissible-operations 1155 This argument indicates the ES-OPERATIONS that the EMSD-UA may invoke 1156 on the EMSD-SA. It may be generated by the EMSD-SA. 1158 This argument may have the value allowed or prohibited for each of the 1159 following: 1161 o submit: The EMSD-UA may/may not invoke the submit ES-OPERATIONS; 1162 and 1164 o Other ES-OPERATIONS are not subject to controls, and may be 1165 invoked at any time. 1167 In the absence of this argument, the ES-OPERATIONS that the EMSD-UA 1168 may invoke on the EMSD-SA are unchanged. 1170 Permissible-max-content-length 1172 This argument contains the content-length, in octets, of the 1173 longest-content message that the EMSD-UA shall submit to the EMSD-SA 1174 via the submit ES-OPERATIONS. It may be generated by the EMSD-SA. 1176 In the absence of this argument, the 1177 permissible-maximum-content-length of a message that the EMSD-UA may 1178 submit to the EMSD-SA is unchanged. 1180 Security 1182 See Section 3.4.1, "SecurityElements". 1184 Results 1186 SubmissionControlResult ::= SEQUENCE 1187 { 1188 -- Operation types queued at the EMSD-SA due to existing 1189 -- restrictions. 1190 waiting-operations [0] IMPLICIT Operations DEFAULT { } 1192 }; 1193 Waiting-operations 1195 This result indicates the ES-OPERATIONS being held by the EMSD-UA, and 1196 that the EMSD-UA would invoke if it were not for the prevailing 1197 controls. It may be generated by the EMSD-UA. 1199 This result may have the value holding or not-holding for each of the 1200 following: 1202 o submit: The EMSD-UA is/is not holding messages, and would invoke 1203 the submit ES-OPERATIONS if it were not for the prevailing 1204 controls. 1206 In the absence of this result, it may be assumed that the EMSD-UA is 1207 not holding any messages for submission due to the prevailing 1208 controls. 1210 Errors 1212 See Section 3.4.3. 1214 3.3.3 submissionVerify 1216 The submissionVerify ES-OPERATIONS enables the EMSD-SA to verify if 1217 the EMSD-UA has received the result of its submission. 1219 submissionVerify ES-OPERATION 1221 ARGUMENT SubmissionVerifyArgument 1222 RESULT SubmissionVerifyResult 1223 ERRORS 1224 { 1225 submissionVerifyError, 1226 resourceError, 1227 protocolViolation 1228 } ::= 6; 1230 The duplicate operation detection is not required for this operation. 1232 Arguments 1234 This operation's arguments are: 1236 SubmissionVerifyArgument ::= SEQUENCE 1238 -- Identifier of this message. This is the same identifier that 1239 -- was provided to the originator in the Submission Result. 1240 -- See comment regarding assignment of message identifiers, 1241 -- at the definition of EMSDMessageId. 1242 { 1243 message-id EMSDMessageId 1244 }; 1246 Message-id 1248 This argument contains an EMSD-SA-identifier that distinguishes the 1249 message from all other messages. It shall be generated by the 1250 EMSD-SA, and shall have the same value as the 1251 message-submission-identifier supplied to the originator of the 1252 message when the message was submitted. 1254 Results 1256 SubmissionVerifyResult ::= SEQUENCE 1257 { 1258 status SubmissionStatus 1259 }; 1261 SubmissionStatus::= ENUMERATED 1262 { 1263 send-message (1), 1264 drop-message (2) 1265 }; 1267 Send-message 1269 This result indicates that EMSD-SA is supposed to send the message 1270 out. 1272 Drop-message 1274 This result indicates that EMSD-SA is supposed to drop the message. 1276 Errors 1278 See Section 3.4.3. 1280 3.4 EMSD Common Information Objects 1282 3.4.1 SecurityElements 1284 SecurityElement ::= SEQUENCE 1286 { 1287 credentials Credentials, 1288 contentIntegrityCheck ContentIntegrityCheck OPTIONAL 1289 }; 1291 Credentials ::= CHOICE 1292 { 1293 simple [0] IMPLICIT SimpleCredentials 1295 -- Strong Credentials are for future study 1296 -- strong [1] IMPLICIT StrongCredentials 1297 -- externalProcedure [2] EXTERNAL 1298 }; 1300 SimpleCredentials ::= SEQUENCE 1301 { 1302 eMSDAddress EMSDAddress OPTIONAL, 1303 password [0] IMPLICIT OCTET STRING 1304 SIZE (0..ub-password-length)) OPTIONAL 1305 }; 1307 -- StrongCredentials ::= NULL 1308 -- for now. 1309 -- ContentIntegrityCheck is a 16-bit checksum of content 1310 ContentIntegrityCheck ::= INTEGER (0..65535); 1312 3.4.2 Message Segmentation and Reassembly 1314 Small messages can benefit from the efficiencies of connectionless 1315 feature of ESROS (See Efficient Short Remote Operations, RFC-2188 1316 [1]). 1318 Very large messages are transferred using protocols (e.g., SMTP) that 1319 rely on Connection Oriented Transport Service (e.g., TCP). 1321 When a message is too large to fit in a single connectionless PDU but 1322 is not large enough to justify the overhead of connection 1323 establishment, it may be more efficient for the message to be 1324 segmented and reassembled while the connectionless service of ESROS is 1325 used. If the underlying Remote Operation Service is capable of 1326 efficient segmentation/reassembly over connectionless (CL) services, 1327 then use of the segmenting/reassembly mechanism introduced in this 1328 section is not necessary. This feature is accommodated in this layer 1329 by: 1331 SegmentInfo ::= CHOICE 1333 { 1334 first [APPLICATION 2] IMPLICIT FirstSegment, 1335 other [APPLICATION 3] IMPLICIT OtherSegment 1336 }; 1338 FirstSegment ::= SEQUENCE 1339 { 1340 sequence-id INTEGER, 1341 number-of-segments INTEGER 1342 -- number-of-segments must not exceed ub-total-number-of-segments 1343 }; 1345 OtherSegment ::= SEQUENCE 1346 { 1347 sequence-id INTEGER, 1348 segment-number INTEGER 1349 }; 1351 Segmentation and reassembly only applies to Message-submission and 1352 Message-delivery. 1354 The sender of the message is responsible for segmenting the message 1355 content into segments that fit in CL PDUs. The segmented content is 1356 sent in a sequence of message- segments each carrying a segment of the 1357 content. sequence-Id is a unique identifier that is present in all 1358 message-segments. In addition to sequence identifier, the first 1359 message- segment specifies the total number of segments 1360 (number-of-segments). Other message- segments have a segment sequence 1361 number (segment-number). The receiver is responsible for sequencing 1362 (based on segment-number) and reassembling the entire message. 1364 Segmenting over the Connectionless ESRO Service 1366 The sender of the message maps the original message into an ordered 1367 sequence of message-segments. This sequence shall not be interrupted 1368 by other messages over the same ESROS association. 1370 All message-segments in the sequence shall be assigned a sequence 1371 identifier by sender. The sequence identifier shall be incremented by 1372 one by the sender after transmission of a complete message sequence. 1374 The first message-segment specifies the total number of segments. All 1375 message- segments in the sequence except the first one shall be 1376 sequentially numbered, starting at 1 (first message-segment has 1377 implicit segment number of 0). 1379 Each message-segment is transmitted by issuing a Message-submission or 1380 Message-delivery ES-OPERATIONS. All segments of a segmented message 1381 are identified by the same sequence-id. For a given message, the 1382 receiver should not impose any restriction on the order of arrival of 1383 message-segments. 1385 There is no requirement that any message-segment content be of maximum 1386 length allowed by ESROS for connectionless transmission; however, no 1387 more than ub-total-number-of-segments segments can be derived from a 1388 single message. 1390 The receiver reassembles a sequence of message-segments into a single 1391 message. A message shall not be further processed unless all segments 1392 of the message are received. Failure to receive the message shall be 1393 determined by the following events: 1395 o Expiration of Reassembly Timer (see Section 3.4.3). 1397 o Receipt of a message-segment with different sequence identifier. 1399 In the event of the above mentioned failures, the receiver shall 1400 discard a partially assembled sequence. 1402 In Reassembly process, all arguments other than content are ignored in 1403 all segments except the first one. The content parts of all segments 1404 are concatenated to compose the original message content. 1406 When sender receives FAILURE.indication (as opposed to a 1407 resourceError) for a message-segment, the whole message shall be 1408 retransmitted. 1410 In the case of submission and delivery operations, the verify function 1411 is used as described below: 1413 Receiver ignores FAILURE.indications received for message-segments, 1414 and just collects the message-segments to complete the message. 1415 However, it keeps a failure status for a segmented message which says 1416 if any segment of the message has received FAILURE.indication. When 1417 receiver succeeds to assemble the whole segmented message, then if the 1418 status of the message shows there has been a FAILURE.indication for 1419 any of the message-segments, it verifies the message through verify 1420 operation. It's not enough to invoke verify operation just based on 1421 the last message-segment because the sender might send a segment 1422 without waiting for the result of the previous segment. In such 1423 cases, there might be any combination of success and failure for 1424 message- segments on the sender side. 1426 Receiver uses the error code ResourceError (see Section 3.4.3) to ask 1427 for retransmission of a single segment and uses the error code 1428 MessageError (see Section 3.4.3) to ask for retransmission of all 1429 segments (the whole message). 1431 Reassembly Timer 1433 The Reassembly Timer is a local timer maintained by the receiver of 1434 message-segments that assists in performing the reassembly function. 1435 This timer determines how long a receiver waits for all segments of a 1436 message-segment sequence to be received. The timer protects the 1437 receiver from the loss of a series of segments and possible sequence 1438 identifier wrap-around. 1440 The Reassembly Timer shall be started on receipt of a message-segment 1441 with different sequence identifier than that previously received. The 1442 timer shall be stopped on receipt of all segments composing the 1443 sequence. 1445 The value of Reassembly Timer is defined based on the network 1446 characteristics and the number of segments. This requires that the 1447 transmission of all segments of a single message must be completed 1448 within this time limit. 1450 3.4.3 Common Errors 1452 protocolVersionNotRecognized ERROR PARAMETER NULL ::= 1; 1454 submissionControlViolated ERROR PARAMETER NULL ::= 2; 1456 messageIdentifierInvalid ERROR PARAMETER NULL ::= 3; 1458 securityError ERROR PARAMETER security-problem SecurityProblem ::= 4; 1459 deliveryControlViolated ERROR PARAMETER NULL ::= 5; 1461 resourceError ERROR PARAMETER NULL ::= 6; 1463 protocolViolation ERROR PARAMETER NULL ::= 7; 1465 messageError ERROR PARAMETER NULL ::= 8; 1467 SecurityProblem ::= INTEGER (0..127); 1469 protocolVersionNotRecognized 1471 The major and minor protocol versions presented do not match those 1472 recognized as being valid. 1474 submissionControlViolated 1476 The Submission control violated error reports the violation by the 1477 MTS-user of a control on submission services imposed by the MTS via 1478 the Submission control service. The Submission control violated 1479 abstract-error has no parameters. 1481 messageIdentifierInvalid 1483 The Message Identifier Invalid error reports that the Message 1484 Identifier presented to the MTS is not considered valid. 1486 securityError 1488 The Security error reports that the requested operation could not be 1489 provided by the MTS or MTS-user because it would violate the security 1490 policy in force. 1492 deliveryControlViolated 1494 The Delivery control violated error reports the violation by the MTS 1495 of a control on delivery operations imposed by the MTS-user via the 1496 Delivery-control operation. 1498 resourceError 1500 The messaging agent cannot currently support this operation. In the 1501 case of segmentation and reassembly, resourceError is by the receiver 1502 used to request that the sender retransmit of a single segment. 1504 protocolViolation 1506 Indicates that one or more mandatory argument(s) were missing. 1508 messageError 1510 For a multi-segment message, this error indicates that the messaging 1511 agent has not received the message completely and that the message 1512 must be retransmitted. 1514 SecurityProblem 1516 To ensure the security-policy is not violated during delivery, the 1517 message-security-label is checked against the security-context. If 1518 delivery is barred by the security -policy then, subject to the 1519 security policy, a report instruction for this is generated. 1521 3.4.4 ContentType 1523 ContentType ::= INTEGER 1524 { 1525 -- Content type 0 is reserved and shall never be transmitted. 1526 reserved (0), 1527 -- Content types between 1 and 31 (inclusive) are for 1528 -- internal-use only 1529 probe (1), -- reserved 1530 delivery-report (2), -- reserved 1532 -- Content types between 32 and 63 (inclusive) are for 1533 -- message types defined within this specifications. 1534 emsd-interpersonal-messaging-1995 (32), 1535 voice-messaging (33) -- reserved 1537 -- Content types beyond and including 64 are for 1538 -- bilaterally-agreed use between peers. 1539 } (0..127); 1540 3.4.5 EMSDMessageId 1542 If this message was originated as an RFC-822 message, then this 1543 EMSDMessageId shall be the ``Message-Id:" field from that message. If 1544 this message was originated within the EMSD domain, then this 1545 identifier shall be unique for the EMSD-SA generating this id. 1547 EMSDMessageId ::= CHOICE 1548 { 1549 EMSDLocalMessageId [APPLICATION 4] 1550 IMPLICIT EMSDLocalMessageId, 1552 rfc822MessageId [APPLICATION 5] 1553 IMPLICIT AsciiPrintableString 1554 (SIZE (0..ub-message-id-length)) 1555 }; 1557 EMSDLocalMessageId ::= SEQUENCE 1558 { 1559 submissionTime DateTime, 1560 messageNumber INTEGER (0..ub-local-message-nu) 1561 }; 1563 3.5.6 EMSDORAddress 1565 EMSDORAddress ::= CHOICE 1566 { 1567 -- This is the local-format address 1568 emsd-local-address-format EMSDAddress, 1570 -- This is a globally-unique RFC-822 Address 1571 rfc822DomainAddress AsciiPrintableString 1572 }; 1574 In the global sense Originators and Recipients are represented by 1575 EMSDORAddress. The rfc822Domain may be used to address any recipient. 1577 3.4.6 EMSDAddress 1579 EMSDAddress ::= SEQUENCE 1580 { 1581 emsd-address OCTET STRING (SIZE 1582 (1..ub-emsd-address-length)), 1584 -- emsd-address is a decimal integer in BCD 1585 (Binary Encoded Decimal) format. 1586 -- If it had an odd number of digits, it is 1587 -- padded with 0 on the left. 1589 emsd-name [0] IMPLICIT OCTET STRING 1590 (SIZE (0..ub-emsd-name-length)) 1591 OPTIONAL 1592 }; 1594 Originator and Recipients in the scope of EMSD network are identified 1595 by a digit based addressing scheme. EMSDAddress can only be used 1596 where the scope of addressing has clearly been limited to the EMSD 1597 network. 1599 3.4.7 DateTime 1601 DateTime ::= INTEGER; 1603 DateTime is a Julian date, expressed as the number of seconds since 1604 00:00:00 UTC, January 1, 1970. 1606 3.4.8 AsciiPrintableString 1608 Iso8859String ::= GeneralString; 1610 AsciiPrintableString ::= [APPLICATION 0] 1611 IMPLICIT Iso8859String (FROM 1613 (" "|"!"|"#"|"$"|"%"|"&"|"'"|"("|")"|"*"|"+"|","|"-"|"."|"/"| 1614 "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"|":"|";"|"<"|"="|">"| 1615 "?"|"@"|"A"|"B"|"C"|"D"|"E"|"F"|"G"|"H"|"I"|"J"|"K"|"L"|"M"| 1616 "N"|"O"|"P"|"Q"|"R"|"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"|"["|"]"| 1617 "^"|"_"|"`"|"a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|"l"| 1618 "m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|"w"|"x"|"y"|"z"|"{"| 1619 "|"|"}"|"~"|"\"|"""")); 1621 3.4.9 ProtocolVersionNumber 1623 ProtocolVersionNumber ::= [APPLICATION 1] SEQUENCE 1624 { 1625 version-major INTEGER, 1627 +------------------+-------+----+---------+----+---------+-----+-----+ 1628 |Operation |Invoker|Sap |Performer|Sap |Duplicate|OpId |ESROS| 1629 | | |Sel | |Sel |Detect | |Use | 1630 |__________________|_______|____|_________|____|_________|_____|_____| 1631 |submit |UA |4 |MTS |5 |Yes |33 |3-Way| 1632 |__________________|_______|____|_________|____|_________|_____|_____| 1633 |deliver |MTS |2 |UA |3 |Yes |35 |3-Way| 1634 |__________________|_______|____|_________|____|_________|_____|_____| 1635 |deliveryControl |UA |8 |MTS |9 |No |2 |2-Way| 1636 |__________________|_______|____|_________|____|_________|_____|_____| 1637 |submissionControl |MTS |6 |UA |7 |No |4 |2-Way| 1638 |__________________|_______|____|_________|____|_________|_____|_____| 1639 |submissionVerify |MTS |6 |UA |7 |No |6 |2-Way| 1640 |__________________|_______|____|_________|____|_________|_____|_____| 1641 |deliveryVerify |UA |8 |MTS |9 |No |5 |2-Way| 1642 |__________________|_______|____|_________|____|_________|_____|_____| 1643 |getConfiguration |UA |8 |MTS |9 |No |7 |2-Way| 1644 |__________________|_______|____|_________|____|_________|_____|_____| 1645 |setConfiguration |MTS |6 |UA |7 |No |8 |2-Way| 1646 +------------------+-------+----+---------+----+---------+-----+-----+ 1648 Table 1: EMSD-P Operations Summary 1650 version-minor [0] IMPLICIT INTEGER DEFAULT 0 1651 } 1653 3.5 Submission and Delivery Procedures 1655 Table 1 provides a comprehensive summary of EMSD-P operations, the SAP 1656 selectors used and the operation IDs used. 1658 Submission 1660 The semantics of a submission operation is Exactly Once. Exactly Once 1661 means that every operation is carried out exactly one time, no more 1662 and no less. This semantic can not be fully implemented because, if 1663 after invoking the operation, an invoker has a Success (e.g. result) 1664 indication and the performer has a FAILURE.indication, and the network 1665 goes down, the result of the operation will be Zero (and not Exactly 1666 Once). 1668 No more than one is controlled and guaranteed by the performer by 1669 using the Duplicate Operation Detection Support Functions (see the 1670 chapter entitled Duplicate Operation Detection Support). 1672 Not zero but one is realized by performer by using the 1673 SubmissionVerify operation. When the performer receives 1674 FAILURE.indication, it's responsibility is to resolve the case by 1675 using SubmissionVerify resulting in Not zero but one. 1677 Submission procedure is as follows: 1679 o Submit operation with 3-Way handshake and Duplicate Operation 1680 Detection Support Function is invoked. 1682 o If performer at EMSD-SA receives FAILURE.indication, it invokes 1683 SubmissionVerify. 1685 o Message is sent out by EMSD-SA only if result operation is 1686 confirmed or the operation is verified (in the case of 1687 FAILURE.indication). 1689 The semantic of SubmissionVerify operation is At Least Once. This 1690 type of semantics corresponds to the case that invoker keeps trying 1691 over and over until it gets a proper reply. This operation can be 1692 performed more than once without any harm. 1694 Implications: 1696 o MTS sends out the message if and only if it's sure that UA knows 1697 about it. 1699 Delivery 1701 The semantics of Deliver operation is Exactly Once. Exactly Once 1702 means that every operation is carried out exactly one time, no more 1703 and no less. This semantic can not be fully implemented and if after 1704 invoking the operation, invoker has Success indication and performer 1705 has FAILURE.indication, and the network goes down, the result of the 1706 operation will be Zero (and not Exactly Once). 1708 No more than one is controlled and guaranteed by performer and by 1709 using the Duplicate Operation Detection Support Functions. 1711 Not zero but one is realized by performer by using the DeliveryVerify 1712 operation. When performer receives FAILURE.indication, it's 1713 responsible to resolve the case by using DeliveryVerify resulting in 1714 Not zero but one. 1716 Delivery procedure is as follows: 1718 o Deliver operation with 3-Way handshake is invoked. 1720 o If performer at User Agent (device) receives FAILURE.indication, 1721 it invokes DeliveryVerify. 1723 The semantic of DeliveryVerify operation is At Least Once. This type 1724 of semantics corresponds to the case that invoker keeps trying over 1725 and over until it gets a proper reply. This operation can be 1726 performed more than once without any harm. 1728 Implications: 1730 o A non-delivery report is sent by MTS only if the message is not 1731 delivered. 1733 o The UA is responsible for notifying the MTS (through an explicit 1734 deliveryVerify) to make sure that a delivery report is sent out. 1736 4 DUPLICATE OPERATION DETECTION SUPPORT 1738 4.1 Duplicate Operation Detection Support Overview 1740 Some operations are idempotent in nature, i.e. they can be performed 1741 more than once without any harm. However, some other operations are 1742 non-idempotent in nature, i.e. they should be performed only once. 1743 In the case of non-idempotent operations, performer should be able to 1744 detect duplicate operations and perform each non- idempotent operation 1745 only once. 1747 Examples of non-idempotent operations are Submission and Delivery of 1748 messages which shouldn't be performed more than once. Examples of 1749 idempotent operations are Submission-control and Delivery-control 1750 which can be performed more than once with no harm. 1752 ESRO Services don't detect duplicate invocation of operations. As a 1753 result, the Duplicate Operation Detection Support Functional Unit is 1754 used to detect duplication when the same operation instance is invoked 1755 more than once. Invoker assigns an Operation Instance Identifier to 1756 an operation and this Operation Instance Identifier is used at the 1757 peer performer entity to detect the duplicate invocation of the same 1758 operation. 1760 Using this support, non-idempotent operations can be repeated over and 1761 over with no harm because the duplicate invocations are detected by 1762 this functional unit. This support helps the performer not to perform 1763 an operation more than once. 1765 Support for duplication detection is realized through allocating 1766 Operation Instance Id (see Section 4.1.2, "Operation Instance 1767 Identifier") to an operation by invoker. When an operation is invoked 1768 using duplication detection support, performer logs the Operation 1769 Instance Identifier and checks the next operations against 1770 duplication. 1772 Operation value identifies whether performer should detect duplicate 1773 operations (see Section 4.1.1, ``Operation Value") and Operation 1774 Instance Id is assigned by invoker and sent as the first byte of 1775 operation's parameter. 1777 4.1.1 Operation Value 1779 Operation Values are divided into two groups. Operation values from 0 1780 to 31 do not have Duplicate Operation Detection Support (0 to 31) and 1781 operation values from 32 to 63 have Duplicate Operation Detection 1782 Support. 1784 Duplicate Operation Detection Functional Unit checks for duplication 1785 only if Operation Value is in the range of 32 to 63. 1787 When invoker user uses an Operation Value in the range of 32 to 63 1788 which means operation with support for duplication detection, the user 1789 should specify an Operation Instance ID for the operation (see next 1790 section). 1792 4.1.2 Operation Instance Identifier 1794 To support duplication detection, an Operation Instance Identifier is 1795 assigned by invoker user and sent as the first byte of the operation's 1796 parameter. This identifier is used on performer side to detect 1797 duplicate invocation of the same operation. Characteristics of 1798 Operation Instance Identifier is as follows: 1800 o Operation Instance Identifier is one byte and can have values from 1801 0 to 255. 1803 o Operation Instance Identifier is sent as the first byte of the 1804 operations parameter (without encoding). 1806 o The length of Operation Instance Identifier is 8-bit, but 1807 depending on the performer capabilities, it might keep 0 to 127 1808 Operation Instance Identifiers for duplication detection. The 1809 performer profile defines the number of outstanding Operation 1810 Instance Identifiers that are checked against duplication. When a 1811 performer profile indicates support for 0 outstanding Operation 1812 Instance Identifier, it means it does not have support for 1813 Duplicate Operation Detection. In this case, there should be only 1814 one outstanding operation at any point of time. 1816 o Instance ID check is not part of ESROS, per se. Use of Duplicate 1817 Detection is determined by EMSD-P. Operation Instance ID for 1818 operations 32-63 is the first byte of the argument. Duplicate 1819 Detection suuport strips that byte. 1821 o The Instance ID is not subject to Basic Encoding Rules (BER). 1823 o The invoker user assigns the Operation Instance Identifier to the 1824 operation at the time of requesting the invoke service. The 1825 Operation Value should be in the range of operation values with 1826 duplication detection support, i.e. 32 to 63. 1828 o It's the responsibility of the user to choose Operation Instance 1829 Identifier in a way that uniqely and unambiguously identifies the 1830 operation. 1832 o From the invoker's perspective, assumption is that two operations 1833 with the same operation Instance Identifier are totally identical 1834 which means they produce exact same results. 1836 o Operation Instance Identifier uniqely specifies a non-idempotent 1837 operation and multiple invocations of such an operation will 1838 eventually result in the same outcome because the duplicate 1839 instances are identified and the operation is not performed more 1840 than once. 1842 o From the performer's perspective, assumption is that two 1843 operations with the same Operation Instance Identifier should be 1844 executed once and once only. 1846 o If requested, the degree of duplication checked by Duplicate 1847 Operation Detection Support Functional Unit on the performer's 1848 side (i.e. the total number of outstanding Operation Instance 1849 Identifier kept) can be communicated with the invoker to 1850 synchronize the invocations. 1852 o User of Duplicate Operation Detection Support is responsible to 1853 behave based on the performer profile and its limitations in this 1854 regard. This behavior is defined based on the desired semantic of 1855 the operation which is to be implemented. 1857 o On the performer side, when an Operation Instance Identifier is 1858 received, a previous Operation Instance Identifier whose distance 1859 to this latest one is greater than or equal to half of the 1860 wrap-around range of the Operation Instance Identifier number is 1861 expired, i.e. for an 8-bit Operation Instance Identifier, the 1862 distance of 128 causes an old Operation Instance Identifier to 1863 expire. 1865 o It's the responsibility of the invoker user to use consecutive 1866 Operation Instance Identifier numbers, or when it skips some 1867 Operation Instance Identifiers, it should remember that if there 1868 is an smaller Operation Instance Identifier on performer side with 1869 the distance explained above, it will be expired. 1871 5 EMSD PROCEDURE FOR OPERATIONS 1873 The following sections shows the general procedures to be used in the 1874 implementation of the EMSD Message Transfer Server (MTS) and the EMSD 1875 User Agent (UA), with the option for 3-Way or 2-Way handshakes on 1876 operations which support them. These procedures do not constitute 1877 complete behavior specifications for implementations. The following 1878 sections contain information helpful to implementors. 1880 The MTS and the UA are event-driven. Each waits for any of the 1881 possible event types, and, upon receiving an event, processes it. 1882 After processing the event, the next event is waited upon. 1884 5.1 MTS Behavior 1886 The MTS is event-driven. 1888 If it received an event from ESROS, then it could be any of the 1889 following types: 1891 o Message submit indication; 1893 o Message submit confirm and failure indication; 1895 o Result and Error indication for a deliver operation; 1897 o DeliveryVerify indication; 1899 o Result and Error indication for a submissionVerify operation; 1901 o Result and Error indication for a submissionControl operation; 1903 o DeliveryControl indication. 1905 For an ESROS event responsibility is passed to the MTS performer 1906 (Section 5.1.1). 1908 If the MTS received an event: 1910 o for message delivery, from the RFC-822 mailer; 1912 o requesting submission controls upon the UA, or; 1914 o indicating an elapsed timer (meaning that it's time to re-attempt 1915 a message delivery) 1917 then responsibility is passed to the MTS invoker (Section 5.1.5). 1919 5.1.1 MTS Performer 1921 The MTS performer is responsible for processing the following 1922 operations, received from ESROS: 1924 o Message-submission 1926 o Delivery-control 1928 o Delivery-verify 1930 The MTS performer should first make sure that it has received an 1931 INVOKE.indication. Any other type of primitive shouldn't be occurring 1932 at this point, and should be ignored. 1934 If there's something wrong with the PDU or operation data, the MTS 1935 performer should send back an error to the proper invoker: 1937 1. Send an ESROS Error Request, then go wait for a response (either a 1938 confirmation or a failure indication). The response is sent back 1939 on the same SAP type on which the event occurred. 1941 2. Keep track of the type of request that was issued. 1943 If there isn't anything wrong with the PDU or operation data, then the 1944 MTS performer has received a valid event from ESROS. This could be any 1945 of the defined Submission and Delivery Protocol operations. 1947 5.1.2 Message-submission 1949 1. The Message-submission operation first checks to see which SAP 1950 this Submit Request came in on. 1952 2. The request could have arrived as 2-Way SAP (see #3) or a 3-Way 1953 SAP (see #7). 1955 3. If the event arrived on the 2-Way SAP, consider this a protocol 1956 violation and ignore it. 1958 4. Wait for a response to the request. The response could be either 1959 an ERROR.confirm (see #5) or a FAILURE.indication (see #6). 1961 5. The ERROR.request has been confirmed. The UA knows that the 1962 submitted message wasn't sent. Since there was an error, there is 1963 nothing more to do, so return. 1965 6. If the result to the ErrorRequest is a Failure.indication, it can 1966 be assumed that either the UA has received nothing (the 1967 ERROR.request PDU was lost), which means failure for the UA; or 1968 that the 3-Way acknowledgment was lost, which means that the UA 1969 has in fact received the ERROR.request PDU and knows about the 1970 delivery failure. Either way, the message can be ignored. There 1971 is nothing more to do, so return. 1973 7. If the event was received on the 3-Way SAP, then this is the 1974 correct SAP on which to receive a Submit Request. Send back a 1975 Result Request and keep track of the primitive which was issued. 1977 8. Now wait for a response to our request. The response will be 1978 either a Result.confirm (see #9) or a Failure.indication (see 1979 #13). 1981 9. The RESULT.request has been confirmed. 1983 10. Submit the message to the RFC-822 mailer. 1985 11. Attempt, a number of times, to send the submitted message via the 1986 RFC-822 mailer. If the send was successful, then return. 1988 12. If, after the maximum number of retries, the message was not able 1989 to be sent, consider it a failure. Since the UA assumption has 1990 been that submission was successful, but now it has not been sent, 1991 a brand new message, a Non-Delivery message, must be generated and 1992 delivered to the UA. When this is completed, then return. 1994 13. A FAILURE.indication has occurred due to the previously issued 1995 RESULT.request. 1997 14. A Submission Verification is issued to the UA to see if the 1998 RESULT.request was received. There are three possible results 1999 from sending the submission verification to the UA: Fail (see 2000 #15), Send Message (see #16) or Drop Message (see #20). 2002 15. Fail -- The Submission-verify request didn't reach the UA, or the 2003 Submission Verify response didn't get back. Ignore the message 2004 and return. 2006 16. The Submission Verify operation succeeded, meaning that the UA 2007 received the request, and responded with a message stating that it 2008 wants the message to be sent. 2010 17. Attempt, a number of times, to send the submitted message via the 2011 RFC-822 mailer. 2013 18. If the message was submitted to the RFC-822 mailer successfully, 2014 then return. If, after the maximum number of retries, the message 2015 was not able to send the message, consider it a failure. 2017 19. The UA already assumes that the Message-submission was successful. 2018 Now since the submitted message has not been sent, a brand new 2019 message, a Non-Delivery message, must be generated and delivered 2020 to the UA. After this is accomplished, then return. 2022 20. The UA responded with a message stating that the message should be 2023 dropped. This may occur if the UA never received the result from 2024 the MTS, meaning that it never received the Message Id, and had to 2025 therefore inform the user that the message couldn't be submitted. 2026 This may also occur if the UA doesn't have the record of the 2027 message being verified. It can be because the message record has 2028 been aged and expired, or because the EMSD-UA has not been able to 2029 keep the record of the received message because of storage or 2030 memory limitations. There is nothing to do, so return. 2032 5.1.3 Delivery-control 2034 This operation can be processed immediately. After it is processed, 2035 the appropriate result is returned. 2037 5.1.4 Delivery-verify 2039 This operation occurs when the UA doesn't think that the MTS has 2040 received the RESULT.indication from a previously delivered message. 2041 The UA wants to make sure that the MTS knows it has been delivered. 2042 The MTS will determine what it knows of the specified message, and 2043 send back a result. This can be processed immediately, as it doesn't 2044 need to deal with duplicate detection. 2046 5.1.5 MTS Invoker 2048 The MTS invoker is responsible for processing the following 2049 operations, received from ESROS: 2051 o Message-delivery 2053 o Submission-control 2055 o Submission-verify 2057 Submission-control 2059 Process the Submission Control request. 2061 Message-delivery 2063 1. Check the User Agent's profile to determine the SAP. 2065 2. Set the SAP to 3-Way. 2067 3. Issue the INVOKE.request on the appropriate SAP, with duplication 2068 detection enabled. Since a local error is possible on issuing the 2069 INVOKE.request, a retry counter is needed. 2071 4. There are three possible events possible in result to the 2072 INVOKE.request: an ERROR.indication (see #5), a RESULT.indication 2073 (see #9) or a FAILURE.indication (see #10). 2075 5. An ERROR.indication was received, which means that the UA can't 2076 accept the message right now. 2078 6. If the reason was one of a transient nature, wait for a while and 2079 then send the Deliver Request again. 2081 7. If the reason was one of a permanent nature, send back a 2082 non-delivery report to the originator. 2084 8. Since the error was one of a permanent nature, then the MTS must 2085 send back a non-delivery report, then log the unsuccessful 2086 delivery with error from UA and return. 2088 9. A RESULT.Indication was returned, which means that the Delivery 2089 was successful. Send a delivery report to the originator if one 2090 was requested and log successful delivery and return. 2092 If the UA profile indicated that Complete mode was to be used, 2093 keep track of the fact that this message has been successfully 2094 delivered (as far as the MTS is concerned), so that if the UA 2095 sends us a Delivery Verify operation, we know that we consider the 2096 message to be delivered. 2098 10. A FAILURE.indication was returned, which means there was a problem 2099 getting the Deliver Request to the UA, or in getting the response 2100 back from the UA. In any case, a response was never received, so 2101 the request timed out. Wait for a while, and then send the 2102 Deliver Request again. 2104 As long as a FAILURE.indication is returned and the number of 2105 retries has not been exceeded, keep trying to verify the delivery. 2107 Submission-verify 2109 The Submission-verify operation is always issued on the 2-Way SAP. The 2110 response is awaited. If a response doesn't come, the request is 2111 queued and attempted again later. 2113 1. Issue the INVOKE.request on the 2-Way SAP, with duplication 2114 detection disabled. Since a local error on issuing the invoke 2115 request is possible, a retry counter is needed. 2117 2. An INVOKE.Request has been issued and a response has been 2118 received. The response will be either a a RESULT.indication (see 2119 #3) or a FAILURE.indication (see #4). There are no defined errors 2120 to a Submission Verify operation, so an ERROR.indication should 2121 not be occurring here. 2123 3. A RESULT.indication was received. Either ResponseSendMessage or 2124 ResponseDropMessage, as specified in the PDU, will be returned. 2126 4. A FAILURE.indication was received, which means that there was a 2127 problem getting the Submission Verify Request to the UA, or in 2128 getting the response back from the UA. In any case, the response 2129 was never received, so the request timed out. Wait for a while, 2130 and then another attempt to send the Submission Verify request is 2131 needed. 2133 Non-Delivery Report 2135 Issue an INVOKE.request containing a Submit operation with a content 2136 type of Non- Delivery Report, to the UA. This operation is always 2137 issued on the 2-Way SAP. The response is awaited. If a response 2138 doesn't come, the request is queued and attempted again later. 2140 1. Create a Submit operation. 2142 2. Issue the INVOKE.request on the 2-Way SAP, with duplication 2143 detection enabled. Since a local error on issuing the invoke 2144 request is possible, a retry counter for is needed. 2146 3. A response to the INVOKE.Request has been received. The response 2147 will be either a RESULT.indication (see #5), ERROR.indication (see 2148 #4), or a FAILURE indication (see #7). 2150 4. An ERROR.indication was received, which means that the UA doesn't 2151 know what to do with our non-delivery report. That's the UAs 2152 problem, so just do nothing and return. 2154 5. A RESULT.indication was received, which means we delivered a 2155 successful non-delivery report. 2157 6. The result is logged. Nothing more is needed, so return. 2159 7. A FAILURE.indication was received, which means there was a problem 2160 getting the Submit Request to the UA, or in getting the response 2161 back from the UA. In any case, the response was never, so the 2162 request timed out. Wait for a while, and then send the Submission 2163 Verify request again. 2165 5.2 UA Behavior 2167 The User Agent is event-driven. 2169 If it received an event from ESROS, then it could be any of the 2170 following types: 2172 o Message deliver indication; 2174 o Message deliver confirm and failure indication; 2176 o Result and Error indication for a submit operation; 2178 o Submission verify indication; 2180 o Result and Error indication for a delivery verify operation; 2182 o Result and Error indication for a delivery control operation; 2184 o Submission control indication. 2186 For an ESROS event responsibility is passed to the UA performer 2187 (Section 5.2.1). 2189 IF the UA received an event indicating that there's a message from the 2190 user, for submission, then responsibility is passed to the UA invoker 2191 (Section 5.2.2). 2193 5.2.1 UA Performer 2195 The performer on the UA side is responsible for processing the 2196 following operations: 2198 o Message Delivery 2200 o Submission Verification 2202 o Submission Control 2204 Message-delivery 2206 1. A Message-delivery request is received. 2208 2. Check for the correctness of the PDU. If the PDU is bad the see 2209 #3. If the PDU is good then see #8. 2211 3. Send an ESROS ERROR.request. If the request arrived on a 3-Way 2212 SAP, use a 3-Way SAP for the result. If the request arrived on a 2213 2-Way SAP, use a 2-Way SAP for the result. Keep track of the type 2214 of request that was issued. 2216 4. Wait for the ESROS event. The result could be an ERROR.confirm 2217 (see #5) or a FAILURE.indication (see #7). 2219 5. The ESROS event was an ERROR.confirm 2221 6. Log the message as the Non-Delivery was confirmed by the MTS and 2222 return. 2224 7. If the ESROS event was a FAILURE.indication, that means one of two 2225 things has occurred: 2227 A. The MTS has received nothing (the ERROR.request PDU was lost), 2228 which means that the MTS doesn't know that the message delivery 2229 has been rejected. In this case, the MTS will eventually time 2230 out, and retransmit the message delivery request. 2232 B. The 3-Way acknowledgment was lost, which means that the MTS has 2233 in fact received the ERROR.request PDU and knows about the 2234 delivery failure. 2236 Either way, the message can now be ignored. 2238 8. Send an ESROS RESULT.request. If the request arrived on a 3-Way 2239 SAP, use a 3-Way SAP for the result. If the request arrived on a 2240 2-Way SAP, use a 2-Way SAP for the result. Keep track of the type 2241 of request that was issued. 2243 9. Wait for the ESROS event. The result could be an RESULT.confirm 2244 (see #10) or a FAILURE.indication (see #13). 2246 10. If the event is a RESULT.confirm, then the delivered message can 2247 now be given to the user. 2249 11. Deliver the message to the user. 2251 12. Log the message as Message Delivery Known to MTS. 2253 13. If the event is a FAILURE.indication, then, if the delivery was on 2254 a 3-Way SAP, a Delivery Verification request to the MTS can be 2255 issued to see if the MTS actually got the RSULT.request. If the 2256 delivery was on a 2-Way SAP, then the message will delivered to 2257 the user and if the MTS has not received the RESULT.request, it 2258 will retransmit it later and the duplicate will be ignored. 2260 14. Deliver the message to the user. Since a FAILRUE.indication was 2261 received in response to a RESULT.requst, it means that possible, 2262 the MTS didn't receive the RESULT.request. The MTS could now time 2263 out, and send another copy of the same message. Save the message 2264 for duplication detection. 2266 15. Log the fact that the message was delivered, but that the MTS 2267 might not be aware of it. 2269 16. If the UA supports Delivery Verification, and the Delivery Request 2270 was sent on the 3-Way SAP, then see #17. If either of these 2271 conditions are not true, then return. 2273 17. Send a Delivery-verify request to see if the MTS got the 2274 RESULT.request. 2276 There are three possible results from sending the delivery 2277 verification to the MTS: Fail (see #18), ResponseNonDelivery (see 2278 #20) or ResponseDelivery (see #23). 2280 18. Fail -- Delivery Verify request didn't reach the MTS, or the 2281 Delivery Verify response didn't get back to the UA. 2283 19. Log this as delivering the message to the user, but the MTS having 2284 possibly sent a Non-Delivery report to the originator even though 2285 the UA did actually deliver the message to the user. Then return. 2287 20. ResponseNonDelivery -- Verify Response indicates that the MTS now 2288 knows (because of the Delivery Verify operation that the message 2289 has been delivered to the user, but had not received our 2290 RESULT.request nor a Delivery Verify operation in a timely manner, 2291 and had already sent out a Non-Delivery report to the originator. 2293 21. The MTS had not received, from the UA, in a timely manner, a 2294 RESULT.indication indicating that the message had been delivered 2295 to the user. The MTS has already sent a Non-Delivery report to 2296 the originator. The UA must let the user know about this. Log 2297 the message as delivered to the user, but a Non-Delivery sent to 2298 the originator. 2300 22. Since the UA received a response to the Verify operation, it knows 2301 that the MTS knows about this message delivery, so the UA also 2302 knows that it won't be receiving a duplicate of it. The UA can 2303 now remove this message's Message Id from the list of possible 2304 duplicates. 2306 23. ResponseDelivery -- Verify Response received from MTS. 2308 24. This means that the MTS knows (either because the MTS had received 2309 the RESULT.request that was sent by the UA or because the MTS has 2310 now received the UAs Delivery-verification message, informing that 2311 the UA received the message for delivery to the user. The MTS is 2312 (or was) able to send a Delivery report to the originator if one 2313 was requested. Log it as such. 2315 25. Since the UA received a response to the Verify operation, it knows 2316 that the MTS knows about this message delivery, so the UA also 2317 knows that it won't be receiving a duplicate of it. The UA can 2318 now remove this message's Message Id from the list of possible 2319 duplicates and return. 2321 Submission-verify 2323 Process the Submission-verify request and return. 2325 Submission-control 2327 This operation can be processed immediately. After it is processed, 2328 the appropriate result is returned. 2330 5.2.2 UA Invoker 2332 The invoker on the UA side is responsible for processing the following 2333 operations: 2335 o Message-submission 2337 o Delivery-control 2339 o Delivery-verify 2341 Message-submission 2343 General procedures for UA's Message-submission mirror that of MTS's 2344 Message-delivery. 2346 Delivery-control 2348 1. Issue the INVOKE.request on the 3-Way SAP, with duplication 2349 detection enabled. Since the UA can get a local error on issuing 2350 the invoke request, a retry counter is needed. 2352 If we got a local failure in issuing the Invoke Request, wait a 2353 while and then try again (up to the limit of the maximum number of 2354 retries). 2356 2. The UA has issued an INVOKE.Request. Wait for a response from 2357 ESROS. The response will be either a RESULT.indication (see #5), 2358 ERROR.indication (see #3), or FAILURE.indication (see #7). 2360 3. A ERROR.indicaiton was received, meaning that the MTS told says 2361 that it cannot accept the message. 2363 4. Log the MTS rejection and return 2365 5. A RESULT.indication was received, which means that the Submission 2366 was successful. 2368 6. Log successful submission and return. 2370 7. a FAILURE.indication was received, meaning that there was a 2371 problem getting the Submit Request to the MTS, or in getting the 2372 response back from the MTS. In any case, the UA never received the 2373 response, so the request timed out. Wait for a while, and then 2374 send the Submit Request again. 2376 8. The UA has exceeded the maximum number of retries. Let the user 2377 know, log the failure and return. 2379 Delivery-verify 2381 General procedures for UA's Delivery-verify mirror that of MTS's 2382 Submission-verify. 2384 6 EMSD FORMAT STANDARDS 2386 6.1 Format Standard Overview 2388 EMSD Format Standard (EMSD-FS) is a non-textual form of compact 2389 encoding of Internet mail (RFC-822) messages which facilitates 2390 efficient transfer of messages. EMSD-FS is used in conjunction with 2391 the EMSD-P but is not a general replacement for RFC-822. EMSD-FS 2392 defines a method of representation of short interpersonal message. It 2393 defines the ``Content'' encoding (Header + Body). Although EMSD-FS 2394 contains end-to-end information its scope is purely point-to-point. 2396 The "Efficient InterPersonal Message Format Standard" is defined in 2397 this section. This standard is primarily intended for communication 2398 among people. 2400 The EMSD Format Standard is designed to be fully consistent with 2401 RFC-822 [3]. In many ways EMSD-FS can be considered to be an 2402 efficiency oriented encoder and decoder. Through use of EMSD-FS an 2403 RFC-822 message is converted to a more compact binary encoding. This 2404 more compact message is then transfered between an EMSD-SA and 2405 EMSD-UA. The compact message (represented in EMSD-FS) may then be 2406 converted back to RFC-822 intact. 2408 For messages that are originated (submitted) with EMSD protocol, 2409 certain fields (e.g., addresses, message-id) can have special forms 2410 that are specialized and produce more compact EMSD-FS encoding. These 2411 special forms are legitimate values of RFC-822 messages. 2413 This specification expresses information objects using ASN.1 [X.208]. 2414 Encoding of ASN.1 shall be based on Basic Encoding Rules (BER) [5]. 2415 Future revisions of this specification will use Packed Encoding Rules 2416 (PER) [4]. 2418 The convention of (O) "OPTIONAL", (D) "DEFAULT", (C) "CONDITIONAL" and 2419 (M) "MANDATORY" which express requirements for presence of information 2420 is used in this section. 2422 6.2 Interpersonal Messages 2424 An interpersonal message (IPM) consists of a heading and a body. 2426 IPM ::= SEQUENCE 2428 { 2430 heading Heading, 2432 body Body OPTIONAL 2434 }; 2436 6.2.1 Heading fields 2438 The fields that may appear in the Heading of an IPM are defined and 2439 described below. 2441 Heading ::= SEQUENCE 2442 { 2443 -- Address of the sending agent (person, program, machine) of 2444 -- this message. This field is mandatory if the sender 2445 -- is different than the originator. 2446 sender [0] EMSDORAddress OPTIONAL, 2448 -- Address of the originator of the message 2449 -- (not necessarily the sender) 2450 originator EMSDORAddress, 2452 -- List of recipients and flags associated with each. 2453 recipient-data SEQUENCE SIZE (1..ub-recipients) 2454 OF PerRecipientFields, 2456 -- Flags applying to this entire message 2457 per-message-flags [1] IMPLICIT BIT STRING 2459 { 2460 -- Priority values 2461 -- At most one of "non-urgent" and "urgent" may be specified 2462 -- concurrently. If neither is specified, then a Priority 2463 -- level of "normal" is assumed. 2464 priority-non-urgent (0), 2465 priority-urgent (1), 2467 -- Importance values 2468 -- At most one of "low" and "high" may be specified 2469 -- concurrently. If neither is specified, then an 2470 -- Importance level of "normal" is assumed. 2471 importance-low (2), 2472 importance-high (3), 2474 -- Indication of whether this message has been 2475 automatically forwarded 2476 auto-forwarded (4) 2477 } OPTIONAL, 2479 -- User-specified recipient who is to receive replies 2480 to this message. 2481 reply-to [2] IMPLICIT SEQUENCE SIZE 2482 (1..ub-reply-to) 2483 OF EMSDORAddress OPTIONAL, 2485 -- Identifier of a previous message, for which this message 2486 -- is a reply 2487 replied-to-IPM EMSDMessageId OPTIONAL, 2489 -- Subject of the message. 2490 subject [3] IMPLICIT AsciiPrintableString 2491 (SIZE (0..ub-subject-field)) 2492 OPTIONAL, 2494 -- RFC-822 header fields not explicitly provided for in 2495 -- this Heading. For messages incoming from the external 2496 -- world (i.e. in RFC-822 format), the Message-Id: field 2497 -- need not go here, as it is placed in the 2498 -- Envelope's EMSDMessageId (message-id) field. 2499 extensions [4] IMPLICIT SEQUENCE 2500 (SIZE (0..ub-header-extensions)) 2501 OF IPMSExtension OPTIONAL, 2503 -- MIME Version (if other than 1.0) 2504 mime-version [5] IMPLICIT AsciiPrintableString 2505 (SIZE (0..ub-mime-version-length)) 2506 OPTIONAL, 2508 -- Top-level MIME Content Type 2509 mime-content-type [6] IMPLICIT AsciiPrintableString 2510 (SIZE (0.. 2511 ub-mime-content-type-length)) 2512 OPTIONAL, 2514 -- MIME Content Id 2515 mime-content-id [7] IMPLICIT AsciiPrintableString 2516 (SIZE (0.. 2517 ub-mime-content-id-length)) 2518 OPTIONAL, 2520 -- MIME Content Description 2521 mime-content-description [8] IMPLICIT AsciiPrintableString 2522 (SIZE (0..ub-mime-content- 2523 description-length)) 2524 OPTIONAL, 2525 -- Top-level MIME Content Type 2526 mime-content-transfer-encoding 2527 [9] IMPLICIT AsciiPrintableString 2528 (SIZE (0..ub-mime-content- 2529 transfer-encoding)) 2530 OPTIONAL 2531 }; 2533 Some fields have components and thus are composite, rather than 2534 indivisible. A field component is called a sub-field. 2536 Sender 2538 This field is mandatory if the sender is different from the 2539 originator. 2541 Originator 2543 The Originator heading field (O) identifies the IPM's originator. 2545 Recipient-data 2547 PerRecipientFields ::= SEQUENCE 2548 { 2549 recipient-address EMSDORAddress, 2550 per-recipient-flags BIT STRING 2552 { 2553 -- Recipient Types. 2554 -- At most one of "copy" and "blind-copy" may be 2555 -- specified concurrently for a single recipient. If 2556 -- neither is specified, than the recipient 2557 -- is assumed to be a "primary" recipient. 2558 recipient-type-copy (0), 2559 recipient-type-blind-copy (1), 2561 -- Notification Request Types. 2562 -- Only one of "rn" and "nrn" may be specified 2563 -- concurrently, \\x110011 for a single recipient. 2564 -- "rn" implies "nrn" in addition. 2565 notification-request-rn (2), 2566 notification-request-nrn (3), 2568 notification-request-ipm-return (4), 2570 -- Report Request Types 2571 -- At most one of these should be set for a 2572 -- particular recipient. "delivery" implies "non-delivery" 2573 -- in addition. 2574 report-request-non-delivery (5), 2575 report-request-delivery (6), 2577 -- Originator-to-Recipient request for a reply. 2578 reply-requested (7) 2579 } DEFAULT { report-request-non-delivery } 2581 }; 2583 recipient-address 2585 The Primary Recipients heading field identifies the zero or more users 2586 who are the "primary recipients" of the IPM. The primary recipients 2587 might be those users who are expected to act upon the IPM. 2589 per-recipient-flags 2591 The Copy Recipients heading field identifies the zero or more users 2592 who are the "copy recipients" of the IPM. The copy recipients might be 2593 those users to whom the IPM is conveyed for information. 2595 recipient-type-copy 2597 This field is set if the recipient is on the Carbon Copy (CC) list. 2599 recipient-type-blind-copy 2601 This field is set if the recipient is on the Blind Carbon Copy (BCC) 2602 list. 2604 The Blind Copy Recipients heading field (C) identifies zero or more 2605 users who are the intended blind copy recipients of the IPM. 2607 The phrase "copy recipients" above has the same meaning as in "Copy 2608 Recipients" from Section 6.2.1 . A blind copy recipient is one whose 2609 role as such is disclosed to neither primary nor copy recipients. 2611 In the instance of an IPM intended for a blind copy recipient, this 2612 conditional field shall be present and identify that user. Whether it 2613 shall also identify the other blind copy recipients is a local matter. 2614 In the instance of the IPM intended for a primary or copy recipient, 2615 the field shall be absent. 2617 notification-request-rn 2619 A receipt notification (rn) reports its originator's receipt, or his 2620 expected and arranged future receipt, of an IPM. 2622 notification-request-nrn 2624 A non-receipt notification (nrn) reports its originator's failure to 2625 receive, to accept, or his delay in receiving, an IPM. 2627 notification-request-ipm-return 2629 When this field is set, the contents of the message are returned along 2630 with the notification. 2632 report-request-non-delivery 2634 The report request enables the MTS to acknowledge to the MTS-user one 2635 or more outcomes of a previous invocation of the message-submission or 2636 probe-submission abstract-operations. 2638 A report is returned only in case of non-delivery. 2640 report-request-delivery 2642 For the message-submission, report-delivery indicates the delivery or 2643 non-delivery of the submitted message to one or more recipients. For 2644 the probe-submission, the report- delivery indicates whether or not a 2645 message could be delivered if the message were to be submitted. 2647 reply-requested 2649 When set this field indicates that the originator requests that a 2650 recipient send a message in reply to the message which carries the 2651 request. 2653 per-message-Flags 2655 Priority 2657 The Priority field (default is normal) identifies the priority that 2658 the authorizing users attach to the IPM. It may assume any one of the 2659 following values: urgent, normal, or non-urgent. 2661 At most one of either "non-urgent" or "urgent" may be specified 2662 concurrently. If neither is specified, then a Priority level of 2663 "normal" is assumed. 2665 Importance 2667 The Importance heading field (default normal) identifies the 2668 importance that the authorizing users attach to the IPM. It may assume 2669 any one of the following values: low, normal, or high. 2671 At most one of either "low" or "high" may be specified concurrently. 2672 If neither is specified, then a Importance level of "normal" is 2673 assumed. 2675 The values above are not defined by this specification; they are given 2676 meaning by users. 2678 auto-forwarded 2680 The Auto-forwarded heading field (default is false) indicates whether 2681 the IPM is the result of auto-forwarding. It is a Boolean value. 2683 reply-to 2685 User-specified recipient or recipients who are to receive replies to 2686 this message. 2688 replied-to IPM 2690 The Replied-to IPM heading field (C) identifies the IPM to which the 2691 present IPM is a reply. It comprises an IPM identifier. 2693 This conditional field shall be present if, and only if, the IPM is a 2694 reply. 2696 Note - In the context of forwarding, care should be taken to 2697 distinguish between the forwarding IPM and the forwarded IPM. This 2698 field should identify whichever of these two IPMs to which the reply 2699 responds. 2701 subject 2703 The Subject heading field (O) identifies the subject of the IPM. It 2704 corresponds to the "Subject:" field of RFC-822. 2706 extensions 2708 The Extensions heading field [D no extensions (i.e. members)] conveys 2709 information accommodated by no other heading field. It comprises a 2710 Set of zero or more IPMS extensions, each conveying one such 2711 information item. 2713 IPMSExtension ::= SEQUENCE 2714 { 2715 x-header-label AsciiPrintableString, 2716 x-header-value AsciiPrintableString 2717 }; 2719 6.2.2 Body part types 2721 The types of body parts that may appear in the Body of an IPM are 2722 structured using the MIME specification. 2724 Body ::= SEQUENCE 2725 { 2726 compression-method [0] IMPLICIT CompressionMethod 2727 OPTIONAL, 2728 -- If compression method is not specified, 2729 -- "no-compression" is implied. 2731 message-body OCTET STRING 2732 -- See MIME for structure of the Body. 2733 -- If a compression method is specified, the entire text containing 2734 -- the Content-Type: element followed by the RFC-822 body are 2735 -- compressed using the specified method, and placed herein. 2736 }; 2738 CompressionMethod ::= INTEGER 2739 { 2740 -- Compression Methods numbered 0 to 63 are reserved for 2741 -- assignment within this and associated specifications. 2742 no-compression (0), 2743 lempel-ziv (1) 2745 -- Compression Methods numbered between 64 and 127 may be 2746 -- used on a bilaterally-agreed basis between peers. 2747 } (0..127) 2749 7 ACKNOWLEDGMENTS 2751 In the context of Limited Size Messaging (LSM) over CDPD and pACT over 2752 Narrowband PCS, AT&T Wireless Services (AWS), funded work which was 2753 relevant to the development of the EMSD protocols. 2755 8 SECURITY CONSIDERATIONS 2757 This protocol supports simple authentication of the originator's 2758 address by the EMSD-SA and simple authentication of EMSD-SA by 2759 EMSD-UA. 2761 Mainstream Internet mail security mechanisms can be used in 2762 conjunction with the EMSD protocol. 2764 9 AUTHOR'S ADDRESS 2766 Mohsen Banan 2767 Neda Communications, Inc. 2768 17005 SE 31st Place 2769 Bellevue, WA 98008 2770 email: mohsen@neda.com 2771 A EMSD-P ASN.1 MODULE 2773 This section compiles in one place the complete ASN.1 Module for EM 2774 Submission and Delivery Protocol. 2776 EMSD-SubmissionAndDeliveryProtocol DEFINITIONS ::= 2778 BEGIN 2780 EXPORTS EMSDORAddress, AsciiPrintableString, ContentType, 2781 DateTime, EMSDMessageId, EMSDORAddress, ProtocolVersionNumber; 2783 -- Upper bounds 2785 ub-recipients INTEGER ::= 256; 2786 -- also defined in EMSD-InterpersonalMessaging1995 2787 ub-reply-to INTEGER ::= 256; 2788 -- also defined in EMSD-InterpersonalMessaging1995 2789 ub-subject-field INTEGER ::= 128; 2790 -- also defined in EMSD-InterpersonalMessaging1995 2791 ub-password-length INTEGER ::= 16; 2792 ub-content-length INTEGER ::= 65535; 2793 -- also defined in EMSD-Probe 2794 ub-content-types INTEGER ::= 128; 2795 ub-message-id-length INTEGER ::= 127; 2796 ub-total-number-of-segments INTEGER ::= 32; 2797 ub-header-extensions INTEGER ::= 64; 2798 -- also defined in EMSD-InterpersonalMessaging1995 2799 ub-emsd-name-length INTEGER ::= 64; 2800 ub-emsd-address-length INTEGER ::= 20; 2801 ub-rfc822-name-length INTEGER ::= 127; 2802 ub-mime-version-length INTEGER ::= 8; 2803 -- also defined in EMSD-InterpersonalMessaging1995 2804 ub-mime-content-type-length INTEGER ::= 127; 2805 -- also defined in EMSD-InterpersonalMessaging1995 2806 ub-mime-content-id-length INTEGER ::= 127; 2807 -- also defined in EMSD-InterpersonalMessaging1995 2808 ub-mime-content-description-length INTEGER ::= 127; 2809 -- also defined in EMSD-InterpersonalMessaging1995 2810 ub-mime-content-transfer-encoding INTEGER ::= 127; 2811 -- also defined in EMSD-InterpersonalMessaging1995 2812 ub-local-message-nu INTEGER ::= 4096; 2814 ---------------------- 2815 -- SUBMIT Operation -- 2816 ---------------------- 2818 submit ES-OPERATION 2819 ARGUMENT SubmitArgument 2820 RESULT SubmitResult 2821 ERRORS 2822 { 2823 submissionControlViolated, 2824 securityError, 2825 resourceError, 2826 protocolViolation, 2827 messageError 2828 } ::= 33; 2830 SubmitArgument ::= SEQUENCE 2831 { 2832 -- Security features 2833 security [0] IMPLICIT SecurityElement 2834 OPTIONAL, 2836 -- Segmentation features for efficient transport 2837 segment-info SegmentInfo OPTIONAL, 2839 -- Content type of the message 2840 content-type ContentType, 2842 -- 2843 -- THE CONTENT -- 2844 -- 2846 -- The submission content 2847 content ANY DEFINED BY content-type 2849 }; 2851 SubmitResult ::= SEQUENCE 2853 { 2855 -- Permanent identifier for this message. 2856 -- Also contains the message submission time. 2857 -- See comment regarding assignment of message 2858 -- identifiers, at the definition of EMSDLocalMessageId. 2859 message-id EMSDLocalMessageId 2860 }; 2862 -------------------------------- 2863 -- Delivery Control Operation -- 2864 -------------------------------- 2866 deliveryControl ES-OPERATION 2867 ARGUMENT DeliveryControlArgument 2868 RESULT DeliveryControlResult 2869 ERRORS 2870 { 2871 securityError, 2872 resourceError, 2873 protocolViolation 2874 } ::= 2; 2876 DeliveryControlArgument ::= SEQUENCE 2877 { 2878 -- Request an addition of or removal of a set of restrictions 2879 restrict [0] IMPLICIT Restrict DEFAULT update, 2881 -- Which operations are to be placed in the restriction set 2882 permissible-operations [1] IMPLICIT Operations OPTIONAL, 2884 -- What maximum content length should be allowed 2885 permissible-max-content-length 2886 [2] IMPLICIT INTEGER 2887 (0..ub-content-length) OPTIONAL, 2889 -- What is the lowest priority message which may be delivered 2890 permissible-lowest-priority 2891 [3] IMPLICIT ENUMERATED 2892 { 2893 non-urgent (0), 2894 normal (1), 2895 urgent (2) 2896 } OPTIONAL, 2898 -- Security features 2899 security [4] IMPLICIT SecurityElement 2900 OPTIONAL, 2902 -- User Feature selection 2903 user-features [5] IMPLICIT OCTET STRING OPTIONAL 2904 }; 2906 DeliveryControlResult ::= SEQUENCE 2907 { 2908 -- Operation types queued at the EMSD-SA due to existing 2909 -- restrictions. 2910 waiting-operations [0] IMPLICIT Operations DEFAULT { }, 2912 -- Types of messages queued at the EMSD-SA due to 2913 -- existing restrictions 2914 waiting-messages [1] IMPLICIT WaitingMessages DEFAULT { }, 2916 -- Content Types of messages queued at the EMSD-SA 2917 waiting-content-types SEQUENCE SIZE (0..ub-content-types) OF 2918 ContentType DEFAULT { } 2919 }; 2920 Restrict ::= ENUMERATED 2921 { 2922 update (1), 2923 remove (2) 2924 }; 2926 Operations ::= BIT STRING 2927 { 2928 submission (0), 2929 delivery (1) 2930 }; 2932 WaitingMessages ::= BIT STRING 2933 { 2934 long-content (0), 2935 low-priority (1) 2936 }; 2938 -- Delivery Verify Operation 2940 deliveryVerify ES-OPERATION 2942 ARGUMENT DeliveryVerifyArgument 2943 RESULT DeliveryVerifyResult 2944 ERRORS 2945 { 2946 verifyError, 2947 resourceError, 2948 protocolViolation 2949 } ::= 5; 2951 DeliveryVerifyArgument ::= SEQUENCE 2952 { 2953 -- Identifier of this message. This is the same identifier that 2954 -- was provided to the originator in the Submission Result. 2955 -- See comment regarding assignment of message identifiers, 2956 -- at the definition of EMSDMessageId. 2957 message-id EMSDMessageId 2958 }; 2960 DeliveryVerifyResult ::= SEQUENCE 2961 { 2962 status DeliveryStatus 2963 }; 2965 DeliveryStatus ::= ENUMERATED 2966 { 2967 no-report-is-sent-out (1), 2968 delivery-report-is-sent-out (2), 2969 non-delivery-report-is-sent-out (3) 2970 }; 2972 ----------------------- 2973 -- DELIVER Operation -- 2974 ----------------------- 2976 deliver ES-OPERATION 2977 ARGUMENT DeliverArgument 2978 RESULT NULL 2979 ERRORS 2980 { 2981 deliveryControlViolated, 2982 securityError, 2983 resourceError, 2984 protocolViolation, 2985 messageError 2986 } ::= 35; 2988 DeliverArgument ::= SEQUENCE 2989 { 2990 -- Identifier of this message. This is the same identifier that 2991 -- was provided to the originator in the Submission Result. 2992 -- See comment regarding assignment of message identifiers, 2993 -- at the definition of EMSDMessageId. 2994 message-id EMSDMessageId, 2996 -- Time the message was delivered to the recipient by EMSD-SA 2997 message-delivery-time DateTime, 2999 -- Time EMSD-SA originally took responsibility for processing 3000 -- of this message. This field shall be omitted if the message-id 3001 -- contains an EMSDLocalMessageId, because that field contains 3002 -- the submission time within it. 3003 message-submission-time [0] IMPLICIT DateTime OPTIONAL, 3005 -- Security features 3006 security [1] IMPLICIT SecurityElement OPTIONAL, 3008 -- SegContentTypementation features for efficient transport 3009 segment-info SegmentInfo OPTIONAL, 3011 -- The type of the content 3012 content-type ContentType, 3014 -- 3015 -- THE CONTENT -- 3016 -- 3018 -- The submitted (and now being delivered) content 3019 content ANY DEFINED BY content-type 3021 }; 3023 -- Submission Control Operation 3025 submissionControl ES-OPERATION 3026 ARGUMENT SubmissionControlArgument 3027 RESULT SubmissionControlResult 3028 ERRORS 3029 { 3030 securityError, 3031 resourceError, 3032 protocolViolation 3033 } ::= 4; 3035 SubmissionControlArgument ::= SEQUENCE 3036 { 3037 -- Request an addition of or removal of a set of restrictions 3038 restrict [0] IMPLICIT Restrict DEFAULT update, 3040 -- Which operations are to be placed in the restriction set 3041 permissible-operations [1] IMPLICIT Operations OPTIONAL, 3043 -- What maximum content length should be allowed 3044 permissible-max-content-length 3045 [2] IMPLICIT INTEGER 3046 (0..ub-content-length) OPTIONAL, 3048 -- Security features 3049 security [3] IMPLICIT SecurityElement 3050 OPTIONAL 3051 }; 3053 SubmissionControlResult ::= SEQUENCE 3054 { 3055 -- Operation types queued at the EMSD-SA due to existing 3056 -- restrictions. 3057 waiting-operations [0] IMPLICIT Operations DEFAULT { } 3059 }; 3061 ---------------------------------- 3062 -- Submission Verify Operation -- 3063 ---------------------------------- 3065 submissionVerify ES-OPERATION 3067 ARGUMENT SubmissionVerifyArgument 3068 RESULT SubmissionVerifyResult 3069 ERRORS 3070 { 3071 submissionVerifyError, 3072 resourceError, 3073 protocolViolation 3074 } ::= 6; 3076 SubmissionVerifyArgument ::= SEQUENCE 3077 -- Identifier of this message. This is the same identifier that 3078 -- was provided to the originator in the Submission Result. 3079 -- See comment regarding assignment of message identifiers, 3080 -- at the definition of EMSDMessageId. 3081 { 3082 message-id EMSDMessageId 3083 }; 3085 SubmissionVerifyResult ::= SEQUENCE 3086 { 3087 status SubmissionStatus 3088 }; 3090 SubmissionStatus::= ENUMERATED 3091 { 3092 send-message (1), 3093 drop-message (2) 3094 }; 3096 -- GetConfiguration Operation 3097 -- To be fully defined later. This will possibly include, 3098 -- but not be limited to: 3099 -- get-local-time-zone 3100 -- get-protocol-version 3101 -- etc. 3103 getConfiguration ES-OPERATION 3105 ARGUMENT NULL 3106 RESULT NULL 3107 ERRORS 3108 { 3109 resourceError, 3110 protocolViolation 3111 } ::= 7; 3113 -- SetConfiguration Operation 3114 -- To be fully defined later. 3116 setConfiguration ES-OPERATION 3118 ARGUMENT NULL 3119 RESULT NULL 3120 ERRORS 3121 { 3122 resourceError, 3123 protocolViolation 3124 } ::= 8; 3126 -- Security -- 3128 SecurityElement ::= SEQUENCE 3130 { 3131 credentials Credentials, 3132 contentIntegrityCheck ContentIntegrityCheck OPTIONAL 3133 }; 3135 Credentials ::= CHOICE 3136 { 3137 simple [0] IMPLICIT SimpleCredentials 3138 -- Strong Credentials are for future study 3139 -- strong [1] IMPLICIT StrongCredentials 3140 -- externalProcedure [2] EXTERNAL 3141 }; 3143 SimpleCredentials ::= SEQUENCE 3145 { 3146 eMSDAddress EMSDAddress OPTIONAL, 3147 password [0] IMPLICIT OCTET STRING 3148 (SIZE (0..ub-password-length)) OPTIONAL 3149 }; 3151 -- StrongCredentials ::= NULL 3152 -- for now. 3154 -- ContentIntegrityCheck is a 16-bit checksum of content 3155 ContentIntegrityCheck ::= INTEGER (0..65535); 3157 SegmentInfo ::= CHOICE 3159 { 3160 first [APPLICATION 2] IMPLICIT FirstSegment, 3161 other [APPLICATION 3] IMPLICIT OtherSegment 3162 }; 3164 FirstSegment ::= SEQUENCE 3166 { 3167 sequence-id INTEGER, 3168 number-of-segments INTEGER 3169 -- number-of-segments must not exceed ub-total-number-of-segments 3171 }; 3173 OtherSegment ::= SEQUENCE 3174 { 3175 sequence-id INTEGER, 3176 segment-number INTEGER 3177 }; 3179 ----------- 3180 -- Errors -- 3181 ------------ 3183 protocolVersionNotRecognized ERROR PARAMETER NULL ::= 1; 3185 submissionControlViolated ERROR PARAMETER NULL ::= 2; 3187 messageIdentifierInvalid ERROR PARAMETER NULL ::= 3; 3189 securityError ERROR PARAMETER security-problem SecurityProblem ::= 4; 3191 deliveryControlViolated ERROR PARAMETER NULL ::= 5; 3193 resourceError ERROR PARAMETER NULL ::= 6; 3195 protocolViolation ERROR PARAMETER NULL ::= 7; 3197 messageError ERROR PARAMETER NULL ::= 8; 3199 SecurityProblem ::= INTEGER (0..127); 3201 -- 3202 -- EXPORTED Definitions (for use by associated specifications) -- 3203 -- 3205 ContentType ::= INTEGER 3206 { 3207 -- Content type 0 is reserved and shall never be transmitted. 3208 reserved (0), 3209 -- Content types between 1 and 31 (inclusive) are for 3210 -- internal-use only 3211 probe (1), -- reserved 3212 delivery-report (2), -- reserved 3214 -- Content types between 32 and 63 (inclusive) are for 3215 -- message types defined within this specifications. 3216 emsd-interpersonal-messaging-1995 (32), 3217 voice-messaging (33) -- reserved 3219 -- Content types beyond and including 64 are for 3220 -- bilaterally-agreed use between peers. 3221 } (0..127); 3222 -- If this message was originated as an RFC-822 message, then this 3223 -- EMSDMessageId shall be the "Message-Id:" field from that message. 3224 -- If this message was originated within the EMSD domain, 3225 -- then this identifier shall be unique for the Message Center 3226 -- generating this id. 3228 EMSDMessageId ::= CHOICE 3229 { 3230 emsdLocalMessageId [APPLICATION 4] IMPLICIT 3231 EMSDLocalMessageId, 3232 rfc822MessageId [APPLICATION 5] IMPLICIT 3233 AsciiPrintableString 3234 (SIZE (0..ub-message-id-length)) 3236 }; 3238 EMSDLocalMessageId ::= SEQUENCE 3239 { 3240 submissionTime DateTime, 3241 messageNumber INTEGER (0..ub-local-message-nu) 3242 }; 3244 -- An Originator/Recipient Address in EMSD Environment 3246 EMSDORAddress ::= CHOICE 3247 { 3248 -- This is the local-format address 3249 emsd-local-address-format EMSDAddress, 3251 -- This is a globally-unique RFC-822 Address 3252 rfc822DomainAddress AsciiPrintableString 3253 }; 3255 EMSDAddress ::= SEQUENCE 3256 { 3257 emsd-address OCTET STRING 3258 (SIZE (1..ub-emsd-address-length)), 3260 -- emsd-address is a decimal integer in BCD (Binary Encoded Decimal) 3261 -- format. 3262 -- If it had an odd number of digits, it is padded with 0 on 3263 -- the left. 3265 emsd-name [0] IMPLICIT OCTET STRING 3266 (SIZE (0..ub-emsd-name-length)) 3267 OPTIONAL 3268 }; 3269 DateTime ::= INTEGER; 3271 Iso8859String ::= GeneralString; 3273 AsciiPrintableString ::= [ APPLICATION 0 ] 3274 IMPLICIT Iso8859String (FROM 3276 (" "|"!"|"#"|"$"|"%"|"&"|"'"|"("|")"|"*"|"+"|","|"-"|"."|"/"| 3277 "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"|":"|";"|"<"|"="|">"| 3278 "?"|"@"|"A"|"B"|"C"|"D"|"E"|"F"|"G"|"H"|"I"|"J"|"K"|"L"|"M"| 3279 "N"|"O"|"P"|"Q"|"R"|"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"|"["|"]"| 3280 "^"|"_"|"`"|"a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|"l"| 3281 "m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|"w"|"x"|"y"|"z"|"{"| 3282 "|"|"}"|"~"|"\"|"""")); 3284 ProtocolVersionNumber ::= [APPLICATION 1] SEQUENCE 3285 { 3286 version-major INTEGER, 3287 version-minor [0] IMPLICIT INTEGER DEFAULT 0 3288 } 3289 END -- end of EMSD-SubmissionAndDeliveryProtocol 3291 B EMSD-IPM ASN.1 MODULE 3293 This section compiles in one place the complete ASN.1 Module for 3294 EMSD-IPM. 3296 EMSD-InterpersonalMessaging1995 DEFINITIONS ::= 3298 BEGIN 3300 IMPORTS EMSDORAddress, EMSDMessageId, AsciiPrintableString 3301 FROM EMSD-SubmissionAndDeliveryProtocol; 3303 ub-recipients INTEGER ::= 256; 3304 ub-reply-to INTEGER ::= 256; 3305 ub-subject-field INTEGER ::= 128; 3306 ub-header-extensions INTEGER ::= 64; 3307 ub-emsd-name-length INTEGER ::= 64; 3308 ub-mime-version-length INTEGER ::= 8; 3309 ub-mime-content-type-length INTEGER ::= 127; 3310 ub-mime-content-id-length INTEGER ::= 127; 3311 ub-mime-content-description-length INTEGER ::= 127; 3312 ub-mime-content-transfer-encoding INTEGER ::= 127; 3314 IPM ::= SEQUENCE 3315 { 3316 heading Heading, 3317 body Body OPTIONAL 3318 }; 3320 Heading ::= SEQUENCE 3321 { 3322 -- Address of the sending agent (person, program, machine) of 3323 -- this message. This field is mandatory if the sender 3324 -- is different than the originator. 3325 sender [0] EMSDORAddress OPTIONAL, 3327 -- Address of the originator of the message 3328 -- (not necessarily the sender) 3329 originator EMSDORAddress, 3331 -- List of recipients and flags associated with each. 3332 recipient-data SEQUENCE SIZE (1..ub-recipients) 3333 OF PerRecipientFields, 3335 -- Flags applying to this entire message 3336 per-message-flags [1] IMPLICIT BIT STRING 3338 { 3339 -- Priority values 3340 -- At most one of "non-urgent" and "urgent" may be specified 3341 -- concurrently. If neither is specified, then a Priority 3342 -- level of "normal" is assumed. 3343 priority-non-urgent (0), 3344 priority-urgent (1), 3346 -- Importance values 3347 -- At most one of "low" and "high" may be specified 3348 -- concurrently. If neither is specified, then an 3349 -- Importance level of "normal" is assumed. 3350 importance-low (2), 3351 importance-high (3), 3353 -- Indication of whether this message has been automatically 3354 -- forwarded 3355 auto-forwarded (4) 3356 } OPTIONAL, 3358 -- User-specified recipient who is to receive replies to this 3359 -- message. 3360 reply-to [2] IMPLICIT SEQUENCE SIZE 3361 (1..ub-reply-to) 3362 OF EMSDORAddress OPTIONAL, 3364 -- Identifier of a previous message, for which this message 3365 -- is a reply 3366 replied-to-IPM EMSDMessageId OPTIONAL, 3368 -- Subject of the message. 3369 subject [3] IMPLICIT AsciiPrintableString 3370 (SIZE (0..ub-subject-field)) 3371 OPTIONAL, 3373 -- RFC-822 header fields not explicitly provided for in 3374 -- this Heading. For messages incoming from the external 3375 -- world (i.e. in RFC-822 format), the Message-Id: field 3376 -- need not go here, as it is placed in the 3377 -- Envelope's EMSDMessageId (message-id) field. 3378 extensions [4] IMPLICIT SEQUENCE 3379 (SIZE (0..ub-header-extensions)) 3380 OF IPMSExtension OPTIONAL, 3382 -- MIME Version (if other than 1.0) 3383 mime-version [5] IMPLICIT AsciiPrintableString 3384 (SIZE 3385 (0..ub-mime-version-length)) 3386 OPTIONAL, 3388 -- Top-level MIME Content Type 3389 mime-content-type [6] IMPLICIT AsciiPrintableString 3390 (SIZE (0.. 3391 ub-mime-content-type-length)) 3392 OPTIONAL, 3394 -- MIME Content Id 3395 mime-content-id [7] IMPLICIT AsciiPrintableString 3396 (SIZE (0.. 3397 ub-mime-content-id-length)) 3398 OPTIONAL, 3400 -- MIME Content Description 3401 mime-content-description [8] IMPLICIT AsciiPrintableString 3402 (SIZE (0.. 3403 ub-mime-content-description-length)) 3404 OPTIONAL, 3406 -- Top-level MIME Content Type 3407 mime-content-transfer-encoding 3408 [9] IMPLICIT AsciiPrintableString 3409 (SIZE (0..ub-mime-content-transfer-encoding)) 3410 OPTIONAL 3411 }; 3413 PerRecipientFields ::= SEQUENCE 3414 { 3415 recipient-address EMSDORAddress, 3416 per-recipient-flags BIT STRING 3417 { 3418 -- Recipient Types. 3419 -- At most one of "copy" and "blind-copy" may be 3420 -- specified concurrently for a single recipient. If 3421 -- neither is specified, than the recipient 3422 -- is assumed to be a "primary" recipient. 3423 recipient-type-copy (0), 3424 recipient-type-blind-copy (1), 3426 -- Notification Request Types. 3427 -- Only one of "rn" and "nrn" may be specified 3428 -- concurrently, \\x110011 for a single recipient. 3429 -- "rn" implies "nrn" in addition. 3430 notification-request-rn (2), 3431 notification-request-nrn (3), 3432 notification-request-ipm-return (4), 3434 -- Report Request Types 3435 -- At most one of these should be set for a 3436 -- particular recipient. "delivery" implies "non-delivery" 3437 -- in addition. 3438 report-request-non-delivery (5), 3439 report-request-delivery (6), 3441 -- Originator-to-Recipient request for a reply. 3442 reply-requested (7) 3443 } DEFAULT { report-request-non-delivery } 3445 }; 3447 IPMSExtension ::= SEQUENCE 3448 { 3449 x-header-label AsciiPrintableString, 3450 x-header-value AsciiPrintableString 3451 }; 3453 Body ::= SEQUENCE 3454 { 3455 compression-method [0] IMPLICIT CompressionMethod 3456 OPTIONAL, 3457 -- If compression method is not specified, 3458 -- "no-compression" is implied. 3460 message-body OCTET STRING 3461 -- See MIME for structure of the Body. 3462 -- If a compression method is specified, the entire text containing 3463 -- the Content-Type: element followed by the RFC-822 body are 3464 -- compressed using the specified method, and placed herein. 3465 }; 3466 CompressionMethod ::= INTEGER 3467 { 3468 -- Compression Methods numbered 0 to 63 are reserved for 3469 -- assignment within this and associated specifications. 3470 no-compression (0), 3471 lempel-ziv (1) 3473 -- Compression Methods numbered between 64 and 127 may be 3474 -- used on a bilaterally-agreed basis between peers. 3475 } (0..127) 3477 END -- end of EMSD-InterpersonalMessaging1995 3479 C RATIONALE FOR KEY DESIGN DECISIONS 3481 This section summarizes the rationale behind key design decisions that 3482 were made while developing the EMSD Protocols. 3484 C.1 Deviation From The SMTP Model 3486 SMTP is the main mail transport mechanism throughout the Internet. 3487 SMTP is widely deployed and well understood by many engineers who 3488 specialize in Internet email. Because of these reasons, works based 3489 on SMTP or derived from it have a higher likelyhood of being widely 3490 deployed throughout the Internet. 3492 However, SMTP is highly inefficient for transfer of short messages. 3493 SMTP's inefficiency applies to both the number of transmissions and 3494 also to the number of bytes transmitted. 3496 Even when fully optimized with PIPELINING, SMTP is still quite 3497 inefficient. 3499 Submission of a short message with SMTP involves 15 transmissions. 3500 Submission of a short message with SMTP and PIPELINING involves 9 3501 transmissions. Submission of a short message with EMSD (EMSD-P and 3502 ESRO) involves 3 transmissions (in typical cases). 3504 The key requirement driving the design of EMSD is efficiency. It was 3505 determined that the at least 3 fold gains in efficiency justifies the 3506 deviation from the SMTP model. 3508 C.1.1 Comparison of SMTP and EMSD Efficiency 3510 The table below illustrates the number of N-PDUs exchanged for 3511 transfer of a short Internet email when using SMTP, SMTP and 3512 PIPELINING, QMTP and EMSD. The names used for identifying the PDUs are 3513 informal names. 3515 SMTP SMTP + pipelining QMTP, QMQP, EMSD 3516 ------- ----------------- ------------ ----------- 3517 client: SYN SYN SYN Submit.Req 3518 server: SYN ok SYN ok SYN Submit.Resp 3519 client: HELO EHLO message ack 3520 server: ok PIPELINING accept close 3521 client: MAIL MAIL RCPT DATA close 3522 server: ok ok 3523 client: RCPT message QUIT 3524 server: ok accept ok close 3525 client: DATA close 3526 server: ok 3527 client: message 3528 server: accept 3529 client: QUIT 3530 server: ok close 3531 client: close 3533 C.2 Use of ESRO Instead of TCP 3535 In order to provide the same level of reliability that the existing 3536 email protocols provide for short messages, it is clear that a 3537 reliable underlying service is needed. UDP [6], by itself, is clearly 3538 not adequate. 3540 Use of TCP however, involves three phases: 3542 1. Connection Establishment 3544 2. Data Transfer 3546 3. Disconnect 3548 Reliable transfer of a short message using TCP at a minimum involves 5 3549 transmissions as it is the case with QMTP. 3551 The key requirement driving the design of EMSD is Efficiency. It was 3552 determined that elimination of the extra 2 transmissions that are an 3553 inherent characteristic of TCP, justifies deviation from it. 3555 ESRO protocol, as specified in (RFC-2188 [1]), provides reliable 3556 connectionless remote operation services on top of UDP [6] with 3557 minimum overhead. ESRO protocol supports segmentation and reassembly, 3558 concatenation and separation. 3560 Reliable transfer of a short message using ESRO involves 3 3561 transmissions as it is the case with EMSD-P. 3563 C.3 Use Of Remote Procedure Call (RPC) Model 3565 Many Internet protocols are "text-based". Few Internet protocols are 3566 RPC based. Protocols designed around the "text-based" approach have a 3567 better track record of acceptance throughout the Internet. 3569 Considering that message submission and delivery in EMSD involve no 3570 more than two data exchanges, the text-based model becomes the same as 3571 an operation. Furthermore, the RPC model is the natural way of using 3572 ESRO. 3574 C.4 Use Of ASN.1 3576 In order to minimize the number of bytes transferred, efficient 3577 encoding mechanisms are needed. 3579 Amongst today's encoding mechanisms, ASN.1 has the unique feature of 3580 separating the abstract syntax from the encoding rules. By selecting 3581 ASN.1 as the notation used for expressing EMSD's information objects, 3582 EMSD has the flexibility of using the most efficient encoding rules 3583 such as Packed Encoding Rules (PER) when they are available. 3585 Efficient encoding can always be better performed when the syntax of 3586 the information is known. In general, encoding and compression 3587 techniques which use the knowledge of the syntax of the information 3588 produce better results than those compression techniques that work on 3589 arbitrary text. 3591 D FURTHER DEVELOPMENT 3593 Beyond this documentation of existing implementations, further 3594 development of EMSD protocol is anticipated. 3596 The following deficiencies and areas of improvement are identified. 3598 o Mapping of RFC-822 to EMSD-FS needs to be more explicit. 3600 o Mapping of EMSD-FS to RFC-822 needs to be more explicit. 3602 o Text of duplicate detection section needs more structure. 3604 o SubmissionControl operation needs more informative description. 3606 o Based on implementor's feedback the "EMSD PROCEDURE FOR 3607 OPERATIONS" section needs to be adjusted or re-done. 3609 o The EMSD protocol can be extended to also support transfer of raw 3610 RFC-822 text-based messages in addition to EMSD-FS. This would be 3611 a trade-off in favor of "ease of implementation" against 3612 "efficiency of bytes transfered". 3614 o Provide mechanisms to support fully automated initial provisioning 3615 of mail-boxes. 3617 Future development of the EMSD Protocol is anticipated to take place 3618 at http://www.emsd.org/. Those interested in further development and 3619 maintenance of this protocol are invited to join the various mailing 3620 lists hosted at http://www.emsd.org/. 3622 References 3624 [1] M. Banan, J. Cheng, and M. Taylor. At&t/neda's efficient short 3625 remote operations (ESRO) protocol specification version 1.2. 3626 Request for Comments (Informational) 2188, Neda Communications, 3627 Inc., September 1997. 3628 [2] S. Bradner. Key words for use in RFCs to indicate requirement 3629 levels. BC 2119, Internet Engineering Task Force, March 1997. 3631 [3] D. Crocker. Standard for the format of ARPA internet text 3632 messages. Request for Comments (Standard) STD 11, 822, Internet 3633 Engineering Task Force, August 1982. (Obsoletes RFC733); (Updated 3634 by RFC987); (Updated by RFC1327). 3636 [4] Information Processing --- Open Systems 3637 Interconnection --- Specification of Packed Encoding Rules for 3638 Abstract Syntax Notation One (ASN.1). International Organization 3639 for Standardization and International Electrotechnical Committee. 3640 International Standard 8825-2. 3641 [5] Information Processing --- Open Systems 3642 Interconnection --- Specification of Basic Encoding Rules for 3643 Abstract Syntax Notation One (ASN.1). International Organization 3644 for Standardization and International Electrotechnical Committee, 3645 1987. International Standard 8825. 3647 [6] Jon B. Postel. User Datagram Protocol. Request for Comments 768, 3648 DDN Network Information Center, SRI International, August 1980. 3650 INTERNET DRAFT EXPIRES JULY 1999 INTERNET DRAFT