|
Français | Contact Us | Help | Search | Canada Site | ||||
| What's New | About Us | Policies | Documents | TBS Site |
| Calendar | Links | FAQs | Presentations | Home | ||||||
|
|
|
 |
TABLE OF CONTENTSCOSAC addressing scheme for PRMD names and remaining O/R components Government registration service Appendix A - Implementation considerations Appendix B - Addressing to/from GEMDES users Appendix C - Addressing between PRMDs and the Internet 1.1 Objective and scope Open Systems Interconnection (OSI) specifications, produced under the umbrella of the Canadian Open Systems Application Criteria (COSAC), are designed to enable the purchase and use of OSI network related products and services that conform to International Standards. The use of this particular specification will maximize the interoperability of Government Message Handling Systems, based on X.400, both within and between departments and with the external world. This document mandates the selection of specific naming/addressing options and formats within available standards issued by the International Organization for Standardization (known as ISO). This Treasury Board Information Technology Standard (TBITS) specifies the requirements and guidelines for: Naming and Addressing for Government Message Handling System Applications. This TBITS conforms to the relevant CCITT X.400 (88) Recommendations and equivalent ISO/IEC 10021 standards. The naming and addressing terminology used in X.400 and in ISO/IEC 10021 has been adopted in this report. The naming requirements focus on the mnemonic form of Originator/Recipient (O/R) addresses (clause 18.5.1 of ISO/IEC 10021-2). Although other forms of O/R Addresses may be used within the Federal Government, specific guidelines relating to their use are not within the scope of this document. Additionally, the requirements for national registration as defined in Canadian Standards Association (CSA) Standard Z243.110 have been taken into account. 1.2 Background The unrestricted interchange of electronic messages within the Government, and between the outside world and the Government can only be achieved within a single and unambiguous naming and addressing framework. The messaging systems within the Government Enterprise Network, must, right from the outset, adopt a name and address allocation scheme within an international framework of universally unique addresses. It is essential that any given Enterprise Network be theoretically interconnectable to any other Enterprise Network, either within or without the Federal jurisdiction. It is undesirable, and impractical, to change the addressing scheme each time a new interconnection requirement is identified. This TBITS is designed for use by departmental representatives responsible for planning, establishing and managing X.400 and non-X.400 electronic mail systems. This TBITS specifies the mnemonic form of X.400 Originator/Recipient Addresses and provides: (a) compatibility with X.400 naming conventions as currently used by departmental and public systems; (b) a solution which meets departmental, intradepartmental and interdepartmental naming requirements; (c) support for bilingual names; (d) support for applications other than electronic mail, for example Electronic Data Interchange and Interlibrary Loan. This TBITS takes account of (e) the interconnectivity requirements of Government Message Handling System (GMHS); (f) the role and relation of the national Canadian OSI Registration Authority (COSIRA) operated by CGI on behalf of Standards Council of Canada and ISC Telecommunications Policy Branch; (g) the role and relation of the Governmental Registration Service operated by the Government Telecommunications Agency (GTA). 1.3 Summary This TBITS specifies the format of Originator/Recipient Addresses, for application to Government Message Handling Systems consistent with: (a) national and international standards; (b) Industry and Science Canada's (ISC) Telecommunications Policy; (c) the Canadian Open Systems Interconnection Registration Authority (COSIRA); (d) Governmental interconnectivity and registration capabilities. The TBITS is organized as follows: The Abbreviations and References used in this document are summarized in sections 2 and 3 respectively. The basic principles of O/R addressing and MHS systems interconnectivity are described in section 4. Section 5 describes the applicable national registration standards, and national registration procedures within Canada at the national level. Section 6 describes the COSAC addressing scheme and the requirements to be met by departments. Section 7 covers the Government Registration Service operated by the Government Telecommunications Agency. Section 8 contains the compliance requirements of this TBITS. Section 9 shows how X.400 names should be represented on business cards. Appendix A contains further background and guidance information. Appendix B contains examples of address formats for use by, and to, GEMDES users. Appendix C contains examples of address formats used between PRMDs and the Internet, and vice-versa. Computer Communications, Vol. 13, No. 1, Jan/Feb 1990, pp. 27-36, Ahmed Patel and Vincent Ryan, Introduction to names, addresses and routes in an OSI environment. Canadian Open Systems Application Criteria Profile for Message Handling Systems, 1988-COSAC: MHS (88), Draft March 1994. CSA Z243.110, Canadian OSI Registration Procedures and Guidelines. CCITT X.208|ISO/IEC 8824, Information technology - Open Systems Interconnection - Abstract Syntax Notation One (ASN.1). CCITT T.61, character repertoire and coded character sets for the international teletex service. CCITT X.400|ISO/IEC 10021-1, Information processing systems - Text communication - Message Handling Systems - Part 1: System and service overview. CCITT X.402|ISO/IEC 10021-2, Information processing systems - Text communication - Message Handling Systems - Part 2: Overall architecture. Request for Comments (RFC) 1327, Mapping between X.400(1988) / ISO 10021 and RFC 822, S. Hardcastle-Kille, May 1992. Treasury Board of Canada Secretariat Federal Identity Program, Titles of Federal Organizations, March 1989. Note: The adjective "X.400" has become the most widely used term to describe standardized mail systems. Strictly, X.400 is an ITU-T (formerly CCITT) term. The ISO MOTIS standards are, for the most part, identical to the ITU-T/CCITT Recommendations.
4.1 General The CCITT Recommendation X.402 defines how a "Global MHS" can be realized as a set of interconnected but independently managed messaging systems. The concept of Management Domains (MDs) is introduced as the components from which the global MHS is assembled. 4.1.1 Management domains A Management Domain, or MD, is a set of messaging systems, at least one of which contains or realizes a Message Transfer Agent (MTA), and which is managed by a single organization. Two types of MD have been defined: (a) the Administration Management Domain (ADMD); (b) the Private Management Domain (PRMD). 4.1.2 Administration management domain An Administration Management Domain (ADMD) is a Management Domain managed by an organization authorized to provide public service. Typically, this will be an organization mandated by a national Government to provide public service, such as the national carrier, nationally appointed Recognized Private Operating Agencies (RPOAs), or authorized Value-Added Network providers. 4.1.2 Private management domain A private management domain (PRMD) is managed by organizations not authorized to provide a public service. Typically, this will be a company system providing service to the whole company or, perhaps, to a particular company site. 4.2 Global MHS The major technical distinction between a PRMD and an ADMD is that the former is positioned below the latter in addressing and routing schemes. ADMDs and PRMDs form a hierarchy as shown in Figure 1. Figure 1 Global MHS Service Components 4.1 General The CCITT Recommendation X.402 defines how a "Global MHS" can be realized as a set of interconnected but independently managed messaging systems. The concept of Management Domains (MDs) is introduced as the components from which the global MHS is assembled. 4.1.1 Management domains A Management Domain, or MD, is a set of messaging systems, at least one of which contains or realizes a Message Transfer Agent (MTA), and which is managed by a single organization. Two types of MD have been defined: (a) the Administration Management Domain (ADMD); (b) the Private Management Domain (PRMD). 4.1.2 Administration management domain An Administration Management Domain (ADMD) is a Management Domain managed by an organization authorized to provide public service. Typically, this will be an organization mandated by a national Government to provide public service, such as the national carrier, nationally appointed Recognized Private Operating Agencies (RPOAs), or authorized Value-Added Network providers. 4.1.2 Private management domain A private management domain (PRMD) is managed by organizations not authorized to provide a public service. Typically, this will be a company system providing service to the whole company or, perhaps, to a particular company site. 4.2 Global MHS The major technical distinction between a PRMD and an ADMD is that the former is positioned below the latter in addressing and routing schemes. ADMDs and PRMDs form a hierarchy as shown in Figure 1. Figure 1 Global MHS Service Components
4.3 Basic MHS naming/addressing scheme Users of Message Handling Systems are known by what is designated as a Originator/Recipient Name. The standardized generic framework of a mnemonic O/R address is shown in Figure 2. A Government-wide Naming and Addressing scheme is required to ensure any-to-any electronic mail (messaging) capability within the Government. This TBITS defines the scheme to be deployed within Government, as a specific application of the appropriate national and international standards. Figure 2 Generic Address Framework
A mnemonic O/R address comprises: (a) one Country Name and one Administration Management Domain Name; (b) one Private Management Domain Name, one Organization Name, one Organizational Unit Name, one Personal Name or Common Name, or some combination of the thereof, and optionally one or more Domain Defined Attributes. Within this framework the country name is "CA" (as assigned by the International Organization for Standardization (ISO), and the ADMD and PRMD names are subject to national registration criteria under the jurisdiction of the Canadian OSI Registration Authority (COSIRA). Although not strictly necessary, there are significant advantages to nationally assigning PRMD names. In particular: (a) a PRMD can be connected to several ADMDs; (b) direct interconnection can be achieved between PRMDs; (c) an upgrade from PRMD to ADMD status is more readily achieved. Further levels of assignment, i.e. Organization Name, etc., are under the jurisdiction of the particular organization in question. In the case of the Government, however, a global and consistent Government-wide scheme is mandated by this TBITS. 4.4 Government MHS interconnectivity 4.4.1 Interconnectivity scenarios The form of the O/R address of a particular user will depend on the level at which the user's department resides in the address hierarchy shown in Figure 2. This in turn depends on the way in which the user's department is connected to the "global" MHS. This TBITS anticipates three major cases of interconnectivity: (a) User Department PRMD connected to the Government Message Handling Service (GMHS), with ADMD Name GOVMT.CANADA; (b) User Department PRMD connected to a commercial ADMD (e.g. Stentor (formerly Telecom Canada) with ADMD name TELECOM.CANADA); (c) Use of the Government Electronic Message and Document Exchange Service (GEMDES). These three cases are shown in Figure 3. Other cases, such as PRMD interconnection with more than ADMD, are not precluded. Figure 3 Interconnectivity Scenarios
Since, however, GMHS is the preferred solution for interconnectivity of departmental PRMDs, this TBITS concentrates on case (a) above. Migration from (b) to (a) presents no problems, and simply involves a change of ADMD Name. Migration from (c) to (a) either requires a shift two levels up the address hierarchy, or at least the insertion of departmental PRMD and Organization Names i.e. from an Organizational Unit to a PRMD. Since migration from (c) to (a) requires the establishment of a new in-house departmental mail system(s), changes from the previous GEMDES based naming conventions to those specified in this TBITS can readily be accommodated. 4.4.2 GMHS interconnectivity The Government (of Canada) Message Handling Service (GMHS) provided by the Government Telecommunications Agency (GTA) has been accorded ADMD status. GMHS is expected to be the basis for interconnectivity within the Government, and between the Government and the external world. GMHS will comprise a backbone of one or more interconnected MTAs. GMHS will provide connectivity with all other Government departments, external national and international MTAs, the Internet, GEMDES and ENVOY. The range of connectivity is shown in Figure 4. From a departmental perspective, the "whole external world" can be accessed through a single connection to GMHS using the X.400 P1 protocol. Control over the national level components of O/R addresses is exercised at the national level within Canada through: (a) the application of a national standard; (b) the jurisdiction of a national registration authority. 5.1 Canadian OSI registration procedures and guidelines B Z243.110 The Canadian Interest Group on Open Systems (CIGOS) has overseen the development of a Canadian Standard Z243.110 B Canadian OSI Registration Procedures and Guidelines. This standard is published by the Canadian Standards Association (CSA). Z243.110 is a five part standard comprising: Part 1: Registration Procedures; Part 2: Guidelines for Network service Access Point Addresses of the Data Country Code Format; Part 3: Guidelines for Object Identifier Names Part 4: Guidelines for Directory Names; Part 5: Guidelines for MHS-MOTIS Names. Figure 4 GMHS Interconnectivity
As far as this TBITS is concerned, parts 1 and 5 are relevant. Part 1 provides the rules and procedures for the client/server relationship involved in registration in general. The server in this case being the National Registration Authority. The National Registration Authority for Canada is Canadian Open Systems Interconnection Registration Authority (COSIRA) as mandated by Standards Council of Canada and Industry Canada, see section 5.2. Part 5 is relevant to MHS ADMD and PRMD name registration, see also section 6. In the context of MHS registration the CSA standard has jurisdiction over, and applies to, both Standards Council of Canada (SCC) and Industry Science Canada Telecommunications policy sectors. In particular, it should be noted that the CSA standard mandates a single name space from which ADMD and PRMD names will be assigned, for public and private service providers respectively. Only in this way can the requirements for: (a) connecting a PRMD to several different ADMDs; (b) direct interconnection between PRMDs; (c) easily upgrading a PRMD to ADMD; be readily achieved. It should also be noted that the use of a single name space permits the use of the null ADMD name (since all Canadian PRMD names are unique in their own right), represented by a single space attribute value (" "). This permits maximum flexibility with respect to MTA interconnection and routing arrangements both within Canada, and between Canada and other countries. In the case of PRMD names comprising a prefix and a suffix, it should also be noted that the CSA standard requires the suffix to be registered at the national level via COSIRA (see section 5.2). 5.2 Canadian open systems interconnection registration authority (COSIRA) In the context of MHS registration COSIRA has jurisdiction over, and applies to, both Standards Council of Canada (SCC) and Industry Canada Telecommunications policy sectors. In other words, COSIRA is a single National Registration Authority in respect of MHS naming, for both the public service provider and private service provider sectors. The Government Message Handling Service (GMHS) has been accorded ADMD status. A GMHS ADMD name has been registered by COSIRA. The ADMD name for GMHS is: GOVT.CANADA It is clear that individual departments will require PRMD names under the ADMD of GOVT.CANADA. Given the previous considerations about using a single name space, it follows that PRMD names also have to be registered nationally. However, due to special requirements for PRMD names, the general oversight and registration of PRMD names is subject to the requirements in section 6 of this TBITS. The requirement for the single name space and unambiguous PRMD names is met by registering a single PRMD prefix name with COSIRA. However, it is still required that the rest of the PRMD name, i.e. the suffix, be registered with COSIRA. This prefix name for the Government of Canada is: GC+ For example, the PRMD name for the Ministry of Natural Resources is: GC+EMR Thus, the remaining item for standardization and registration is that part of the PRMD name following the GC+ prefix, i.e. the suffix. Additionally, principles and guidelines are required for departments to follow in allocating the remaining address components which fall entirely under their jurisdiction, i.e. Organization Name, Organization Unit Name, Personal Name, etc. These requirements are also the subject of section 6 of this TBITS. 6. COSAC addressing scheme for PRMD names and remaining O/R components As indicated by the foregoing the top level of a departmental O/R address are preassigned and preregistered, that is: Country = CA This section details the requirements to be followed by departments in assigning values to the remaining O/R address components. 6.1 Basic considerations The naming and addressing requirements and guidelines for departments are based on the considerations outlined below. 6.1.1 Configuration of the government into domains Individual departments may be organized as one or more management domains. Conventions and guidelines are required in selecting the optimal domain boundaries. 6.1.2 Departmental, intradepartmental and interdepartmental naming Recommendations for departmental naming must be in accordance with established government policies and practices. Guidance and conventions are also required for naming entities within government departments as well as at the interdepartmental (e.g. interdepartmental work groups or committees) level. 6.1.3 Bilingual naming As a statement of policy, the Government of Canada shall provide all federal government services in both official languages. This policy has been confirmed with the Treasury Board of Canada Secretariat to include government MHS services. The government naming guidelines must therefore endeavor to satisfy this policy within practical limitations. To provide full support for French names, accented characters must be available for use within O/R Addresses. However, there are a number of impediments to the realization of this objective, the most significant impediment being that X.400 (84) does not support accented French characters. However, where possible, full support is provided through the use of both Printable and Teletex String attribute values for X.400 (88) implementations. See also consideration 6.1.9 for further details. 6.1.4 Name and address mapping In developing name and address mapping guidelines, the limitations imposed by the various commercial off-the-shelf X.400 gateway products should be considered. 6.1.5 Support for applications other than electronic mail While the X.400 recommendations initially standardized only the electronic mail application (called Interpersonal Mail), they recognize the possibility of other applications using the services of the X.400 Message Transfer System to convey messages on a store-and-forward basis. The naming and addressing guidelines must be applicable to other messaging applications in addition to electronic mail. Two examples are Electronic Data Interchange (EDI) and Interlibrary Loan (ILL). 6.1.6 Relationship to COSAC B MHS profile A key national decision established by the COSAC: MHS (88) Profile is the allowance of message transfers directly between PRMDs (without the use of one or more administration management domain (ADMD) intermediaries). By allowing such message transfers, more efficient and cost-effective transfers between PRMDs may result by not having to involve ADMD services in all PRMD-to-PRMD message transfers. This applies particularly to the case where there are several PRMDs in a given department. 6.1.7 Number of hierarchical naming levels The number of hierarchical naming levels within a department ranges from one (in the case of the National Library of Canada) to five (in the case of GEMDES). The naming conventions should therefore be flexible enough to accommodate a range in the number of hierarchical naming levels. The naming conventions should also accommodate the worst case of five hierarchical naming levels. 6.1.8 Name length and character set restrictions The name length and character set restrictions imposed by the variety of non-X.400 e-mail systems do not lead to an obvious solution. Many of them are more restrictive than the X.400 standard. Although a lowest common denominator approach could be chosen, it has been determined that the best approach is to adhere to the X.400 recommendations and to make use of alias and mapping functions within the non-X.400 systems. 6.1.9 Accented characters To provide full support for French names, accented characters must be available for use within O/R Addresses. However, there are a number of impediments to the full realization of this objective, and the following considerations apply. 6.1.9.1 X.400 (88)/(84) In X.400 (88) two different character sets as defined in ISO 8824 are accepted for specifying addresses: (a) PrintableString; and (b) TeletexString (T61String). However, the exclusive use of the latter is problematic since it would not be supported by X.400 (84) based systems. 6.1.9.2 X.400 (88) to X.400 (84) interoperability The downgrading rules defined in X.400 (88), for mapping O/R addressees between X.400 (88) based systems and X.400 (84) based systems, state that an O/R address cannot be downgraded if only the TeletexString has been supplied and it contains accented characters (which cannot be mapped to an equivalent PrintableString). This has the effect that it is not possible to assign O/R addresses containing only TeletexString attribute values if interoperability between X.400 (88) and X.400 (84) systems is to be achieved. The interoperability between X.400 (88) and X.400 (84) based systems is considered to be a prime requirement. 6.1.9.3 COSAC solution At a minimum, all O/R addresses shall include PrintableString values for all attributes within a given address. Optionally, for all those attributes that permit an additional TeletexString representation, i.e. for: Organization name; it is permissible to assign a second attribute value using the TeletexString. The PrintableString form will be used internally within the MHS for routing purposes. The TeletexString form, with suitable User Agent support, can be used for displays to the user. 6.2 COSAC requirements for a PRMD name A PRMD Name shall be "GC+" followed by the department's suffix which comprises the department's bilingual abbreviation. The department's bilingual abbreviation shall be in accordance with the Treasury Board of Canada Secretariat Federal Identity Program. For those departments where the English and French abbreviations are not the same, the domain name will consist of the "GC+" prefix, and the English and French abbreviations in either order, separated by the full stop ".", e.g. NLC.BNC for National Library of Canada. These abbreviations are limited to a maximum of six characters each. If the department establishes more than one PRMD, each PRMD name will consist of "GC+" appended with the department's bilingual abbreviation appended with a full stop (".") appended with the next naming level within the department. The total length of the PRMD name (including the prefix GC+) is limited to 16 characters in length and may contain only characters selected from the list in Table 1. These characters form the set PrintableString as defined in ISO 8824. It should be noted that this character set does not support accented French characters. Table 1 Allowed Characters
Note: No distinction is made between upper and lower case characters. If the department's bilingual abbreviation, together with the "GC+" prefix, consumes the full 16-character PRMD name length, and it is desired to establish more than one PRMD within the department, then the department may use only either the English or the French abbreviation, and append to it additional name components to distinguish each PRMD name. Notes: The full stop (".") is used as the separator between the English and French abbreviations in preference to the solidus ("/") which is commonly used in Government texts. This is for the following reasons: (a) the solidus is used within GEMDES as the separator between names attributes; its use as a separator between English and French name components would require the attribute be quoted in double quotation marks. (b) the full stop already has been in use for some time as a convention for distinguishing between English and French name components, e.g. the current GTA PRMD Name is "GTA.ATG" (c) it does not conflict with naming conventions used in existing messaging systems, including Internet gateways. Although the naming convention used in the TCP/IP Internet does make use of the full stop to delimit subdomains within an Internet mail address, the mapping defined in RFC 1327 between X.400 and Internet addresses permits the use of a full stop as a delimiter provided the X.400 O/R components containing the full stop are limited to the local part of the Internet mail address. Once a PRMD name (suffix) has been chosen by a given department, COSIRA shall be approached by the said department in order to register the chosen name. Subsequently, the registered name may be submitted to the Government Registration Service for centralised recording, see section 7 on Government Registration Service. Note: Currently, CSA Z243.110 states that the suffix of a PRMD name must be registered nationally with the National Registration Authority, i.e. COSIRA. 6.3 COSAC requirements for an organization name The Organizational Name shall be a value representing the next hierarchical naming level below the PRMD Name. An Organization Name is limited to a total of 64 characters and to the characters listed in Table 1. Optionally, and additionally, an equivalent TeletexString form may be selected to permit use of French accented characters. An Organization Name should be bilingual, with the English and French Names separated by a full stop. Once an Organization Name (Printable String form and optionally Teletex String form) has been chosen by a given department, the Government Registration Service may be approached by the said department in order to record the chosen name(s), see section 7 on Government Registration Service. 6.4 COSAC requirements for an organization unit names The Organizational Unit Name is optional. If used, it will consist of up to four names, listed in descending order of hierarchical significance. Each Organizational Unit Name is limited to a maximum length of 32 characters from the list of permitted characters shown in Table 1. Optionally, and additionally an equivalent TeletexString form may be selected. Once an Organizational Unit Name (PrintableString form and optionally TeletexString form) has been chosen by a given department, the Government Registration Service may be approached by the said department in order to record the chosen name(s), see section 7 on Government Registration Service. 6.5 COSAC requirements for personal names A Personal Name shall consist of the Surname, optionally followed by the Given Name, Initials and Generation-Qualifier where: (a) the Surname is limited to 40 characters in length; (b) the Given-Name is limited to 16 characters in length; (c) the Initials are limited to 5 characters in length; (d) the Generation-Qualifier is limited to 3 characters in length (e.g. "Jr", "Sr", "III". etc.). For any element above that is required a PrintableString form shall be produced with additional Teletex String form as required for full French character support if appropriate. Personal names may also be submitted to the Government Registration Service for recording, see section 7. 6.6 COSAC requirements for distribution lists For the naming of interdepartmental working groups and committees, the preceding requirements shall be applied except that: (a) An O/R address will identify a group of users rather than an individual user. The Personal Name attribute shall contain the name of the distribution list (e.g. MHS.Naming.WG); (b) The O/R address attributes of hierarchical significance above the Personal Name shall identify the departmental organization responsible for maintaining the distribution list. 6.7 COSAC requirements for common name A Common name is a standard attribute that identifies a user or distribution list, relative to an entity defined by another attribute. e.g. an Organization name. A Common name is limited to a maximum length of 64 characters from the list of permitted characters shown in Table 1. Optionally, and additionally an equivalent TeletexString form may be selected. Common names may also be submitted to the Government Registration Service for recording, see section 7. 6.8 Domain defined attributes Domain Defined Attribute Types shall be limited to 8 characters in length. Each attribute value shall be limited to 128 characters in length. The use of Domain Defined Attributes is not recommended. Preference should be given to the use of standard attributes which will maximize the standardization of MHS names within Government. 7. Government registration service GTA has established a Government Registration Service. This service is intended to provide a centralized and automated repository for items registered by the various registration authorities. The service offered by GTA is not to be confused with a registration authority. GTA only has direct authority for Organization Names directly associated with the GMHS ADMD or the GTA PRMD. As stated previously in this document, the Registration Authority for PRMD names is the National Registration Authority, COSIRA. The registration authority for elements below a given PRMD name is the department or group responsible for the given PRMD. However, Government Registration Service provided by GTA may assist departments in their registration process, and will provide a centralized repository for all registered items. Such a service may obviate the need for individual departments to retain their own database, and may assist in the production of government-wide Directories. Among other items, the Government Registration Service will record: (a) PRMD Names; (b) Organization Names; (c) Organizational Unit Names; (d) Personal Names; (e) Distribution Lists; (f) Common Names. To comply with this TBITS the requirements of this section shall be met. Equipment must be able to accommodate MHS O/R addresses of the form specified above in sections 4, 5, and 6. To comply with this TBITS departments shall design and assign O/R addresses in accordance with: (a) section 6.2 for PRMD Names; (b) section 6.3 for Organization Names; (c) section 6.4 for Organization Unit Names; (d) section 6.5 for Personal Names; (e) section 6.6 for Distribution Lists; (f) section 6.7 for Common Names. 9. Business card representation The form of an X.400 address on an individual's business card should be presented in a style that is easily mapped to the use of X.400 based mail systems. It also desirable that all departments follow a common representation. It is recommended that X.400 addresses on business cards be presented in the format recommended in Appendix F of X.402 (92): X.400: DDA:<domain-defined-type> = <domain-defined-value>/I = <initials> G = <Given-name>/S = <Surname>/Q = <Generation-Qualifier>/OU = <Organization-Unit-name>/O = <Organization-name>/P = <PRMD-name>/A = <ADMD-name>/C= <country-name> Using the form specified above, a typical example of an X.400 address shown on a business card would be: X.400: I = JR/G = Joe/S = Smith/OU = DIV3/O = Finance/P = GC+ABC.CBA/ A = GOVMT.CANADA/C= CA
Implementation Considerations A.1 Introduction This appendix contains information and guidelines considered to be useful for departments in relation to application of this TBITS. A.2 Use of GEMDES GTA has established GEMDES within the Telecom Canada ADMD as a cost-effective way for departments to gain access to the government-wide MHS from terminals and/or terminal emulators. This is accomplished by subscribing to GEMDES as one or more organizational units (GEMDES divisions). A number of government organizations have also established organizations along side of GEMDES within the Telecom Canada ADMD. These include the Senior Executive Network (SEN) and the department of Indian and Northern Affairs. All statements made in this document regarding GEMDES apply as well to other organizations that are under the management control of GTA. If the GEMDES solution is selected as the departmental mail system, the department must devise and register its organizational-unit-name(s) (GEMDES division name(s)) with GTA in accordance with the government naming guidelines and GTA registration procedures. A.3 Use of PRMDs For departments with their own private in-house mail system wishing to connect to the Government-wide MHS network, their only alternative is to register as one or more PRMDs with an ADMD. Departments choosing this alternative take on the responsibility of managing their own message transfer agents (MTAs). These PRMDs communicate with the GMHS ADMD via an MHS X.400 interface. If the PRMD solution is selected, the department must devise and register its private-domain-name(s) with COSIRA and its organization-name(s) in accordance with this TBITS. A.4 GEMDES versus PRMD solution For departments not constrained by the need to connect existing equipment, the guidelines below for a cost/benefit analysis may assist to determine whether GEMDES or an private in-house system operating as a PRMD best satisfies the department's needs. A departmental PRMD requires connection to an ADMD, such as GMHS, to obtain global interconnectivity. A.4.1 PRMD solution The following factors should be considered: (a) The ADMD may limit each PRMD to a single access point. Therefore, more than one PRMD per department may be desirable: (i) To provide more cost-effective routing of messages between the ADMD and the department; or (ii) If the performance and/or capacity of a single ADMD access point is insufficient to handle the department's projected X.400 traffic. (b) If multiple PRMDs are needed per department, PRMD boundaries should be selected to minimize installation and operational costs by minimizing: (i) The number of commercially provided links; (ii) the traffic over these links; and (iii) the length of these links. In general, this will be achieved by selecting PRMD boundaries primarily on a geographic basis and secondarily on an administrative basis. A.4.2 GEMDES solution In cooperation with GTA, a solution for the connection of terminals and/or terminal emulators to the government-wide MHS network will be developed as part of the GEMDES organization. A.4.3 Solution comparison The GEMDES solution and the PRMD solution can then be compared on the basis of: (a) Installation, operational and administrative costs; (b) constraints posed by geography, organizational configuration and administration; (c) management control of the department MHS; (d) timing, quality and responsiveness of service; (e) network management, performance, capacity and extensibility; and (f) directory support. A.5 Use of X.400 gateways Many proprietary electronic messaging systems, e.g. Novell, Banyan, Microsoft Mail, DISOSS, etc., provide X.400 gateway functions and interfaces, in order that they can be connected in the global MHS. This section is intended to provide general guidance on the naming and addressing issues to departmental representatives involved in establishing an X.400 PRMD gateway function for a proprietary local electronic mail system. A.5.1 Name/Address Mapping Users belonging to a non-X.400 system, and which is in turn connected to the Government-wide MHS, will have require two names. One will be used for addressing internal to the local system, and the other will be an O/R address for external addressing within the Government-wide MHS. The gateway product will provide the mapping between the internal and external addresses. The mapping capabilities of a given gateway may influence the choice of O/R address components and their lengths. The mapping is usually achieved by one, or a combination of the following techniques: (a) aliasing; (b) address conversion. Aliasing is a technique in which all X.400 and non-X.400 users wishing to exchange messages must have pre-assigned aliases. The gateway contains a look-up table which is used to translate between the alias names of one environment to names which will be understood by the other environment. Conversion is a technique in which address components of one environment are assigned to address components of the other environment. Thus, in this case, the two different environments share some of the components. For example, in the Microsoft Mail gateway, each of the post office and mailbox address components can be assigned to any of the X.400 standard or domain defined attributes. The remaining components are assigned hard-coded values. The aliasing technique is commonly used for outgoing from the proprietary system to the X.400 system. This technique allows for full X.400 specification and thus does not pose any problems with respect to the O/R naming requirements specified in this TBITS. Its drawback is that all names must be preassigned with the gateway before messages can be exchanged. This can be a significant problem if messaging to a large external community is desired. The use of the address conversion technique for incoming mail may imply restrictions inherited form the local system. For example, in the Microsoft X.400 gateway the X.400 attributes which are assigned network, post office and mail box address component values inherit the restriction of: (a) a maximum of 10 characters per component, and; (b) a character set limited to alphanumeric characters. A.6 Mapping between X.400 and internet addresses The address conversion techniques applicable to X.400 and the Internet mail system are specified in Internet document RFC 1327. When sending a message from an Internet system to an X.400 system the entire X.400 address is assigned to the local part of the Internet address. When sending a message from the X.400 system to the Internet, the Internet address is conveyed as domain defined attribute. Examples of Internet addressing are contained in Appendix B and C. Generally the requirements for O/R addresses specified in this TBITS cause no problems for X.400 to Internet gateways. A.7 Hierarchical naming considerations The O/R address structure mandated by this TBITS may comprise up to nine hierarchically organized levels. A Personal Name can in principle be registered directly under an ADMD or a PRMD. This approach is not recommended because of the increased likelihood of duplicate names and the associated risk of devising unfriendly user names to avoid such duplication. The acceptable superior node for a Personal Name can be any one of the following: (a) an organizational unit within the GEMDES organization; (b) an Organization Name; (c) an Organizational Unit Name under (b) above. In case (a), GTA is the Registration Authority for the Personal Name. It is recommended that departments devise and register a hierarchical naming structure consisting of at least three levels, with the department=s abbreviation at the top and the Personal Name at the bottom. A.8 Applications other than electronic mail The two principal requirements associated with applications such as EDI and ILL are: (a) the need to assign an O/R address to an application entity instead of a person; (b) the need to provide a mapping between identification information used within the application to identify the communicating parties and the assigned O/R address. The first requirement can be met satisfactorily using the mnemonic form of O/R Address used for interpersonal messaging. An application can be identified either as a distinct organization, organizational unit or person within its messaging domain. However, the use of common name is preferable to the use of personal name, and its use is recommended when X.400 (1988) implementations are widely available, but personal name is a satisfactory alternative in the interim. The second requirement stems from the fact that applications do not typically use O/R Addresses internally to identify their communication partners. For example, in the case of ILL, a library symbol is the accepted designation for identifying libraries in Canada. This results in a need within the originating system to map from this application- specific identifier to the O/R Address; this is a local requirement that can be met via a Directory lookup function. It has no impact on the requirements for the O/R Addresses themselves. A.9 User friendliness The following guidelines for user friendly naming are taken from Computer Communications, Vol 13, Introduction to Names, Addresses and Routes in an OSI Environment. These guidelines may be applied to Organization Names, Organizational Unit Names, and Common Names. Names which have a user friendly quality are oriented towards ease of use by humans. A name should be: (a) descriptive; (b) relatively static over time; (c) easy to deduce; (d) easy to understand; (e) easy to remember. A user friendly name should be unambiguous. However, the naming scheme should not introduce artificial elements in order to ensure unambiguity. For example the use of Smith1 and Smith2 should be avoided. Instead, further attributes should be used to distinguish names, such as first name or initials, etc. Common abbreviations are permissible. Unfriendly elements in a name are those which depend on entities that may change frequently. In the context of OSI, user friendly names should not contain elements which depend on underlying subnetworks (e.g. subnetwork addresses), since this necessitates an alteration to the name whenever the associated subnetwork address changes.
Addressing To/From GEMDES Users B.1 Introduction This section describes address formats for sending electronic mail messages to and from GEMDES as follows: (a) from GEMDES to PRMDs (b) from PRMDs to GEMDES (c) from GEMDES to the Internet (d) from the Internet to GEMDES B.1.1 From GEMDES to PRMDs Messages being sent from GEMDES to PRMDs must have one of the following formats in the TO: field of the GEMDES message: [ID=<ID>/<Organizational Unit Name>@<Organization Name>]<PRMD Name>/<ADMD Name>/<Country Code> or [<Given Name> <Initials> <Surname>/<Organizational Unit Name>@<Organization Name>]<PRMD Name>/<ADMD Name>/<Country Code> Usually not all of the address values shown in the above two formats are required. The values that are necessary to reach a recipient depends on how the target system has been structured to address its local users. To get the X.400 address of a user on a PRMD, inquiries must be made to either the intended recipient, the administrator of the PRMD, the GEMDES Customer Assistance Center (CAC), or the Government X.500 Directory, as appropriate. If Personal Name (Surname, Given Name, Initials, etc.) is used to identify a recipient, the second format would be used. Often, when Personal Name addressing is not supported by the local mail system, IDs are used to identify local users. In the latter case, the first format would be used. Below are some examples of what a typical address looks like from a GEMDES user to a recipient on a PRMD: (a) [John Smith /MARKETING @ SSC]GC+SSC.ASC/GOVMT.CANADA (b) [ID=M.BROWN @ HQ]GC+DEPT.X (c) [Cathy King]GC+GTA.ATG/GOVMT.CANADA If the targeted PRMD is located in CANADA then the Country Code is the default (i.e., the same as for GEMDES users) and can be omitted from the address. If the PRMD is registered under the same ADMD Name as GEMDES (i.e., ADMD Name = TELECOM.CANADA), then both the Country Code and the ADMD Name may be omitted from the address. B.1.2 From PRMDs to GEMDES When sending to a GEMDES recipient from a PRMD, the following X.400 address values shall be used:
Country Code : CA ADMD Name: TELECOM.CANADA Organization Name: <Organization> Personal Name: Surname: <Last Name> Given Name: <First Name> Initials: <Initials> Domain Defined Attribute Type: ID Domain Defined Attribute Value: <GEMDES ID> For the Organization Name, one of the following should be entered, depending to which Organization the intended GEMDES recipient belongs, e.g.: GEMDES INAC SEN.RICS TRANSPORT CANADA EIC RC.GST The GEMDES ID, or the GEMDES user's Personal Name, or both may be used to identify a GEMDES recipient. If Personal Name is used,the Personal Name information must match the information stored for that user on the GEMDES system. Some examples of X.400 addresses for GEMDES users are: Country Code : CA ADMD Name: TELECOM.CANADA Organization Name: GEMDES Personal Name: Surname: Smith Given Name: Joe Country Code : CA ADMD Name: TELECOM.CANADA Organization Name: GEMDES Domain Defined Attribute Type: ID Domain Defined Attribute Value: SMITH.J Country Code : CA ADMD Name: TELECOM.CANADA Organization Name: GEMDES Personal Name: Surname: Smith Given Name: Joe Domain Defined Attribute Type: ID Domain Defined Attribute Value: SMITH.J B.1.3 From GEMDES to the internet When sending a message from GEMDES to the Internet, the following form of address should be entered in the TO: field of the GEMDES message: [RFC-822="<Internet address>"]GC+GATE.PAS/GOVMT.CANADA For an Internet user whose address is: john@attmail.com.ca the corresponding address in the TO: field would be: [RFC-822="john(a)attmail.com.ca"]GC+GATE.PAS/GOVMT.CANADA For an Internet user whose address is: john_smith@odie.gta.doc.ca the corresponding address in the TO: field would be: [RFC-822="john(u)smith(a)odie.gta.doc.ca"]GC+GATE.PAS/GOVMT. CANADA In an Internet address where the @ symbol would normally be used, the string of characters (a) must be substituted. This is because the @ symbol is not supported by X.400 addressing. When the message gets to the Internet, the characters (a) will be converted back into the @ symbol. There are other symbols which are used in Internet addresses that are not supported by X.400 addressing. A list of these symbols and their substitutions is shown in Table B-1: Table B-1 Required Substitutions for Internet addresses
Table B-2 Characters permitted in X.400 addresses
Internet users can only receive ASCII text messages and attachments. B.1.4 From the internet to GEMDES The following Internet address format is used to identify GEMDES recipients: /C=CA/ADMD=TELECOM.CANADA /DDT =ID/DDV=<GEMDES or, alternatively: @gemdes.carleton.ca: /C = CA/ADMD=TELECOM.CANADA/DDT=ID/ For the Organization, one of the following should be entered, depending to which Organization the intended GEMDES recipient belongs: GEMDES INAC SEN.RICS The GEMDES ID, or the GEMDES user's Personal Name, or both may be used to identify a GEMDES recipient. If Personal Name is used, the Personal Name information must match the information stored for that user on the GEMDES system. Some examples of Internet addresses for GEMDES users are: /C=CA/ADMD=TELECOM.CANADA/O=GEMDES/DDT=ID/DDV= /C=CA/ADMD=TELECOM.CANADA/O=GEMDES/S=Smith/G=Joe / @gemdes.carleton.ca
Addressing Between PRMDs and the Internet C.1 Introduction This Appendix explains how to exchange messages between Internet users and users on Government PRMDs connected to GMHS. The following cases are covered: (a) from PRMDs to the Internet (b) from the Internet to PRMDs C.1.1 From PRMDs to the internet When sending a message from a PRMD to an Internet user, the following X.400 Address values are required: Country Code : CA The characters permitted and substitutions required are the same as those defined in Appendix B. For example an Internet address of: john@attmail.com.ca becomes john(a)attmail.com.ca Similarly, an Internet address of: john_smith@odie.gta.doc.ca becomes john(u)smith(a)odie.gta.doc.ca C.1.2 From the internet to PRMDs When sending messages to PRMDs from the Internet, one of the following Internet address formats has to be used: /C=<Country Code>/ADMD=<ADMD Name>/PRMD=<PRMD Name> or: @gemdes.carleton.ca:/C=<Country Code>/ADMD=<ADMD Name>
Usually not all of the address values shown in the above two formats are required. The values required to reach a recipient depend on how the target system has been structured to address its local users. To get the X.400 address of a user on a PRMD, either the intended recipient, the administrator of the PRMD must be consulted. Often, the Domain Defined Attribute Type "ID" is used to identify a recipient's Mailbox or ID on the target system. This is usually the case when Personal Name addressing is not supported by the target system. Some examples of Internet addresses for users on Governmental PRMDs are as follows: /C=CA/ADMD=GOVMT.CANADA/PRMD=GC+SSC.ASC/S=Smith/G=John/ @gemd es.carleton.ca /C=CA/ADMD=TELECOM.CANADA/PRMD=GC+DEPT.X/O=DEPTX/ /C=CA/ADMD=GOVMT.CANADA/PRMD=GC+EMR/O=EMR/OU=ITB/
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
||||||||
|
 Top of Page |
Important Notices | ||||||
