“X.400”的意思、由来-开放百科全书

X.400 is a suite of ITU-T Recommendations that define standards for Data Communication Networks for Message Handling Systems (MHS) — more commonly known as email.

At one time, the designers of X.400 were expecting it to be the predominant form of email, but this role has been taken by the SMTP-based Internet e-mail. Despite this, it has been widely used within organizations and was a core part of Microsoft Exchange Server until 2006; variants continue to be important in military and aviation contexts.

History

The first X.400 Recommendations were published in 1984 (Red Book), and a substantially revised version was published in 1988 (Blue Book). New features were added in 1992 (White Book) and subsequent updates. Although X.400 was originally designed to run over the OSI transport service, an adaptation to allow operation over TCP/IP, RFC 1006, has become the most popular way to run X.400.

Developed in cooperation with the ISO, the X.400-series recommendations specify OSI standard protocols for exchanging and addressing electronic messages. The companion F.400-series of recommendations define Message Handling Services built on Message Handling Systems (MHS), as well as access to and from the MHS for public services. In the late 1990s, the ITU-T consolidated recommendations F.400 and X.400 and published the ITU-T F.400/X.400 (06/1999) recommendation "Message handling system and service overview".

The X.400-series recommendations define the technical aspects of the MHS: ITU-T Rec. X.402 | (ISO/IEC 10021-2) defines the overall system architecture of an MHS, ITU-T Rec. X.411 | (ISO/IEC 10021-4) defines the Message Transfer Service (MTS) and its functional component the Message Transfer Agent (MTA), and ITU-T Rec. X.413 | (ISO/IEC 10021-5) defines the Message Store. All ITU-T recommendations provide specific terms for descriptions of system entities and procedures. For example, messages (email) exchanged among people is referred to as Interpersonal Messaging (IPM); electronically structured business documents (e.g., invoices, purchase orders, dispatch advice, etc.) exchanged among trading partners’ computers fall under the EDI protocols.

Message handling is a distributed information processing task that integrates two related subtasks: message transfer and message storage. The ITU-T Recommendations define specific protocols for a wide range of communication tasks. For example, the P1 protocol is used explicitly for communication among MTAs, P3 between the user agent and an MTA, and P7 between the user agent and message store.

In the 1994 version, P7 was enhanced to provide folders in the message store, allow storage of submitted messages, and provide many automatic actions such as auto-foldering and correlation of replies, delivery reports and receipt notifications with submitted messages.

X.400 message content standards are defined for communication between user agents. These are modelled as conceptual protocols that treat P1 and P3/P7 as providing an underlying reliable transport of message contents. The message content standard for interpersonal messaging, IPM, defined in ITU-T Rec. X.420 | ISO/IEC 10021-7 was named P2 in the Red Book. The extended version of IPM in the Blue Book was given content-type 22 (for P2 version 2) and is often referred to informally as P22, although that term is not used in the standards. The message content standard for EDI is defined in ITU-T Rec. F.435 | ISO/IEC 10021-8 and ITU-T Rec. X.435 | ISO/IEC 10021-9, and informally referred to as P35. A voice messaging content type is defined in ITU-T Recs. F.440 and X.440.

Exchange Server 2007 does not use the MTA object, and the X.400 connector (which must use the MTA) is gone in Exchange Server 2007. There are no longer any X.400 default proxy e-mail addresses in Exchange Server 2007.^[1]

Important features of X.400 include structured addressing, ASN.1 binary code enabling multimedia content (predating and more efficient than MIME), and integrated security capabilities. As X.400 inter-domain relay services were assumed by ITU to be run by PTTs, X.400 incorporated fields for the automated transfer of messages between X.400 and other PTT services, such as Telex, facsimile and physical postal mail. ISO later added open routing standards (ITU-T Rec. X.412 | ISO/IEC 10021-10 and ITU-T Rec. X.404 | ISO/IEC 10021-11), but the initial misconception that X.400 required PTT relay services, coupled with PTT volume-based charges for these, were factors that inhibited the widespread uptake of X.400.

Implementation

From the late 1980s, many major countries committed to the OSI stack, via GOSIP - Government Open Systems Interconnection Profiles. In the United States this was in the form of the 1990 NIST "Federal Information Processing Standard" (FIPS #146). In turn, major computer vendors committed to producing OSI-compliant products, including X.400. Microsoft's Exchange Server was developed in this time period, and internally based on X.400/X.500 - with the initial release "equally happy to dispatch messages via Messaging API (MAPI), X.400, or Simple Mail Transfer Protocol (SMTP)".^[2] In practice however, most of these were poorly produced, and seldom put into operation.

In North America, many large defense contractors and universities had also already committed to the Internet and TCP/IP standards, including SMTP for email. There, X.400 is still used in some applications, such as the military, intelligence services and aviation, mainly because the X.400 functions for integrity and security were developed and deployed much earlier than their SMTP counterparts (S/MIME, PGP and SMTP-TLS). For similar reasons, it is sometimes used for transmission of EDI messages between applications.

In Europe, South America, and Asia, X.400 is quite widely implemented{{Citation needed|date=October 2008}}, especially for EDI services.

X.400 has been extended for use in military applications (see MMHS) and aviation (see AMHS).

Addressing

One of the core issues X.400 attempted to address was the failure of an email to be properly delivered when the address was not specified correctly. At the time, addressing formats varied from platform to platform, so it was difficult for users to know how to properly type them in. Any error caused the delivery to fail outright. This was in contrast to the "real" postal service, where even partial addresses would be routed to a dead letter office where they will attempt to deliver it even if some of the information is missing or wrong.{{efn|In one famous example, a letter reached air-crash survivor Helen Klaben after being addressed only "To the woman that spent 45 days in the arctic".^[3]}}

To solve this problem, the X.400 address scheme included several redundant fields that could be used to help deliver the message. For instance, there were separate fields for first and last name, as well as initials. The server was identified with multiple fields, including a company or organization name, as well as the country. The idea was that an address with a misspelt name of the company, for instance, would still contain enough information, the person's name and country, for the message to be properly routed.

At the time, it was believed that email would be provided by large service providers, often the national telephone companies. This meant that as long as the message reached the service provider, indicated by the "Administration Management Domain" portion of the address, the system would likely know of the user in question. As this service provider was likely national in scope, simply providing the right country code could be enough information to route the message properly.

However, this model fails when the email services are provided by the user's company or organization, or when the service provider is not known. In this case, there is no national-scale database of users and an improper organization name is enough to cause it to fail. This is the dominant model today, where companies use an internal server, or even more commonly, use a provider like Gmail, which is invisible outside the organization, and even to the users. In this model, the ADMD is unknown or the same as the organization itself.

This multi-part addressing system also led to the format being complex; users were not sure which fields were important and tended to provide all that they could. This made trivial things, like printing the address on a business card or typing it into the email client more difficult than simpler systems like those found in SMTP. The unwieldiness of this addressing format is believed by many to be one factor in the lack of success of X.400.^[4]

An X.400 address is technically referred to as an Originator/Recipient (OR) address. It has two purposes:

The standards themselves originally did not specify how these email addresses should be written (for instance on a business card) or even whether the field identifiers should be upper or lower case, or what character sets were allowed. RFC 1685 specified one encoding, based on a 1993 draft of ITU-T Recommendation F.401, which looked like:

In the 1988 X.400 Recommendations, four forms of addressing were delineated. The 1984 Form 1, Variant 1 format was renamed as the mnemonic O/R address and the 1984 Form 1, Variant 3 and Form 2 format were combined and renamed the terminal O/R address. New forms introduced were the numeric O/R form (a variation of Form 1, Variant 2) and the postal O/R address.

The first large-scale use was conducted in the U.S. under a military communication contract in 1992 to 1997.

X.500 directories

The confusion caused by the X.400 addressing format led to the creation of the X.500 standard for directory services. The idea was to create a hierarchical and standardized email address directory with replication and distribution functionality that allowed multiple organizations to produce a single public directory. For instance, each Administration Management Domain (service provider) could optionally upload their directory to a shared X.500 server, and then allow this database to be searched by the X.400 User Agents during email creation, thereby avoiding needing to know anything about the address other than the recipient's name and some sort of organizational name like a company.^[7]

Unfortunately, the X.500 protocol proved to be every bit as complex and unwieldy as X.400, and this led to the creation of the Lightweight Directory Access Protocol, or LDAP, that standardized a simple subset of the X.500 protocols suitable for use by end-user software searching for addresses. LDAP is widely used in directory services like Microsoft's Active Directory.^[7]

Additionally, the goal of providing a universal address database was fundamentally flawed by the time it was proposed. In the era of national telecommunications companies like Bell Canada or France Télécom, people's names and phone numbers were considered public information and already collected into such directories in the form of the phone book. Extending this to email addresses seemed obvious. However, this was simply not the case in the 1980s; at that time, email was often associated with a business or government users, and those organizations treated these addresses as valuable, or even confidential. There was no reason for the organizations to share this information with anyone else; as RFC2693 put it, "imagine the CIA adding its directory of agents to a world-wide X.500 pool".^[8]

History

Implementation

Addressing

X.500 directories

See also

Notes

References

General references

Further reading

ITU-T X.400 Recommendations

External links