idnits 2.17.1 draft-ietf-mhsds-routdirectory-05.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 6 months document validity. ** 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. ** Bad filename characters: the document name given in the document, 'draft-ietf-mhsds-routdirectory-05.txt,ps', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-mhsds-routdirectory-05.txt,ps', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-mhsds-routdirectory-05.txt,ps', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-mhsds-routdirectory-05.txt,ps', but the file name used is 'draft-ietf-mhsds-routdirectory-05' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 are 18 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([20,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. RFC 2119 keyword, line 923: '... MAY CONTAIN {...' RFC 2119 keyword, line 954: '... dda-key String OPTIONAL,...' RFC 2119 keyword, line 955: '... regex-match IA5String OPTIONAL,...' RFC 2119 keyword, line 981: '... mta-attributes [2] SET OF Attribute OPTIONAL,...' RFC 2119 keyword, line 985: '...es SET OF Attribute OPTIONAL} OPTIONAL...' (33 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2981 has weird spacing: '...present in a...' == Line 2982 has weird spacing: '...ression match...' == Line 2985 has weird spacing: '...ons can be b...' == Line 2988 has weird spacing: '...w. An ordin...' == Line 2991 has weird spacing: '...special chara...' == (35 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (June 1994) is 10909 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 3281, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Experimental RFC: RFC 1465 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 822 (ref. '12') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Duplicate reference: RFC822, mentioned in '16', was also mentioned in '12'. ** Obsolete normative reference: RFC 822 (ref. '16') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' Summary: 16 errors (**), 1 flaw (~~), 10 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working S.E. Kille 3 Group ISODE Consortium 4 INTERNET-DRAFT June 1994 5 Expires: December 1994 6 File: 7 draft-ietf-mhsds-routdirectory-05.txt,ps 9 MHS use of Directory to support MHS Routing 11 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six months. 18 Internet Drafts may be updated, replaced, or obsoleted by other 19 documents at any time. It is not appropriate to use Internet Drafts 20 as reference material or to cite them other than as a ``working 21 draft'' or ``work in progress.'' 22 Please check the I-D abstract listing contained in each Internet Draft 23 directory to learn the current status of this or any other Internet 24 Draft. 25 Abstract 27 This document specifies an approach for X.400 Message Handling Systems 28 to perform application level routing using the OSI Directory [20, 1]. 29 Use of the directory in this manner is fundamental to enabling large 30 scale deployment of X.400. 31 This draft document will be submitted to the RFC editor as a protocol 32 standard. Distribution of this memo is unlimited. Please send 33 comments to the author or to the discussion group 34 . 36 INTERNET--DRAFT MHS Routing using Directory June 1994 38 Contents 40 1 Introduction 6 42 2 Goals 6 44 3 Approach 9 46 4 Direct vs Indirect Connection 9 48 5 X.400 and RFC 822 12 50 6 Objects 12 52 7 Communities 14 54 8 Routing Trees 15 55 8.1 Routing Tree Definition . . . . . . . 16 56 8.2 The Open Community Routing Tree . . . . . 16 58 8.3 Routing Tree Location . . . . . . . 17 59 8.4 Example Routing Trees . . . . . . . 17 61 8.5 Use of Routing Trees to look up Information . . 18 63 9 Routing Tree Selection 19 64 9.1 Routing Tree Order . . . . . . . . 19 66 9.2 Example use of Routing Trees . . . . . . 20 67 9.2.1 Fully Open Organisation . . . . . 20 68 9.2.2 Open Organisation with Fallback . . . 20 70 9.2.3 Minimal-routing MTA . . . . . . 20 71 9.2.4 Organisation with Firewall . . . . . 21 72 9.2.5 Well Known Entry Points . . . . . 21 74 9.2.6 ADMD using the Open Community for Advertising 21 75 9.2.7 ADMD/PRMD gateway . . . . . . . 22 77 10 Routing Information 22 78 INTERNET--DRAFT MHS Routing using Directory June 1994 80 10.1 Multiple routing trees . . . . . . . 26 81 10.2 MTA Choice . . . . . . . . . . 27 82 10.3 Routing Filters . . . . . . . . . 30 84 10.4 Indirect Connectivity . . . . . . . 32 86 11 Local Addresses (UAs) 33 87 11.1 Searching for Local Users . . . . . . 34 89 12 Direct Lookup 35 91 13 Alternate Routes 35 93 13.1 Finding Alternate Routes . . . . . . . 35 94 13.2 Sharing routing information . . . . . . 35 96 14 Looking up Information in the Directory 36 98 15 Naming MTAs 37 99 15.1 Naming 1984 MTAs . . . . . . . . . 39 101 16 Attributes Associated with the MTA 39 103 17 Bilateral Agreements 41 105 18 MTA Selection 42 107 18.1 Dealing with protocol mismatches . . . . . 42 108 18.2 Supported Protocols . . . . . . . . 43 109 18.3 MTA Capability Restrictions . . . . . . 43 111 18.4 Subtree Capability Restrictions . . . . . 43 113 19 MTA Pulling Messages 44 115 20 Security and Policy 44 117 20.1 Finding the Name of the Calling MTA . . . . 44 118 20.2 Authentication . . . . . . . . . 45 120 20.3 Authentication Information . . . . . . 46 122 INTERNET--DRAFT MHS Routing using Directory June 1994 124 21 Policy and Authorisation 47 125 21.1 Simple MTA Policy . . . . . . . . 47 126 21.2 Complex MTA Policy . . . . . . . . 48 128 22 Delivery 49 129 22.1 Redirects . . . . . . . . . . 49 130 22.2 Underspecified O/R Addresses . . . . . . 50 132 22.3 Non Delivery . . . . . . . . . . 50 133 22.4 Bad Addresses . . . . . . . . . 50 135 23 Submission 51 136 23.1 Normal Derivation . . . . . . . . 51 137 23.2 Roles and Groups . . . . . . . . . 52 139 24 Access Units 52 141 25 The Overall Routing Algorithm 53 143 26 Performance 54 145 27 Acknowledgements 54 147 28 Security Considerations 56 149 29 Author's Address 56 151 A Object Identifier Assignment 58 153 B Community Identifier Assignments 60 155 C Protocol Identifier Assignments 61 157 D ASN.1 Summary 62 159 E Regular Expression Syntax 73 160 INTERNET--DRAFT MHS Routing using Directory June 1994 162 E.1 Pseudo Code . . . . . . . . . . 75 164 INTERNET--DRAFT MHS Routing using Directory June 1994 166 List of Figures 168 1 Location of Routing Trees . . . . . . 17 169 2 Routing Tree Use Definition . . . . . . 19 171 3 Routing Information at a Node . . . . . 24 172 4 Indirect Access . . . . . . . . . 32 173 6 MTA Definitions . . . . . . . . . 38 175 19 Object Identifier Assignment . . . . . . 59 176 22 ASN.1 Summary . . . . . . . . . 72 178 5 UA Attributes . . . . . . . . . 76 179 7 MTA Bilateral Table Entry . . . . . . 76 180 8 Bilateral Table Attribute . . . . . . 77 182 9 Supported MTS Extensions . . . . . . . 77 183 10 Subtree Capability Restriction . . . . . 77 184 11 Pulling Messages . . . . . . . . . 78 186 12 Authentication Requirements . . . . . . 79 187 13 MTA Authentication Parameters . . . . . 80 188 14 Simple MTA Policy Specification . . . . . 81 190 15 Redirect Definition . . . . . . . . 81 191 16 Non Delivery Information . . . . . . . 82 192 17 Bad Address Pointers . . . . . . . . 82 194 18 Access Unit Attributes . . . . . . . 83 195 20 Transport Community Object Identifier Assignments 83 197 21 Protocol Object Identifier Assignments . . . 84 199 List of Tables 201 1 Possible target end to end delays . . . . 7 203 INTERNET--DRAFT MHS Routing using Directory June 1994 205 1 Introduction 207 MHS Routing is the problem of controlling the path of a message as it 208 traverses one or more MTAs to reach its destination recipients. 209 Routing starts with a recipient O/R Address, and parameters associated 210 with the message to be routed. It is assumed that this is known a 211 priori, or is derived at submission time as described in Section 23. 213 The key problem in routing is to map from an O/R Address onto an MTA 214 (next hop). This shall be an MTA which in some sense is ``nearer'' to 215 the destination UA. This is done repeatedly until the message can be 216 directly delivered to the recipient UA. There are a number of things 217 which need to be considered to determine this. These are discussed in 218 the subsequent sections. A description of the overall routing process 219 is given in Section 25. 221 2 Goals 223 Application level routing for MHS is a complex procedure, with many 224 requirements. The following goals for the solution are set: 226 o Straightforward to manage. Non-trivial configuration of routing 227 for current message handling systems is a black art, often 228 involving gathering and processing many tables, and editing 229 complex configuration files. Many problems are solved in a very 230 ad hoc manner. Managing routing for MHS is the most serious 231 headache for most mail system managers. 233 o Economic, both in terms of network and computational resources. 235 o Robust. Errors and out of date information shall cause minimal 236 and localised damage. 238 o Deal with link failures. There needs to be some ability to choose 239 alternative routes. In general, it is desirable that the routing 240 approach be redundant. 242 o Load sharing. Information on routes shall allow ``equal'' routes 243 to be specified, and thus facilitate load sharing. 245 o Support format and protocol conversion 247 INTERNET--DRAFT MHS Routing using Directory June 1994 249 _____________________________________________________________ 250 |______________|High_Priority_|Normal_Priority_|Low_Priority_|_ 251 |50%_max_delay_|0.5_hour______|1_hour__________|12_hours_____| 252 |98%_max_delay_|3_hours_______|12_hours________|24_hours_____| 253 |max_delay_____|6_hours_______|72_hours________|96_hours_____| 255 Table 1: Possible target end to end delays 257 o Dynamic and automatic. There shall be no need for manual 258 propagation of tables or administrator intervention. 260 o Policy robust. It shall not allow specification of policies which 261 cause undesirable routing effects. 263 o Reasonably straightforward to implement. 265 o Deal with X.400, RFC 822, and their interaction. 267 o Extensible to other mail architectures 269 o Recognise existing RFC 822 routing, and coexist smoothly. 271 o Improve RFC 822 routing capabilities. This is particularly 272 important for RFC 822 sites not in the SMTP Internet. 274 o Deal correctly with different X.400 protocols (P1, P3, P7), and 275 with 1984, 1988 and 1992 versions. 277 o Support X.400 operation over multiple protocol stacks (TCP/IP, 278 CONS, CLNS) and in different communities. 280 o Messages shall be routed consistently. Alternate routing 281 strategies, which might introduce unexpected delay, shall be used 282 with care (e.g. routing through a protocol converter due to 283 unavailability of an MTA). 285 o Delay between message submission and delivery shall be minimised. 286 Table 1 indicates the sort of target which might be aimed for. 287 The figures are illustrative of the sort of target which might be 288 set. They are better than achieved in most current Research 289 Networks. The long tail-offs on Normal and Low priority recognise 290 the fact that some end systems will not get 24 hour operator 291 coverage (whereas any MTAs providing ADMD service will usually be 292 required to so this). In the case of a high and normal priority 294 INTERNET--DRAFT MHS Routing using Directory June 1994 296 messages, it is a target that a non-delivery notification be 297 returned within the suggested time. 299 o Interact sensibly with ADMD services. 301 o Be global in scope 303 o Routing strategy shall deal with a scale of order of magnitude 304 1,000,000 -- 100,000,000 MTAs. 306 o Routing strategy shall deal with of order 1,000,000 -- 100,000,000 307 Organisations. 309 o Information about alterations in topology shall propagate rapidly 310 to sites affected by the change. 312 o Removal, examination, or destruction of messages by third parties 313 shall be difficult. This is hard to quantify, but ``difficult'' 314 shall be comparable to the effort needed to break system security 315 on a typical MTA system. 317 o As with current Research Networks, it is recognised that 318 prevention of forged mail will not always be possible. However, 319 this shall be as hard as can be afforded. 321 o Sufficient tracing and logging shall be available to track down 322 security violations and faults. 324 o Optimisation of routing messages with multiple recipients, in 325 cases where this involves selection of preferred single recipient 326 routes. 328 The following are not initial goals: 330 o Advanced optimisation of routing messages with multiple 331 recipients, noting dependencies between the recipients to find 332 routes which would not have been chosen for any of the single 333 recipients. 335 o Dynamic load balancing. The approach does not give a means to 336 determine load. However, information on alternate routes is 337 provided, which is the static information needed for load 338 balancing. 340 INTERNET--DRAFT MHS Routing using Directory June 1994 342 3 Approach 344 A broad problem statement, and a survey of earlier approaches to the 345 problem is given in the COSINE Study on MHS Topology and Routing [8]. 346 The interim (table-based) approach suggested in this study, whilst not 347 being followed in detail, broadly reflects what the research X.400 348 (GO-MHS) community is doing. The evolving specification of the RARE 349 table format is defined in [5]. This document specifies the envisaged 350 longer term approach. 351 Some documents have made useful contributions to this work: 353 o A paper by the editor on MHS use of directory, which laid out the 354 broad approach of mapping the O/R Address space on to the DIT [7]. 356 o Initial ISO Standardisation work on MHS use of Directory for 357 routing [21]. Subsequent ISO work in this area has drawn from 358 earlier drafts of this specification. 360 o The work of the VERDI Project [3]. 362 o Work by Kevin Jordan of CDC [6]. 364 o The routing approach of ACSNet [4, 19] paper. This gives useful 365 ideas on incremental routing, and replicating routing data. 367 o A lot of work on network routing is becoming increasingly 368 relevant. As the MHS routing problem increases in size, and 369 network routing increases in sophistication (e.g., policy based 370 routing), the two areas have increasing amounts in common. For 371 example, see [2]. 373 4 Direct vs Indirect Connection 375 Two extreme approaches to routing connectivity are: 377 1. High connectivity between MTAs. An example of this is the way the 378 Domain Name Server system is used on the DARPA/NSF Internet. 379 Essentially, all MTAs are fully interconnected. 381 2. Low connectivity between MTAs. An example of this is the UUCP 382 network. 384 INTERNET--DRAFT MHS Routing using Directory June 1994 386 In general an intermediate approach is desirable. Too sparse a 387 connectivity is inefficient, and leads to undue delays. However, full 388 connectivity is not desirable, for the reasons discussed below. 389 A number of general issues related to relaying are now considered. 390 The reasons for avoiding relaying are clear. These include. 392 o Efficiency. If there is an open network, it is desirable that it 393 be used. 395 o Extra hops introduce delay, and increase the (very small) 396 possibility of message loss. As a basic principle, hop count 397 shall be minimised. 399 o Busy relays or Well Known Entry points can introduce high delay 400 and lead to single point of failure. 402 o If there is only one hop, it is straightforward for the user to 403 monitor progress of messages submitted. If a message is delayed, 404 the user can take appropriate action. 406 o Many users like the security of direct transmission. It is an 407 argument often given very strongly for use of SMTP. 409 Despite these very powerful arguments, there are a number of reasons 410 why some level of relaying is desirable: 412 o Charge optimisation. If there is an expensive network/link to be 413 traversed, it may make sense to restrict its usage to a small 414 number of MTAs. This would allow for optimisation with respect to 415 the charging policy of this link. 417 o Copy optimisation. If a message is being sent to two remote MTAs 418 which are close together, it is usually optimal to send the 419 message to one of the MTAs (for both recipients), and let it pass 420 a copy to the other MTA. 422 o To access an intermediate MTA for some value added service. In 423 particular for: 425 -- Message Format Conversion 427 -- Distribution List expansion 429 INTERNET--DRAFT MHS Routing using Directory June 1994 431 o Dealing with different protocols. The store and forward approach 432 allows for straightforward conversion. Relevant cases include: 434 -- Provision of X.400 over different OSI Stacks (e.g. 435 Connectionless Network Service). 437 -- Use of a different version of X.400. 439 -- Interaction with non-X.400 mail services 441 o To compensate for inadequate directory services: If tables are 442 maintained in an ad hoc manner, the manual effort to gain full 443 connectivity is too high. 445 o To hide complexity of structure. If an organisation has many 446 MTAs, it may still be advantageous to advertise a single entry 447 point to the outside world. It will be more efficient to have an 448 extra hop, than to (widely) distribute the information required to 449 connect directly. This will also encourage stability, as 450 organisations need to change internal structure much more 451 frequently than their external entry points. For many 452 organisations, establishing such firewalls is high priority. 454 o To handle authorisation, charging and security issues. In 455 general, it is desirable to deal with user oriented authorisation 456 at the application level. This is essential when MHS specific 457 parameters shall be taken into consideration. It may well be 458 beneficial for organisations to have a single MTA providing access 459 to the external world, which can apply a uniform access policy 460 (e.g. as to which people are allowed access). This would be 461 particularly true in a multi-vendor environment, where different 462 systems would otherwise have to enforce the same policy --- using 463 different vendor-specific mechanisms. 465 In summary there are strong reasons for an intermediate approach. 466 This will be achieved by providing mechanisms for both direct and 467 indirect connectivity. The manager of a configuration will then be 468 able to make appropriate choices for the environment. 469 Two models of managing large scale routing have evolved: 471 1. Use of a global directory/database. This is the approach proposed 472 here. 474 INTERNET--DRAFT MHS Routing using Directory June 1994 476 2. Use of a routing table in each MTA, which is managed either by a 477 management protocol or by directory. This is coupled with means 478 to exchange routing information between MTAs. This approach is 479 more analogous to how network level routing is commonly performed. 480 It has good characteristics in terms of managing links and dealing 481 with link related policy. However, it assumes limited 482 connectivity and does not adapt well to a network environment with 483 high connectivity available. 485 5 X.400 and RFC 822 487 This document defines mechanisms for X.400 routing. It is important 488 that this can be integrated with RFC 822 base routing, as many MTAs 489 will work in both communities. This routing document is written with 490 this problem in mind, and support for RFC 822 routing using the same 491 basic infrastructure is defined in a companion document [12]. In 492 addition support for X.400/RFC 822 gatewaying is needed, to support 493 interaction. Directory based mechanisms for this are defined in [16]. 494 The advantages of the approach defined by this set of specifications 495 are: 497 o Uniform management for sites which wish to support both protocols. 499 o Simpler management for gateways. 501 o Improved routing services for RFC 822 only sites. 503 For sites which are only X.400 or only RFC 822, the mechanisms 504 associated with gatewaying or with the other form of addressing are 505 not needed. 507 6 Objects 509 It is useful to start with a manager's perspective. Here is the set 510 of object classes used in this specification. It is important that 511 all information entered relates to something which is being managed. 512 If this is achieved, configuration decisions are much more likely to 513 be correct. In the examples, distinguished names are written using 514 the String Syntax for Distinguished Names [10]. The list of objects 515 used in this specification is: 517 INTERNET--DRAFT MHS Routing using Directory June 1994 519 User An entry representing a single human user. This will typically 520 be named in an organisational context. For example: 522 CN=Edgar Smythe, 523 O=Zydeco Services, C=GB 525 This entry would have associated information, such as telephone 526 number, postal address, and mailbox. 528 MTA A Message Transfer Agent. In general, the binding between 529 machines and MTAs will be complex. Often a small number of MTAs 530 will be used to support many machines, by use of local approaches 531 such as shared filestores. MTAs may support multiple protocols, 532 and will identify separate addressing information for each 533 protocol. 534 To achieve support for multiple protocols, an MTA is modelled as 535 an Application Process, which is named in the directory. Each MTA 536 will have one or more associated Application Entities. Each 537 Application Entity is named as a child of the Application Process, 538 using a common name which conveniently identifies the Application 539 Entity relative to the Application Process. Each Application 540 Entity supports a single protocol, although different Application 541 Entities may support the same protocol. Where an MTA only 542 supports one protocol or where the addressing information for all 543 of the protocols supported have different attributes to represent 544 addressing information (e.g., P1(88) and SMTP) the Application 545 Entity(ies) may be represented by the single Application Process 546 entry. 548 User Agent (Mailbox) This defines the User Agent (UA) to which mail 549 may be delivered. This will define the account with which the UA 550 is associated, and may also point to the user(s) associated with 551 the UA. It will identify which MTAs1 are able to access the UA. 553 Role Some organisational function. For example: 555 ---------------------------- 556 1. In the formal X.400 model, there will be a single MTA 557 delivering to a UA. In many practical configurations, multiple MTAs 558 can deliver to a single UA. This will increase robustness, and is 559 desirable. 561 INTERNET--DRAFT MHS Routing using Directory June 1994 563 CN=System Manager, OU=Sales, 564 O=Zydeco Services, C=GB 566 The associated entry would indicate the occupant of the role. 568 Distribution Lists There would be an entry representing the 569 distribution list, with information about the list, the manger, 570 and members of the list. 572 7 Communities 574 There are two basic types of agreement in which an MTA may participate 575 in order to facilitate routing: 577 Bilateral Agreements An agreement between a pair of MTAs to route 578 certain types of traffic. This MTA pair agreement usually 579 reflects some form of special agreement and in general bilateral 580 information shall be held for the link at both ends. In some 581 cases, this information shall be private. 583 Open Agreements An agreement between a collection of MTAs to behave 584 in a cooperative fashion to route traffic. This may be viewed as 585 a general bilateral agreement. 587 It is important to ensure that there are sufficient agreements in 588 place for all messages to be routed. This will usually be done by 589 having agreements which correspond to the addressing hierarchy. For 590 X.400, this is the model where a PRMD connects to an ADMD, and the 591 ADMD provides the inter PRMD connectivity, by the ability to route to 592 all other ADMDs. Other agreements may be added to this hierarchy, in 593 order to improve the efficiency of routing. In general, there may be 594 valid addresses, which cannot be routed to, either for connectivity or 595 policy reasons. 597 We model these two types of agreements as communities. A community is 598 a scope in which an MTA advertises its services and learns about other 599 services. Each MTA will: 601 1. Register its services in one or more communities. 603 INTERNET--DRAFT MHS Routing using Directory June 1994 605 2. Look up services in one or more communities. 607 In most cases an MTA will deal with a very small number of communities 608 --- very often one only. There are a number of different types of 609 community. 611 The open community This is a public/global scope. It reflects 612 routing information which is made available to any MTA which 613 wishes to use it. 615 The local community This is the scope of a single MTA. It reflects 616 routing information private to the MTA. It will contain an MTA's 617 view of the set of bilateral agreements in which it participates, 618 and routing information private and local to the MTA. 620 Hierarchical communities A hierarchical community is a subtree of the 621 O/R Address tree. For example, it might be a management domain, 622 an organisation, or an organisational unit. This sort of 623 community will allow for firewalls to be established. A community 624 can have complex internal structure, and register a small subset 625 of that in the open community. 627 Closed communities A closed community is a set of MTAs which agrees 628 to route amongst themselves. Examples of this might be ADMDs 629 within a country, or a set of PRMDs representing the same 630 organisation in multiple countries. 632 Formally, a community indicates the scope over which a service is 633 advertised. In practice, it will tend to reflect the scope of 634 services offered. It does not make sense to offer a public service, 635 and only advertise it locally. Public advertising of a private 636 service makes more sense, and this is shown below. In general, having 637 a community offer services corresponding to the scope in which they 638 are advertised will lead to routing efficiency. Examples of how 639 communities can be used to implement a range of routing policies are 640 given in Section 9.2. 642 8 Routing Trees 644 Communities are a useful abstract definition of the routing approach 645 taken by this specification. Each community is represented in the 646 INTERNET--DRAFT MHS Routing using Directory June 1994 648 directory as a routing tree. There will be many routing trees 649 instantiated in the directory. Typically, an MTA will only be 650 registered in and make use of a small number of routing trees. In 651 most cases, it will register in and use the same set of routing trees. 653 8.1 Routing Tree Definition 655 Each community has a model of the O/R address space. Within a 656 community, there is a general model of what to do with a given O/R 657 Address. This is structured hierarchically, according to the O/R 658 address hierarchy. A community can register different possible 659 actions, depending on the depth of match. This might include 660 identifying the MTA associated with a UA which is matched fully, and 661 providing a default route for an O/R address where there is no match 662 in the community --- and all intermediate forms. 663 The name structure of a routing tree follows the O/R address 664 hierarchy, which is specified in a separate document [14]. Where 665 there is any routing action associated with a node in a routing tree, 666 the node is of object class routingInformation, as defined in 667 Section 10. 669 8.2 The Open Community Routing Tree 671 The routing tree of the open community starts at the root of the DIT. 672 This routing tree also serves the special function of instantiating 673 the global O/R Address space in the Directory. Thus, if a UA wishes 674 to publish information to the world, this hierarchy allows it to do 675 so. 676 The O/R Address hierarchy is a registered tree, which may be 677 instantiated in the directory. Names at all points in the tree are 678 valid, and there is no requirement that the namespace is instantiated 679 by the owner of the name. For example, a PRMD may make an entry in 680 the DIT, even if the ADMD above it does not. In this case, there will 681 be a ``skeletal'' entry for the ADMD, which is used to hang the PRMD 682 entry in place. The skeletal entry contains the minimum number of 683 entries which are needed for it to exist in the DIT (Object Class and 684 Attribute information needed for the relative distinguished name). 685 This entry may be placed there solely to support the subordinate 686 entry, as its existence is inferred by the subordinate entry. Only 687 the owner of the entry may place information into it. An analogous 688 situation in current operational practice is to make DIT entries for 689 INTERNET--DRAFT MHS Routing using Directory June 1994 691 _______________________________________________________________________ 693 routingTreeRoot OBJECT-CLASS ::= { 694 SUBCLASS OF {routingInformation|subtree} 695 ID oc-routing-tree-root} 697 _________________Figure_1:__Location_of_Routing_Trees__________________ 699 Countries and US States. 701 8.3 Routing Tree Location 703 All routing trees follow the same O/R address hierarchy. Routing 704 trees other than the open community routing tree are rooted at 705 arbitrary parts of the DIT. These routing trees are instantiated using 706 the subtree mechanism defined in the companion document ``Representing 707 Tables and Subtrees in the Directory'' [14]. A routing tree is 708 identified by the point at which it is rooted. An MTA will use a list 709 of routing trees, as determined by the mechanism described in 710 Section 9. Routing trees may be located in either the organisational 711 or O/R address structured part of the DIT. All routing trees, other 712 than the open community routing tree, are rooted by an entry of object 713 class routingTreeRoot, as defined in Figure 1. 715 8.4 Example Routing Trees 717 Consider routing trees with entries for O/R Address: 719 P=ABC; A=XYZMail; C=GB; 721 In the open community routing tree, this would have a distinguished 722 name of: 724 PRMD=ABC, ADMD=XYZMail, C=GB 726 Consider a routing tree which is private to: 728 INTERNET--DRAFT MHS Routing using Directory June 1994 730 O=Zydeco Services, C=GB 732 They might choose to label a routing tree root ``Zydeco Routing 733 Tree'', which would lead to a routing tree root of: 735 CN=Zydeco Routing Tree, O=Zydeco Services, C=GB 737 The O/R address in question would be stored in this routing tree as: 739 PRMD=ABC, ADMD=XYZMail 740 C=GB, CN=Zydeco Routing Tree, 741 O=Zydeco Services, C=GB 743 8.5 Use of Routing Trees to look up Information 745 Lookup of an O/R address in a routing tree is done as follows: 747 1. Map the O/R address onto the O/R address hierarchy described in 748 [14] in order to generate a Distinguished Name. 750 2. Append this to the Distinguished Name of the routing tree, and 751 then look up the whole name. 753 3. Handling of errors will depend on the application of the lookup, 754 and is discussed later. 756 Note that it is valid to look up a null O/R Address, as the routing 757 tree root may contain default routing information for the routing 758 tree. This is held in the root entry of the routing tree, which is a 759 subclass of routingInformation. The open community routing tree does 760 not have a default. 761 Routing trees may have aliases into other routing trees. This will 762 typically be done to optimise lookups from the first routing tree 763 which a given MTA uses. Lookup needs to take account of this. 765 INTERNET--DRAFT MHS Routing using Directory June 1994 767 _______________________________________________________________________ 769 routingTreeList ATTRIBUTE ::= { 770 WITH SYNTAX RoutingTreeList 771 SINGLE VALUE 772 ID at-routing-tree-list} 774 RoutingTreeList ::= SEQUENCE OF RoutingTreeName 776 RoutingTreeName ::= DistinguishedName 778 ________________Figure_2:__Routing_Tree_Use_Definition_________________ 780 9 Routing Tree Selection 782 The list of routing trees which a given MTA uses will be represented 783 in the directory. This uses the attribute defined in Figure 2. 784 This attribute defines the routing trees used by an MTA, and the order 785 in which they are used. Holding these in the directory eases 786 configuration management. It also enables an MTA to calculate the 787 routing choice of any other MTA which follows this specification, 788 provided that none of its routing trees have access restrictions. 789 This will facilitate debugging routing problems. 791 9.1 Routing Tree Order 793 The order in which routing trees are used will be critical to the 794 operation of this algorithm. A common approach will be: 796 1. Access one or more shared private routing trees to access private 797 routing information. 799 2. Utilise the open routing tree. 801 3. Fall back to a default route from one of the private routing 802 trees. 804 Initially, the open routing tree will be very sparse, and there will 805 be little routing information in ADMD level nodes. Access to many 806 services will only be via ADMD services, which in turn will only be 807 INTERNET--DRAFT MHS Routing using Directory June 1994 809 accessible via private links. For most MTAs, the fallback routing 810 will be important, in order to gain access to an MTA which has the 811 right private connections configured. 812 In general, for a site, UAs will be registered in one routing tree 813 only, in order to avoid duplication. They may be placed into other 814 routing trees by use of aliases, in order to gain performance. For 815 some sites, Users and UAs with a 1:1 mapping will be mapped onto 816 single entries by use of aliases. 818 9.2 Example use of Routing Trees 820 Some examples of how this structure might be used are now given. Many 821 other combinations are possible to suit organisational requirements. 823 9.2.1 Fully Open Organisation 825 The simplest usage is to place all routing information in the open 826 community routing tree. An organisation will simply establish O/R 827 addresses for all of its UAs in the open community tree, each 828 registering its supporting MTA. This will give access to all systems 829 accessible from this open community. 831 9.2.2 Open Organisation with Fallback 833 In practice, some MTAs and MDs will not be directly reachable from the 834 open community (e.g., ADMDs with a strong model of bilateral 835 agreements). These services will only be available to 836 users/communities with appropriate agreements in place. Therefore it 837 will be useful to have a second (local) routing tree, containing only 838 the name of the fallback MTA at its root. In many cases, this 839 fallback would be to an ADMD connection. 841 Thus, open routing will be tried first, and if this fails the message 842 will be routed to a single selected MTA. 844 9.2.3 Minimal-routing MTA 846 The simplest approach to routing for an MTA is to deliver messages to 847 associated users, and send everything else to another MTA (possibly 848 with backup). 850 INTERNET--DRAFT MHS Routing using Directory June 1994 852 An organisation using MTAs with this approach will register its users 853 as for the fully open organisation. A single routing tree will be 854 established, with the name of the organisation being aliased into the 855 open community routing tree. Thus the MTA will correctly identify 856 local users, but use a fallback mechanism for all other addresses. 858 9.2.4 Organisation with Firewall 860 An organisation can establish an organisation community to build a 861 firewall, with the overall organisation being registered in the open 862 community. This is an important structure, which cannot be achieved 863 easily with current technology (e.g., DNS with MX records). 865 o Some MTAs are registered in the open community routing tree to 866 give access into the organisation. This will include the O/R tree 867 down to the organisational level. Full O/R Address verification 868 will not take place externally. 870 o All users are registered in a private (organisational) routing 871 tree. 873 o All MTAs in the organisation are registered in the organisation's 874 private routing tree, and access information in the organisation's 875 community. This gives full internal connectivity. 877 o Some MTAs in the organisation access the open community routing 878 tree. These MTAs take traffic from the organisation to the 879 outside world. These will often be the same MTAs that are 880 externally advertised. 882 9.2.5 Well Known Entry Points 884 Well known entry points will be used to provide access to countries 885 and MDs which are oriented to private links. A private routing tree 886 will be established, which indicates these links. This tree would be 887 shared by the well known entry points. 889 9.2.6 ADMD using the Open Community for Advertising 891 An ADMD uses the open community for advertising. It advertises its 892 existence and also restrictive policy. This will be useful for: 894 INTERNET--DRAFT MHS Routing using Directory June 1994 896 o Address validation 898 o Advertising the mechanism for a bilateral link to be established 900 9.2.7 ADMD/PRMD gateway 902 An MTA provides a gateway from a PRMD to an ADMD. It is important to 903 note that many X.400 MDs will not use the directory. This is quite 904 legitimate. This technique can be used to register access into such 905 communities from those that use the directory. 907 o The MTA registers the ADMD in its local community (private link) 909 o The MTA registers itself in the PRMD's community to give access to 910 the ADMD. 912 10 Routing Information 914 Routing trees are defined in the previous section, and are used as a 915 framework to hold routing information. Each node, other than a 916 skeletal one, in a routing tree has information associated with it, 917 which is defined by the object class routingInformation in Figure 3. 918 This structure is fundamental to the operation of this specification, 919 and_it_is_recommended_that_it_be_studied_with_care.____________________ 921 routingInformation OBJECT-CLASS ::= { 922 SUBCLASS OF top 923 MAY CONTAIN { 924 subtreeInformation| 925 routingFilter| 926 routingFailureAction| 927 mTAInfo| 928 accessMD| 929 nonDeliveryInfo| 10 930 badAddressSearchPoint| 931 badAddressSearchAttributes} 932 ID oc-routing-information} 933 -- No naming attributes as this is not a 934 -- structural object class 936 INTERNET--DRAFT MHS Routing using Directory June 1994 938 subtreeInformation ATTRIBUTE ::= { 939 WITH SYNTAX SubtreeInfo 20 940 SINGLE VALUE 941 ID at-subtree-information} 943 SubtreeInfo ::= ENUMERATED { 944 all-children-present(0), 945 not-all-children-present(1) } 947 routingFilter ATTRIBUTE ::= { 948 WITH SYNTAX RoutingFilter 30 949 ID at-routing-filter} 951 RoutingFilter ::= SEQUENCE{ 952 attribute-type OBJECT-IDENTIFIER, 953 weight RouteWeight, 954 dda-key String OPTIONAL, 955 regex-match IA5String OPTIONAL, 956 node DistinguishedName } 957 40 958 String ::= CHOICE {PrintableString, TeletexString} 960 routingFailureAction ATTRIBUTE ::= { 961 WITH SYNTAX RoutingFailureAction 962 SINGLE VALUE 963 ID at-routing-failure-action} 965 RoutingFailureAction ::= ENUMERATED { 966 next-level(0), 967 next-tree-only(1), 50 968 next-tree-first(2), 969 stop(3) } 971 mTAInfo ATTRIBUTE ::= { 972 WITH SYNTAX MTAInfo 973 ID at-mta-info} 975 MTAInfo ::= SEQUENCE { 976 name DistinguishedName, 60 978 INTERNET--DRAFT MHS Routing using Directory June 1994 980 weight [1] RouteWeight DEFAULT preferred-access, 981 mta-attributes [2] SET OF Attribute OPTIONAL, 982 ae-info SEQUENCE OF SEQUENCE { 983 aEQualifier PrintableString, 984 ae-weight RouteWeight DEFAULT preferred-access, 985 ae-attributes SET OF Attribute OPTIONAL} OPTIONAL 986 } 988 RouteWeight ::= INTEGER {endpoint(0), 989 preferred-access(5), 70 990 backup(10)} (0..20) 992 _______________Figure_3:__Routing_Information_at_a_Node________________ 994 For example, information might be associated with the (PRMD) node: 996 PRMD=ABC, ADMD=XYZMail, C=GB 998 If this node was in the open community routing tree, then the 999 information represents information published by the owner of the PRMD 1000 relating to public access to that PRMD. If this node was present in 1001 another routing tree, it would represent information published by the 1002 owner of the routing tree about access information to the referenced 1003 PRMD. The attributes associated with a routingInformation node provide 1004 the following information: 1006 Implicit That the node corresponds to a partial or entire valid O/R 1007 address. This is implicit in the existence of the entry. 1009 Object Class If the node is a UA. This will be true if the node is of 1010 object class routedUA. This is described further in Section 11. 1011 If it is not of this object class, it is an intermediate node in 1012 the O/R Address hierarchy. 1014 routingFilter A set of routing filters, defined by the routingFilter 1015 attribute. This attribute provides for routing on information in 1016 the unmatched part of the O/R Address. This is described in 1017 Section 10.3. 1019 subtreeInformation Whether or not the node is authoritative for the 1020 level below is specified by the subtreeInformation attribute. If 1022 INTERNET--DRAFT MHS Routing using Directory June 1994 1024 it is authoritative, indicated by the value all-children-present, 1025 this will give the basis for (permanently) rejecting invalid O/R 1026 Addresses. The attribute is encoded as enumerated, as it may be 1027 later possible to add partial authority (e.g., for certain 1028 attribute types). If this attribute is missing, the node is 1029 assumed to be non-authoritative (not-all-children-present). 1030 For example, consider the node: 1032 MHS-O=Zydeco, PRMD=ABC, ADMD=XYZMail, C=GB 1034 An organisation which has a bilateral agreement with this 1035 organisation has this entry in its routing tree, with no children 1036 entries. This is marked as non-authoritative. There is a second 1037 routing tree maintained by Zydeco, which contains all of the 1038 children of this node, and is marked as authoritative. When 1039 considering an O/R Address 1041 MHS-G=Random + MHS-S=Unknown, MHS-O=Zydeco, 1042 PRMD=ABC, ADMD=XYZMail, C=GB 1044 only the second, authoritative, routing tree can be used to 1045 determine that this address is invalid. In practice, the manager 1046 configuring the non-authoritative tree, will be able to select 1047 whether an MTA using this tree will proceed to full verification, 1048 or route based on the partially verified information. 1050 mTAInfo A list of MTAs and associated information defined by the 1051 mTAInfo attribute. This information is discussed further in 1052 Sections 15 and 18. This information is the key information 1053 associated with the node. When a node is matched in a lookup, it 1054 indicates the validity of the route, and a set of MTAs to connect 1055 to. Selection of MTAs is discussed in Sections 18 and 1056 Section 10.2. 1058 routingFailureAction An action to be taken if none of the MTAs can be 1059 used directly (or if there are no MTAs present) is defined by the 1060 routingFailureAction attribute. Use of this attribute and 1061 multiple routing trees is described in Section 10.1. 1063 accessMD The accessMD attribute is discussed in Section 10.4. This 1064 attribute is used to indicate MDs which provide indirect access to 1066 INTERNET--DRAFT MHS Routing using Directory June 1994 1068 the part of the tree that is being routed to. 1070 badAddressSearchPoint/badAddressSearchAttributes The 1071 badAddressSearchPoint and badAddressSearchAttributes are discussed 1072 in Section 17. This attribute is for when an address has been 1073 rejected, and allows information on alternative addresses to be 1074 found. 1076 10.1 Multiple routing trees 1078 A routing decision will usually be made on the basis of information 1079 contained within multiple routing trees. This section describes the 1080 algorithms relating to use of multiple routing trees. Issues relating 1081 to use of X.500 and handling of errors is discussed in Section14. 1082 The routing decision works by examining a series of entries (nodes) in 1083 one or more routing trees. Each entry may contain information on 1084 possible next-hop MTAs. When an entry is found which enables the 1085 message to be routed, one of the routing options determined at this 1086 point is selected, and a routing decision is made. It is possible, 1087 that further entries may be examined, in order to determine other 1088 routing options. This sort of heuristic is not discussed here. 1089 When a single routing tree is used, the longest possible match based 1090 on the O/R address to be routed to is found. This entry, and then 1091 each of its parents in turn is considered, ending with the routing 1092 tree root node (except in the case of the open routing tree, which 1093 does not have such a node). When multiple routing trees are 1094 considered, the basic approach is to treat them in a defined order. 1095 This is supplemented by a mechanism whereby if a matched node cannot 1096 be used directly, the routing algorithm will have the choice to move 1097 up a level in the current routing tree, or to move on to the next 1098 routing tree with an option to move back to the first tree later. 1099 This option to move back is to allow for the common case where a tree 1100 is used to specify two things: 1102 1. Routing information private to the MTA (e.g., local UAs or routing 1103 info for bilateral links). 1105 2. Default routing information for the case where other routing has 1106 failed. 1108 The actions allow for a tree to be followed, for the private 1109 INTERNET--DRAFT MHS Routing using Directory June 1994 1111 information, then for other trees to be used, and finally to fall back 1112 to the default situation. For very complex configurations it might be 1113 necessary to split this into two trees. The options defined by 1114 routingFailureAction, to be used when the information in the entry 1115 does not enable a direct route, are: 1117 next-level Move up a level in the current routing tree. This is the 1118 action implied if the attribute is omitted. This will usually be 1119 the best action in the open community routing tree. 1121 next-tree-only Move to the next tree, and do no further processing on 1122 the current tree. This will be useful optimisation for a routing 1123 tree where it is known that there is no useful additional routing 1124 information higher in the routing tree. 1126 next-tree-first Move to the next tree, and then default back to the 1127 next level in this tree when all processing is completed on 1128 subsequent trees. This will be useful for an MTA to operate in 1129 the sequence: 1131 1. Check for optimised private routes 1133 2. Try other available information 1135 3. Fall back to a local default route 1137 stop This address is unroutable. No processing shall be done in any 1138 trees. 1140 For the root entry of a routing tree, the default action and 1141 next-level are interpreted as next-tree-only. 1143 10.2 MTA Choice 1145 This section considers how the choice between alternate MTAs is made. 1146 First, it is useful to consider the conditions why an MTA is entered 1147 into a node of the routing tree are: 1149 o The manager for the node of the tree shall place it there. This 1150 is a formality, but critical in terms of overall authority. 1152 INTERNET--DRAFT MHS Routing using Directory June 1994 1154 o The MTA manager shall agree to it being placed there. For a well 1155 operated MTA, the access policy of the MTA will be set to enforce 1156 this. 1158 o The MTA will in general (for some class of message) be prepared to 1159 route to any valid O/R address in the subtree implied by the 1160 address. The only exception to this is where the MTA will route 1161 to a subset of the tree which cannot easily be expressed by making 1162 entries at the level below. An example might be an MTA prepared 1163 to route to all of the subtree, with certain explicit exceptions. 1165 Information on each MTA is stored in an mTAInfo attribute. This 1166 attribute contains: 1168 name The Distinguished Name of the MTA (Application Process) 1170 weight A weighting factor (Route Weight) which gives a basis to 1171 choose between different MTAs. This is described in Section 10.2. 1173 mta-attributes Attributes from the MTAs entry. Information on the 1174 MTA will always be stored in the MTA's entry. The MTA is 1175 represented here as a structure, which enables some of this entry 1176 information to be represented in the routing node. This is 1177 effectively a maintained cache, and can lead to considerable 1178 performance optimisation. For example if ten MTAs were 1179 represented at a node, another MTA making a routing decision might 1180 need to make ten directory reads in order to obtain the 1181 information needed. If any attributes are present here, all of 1182 the attributes needed to make a routing decision shall be 1183 included, and also all attributes at the Application Entity level. 1185 Where an MTA supports a single protocol only, or the protocols it 1186 supports have address information that can be represented in 1187 non-conflicting attributes, then the MTA may be represented as an 1188 application process only. In this case, the ae-info structure which 1189 gives information on associated application entities may be omitted, 1190 as the MTA is represented by a single application entity which has the 1191 same name as the application process. In other cases, the names of 1192 all application entities shall be included. A weight is associated 1193 with each application entity to allow the MTA to indicate a preference 1194 between its application entities. 1196 INTERNET--DRAFT MHS Routing using Directory June 1994 1198 ae-qualifier A printable string (e.g. ``x400-88''), which is the 1199 value of the common name of the relative distinguished name of the 1200 application entity. This can be used with the application process 1201 name to derive the application entity title. 1203 ae-weight A weighting factor (Route Weight) which gives a basis to 1204 choose between different Application Entities (not between 1205 different MTAs). This is described in Section 10.2. 1207 ae-attributes Attributes from the AEs entry. 1209 Route weighting is a mechanism to distinguish between different route 1210 choices. A routing weight may be associated with the MTA in the 1211 context of a routing tree entry. This is because routing weight will 1212 always be context dependent. This will allow machines which have 1213 other functions to be used as backup MTAs. The Route Weight is an 1214 integer in range 0--20. The lower the value, the better the choice of 1215 MTA. Where the weight is equal, and no other factors apply, the choice 1216 between the MTAs shall be random to facilitate load balancing. If the 1217 MTA itself is in the list, it shall only route to an MTA of lower 1218 weight. The exact values will be chosen by the manager of the 1219 relevant part of the routing tree. For guidance, three fixed points 1220 are given: 1222 o 0. For an MTA which can deliver directly to the entire subtree 1223 implied by the position in the routing tree. 1225 o 5. For an MTA which is preferred for this point in the subtree. 1227 o 10. For a backup MTA. 1229 When an organisation registers in multiple routing trees, the route 1230 weight used is dependent on the context of the subtree. In general it 1231 is not possible to compare weights between subtrees. In some cases, 1232 use of route weighting can be used to divert traffic away from 1233 expensive links. 1235 Attributes present in an MTA Entry are defined in various parts of 1236 this specification. A summary and pointers to these sections is given 1237 in Section 16. 1238 Attributes that are available in the MTA entry and will be needed for 1239 making a routing choice are: 1241 INTERNET--DRAFT MHS Routing using Directory June 1994 1243 protocolInformation 1245 applicationContext 1247 mhs-deliverable-content-length 1249 responderAuthenticationRequirements 1251 initiatorAuthenticationRequirements 1253 responderPullingAuthenticationRequirements 1255 initiatorPullingAuthenticationRequirements 1257 initiatorP1Mode 1259 responderP1Mode 1261 polledMTAs Current MTA shall be in list if message is to be pulled. 1263 mTAsAllowedToPoll 1265 supportedMTSExtensions 1267 If any MTA attributes are present in the mTAInfo attribute, all of the 1268 attribute that may affect routing choice shall be present. Other 1269 attributes may be present. A full list of MTA attributes, with 1270 summaries of their descriptions are given in Section 16, with a formal 1271 definition in Figure 6 on Page 37. 1273 10.3 Routing Filters 1275 This attribute provides for routing on information in the unmatched 1276 part of the O/R Address, including: 1278 o Routing on the basis of an O/R Address component type 1280 o Routing on the basis of a substring match of an O/R address 1281 component. This might be used to route X121 addressed faxes to an 1282 appropriate MTA. 1284 INTERNET--DRAFT MHS Routing using Directory June 1994 1286 When present, the procedures of analysing the routing filters shall be 1287 followed before other actions. The routing filter overrides mTAInfo 1288 and accessMD attributes. The components of the routingFilter 1289 attribute are: 1291 attribute-type This gives the attribute type to be matched, and is 1292 selected from the attribute types which have not been matched to 1293 identify the routing entry. The filter applies to this attribute 1294 type. If there is no regular expression present (as defined 1295 below), the filter is true if the attribute is present. The value 1296 is the object identifier of the X.500 attribute type (e.g., 1297 at-prmd-name). 1299 weight This gives the weight of the filter, which is encoded as a 1300 Route Weight, with lower values indicating higher priority. If 1301 multiple filters match, the weight of each matched filter is used 1302 to select between them. If the weight is the same, then a random 1303 choice shall be made. 1305 dda-key If the attribute is domain defined, then this parameter may 1306 be used to identify the key. 1308 regex-match This string is used to give a regular expression match on 1309 the attribute value. The syntax for regular expressions is 1310 defined in Appendix E. 1312 node This defines where to get routing information for the filter. 1313 It will be an entry with object class routingInformation, which 1314 can be used to determine the MTA or MTA choice. 1316 An example of use of routing filters is now given, showing how to 1317 route on X121 address to a fax gateway in Germany. Consider the 1318 routing point. 1320 PRMD=ABC, ADMD=XYZMail, C=GB 1322 The entry associated would have two routing filters: 1324 1. One with type x121 and no regular expression, to route a default 1325 fax gateway. 1327 INTERNET--DRAFT MHS Routing using Directory June 1994 1329 _______________________________________________________________________ 1331 accessMD ATTRIBUTE ::= { 1332 SUBTYPE OF distinguishedName 1333 ID at-access-md} 1335 ______________________Figure_4:__Indirect_Access_______________________ 1337 2. One with type x121 and a regular expression ^9262 to route all 1338 German faxes to a fax gateway located in Germany with which there 1339 is a bilateral agreement. This would have a lower weight, so that 1340 it would be selected over the default fax gateway. 1342 10.4 Indirect Connectivity 1344 In some cases a part of the O/R Address space will be accessed 1345 indirectly. For example, an ADMD without access from the open 1346 community might have an agreement with another MD to provide this 1347 access. This is achieved by use of the accessMD attribute defined in 1348 Figure 4. If this attribute is found, the routing algorithm shall 1349 read the entry pointed to by this distinguished name and route 1350 according to the information retrieved, in order to route to this 1351 access MD. 1353 The attribute is called an MD, as this is descriptive of its normal 1354 use. It might point to a more closely defined part of the O/R Address 1355 space. 1356 It is possible for both access MD and MTAs to be specified. This 1357 might be done if the MTAs only support access over a restricted set of 1358 transport stacks. In this case, the access MD shall only be routed to 1359 if it is not possible to route to any of the MTAs. 1360 This structure can also be used as an optimisation, where a set of 1361 MTAs provides access to several parts of the O/R Address space. 1362 Rather than repeat the MTA information (list of MTAs) in each 1363 reference to the MD, a single access MD is used as a means of grouping 1364 the MTAs. The value of the Distinguished Name of the access MD will 1365 probably not be meaningful in this case (e.g., it might be the name 1366 ``Access MTA List'', within the organisation.) 1368 If the MTA routing is unable to access the information in the Access 1369 MD dues to directory security restrictions, the routing algorithm 1370 shall continue as if no MTA information was located in the routing 1371 INTERNET--DRAFT MHS Routing using Directory June 1994 1373 entry. 1375 11 Local Addresses (UAs) 1377 Local addresses (UAs) are a special case for routing: the endpoint. 1378 The definition of the routedUA object class is given in Figure 5. 1379 This identifies a User Agent in a routing tree. This is needed for 1380 several reasons: 1382 1. To allow UAs to be defined without having an entry in another part 1383 of the DIT. 1385 2. To identify which (leaf and non-leaf) nodes in a routing tree are 1386 User Agents. In a pure X.400 environment, a UA (as distinct from 1387 a connecting part of the O/R address space) is simply identified 1388 by object class. Thus an organisation entry can itself be a UA. A 1389 UA need not be a leaf, and can thus have children in the tree. 1391 3. To allow UA parameters as defined in X.402 (e.g., the 1392 mhs-deliverable-eits) to be determined efficiently from the 1393 routing tree, without having to go to the user's entry. 1395 4. To provide access to other information associated with the UA, as 1396 defined below. 1398 The following attributes are defined associated with the UA. 1400 supportedExtensions 1402 supportingMTA The MTAs which support a UA directly are noted in the 1403 SupportingMTA attribute, which may be multi-valued. In the X.400 1404 model, only one MTA is associated with a UA. In practice, it is 1405 possible and useful for several MTAs to be able to deliver to a 1406 single UA. This attribute is a subtype of MTAinfo, as it is 1407 possible for an MTA to be registered to route to a UA, without it 1408 actually being able to deliver messages to it. 1409 This attribute shall be present, unless the address is being 1410 non-delivered or redirected. 1412 mandatoryRedirect/filteredRedirect The attributes mandatoryRedirect 1413 and filteredRedirect control redirects, as described in 1415 INTERNET--DRAFT MHS Routing using Directory June 1994 1417 Section 22.1. 1419 userName The attribute userName points to the distinguished Name of 1420 the user, as defined by the mhs-user in X.402. The pointer from 1421 the user to the O/R Address is achieved by the mhs-or-addresses 1422 attribute. This makes the UA/User linkage symmetrical. 1424 nonDeliveryInfo The attribute nonDeliveryInfo mandates non-delivery 1425 to this address, as described in Section 22.3. 1427 When routing to a UA, an MTA will read the supportingMTA attribute. 1428 If it finds its own name present, it will know that the UA is local, 1429 and invoke appropriate procedures for local delivery (e.g., 1430 co-resident or P3 access information). The cost of holding these 1431 attributes for each UA at a site will often be reduced by use of 1432 shared attributes (as defined in X.500(93)). 1434 The linkage between the UA and User entries was noted above. It is 1435 also possible to use a single entry for both User and UA, as there is 1436 no conflict between the attributes in each of the objects. In this 1437 case, the entries shall be in one part of the DIT, with aliases from 1438 the other. Because the UA and User are named with different 1439 attributes, the aliases shall be at the leaf level. 1441 11.1 Searching for Local Users 1443 The approach defined in this specification performs all routing by use 1444 of reads. This is done for performance reasons, as it is a reasonable 1445 expectation that all DSA implementations will support a high 1446 performance read operation. For local routing only, an MTA in 1447 cooperation with the provider of the local routing tree may choose to 1448 use a search operation to perform routing. The major benefit of this 1449 is that there will not be a need to store aliases for alternate names, 1450 and so the directory storage requirement and alias management will be 1451 reduced. The difficulty with this approach is that it is hard to 1452 define search criteria that would be effective in all situations and 1453 well supported by all DUAs. There are also issues about determining 1454 the validity of a route on the basis of partial matches. 1456 INTERNET--DRAFT MHS Routing using Directory June 1994 1458 12 Direct Lookup 1460 Where an O/R address is registered in the open community and has one 1461 or more ``open'' MTAs which support it, this will be optimised by 1462 storing MTA information in the O/R address entry. In general, the 1463 Directory will support this by use of attribute inheritance or an 1464 implementation will optimise the storage or repeated information, and 1465 so there will not be a large storage overhead implied. This is a 1466 function of the basic routing approach. 1467 As a further optimisation of this case, the User's distinguished name 1468 entry may contain the mTAInfo attribute. This can be looked up from 1469 the distinguished name, and thus routing on submission can be achieved 1470 by use of a single read. 1472 13 Alternate Routes 1474 13.1 Finding Alternate Routes 1476 The routing algorithm selects a single MTA to be routed to. It could 1477 be extended to find alternate routes to a single MTA with possibly 1478 different weights. How far this is done is a local configuration 1479 choice. Provision of backup routing is desirable, and leads to robust 1480 service, but excessive use of alternate routing is not usually 1481 beneficial. It will often force messages onto convoluted paths, when 1482 there was only a short outage on the preferred path. 1483 It is important to note that this strategy will lead to picking the 1484 first acceptable route. It is important to configure the routing 1485 trees so that the first route identified will also be the best route. 1487 13.2 Sharing routing information 1489 So far, only single addresses have been considered. Improving routing 1490 choice for multiple addresses is analogous to dealing with multiple 1491 routes. This section defines an optional improvement. When multiple 1492 addresses are present, and alternate routes are available, the 1493 preferred routes may be chosen so as to maximise the number of 1494 recipients sent with each message. 1496 Specification of routing trees can facilitate this optimisation. 1497 Suppose there is a set of addresses (e.g., in an organisation) which 1498 INTERNET--DRAFT MHS Routing using Directory June 1994 1500 have different MTAs, but have access to an MTA which will do local 1501 switching. If each address is registered with the optimal MTA as 1502 preferred, but has the ``hub'' MTA registered with a higher route 1503 weight, then optimisation may occur when a message is sent to multiple 1504 addresses in the group. 1506 14 Looking up Information in the Directory 1508 The description so far has been abstract about lookup of information. 1509 This section considers how information is looked up in the Directory. 1510 Consider that an O/R Address is presented for lookup, and there is a 1511 sequence of routing trees. At any point in the lookup sequence, there 1512 is one of a set of actions that can take place: 1514 Handle MTA Info Information from the node shall be examined. If 1515 suitable information is found, one of the following is done: 1517 o Use the information and finish the routing process 1519 o Continue the routing process in order to find more options to 1520 choose from 1522 Unroutable Address Potentially valid address, which cannot be routed 1524 Bad Address Return the failure to the routing algorithm 1526 Temporary Reject Try again later. The MTA shall handle this in a 1527 similar manner to the way it would handle the failure to connect 1528 to a remote MTA. 1530 Permanent Reject Administrative error on the directory which may be 1531 fixed in future, but which currently prevents routing. 1533 Editor's Note: Add information on what to do and which diagnostic 1534 codes and handling of failed lookups. 1536 Errors from the lookup (directory read) shall be handled as follows: 1538 AttributeError This leads to a permanent reject. 1540 INTERNET--DRAFT MHS Routing using Directory June 1994 1542 NameError The matched parameter is used to determine the number of 1543 components of the name that have matched (possibly zero). The 1544 read is then repeated with this name. This is the normal case, 1545 and allows the ``best'' entry in the routing tree to be located 1546 with two reads. 1548 Referral The referral shall be followed. 1550 SecurityErrror Strip one component of the O/R address and continue. 1552 ServiceError This leads to a temporary reject (see above). 1554 15 Naming MTAs 1556 MTAs need to be named in the DIT, but the name does not have routing 1557 significance, it is simply a unique key. Attributes associated with 1558 naming MTAs are given in Figure 6. This figure also gives a list of 1559 attributes, which may be present in the MTA entry. The use of most of 1560 these is explained in subsequent sections. The mTAName and 1561 globalDomainID attributes are needed to define the information that an 1562 MTA places in trace information. As noted previously, an MTA is 1563 represented as an Application Process, with one or more Application 1564 Entities.______________________________________________________________ 1566 mTAName ATTRIBUTE ::= { 1567 SUBTYPE OF name 1568 WITH SYNTAX DirectoryString{ub-mta-name-length} 1569 SINGLE VALUE 1570 ID at-mta-name} 1571 -- used for naming when 1572 -- MTA is named in O=R Address Hierarchy 1574 globalDomainID ATTRIBUTE ::= { 10 1575 WITH SYNTAX GlobalDomainIdentifier 1576 SINGLE VALUE 1577 ID at-global-domain-id} 1578 -- both attributes present when MTA 1579 -- is named outside O=R Address Hierarchy 1580 -- to enable trace to be written 1582 mTAApplicationProcess OBJECT CLASS ::= { 1583 INTERNET--DRAFT MHS Routing using Directory June 1994 1585 SUBCLASS OF {application-process} 1586 MAY CONTAIN { 20 1587 mTAWillRoute| 1588 globalDomainID| 1589 routingTreeList| 1590 accessMD| 1591 localAccessUnit| 1592 accessUnitsUsed 1593 } 1594 ID oc-mta-application-process} 1596 mTA OBJECT CLASS ::= { -- Application Entity 30 1597 SUBCLASS OF {mhs-message-transfer-agent} 1598 MAY CONTAIN { 1599 mTAName| 1600 globalDomainID| -- per AE variant 1601 responderAuthenticationRequirements| 1602 initiatorAuthenticationRequirements| 1603 responderPullingAuthenticationRequirements| 1604 initiatorPullingAuthenticationRequirements| 1605 initiatorP1Mode| 1606 responderP1Mode| 40 1607 polledMTAs| 1608 protocolInformation| 1609 respondingRTSCredentials| 1610 initiatingRTSCredentials| 1611 callingPresentationAddress| 1612 callingSelectorValidity| 1613 bilateralTable| 1614 mTAWillRoute| 1615 mhs-deliverable-content-length| 1616 routingTreeList| 50 1617 supportedMTSExtensions| 1618 mTAsAllowedToPoll 1619 } 1620 ID oc-mta} 1622 ______________________Figure_6:__MTA_Definitions_______________________ 1624 In X.400, MTAs are named by MD and a single string. This style of 1625 naming is supported, with MTAs named in the O/R Address tree relative 1626 to the root of the DIT (or possibly in a different routing tree). The 1627 mTAName attribute is used to name MTAs in this case. For X.400(88) it 1628 INTERNET--DRAFT MHS Routing using Directory June 1994 1630 is assumed that the Distinguished Name may be passed as an AE Title. 1631 MTAs may be named with any other DN, which can be in the O/R Address 1632 or Organisational DIT hierarchy. There are several reasons why MTAs 1633 might be named differently. 1635 o The flat naming space is inadequate to support large MDs. MTA 1636 name assignment using the directory would be awkward. 1638 o An MD does not wish to register its MTAs in this way (essentially, 1639 it prefers to give them private names in the directory). 1641 o An organisation has a policy for naming application processes, 1642 which does not fit this approach. 1644 In this case, the MTA entry shall contain the correct information to 1645 be inserted in trace. The mTAName and globalDomainID attributes are 1646 used to do this. They are single value. For an MTA which inserts 1647 different trace in different circumstances, a more complex approach 1648 would be needed. 1649 An MD may choose to name its MTAs outside of the O/R address 1650 hierarchy, and then link some or all of them with aliases. A pointer 1651 from this space may help in resolving information based on MTA Trace. 1653 15.1 Naming 1984 MTAs 1655 Some simplifications are necessary for 1984 MTAs, and only one naming 1656 approach may be used. In X.400, MTAs are named by MD and a single 1657 string. This style of naming is supported, with MTAs named in the O/R 1658 Address tree relative to the root of the DIT (or possibly in a 1659 different routing tree). The MTAName attribute is used to name MTAs 1660 in this case. 1662 16 Attributes Associated with the MTA 1664 This section lists the attributes which may be associated with an MTA 1665 as defined in Figure 6, and gives pointers to the sections that 1666 describe them. 1668 mTAName Section 15. 1670 INTERNET--DRAFT MHS Routing using Directory June 1994 1672 globalDomainID Section 15. 1674 protocolInformation Section 18.1. 1676 applicationContext Section 18.2. 1678 mhs-deliverable-content-length Section 18.3. 1680 responderAuthenticationRequirements Section 20.2. 1682 initiatorAuthenticationRequirements Section 20.2. 1684 responderPullingAuthenticationRequirements Section 20.2. 1686 initiatorPullingAuthenticationRequirements Section 20.2. 1688 initiatorP1Mode Section 19. 1690 responderP1Mode Section 19. 1692 polledMTAs Section 19. 1694 mTAsAllowedToPoll Section 19. 1696 respondingRTSCredentials Section 20.3. 1698 initiatingRTSCredentials Section 20.3. 1700 callingPresentationAddress Section 20.3. 1702 callingSelectorValidity Section 20.3. 1704 bilateralTable Section 17. 1706 mTAWillRoute Section 21. 1708 routingTreeList Section 9. 1710 supportedMTSExtensions Section 18.3. 1712 INTERNET--DRAFT MHS Routing using Directory June 1994 1714 17 Bilateral Agreements 1716 Each MTA has an entry in the DIT. This will be information which is 1717 globally valid, and will be useful for handling general information 1718 about the MTA and for information common to all connections. In many 1719 cases, this will be all that is needed. This global information may 1720 be restricted by access control, and so need not be globally 1721 available. In some cases, MTAs will maintain bilateral and 1722 multilateral agreements, which hold authentication and related 1723 information which is not globally valid. This section describes a 1724 mechanism for grouping such information into tables, which enables an 1725 MTA to have bilateral information or for a group of MTAs to share 1726 multilateral information. The description is for bilateral 1727 information, but is equally applicable to multilateral agreements. 1728 For the purpose of a bilateral agreement, the MTA is considered to be 1729 an application entity. This means that when this is distinct from the 1730 application process, that the agreements are protocol specific. 1732 A bilateral agreement is represented by one entry associated with each 1733 MTA participating in the bilateral agreement. For one end of the 1734 bilateral agreement, the agreement information will be keyed by the 1735 name of the MTA at the other end. Each party to the agreement will 1736 set up the entry which represents its half of the agreed policy. The 1737 fact that these correspond is controlled by the external agreement. 1738 In many cases, only one half of the agreement will be in the 1739 directory. The other half might be in an ADMD MTA configuration file. 1740 MTA bilateral information is stored in a table, as defined in [14]. 1741 An MTA has access to a sequence of such tables, each of which controls 1742 agreements in both directions for a given MTA. Where an MTA is 1743 represented in multiple tables, the first agreement shall be used. 1744 This allows an MTA to participate in multilateral agreements, and to 1745 have private agreements which override these. The definition of 1746 entries in this table are defined in Figure 7. This table will 1747 usually be access controlled so that only a single MTA or selected 1748 MTAs which appear externally as one MTA can access it. 1749 Each entry in the table is of the object class 1750 distinguishedNameTableEntry, which is used to name the entry by the 1751 distinguished name of the MTA. In some cases discussed in 1752 Section 20.1, there will also be aliases of type textTableEntry. The 1753 MTA attributes needed as a part of the bilateral agreement (typically 1754 MTA Name/Password pairs), as described in Section 20.3, will always be 1755 present. Other MTA attributes (e.g., presentation address) may be 1756 present for one of two reasons: 1758 INTERNET--DRAFT MHS Routing using Directory June 1994 1760 1. As a performance optimisation 1762 2. Because the MTA does not have a global entry 1764 Every MTA with bilateral agreements will define a bilateral MTA table. 1765 When a connection from a remote MTA is received, its Distinguished 1766 Name is used to generate the name of the table entry. For 1984, the 1767 MTA Name exchanged at the RTS level is used as a key into the table. 1768 The location of the bilateral tables used by the MTA and the order in 1769 which they are used are defined by the bilateralTable attribute in the 1770 MTA entry, which is defined in Figure 8. 1772 All of the MTA information described in Section 16 may be used in the 1773 bilateral table entries. This will allow bilateral control of a wide 1774 range of parameters. 1776 Editor's Note: Need to add in control for various ghastly things such 1777 as trace stripping and originator munging. Whilst this is needed, 1778 it is perhaps best swept under the carpet and left to 1779 implementation specific extensions. This area will be reviewed in 1780 light of implementation experience. 1782 18 MTA Selection 1784 18.1 Dealing with protocol mismatches 1786 MTAs may operate over different stacks. This means that some MTAs 1787 cannot talk directly to each other. Even where the protocols are the 1788 same, there may be reasons why a direct connection is not possible. 1789 An environment where there is full connectivity over a single stack is 1790 known as a transport community [9]. The set of transport communities 1791 supported by an MTA is specified by use of the protocolInformation 1792 attribute defined in X.500(93). This is represented as a separate 1793 attribute for the convenience of making routing decisions. 1794 A community is identified by an object identifier, and so the 1795 mechanism supports both well known and private communities. A list of 1796 object identifiers corresponding to well known communities is given in 1797 Appendix B. 1799 INTERNET--DRAFT MHS Routing using Directory June 1994 1801 18.2 Supported Protocols 1803 It is important to know the protocol capabilities of an MTA. This is 1804 done by the application context. There are standard definitions for 1805 the following 1988 protocols. 1807 o P3 (with and without RTS, both user and MTS initiated) 1809 o P7 (with and without RTS). 1811 o P1 (various modes). Strictly, this is the only one that matters 1812 for routing. 1814 In order to support P1(1984) and P1(1988) in X.410 mode, application 1815 contexts which define these protocols are given in Appendix C. This 1816 context is for use in the directory only, and would never be exchanged 1817 over the network. 1818 For routing purposes, a message store which is not co-resident with an 1819 MTA is represented as if it had a co-resident MTA and configured with 1820 a single link to its supporting MTA. 1822 In cases where the UA is involved in exchanges, the UA will be of 1823 object class mhs-user-agent, and this will allow for appropriate 1824 communication information to be registered. 1826 18.3 MTA Capability Restrictions 1828 In addition to policy restrictions, described in Section 21, an MTA 1829 may have capability restrictions. The maximum size of MPDU is defined 1830 by the standard attribute mhs-deliverable-content-length. The 1831 supported MTS extensions are defined by a new attribute specified in 1832 Figure 9. 1833 It may be useful to define other capability restrictions, for example 1834 to enable routing of messages around MTAs with specific deficiencies. 1835 It has been suggested using MTA capabilities as an optimised means of 1836 expressing capabilities of all users associated with the MTA. This is 1837 felt to be undesirable. 1839 18.4 Subtree Capability Restrictions 1840 INTERNET--DRAFT MHS Routing using Directory June 1994 1842 In many cases, users of a subtree will share the same capabilities. 1843 It is possible to specify this by use of attributes, as defined in 1844 Figure 10. This will allow for restrictions to be determined in cases 1845 where there is no entry for the user or O/R Address. This will be a 1846 useful optimisation in cases where the UA capability information is 1847 not available from the directory, either for policy reasons or because 1848 it is not there. This information may also be present in the domain 1849 tree (RFC 822). 1850 This shall be implemented as a collective attribute, so that it is 1851 available to all entries in the subtree below the entry. This can 1852 also be used for default setting in the subtree. 1854 19 MTA Pulling Messages 1856 Pulling messages between MTAs, typically by use of two way alternate, 1857 is for bilateral agreement. It is not the common case. There are two 1858 circumstances in which it can arise. 1860 1. Making use of a connection that was opened to push messages. 1862 2. Explicitly polling in order to pull messages 1864 Attributes to support this are defined in Figure 11. These attributes 1865 indicate the capabilities of an MTA to pull messages, and allows a 1866 list of polled MTAs to be specified. If omitted, the normal case of 1867 push-only is specified. In the MTA Entry, the polledMTAs attribute 1868 indicates MTAs which are to be polled and the mTAsAllowedToPoll 1869 attribute indicates MTAs that may poll the current MTA. 1871 20 Security and Policy 1873 20.1 Finding the Name of the Calling MTA 1875 A key issue for authentication is for the called MTA to find the name 1876 of the calling MTA. This is needed for it to be able to look up 1877 information on a bilateral agreement. 1878 Where X.400(88) is used, the name is available as a distinguished name 1879 from the AE-Title provided in the A-Associate. For X.400(84), it will 1880 not be possible to derive a global name from the bind. The MTA Name 1881 INTERNET--DRAFT MHS Routing using Directory June 1994 1883 exchanged in the RTS Bind will provide a key into the private 1884 bilateral agreement table (or tables). Thus for X.400(1984) it will 1885 only be possible to have bilateral inbound links or no authentication 1886 of the calling MTA. 1888 Editor's Note CDC use a search here, as a mechanism to use a single 1889 table and an 88/84 independent access. This may be considered for 1890 general adoption. It appears to make the data model cleaner, 1891 possibly at the expense of some performance. This will be 1892 considered in the light of implementation experience. 1894 20.2 Authentication 1896 The levels of authentication required by an MTA will have an impact on 1897 routing. For example, if an MTA requires strong authentication, not 1898 all MTAs will be able to route to it. The attributes which define the 1899 authentication requirements are defined in Figure 12. 1901 The attributes specify authentication levels for the following cases: 1903 Responder These are the checks that the responder will make on the 1904 initiator's credentials. 1906 Initiator These are the checks that the initiator will make on the 1907 responders credentials. Very often, no checks are needed --- 1908 establishing the connection is sufficient. 1910 Responder Pulling These are responder checks when messages are 1911 pulled. These will often be stronger than for pushing. 1913 Initiator Pulling For completeness. 1915 If an attribute is omitted, no checks are required. If multiple 1916 checks are required, then each of the relevant bits shall be set. If 1917 there are alternative acceptable checks, then multiple values of the 1918 attribute are used. 1919 The values of the authentication requirements mean: 1921 mta-name-present That an RTS level MTA parameter shall be present for 1922 logging purposes. 1924 INTERNET--DRAFT MHS Routing using Directory June 1994 1926 aet-present That a distinguished name application entity title shall 1927 be provided at the ACSE level 1929 aet-valid As for aet-present, and that the AET be registered in the 1930 directory. This may be looked up as a part of the validation 1931 process. If mta-name-present is set, the RTS value of mta and 1932 password shall correspond to those registered in the directory. 1934 network-address This can only be used for the responder. The AET 1935 shall be looked up in the directory, and the 1936 callingPresentationAddress attribute matched against the calling 1937 address. This shall match exactly at the network level. The 1938 validity of selectors will be matched according to the 1939 callingSelectorValidity attribute. 1941 simple-authentication All MTA and password parameters needed for 1942 simple authentication shall be used. This will usually be in 1943 conjunction with a bilateral agreement. 1945 strong-authentication Use of strong authentication. 1947 bilateral-agreement-needed This means that this MTA will only accept 1948 connections in conjunction with a bilateral agreement. This link 1949 cannot be used unless such an agreement exists. 1951 These attributes may also be used to specify UA/MTA authentication 1952 policy. They may be resident in the UA entry in environments where 1953 this information cannot be modified by the user. Otherwise, it will 1954 be present in an MTA table (represented in the directory). 1956 An MTA could choose to have different authentication levels related to 1957 different policies (Section 21). This is seen as too complex, and so 1958 they are kept independent. The equivalent function can always be 1959 achieved by using multiple Application Entities with the application 1960 process. 1962 20.3 Authentication Information 1964 This section specifies connection information needed by P1. This is 1965 essentially RTS parameterisation needed for authentication. This is 1966 defined in Figure 13. Confidential bilateral information is implied 1967 by these attributes, and this will be held in the bilateral 1968 information agreement. This shall have appropriate access control 1969 INTERNET--DRAFT MHS Routing using Directory June 1994 1971 applied. Note that in some cases, MTA information will be split 1972 across a private and public entry. 1973 The parameters are: 1975 Initiating Credentials The credentials to be used when the local MTA 1976 initiates the association. It gives the credentials to insert 1977 into the request, and those expected in the response. 1979 Responding Credentials The credentials to be used when the remote MTA 1980 initiates the association. It gives the credential expected in 1981 the request, and those to be inserted into the response. 1983 Remote Presentation Address Valid presentation addresses, which the 1984 remote MTA may connect from. 1986 If an MTA/Password pair is omitted. The MTA shall default to the 1987 local MTA Name, and the password to a zero length OCTET STRING. 1989 Note: It may be useful to add more information here relating to 1990 parameters required for strong authentication. 1992 21 Policy and Authorisation 1994 21.1 Simple MTA Policy 1996 The routing trees will generally be configured in order to identify 1997 MTAs which will route to the destination. A simple means is 1998 identified to specify an MTA's policy. This is defined in Figure 14. 1999 If this attribute is omitted, the MTA shall route all traffic to the 2000 implied destinations from the context of the routing tree for any MTAs 2001 that have valid access to the routing tree. 2002 The multi-valued attribute gives a set of policies which the MTA will 2003 route. O/R Addresses are represented by a prefix, which identifies a 2004 subtree. A distinguished name encoding of O/R Address is used. There 2005 are three components: 2007 from This gives a set of O/R addresses which are granted permission 2008 by this attribute value. If omitted, ``all'' is implied. 2010 INTERNET--DRAFT MHS Routing using Directory June 1994 2012 to This gives the set of acceptable destinations. If omitted, 2013 ``all'' is implied. 2015 from-excludes This defines (by prefix) subtrees of the O/R address 2016 tree which are explicitly excluded from the ``from'' definition. 2017 If omitted, there are no exclusions. 2019 to-excludes This defines (by prefix) subtrees of the O/R address tree 2020 which are explicitly excluded from the ``to'' definition. If 2021 omitted, there are no exclusions. 2023 This simple policy will suffice for most cases. In particular, it 2024 gives sufficient information for most real situations where a policy 2025 choice is forced, and the application of this policy would prevent a 2026 message being routed. 2028 This simple prefixing approach does not deal explicitly with alias 2029 dereferencing. The prefixes refer to O/R addresses where aliases have 2030 been dereferenced. To match against these prefixes, O/R addresses 2031 being matched need to be ``normalised'' by being looked up in the 2032 directory to resolve alias values. If the lookup fails, it shall be 2033 assumed that the provided address is already normalised. This means 2034 that policy may be misinterpreted for parts of the DIT not referenced 2035 in the directory. 2036 The originator refers to the MTS originator, and the recipient to the 2037 MTS recipient, following any list expansion or redirect. 2038 This simple policy does not apply to delivery reports. Any advertised 2039 route shall work for delivery reports, and it does not makes sense to 2040 regulate this on the basis of the sender. 2042 Editor's Note: It would be useful to include some examples here. 2044 21.2 Complex MTA Policy 2046 MTAs will generally have a much more complex policy mechanism, such as 2047 that provided by PP [17]. Representing this as a part of the routing 2048 decision is not done here, but may be addressed in future versions. 2049 Some of the issues which need to be tackled are: 2051 o Use of charging and non-charging nets 2053 INTERNET--DRAFT MHS Routing using Directory June 1994 2055 o Policy dependent on message size 2057 o Different policy for delivery reports. 2059 o Policy dependent on attributes of the originator or 2060 recipient(e.g., mail from students) 2062 o Content type and encoded information types 2064 o The path which the message has traversed to reach the MTA 2066 o MTA bilateral agreements 2068 o Pulling messages 2070 o Costs. This sort of policy information may also be for 2071 information only. 2073 Where an MTA applies more complex policies, it is highly undesirable 2074 that they lead to non-routablity of messages for MTAs routing using 2075 the published information. 2077 Policies relating to submission do not need to be public. They can be 2078 private to the MTA. 2080 22 Delivery 2082 22.1 Redirects 2084 There is a need to specify redirects in the Directory. This will be 2085 done at the O/R Address level (i.e., in a routing tree). This will be 2086 useful for alternate names where an equivalent name (synonym) defined 2087 by an alias is not natural. An example where this might be 2088 appropriate is to redirect mail to a new O/R address where a user had 2089 changed organisation. The definitions are given in Figure 15. 2091 Mandatory redirects are specified by the mandatoryRedirect attribute. 2092 A filtered redirect is provided, to allow small messages, large 2093 messages, or messages containing specific EITs or content to be 2094 redirected. Message size is measured in kBytes. Where multiple 2095 elements are contained in the FilteredRedirect structure, they are 2096 treated as having a ``logical or'' relationship. 2098 INTERNET--DRAFT MHS Routing using Directory June 1994 2100 When a delivery report is sent to an address which would be 2101 redirected, X.400 would ignore the redirect. This means that every 2102 O/R address would need to have a valid means of delivery. This would 2103 seem to be awkward to manage. Therefore, the redirect shall be 2104 followed, and the delivery report delivered to the redirected address. 2105 These redirects are handled directly by the MTA. Redirects can also be 2106 initiated by the UA, for example in the context of a P7 interaction. 2108 22.2 Underspecified O/R Addresses 2110 X.400 requires that some underspecified O/R Addresses are handled in a 2111 given way (e.g., if a surname is given without initials or given 2112 name). Where an underspecified O/R Address is to be treated as if it 2113 were another O/R Address, an alias shall be used. If the O/R Address 2114 is to be rejected as ambiguous, and entry shall be created in the DIT, 2115 and forced non-delivery specified for this reason. 2117 22.3 Non Delivery 2119 It is possible for a manager to define an address to non-deliver with 2120 specified reason and diagnostic codes. This might be used for a range 2121 of management purposes. The attribute to do this is defined in 2122 Figure 16. 2124 22.4 Bad Addresses 2126 If there is a bad address, it is desirable to do a directory search to 2127 find alternatives. This is a helpful user service and may be 2128 supported. This function is invoked after address checking has 2129 failed, and where this is no user supplied alternate recipient. This 2130 function would be an MTA-chosen alternative to administratively 2131 assigned alternate recipient. 2132 Attributes to support handling of bad addresses are defined in 2133 Figure 17. The attributes are: 2135 badAddressSearchPoint This gives the point (or list of points) from 2136 which to search. 2138 badAddressSearchAttributes This gives the set of attribute types to 2139 search on. The default is common name. 2141 INTERNET--DRAFT MHS Routing using Directory June 1994 2143 Searches are always single level, and always use approximate match. 2144 If a small number of matches are made, this is returned to the 2145 originator by use of the per recipient AlternativeAddresssInformation 2146 in the delivery report (DR). This shall be marked non-critical, so 2147 that it will not cause the DR to be discarded (e.g., in downgrading to 2148 X.400(1984)). This attribute allows the Distinguished Name and O/R 2149 Address of possible alternate recipients to be returned with the 2150 delivery report. There is also the possibility to attach extra 2151 information in the form of directory attributes. Typically this might 2152 be used to return attributes of the entry which were matched in the 2153 search. A summary of the information shall also be returned using the 2154 delivery report supplementary information filed (e.g., ``your message 2155 could not be delivered to smith, try J. Smith or P. Smith''), so that 2156 the information is available to user agents not supporting this 2157 extension. Note the length restriction of this field is 256 2158 (ub-supplementary-info-length). 2159 If the directory search fails, or there are no matches returned, a 2160 delivery report shall be returned as if this extra check had not been 2161 made. 2163 Editor's Note: It might be useful to allow control of search type, 2164 and also single level vs subtree. This issue is for further 2165 study. 2167 23 Submission 2169 A message may be submitted with Distinguished Name only. If the MTA 2170 to which the message is submitted supports this service, this section 2171 describes how the mapping is done. 2173 23.1 Normal Derivation 2175 The Distinguished Name is looked up to find the attribute 2176 mhs-or-addresses. If the attribute is single value, it is 2177 straightforward. If there are multiple values, one O/R address shall 2178 be selected at random. 2180 INTERNET--DRAFT MHS Routing using Directory June 1994 2182 23.2 Roles and Groups 2184 Some support for roles is given. If there is no O/R address, and the 2185 entry is of object class role, then the roleOccupant attribute shall 2186 be dereferenced, and the message submitted to each of the role 2187 occupants. Similarly, if the entry is of object class group, where 2188 the groupMember attribute is used. 2190 24 Access Units 2192 Attributes needed for support of Access Units, as defined in 2193 X.400(88), are defined in Figure 18. 2195 The attributes defined are: 2197 localAccessUnit This defines the list of access units supported by 2198 the MTA. 2200 accessUnitsUsed This defines which access units are used by the MTA, 2201 giving the type and MTA. An O/R Address filter is provided to 2202 control which access unit is used for a given recipient. For a 2203 filter to match an address, all attributes specificed in the 2204 filter shall match the given address. This is specified as an O/R 2205 Address, so that routing to access units can be filtered on the 2206 basis of attributes not mapped onto the directory (e.g., postal 2207 attributes). Where a remote MTA is used, it may be necessary to 2208 use source routing. 2210 Editor's Note 1: This mechanism might be used to replace the 2211 routefilter mechanism of the MTS routing. Comments are solicited. 2213 Editor's Note 2: It has been proposed to add a more powerful filter 2214 mechanism. Comments are solicited. 2216 Editor's Note 3: The utility of this specification as a mechanism to 2217 route faxes and other non MHS messages has been noted, but not 2218 explored. Comments as to how and if this should be developed are 2219 solicited. 2221 These three issues are for further study. 2223 INTERNET--DRAFT MHS Routing using Directory June 1994 2225 25 The Overall Routing Algorithm 2227 Having provided all the pieces, a summary of how routing works can be 2228 given. 2229 The core of the X.400 routing is described in Section 10. A sequence 2230 of routing trees are followed. As nodes of the routing tree are 2231 matched, a set of MTAs will be identified for evaluation as possible 2232 next hops. If all of these are rejected, the trees are followed 2233 further2. A set of MTAs is evaluated on the following criteria: 2235 o If an MTA is the local MTA, deliver locally. 2237 o Supported protocols. The MTA shall support a protocol that the 2238 current MTA supports3, as described in Section 18.2. 2240 o The protocols shall share a common transport community, as 2241 described in Section 18.1. 2243 o There shall be no capability restrictions in the MTA which 2244 prevents transfer of the current message, as described in 2245 Section 18.3. 2247 o There shall be no policy restrictions in the MTA which prevents 2248 transfer of the current message, as described in Section 21. 2250 o The authentication requirements of the MTA shall be met by the 2251 local MTA, as described in Section 20.2. 2253 o If the authentication (Section 20.2) indicates that a bilateral 2254 agreement is present, the MTA shall be listed in the local set of 2255 bilateral agreements, as described in Section 17. 2257 o In cases where the recipient UA's capabilities can be determined, 2258 there should either be no mismatch, or there shall be an ability 2259 to use local or remote reformatting capabilities, as described 2261 ---------------------------- 2262 2. It might be argued that the trees should be followed to find 2263 alternate routes in the case that only one MTA is acceptable. This is 2264 not proposed. 2265 3. Note that this could be an RFC 822 protocol, as well as an 2266 X.400 protocol. 2268 INTERNET--DRAFT MHS Routing using Directory June 1994 2270 in[11]. 2272 26 Performance 2274 The routing algorithm has beed designed with performance in mind. In 2275 particular, care has been taken to use only the read function, which 2276 will in general be optimised. Routing trees may be configured so that 2277 routing decisions can be made with only two directory reads. More 2278 complex configurations will not require a substantially larger number 2279 of operations. 2281 27 Acknowledgements 2283 This INTERNET--DRAFT is the central document of a series of 2284 specifications [13, 14, 16, 18, 12, 15, 11]. The acknowledgements for 2285 all of this work is given here. Previous work, which significantly 2286 influenced these specifications is described in Section 3. This lead 2287 to an initial proposal by the editor, which was subsequently split 2288 into eight documents. 2290 Work on this specifications has been done by the IETF MHS-DS working 2291 group. Special credit is given to the joint chairs of this group: 2292 Harald Alvestrand (Uninett) and Kevin Jordan (CDC). Credit is given to 2293 all members of the WG. Those who have made active contribution 2294 include: Piete Brooks (Cambridge University); Allan Cargille 2295 (University of Wisconsin); Jim Craigie (JNT); Dennis Doyle (SSS); Urs 2296 Eppenberger (SWITCH); Peter Furniss; Christian Huitema (Inria); Marko 2297 Kaittola (Dante); Sylvain Langlois (EDF); Lucy Loftin (AT&T GIS); 2298 Julian Onions (NEXOR); Paul-Andre Pays (Inria); Colin Robbins (NEXOR); 2299 Michael Roe (Cambridge University); Jim Romaguera (Netconsult); 2300 Michael Storz (Leibniz Rechenzentrum); Mark Wahl (ISODE Consortium); 2301 Alan Young (ISODE Consortium). 2302 This work was partly funded by the COSINE Paradise project. 2304 References 2306 [1] The Directory --- overview of concepts, models and services, 2307 1993. CCITT X.500 Series Recommendations. 2309 [2] J.N. Chiappa. A new IP routing and addressing architecture, 2311 INTERNET--DRAFT MHS Routing using Directory June 1994 2313 1991. 2315 [3] A. Consael, M. Tschicholz, O. Wenzel, K. Bonacker, and M. Busch. 2316 DFN-Directory nutzung durch MHS, April 1990. GMD Report. 2318 [4] P. Dick-Lauder, R.J. Kummerfeld, and K.R. Elz. ACSNet - the 2319 Australian alternative to UUCP. In EUUG Conference, Paris, pages 2320 60--69, April 1985. 2322 [5] U. Eppenberger. Routing coordination for an X.400 MHS service 2323 within a multi protocol / multinetwork environment. RFC 1465. 2325 [6] K.E. Jordan. Using X.500 directory services in support of X.400 2326 routing and address mapping, November 1991. Private Note. 2328 [7] S.E. Kille. MHS use of directory service for routing. In IFIP 2329 6.5 Conference on Message Handling, Munich, pages 157--164. 2330 North Holland Publishing, April 1987. 2332 [8] S.E. Kille. Topology and routing for MHS. COSINE Specification 2333 Phase 7.7, RARE, 1988. 2335 [9] S.E. Kille. Encoding network addresses to support operation over 2336 non-OSI lower layers. Request for Comments RFC 1277, Department 2337 of Computer Science, University College London, November 1991. 2339 [10] S.E. Kille. A string representation of distinguished name. 2340 Request for Comments in preparation, Department of Computer 2341 Science, University College London, January 1992. 2343 [11] S.E. Kille. Mhs use of directory to support mhs content 2344 conversion, July 1993. Internet Draft. 2346 [12] S.E. Kille. Use of the directory to support routing for RFC 822 2347 and related protocols, July 1993. Internet Draft. 2349 [13] S.E. Kille. Representing tables and subtrees in the directory, 2350 June 1994. Internet Draft. 2352 [14] S.E. Kille. Representing the O/R Address hierarchy in the 2353 directory information tree, June 1994. Internet Draft. 2355 [15] S.E. Kille. A simple profile for MHS use of directory, March 2356 1994. Internet Draft. 2358 INTERNET--DRAFT MHS Routing using Directory June 1994 2360 [16] S.E. Kille. Use of the directory to support mapping between 2361 X.400 and RFC 822 addresses, June 1994. Internet Draft. 2363 [17] S.E. Kille and J.P. Onions. The PP manual, December 1991. 2364 Version 6.0. 2366 [18] S.E. Kille and C.J. Robbins. MHS use of the directory to support 2367 distribution lists, March 1994. Internet Draft. 2369 [19] P. Lauder, R.J. Kummerfeld, and A. Fekete. Hierarchical network 2370 routing. In Tricomm 91, 1991. 2372 [20] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT 2373 SG 5/VII / ISO/IEC JTC1, Message Handling: System and Service 2374 Overview. 2376 [21] Zen and the ART of navigating through the dark and murky regions 2377 of the message transfer system: Working document on MTS 2378 routing, September 1991. ISO SC 18 SWG Messaging. 2380 28 Security Considerations 2382 Security considerations are not discussed in this INTERNET--DRAFT. 2384 29 Author's Address 2386 Steve Kille 2387 ISODE Consortium 2388 The Dome 2389 The Square 2390 Richmond 2391 TW9 1DT 2392 England 2394 Phone: +44-81-332-9091 2396 Internet EMail: S.Kille@ISODE.COM 2398 X.400: I=S; S=Kille; O=ISODE Consortium; P=ISODE; 2399 A=Mailnet; C=FI; 2401 INTERNET--DRAFT MHS Routing using Directory June 1994 2403 DN: CN=Steve Kille, 2404 O=ISODE Consortium, C=GB 2406 UFN: S. Kille, ISODE Consortium, GB 2408 INTERNET--DRAFT MHS Routing using Directory June 1994 2410 A Object Identifier Assignment 2412 _______________________________________________________________________ 2413 mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4) 2414 enterprises(1) isode-consortium (453) mhs-ds (7)} 2416 routing OBJECT IDENTIFIER ::= {mhs-ds 3} 2418 oc OBJECT IDENTIFIER ::= {routing 1} 2419 at OBJECT IDENTIFIER ::= {routing 2} 2420 id OBJECT IDENTIFIER ::= {routing 3} 2422 10 2423 oc-mta OBJECT IDENTIFIER ::= {oc 1} 2424 oc-mta-bilateral-table-entry OBJECT IDENTIFIER ::= {oc 2} 2425 oc-routing-information OBJECT IDENTIFIER ::= {oc 3} 2426 oc-restricted-subtree OBJECT IDENTIFIER ::= {oc 4} 2427 oc-routed-ua OBJECT IDENTIFIER ::= {oc 5} 2428 oc-routing-tree-root OBJECT IDENTIFIER ::= {oc 6} 2429 oc-mta-application-process OBJECT IDENTIFIER ::= {oc 7} 2431 at-access-md OBJECT IDENTIFIER ::= {at 1} 2432 at-access-units-used OBJECT IDENTIFIER ::= {at 2} 20 2433 at-subtree-information OBJECT IDENTIFIER ::= {at 3} 2434 at-bad-address-search-attributes OBJECT IDENTIFIER ::= {at 4} 2435 at-bad-address-search-point OBJECT IDENTIFIER ::= {at 5} 2437 at-calling-selector-validity OBJECT IDENTIFIER ::= {at 7} 2439 at-filtered-redirect OBJECT IDENTIFIER ::= {at 38} 2440 at-global-domain-id OBJECT IDENTIFIER ::= {at 10} 2441 at-initiating-rts-credentials OBJECT IDENTIFIER ::= {at 11} 2442 at-initiator-authentication-requirements OBJECT IDENTIFIER ::= {at 12}30 2443 at-initiator-p1-mode OBJECT IDENTIFIER ::= {at 13} 2444 at-initiator-pulling-authentication-requirements OBJECT IDENTIFIER ::= {at 14} 2445 at-local-access-unit OBJECT IDENTIFIER ::= {at 15} 2446 at-mandatory-redirect OBJECT IDENTIFIER ::= {at 16} 2447 at-mta-info OBJECT IDENTIFIER ::= {at 40} 2448 at-mta-name OBJECT IDENTIFIER ::= {at 19} 2450 at-mta-will-route OBJECT IDENTIFIER ::= {at 21} 2451 at-calling-presentation-address OBJECT IDENTIFIER ::= {at 22} 2452 INTERNET--DRAFT MHS Routing using Directory June 1994 2454 at-responder-authentication-requirements OBJECT IDENTIFIER ::= {at 23}40 2455 at-responder-p1-mode OBJECT IDENTIFIER ::= {at 24} 2456 at-responder-pulling-authentication-requirements OBJECT IDENTIFIER ::= {at 25} 2457 at-responding-rts-credentials OBJECT IDENTIFIER ::= {at 26} 2458 at-routing-failure-action OBJECT IDENTIFIER ::= {at 27} 2459 at-routing-filter OBJECT IDENTIFIER ::= {at 28} 2460 at-routing-tree-list OBJECT IDENTIFIER ::= {at 29} 2461 at-subtree-deliverable-content-length OBJECT IDENTIFIER ::= {at 30} 2462 at-subtree-deliverable-content-types OBJECT IDENTIFIER ::= {at 31} 2463 at-subtree-deliverable-eits OBJECT IDENTIFIER ::= {at 32} 2464 at-supporting-mta OBJECT IDENTIFIER ::= {at 33} 50 2465 at-transport-community OBJECT IDENTIFIER ::= {at 34} 2466 at-user-name OBJECT IDENTIFIER ::= {at 35} 2467 at-non-delivery-info OBJECT IDENTIFIER ::= {at 36} 2468 at-polled-mtas OBJECT IDENTIFIER ::= {at 37} 2469 at-bilateral-table OBJECT IDENTIFIER {at 41} 2470 at-supported-extension OBJECT IDENTIFIER {at 42} 2471 at-supported-mts-extension OBJECT IDENTIFIER {at 43} 2472 at-mtas-allowed-to-poll OBJECT IDENTIFIER {at 44} 2474 id-alternative-address-information OBJECT IDENTIFIER ::= {id 1} 60 2476 _______________Figure_19:__Object_Identifier_Assignment________________ 2477 INTERNET--DRAFT MHS Routing using Directory June 1994 2479 B Community Identifier Assignments 2480 INTERNET--DRAFT MHS Routing using Directory June 1994 2482 C Protocol Identifier Assignments 2483 INTERNET--DRAFT MHS Routing using Directory June 1994 2485 D ASN.1 Summary 2486 _______________________________________________________________________ 2487 MHS-DS-Definitions 2488 DEFINITIONS ::= 2489 BEGIN 2491 -- assign OID to module 2492 -- define imports and exports 2494 routingTreeRoot OBJECT-CLASS ::= { 2495 SUBCLASS OF {routingInformation|subtree} 2496 ID oc-routing-tree-root} 10 2498 routingTreeList ATTRIBUTE ::= { 2499 WITH SYNTAX RoutingTreeList 2500 SINGLE VALUE 2501 ID at-routing-tree-list} 2503 RoutingTreeList ::= SEQUENCE OF RoutingTreeName 2505 RoutingTreeName ::= DistinguishedName 2506 20 2507 routingInformation OBJECT-CLASS ::= { 2508 SUBCLASS OF top 2509 MAY CONTAIN { 2510 subtreeInformation| 2511 routingFilter| 2512 routingFailureAction| 2513 mTAInfo| 2514 accessMD| 2515 nonDeliveryInfo| 2516 badAddressSearchPoint| 30 2517 badAddressSearchAttributes} 2518 ID oc-routing-information} 2519 -- No naming attributes as this is not a 2520 -- structural object class 2522 subtreeInformation ATTRIBUTE ::= { 2523 WITH SYNTAX SubtreeInfo 2524 SINGLE VALUE 40 2525 ID at-subtree-information} 2527 INTERNET--DRAFT MHS Routing using Directory June 1994 2529 SubtreeInfo ::= ENUMERATED { 2530 all-children-present(0), 2531 not-all-children-present(1) } 2533 routingFilter ATTRIBUTE ::= { 2534 WITH SYNTAX RoutingFilter 2535 ID at-routing-filter} 50 2537 RoutingFilter ::= SEQUENCE{ 2538 attribute-type OBJECT-IDENTIFIER, 2539 weight RouteWeight, 2540 dda-key String OPTIONAL, 2541 regex-match IA5String OPTIONAL, 2542 node DistinguishedName } 2544 String ::= CHOICE {PrintableString, TeletexString} 60 2546 routingFailureAction ATTRIBUTE ::= { 2547 WITH SYNTAX RoutingFailureAction 2548 SINGLE VALUE 2549 ID at-routing-failure-action} 2551 RoutingFailureAction ::= ENUMERATED { 2552 next-level(0), 2553 next-tree-only(1), 2554 next-tree-first(2), 70 2555 stop(3) } 2557 mTAInfo ATTRIBUTE ::= { 2558 WITH SYNTAX MTAInfo 2559 ID at-mta-info} 2561 MTAInfo ::= SEQUENCE { 2562 name DistinguishedName, 2563 weight [1] RouteWeight DEFAULT preferred-access, 80 2564 mta-attributes [2] SET OF Attribute OPTIONAL, 2565 ae-info SEQUENCE OF SEQUENCE { 2566 aEQualifier PrintableString, 2567 ae-weight RouteWeight DEFAULT preferred-access, 2568 ae-attributes SET OF Attribute OPTIONAL} OPTIONAL 2570 INTERNET--DRAFT MHS Routing using Directory June 1994 2572 } 2574 RouteWeight ::= INTEGER {endpoint(0), 2575 preferred-access(5), 2576 backup(10)} (0..20) 90 2578 accessMD ATTRIBUTE ::= { 2579 SUBTYPE OF distinguishedName 2580 ID at-access-md} 2582 routedUA OBJECT-CLASS ::= { 2583 SUBCLASS OF {routingInformation} 2584 MAY CONTAIN { 2585 -- from X.402 2586 mhs-deliverable-content-length| 100 2587 mhs-deliverable-content-types| 2588 mhs-deliverable-eits| 2589 mhs-message-store| 2590 mhs-preferred-delivery-methods| 2591 -- defined here 2592 supportedExtensions| 2593 mandatoryRedirect| 2594 supportingMTA| 2595 filteredRedirect| 2596 userName| 110 2597 nonDeliveryInfo} 2598 ID oc-routed-ua} 2600 supportedExtensions ATTRIBUTE ::= { 2601 SUBTYPE OF objectIdentifier 2602 ID at-supported-extensions} 2604 supportingMTA ATTRIBUTE ::= { 2605 SUBTYPE OF mtaInfo 2606 ID at-supporting-mta} 120 2608 userName ATTRIBUTE ::= { 2609 SUBTYPE OF distinguishedName 2610 ID at-user-name} 2612 mTAName ATTRIBUTE ::= { 2613 SUBTYPE OF name 2614 WITH SYNTAX DirectoryString{ub-mta-name-length} 2615 SINGLE VALUE 2617 INTERNET--DRAFT MHS Routing using Directory June 1994 2619 ID at-mta-name} 130 2620 -- used for naming when 2621 -- MTA is named in O=R Address Hierarchy 2623 globalDomainID ATTRIBUTE ::= { 2624 WITH SYNTAX GlobalDomainIdentifier 2625 SINGLE VALUE 2626 ID at-global-domain-id} 2627 -- both attributes present when MTA 2628 -- is named outside O=R Address Hierarchy 2629 -- to enable trace to be written 140 2631 mTAApplicationProcess OBJECT CLASS ::= { 2632 SUBCLASS OF {application-process} 2633 MAY CONTAIN { 2634 mTAWillRoute| 2635 globalDomainID| 2636 routingTreeList| 2637 accessMD| 2638 localAccessUnit| 2639 accessUnitsUsed 150 2640 } 2641 ID oc-mta-application-process} 2643 mTA OBJECT CLASS ::= { -- Application Entity 2644 SUBCLASS OF {mhs-message-transfer-agent} 2645 MAY CONTAIN { 2646 mTAName| 2647 globalDomainID| -- per AE variant 2648 responderAuthenticationRequirements| 2649 initiatorAuthenticationRequirements| 160 2650 responderPullingAuthenticationRequirements| 2651 initiatorPullingAuthenticationRequirements| 2652 initiatorP1Mode| 2653 responderP1Mode| 2654 polledMTAs| 2655 protocolInformation| 2656 respondingRTSCredentials| 2657 initiatingRTSCredentials| 2658 callingPresentationAddress| 2659 callingSelectorValidity| 170 2660 bilateralTable| 2661 mTAWillRoute| 2662 mhs-deliverable-content-length| 2664 INTERNET--DRAFT MHS Routing using Directory June 1994 2666 routingTreeList| 2667 supportedMTSExtensions| 2668 mTAsAllowedToPoll 2669 } 2670 ID oc-mta} 2672 mTABilateralTableEntry OBJECT-CLASS ::= 180 2673 SUBCLASS OF {mTA| distinguishedNameTableEntry} 2674 ID oc-mta-bilateral-table-entry} 2676 bilateralTable ATTRIBUTE ::= { 2677 WITH SYNTAX SEQUENCE OF DistinguishedName 2678 SINGLE VALUE 2679 ID at-bilateral-table} 2681 supportedMTSExtensions ATTRIBUTE ::= { 2682 SUBTYPE OF objectIdentifier 190 2683 ID at-supported-mts-extensions} 2685 restrictedSubtree OBJECT-CLASS ::= { 2686 SUBCLASS OF {top} 2687 MAY CONTAIN { 2688 subtreeDeliverableContentLength| 2689 subtreeDeliverableContentTypes| 2690 subtreeDeliverableEITs} 2691 ID oc-restricted-subtree} 2692 200 2693 subtreeDeliverableContentLength ATTRIBUTE ::= { 2694 SUBTYPE OF mhs-deliverable-content-length 2695 ID at-subtree-deliverable-content-length} 2697 subtreeDeliverableContentTypes ATTRIBUTE ::= { 2698 SUBTYPE OF mhs-deliverable-content-types 2699 ID at-subtree-deliverable-content-types} 2701 subtreeDeliverableEITs ATTRIBUTE ::= { 2702 SUBTYPE OF mhs-deliverable-eits 210 2703 ID at-subtree-deliverable-eits} 2705 initiatorP1Mode ATTRIBUTE ::= { 2706 WITH SYNTAX P1Mode 2707 SINGLE VALUE 2708 ID at-initiator-p1-mode} 2710 INTERNET--DRAFT MHS Routing using Directory June 1994 2712 responderP1Mode ATTRIBUTE ::= { 2713 WITH SYNTAX P1Mode 220 2714 SINGLE VALUE 2715 ID at-responder-p1-mode} 2717 P1Mode ::= ENUMERATED { 2718 push-only(0), 2719 pull-only(1), 2720 twa(2) } 2722 polledMTAs ATTRIBUTE ::= { 2723 WITH SYNTAX PolledMTAs 230 2724 ID at-polled-mtas} 2726 PolledMTAs ::= SEQUENCE { 2727 mta DistinguishedName, 2728 poll-frequency INTEGER OPTIONAL --frequency in minutes 2729 } 2731 mTAsAllowedToPoll ATTRIBUTE ::= { 2732 SUBTYPE OF distinguishedName 2733 ID at-mtas-allowed-to-poll} 240 2735 responderAuthenticationRequirements ATTRIBUTE ::= { 2736 WITH SYNTAX AuthenticationRequirements 2737 SINGLE VALUE 2738 ID at-responder-authentication-requirements} 2740 initiatorAuthenticationRequirements ATTRIBUTE ::= { 2741 WITH SYNTAX AuthenticationRequirements 2742 SINGLE VALUE 250 2743 ID at-initiator-authentication-requirements} 2745 repsonderPullingAuthenticationRequirements ATTRIBUTE ::= { 2746 WITH SYNTAX AuthenticationRequirements 2747 SINGLE VALUE 2748 ID at-responder-pulling-authentication-requirements} 2750 initiatorPullingAuthenticationRequirements ATTRIBUTE ::= { 2751 WITH SYNTAX AuthenticationRequirements 2752 SINGLE VALUE 260 2753 ID at-initiator-pulling-authentication-requirements} 2755 INTERNET--DRAFT MHS Routing using Directory June 1994 2757 AuthenticationRequirements ::= BITSTRING { 2758 mta-name-present(0), 2759 aet-present(1), 2760 aet-valid(2), 2761 network-address(3), 2762 simple-authentication(4), 2763 strong-authentication(5), 2764 bilateral-agreement-needed(6)} 270 2766 respondingRTSCredentials ATTRIBUTE ::= { 2767 WITH SYNTAX RTSCredentials 2768 SINGLE VALUE 2769 ID at-responding-rts-credentials} 2771 initiatingRTSCredentials ATTRIBUTE ::= { 2772 WITH SYNTAX RTSCredentials 2773 SINGLE VALUE 280 2774 ID at-initiating-rts-credentials} 2776 RTSCredentials ::= SEQUENCE { 2777 request [0] MTAandPassword OPTIONAL, 2778 response [1] MTAandPassword OPTIONAL } 2780 MTAandPassword ::= SEQUENCE { 2781 MTAName, 290 2782 Password } -- MTAName and Password 2783 -- from X.411 2785 callingPresentationAddress ATTRIBUTE ::= { 2786 SUBTYPE OF presentationAddress 2787 MULTI VALUE 2788 ID at-calling-presentation-address} 2790 callingSelectorValidity ATTRIBUTE ::= { 300 2791 WITH SYNTAX CallingSelectorValidity 2792 SINGLE VALUE 2793 ID at-calling-selector-validity} 2795 CallingSelectorValidity ::= ENUMERATED { 2796 INTERNET--DRAFT MHS Routing using Directory June 1994 2798 all-selectors-fixed(0), 2799 tsel-may-vary(1), 2800 all-selectors-may-vary(2) } 2802 mTAWillRoute ATTRIBUTE ::= { 310 2803 WITH SYNTAX MTAWillRoute 2804 ID at-mta-will-route} 2806 MTAWillRoute ::= SEQUENCE { 2807 from [0] SET OF ORAddressPrefix OPTIONAL, 2808 to [1] SET OF ORAddressPrefix OPTIONAL, 2809 from-excludes [2] SET OF ORAddressPrefix OPTIONAL, 2810 to-excludes [3] SET OF ORAddressPrefix OPTIONAL } 2812 ORAddressPrefix ::= DistinguishedName 320 2814 mandatoryRedirect ATTRIBUTE ::= { 2815 SUBTYPE OF distinguishedName 2816 SINGLE VALUE 2817 ID at-mandatory-redirect} 2819 filteredRedirect ATTRIBUTE ::= { 2820 WITH SYNTAX FilteredRedirect 2821 SINGLE VALUE 2822 ID at-filtered-redirect} 330 2824 FilteredRedirect ::= SEQUENCE { 2825 redirect-to DistinguishedName, 2826 SEQUENCE { 2827 min-size [1] INTEGER, 2828 max-size [2] INTEGER, 2829 content [3] ContentType, 2830 eit [4] ExternalEncodedInformationType } 2831 } 2832 340 2834 nonDeliveryInfo ATTRIBUTE ::= { 2835 WITH SYNTAX NonDeliveryReason 2836 ID at-non-delivery-info} 2838 NonDeliveryReason ::= SEQUENCE { 2839 reason INTEGER (0..ub-reason-codes), 2841 INTERNET--DRAFT MHS Routing using Directory June 1994 2843 diagnostic INTEGER (0..ub-diagnostic-codes), 350 2844 supplementaryInfo PrintableString } 2846 badAddressSearchPoint ATTRIBUTE ::= { 2847 SUBTYPE OF distinguishedName 2848 ID at-bad-address-search-point} 2850 badAddressSearchAttributes ATTRIBUTE ::= { 2851 WITH SYNTAX AttributeType 2852 ID at-bad-address-search-attributes} 2853 360 2854 alternativeAddressInformation EXTENSION 2855 AlternativeAddressInformation 2856 ::= id-alternative-address-information 2857 -- X.400(92) continues to use MACRO notation 2859 AlternativeAddressInformation ::= SET OF SEQUENCE { 2860 distinguished-name DistinguishedName OPTIONAL, 2861 or-address ORAddress OPTIONAL, 2862 other-useful-info SET OF Attribute } 2863 370 2864 localAccessUnit ATTRIBUTE ::= { 2865 WITH SYNTAX AccessUnitType 2866 ID at-local-access-unit} 2868 AccessUnitType ::= ENUMERATED { 2869 fax (1), 2870 physical-delivery (2), 2871 teletex (3), 2872 telex (4) } 2873 380 2874 accessUnitsUsed ATTRIBUTE ::= { 2875 WITH SYNTAX SelectedAccessUnit 2876 ID at-access-units-used} 2878 SelectedAccessUnit ::= SEQUENCE { 2879 type AccessUnitType, 2880 providing-MTA DistinguishedName, 2881 filter SET OF ORAddress OPTIONAL } 2882 mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4) 2883 enterprises(1) isode-consortium (453) mhs-ds (7)} 390 2885 routing OBJECT IDENTIFIER ::= {mhs-ds 3} 2886 INTERNET--DRAFT MHS Routing using Directory June 1994 2888 oc OBJECT IDENTIFIER ::= {routing 1} 2889 at OBJECT IDENTIFIER ::= {routing 2} 2890 id OBJECT IDENTIFIER ::= {routing 3} 2892 oc-mta OBJECT IDENTIFIER ::= {oc 1} 2893 oc-mta-bilateral-table-entry OBJECT IDENTIFIER ::= {oc 2} 400 2894 oc-routing-information OBJECT IDENTIFIER ::= {oc 3} 2895 oc-restricted-subtree OBJECT IDENTIFIER ::= {oc 4} 2896 oc-routed-ua OBJECT IDENTIFIER ::= {oc 5} 2897 oc-routing-tree-root OBJECT IDENTIFIER ::= {oc 6} 2898 oc-mta-application-process OBJECT IDENTIFIER ::= {oc 7} 2900 at-access-md OBJECT IDENTIFIER ::= {at 1} 2901 at-access-units-used OBJECT IDENTIFIER ::= {at 2} 2902 at-subtree-information OBJECT IDENTIFIER ::= {at 3} 2903 at-bad-address-search-attributes OBJECT IDENTIFIER ::= {at 4} 410 2904 at-bad-address-search-point OBJECT IDENTIFIER ::= {at 5} 2906 at-calling-selector-validity OBJECT IDENTIFIER ::= {at 7} 2908 at-filtered-redirect OBJECT IDENTIFIER ::= {at 38} 2909 at-global-domain-id OBJECT IDENTIFIER ::= {at 10} 2910 at-initiating-rts-credentials OBJECT IDENTIFIER ::= {at 11} 2911 at-initiator-authentication-requirements OBJECT IDENTIFIER ::= {at 12} 2912 at-initiator-p1-mode OBJECT IDENTIFIER ::= {at 13} 2913 at-initiator-pulling-authentication-requirements OBJECT IDENTIFIER ::=4{at214}0 2914 at-local-access-unit OBJECT IDENTIFIER ::= {at 15} 2915 at-mandatory-redirect OBJECT IDENTIFIER ::= {at 16} 2916 at-mta-info OBJECT IDENTIFIER ::= {at 40} 2917 at-mta-name OBJECT IDENTIFIER ::= {at 19} 2919 at-mta-will-route OBJECT IDENTIFIER ::= {at 21} 2920 at-calling-presentation-address OBJECT IDENTIFIER ::= {at 22} 2921 at-responder-authentication-requirements OBJECT IDENTIFIER ::= {at 23} 2922 at-responder-p1-mode OBJECT IDENTIFIER ::= {at 24} 2923 at-responder-pulling-authentication-requirements OBJECT IDENTIFIER ::=4{at325}0 2924 at-responding-rts-credentials OBJECT IDENTIFIER ::= {at 26} 2925 at-routing-failure-action OBJECT IDENTIFIER ::= {at 27} 2926 at-routing-filter OBJECT IDENTIFIER ::= {at 28} 2927 at-routing-tree-list OBJECT IDENTIFIER ::= {at 29} 2928 at-subtree-deliverable-content-length OBJECT IDENTIFIER ::= {at 30} 2929 at-subtree-deliverable-content-types OBJECT IDENTIFIER ::= {at 31} 2930 at-subtree-deliverable-eits OBJECT IDENTIFIER ::= {at 32} 2931 INTERNET--DRAFT MHS Routing using Directory June 1994 2933 at-supporting-mta OBJECT IDENTIFIER ::= {at 33} 2934 at-transport-community OBJECT IDENTIFIER ::= {at 34} 2935 at-user-name OBJECT IDENTIFIER ::= {at 35} 440 2936 at-non-delivery-info OBJECT IDENTIFIER ::= {at 36} 2937 at-polled-mtas OBJECT IDENTIFIER ::= {at 37} 2938 at-bilateral-table OBJECT IDENTIFIER {at 41} 2939 at-supported-extension OBJECT IDENTIFIER {at 42} 2940 at-supported-mts-extension OBJECT IDENTIFIER {at 43} 2941 at-mtas-allowed-to-poll OBJECT IDENTIFIER {at 44} 2943 id-alternative-address-information OBJECT IDENTIFIER ::= {id 1} 2945 ts-communities OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)4private(4)50 2946 enterprises(1) isode-consortium (453) ts-communities (4)} 2948 tc-cons OBJECT IDENTIFIER ::= {ts-communities 1} -- OSI CONS 2949 tc-clns OBJECT IDENTIFIER ::= {ts-communities 2} -- OSI CLNS 2950 tc-internet OBJECT IDENTIFIER ::= {ts-communities 3} -- Internet + RFC 1006 2951 tc-int-x25 OBJECT IDENTIFIER ::= {ts-communities 4} -- International X.25 2952 -- Without CONS 2953 tc-ixi OBJECT IDENTIFIER ::= {ts-communities 5} -- IXI (Europe) 2954 tc-janet OBJECT IDENTIFIER ::= {ts-communities 6} -- Janet (UK)460 2956 mail-protocol OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4) 2957 enterprises(1) isode-consortium (453) mail-protocol (5)} 2959 ac-p1-1984 OBJECT IDENTIFIER ::= {mail-protocol 1} -- p1(1984) 2960 ac-smtp OBJECT IDENTIFIER ::= {mail-protocol 2} -- SMTP 2961 ac-uucp OBJECT IDENTIFIER ::= {mail-protocol 3} -- UUCP Mail 2962 ac-jnt-mail OBJECT IDENTIFIER ::= {mail-protocol 4} -- JNT Mail (UK) 2963 ac-p1-1988-x410 OBJECT IDENTIFIER ::= {mail-protocol 5} -- p1(1988) in X.410 mode 2964 ac-p3-1984 OBJECT IDENTIFIER ::= {mail-protocol 6} -- p3(1984)470 2965 END 2967 ______________________Figure_22:__ASN.1_Summary________________________ 2968 INTERNET--DRAFT MHS Routing using Directory June 1994 2970 E Regular Expression Syntax 2972 This appendix defines a form of regular expression for pattern 2973 matching. This pattern matching is derived from the UNIX ed(1) 2974 command. The matching is modified to be case insensitive. 2976 A regular expression (RE) specifies a set of character strings to 2977 match against - such as ``any string containing digits 5 through 9''. 2978 A member of this set of strings is said to be matched by the regular 2979 expression. 2981 Where multiple matches are present in a line, a regular 2982 expression matches the longest of the leftmost matching 2983 strings. 2985 Regular expressions can be built up from the following 2986 ``single-character'' RE's: 2988 c Any ordinary character not listed below. An ordinary 2989 character matches itself. 2991 \ Backslash. When followed by a special character, the 2992 RE matches the "quoted" character. A backslash fol- 2993 lowed by one of ( or ) represents an 2994 operator in a regular expression, as described below. 2996 . Dot. Matches any single character. 2998 ^ As the leftmost character, a caret (or circumflex) con- 2999 strains the RE to match the leftmost portion of a string. 3000 A match of this type is called an "anchored match" 3001 because it is "anchored" to a specific place in the 3002 string. The ^ character loses its special meaning if it 3003 appears in any position other than the start of the RE. 3005 $ As the rightmost character, a dollar sign constrains 3006 the RE to match the rightmost portion of a string. The $ 3007 character loses its special meaning if it appears in 3008 any position other than at the end of the RE. 3010 ^RE$ The construction ^RE$ constrains the RE to match the 3012 INTERNET--DRAFT MHS Routing using Directory June 1994 3014 entire string. 3016 [c...] 3017 A nonempty string of characters, enclosed in square 3018 brackets matches any single character in the string. 3019 For example, [abcxyz] matches any single character from 3020 the set `abcxyz'. When the first character of the 3021 string is a caret (^), then the RE matches any charac- 3022 ter except those in the remainder of the string. For 3023 example, `[^45678]' matches any character except `45678'. 3024 A caret in any other position is interpreted as an 3025 ordinary character. 3027 []c...] 3028 The right square bracket does not terminate the 3029 enclosed string if it is the first character (after an 3030 initial `^', if any), in the bracketed string. In this 3031 position it is treated as an ordinary character. 3033 [l-r] 3034 The minus sign, between two characters, indicates a 3035 range of consecutive ASCII characters to match. For 3036 example, the range `[0-9]' is equivalent to the string 3037 `[0123456789]'. Such a bracketed string of characters 3038 is known as a character class. The `-' is treated as 3039 an ordinary character if it occurs first (or first 3040 after an initial ^) or last in the string. 3042 The following rules and special characters allow for con- 3043 structing RE's from single-character RE's: 3045 A concatenation of RE's matches a concatenation of text 3046 strings, each of which is a match for a successive RE 3047 in the search pattern. 3049 * A single-character RE, followed by an asterisk (*) 3050 matches zero or more occurrences of the single- 3051 character RE. Such a pattern is called a closure. For 3052 example, [a-z][a-z]* matches any string of one or more 3053 lower case letters. 3055 \(...\) 3056 An RE enclosed between the character sequences \( and 3057 \) matches whatever the unadorned RE matches, but saves 3059 INTERNET--DRAFT MHS Routing using Directory June 1994 3061 the string matched by the enclosed RE in a numbered 3062 substring register. There can be up to nine such sub- 3063 strings in an RE, and parenthesis operators can be 3064 nested. 3066 \n Match the contents of the nth substring register from 3067 the current RE. This provides a mechanism for extract- 3068 ing matched substrings. For example, the expression 3069 ^\(..*\)\1$ matches a string consisting entirely of two 3070 adjacent non-null appearances of the same string. When 3071 nested parenthesized substrings are present, n is 3072 determined by counting occurrences of \( starting from 3073 the left. 3075 E.1 Pseudo Code 3077 This section describes the routing algorithm in pseudo-code and gives 3078 examples of its use. 3079 To be supplied. 3081 INTERNET--DRAFT MHS Routing using Directory June 1994 3083 _______________________________________________________________________ 3085 routedUA OBJECT-CLASS ::= { 3086 SUBCLASS OF {routingInformation} 3087 MAY CONTAIN { 3088 -- from X.402 3089 mhs-deliverable-content-length| 3090 mhs-deliverable-content-types| 3091 mhs-deliverable-eits| 3092 mhs-message-store| 3093 mhs-preferred-delivery-methods| 10 3094 -- defined here 3095 supportedExtensions| 3096 mandatoryRedirect| 3097 supportingMTA| 3098 filteredRedirect| 3099 userName| 3100 nonDeliveryInfo} 3101 ID oc-routed-ua} 3103 supportedExtensions ATTRIBUTE ::= { 20 3104 SUBTYPE OF objectIdentifier 3105 ID at-supported-extensions} 3107 supportingMTA ATTRIBUTE ::= { 3108 SUBTYPE OF mtaInfo 3109 ID at-supporting-mta} 3111 userName ATTRIBUTE ::= { 3112 SUBTYPE OF distinguishedName 3113 ID at-user-name} 30 3115 _______________________Figure_5:__UA_Attributes________________________ 3117 _______________________________________________________________________ 3119 mTABilateralTableEntry OBJECT-CLASS ::= 3120 SUBCLASS OF {mTA| distinguishedNameTableEntry} 3121 ID oc-mta-bilateral-table-entry} 3123 _________________Figure_7:__MTA_Bilateral_Table_Entry__________________ 3124 INTERNET--DRAFT MHS Routing using Directory June 1994 3126 _______________________________________________________________________ 3128 bilateralTable ATTRIBUTE ::= { 3129 WITH SYNTAX SEQUENCE OF DistinguishedName 3130 SINGLE VALUE 3131 ID at-bilateral-table} 3133 _________________Figure_8:__Bilateral_Table_Attribute__________________ 3135 _______________________________________________________________________ 3137 supportedMTSExtensions ATTRIBUTE ::= { 3138 SUBTYPE OF objectIdentifier 3139 ID at-supported-mts-extensions} 3141 _________________Figure_9:__Supported_MTS_Extensions___________________ 3143 _______________________________________________________________________ 3145 restrictedSubtree OBJECT-CLASS ::= { 3146 SUBCLASS OF {top} 3147 MAY CONTAIN { 3148 subtreeDeliverableContentLength| 3149 subtreeDeliverableContentTypes| 3150 subtreeDeliverableEITs} 3151 ID oc-restricted-subtree} 3153 subtreeDeliverableContentLength ATTRIBUTE ::= { 10 3154 SUBTYPE OF mhs-deliverable-content-length 3155 ID at-subtree-deliverable-content-length} 3157 subtreeDeliverableContentTypes ATTRIBUTE ::= { 3158 SUBTYPE OF mhs-deliverable-content-types 3159 ID at-subtree-deliverable-content-types} 3161 subtreeDeliverableEITs ATTRIBUTE ::= { 3162 SUBTYPE OF mhs-deliverable-eits 3163 ID at-subtree-deliverable-eits} 20 3165 ______________Figure_10:__Subtree_Capability_Restriction_______________ 3166 INTERNET--DRAFT MHS Routing using Directory June 1994 3168 _______________________________________________________________________ 3170 initiatorP1Mode ATTRIBUTE ::= { 3171 WITH SYNTAX P1Mode 3172 SINGLE VALUE 3173 ID at-initiator-p1-mode} 3175 responderP1Mode ATTRIBUTE ::= { 3176 WITH SYNTAX P1Mode 3177 SINGLE VALUE 3178 ID at-responder-p1-mode} 10 3180 P1Mode ::= ENUMERATED { 3181 push-only(0), 3182 pull-only(1), 3183 twa(2) } 3185 polledMTAs ATTRIBUTE ::= { 3186 WITH SYNTAX PolledMTAs 3187 ID at-polled-mtas} 3188 20 3189 PolledMTAs ::= SEQUENCE { 3190 mta DistinguishedName, 3191 poll-frequency INTEGER OPTIONAL --frequency in minutes 3192 } 3194 mTAsAllowedToPoll ATTRIBUTE ::= { 3195 SUBTYPE OF distinguishedName 3196 ID at-mtas-allowed-to-poll} 3198 _____________________Figure_11:__Pulling_Messages______________________ 3199 INTERNET--DRAFT MHS Routing using Directory June 1994 3201 _______________________________________________________________________ 3203 responderAuthenticationRequirements ATTRIBUTE ::= { 3204 WITH SYNTAX AuthenticationRequirements 3205 SINGLE VALUE 3206 ID at-responder-authentication-requirements} 3208 initiatorAuthenticationRequirements ATTRIBUTE ::= { 3209 WITH SYNTAX AuthenticationRequirements 3210 SINGLE VALUE 3211 ID at-initiator-authentication-requirements} 10 3213 repsonderPullingAuthenticationRequirements ATTRIBUTE ::= { 3214 WITH SYNTAX AuthenticationRequirements 3215 SINGLE VALUE 3216 ID at-responder-pulling-authentication-requirements} 3218 initiatorPullingAuthenticationRequirements ATTRIBUTE ::= { 3219 WITH SYNTAX AuthenticationRequirements 3220 SINGLE VALUE 3221 ID at-initiator-pulling-authentication-requirements} 20 3223 AuthenticationRequirements ::= BITSTRING { 3224 mta-name-present(0), 3225 aet-present(1), 3226 aet-valid(2), 3227 network-address(3), 3228 simple-authentication(4), 3229 strong-authentication(5), 3230 bilateral-agreement-needed(6)} 3232 _______________Figure_12:__Authentication_Requirements_________________ 3233 INTERNET--DRAFT MHS Routing using Directory June 1994 3235 _______________________________________________________________________ 3237 respondingRTSCredentials ATTRIBUTE ::= { 3238 WITH SYNTAX RTSCredentials 3239 SINGLE VALUE 3240 ID at-responding-rts-credentials} 3242 initiatingRTSCredentials ATTRIBUTE ::= { 3243 WITH SYNTAX RTSCredentials 3244 SINGLE VALUE 10 3245 ID at-initiating-rts-credentials} 3247 RTSCredentials ::= SEQUENCE { 3248 request [0] MTAandPassword OPTIONAL, 3249 response [1] MTAandPassword OPTIONAL } 3251 MTAandPassword ::= SEQUENCE { 3252 MTAName, 20 3253 Password } -- MTAName and Password 3254 -- from X.411 3256 callingPresentationAddress ATTRIBUTE ::= { 3257 SUBTYPE OF presentationAddress 3258 MULTI VALUE 3259 ID at-calling-presentation-address} 3261 callingSelectorValidity ATTRIBUTE ::= { 30 3262 WITH SYNTAX CallingSelectorValidity 3263 SINGLE VALUE 3264 ID at-calling-selector-validity} 3266 CallingSelectorValidity ::= ENUMERATED { 3267 all-selectors-fixed(0), 3268 tsel-may-vary(1), 3269 all-selectors-may-vary(2) } 3271 ______________Figure_13:__MTA_Authentication_Parameters________________ 3272 INTERNET--DRAFT MHS Routing using Directory June 1994 3274 _______________________________________________________________________ 3276 mTAWillRoute ATTRIBUTE ::= { 3277 WITH SYNTAX MTAWillRoute 3278 ID at-mta-will-route} 3280 MTAWillRoute ::= SEQUENCE { 3281 from [0] SET OF ORAddressPrefix OPTIONAL, 3282 to [1] SET OF ORAddressPrefix OPTIONAL, 3283 from-excludes [2] SET OF ORAddressPrefix OPTIONAL, 3284 to-excludes [3] SET OF ORAddressPrefix OPTIONAL } 10 3286 ORAddressPrefix ::= DistinguishedName 3288 _____________Figure_14:__Simple_MTA_Policy_Specification_______________ 3290 _______________________________________________________________________ 3292 mandatoryRedirect ATTRIBUTE ::= { 3293 SUBTYPE OF distinguishedName 3294 SINGLE VALUE 3295 ID at-mandatory-redirect} 3297 filteredRedirect ATTRIBUTE ::= { 3298 WITH SYNTAX FilteredRedirect 3299 SINGLE VALUE 3300 ID at-filtered-redirect} 10 3302 FilteredRedirect ::= SEQUENCE { 3303 redirect-to DistinguishedName, 3304 SEQUENCE { 3305 min-size [1] INTEGER, 3306 max-size [2] INTEGER, 3307 content [3] ContentType, 3308 eit [4] ExternalEncodedInformationType } 3309 } 3310 20 3312 ___________________Figure_15:__Redirect_Definition_____________________ 3313 INTERNET--DRAFT MHS Routing using Directory June 1994 3315 _______________________________________________________________________ 3317 nonDeliveryInfo ATTRIBUTE ::= { 3318 WITH SYNTAX NonDeliveryReason 3319 ID at-non-delivery-info} 3321 NonDeliveryReason ::= SEQUENCE { 3322 reason INTEGER (0..ub-reason-codes), 3323 diagnostic INTEGER (0..ub-diagnostic-codes), 3324 supplementaryInfo PrintableString } 3326 _________________Figure_16:__Non_Delivery_Information__________________ 3328 _______________________________________________________________________ 3330 badAddressSearchPoint ATTRIBUTE ::= { 3331 SUBTYPE OF distinguishedName 3332 ID at-bad-address-search-point} 3334 badAddressSearchAttributes ATTRIBUTE ::= { 3335 WITH SYNTAX AttributeType 3336 ID at-bad-address-search-attributes} 3338 alternativeAddressInformation EXTENSION 10 3339 AlternativeAddressInformation 3340 ::= id-alternative-address-information 3341 -- X.400(92) continues to use MACRO notation 3343 AlternativeAddressInformation ::= SET OF SEQUENCE { 3344 distinguished-name DistinguishedName OPTIONAL, 3345 or-address ORAddress OPTIONAL, 3346 other-useful-info SET OF Attribute } 3348 ___________________Figure_17:__Bad_Address_Pointers____________________ 3349 INTERNET--DRAFT MHS Routing using Directory June 1994 3351 _______________________________________________________________________ 3353 localAccessUnit ATTRIBUTE ::= { 3354 WITH SYNTAX AccessUnitType 3355 ID at-local-access-unit} 3357 AccessUnitType ::= ENUMERATED { 3358 fax (1), 3359 physical-delivery (2), 3360 teletex (3), 3361 telex (4) } 10 3363 accessUnitsUsed ATTRIBUTE ::= { 3364 WITH SYNTAX SelectedAccessUnit 3365 ID at-access-units-used} 3367 SelectedAccessUnit ::= SEQUENCE { 3368 type AccessUnitType, 3369 providing-MTA DistinguishedName, 3370 filter SET OF ORAddress OPTIONAL } 3372 __________________Figure_18:__Access_Unit_Attributes___________________ 3374 _______________________________________________________________________ 3376 ts-communities OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4) 3377 enterprises(1) isode-consortium (453) ts-communities (4)} 3379 tc-cons OBJECT IDENTIFIER ::= {ts-communities 1} -- OSI CONS 3380 tc-clns OBJECT IDENTIFIER ::= {ts-communities 2} -- OSI CLNS 3381 tc-internet OBJECT IDENTIFIER ::= {ts-communities 3} -- Internet + RFC 1006 3382 tc-int-x25 OBJECT IDENTIFIER ::= {ts-communities 4} -- International X.25 3383 -- Without CONS10 3384 tc-ixi OBJECT IDENTIFIER ::= {ts-communities 5} -- IXI (Europe) 3385 tc-janet OBJECT IDENTIFIER ::= {ts-communities 6} -- Janet (UK) 3387 ____Figure_20:__Transport_Community_Object_Identifier_Assignments______ 3388 INTERNET--DRAFT MHS Routing using Directory June 1994 3390 _______________________________________________________________________ 3392 mail-protocol OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4) 3393 enterprises(1) isode-consortium (453) mail-protocol (5)} 3395 ac-p1-1984 OBJECT IDENTIFIER ::= {mail-protocol 1} -- p1(1984) 3396 ac-smtp OBJECT IDENTIFIER ::= {mail-protocol 2} -- SMTP 3397 ac-uucp OBJECT IDENTIFIER ::= {mail-protocol 3} -- UUCP Mail 3398 ac-jnt-mail OBJECT IDENTIFIER ::= {mail-protocol 4} -- JNT Mail (UK) 3399 ac-p1-1988-x410 OBJECT IDENTIFIER ::= {mail-protocol 5} -- p1(1988) in X.410 mode 3400 ac-p3-1984 OBJECT IDENTIFIER ::= {mail-protocol 6} -- p3(1984) 10 3402 __________Figure_21:__Protocol_Object_Identifier_Assignments___________