idnits 2.17.1 draft-ietf-mixer-rfc1664bis-00.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-25) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. 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 22 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The abstract seems to indicate that this document obsoletes RFC1664, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 269 has weird spacing: '...s based on a ...' == Line 292 has weird spacing: '... va ca ...' == Line 541 has weird spacing: '...slation con...' == Line 549 has weird spacing: '...slation con...' == Line 561 has weird spacing: '...slation con...' == (2 more instances...) == Unrecognized Status in 'Category: Internet-Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1997) is 9962 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'CCITT' is defined on line 1117, but no explicit reference was found in the text == Unused Reference: 'RFC 1327' is defined on line 1120, but no explicit reference was found in the text == Unused Reference: 'RFC 1034' is defined on line 1123, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 1127, but no explicit reference was found in the text == Unused Reference: 'RFC 1033' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'MIXER' is defined on line 1134, but no explicit reference was found in the text == Unused Reference: 'Costa' is defined on line 1137, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CCITT' ** Obsolete normative reference: RFC 1327 (Obsoleted by RFC 2156) ** Downref: Normative reference to an Unknown state RFC: RFC 1033 ** Obsolete normative reference: RFC 822 (ref. 'MIXER') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. 'Costa' Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working C. Allocchio (editor) 2 Group G.A.R.R. Italy 3 INTERNET-DRAFT January 1997 4 Expires: August 1997 5 File: draft-ietf-mixer-rfc1664bis-00.txt 7 Using the Internet DNS to Distribute 8 MIXER Conformant Global Address Mapping (MCGAM) 10 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. Internet Drafts are draft 16 documents valid for a maximum of six months. Internet Drafts may be 17 updated, replaced, or obsoleted by other documents at any time. It is 18 not appropriate to use Internet Drafts as reference material or to 19 cite them other than as a ``working draft'' or ``work in progress.'' 20 Please check the I-D abstract listing contained in each Internet Draft 21 directory to learn the current status of this or any other Internet 22 Draft. 24 RFC 1664bis Internet DNS for Mail Mapping Tables January 1997 26 Network Working Group C. Allocchio 27 Request for Comments: 1664bis GARR-Italy 28 Category: Internet-Draft January 1997 29 Obsoletes: RFC1664 31 Using the Internet DNS to Distribute 32 MIXER Conformant Global Address Mapping (MCGAM) 34 Status of this Memo 36 This memo will be submitted to the RFC editor as a protocole 37 specification for the Internet community. This memo obsoletes 38 RFC1664, updating its specifications to conform with MIXER (updated 39 version of RFC1327). Distribution of this memo is unlimited. 41 Abstract 43 This memo is the complete technical specification to store in the 44 Internet Domain Name System (DNS) the mapping information (MCGAM) 45 needed by MIXER conformant e-mail gateways and other tools to map 46 RFC822 domain names into X.400 O/R names and vice versa. Mapping 47 information can be managed in a distributed rather than a centralised 48 way. Organizations can publish their MIXER mapping or preferred 49 gateway routing information using just local resources (their local 50 DNS server), avoiding the need for a strong coordination with any 51 centralised organization. MIXER conformant gateways and tools located 52 on Internet hosts can retrieve the mapping information querying the 53 DNS instead of having fixed tables which need to be centrally updated 54 and distributed. 56 This memo obsoletes RFC1664. It includes the changes introduced by 57 MIXER specification with respect to RFC1327: the new 'gate1' (O/R 58 addresses to domain) table is fully supported. Full backward 59 compatibility with RFC1664 specification is mantained, too. 61 RFC1664 was a joint effort of IETF X400 operation working group 62 (x400ops) and TERENA (formely named "RARE") Mail and Messaging working 63 group (WG-MSG). This update was performed by the IETF MIXER working 64 group. 66 1. Introduction 68 The connectivity between the Internet SMTP mail and other mail 69 services, including the Internet X.400 mail and the commercial X.400 70 service providers, is assured by the Mail eXchanger (MX) record 71 information distributed via the Internet Domain Name System (DNS). A 73 RFC 1664bis Internet DNS for Mail Mapping Tables January 1997 75 number of documents then specify in details how to convert or encode 76 addresses from/to RFC822 style to the other mail system syntax. 77 However, only conversion methods provide, via some algorithm or a set 78 of mapping rules, a smooth translation, resulting in addresses 79 indistinguishable from the native ones in both RFC822 and foreign 80 world. 82 MIXER describes a set of mappings (MIXER Conformant Global Address 83 Mapping - MCGAM) which will enable interworking between systems 84 operating the CCITT X.400 (1984/88/92) Recommendations and systems using 85 using the RFC822 mail protocol, or protocols derived from RFC822. That 86 document addresses conversion of services, addresses, message 87 envelopes, and message bodies between the two mail systems. 88 This document is concerned with one aspect of MIXER: the mechanism 89 for mapping between X.400 O/R addresses and RFC822 domain names. As 90 described in Appendix F of MIXER, implementation of the mappings 91 requires a database which maps between X.400 O/R addresses and domain 92 names; in RFC1327 this database was statically defined. 94 The original approach in RFC1327 required many efforts to maintain the 95 correct mapping: all the gateways needed to get coherent tables to apply 96 the same mappings, the conversion tables had to be distributed among all 97 the operational gateways, and also every update needed to be distributed. 99 The concept of mapping rules distribution and use has been revised in 100 the new MIXER specification, introducing the concept of MIXER Conformant 101 Global Address Mapping (MCGAM). A MCGAM does not need to be globally 102 installed by any MIXER conformant gateway in the world any more. However 103 MIXER requires now efficient methods to publish its MCGAM. 105 Static tables are one of the possible methods to publish MCGAM. 106 However this static mechanism requires quite a long time to be spent 107 modifying and distributing the information, putting heavy constraints 108 on the time schedule of every update. In fact it does not appear 109 efficient compared to the Internet Domain Name Service (DNS). More 110 over it does not look feasible to distribute the database to a large 111 number of other useful applications, like local address converters, 112 e-mail User Agents or any other tool requiring the mapping rules to 113 produce correct results. 115 Two much more efficient methods are proposed by MIXER for publication 116 of MCGAM: the Internet DNS and X.500. This memo is the complete 117 technical specification for publishing MCGAM via Internet DNS. 119 A first proposal to use the Internet DNS to store, retrieve and 120 maintain those mappings was introduced by two of the authors of 121 RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record 122 (RR) types: TO-X400 and TO-822. This proposal now adopts a more 123 complete strategy, and requires one new RR only. The distribution of 124 MCGAMs via DNS is in fact an important service for the whole Internet 125 community: it completes the information given by MX resource record 127 RFC 1664bis Internet DNS for Mail Mapping Tables January 1997 129 and it allows to produce clean addresses when messages are exchanged 130 among the Internet RFC822 world and the X.400 one (both Internet and 131 Public X.400 service providers). 133 A first experiment in using the DNS without expanding the current set 134 of RR and using available ones was deployed by some of the authors of 135 RFC1664 at the time of its development. The existing PTR resource 136 records were used to store the mapping rules, and a new DNS tree was 137 created under the ".it" top level domain. The result of the experiment 138 was positive, and a few test applications ran under this provisional 139 set up. This test was also very useful in order to define a possible 140 migration strategy during the deployment of the new DNS containing 141 the new RR. The Internet DNS nameservers wishing to provide this 142 mapping information need in fact to be modified to support the new RR 143 type, and in the real Internet, due to the large number of different 144 implementations, this takes some time. 146 The basic idea is to adopt a new DNS RR to store the mapping 147 information. The RFC822 to X.400 mapping rules (including the so 148 called 'gate2' rules) will be stored in the ordinary DNS tree, while 149 the definition of a new branch of the name space defined under each 150 national top level domain is envisaged in order to contain the X.400 151 to RFC822 mappings ('table1' and 'gate1'). A "two-way" mapping 152 resolution schema is thus fully implemented. 154 The creation of the new domain name space representing the X.400 O/R 155 names structure also provides the chance to use the DNS to distribute 156 dynamically other X.400 related information, thus solving other 157 efficiency problems currently affecting the X.400 MHS service. 159 In this paper we will adopt the MCGAM syntax, showing how it can be 160 stored into the Internet DNS. 162 1.1 Definitions syntax 164 The definitions in this document is given in BNF-like syntax, using 165 the following conventions: 167 | means choice 168 \ is used for continuation of a definition over several lines 169 [] means optional 170 {} means repeated one or more times 172 The definitions, however, are detailed only until a certain level, 173 and below it self-explaining character text strings will be used. 175 2. Motivation 177 Implementations of MIXER gateways require that a database store 178 address mapping information for X.400 and RFC822. This information 179 must be made available (published) to all MIXER gateways. In the 181 RFC 1664bis Internet DNS for Mail Mapping Tables January 1997 183 Internet community, the DNS has proven to be a practical mean for 184 providing a distributed name service. Advantages of using a DNS 185 based system over a table based approach for mapping between O/R 186 addresses and domain names are: 188 - It avoids fetching and storing of entire mapping tables by every 189 host that wishes to implement MIXER gateways and/or tools 191 - Modifications to the DNS based mapping information can be made 192 available in a more timely manner than with a table driven 193 approach. 195 - It allows full authority delegation, in agreement with the 196 Internet regionalization process. 198 - Table management is not necessarily required for DNS-based 199 MIXER gateways. 201 - One can determine the mappings in use by a remote gateway by 202 querying the DNS (remote debugging). 204 Also many other tools, like address converters and User Agents can 205 take advantage of the real-time availability of MIXER tables, 206 allowing a much easier maintenance of the information. 208 3. The domain space for X.400 O/R name addresses 210 Usual domain names (the ones normally used as the global part of an 211 RFC822 e-mail address) and their associated information, i.e., host 212 IP addresses, mail exchanger names, etc., are stored in the DNS as a 213 distributed database under a number of top-level domains. Some top- 214 level domains are used for traditional categories or international 215 organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand 216 any country has its own two letter ISO country code as top-level 217 domain (FR, DE, GB, IT, RU, ...), including "US" for USA. The 218 special top-level/second-level couple IN-ADDR.ARPA is used to store 219 the IP address to domain name relationship. This memo defines in 220 the above structure the appropriate way to locate the X.400 O/R name 221 space, thus enabling to store in DNS the MIXER mappings (MCGAMs). 223 The MIXER mapping information is composed by four tables: 225 - 'table1' and 'gate1' gives the translation from X.400 to RFC822; 226 - 'table2' and 'gate2' tables map RFC822 into X.400. 228 Each mapping table is composed by mapping rules, and a single 229 mapping rule is composed by a keyword (the argument of the mapping 230 function derived from the address to be translated) and a translator 231 (the mapping function parameter): 233 keyword#translator# 235 RFC 1664bis Internet DNS for Mail Mapping Tables January 1997 237 the '#' sign is a delimiter enclosing the translator. An example: 239 foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us# 241 Local mappings are not intended for use outside their restricted 242 environment, thus they should not be included in DNS. If local 243 mappings are used, they should be stored using static local tables, 244 exactly as local static host tables can be used with DNS. 246 The keyword of a 'table2' and 'gate2' table entry is a valid RFC822 247 domain; thus the usual domain name space can be used without problems 248 to store these entries. 249 On the other hand, the keyword of a 'table1' and 'gate1' entry 250 belongs to the X.400 O/R name space. The X.400 O/R name space 251 does not usually fit into the usual domain name space, although 252 there are a number of similarities; a new name structure is thus 253 needed to represent it. This new name structure contains the X.400 254 mail domains. 256 To ensure the correct functioning of the DNS system, the new X.400 257 name structure must be hooked to the existing domain name space in a 258 way which respects the existing name hierarchy. 260 A possible solution was to create another special branch, starting 261 from the root of the DNS tree, somehow similar to the in-addr.arpa 262 tree. This idea would have required to establish a central authority 263 to coordinate at international level the management of each national 264 X.400 name tree, including the X.400 public service providers. This 265 coordination problem is a heavy burden if approached globally. More 266 over the X.400 name structure is very 'country oriented': thus while 267 it requires a coordination at national level, it does not have 268 concepts like the international root. In fact the X.400 international 269 service is based on a large number of bilateral agreements, and only 270 within some communities an international coordination service exists. 272 The X.400 two letter ISO country codes, however, are the same used 273 for the RFC822 country top-level domains and this gives us an 274 appropriate hook to insert the new branches. The proposal is, in 275 fact, to create under each national top level ISO country code a new 276 branch in the name space. This branch represents exactly the X.400 277 O/R name structure as defined in each single country, following the 278 ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed 279 under each country top-level domain, and hence the national X.400 280 name space derives its own structure: 282 RFC 1664bis Internet DNS for Mail Mapping Tables January 1997 284 . (root) 285 | 286 +-----------------+-----------+--------+-----------------+... 287 | | | | 288 edu it us fr 289 | | | | 290 +---+---+... +-----+-----+... +-----+-----+... +--+---+... 291 | | | | | | | | | | 292 ... ... cnr X42D infn va ca X42D X42D inria 293 | | | | 294 +------------+------------+... ... ... +----+-------+... 295 | | | | | 296 ADMD-PtPostel ADMD-garr ADMD-Master400 ADMD-atlas ADMD-red 297 | | | | 298 +----------+----+... ... +-------+------+... ... 299 | | | | 300 PRMD-infn PRMD-STET PRMD-Telecom PRMD-Renault 301 | | | | 302 ... ... ... ... 304 The creation of the X.400 new name tree at national level solves the 305 problem of the international coordination. Actually the coordination 306 problem is just moved at national level, but it thus becomes easier 307 to solve. The coordination at national level between the X.400 308 communities and the Internet world is already a requirement for the 309 creation of the national static MIXER mapping tables; the use of 310 the Internet DNS gives further motivations for this coordination. 312 The coordination at national level also fits in the new concept of 313 MCGAM pubblication. The DNS in fact allows a step by step authority 314 distribution, up to a final complete delegation: thus organizations 315 whishing to publish their MCGAM just need to receive delegation also 316 for their branch of the new X.400 name space. A further advantage of 317 the national based solution is to allow each country to set up its 318 own X.400 name structure in DNS and to deploy its own authority 319 delegation according to its local time scale and requirements, with 320 no loss of global service in the mean time. And last, placing the 321 new X.400 name tree and coordination process at national level fits 322 into the Internet regionalization and internationalisation process, 323 as it requires local bodies to take care of local coordination 324 problems. 326 The DNS name space thus contains completely the information required 327 by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a 328 simple query to the nearest nameserver provides it. Moreover there is 329 no more any need to store, maintain and distribute manually any 330 mapping table. The new X.400 name space can also contain further 331 information about the X.400 community, as DNS allows for it a 333 RFC 1664bis Internet DNS for Mail Mapping Tables January 1997 335 complete set of resource records, and thus it allows further 336 developments. This set of RRs in the new X.400 name space must be 337 considered 'reserved' and thus not used until further specifications. 339 The construction of the new domain space trees will follow the same 340 procedures used when organising at first the already existing DNS 341 space: at first the information will be stored in a quite centralised 342 way, and distribution of authority will be gradually achieved. A 343 separate document will describe the implementation phase and the 344 methods to assure a smooth introduction of the new service. 346 4. The new DNS resource record for MIXER mapping rules: PX 348 The specification of the Internet DNS (RFC1035) provides a number of 349 specific resource records (RRs) to contain specific pieces of 350 information. In particular they contain the Mail eXchanger (MX) RR 351 and the host Address (A) records which are used by the Internet SMTP 352 mailers. As we will store the RFC822 to X.400 mapping information in 353 the already existing DNS name tree, we need to define a new DNS RR in 354 order to avoid any possible clash or misuse of already existing data 355 structures. The same new RR will also be used to store the mappings 356 from X.400 to RFC822. More over the mapping information, i.e., the 357 MCGAMs, has a specific format and syntax which require an 358 appropriate data structure and processing. A further advantage of 359 defining a new RR is the ability to include flexibility for some 360 eventual future development. 362 The definition of the new 'PX' DNS resource record is: 364 class: IN (Internet) 366 name: PX (pointer to X.400/RFC822 mapping information) 368 value: 26 370 The PX RDATA format is: 372 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 373 | PREFERENCE | 374 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 375 / MAP822 / 376 / / 377 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 378 / MAPX400 / 379 / / 380 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 382 where: 384 RFC 1664bis Internet DNS for Mail Mapping Tables January 1997 386 PREFERENCE A 16 bit integer which specifies the preference given to 387 this RR among others at the same owner. Lower values 388 are preferred; 390 MAP822 A element containing , the 391 RFC822 part of the MCGAM; 393 MAPX400 A element containing the value of 394 derived from the X.400 part of 395 the MCGAM (see sect. 4.2); 397 PX records cause no additional section processing. The PX RR format 398 is the usual one: 400 [] [] 402 When we store in DNS a 'table1' or a 'gate1' entry, then will 403 be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we 404 store a 'table2' or a 'gate2' table entry, will be an RFC822 405 mail domain name, including both fully qualified DNS domains and mail 406 only domains (MX-only domains). All normal DNS conventions, like 407 default values, wildcards, abbreviations and message compression, 408 apply also for all the components of the PX RR. In particular , 409 MAP822 and MAPX400, as elements, must have the final 410 "." (root) when they are fully qualified. 412 4.1 Additional features of the PX resource record 414 The definition of the RDATA for the PX resource record, and the fact 415 that DNS allows a distinction between an exact value and a wildcard 416 match for the parameter, represent an extension of the MIXER 417 specification for mapping rules. In fact, any MCGAM entry is an 418 implicit wildcard entry, i.e., the rule 420 net2.it#PRMD$net2.ADMD$p400.C$it# 422 covers any RFC822 domain ending with 'net2.it', unless more detailed 423 rules for some subdomain in 'net2.it' are present. Thus there is no 424 possibility to specify explicitly a MCGAM as an exact match only 425 rule. In DNS an entry like 427 *.net2.it. IN PX 10 net2.it. PRMD-net2.ADMD-p400.C-it. 429 specify the usual wildcard match as for MIXER tables. However an 430 entry like 432 ab.net2.it. IN PX 10 ab.net2.it. O-ab.PRMD-net2.ADMDb.C-it. 434 RFC 1664bis Internet DNS for Mail Mapping Tables January 1997 436 is valid only for an exact match of 'ab.net2.it' RFC822 domain. 438 Note also that in DNS syntax there is no '#' delimiter around MAP822 439 and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not 440 allow the (ASCII decimal 32) character within these fields, 441 making unneeded the use of an explicit delimiter as required in the 442 MIXER original syntax. 444 Another extension to the MIXER specifications is the PREFERENCE 445 value defined as part of the PX RDATA section. This numeric value has 446 exactly the same meaning than the similar one used for the MX RR. It 447 is thus possible to specify more than one single mapping for a domain 448 (both from RFC822 to X.400 and vice versa), giving as the preference 449 order. In MIXER static tables, however, you cannot specify more 450 than one mapping per each RFC822 domain, and the same restriction 451 apply for any X.400 domain mapping to an RFC822 one. 453 More over, in the X.400 recommendations a note suggests than an 454 ADMD= should be reserved for some special cases. Various 455 national functional profile specifications for an X.400 MHS states 456 that if an X.400 PRMD is reachable via any of its national ADMDs, 457 independently of its actual single or multiple connectivity with 458 them, it should use ADMD= to advertise this fact. Again, if a 459 PRMD has no connections to any ADMD it should use ADMD=0 to notify 460 its status, etc. However, in most of the current real situations, the 461 ADMD service providers do not accept messages coming from their 462 subscribers if they have a blank ADMD, forcing them to have their own 463 ADMD value. In such a situation there are problems in indicating 464 properly the actually working mappings for domains with multiple 465 connectivity. The PX RDATA 'PREFERENCE' extension was introduced to 466 take in consideration these problems. 468 However, as these extensions are not available with MIXER static 469 tables, it is strongly discouraged to use them when interworking with 470 any table based gateway or application. The extensions were in fact 471 introduced just to add more flexibility, like the PREFERENCE value, 472 or they were already implicit in the DNS mechanism, like the wildcard 473 specification. They should be used very carefully or just considered 474 'reserved for future use'. In particular, for current use, the 475 PREFERENCE value in the PX record specification should be fixed to a 476 value of 50, and only wildcard specifications should be used when 477 specifying values. 479 4.2 The DNS syntax for an X.400 'domain' 481 The syntax definition of the MCGAM rules is defined in appendix F of 482 that document. However that syntax is not very human oriented and 483 contains a number of characters which have a special 485 RFC 1664bis Internet DNS for Mail Mapping Tables January 1997 487 meaning in other fields of the Internet DNS. Thus in order to avoid 488 any possible problem, especially due to some old DNS implementations 489 still being used in the Internet, we define a syntax for the X.400 490 part of any MCGAM rules (and hence for any X.400 O/R name) which 491 makes it compatible with a element, i.e., 493 ::= | " " 494 ::=