RFC1616 日本語訳
1616 X.400(1988) for the Academic and Research Community in Europe.RARE WG-MSG Task Force 88, E. Huizer, J. Romaguera, Eds.. May 1994. (Format: TXT=107432 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group RARE WG-MSG Task Force 88 Request for Comments: 1616 May 1994 RARE Technical Report: 10 Category: Informational
Network Working Group RARE WG-MSG Task Force 88 Request for Comments: 1616 May 1994 RARE Technical Report: 10 Category: Informational
X.400(1988) for the Academic and Research Community in Europe
X.400(1988) for the Academic and Research Community in Europe
A report by the RARE Task Force on X.400(1988)
of the RARE Working Group on Mail & Messaging
A report by the RARE Task Force on X.400(1988) of the RARE Working Group on Mail & Messaging
Status of this Memo
Status of this Memo
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
1. Abstract
1. Abstract
The European research and development community, as represented by the member research networks of RARE, has lead the deployment within the global R&D community of X.400 electronic messaging services, as specified in the international recommendations CCITT X.400(1984), for more than five years. As a result of providing such services to the European R&D users it has become clear that there is an existing and ever increasing demand from these users for new and enhanced electronic messaging services and product to be used to communicate within the R&D community but within commercial service providers and organisations as well.
The European research and development community, as represented by the member research networks of RARE, has lead the deployment within the global R&D community of X.400 electronic messaging services, as specified in the international recommendations CCITT X.400(1984), for more than five years. As a result of providing such services to the European R&D users it has become clear that there is an existing and ever increasing demand from these users for new and enhanced electronic messaging services and product to be used to communicate within the R&D community but within commercial service providers and organisations as well.
It is also clear that new services, such as Multimedia messaging and Secure messaging, and the resulting products promise dramatic benefits and opportunities, for not only the R&D community but also for the wider commercial, industrial and public communities, in terms of facilitating innovative ways of working and living which can only enhance the missions and goals of the respective communities. Not least the establishment of globally pervasive messaging services between all users, R&D and commercial, is facilitated by the early adoption of such advanced new services. An indication of the importance of such a messaging service can be appreciated if one considers that in many organizations (especially commercially based) messaging may be the only method to communicate between independent organizations due to security considerations and lower layer network differences.
It is also clear that new services, such as Multimedia messaging and Secure messaging, and the resulting products promise dramatic benefits and opportunities, for not only the R&D community but also for the wider commercial, industrial and public communities, in terms of facilitating innovative ways of working and living which can only enhance the missions and goals of the respective communities. Not least the establishment of globally pervasive messaging services between all users, R&D and commercial, is facilitated by the early adoption of such advanced new services. An indication of the importance of such a messaging service can be appreciated if one considers that in many organizations (especially commercially based) messaging may be the only method to communicate between independent organizations due to security considerations and lower layer network differences.
The Commission of European Communities (CEC) VALUE subprogram II has been established to support initiatives relating to the development and adaptation of R&D networks in member states. Amongst other
The Commission of European Communities (CEC) VALUE subprogram II has been established to support initiatives relating to the development and adaptation of R&D networks in member states. Amongst other
RARE WG-MSG Task Force 88 [Page 1] RFC 1616 X.400(88) for European Academics and Research May 1994
RARE WG-MSG Task Force 88 [Page 1] RFC 1616 X.400(88) for European Academics and Research May 1994
initiatives the VALUE program supports X.400 initiatives in certain countries. VALUE support has so far been limited to X.400(1984) initiatives, as X.400(1984) has up until now been the dominating OSI services. However as X.400(1988) implementations have started to appear a VALUE funded study of the X.400(1988) aspects of messaging and their impact on the R&D community was felt necessary. This report is one of the results of that study.
initiatives the VALUE program supports X.400 initiatives in certain countries. VALUE support has so far been limited to X.400(1984) initiatives, as X.400(1984) has up until now been the dominating OSI services. However as X.400(1988) implementations have started to appear a VALUE funded study of the X.400(1988) aspects of messaging and their impact on the R&D community was felt necessary. This report is one of the results of that study.
The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. Open reviews of the report have occurred in the RARE Mail and Messaging Work Group and within the IETF X.400ops Working Group.
The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. Open reviews of the report have occurred in the RARE Mail and Messaging Work Group and within the IETF X.400ops Working Group.
The scope of the report is limited to deployment of X.400(1988) services, and as such the report does not contain any recommendations on development and deployment of Internet RFC 822 / MIME/ PEM related (pilot) services. However, since the report shows that both X.400(1988) and RFC 822 / MIME / PEM will be developed and used within the European R&D community, such a pilot should also considered. Note: RFC 822 is also known as Internet STD 11.
The scope of the report is limited to deployment of X.400(1988) services, and as such the report does not contain any recommendations on development and deployment of Internet RFC 822 / MIME/ PEM related (pilot) services. However, since the report shows that both X.400(1988) and RFC 822 / MIME / PEM will be developed and used within the European R&D community, such a pilot should also considered. Note: RFC 822 is also known as Internet STD 11.
Circulation of this report is unlimited. Comments on this report may be sent to the e-mail distribution list:
Circulation of this report is unlimited. Comments on this report may be sent to the e-mail distribution list:
RFC 822: wg-msg@rare.nl
X.400: S=wg-msg;O=rare;P=surf;A=400net;C=nl;
RFC 822: wg-msg@rare.nl X.400: S=wg-msg;O=rare;P=surf;A=400net;C=nl;
Task Force Members:
Task Force Members:
Claudio Allocchio (INFN),
Harald T. Alvestrand (SINTEF),
James C. I. Craigie (JNT),
Urs Eppenberger (SWITCH),
Frode Hernes (maXware),
Jeroen Houttuin (RARE),
Erik Huizer (SURFnet) - chairman,
Steve Kille (ISODE Consortium),
James A. (Jim) Romaguera (NetConsult).
Claudio Allocchio (INFN), Harald T. Alvestrand (SINTEF), James C. I. Craigie (JNT), Urs Eppenberger (SWITCH), Frode Hernes (maXware), Jeroen Houttuin (RARE), Erik Huizer (SURFnet) - chairman, Steve Kille (ISODE Consortium), James A. (Jim) Romaguera (NetConsult).
Editors: James A. (Jim) Romaguera & Erik Huizer
Editors: James A. (Jim) Romaguera & Erik Huizer
The work of this Task Force has been funded by the Commission of European Communities (CEC) VALUE subprogram II, Stichting SURF and SURFnet bv.
The work of this Task Force has been funded by the Commission of European Communities (CEC) VALUE subprogram II, Stichting SURF and SURFnet bv.
RARE WG-MSG Task Force 88 [Page 2] RFC 1616 X.400(88) for European Academics and Research May 1994
RARE WG-MSG Task Force 88 [Page 2] RFC 1616 X.400(88) for European Academics and Research May 1994
Table of Contents
Table of Contents
1. Abstract 1
2. Management Summary 3
3. Framework for the report 6
4. Present situation of European Messaging 7
4.1. Messaging services 7
4.2. Requirements for messaging 8
4.2.1. User Oriented 9
4.2.2. Service provider viewpoint 10
4.3. Messaging capabilities 11
5. Possible solutions for providing globally pervasive
messaging 12
5.1. PC LAN E-mail systems 13
5.2. RFC 822, MIME and PEM services 15
5.3. X.400 - 1984 and 1988 19
6. Migration to X.400(1988) 23
6.1. PC LAN E-mail systems 25
6.2. RFC 822, MIME and PEM services 25
6.3. X.400(1984) services 27
6.4. Mail-11 services 28
7. Benefits of migrating to X.400(1988) and the involved costs 28
8. Main Recommendations 33
9. Security Considerations 34
10. Reading List and Bibliography 35
11. Terminology 37
Appendix A - Elaboration on the main recommendations 38
Appendix B - A number of detailed guidelines. 40
Authors' Addresses 44
1. Abstract 1 2. Management Summary 3 3. Framework for the report 6 4. Present situation of European Messaging 7 4.1. Messaging services 7 4.2. Requirements for messaging 8 4.2.1. User Oriented 9 4.2.2. Service provider viewpoint 10 4.3. Messaging capabilities 11 5. Possible solutions for providing globally pervasive messaging 12 5.1. PC LAN E-mail systems 13 5.2. RFC 822, MIME and PEM services 15 5.3. X.400 - 1984 and 1988 19 6. Migration to X.400(1988) 23 6.1. PC LAN E-mail systems 25 6.2. RFC 822, MIME and PEM services 25 6.3. X.400(1984) services 27 6.4. Mail-11 services 28 7. Benefits of migrating to X.400(1988) and the involved costs 28 8. Main Recommendations 33 9. Security Considerations 34 10. Reading List and Bibliography 35 11. Terminology 37 Appendix A - Elaboration on the main recommendations 38 Appendix B - A number of detailed guidelines. 40 Authors' Addresses 44
2. Management Summary
2. Management Summary
This document reports the results of study of the X.400(1988) aspects of messaging and their impact on the R&D community. The study was funded by the CEC under VALUE Subprogram II and has been carried out by a task force on the RARE Mail Working Group. The document is targeted at technical decision makers as well as those who would fund activity in this area.
This document reports the results of study of the X.400(1988) aspects of messaging and their impact on the R&D community. The study was funded by the CEC under VALUE Subprogram II and has been carried out by a task force on the RARE Mail Working Group. The document is targeted at technical decision makers as well as those who would fund activity in this area.
The document presents the existing situation as regards the predominate messaging technologies within Europe. These are presented within the context of a number of large messaging communities that are using these technologies:
The document presents the existing situation as regards the predominate messaging technologies within Europe. These are presented within the context of a number of large messaging communities that are using these technologies:
- RFC 822,
- X.400(1984),
- Mail-11 and
- PC LAN messaging
- RFC 822, - X.400(1984), - Mail-11 and - PC LAN messaging
RARE WG-MSG Task Force 88 [Page 3] RFC 1616 X.400(88) for European Academics and Research May 1994
RARE WG-MSG Task Force 88 [Page 3] RFC 1616 X.400(88) for European Academics and Research May 1994
Three major European communities are referenced:
Three major European communities are referenced:
- Commercial service providers
- R&D community
- Commercial organisations using messaging services.
- Commercial service providers - R&D community - Commercial organisations using messaging services.
The report states the following facts:
The report states the following facts:
- The resources, human or financial, to operate multiple wide
area messaging services connecting together independent
organisations are high. As such it is desirable to try and
keep to a minimum the number of such services. This statement
is true for the R&D community but is also highly likely to be
valid for the general European industry.
- The resources, human or financial, to operate multiple wide area messaging services connecting together independent organisations are high. As such it is desirable to try and keep to a minimum the number of such services. This statement is true for the R&D community but is also highly likely to be valid for the general European industry.
- There are two publicly available technological standards
that can be used by open communities, such as the R&D
community and public service providers: the X.400(1984 and
1988) recommendations and the Internet RFC 822 / MIME / PEM
standards.
- There are two publicly available technological standards that can be used by open communities, such as the R&D community and public service providers: the X.400(1984 and 1988) recommendations and the Internet RFC 822 / MIME / PEM standards.
- There is an established very large global user base of
Internet RFC 822 and X.400(1984) messaging services. Both
services have their own momentum within different parts of
the user community, both are still developing and growing
fast.
- There is an established very large global user base of Internet RFC 822 and X.400(1984) messaging services. Both services have their own momentum within different parts of the user community, both are still developing and growing fast.
The report concludes that X.400(1988) will be the preferred protocol for inter organizational connection for European industry and government and parts of the European R&D community. RFC 822 / MIME / PEM will be the preferred protocol suite for inter-organisational connection for the Internet community and, as products are already widely available, it is the preferred protocol for parts of the European R&D community.
The report concludes that X.400(1988) will be the preferred protocol for inter organizational connection for European industry and government and parts of the European R&D community. RFC 822 / MIME / PEM will be the preferred protocol suite for inter-organisational connection for the Internet community and, as products are already widely available, it is the preferred protocol for parts of the European R&D community.
The goal of European pervasive messaging - incorporating Industry, Government and Academia - would be best accommodated and reached by the establishment of a single messaging service. However taking the above into account, this is not feasible, as X.400(84 and 88) and RFC 822( and MIME) based services will be around for a long time to come. To increase the functionality of Wide Area E-mail services there is a clear necessity to:
The goal of European pervasive messaging - incorporating Industry, Government and Academia - would be best accommodated and reached by the establishment of a single messaging service. However taking the above into account, this is not feasible, as X.400(84 and 88) and RFC 822( and MIME) based services will be around for a long time to come. To increase the functionality of Wide Area E-mail services there is a clear necessity to:
- migrate RFC 822 services to a RFC 822 / MIME / PEM service.
A MIME based service offers more functionality to the user
than a plain RFC 822 service.
- migrate RFC 822 services to a RFC 822 / MIME / PEM service. A MIME based service offers more functionality to the user than a plain RFC 822 service.
- migrate existing X.400 services to a X.400(1988) service.
- migrate existing X.400 services to a X.400(1988) service.
RARE WG-MSG Task Force 88 [Page 4] RFC 1616 X.400(88) for European Academics and Research May 1994
RARE WG-MSG Task Force 88 [Page 4] RFC 1616 X.400(88) for European Academics and Research May 1994
Due to the lack of scalability of the X.400(1984) service in
terms of extra functionality, it will become increasingly
difficult to meet the needs of research users of existing
X.400(1984) services unless an X.400(1988) service is put
into place.
Due to the lack of scalability of the X.400(1984) service in terms of extra functionality, it will become increasingly difficult to meet the needs of research users of existing X.400(1984) services unless an X.400(1988) service is put into place.
- provide a transparent gateway between X.400(1988) and RFC
822/MIME/PEM. For the European R&D community it is essential
to have a transparent gateway between the X.400(1988) service
and the RFC 822 / MIME / PEM service, thus ensuring
connectivity between these two services with a maximum
functionality.
- provide a transparent gateway between X.400(1988) and RFC 822/MIME/PEM. For the European R&D community it is essential to have a transparent gateway between the X.400(1988) service and the RFC 822 / MIME / PEM service, thus ensuring connectivity between these two services with a maximum functionality.
Such a gateway is technically feasible and it is an essential part of an unified E-mail service. Without such a standardised gateway the overall E-mail service would deteriorate.
Such a gateway is technically feasible and it is an essential part of an unified E-mail service. Without such a standardised gateway the overall E-mail service would deteriorate.
The lack of open standards for the PC LAN messaging systems discourages their use as 'backbone' messaging technologies within open communities. However the products that these systems deliver to end users ensures that their already large share of the messaging market will continue to exist for some time. Thus it is also essential that strategies that allow these systems to be 'seamlessly' integrated within the global messaging community are put in place. Not least due to the indications that the main messaging vendors are developing X.400(1988) and RFC 822/MIME gateways, a strategy to link these systems together via X.400 and RFC 822 should be developed.
The lack of open standards for the PC LAN messaging systems discourages their use as 'backbone' messaging technologies within open communities. However the products that these systems deliver to end users ensures that their already large share of the messaging market will continue to exist for some time. Thus it is also essential that strategies that allow these systems to be 'seamlessly' integrated within the global messaging community are put in place. Not least due to the indications that the main messaging vendors are developing X.400(1988) and RFC 822/MIME gateways, a strategy to link these systems together via X.400 and RFC 822 should be developed.
The report concludes with a set of recommendations, the main one being the establishment of a X.400(1988) European pilot messaging service for the R&D community. This pilot should include the establishment of a transparent gateway service between X.400(1988) and RFC 822/MIME. The goal of a European pilot is to ensure the successful deployment of a European wide operational X.400(1988) service that is pervasive and meets the needs of users. By collecting together the issues related to the establishment of a European X.400(1988) service, this report acts as a focal point and stimulant for discussion on this topic within the R&D community. In the report a summary of the benefits and problems of each of the above messaging technologies within the context of achieving a global messaging service, of which the R&D community is one part, is presented. Further the document identifies issues, strategies and recommendations related to the migration and coexistence of these technologies within the scope of mainly the European R&D community but also in relation to other messaging communities. A cost / benefit analysis on the establishment of a European wide pilot X.400(1988) messaging service is also presented. Finally a reading list of references related to this subject has been compiled.
The report concludes with a set of recommendations, the main one being the establishment of a X.400(1988) European pilot messaging service for the R&D community. This pilot should include the establishment of a transparent gateway service between X.400(1988) and RFC 822/MIME. The goal of a European pilot is to ensure the successful deployment of a European wide operational X.400(1988) service that is pervasive and meets the needs of users. By collecting together the issues related to the establishment of a European X.400(1988) service, this report acts as a focal point and stimulant for discussion on this topic within the R&D community. In the report a summary of the benefits and problems of each of the above messaging technologies within the context of achieving a global messaging service, of which the R&D community is one part, is presented. Further the document identifies issues, strategies and recommendations related to the migration and coexistence of these technologies within the scope of mainly the European R&D community but also in relation to other messaging communities. A cost / benefit analysis on the establishment of a European wide pilot X.400(1988) messaging service is also presented. Finally a reading list of references related to this subject has been compiled.
RARE WG-MSG Task Force 88 [Page 5] RFC 1616 X.400(88) for European Academics and Research May 1994
RARE WG-MSG Task Force 88 [Page 5] RFC 1616 X.400(88) for European Academics and Research May 1994
The report does not include any recommendations on development and deployment of RFC 822 / MIME / PEM related (pilot) services, as these are outside of the scope of the Task Force. However, since the report shows that both X.400(1988) and RFC 822 / MIME / PEM will be developed and used within the European R&D community, such a pilot should also be considered.
The report does not include any recommendations on development and deployment of RFC 822 / MIME / PEM related (pilot) services, as these are outside of the scope of the Task Force. However, since the report shows that both X.400(1988) and RFC 822 / MIME / PEM will be developed and used within the European R&D community, such a pilot should also be considered.
3. Framework for the report
3. Framework for the report
With the belief that user demands for new messaging services such as Multimedia and Secure Messaging would develop, the RARE community (together with other communities; most notably the Internet Engineering Task Force (IETF)) has over the preceding years experimented in new messaging and related technologies. Experiments and pilots, have been performed in messaging services e.g., as recommended by CCITT X.400(1988) and Directory Services based upon the CCITT X.500(1988) recommendations.
With the belief that user demands for new messaging services such as Multimedia and Secure Messaging would develop, the RARE community (together with other communities; most notably the Internet Engineering Task Force (IETF)) has over the preceding years experimented in new messaging and related technologies. Experiments and pilots, have been performed in messaging services e.g., as recommended by CCITT X.400(1988) and Directory Services based upon the CCITT X.500(1988) recommendations.
The results of such pilots and experiments indicate that it is now opportune to commence a pilot X.400(1988) messaging service for the European R&D community. The major goals of the pilot being, to
The results of such pilots and experiments indicate that it is now opportune to commence a pilot X.400(1988) messaging service for the European R&D community. The major goals of the pilot being, to
- establish a large scale European wide pilot messaging
service based on X.400(1988).
- establish a large scale European wide pilot messaging service based on X.400(1988).
- collaborate with and facilitate the commencement of similar
pilot services within diverse communities; both R&D and non-
R&D (e.g., commercial ADMDs and PRMDs, etc.); both European
and non-European (e.g., North American , Asian, etc.).
- collaborate with and facilitate the commencement of similar pilot services within diverse communities; both R&D and non- R&D (e.g., commercial ADMDs and PRMDs, etc.); both European and non-European (e.g., North American , Asian, etc.).
- encourage and assist the development and deployment of a
wide variety of commercial and public domain X.400(1988)
messaging products that meet the user's needs, for instance
X.400(1988) products such as User Agents (UAs), Message
Stores (MSs), Message Transfer Agents (MTAs) and gateways
between X.400(1988) services and other widespread messaging
services i.e., RFC 822, Mail-11 and proprietary.
- encourage and assist the development and deployment of a wide variety of commercial and public domain X.400(1988) messaging products that meet the user's needs, for instance X.400(1988) products such as User Agents (UAs), Message Stores (MSs), Message Transfer Agents (MTAs) and gateways between X.400(1988) services and other widespread messaging services i.e., RFC 822, Mail-11 and proprietary.
- prove that such a service and products efficiently meets the
existing and expected demands for new messaging services by
European R&D users. And as such determine the steps for a
European deployment of an operational X.400(1988) messaging
service.
- そのようなサービスと製品がヨーロッパ人の研究開発ユーザで効率的に新しいメッセージングサービスを求める存在と予想需要を満たすと立証してください。 そして、そういうものとして操作上のX.400(1988)メッセージングサービスのヨーロッパの展開のためのステップを決定してください。
- determine the needed steps to facilitate migration for the
existing operational R&D X.400(1984) based messaging service,
as represented by the R&D MHS service (the former COSINE
MHS), RFC 822 / MIME / PEM based messaging services and the
- そして必要なステップがサービスを通信させながら基づく既存の操作上のR&D X.400(1984)のために移行を容易にすることを決定してください、R&D MHSサービス(元COSINE MHS)で表されるように、サービスを通信させながら基づくRFC822/MIME/PEM。
RARE WG-MSG Task Force 88 [Page 6] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[6ページ]RFC1616X.400(88)
HEPnet / SPAN Mail-11 based messaging service to an
operational X.400(1988) messaging service. It is self evident
that during such migrations, transition steps must be
included that allow a period of coexistence, at the highest
possible service level, between X.400(1988), X.400(1984), RFC
822 / MIME and HEPnet / SPAN Mail-11 services.
HEPnet / SPANメール-11は操作上のX.400(1988)メッセージングサービスに対するメッセージングサービスを基礎づけました。 そのような移行の間共存の一区切りを許容する変遷ステップを含んでいなければならないのは自明です、可能な限り高いサービスレベルで、X.400(1988)と、X.400(1984)と、RFC822/MIMEとHEPnet / SPANメール-11サービスの間で。
- determine the needed steps that allow proprietary messaging
systems, that are widely deployed within the European R&D
community to be integrated at as high as possible service
level, by an X.400(1988) infrastructure.
- できるだけ高く統合している独占メッセージシステムを許容して、ヨーロッパの研究開発共同体の中で広く配布される必要なステップがレベルを修理することを決定してください、X.400(1988)インフラストラクチャで。
This report identifies the issues involved in such a pilot service. It is not a concrete proposal for such a project but the report discusses advantages and disadvantages, costs and enefits and migration issues for deploying a X.400(1988) service. As such it is a discussion and feasibility paper on the creation of a large scale European wide pilot X.400(1988) messaging service for the European R&D community.
このレポートはそのようなパイロットサービスにかかわる問題を特定します。 それはプロジェクトにもかかわらず、レポートが利点、損失、コスト、enefits、および移行問題について議論するそのようなもののためのX.400(1988)がサービスであると配布する具体的な提案ではありません。 そういうものとして、それは、大規模ヨーロッパのヨーロッパの研究開発共同体に、広いパイロットX.400(1988)メッセージングサービスの作成に関する議論と実行可能性論文です。
4. Present situation of European Messaging
4. ヨーロッパのMessagingの現在の状況
4.1. Messaging services
4.1. メッセージングサービス
Electronic messaging within Europe can be viewed as a number of messaging services communities. Three important communities comprise,
多くのメッセージングサービス共同体としてヨーロッパの中の電子メッセージ通信を見なすことができます。 重要な共同体が含む3
- Commercial e-mail networks,
- Research e-mail networks and
- PC LAN messaging systems.
- そして、商用電子メールネットワーク--メールネットワークについて研究してください、--PC LANメッセージシステム。
Commercial e-mail networks are classified as either ADMDs or PRMDs. ADMDs and PRMDs are operating in nearly every European country.
商用電子メールネットワークはADMDsかPRMDsのどちらかとして分類されます。 ADMDsとPRMDsはほとんどあらゆるヨーロッパの国で作動しています。
- ADMD services (or public commercial e-mail services) are
provided by over 50 service providers which have
interconnected using the X.400(1984) protocols. The topology
between these ADMDs, although not yet 'mesh', can be stated
as progressing quite rapidly to this optimum goal. However
there is still a way to go before ADMDs provide full European
connectivity.
- ADMDサービス(または、公共の商用電子メールサービス)はX.400(1984)プロトコルを使用することで内部連絡した50以上のサービスプロバイダーによって提供されます。 しかし、'メッシュ'ではありませんが、全く急速にこの最適な目標に進んでいるとしてこれらのADMDsの間のトポロジーを述べることができます。 しかしながら、まだ、ADMDsが完全なヨーロッパの接続性を提供する前に行く方法があります。
- PRMDs (or private commercial e-mail service providers) have
interconnected to ADMDs and other PRMDs predominantly using
the X.400(1984) protocols but also with proprietary
protocols.
- PRMDs(または、私設の商用電子メールサービスプロバイダー)は、プロトコルですが、固有のプロトコルをもってX.400(1984)を支配的に使用することでADMDsと他のPRMDsに内部連絡しました。
RARE WG-MSG Task Force 88 [Page 7] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[7ページ]RFC1616X.400(88)
Research networks are providing messaging services in every European country. These R&D service providers are operated as either ADMDs or PRMDs and are using both X.400(1984) protocols and Internet RFC 822 protocols to connect to each other.
研究ネットワークはあらゆるヨーロッパの国にメッセージングサービスを提供しています。 これらの研究開発サービスプロバイダーは、ADMDsかPRMDsのどちらかとして運用されて、互いに接するのにX.400(1984)プロトコルとインターネットRFC両方の822のプロトコルを使用しています。
Moreover, there are also large R&D communities (i.e., HEPnet and SPAN) using proprietary protocols (i.e., DECnet Phase IV and Mail-11) as their main messaging systems. The DECnet IV based communities are now migrating to DECnet Phase V (OSI connectionless protocol stack), which provides X.400(1988) (plus X.400(1984)) as a major messaging system. In general, all these services are totally interconnected. As such it is a statement of fact that there exists within the European R&D community, two parallel interconnected messaging infrastructures based upon X.400(1984) and RFC 822. However interconnections between the R&D messaging community and the majority of the European commercial service providers use the X.400(1984) protocols.
そのうえ、また、それらの主なメッセージシステムとして固有のプロトコル(すなわち、DECnet Phase IVとメール-11)を使用する大きい研究開発共同体(すなわち、HEPnetとSPAN)があります。DECnetのIVのベースの共同体は現在、DECnet Phase V(OSIのコネクションレスなプロトコル・スタック)にわたっています。(DECnet Phaseは主要なメッセージシステムとしてX.400(1988)(プラスX.400(1984))を提供します)。 一般に、これらのすべてのサービスが完全にインタコネクトされます。 そういうものとして、それはヨーロッパの研究開発共同体の中に存在している事実の声明です、X.400(1984)とRFC822に基づく2つの平行なインタコネクトされたメッセージングインフラストラクチャ。 しかしながら、研究開発メッセージング共同体とヨーロッパの商業サービスプロバイダーの大部分の間のインタコネクトはX.400(1984)プロトコルを使用します。
It is also clear that the commercial world mostly makes inter- organizational messaging interconnections using the X.400(1984) protocols. And also that the commercial messaging world is not as totally interconnected as the R&D messaging community. Finally, for a number of commercial and public organisations there is often a mandatory requirement to use X.400 for messaging interconnections.
また、商業界が相互組織的なメッセージングをインタコネクトにX.400(1984)プロトコルを使用することでほとんどするのも、明確です。 そして、また、商業メッセージング世界は研究開発メッセージング共同体として同じくらい完全にインタコネクトされません。 最終的に、多くの商業の、そして、公立の機構のために、メッセージングインタコネクトにX.400を使用するという義務的な要件がしばしばあります。
The usage of PC LAN messaging systems is increasing very rapidly within the academic and commercial communities. In general, PC LAN messaging services within both communities do not use X.400(1984) or RFC 822 messaging systems but systems based upon proprietary protocols. The PC LAN messaging systems can be considered more as 'Islands of Messaging' that gateway to the commercial and R&D messaging services by using X.400(1984) or RFC 822 gateways. PC LAN messaging systems within commercial organisations connect to commercial service providers also via proprietary protocols. The PC LAN messaging services, although probably comprising the largest number of users, are in general poorly integrated with the global messaging service (The Dutch, UK and Italian academic communities confirm that there appears to be many such 'Islands' of PC LAN messaging systems within their networks.).
PC LANメッセージシステムの用法はアカデミックで商業の共同体の中で非常に急速に増加することです。 一般に、両方の共同体の中のPC LANメッセージングサービスはX.400(1984)かRFC822メッセージシステムではなく、固有のプロトコルに基づくシステムを使用します。 'Messagingの諸島'としての考えられた以上がコマーシャルへのそのゲートウェイとX.400(1984)かRFC822門を使用することによって研究開発メッセージングサービスであったかもしれないならシステムを通信させるPC LAN。 営利団体の中のPC LANメッセージシステムは固有のプロトコルを通しても商業サービスプロバイダーに接続します。 たぶんユーザの最多数を包括しますが、一般に、PC LANメッセージングサービスはグローバルなメッセージングサービスと不十分に統合されます(オランダ人、イギリス、およびイタリアの学界は、PC LANメッセージシステムのそのような多くの'諸島'がそれらのネットワークの中であるように見えると確認します。)。
4.2. Requirements for messaging
4.2. メッセージングのための要件
Experience with existing global e-mail services has proven that with the increased use of messaging, there follows an awareness of extra requirements for related services. These requirements can be classified into 'User based Requirements' and 'Service Provider based Requirements' to either support, or exploit, high quality messaging services. These requirements are elaborated upon within this chapter.
既存のグローバルなメールサービスの経験は、メッセージングの増強された使用で、関連するサービスのための付加的な要件の認識が従うと立証しました。 高品質のメッセージングサービスを支えるか、または利用するためにこれらの要件を'ユーザのベースのRequirements'と'サービスProviderはRequirementsを基礎づけたこと'に分類できます。 これらの要件では、本章の中に詳しく説明されます。
RARE WG-MSG Task Force 88 [Page 8] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[8ページ]RFC1616X.400(88)
4.2.1. User Oriented
4.2.1. 適応するユーザ
The only thing a user requires is an easy to use, well integrated, user interface to electronic mail. Usually the user does not care what protocol is used. However there are certain inherent requirements to the functionality that can be identified as user requirements. The main user requirements identified are:
ユーザが必要とする唯一のものが電子メールへの使用しやすくて、よく統合しているユーザーインタフェースです。 通常、ユーザは、どんなプロトコルが使用されているかを気にかけません。 しかしながら、ユーザ要件として特定できる機能性へのある固有の要件があります。 特定された主なユーザ要件は以下の通りです。
- Distribution Lists (DLs)
- 発送先リスト(dl)
A widely perceived omission from the X.400(1984) recommendations
was the lack of support of DLs. Distribution lists allow users to
enlist themselves onto electronic mail expander lists
(distribution lists). A message to such a distribution list will
automatically, and without significant delay, be sent on to anyone
whose electronic mail address is on that list. Such a list can be
a public list, that is meant for discussions on a specific
subject, much like a sort of "magazine". However the list can also
be a "closed" list, containing only a selected set of people who
need to communicate privately, e.g., a project-team.
X.400(1984)推薦からの広く知覚された省略はDLsのサポートの不足でした。 発送先リストで、ユーザは電子メールエキスパンダリスト(発送先リスト)に自分たちの協力を得ることができます。 そのような発送先リストへのメッセージは自動的に送るでしょう、そして、重要な遅れがなければ、電子メールアドレスがそのリストにあるだれにも送ってください。 そのようなリストが公共のリストであるかもしれない、それは特定の問題についての議論のために意味されます、一種の「雑誌」のように。 しかしながら、また、リストは「閉じている」リストであるかもしれません、個人的に交信する必要がある選択されたセットの人々だけを含んで、例えば、プロジェクト・チーム。
- Multinational language and Multimedia support
- 多国籍の言語とMultimediaサポート
European users have for many years been frustrated in their
inability to use their national character sets when communicating
using messaging systems. The problems within e-mail systems that
were causing this character set frustration are at their base the
same problem that would get in the way of Multimedia messaging
like:
メッセージシステムを使用することで交信するとき、ヨーロッパ人のユーザは彼らの無能でだめにされた多くの年の間、彼らの国民性セットを使用しなければなりません。問題は以下のように中でこの文字集合を引き起こすのが、フラストレーションであったならそれらのベースにあるシステムにMultimediaメッセージングの邪魔をするのと同じ問題をメールします。
- lack of binary data support
- lack of standardised encoding schema's
- definition of multiple body-parts
- バイナリ・データサポートの不足--標準化された図式のコード化ものの不足--複数の身体部分の定義
The enormous potential of Multimedia systems and services
(especially within the commercial community as evidenced by the
enormous press publicity and mega-mergers positioning companies to
exploit this technology but also within the government spheres
i.e., the U.S.A. Government's 'Information Superhighway'
initiative) has acted as a spur to make rapid progress in solving
the problems in this area.
莫大なMultimediaシステムの、そして、サービスの可能性(特にこの技術を利用するために莫大な新聞による広報と大型合併位置決め会社によって証明される商業共同体にもかかわらず、中でも、政府はすなわち、米国政府の'情報スーパーハイウェイ'イニシアチブを丸くします。) 拍車として、この領域で問題を解決する際に急速に進歩するように、機能しました。
- White pages Directory Service
- ホワイトページディレクトリサービス
A white pages directory service provides a unique but very basic
and important service; a way to store and find information about
people and resources that is analogous to a telephone service's
paper based directory i.e., White Pages. User's E-mail addresses
ホワイトページディレクトリサービスはユニークな、しかし、非常に基本的で重要なサービスを提供します。 人々とリソースの電話サービスの論文に類似の情報を保存して、見つける方法はすなわち、ディレクトリホワイトのためにページを基礎づけました。 ユーザのEメールアドレス
RARE WG-MSG Task Force 88 [Page 9] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[9ページ]RFC1616X.400(88)
can be stored for subsequent retrieval by E-mail systems.
メールシステムはその後の検索のために保存できます。
- EDI
- エディ
EDI today is not extensively used within the academic environment.
However there is a distinct potential within the academic
community to reduce costs and improve services with EDI. Potential
EDI uses could be,
今日のEDIはアカデミックな環境の中で手広く使用されません。 しかしながら、コストを削減して、EDIとのサービスを改良するために、学界の中に異なった可能性があります。 潜在的EDI用途はそうであるかもしれません。
- EDI between universities
- EDI between universities and government
- EDI between universities and lower level educational
institutions (e.g., student records)
- Commercial EDI using the Internet as an infrastructure.
- 大学の間のEDI--大学と政府の間のEDI--大学の間のEDIと下のレベル学園(例えば、指導要録)--インフラストラクチャとしてインターネットを使用する商業EDI。
The significance of maintaining end to end integrity (especially
security aspects) of the EDI messages mandates that no gateways
should be used between originator and recipient.
EDIメッセージ命令の保全(特にセキュリティ局面)を終わらせるゲートウェイがないのがそうするべきである終わりが創始者と受取人の間で使用されると主張する意味。
- Support of Security services
- Securityサービスのサポート
E-mail as it is currently used is far from secure. To allow for
serious usage of E-mail security issues need to be addressed,
like:
それが現在使用されているようにメールは全く安全ではありません。 メールの重大な用法を考慮するために、安全保障問題は、以下のように扱われる必要があります。
- integrity; making sure that the message is transferred
intact, without any changes or additions.
- encryption; making sure the message content is only
decipherable by the intended recipient.
- authentication; making sure that the originator and/or
recipient are authenticated.
- 保全。 少しも変化や追加なしで完全な状態で確実にそれをメッセージにするのを移します。 - 暗号化。 確実にメッセージ内容を作るのは単に意図している受取人で解読可能です。 - 認証。 確実に創始者、そして/または、受取人にそれを作るのは認証されます。
4.2.2. Service provider viewpoint
4.2.2. サービスプロバイダー観点
The task force believes the following points as being the most significant service provider requirements:
特別委員会は最も重要なサービスプロバイダー要件であるとして以下のポイントを信じています:
- Network Management
- ネットワークマネージメント
This area is still very new, in terms of offering standardised
protocols, services and products for management. However a minimum
'goal' is to provide for central management functions that will
allow providers to offer a better quality of service. There is
presently ongoing work within the IETF Working Group MADMAN to
define SNMP monitoring and managing of E-mail systems, gateways
and X.500 directory systems. A number of management areas that
need to be worked upon include: QOS, Service Level Agreements
(SLAs), Multiple system queue management, Accounting, Routing Co-
この領域は管理のために標準化されたプロトコル、サービス、および製品を提供するのにおいてまだ非常に新しいです。 しかしながら、最小の'目標'はプロバイダーがサービスで、より良質のaを提供できる中枢管理機能に備えることです。 現在、メールシステムをモニターして、管理するSNMPを定義するために、IETF作業部会MADMANの中に進行中の仕事があります、ゲートウェイ、X.500ディレクトリシステム作用される必要がある多くの管理領域ゲートウェイ QOS、サービス・レベル・アグリーメント(SLA)、Multipleシステム待ち行列管理Accounting、ルート設定Co
RARE WG-MSG Task Force 88 [Page 10] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[10ページ]RFC1616X.400(88)
ordination and Message Tracing.
叙階式とMessage Tracing。
- Support of MTA routing
- MTAルーティングのサポート
Dynamic routing from MTA to MTA, relieves the necessity to
maintain large routing tables, especially within a large PRMD, or
community of PRMDs (like the R&D MHS community).
MTAからMTAまでのダイナミックルーティング、特に大きいPRMD、またはPRMDsの共同体(R&D MHS共同体のような)の中で大きい経路指定テーブルを維持する必要性を軽減します。
- Address mapping between RFC 822 and X.400
- RFC822とX.400の間のアドレス・マッピング
The widespread use of X.500 or DNS for mapping, allows a reduction
of manpower for centrally co-ordinating globally consistent
X.400-to-RFC-822 mapping tables and distributes the responsibility
for updating the mapping rules. This should allow mapping rules to
change when needed and to be available immediately.
X.500かDNSの普及使用、写像して、テーブルを写像しながらグローバルに一貫したX.400からRFC-822を調整しながら中心のための労働力の減少を許して、配置規則をアップデートすることへの責任を分配します。 これは配置規則が必要であるいつを変えるか、そして、すぐに利用可能であることを許容するべきです。
- UA capabilities registration
- UA能力登録
The use of the directory to register UA capabilities for
X.400(1988), X.400(1984) and RFC 822 / MIME / PEM systems is a
very desirable benefit for users in terms of speeding the
deployment of new messaging services (e.g., Multimedia Messaging).
X.400(1988)のためのレジスタUA能力、X.400(1984)、およびRFC822/MIME/PEMシステムへのディレクトリの使用は新しいメッセージングサービス(例えば、Multimedia Messaging)の展開を促進することに関するユーザには、非常に望ましい利益です。
4.3. Messaging capabilities
4.3. メッセージング能力
Due to the problems of gatewaying within a multi-protocol messaging environment, the great majority of R&D E-mail users are reduced to using only InterPersonal Messaging (IPM) services based upon the exchange of message body parts using CCITT character set IA5 (US ASCII).
環境を通信させながらマルチプロトコルの中でgatewayingするという問題のため、研究開発メールユーザの大多数はCCITT文字集合IA5(米国ASCII)を使用することでメッセージ身体の部分の交換に基づくInterPersonal Messaging(IPM)サービスだけを利用するのに減少します。
Within the R&D community recent work to meet user requirements for non ASCII messaging services - as documented above - has resulted in enhancements to the messaging services based upon RFC 822 protocols. The enhancements provide Multimedia support via the Multipurpose Internet Mail Extensions (MIME) and the prospect in the very near future of secure messaging via Privacy Enhanced Mail (PEM). Deployment of the MIME enhanced RFC 822 based services, via distribution of software and the setting up of the needed organisational structures, has commenced. The PEM enhancements are in a large scale pilot phase e.g., VALUE PASSWORD project.
満たす研究開発の共同体の最近の仕事の中では、上に記録されるようなサービスを通信させる非ASCIIがメッセージングサービスへの増進をもたらしたので、ユーザ要件は822のプロトコルをRFCに基礎づけました。 増進は安全なメッセージングの近い将来、マルチパーパスインターネットメールエクステンション(MIME)と見通しでサポートをMultimediaにPrivacy Enhancedメール(PEM)で供給します。 必要なorganisational構造を上がっているソフトウェアと設定の分配で、MIMEの高められたRFC822ベースのサービスの展開は始まりました。 例えば、試験段階VALUE PASSWORDが映し出す大規模にはPEM増進があります。
In the case of X.400(1984) the usage of non ASCII body parts is mostly effected by bilateral agreement between recipient and originator, through use of body part 14. In practice this restricts the exchange of non ASCII body parts to those cases where the recipient and the originator use the same bilateral agreement or else the originator includes an ASCII message explaining the included
X.400(1984)の場合では、非ASCII身体の部分の使用法は受取人と創始者の間の二国間条約でほとんど作用します、身体のパート14の使用で。 実際には、これは非ASCII身体の部分の交換を受取人と創始者が同じ二国間条約を使用するか、または創始者が包含がわかるASCIIメッセージを含んでいるそれらのケースに制限します。
RARE WG-MSG Task Force 88 [Page 11] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[11ページ]RFC1616X.400(88)
content type. Besides IPM there is a growing usage of EDI on top of X.400(1984).
content type。 そのうえ、そこのIPMはX.400(1984)の上のEDIの増加している使用法です。
With the above X.400(1984) deficiencies in mind, X.400(1988) has been specified by the CCITT / ISO to meet new user demands. X.400(1988) provides support for various different body parts, enhanced security features, international character set support capabilities and support of X.500 Directory Services. Due to the technological potential of these standards to satisfy user needs for new messaging services, the R&D community has been experimenting and piloting X.400(1988) and X.500(1988) services. As there is a strong dependency of X.400(1988) messaging upon X.500(1988) directory services, the necessary precondition to supply these user demands is a deployed and operational X.500(1988) directory service. Piloting and deployment of the X.500(1988) directory service within the R&D community has been successfully initiated and co-ordinated by the COSINE and the VALUE PARADISE projects.
上のX.400(1984)欠乏が念頭にある状態で、X.400(1988)は、新しいユーザ需要にこたえるためにCCITT/ISOによって指定されました。 X.400(1988)はX.500ディレクトリサービスの様々な異なった身体の部分、警備の強化機能、国際的な人物セットサポート能力、およびサポートのサポートを提供します。 新しいメッセージングサービスのユーザ需要を満たすこれらの規格の技術的な可能性のため、研究開発共同体は、X.400(1988)とX.500(1988)サービスを実験して、操縦しています。 X.500(1988)ディレクトリサービスで通信するX.400(1988)の強い依存があるとき、これらのユーザ要求を供給する必要な前提条件は配布していて操作上のX.500(1988)ディレクトリサービスです。 研究開発共同体の中のX.500(1988)ディレクトリサービスの操縦と展開は、COSINEとVALUE PARADISEプロジェクトによって首尾よく開始されて、調整されました。
Similarly, secure messaging has been addressed by the VALUE PASSWORD project and the RARE and IETF communities. Work to solve problems related to directory support of X.400(1988) messaging has been pursued within the IETF and RARE. The relevant RARE and IETF work groups (e.g., RARE WG-MSG, IETF MHS-DS, etc.) have also worked to produce any needed enhancements to the base X.400(1988) and X.500(1988) standards. Last but not least it should not be overlooked that X.400(1988), as compared to X.400(1984), provides a comprehensive basis for gatewaying to and from RFC 822 / MIME / PEM and PC LAN messaging services. To that respect the IETF has defined standards for gatewaying Multimedia mail between RFC 822 / MIME / PEM and X.400(1988). As RFC 822 / MIME / PEM is now being deployed on the Internet, deployment of X.400(1988) services is needed to assure multimedia and secure messaging connectivity for the European R&D community.
同様に、安全なメッセージングはVALUE PASSWORDプロジェクト、RARE、およびIETF共同体によって扱われました。 通信することにおけるX.400(1988)のディレクトリサポートに関連する問題を解決する仕事はIETFとRAREの中で追求されました。 また、関連RAREとIETF仕事グループ(例えば、RARE WG-エムエスジー、IETF MHS-DSなど)は、ベースX.400(1988)とX.500(1988)規格にどんな必要な増進も起こすために働いていました。 最も最少でないのにもかかわらず、最後に、見落とされて、X.400(1984)と比べるそのX.400(1988)がメッセージングサービスとRFC822/MIME/PEMとPC LANメッセージングサービスからgatewayingする包括的な基礎を提供するということであるべきではありません。 その敬意と、IETFはRFC822/MIME/PEMとX.400(1988)の間のgatewaying Multimediaメールの規格を定義しました。 RFC822/MIME/PEMが現在インターネットで配布されているとき、X.400(1988)サービスの展開が、マルチメディアと安全なメッセージングの接続性をヨーロッパの研究開発共同体に保証するのに必要です。
5. Possible solutions for providing globally pervasive messaging
5. グローバルに普及しているメッセージングを提供するための可能なソリューション
As can be now seen, a correlation of the present situation to the requirements of the user, shows that the current messaging services do not match the needs of users. To try to meet these needs a number of developments within various messaging technology areas are occurring. The following messaging technological areas, due to the present installed user base within the R&D community, are considered relevant:
今見ることができるように、ユーザの要件への現在の状況、電流がサービスを通信させて、ユーザの必要性に合っていないショーの相関関係です。 これらの需要を満たそうとするために、様々なメッセージング技術領域の中の多くの開発が起こっています。 現在のインストールされたユーザベースのため研究開発共同体の中で技術的な領域を通信させる以下は関連していると考えられます:
- PC LAN E-mail systems such as Lotus cc:Mail, Microsoft Mail
and Novell MHS
- RFC 822 / MIME / PEM E-mail services
- X.400(1988) messaging services
- ロータスcc:Mailや、マイクロソフトメールやノベルMHSなどのPC LANメールシステム--RFC822/MIME/PEMメールサービス--サービスを通信させるX.400(1988)
RARE WG-MSG Task Force 88 [Page 12] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[12ページ]RFC1616X.400(88)
Ongoing developments within each of the above technological areas provide new messaging options for the R&D community. The ability of each technological area to provide solutions for user and service provider requirements is summarised within this chapter.
それぞれの上の技術的な領域の中の開発現況は新しいメッセージングオプションを研究開発共同体に提供します。 本章の中でそれぞれの技術的な領域がユーザとサービスプロバイダー要件に解決法を提供する能力について略言します。
5.1. PC LAN E-mail systems
5.1. PC LANメールシステム
Currently the usage of PC LAN E-mail systems is mostly for internal communication within an organisation. External connections, if present at all, to public service providers or other organisations is mostly through gateways to X.400(1984) or RFC 822. The use of a PC LAN E-mail system in terms of an infrastructure for interconnecting E-mail systems of different hues is not common within the Research community. Recent experience, from amongst others the Dutch Research network - SURFnet - [14] and the Norwegian Directorate for Public Management - Statskonsult - [18], has shown that a number of problems (i.e., limited functionality, high operational management cost, etc.) can be expected should these PC LAN E-mail systems be used as an E- mail infrastructure. (The use of native X.400 protocols for PC LAN E-mail systems would avoid the usage of gateways and would thus alleviate many of these problems.) A summary of those problems and some relevant issues follows:
機構の中に現在の、PC LANメールシステムの使用法はほとんど内部のコミュニケーションのためにあります。 外部の接続、全くプレゼントは社会奉仕プロバイダーか他の機構へのほとんどX.400(1984)へのゲートウェイを通したそうであるか、そして、またはRFC822。 インフラストラクチャに関するPC LANメールシステムの異なった色のメールシステムとインタコネクトする使用はResearch共同体の中で一般ではありません。 他のものオランダのResearchネットワーク--SURFnet--[14]とPublic ManagementのためのノルウェーのDirectorate--Statskonsult--[18]から、最近の経験は、これらのPC LANメールシステムがEメールインフラストラクチャとして使用されるなら多くの問題(すなわち、限られた機能性、高い運営管理費用など)を予想できるのを示しました。 (固有のX.400プロトコルのPC LANメールシステムの使用は、ゲートウェイの使用法を避けて、その結果、これらの問題の多くを軽減するでしょう。) それらの問題といくつかの当該の問題の概要は従います:
- Interconnecting heterogeneous PC LAN messaging systems
- 異種のPC LANメッセージシステムとインタコネクトします。
One very distinct benefit for E-mail users of all hues is the
potential to integrate heterogeneous PC LAN messaging systems with
a minimum loss of service (e.g., multimedia services) by
connecting them via X.400(1988) (or RFC 822/MIME/SMTP).
X.400(1988) is already being used, or under active development,
for connecting together PC LAN messaging systems in a number of
environments (e.g., Apple Macintoshes, DEC, Microsoft, Lotus,
etc.). This tendency to gateway PC LAN messaging systems via
X.400(1988) will increase and is one of the benefits that
X.400(1988) brings to global multiprotocol messaging.
すべての色のメールユーザのための1つの非常に異なった利益がX.400(1988)(または、RFC822/MIME/SMTP)を通してそれらを接続することによって最小のサービス(例えば、マルチメディアサービス)の損失と異種のPC LANメッセージシステムを統合する可能性です。 使用されるか、またはX.400(1988)は既に活発に開発中です、多くの環境(例えば、アップルマッキントッシュ、12月、マイクロソフト、ロータスなど)におけるPC LANメッセージシステムを一緒に接続するために。 X.400(1988)を通したゲートウェイPC LANメッセージシステムへのこの傾向は、増加して、X.400(1988)がグローバルな「マルチ-プロトコル」メッセージングにもたらす利益の1つです。
- Multimedia and binary data support
- マルチメディアとバイナリ・データサポート
The benefit of E-mail systems using these PC LAN systems is that
the user interfaces are usually well integrated in the users
standard working environment. Using a proprietary protocol these
systems allow not only text (ASCII) but also binary, word
processor, video, audio and other types of files to be
transported. To reap the benefits of this multimedia / binary data
transfer it would normally require that the same type of gateway
is used by sender and receiver. Transporting these same files to
another type of PC LAN E-mail system is not possible through the
これらのPC LANシステムを使用するメールシステムの利益は通常、ユーザインタフェースが環境を扱うユーザ規格でよく統合しているということです。 固有のプロトコルを使用して、これらのシステムは、テキスト(ASCII)だけではなく、ファイルのバイナリー、ワードプロセッサ、ビデオ、オーディオ、および他のタイプも輸送されるのを許容します。 このマルチメディア/バイナリ・データ転送の恩恵を獲得するために、通常、それは、同じタイプのゲートウェイが受信機送付者とこれらの同じファイルを別のものに輸送することによってPC LANメールシステムのタイプが可能でない使用されるのを必要とするでしょう。
RARE WG-MSG Task Force 88 [Page 13] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[13ページ]RFC1616X.400(88)
current gateways without some information loss. In effect PC LAN
E-mail system's X.400 (or RFC 822) gateways from different vendors
perform acceptably only for text body parts. True heterogeneous
multimedia PC LAN messaging needs gateways to X.400(1988)'s
service.
いくらかの情報の損失のない現在のゲートウェイ。 異なったベンダーからの事実上PC LANメールシステムのX.400(または、RFC822)ゲートウェイはテキスト身体の部分だけに許容できて働きます。 本当の異種のマルチメディア・パソコンLANメッセージングはX.400(1988)のサービスへのゲートウェイを必要とします。
- Application Programming Interfaces
- アプリケーションプログラミングインターフェース
To help solve the problem of portability for Mail Enabled
Applications Microsoft, Lotus, Novell, XAPIA and X/OPEN have been
working on a number of standards for the Application Interface to
mail transport protocols (i.e., Mail Application Programming
Interface - MAPI, Vendor Independent Messaging - VIM, Common Mail
Calls - CMC). These efforts are structured independent of the
existing 'Wide-Area' or inter organisational E-mail protocols of
X.400(1984) and RFC 822. However the MAPI, VIM and CMC efforts,
due to their proposers (respectively Microsoft, Lotus and X/OPEN),
do look like they will provide the stimulant to various software
developers to develop more portable applications plus allow the
rich functionality of X.400(1988) to be accessed by these
applications thus reducing the need for gatewaying to X.400(1988).
メールEnabled Applicationsマイクロソフトのための移植性の問題を解決するのを助けるなら、HTTPサーバとNETSCAPE間のインタフェースがトランスポート・プロトコル(すなわち、メールApplication Programming Interface--MAPI、Vendor無党派Messaging--VIM、CommonメールCalls--CMC)を郵送するように、ロータス、ノベル、XAPIA、およびX/オープンは多くの規格に動いています。 これらの取り組みはX.400(1984)とRFC822の既存の'広い領域'か間のorganisationalメールプロトコルの如何にかかわらず構造化されます。 しかしながら、MAPI(彼らの提案者によるVIMとCMC取り組み(それぞれマイクロソフト、ロータス、およびX/オープン))は、彼らが、より携帯用のアプリケーションを開発して、X.400(1988)にgatewayingする必要性を減少させながらこれらのアプリケーションでX.400(1988)の豊かな機能性がこのようにしてアクセスされるのを許容するために様々なソフトウェア開発者に興奮剤を提供するように見えます。
- Security
- セキュリティ
As the PC LAN E-mail systems require gateways for connectivity,
they pose a problem with regard to encrypted messages. Gatewaying
of secure messages is normally not possible. The gatewaying of
secure messages is a general problem of gatewaying from one mail
system to any other system and is not specific to PC LAN E-mail
systems.
PC LANメールシステムが接続性のためにゲートウェイを必要とするとき、それらは暗号化メッセージに関して問題を設定します。 通常、安全なメッセージのGatewayingは可能ではありません。 安全なメッセージのgatewayingは1台のメールシステムからいかなる他のシステムまでもgatewayingするという一般的問題であり、PC LANメールシステムに特定ではありません。
- Directory Services
- ディレクトリサービス
To date mostly proprietary directory services have been deployed
that do not match the needs of the users in terms of access
controls for data, distributed and decentralised across
organisations. X.500 based services promise solutions to such
needs. As a result various suppliers have announced support of
X.500 directory services for their E-mail products. However,
should these interfaces be delayed then support of an inter
organisational 'White Pages' services requires either,
デートするために、機構の向こう側に分配されて、分散されたデータのためのアクセス制御に関してユーザの必要性に合っていないほとんど独占であるディレクトリサービスは配布されました。 X.500のベースのサービスはそのような必要性にソリューションを約束します。 その結果、様々な供給者はそれらのメール製品のためにX.500ディレクトリサービスのサポートを発表しました。 しかしながら、これらのインタフェースは'白いページ'サービスが必要とする間のorganisationalの遅れた当時のサポートであるべきです。
- directory information exchange products (i.e., directory
gateways) deployed between a proprietary system and an X.500
directory system
- プロプライエタリシステムとX.500ディレクトリシステムの間で配布されたディレクトリ情報交換製品(すなわち、ディレクトリゲートウェイ)
RARE WG-MSG Task Force 88 [Page 14] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[14ページ]RFC1616X.400(88)
- gateways between de-facto market based proprietary
standards, such as Retix Directory Exchange (DX) or
Soft*switch's Directory Synchronisation (DS), and X.500
protocols
- RetixディレクトリExchange(DX)かスイッチのSoft*ディレクトリSynchronisationなどのデファクトの市場のベースの独占規格(DS)と、X.500プロトコルの間のゲートウェイ
- duplicated directories i.e., one proprietary and one X.500
need to be operated.
- すなわち、1独占X.500と1X.500が操作されるために必要とするディレクトリをコピーしました。
It should be stressed that gatewaying mechanisms and products are often problematic due to the lack of an open standard on the proprietary messaging system and or directory system. (As an aside it is thus essential to establish an operational X.500 infrastructure, including E-mail user interfaces that can transparently access this Directory Service, as soon as possible.)
そして、メカニズムをgatewayingして、製品が独占メッセージシステムのオープンスタンダードの不足のためにしばしば問題が多いと強調されるべきである、または、ディレクトリシステム。 (その結果、余談として、操作上のX.500インフラストラクチャを確立するのは不可欠です、透過的にこのディレクトリサービスにアクセスできるメールユーザインタフェースを含んでいて、できるだけ早く。)
5.2. RFC 822, MIME and PEM services
5.2. RFC822、MIME、およびPEMサービス
RFC 822 messaging services are widely deployed within the R&D community. There is ongoing work to extend RFC 822 to meet user requirements. Some of these extensions are elaborated upon within this chapter.
RFC822メッセージングサービスは研究開発共同体の中で広く配布されます。 ユーザ要件を満たすためにRFC822を広げるために、進行中の仕事があります。 これらの拡大のいくつか、本章の中に詳しく説明されます。
- Distribution lists
- 発送先リスト
RFC 822 allows for the usage of DLs. Management of DLs is not
(yet) standardised.
RFC822はDLsの使用法を考慮します。 DLsの管理は(まだ)標準化されていません。
- RFC 822 multimedia messaging via MIME
- MIMEで通信するRFC822マルチメディア
With the arrival of MIME, the RFC 822 service has an additional
protocol standard that addresses Multimedia messaging very
comprehensively. In terms of user needs, MIME now allows messaging
body parts to comprise multinational character sets and binary
data. Multi-body part messages are also supported. One of MIME's
real strengths, in terms of deployment within the existing RFC 822
service, is that it achieves its goals by overlaying its services
over the existing RFC 822 service and thus mandating no changes to
the in place RFC 822 infrastructure. This greatly simplifies the
MIME deployment.
MIMEの到着によって、RFC822サービスには、Multimediaがメッセージングであると非常に包括的に扱う追加議定書規格があります。 ユーザの必要性に関して、MIMEで、メッセージング身体の部分は現在、多国籍の文字集合とバイナリ・データを包括できます。 また、マルチボディー部分メッセージはサポートされます。 既存のRFC822サービスの中の展開で、MIMEの底力の1つは既存のRFC822サービスの上でサービスをかぶせることによって目的を果たして、その結果、いいえを強制するのがRFC822インフラストラクチャを適所にあるのに変えるということです。 これはMIME展開を大いに簡素化します。
- RFC 822 secure messaging via PEM
- PEMを通したRFC822の安全なメッセージング
Just as MIME has brought multimedia messaging to RFC 822 services,
Privacy Enhanced Mail (PEM) is bringing secure messaging to RFC
822 services. PEM also has used the same approach as MIME to
deploy secure messaging within RFC 822 services; overlay PEM
services over the existing RFC 822 services without requiring
changes to the RFC 822 infrastructure. PEM brings confidentiality
ちょうどMIMEが822のサービスをRFCへ通信させるマルチメディアをもたらしたように、Privacy Enhancedメール(PEM)はRFC822サービスに安全なメッセージングをもたらしています。 PEMもRFC822サービスの中で安全なメッセージングを配布するのにMIMEと同じアプローチを使用しました。 オーバレイPEMは存在の上でRFC822インフラストラクチャに対する釣り銭がいることのないRFC822サービスを修理します。 PEMは秘密性を持って来ます。
RARE WG-MSG Task Force 88 [Page 15] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[15ページ]RFC1616X.400(88)
and integrity of messages to RFC 822 users. However a number of
problems with PEM, and X.400(1988) as well, still need to be
solved before secure messaging can be considered to be an
operational service. These problems are independent of the secure
messaging protocol (i.e., PEM or X.400(1988)) and deal mainly with
distribution of secret keys to the end users. There is very active
work going on within the IETF to solve these problems.
そして、RFC822ユーザへのメッセージの保全。 しかしながら、また、PEM、およびX.400(1988)に関する多くの問題が、まだ操作上のサービスであると安全なメッセージングを考えることができる前に解決される必要があります。 これらの問題は、安全なメッセージング・プロトコル(すなわち、PEMかX.400(1988))から独立していて、主にエンドユーザの秘密鍵の分配に対処します。 IETFの中でこれらの問題を解決し続ける非常に活発な仕事があります。
- MIME and PEM
- MIMEとPEM
There are still problems for messages that are simultaneously a
multimedia message, as per MIME, and a secure message, as per PEM.
A PEM encoded MIME message does not allow gatewaying to other
messaging environments and therefore does not allow any of the
features inherent within MIME to be exploited along the message
path. A MIME message that contains PEM encoded body parts can be
gatewayed but the integrity of the entire message is then not
guaranteed. This is a real deficiency of both existing approaches
as it is essential that users are able to simultaneously use
multimedia and secure messaging. However, once again, the IETF is
working very hard on solving these problems and solutions can be
expected, although the solution of the gatewaying of PEM messages
to other E-mail systems is still unclear.
同時にマルチメディアメッセージであるメッセージのための問題がまだあります、MIME、および安全なメッセージに従って、PEMに従って。 コード化されたMIMEメッセージが他のメッセージング環境にgatewayingするのを許容しないで、またしたがってメッセージ経路に沿って利用されるのをMIMEの中で固有の特徴のいずれも許容しないPEM。 PEMを含むMIMEメッセージはボディーをコード化しました。部品をgatewayedされることができますが、保証されて、全体のメッセージの保全はそしてgatewayedしていません。 ユーザが同時にマルチメディアと安全なメッセージングを使用できるのが、不可欠であるので、これは両方の既存のアプローチの本当の欠乏です。 しかしながら、これらの問題を解決するときもう一度、IETFは一生懸命仕事します、そして、ソリューションは予想できます、他のメールシステムへのPEMメッセージのgatewayingのソリューションがまだ不明瞭ですが。
- Dynamic and distributed messaging routing via the Domain Name
System (DNS)
- ドメインネームシステムを通したダイナミックで分配されたメッセージングルーティング(DNS)
RFC 822 messaging benefits greatly by having a dynamic and
distributed mechanism to assist in message routing i.e., Domain
Name System (DNS). With the support of the DNS, RFC 822 MTAs are
able to directly route to other RFC 822 MTAs and thus deliver
messages with a minimum of delay. In practice mail often still
traverses multiple RFC 822 MTAs for a number of reasons e.g., Mail
Hubs provided for users who turn their machine off when they go
home, Firewall Hubs for security reasons, etc. However it is
commonly accepted that between RFC 822 mail hubs the delivery of
messages is very fast. Typically resolution of routing decisions
occurs in less than one minute and very often within seconds. In
general the DNS service is a very valuable service that functions
well in practice.
RFC822メッセージングは、メッセージルーティングすなわち、ドメインネームシステム(DNS)を助けるためにダイナミックで分配されたメカニズムを持っていることによって、大いに利益を得ます。 DNSのサポートで、RFC822MTAsは直接822MTAsを他のRFCに発送して、その結果、最小遅れでメッセージを提供できます。 例えば、メールHubsが彼らが家に帰るとき彼らのマシンをオフにするユーザに備えた多くの理由、セキュリティ理由によるFirewall Hubsなどのための複数の習慣メールそれでも、しばしば横断RFC822MTAsで しかしながら、一般的に、RFC822メール・ハブの間では、メッセージの配送が非常に速いと受け入れます。 通常、ルーティング決定の解決は秒以内に1分未満と頻繁に起こります。 一般に、DNSサービスは実際にはよく機能する非常に貴重なサービスです。
- Support for Character sets
- キャラクターセットのサポート
Together with the MIME specification for content types, an
extension for RFC 822 headers was defined that allows for usage of
multiple character sets in names, subject etc. in RFC 822 headers
[9]. This allows (European) users to use their preferred character
set to support their language not only in the contents of a
content type、拡大のためのMIME仕様、RFCに関しては、RFC822ヘッダー[9]で対象名前などにおける複数の文字集合の用法を考慮する822個のヘッダーが定義されました。 これで、(ヨーロッパ)のユーザは、aのコンテンツであるだけではないのにおける彼らの言語をサポートするのに彼らの都合のよい文字集合を使用できます。
RARE WG-MSG Task Force 88 [Page 16] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[16ページ]RFC1616X.400(88)
message but also in the headers.
メッセージですが、ヘッダーで。
- MIME capable gateways
- MIMEのできるゲートウェイ
It is clear that to provide a seamless service to all users
regardless of whether they are using RFC 822 or X.400 services, a
widely available set of well run and standardised RFC 822 to X.400
gateways must be in place. For InterPersonal Messaging (IPM) based
on US ASCII there are already a large number of such standardised
(i.e., X.400-to-RFC 822) gateways deployed. To ensure seamless
gatewaying between MIME and X.400 multimedia users, these existing
text based gateways must be either upgraded to or replaced with
multimedia messaging gateways. A number of proposed Internet
standards to solve these problems, for both X.400(1984) and
X.400(1988) and generated within the MIMEMHS work group of the
IETF, have been completed [4].
彼らがRFC822かX.400サービスを利用しているかどうかにかかわらずすべてのユーザに対するシームレスのサービスを提供するために、X.400ゲートウェイへのよく実行されて、標準化されたRFC822の広く利用可能なセットが適所にあるに違いないのは、明確です。 既にある米国ASCIIに基づくInterPersonal Messaging(IPM)に関しては、そのような多くの標準化された(すなわち、X.400からRFCへの822)ゲートウェイが展開しました。 マルチメディアユーザ、既存のテキストが基礎づけたこれらをMIMEとX.400の間のシームレスのgatewayingに確実にするために、ゲートウェイは、ゲートウェイをアップグレードしなければならないか、または通信するマルチメディアに取り替えなければなりません。 Aは、仕事がIETFのグループであるとX.400(1984)とX.400(1988)の両方のこれらの問題を解決する提案されたインターネット標準に付番して、MIMEMHSの中で生成して、完成した[4]です。
- Access to fax, teletex, telex or physical delivery
- ファックスで送るアクセス、テレテックス、テレックスまたは物理的な配送
For the moment, there is no standardised way for RFC 822 users to
access gateways to the above services except by indirect access to
X.400(1988) systems (i.e., concatenated gateways of RFC 822 to
X.400(1988) and then onwards to the appropriate X.400(1988) Access
Unit). Although even this indirect method would require some
further work on standardising mappings between RFC 822 addresses
and X.400(1992)'s X.121 addresses. As well some experiments within
the RFC 822 world are occurring on routing fax messages.
さしあたり、ずっとRFCのために、X.400(1988)システム(すなわち、前方へ次に、適切なX.400(1988)アクセスUnitにRFC822からX.400(1988)のゲートウェイを連結する)への間接アクセス以外に、上のサービスへのゲートウェイにアクセスする822人のユーザは標準化されません。 この間接的なメソッドさえさらにいくつかを必要とするでしょうが、RFC822アドレスとX.400(1992)のX.121アドレスの間のマッピングを標準化するのに働いてください。 また、RFC822世界の中のいくつかの実験がルーティングファックス通信に起こっています。
- Operational support
- 操作上のサポート
Generally, RFC 822 messaging services are delivered on a 'best
effort' basis and thus service level agreements requesting
stringent response times to operational problems or guaranteed
delivery times for messages are difficult to agree. This phenomena
might be a result of the distribution and delegation of authority
to organisations updating the RFC 822 MTA's routing mechanism
i.e., DNS. As a result it makes it hard to reach a 'one stop
shopping' agreement for RFC 822 messaging services.
一般に、RFC822メッセージングサービスは、緊縮応答時間を運転上の問題に要求しながら'ベストエフォート型'の基礎とその結果、サービスレベル協定で提供されるか、またはメッセージのための配送時間は同意するのが難しいのが保証されます。 この現象はすなわち、RFCをアップデートする機構への分配と権限の委任の結果が822MTAのルーティングメカニズムDNSであるならそうするでしょうに。 その結果、それで、RFC822メッセージングサービスのための'ワン・ストップ・ショッピング'合意に達するのは困難になります。
- Notifications
- 通知
The RFC 822 service provides a minimum amount of base protocol
support for messaging users. It could be argued that the RFC 822
protocol is simplified by this choice and thus software that
implements the standard need be smaller in size and easier to
build. However some features e.g., delivery & receipt
notifications and UA capabilities registration, would be commonly
accepted as being desirable from a user standpoint and thus
RFC822サービスはメッセージングユーザの最小の量のベースプロトコルサポートを提供します。 選択がこれによって簡素化されて、その結果、サイズが、より小さくて、建てるのが、より簡単な状態でRFC822プロトコルは規格がそうしなければならない道具があるソフトウェアを簡素化されると主張できました。 しかしながら、或るものは、例えば、配送、領収書通知、およびUA能力登録を特徴として、その結果、ユーザ見地から望ましいとして一般的に認められるでしょう。
RARE WG-MSG Task Force 88 [Page 17] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[17ページ]RFC1616X.400(88)
desirable extensions to RFC 822. Some operational problems
relating to reliability could be minimised by technology that has
a standardised support for positive and negative notifications of
messages. RFC 822, as compared to X.400, technology does not yet
support positive notifications (although there is work starting
within the IETF to extend RFC 822 to support delivery
notifications). However within RFC 821 transport system (i.e.,
SMTP) there are standardised negative notifications that work
well. Alternatively X.400 technology, deployed over TCP/IP (using
STD 35, RFC 1006), may help to address the lack of adequate
service quality - notification support - when using E-mail within
the Internet.
RFC822への望ましい拡大。 信頼性に関連することにおけるいくつかの運転上の問題がメッセージの積極的で否定的な通知の標準化されたサポートを持っている技術で最小となることができるでしょう。 RFC822、X.400と比べて、技術はまだ積極的な通知をサポートしていません(配送が通知であるとサポートするためにIETFの中でRFC822を広げ始める仕事がありますが)。 しかしながら、RFC821輸送システム(すなわち、SMTP)の中に、うまくいく標準化された否定的通知があります。 あるいはまたTCP/IP(STD35、RFC1006を使用する)の上で配布されたX.400技術は、インターネットの中でメールを使用するとき、適切なサービス品質(通知サポート)の不足を扱うのを助けるかもしれません。
- Portability of RFC 822 products
- RFC822製品の移植性
There are only a few mailbox formats in general use by RFC 822
software, one being the 'bin/mail' format and the other 'MH'
format. This 'standard' mailbox format is a definite benefit for
RFC 822 users as it allows them to change RFC 822 UAs (e.g.,
upgrading to MIME RFC 822 UAs) whilst not compromising or
converting their existing archived mail, which may comprise 1000s
of archived messages.
そこでは、1つが''形式ともう片方'という容器/メールMH'形式であり一般に、ほんのいくつかのメールボックス形式はRFC822ソフトウェアで使用ですか? この'標準'のメールボックス形式はそれとしての822人のユーザが彼らを1000年代を含むかもしれない彼らの既存の格納されたメールを感染しないか、または変換していない間の格納されたメッセージのRFC822UAs(例えば、822UAsをMIME RFCにアップグレードさせる)を変えさせるRFCのための明確な利益です。
- System support for RFC 822 products
- RFC822製品のシステム支援
Normally, RFC 822 MTAs and UAs come pre-installed on UNIX
workstations. As a result, users are spared the effort of
installing RFC 822 MTA software. If for some reason, a user or
mail administrator should wish to install a different MTA or UA to
the pre-installed system, there exists a large number of easily
available (i.e., via widespread distribution amongst many FTP and
other information servers) public domain RFC 822 MTAs and UAs.
通常、RFC822MTAsとUAsはUnixワークステーションでプレインストールされていた状態で来ます。 その結果、インストールRFC822MTAソフトウェアの取り組みからユーザを開放します。 ユーザかメール管理者が、ある理由でなら多くの容易に利用可能な(すなわち、多くのFTPの、そして、他の情報サーバの中の広範囲の分配を通した)公共の場のRFC822MTAsとUAsが存在するのを異なったMTAかUAをプレインストールされたシステムにインストールしたがっているべきです。
Both of the above points encourages the spread and eases the
installation of software for the RFC 822 messaging service and in
many ways explains the size and importance of the installed base
of RFC 822 systems. To illustrate the extent of RFC 822 / MIME
products, a non-comprehensive list of available MIME enhanced RFC
822 products follows; ELM 2.4, MH 6.8, Sun Mailtool, HP Mpower
Desktop, Lotus cc:Mail (unconfirmed), Zcode Zmail, Frontier
Super-TCP for Windows, PMDF (VAX VMS), Pine, C-Client (library
routines), Metamail (viewer only), Andrew-MIME gateway.
上のポイントは両方の、基礎づけるのがRFC822メッセージングサービスと多くの道における、ソフトウェアのインストールでインストールのサイズと重要性がわかるRFC822システムの普及と容易さを奨励します。RFC822/MIME製品の範囲を例証するために、利用可能なMIME高められたRFC822製品に関する非総覧は従います。 ELM2.4、MH6.8、Sun Mailtool、HP Mpower Desktop、ロータスcc:Mail(未確認の)、Zcode Zmail、WindowsのためのFrontier Super-TCP、PMDF(VAX VMS)、Pine、C-クライアント(ライブラリ・ルーチン)、Metamail(ビューアー専用)(アンドリュー-MIMEゲートウェイ)。
- UA capability registration
- UA能力登録
The IETF MHS-DS working group has defined how X.400 and RFC 822
User Agent capabilities can be stored in X.500 directory services.
This work is still ongoing.
IETF MHS-DSワーキンググループはX.500ディレクトリサービスにどうX.400とRFC822Userエージェント能力を保存できるかを定義しました。 この仕事はまだ進行中です。
RARE WG-MSG Task Force 88 [Page 18] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[18ページ]RFC1616X.400(88)
5.3. X.400 - 1984 and 1988
5.3. X.400--1984と1988
X.400(1988) substantially upgrades and enhances the X.400(1984) standards. A number of new functions have been incorporated within X.400(1988). A description of the most important features of X.400 - 1984 and 1988 - follows.
X.400(1988)は実質的にX.400(1984)規格をアップグレードして、高めます。 多くの新しい機能がX.400(1988)の中に組み込んでいます。 X.400の最も重要な特徴の記述(1984と1988)は続きます。
- Notifications
- 通知
X.400(1984) provides four notifications - positive and negative
delivery notifications and positive and negative receipt
notifications. These notifications allow users to ensure
successful message delivery or that the message was read. The
delivery notifications are also used by service operators in their
fault escalation procedures.
X.400(1984)は4つの通知を提供します--積極的で否定的な配送通知と積極的で否定的な領収書通知。 これらの通知で、ユーザは、うまくいっているメッセージ配送と、メッセージが読まれたのを保証できます。 また、配送通知は彼らの欠点増大手順でサービスオペレータによって使用されます。
- Binary Data Transfer
- バイナリ・データ転送
X.400(1984) allows binary data transfer to be transported without
the necessity of character encoding. The ability to transfer files
of whatever type is a valuable end user service. As well the lack
of any necessary character encoding allows users to utilise the
received data without needing any character decoding software.
X.400(1984)は、バイナリ・データ転送が文字符号化の必要性なしで輸送されるのを許容します。 いかなるタイプのファイルも移す能力は貴重なエンドユーザサービスです。 また、どんな必要な文字符号化の不足でも、ソフトウェアを解読するどんなキャラクタも必要としないで、ユーザは受信データを利用できます。
- Multiple Body Parts
- 複数のボディ・パーツ
The ability to send multiple body parts within one message gives
the user the ability to send multiple logical components within
one message. This is a natural mechanism for users as it mirrors
the real life situation of being able to send within one message,
a letter, a word processor file, a spreadsheet file, etc.
1つのメッセージの中で複数の身体の部分を送る能力は1つのメッセージの中で複数の論理的なコンポーネントを送る能力をユーザに与えます。 1つのメッセージ、手紙、ワードプロセッサファイル、スプレッドシートファイルなどの中で発信できる現実の状況を反映するとき、これはユーザのための自然なメカニズムです。
- Feature rich messaging model
- 金持ちのメッセージングモデルを特集してください。
The features of X.400 are very rich. This provides benefits for
users as vendors are able to provide applications that can utilise
these extensive features in an interoperable manner due to the
standardisation of the features within X.400.
X.400の特徴は大金持ちです。 ベンダーがX.400の中の特徴の規格化のため共同利用できる方法でこれらの大規模な特徴を利用できる利用を提供できるとき、これは利益をユーザに提供します。
- Clear messaging model
- 明確なメッセージングモデル
X.400(1984), as one of its most wide reaching achievements, has
popularised within the market a consistent and clear model to
describe message handling systems. The decomposition of a message
handling system into UAs, MSs, MTAs, MTS - ADMDs and PRMDs and
Access Units / Gateways has proved to be an extremely useful tool
for users and vendors to understand and communicate their
messaging needs or solutions.
最も広い業績に達するものの1つとして、X.400(1984)はメッセージハンドリングシステムメッセージハンドリングシステムの分解についてUAsに説明するために市場の中で一貫して明確なモデルを流行らせました、MSs、MTAs、MTS--ユーザとベンダーが、彼らが必要性かソリューションを通信させると理解して、伝えるように、ADMDs、PRMDs、およびAccess Units/ゲートウェイは非常に役に立つツールであると判明しました。
RARE WG-MSG Task Force 88 [Page 19] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[19ページ]RFC1616X.400(88)
- Multiple lower layer networks
- 複数の下層ネットワーク
X.400 has embraced the concept that there are different technology
lower layer networks. This concept even allows multiple logical
networks of the same technology to be supported. X.400 allows the
messaging service to fully function even though the underlying
network is varying. In the real world of a non-uniform network
layer this is an extremely powerful capability.
X.400は異なった技術下層ネットワークがあるという概念を受け入れました。 この概念は同じサポートするべき技術の複数の論理的なネットワークを許容さえします。 基本的なネットワークは異なっていますが、X.400はメッセージングサービスを完全に機能させます。 不均等なネットワーク層の本当の世界では、これが非常に強力な能力です。
The list of major X.400(1988) extensions to X.400(1984) follows:
X.400(1984)への主要なX.400(1988)拡張子のリストは従います:
- Distribution Lists (DLs)
- 発送先リスト(dl)
A powerful mechanism for arbitrarily nested Distribution Lists
including the ability for DL owners to control access to their
lists and to control the destination of non delivery reports. The
current endemic use of DLs in the R&D community makes this a
fundamental requirement for any service. X.400(1988) uses X.500 to
provide a standardised support for DLs, although there have been
some needed standardised enhancements relating to the CCITT
defined DLs by the IETF MHS-DS work group. The provision of
powerful nesting capabilities plus management mechanisms for DL
owners within X.400(1988) DLs are features providing attractive
benefits for users and DL managers. There is already 'running
code', via the COSINE Explode project which is implementing the
MHS-DS based enhancements. The project builds upon experience
gained within a number of networks e.g., JNT and provides:
DL所有者が彼らのリストへのアクセスを制御して、非配送の目的地を制御する能力を含む任意に入れ子にされたDistribution Listsのための強力なメカニズムは報告します。 研究開発共同体でのDLsの現在の風土病の使用はこれをどんなサービスのための基本的な要件にもします。 X.400(1988)はDLsの標準化されたサポートを提供するのにX.500を使用して、標準化されるように必要である何かがありましたが、CCITTに関連する増進がIETF MHS-DS仕事グループでDLsを定義しました。 X.400(1988)DLsの中のDL所有者がいるので、強力な巣篭もり能力と管理メカニズムに関する条項はユーザとDLマネージャのために提供の魅力的な利益を特徴とします。 既に、MHS-DSがベースの増進であると実装しているCOSINE Explodeプロジェクトを通して'実行しているコード'があります。 経験での体格が数の中で獲得したプロジェクトは、例えばJNTをネットワークでつないで、提供されます:
- implementation of MHS-DS enhancements related to the
X.400(1988) DLs
- archiving of messages received by a DL.
- access by users to the DL archive via e-mail.
- subscription to a DL by users via e-mail.
- MHS-DS増進の実装はX.400(1988)DLsに関連しました--DLによって受け取られたメッセージの格納。 - メールを通したDLアーカイブへのユーザによるアクセス。 - メールを通したユーザによるDLの購読。
- Message Store (MS)
- メッセージストア(さん)
The Message Store provides a server for remote UAs on workstations
and PCs enabling messages to be held for their recipient, solving
the problems of non-continuous availability of such UAs. The
message store allows mobile workers, small offices and local
schools to become active messaging users in a cost effective
manner. The message store provides powerful selection mechanisms
allowing the user to select messages to be transferred between the
store and the workstation. This facility is not catered for
adequately by the P3 protocol of X.400(1984) and provides a major
incentive for transition.
Messageストアは彼らの受取人のために保持されるべきメッセージを可能にしながら、ワークステーションとPCの上でリモートUAsにサーバを供給します、そのようなUAsの非連続した有用性の問題を解決して。 メッセージ店は、費用効率がよい方法でユーザを通信させながらアクティブになるようにモバイル労働者、小さいオフィス、および地元の学校を許容します。 メッセージ店はユーザが店とワークステーションの間に移されるべきメッセージを選択できる強力な選択メカニズムを提供します。 この施設は、X.400(1984)のP3プロトコルによって適切に満たされないで、主要な誘因を変遷に提供します。
RARE WG-MSG Task Force 88 [Page 20] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[20ページ]RFC1616X.400(88)
- X.500 Directory names
- X.500ディレクトリ名
Support for use of Directory Names in MHS will allow a transition
from use of O/R addresses to Directory Names when X.500
Directories become widespread, thus removing the need for users to
know about MHS topological addressing components.
X.500ディレクトリが広範囲になるとき、MHSにおけるディレクトリNamesの使用のサポートはO/Rアドレスの使用からディレクトリNamesまでの変遷を許容するでしょう、その結果、ユーザがMHSの位相的なアドレシングの部品に関して知る必要性を取り除きます。
The ability for X.400(1988) messages to contain directory names
instead of the O/R addresses is a powerful feature for users as it
frees them of the necessity to insert O/R addresses containing
routing information but allows them to insert the more natural
directory names. However, the management of the large amounts of
distributed data contained within the directory is problematic in
that it involves a number of organisational issues and not just
software issues. A number of X.400(1988) UAs which allow users to
insert directory names instead of O/R addresses have already been
developed.
O/Rアドレスの代わりにディレクトリ名を含むX.400(1988)メッセージのための能力で、ユーザのためのルーティング情報を含むO/Rアドレスを挿入する必要性の彼らを解放するときの強力な特徴ですが、それらは、より当然のディレクトリ名を挿入します。 しかしながら、ソフトウェア問題だけではなく、多くのorganisational問題にかかわるので、ディレクトリの中に含まれた多量の分散データの管理は問題が多いです。 ユーザにO/Rアドレスの代わりにディレクトリ名を挿入させる多くのX.400(1988)UAsが既に開発されました。
- Support for EDI
- EDIのサポート
Through the definition of Pedi, as defined in X.435, X.400(1988)
offers integrated support for EDI messaging. The CEC TEDIS program
has mandated X.400 as the main carrier for EDI, and standardised
how EDI transactions are inserted into X.400 messages (i.e., Pedi
and P2). This provides a strong incentive to provide native
X.400(1988) services to users and applications thus encouraging
commercial EDI traffic to migrate to X.400(1988).
ペディ族の定義で、X.435で定義されるように、X.400(1988)はEDIメッセージングの統合サポートを提供します。 CEC TEDISプログラムは、EDIのためのメインキャリヤーとしてX.400を強制して、EDIトランザクションがどうX.400メッセージ(すなわち、ペディ族とP2)に挿入されるかを標準化しました。 これはその結果、商業EDIトラフィックがX.400(1988)にわたるよう奨励しながらネイティブのX.400(1988)にユーザとアプリケーションに対するサービスを供給する強い動機を提供します。
- Secure Messaging
- 安全なメッセージング
The provision of secure messaging services including
authentication, confidentiality, integrity and non-repudiation as
well as secure access between MHS components are important
benefits for the R&D community. The base standards are adequate
for security, however organisational and software issues need
still to be solved. Organisational issues of globally scaling the
distribution of secret keys is still unsolved. Software issues of
how end users will be able to comfortably and securely input
secret keys of length 512 -> 1024 bits into security software need
to be solved.
認証を含む安全なメッセージングサービスの設備、MHSの部品の間の秘密性、保全、および非拒否であって安全なアクセスは研究開発共同体に、重要な利益です。 ベース規格がセキュリティのために適切である、しかしながら、organisationalとソフトウェア問題はまだ解決されている必要があります。 秘密鍵の分配をグローバルにスケーリングするOrganisational問題はまだ未解決です。 エンドユーザがどう楽にしっかりと長さ512の->の秘密鍵を機密保護ソフトウェアに1024ビット入力できるかに関するソフトウェア問題は、解決される必要があります。
- Multimedia
- マルチメディア
The definition of a number of additional body parts plus the
ability to define new body parts (e.g., Word Processor formats,
Excel documents, etc.) provides the basis for multimedia services
over X.400(1988). As well, the newly defined General Text body
part supports multinational character sets (except for ISO 10646)
多くの追加身体の部分の定義と新しい身体の部分(例えば、Word Processor形式、Excelドキュメントなど)を定義する能力はX.400(1988)の上のマルチメディアサービスの基礎を提供します。 また、新たに定義された一般Text身体の部分は多国籍の文字集合をサポートします。(ISO10646を除いた)
RARE WG-MSG Task Force 88 [Page 21] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[21ページ]RFC1616X.400(88)
without the need for transmission encoding. However, unlike MIME,
X.400(1988) is only specifying a standard for multimedia
messaging. To achieve multimedia document exchange, there is a
further text exchange standard such as ODIF, Hytime, etc., needed.
トランスミッションコード化の必要性なしで。 しかしながら、MIMEと異なって、X.400(1988)はマルチメディアメッセージングの規格を指定しているだけです。 マルチメディアドキュメント交換を達成するために、ODIFなどの交換規格、Hytimeなどが必要としたさらなるテキストがあります。
- Character set support for extended addressing
- 拡張アドレシングの文字集合サポート
A highly desirable potential benefit for European R&D users is
provided by the extended character set support(i.e., T.61) within
addresses. Nearly all European languages, except for Greek and
Cyrillic, are supported by the T.61 teletex encoding. Further
extensions to X.400 for support of extended character sets has
been defined by the RARE WG on character sets and RARE WG on
messaging [15].
拡張文字集合サポート(すなわち、T.61)でアドレスの中でヨーロッパ人の研究開発ユーザには、非常に望ましい潜在的利益を提供します。 ギリシア語とキリール文字以外のほとんどすべてのヨーロッパの言語がT.61テレテックスコード化でサポートされます。 拡張文字集合のサポートのためのX.400へのさらなる拡大はメッセージング[15]で文字集合とRARE WGの上のRARE WGによって定義されました。
- Physical Delivery Services
- 物理的なデリバリ・サービス
This standardised method for a message to be delivered on a
physical medium, such as paper, through the normal postal service
is useful when trying to reach a very wide number of (non-
electronically reachable) recipients. In effect this service
provides an ability to 'go the last mile' and communicate with
users previously not easily reachable e.g., farmers, etc.
非常に広い数の(非電子的に届く)の受取人に届こうとするとき、正常な郵便業務を通した紙などの物理的な媒体の上で提供されるべきメッセージのためのこの標準化されたメソッドは役に立ちます。 事実上、このサービスが'碁への能力に最後のマイルを提供する、'、ユーザが以前に容易に届いていなく、例えば農業者などを伝えてください。
- General Extension Mechanism
- 一般拡張機能
One of the major assets of X.400(1988) is the extension mechanism.
This is used to carry most of the extensions defined in these
standards, but its principal benefit will be in reducing the
trauma of transitions to future versions of the standards.
X.400(1988)の主要な資産の1つは拡張機能です。 これはこれらの規格で定義された拡大の大部分を運ぶのに使用されますが、規格の将来のバージョンへの変遷のトラウマを減少させるのにおいて主要な利益があるでしょう。
Provided that implementations of the X.400(1988) standards do not
try to place restrictions on the values that may be present, any
future extension will be relayed by these implementations when the
extension is not critical, thus providing a painless migration to
new versions (1992 and beyond) of the standards.
拡大が重要でないときに、X.400(1988)規格の実装が存在するかもしれない値に関して制限を課そうとしないと、どんな今後の拡大もこれらの実装によってリレーされるでしょう、その結果、規格の新しいバージョン(1992と以遠)に無痛の移行を提供します。
- UA Capability Registration
- UA能力登録
With the extra functionality available to X.400(1988 and
especially 1992) UAs (i.e., extra non-IA5 body parts, secure
messaging, etc.) it is expected that the demand to register UA
capabilities will increase. In that respect X.400(1988)'s ability
to query X.500, where such capabilities would be stored, is a
significant potential benefit for users.
X.400(1988と特に1992)UAs(すなわち、付加的な非IA5身体の部分、安全なメッセージングなど)に利用可能な付加的な機能性で、UA能力を登録するという需要が増加すると予想されます。 その点で、X.500について質問するX.400(1988)の性能はユーザのためのそのような能力が保存されるところの大きな潜在的可能性利益です。
RARE WG-MSG Task Force 88 [Page 22] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[22ページ]RFC1616X.400(88)
- X.500 support for MTA routing
- MTAルーティングのX.500サポート
The piloting of X.500 to support MTA routing within the R&D
community has already commenced, on a small experimental scale,
via the Longbud project co-ordinated by the IETF MHS-DS work
group. Some concrete benefits promised by X.500 based routing are:
研究開発共同体の中でMTAがルーティングであるとサポートするX.500の操縦は既に始まりました、わずかな実験スケールで、IETF MHS-DS仕事グループによって調整されたLongbudプロジェクトを通して。 X.500のベースのルーティングで約束されたいくつかの具体的な利益は以下の通りです。
- routing based upon content types, security, transport stacks
and other criteria allow optimum routing paths to a
destination MTA to be chosen. (There is presently no such
similar capability within the DNS).
- content typeに基づくルーティング、セキュリティ、輸送スタック、および他の評価基準は、目的地MTAへの最適なルーティング経路が選ばれるのを許容します。 (現在、DNSの中にそのようなどんな同様の能力もありません。)
- allowing the routing information to be inserted and modified
in a distributed manner reduces (if not eliminates) the
necessity of central distribution of static routing tables.
The consequent reduction in manpower to co-ordinate MTA
routing plus the increase in scalability of the service
allows a truly global messaging service to be put in place.
- ルーティング情報が分配された方法で挿入されて、変更されるのを許容するのがスタティックルーティングテーブルの主要な分配の必要性を減少させます(そうでなければ、排泄します)。 サービスのスケーラビリティのMTAルーティングと増加を調整する労働力の結果の減少は、本当にグローバルなメッセージングサービスが適所に置かれるのを許容します。
6. Migration to X.400(1988)
6. X.400への移行(1988)
What is clear from the previous chapters is that;
前の章から明確なことはそれです。
- The resources, human or financial, to operate multiple wide
area messaging services connecting together independent
organisations are high. As such it is desirable to try and
keep to a minimum the number of such services. This statement
is true for the R&D community but is also highly likely to be
valid for the general European industry.
- リソースであり、人間的であるか、または財政的であることで、一緒に接続する複数の広い領域メッセージングサービスを操作するために、独立機関は高いです。 そういうものとして、そのようなサービスの数を最小限に保ってみるのは望ましいです。 この声明も、研究開発共同体に本当ですが、また、非常に一般的なヨーロッパの産業に有効である傾向があります。
- There are two publicly available technological standards
that can be used by open communities, such as the R&D
community and public service providers: the X.400(1984 and
1988) recommendations and the Internet RFC 822 / MIME / PEM
standards.
- 疎生群落が使用できる2つの公的に利用可能な技術的な規格があります、研究開発共同体や社会奉仕プロバイダーのように: X.400(1984と1988)推薦とインターネットRFC822/MIME/PEM規格。
- There is an established very large global user base of
Internet RFC 822 and X.400(1984) messaging services. Both
services have their own momentum within different parts of
the user community, both are still developing and growing
fast.
- インターネットRFC822とX.400(1984)メッセージングサービスの確立した非常に大きいグローバルなユーザベースがあります。 両方のサービスがユーザーコミュニティの異なった地域の中にそれら自身の勢いを持っていて、両方が、まだ展開していて、伸びが早いです。
From the above discussion, it is clear that the infrastructure services that have to be supported within these open communities, and especially within the R&D community, are RFC 822 / MIME / PEM, X.400(1984) and X.400(1988). X.400(1988) will be the preferred protocol for inter-organisational connection for European industry and government and parts of the European R&D community. RFC 822 /
上の議論によって、これらの疎生群落以内と研究開発共同体の特に中で支持されなければならないインフラストラクチャサービスがRFC822/MIME/PEMと、X.400(1984)とX.400(1988)であることは明確です。 X.400(1988)はヨーロッパの産業と政府のための相互organisational接続とヨーロッパの研究開発共同体の地域への都合のよいプロトコルになるでしょう。 RFC822/
RARE WG-MSG Task Force 88 [Page 23] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[23ページ]RFC1616X.400(88)
MIME / PEM will be the preferred protocol suite for inter- organisational connection for the Internet community and, as products are already widely available, it is the preferred protocol for parts of the European R&D community.
MIME/PEMはインターネットコミュニティのための相互organisational接続に、都合のよいプロトコル群になるでしょう、そして、製品が既に広く利用可能であるときに、それはヨーロッパの研究開発共同体の地域への都合のよいプロトコルです。
The goal of European pervasive messaging - incorporating Industry, Government and Academia - would be best accommodated and reached by the establishment of a single messaging service. However taking the above into account, this is not feasible, as X.400 and RFC 822 based services will be around for a long time to come. To increase the functionality of Wide Area E-mail services there is a clear necessity to:
ヨーロッパの普及しているメッセージングの目標(Industry、政府、およびAcademiaを組み込む)は、単一のメッセージングサービスの設立によって対応するのが最も良く、達せられるでしょう。 上記を考慮に入れて、これがX.400とRFC822としてどのように可能でなくても、ベースのサービスが周囲に今後ずっとあるでしょう。 そこでWide Areaメールサービスの機能性を増加させるのは、以下への明確な必要性です。
- migrate RFC 822 services to a RFC 822 / MIME / PEM service.
A MIME based service offers more functionality to the user
than a plain RFC 822 service.
- 移動してください。RFC822/MIME/PEMサービスに対するRFC822サービス。 MIMEに基づいているサービスは明瞭なRFC822サービスよりユーザへの機能性を提供します。
- migrate existing X.400 services to a X.400(1988) service.
Due to the lack of scalability of the X.400(1984) service in
terms of extra functionality, it will become increasingly
difficult to meet the needs of research users of existing
X.400(1984) services unless an X.400(1988) service is put
into place.
- 存在しながら、移動してください。X.400はX.400(1988)にサービスを修理します。 余分な機能性に関するX.400(1984)サービスのスケーラビリティの不足のため、X.400(1988)サービスが場所に入れられない場合、既存のX.400(1984)サービスの研究ユーザの需要を満たすのはますます難しくなるでしょう。
- provide a transparent gateway between X.400(1988) and RFC
822/MIME/PEM. For the European R&D community it is essential
to have a transparent gateway between the X.400(1988) service
and the RFC 822 / MIME / PEM service, thus ensuring
connectivity between these two services with a maximum
functionality.
- X.400(1988)とRFC822/MIME/PEMの間に透明なゲートウェイを供給してください。 ヨーロッパの研究開発共同体に、X.400(1988)サービスとRFC822/MIME/PEMサービスの間に透明なゲートウェイを持っているのは不可欠です、その結果、最大の機能性でこれらの2つのサービスの間の接続性を確実にします。
Such a gateway is technically feasible and it is an essential part of an unified E-mail service. Without such a standardised gateway the overall E-mail service would deteriorate.
そのようなゲートウェイは技術的に可能です、そして、それは統一されたメールサービスの不可欠の部分です。 そのような標準化されたゲートウェイがなければ、総合的なメールサービスは悪化するでしょう。
The lack of open standards for the PC LAN messaging systems discourages their use as 'backbone' messaging technologies within open communities. However the products that these systems deliver to end users ensures that their already large share of the messaging market will continue to exist for some time. Thus it is also essential that strategies that allow these systems to be 'seamlessly' integrated within the global messaging community are put in place. Not least due to the indications that the main messaging vendors are developing X.400(1988) and RFC 822/MIME gateways, a strategy to link these systems together via X.400(1988) and RFC 822/MIME should be developed.
'背骨'メッセージング技術が中で共同体を開くとき、PC LANメッセージシステムのためのオープンスタンダードの不足は彼らの使用に水をさしています。 しかしながら、これらのシステムがエンドユーザに届ける製品は、彼らのメッセージング市場の既に大きいシェアがしばらく存続するのを確実にします。 したがって、また、グローバルなメッセージング共同体の中にこれらのシステムが'継ぎ目なく'統合しているのを許容する戦略が適所に置かれるのも、不可欠です。 主なメッセージング業者がX.400(1988)とRFC822/MIMEゲートウェイを開発しているという特に指摘のため、X.400(1988)とRFC822/MIMEを通してこれらのシステムを結びつける戦略は開発されるべきです。
RARE WG-MSG Task Force 88 [Page 24] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[24ページ]RFC1616X.400(88)
To make migration to a X.400(1988) service feasible, extensive migration and coexistence options for various non-X.400(1988) users have to be developed. Main issue in each migration strategy remains the co-operation of the users. The migration needs to be user-driven, i.e., the users need to be convinced of the added functionality (versus the cost) of migrating towards X.400(1988). A detailed summary of the different issues and possible problems involved in the transition to a X.400(1988) based messaging service, with respect to what are commonly accepted as the four most important messaging services: RFC 822, MIME and PEM; X.400(1984); MAIL-11 and PC LAN messaging systems are presented in this chapter.
X.400(1988)サービスへの移動を可能で、大規模な移動と共存にするように、(1988)様々な非X.400ユーザのためのオプションは開発されなければなりません。 それぞれの移動戦略による本題はユーザの協力のままで残っています。 ユーザが駆動になる移動の必要性、すなわち、ユーザはX.400(1988)に向かって移動する付記された機能性(費用に対する)が確信する必要があります。 X.400(1988)への変遷にかかわる別問題と起こりうる問題の詳細な概要はメッセージングサービスを基礎づけました、4個の最も重要なメッセージングサービスとして認められて、何が一般的にそうかに関して: RFC822、MIME、およびPEM。 X.400(1984)。 メール-11とPC LANメッセージシステムは本章に提示されます。
6.1. PC LAN E-mail systems
6.1. PC LANメールシステム
To provide coexistence and migration the usage of gateways is unavoidable. The quality of these gateways, with regard to:
ゲートウェイの使用法を共存と移動に提供するのは避けられません。 これらのゲートウェイの以下に関する品質
- Transparency (gatewaying multimedia messages, transparent
addressing)
- Manageability
- Reliability
- 透明(マルチメディアメッセージ、見え透いたアドレシングをgatewayingする)--管理可能性--信頼性
has to be improved. Ultimately through usage of APIs like MAPI and CMC, the users interface hopefully will become independent of the mail protocol that is used. It will then be expected to be possible to let the user retain his preferred mail user interface, while the protocol used migrates to X.400(1988).
改良されるために、持っています。 結局、MAPIとCMC、ユーザのようなAPIの使用法で、インタフェースは希望をいだいて使用されたメールプロトコルから独立するようになるでしょう。 次に、ユーザに彼の都合のよいメールユーザーインタフェースを保有させるのにおいてそれが可能であると予想されるでしょう、使用されるプロトコルはX.400(1988)にわたりますが。
Via the use of these APIs it may be possible to access the full features of X.400(1988) while retaining a proprietary PC LAN UAs. This way a PC LAN can be easily connected to a X.400(1988) backbone. This usage of APIs to ease migration for end users should be encouraged.
これらのAPIの使用で、X.400(1988)の完全な特徴にアクセスするのは独占PC LAN UAsを保有している間、可能であるかもしれません。 このように、X.400(1988)背骨に容易にPC LANを接続できます。 エンドユーザのために移動を緩和するAPIのこの使用法は奨励されるべきです。
The migration of PC LAN E-mail systems will likely be driven by the commercial vendors of mail enabled applications, such as UAs, Work Group Systems, Task Flow Systems plus X.400(1988) MTAs and gateways able to serve these applications via these new APIs.
PC LANメールシステムの移動はおそらく運転されて、メールの商業業者がアプリケーションを可能にしました、UAsや、Work Group Systemsや、Task Flow Systemsや、X.400(1988)MTAsやこれらの新しいAPIを通してこれらのアプリケーションに役立つことができるゲートウェイなどのようにことでしょう。
6.2. RFC 822, MIME and PEM services
6.2. RFC822、MIME、およびPEMサービス
A migration from RFC 822 / MIME and PEM services to X.400(1988) needs to be formulated for those management domains that wish to effect this change. As well a long term transition and coexistence phase needs to be accommodated due to the existing base of RFC 822 users. An understanding of the issues involved in migrating from RFC 822 to X.400(1988) messaging services is essential before any rational decisions on migration can occur. Certainly one, if not the main,
RFC822/MIMEとX.400(1988)に対するPEMサービスからの移動は、この変化に作用したがっているそれらの管理ドメインに定式化される必要があります。 また、変遷と共存が位相を合わせる長期は、RFCの存立基盤への設備された支払われるべきものが822人のユーザであったなら必要があります。 移動のどんな合理的な決定も起こることができる前にRFC822からX.400(1988)メッセージングサービスまで移動するのにかかわる問題の理解は不可欠です。 確かに1、またはメイン
RARE WG-MSG Task Force 88 [Page 25] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[25ページ]RFC1616X.400(88)
issue in such a migration is that the migration must allow a transition period where maximum functionality between both services exists. Any migration must be aware that RFC 822 messaging services are a 'moving target'.
そのような移動における問題は両方のサービスの間の最大の機能性が存在しているところに移動が過渡期を許容しなければならないということです。 どんな移動もRFC822メッセージングサービスが'移動標的'であると意識しているに違いありません。
- Ease of transition as perceived by an RFC 822 user mandates
that the user's existing mail folders are converted into the
new mail product's folder system flawlessly.
- RFC822ユーザによって知覚される変遷の容易さは、ユーザの既存のメール・フォルダが新メール製品のフォルダーシステムに無傷に変換されるのを強制します。
- The RFC 822's user's e-mail address should remain the same
even after a migration. (i.e., the user keeps the same address
that has two different notation forms: X.400 and RFC 822).
- RFC822のユーザのEメールアドレスは移動の後にさえ同じままで残るべきです。 (すなわち、ユーザは2つの異なった記法フォーム: X.400とRFC822を持っているのと同じアドレスを保管します。)
- Users contemplating a migration will be stimulated to do so
if they experience no loss of service as regards MIME and
X.400(1988) gatewaying; are still able to insert RFC 822
style addresses into the X.400(1988) UA and are provided with
high performance X.400-to-RFC 822 gateways.
- 彼らがあいさつMIMEとX.400(1988)gatewayingとしてサービスの損失を全く経験しないと、移動を熟考するユーザはそうするために刺激されるでしょう。 まだX.400(1988)UAにRFC822スタイルアドレスを挿入できて、RFCへの高性能X.400 822門を提供します。
- The added connectivity provided by X.400(1984 or 1988)
gateways to fax, telex, post etc. plus additional X.400 users
that the user is able to reach easily (whilst not losing
connectivity to RFC 822 addresses) plus the additional
functionality of X.400(1988) possible when communicating with
X.400(1988) users will also act as a stimulant to a
migration.
- 付記された接続性は、ファックスで送るX.400(1984か1988)ゲートウェイ、テレックス、ポストなど、および追加X.400ユーザでユーザが容易に達することができるのを(RFC822アドレスに接続性を失っていない間)前提としました、そして、また、X.400(1988)ユーザとコミュニケートするとき、可能なX.400(1988)に関する追加機能性は興奮剤として移動に機能するでしょう。
- The functionality provided by RFC 822 / MIME products will
be the yardstick that an RFC 822 user compares an offered
X.400(1988) product with. As such X.400(1988) products must
provide some basic and important functions like: Character
Set support via GeneralText; Multimedia capability via
Extended Body Parts; low message delays within the seconds
time scales and ease of configuration of products. At present
there is no RFC 822 equivalent to X.400 delivery and receipt
notifications and as such these functions are seen as extra
functionality by the user.
- RFC822/MIME製品によって提供された機能性はRFC822ユーザが提供されたX.400(1988)製品を比較するヤード尺になるでしょう。 そういうものとして、X.400(1988)製品は以下のようにいくつかの基本的で重要な機能を提供しなければなりません。 GeneralTextを通した文字コードサポート。 Extendedボディ・パーツを通したマルチメディア能力。 少ないメッセージは、製品の構成を時間がスケーリングする秒以内に遅らせて、軽くならせます。 現在のところ、X.400配送とRFC822同等物が全くありません、そして、領収書通知とそういうものとしてこれらの機能はユーザによって余分な機能性と考えられます。
- A follow on to the extra functionality point above is that
present RFC 822 users, most likely commercial users, that
want to be able to use EDI or other mail enabled applications
that need security, message audits and positive confirmations
will be encouraged to migrate to X.400(1988). A decision to
use X.400(1988) in this case would be especially attractive
for those commercial RFC 822 users that are already operating
multiple lower layer networks. As X.400(1988) accommodates
multiple different network layers easily, the cost to migrate
could be considered quite small.
- 余分な機能性ポイント上への尾行は822人のユーザ、EDIを使用できるようになりたがっているほとんどのありそうな営利的ユーザをRFCに紹介するか、または他のメールがセキュリティを必要とするアプリケーションを可能にして、メッセージ監査と積極的確認がX.400(1988)にわたるよう奨励されるということです。 既に複数の下層ネットワークを経営しているそれらの商業RFC822ユーザにとって、この場合X.400(1988)を使用するという決定は特に魅力的でしょう。 X.400(1988)が容易に複数の異なったネットワーク層を収容するとき、かなり小さいと移動する費用を考えることができました。
RARE WG-MSG Task Force 88 [Page 26] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[26ページ]RFC1616X.400(88)
6.3. X.400(1984) services
6.3. X.400(1984)サービス
A number of problems can be identified in a migration from X.400(1984) to X.400(1988). They are summarised as,
X.400(1984)からX.400(1988)までの移動で多くの問題を特定できます。 それらについて略言します。
- OSI supporting layers are mandatory in the ISO10021 MOTIS
standard, while the support of the complete OSI stack (normal
mode ) is optional in the otherwise equivalent CCITT
X.400(1988) specifications. It is thus recommended that the
migration from X.400(1984) should be straight to ISO 10021
i.e., straight to use of the full OSI stack with normal mode
RTS.
- 層を支えるOSIはISO10021 MOTIS規格で義務的です、完全なOSIスタック(正規モード)のサポートがそうでなければ、同等なCCITT X.400(1988)仕様で任意ですが。 その結果、X.400(1984)からの移動がすなわち、まっすぐ正規モードRTSとの完全なOSIスタックの使用へのISO10021にまっすぐであることは、お勧めです。
- There is a negative impact on quality of service caused by
implementation decisions related to the 'General Extension
Mechanism'. To overcome this negative impact no minimal
X.400(1988) MTAs, which relay the syntax but understand none
of the semantics of extensions, should be used.
- 'Extension Mechanism司令官'に関連する実現決定で引き起こされたサービスの質への負の衝撃があります。 最小量のX.400(1988)のこの負の衝撃ノーMTAsに打ち勝つのは使用されているべきです。(構文をリレーしますが、MTAsは拡大の意味論のいずれも理解していません)。
- All X.400(1988) MTAs should generate reports containing the
extensions that are present in the original message and route
such reports through the DL expansion hierarchy where
appropriate.
- すべてのX.400(1988)MTAsがオリジナルのメッセージで存在している拡大を含むレポートを作って、DL拡大階層構造を通してそのようなレポートを適切であるところに発送するはずです。
- Choice of standards to be used within mixed X.400(1984 and
1988) management domains needs to accommodate in one option
the danger of undetectable routing loops from incorrectly
configured routing entries and in another option the problem
that systems that have fixed the routing loop problem may not
all be consistently implemented due to ambiguities within the
standards. The choice of which of these two options a
management domain uses internally has no impact on external
management domains.
- 1つのオプションで検知されないルーティングという危険を収容する混ぜられたX.400(1984と1988)管理ドメインの必要性の中で使用されるべき規格の選択は不当に構成されたルーティングエントリーと別のオプションでルーティング輪の問題を修正したシステムがあいまいさのために規格の中で一貫してすべて導入されないかもしれないという問題を輪にします。 選択は管理ドメインが内部的にこれらの2つのオプションのどれを使用するかを外部の管理ドメインに変化も与えません。
- DDA support is needed by X.400(1984) systems to address
X.400(1988) Common Name Attribute users [2].
- DDAサポートは、X.400(1988)俗称Attributeユーザ[2]に演説するためにX.400(1984)システムによって必要とされます。
- Minimum loss of service quality mandates that downgrading of
X.400(1988) body parts to X.400(1984) bodyparts be done
according to the MIMEMHS specifications [4].
- サービス品質の最小の損失は、MIMEMHS仕様[4]通りにX.400(1984)bodypartsへのX.400(1988)身体の部分の格下げをするのを強制します。
- To enhance connectivity to both X.400(1984 and 1988)
management domains without degradation of X.400(1988)
service, management domain entry points that support both
X.400(1984 and 1988) are recommended.
- X.400(1988)サービス、両方を支持する管理ドメインエントリー・ポイントの退行なしで両方のX.400(1984と1988)管理ドメインに接続性を高めるために、X.400(1984と1988)はお勧めです。
RARE WG-MSG Task Force 88 [Page 27] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[27ページ]RFC1616X.400(88)
- Ensuring that no X.400(1988) MTAs transit via X.400(1984)
MTAs. This allows no degradation of X.400(1988) service
quality [17].
- X.400(1984)MTAsを通してそのノーX.400(1988)にMTAsトランジットを確実にします。 これはX.400(1988)サービス品質[17]の低下を全く許容しません。
The consequence of the last point is that the existing European Research X.400(1984) - formerly COSINE MHS - MTA RELAY backbone should be one of the first MTA communities to migrate to X.400(1988).
最後のポイントの結果は既存のヨーロッパのResearch X.400(1984)--以前COSINE MHS--MTA RELAY背骨がX.400(1988)にわたる最初のMTA共同体の1つであるべきであるということです。
6.4. Mail-11 services
6.4. メール-11のサービス
The Mail-11 (also known as DECnet mail) e-mail service is the major e-mail service used within the High Energy Physics and Space Physics Analysis Networks (i.e., HEPnet and SPAN) and is the native e-mail service present on VMS operating systems. The Mail-11 service is considered the most popular service by the large HEPnet / SPAN community. Mail-11 provides also large and easy to use gateways to other E-mail protocols, like X.400 (84), RFC 822 (SMTP over TCP/IP, DECnet and X.25, BSMTP over NJE), and PC LAN E-mail services.
メール-11(また、DECnetメールとして、知られている)メールサービスは、High Energy PhysicsとSpace Physics Analysis Networks(すなわち、HEPnetとSPAN)の中で利用された主要なメールサービスであり、VMSオペレーティングシステムの現在のネイティブのメールサービスです。メール-11サービスは最もポピュラーなサービスであると大きいHEPnet / SPAN共同体によって考えられます。 また、大きくて、他のメールプロトコルへのゲートウェイを使用するのが簡単な状態でメール-11は提供されます、X.400(84)、RFC822(NJEの上のTCP/IPの上のSMTPとDECnetとX.25、BSMTP)、およびPC LANメールサービスのように。
Jointly with the "old style" Mail-11 UA, the DECnet Phase V (OSI CLNS) service provides the native capability to run X.400 (88) and X.400(1984) services. There is thus the potential for X.400 (88) services to become available as soon as the HEPnet / SPAN community migrates to DECnet Phase V. However the availability of VMS based UAs for the X.400(1988) service is still very limited and is thus forcing users to continue to stay with their Mail-11 UA (and thus the Mail-11 service).
「古いスタイル」メール-11UAと一緒に、DECnet Phase V(OSI CLNS)サービスはX.400(88)とX.400(1984)サービスを走らせるネイティブの能力を提供します。 その結果、HEPnet / SPAN共同体がDECnet Phase V.Howeverにわたって、X.400(1988)サービスのためのVMSのベースのUAsの有用性がすぐX.400(88)サービスが利用可能になって、まだ非常に制限されていて、その結果、ユーザに彼らのメール-11UA(そして、その結果、メール-11サービス)と共に滞在し続けることにさせるのである可能性があります。
Users in HEPnet / SPAN are demanding enhancements to their mail services to support multimedia and delivery / read receipt services. This is a strong driving factor for good X.400(1988) UAs to become available soon to allow users to properly use the available X.400(1988) service of DECnet Phase V.
HEPnet / SPANのユーザは、それらのメールへの増進が領収書サービスをサポートマルチメディアと配送に修理したか、または読み込んだのを要求しています。 これは良いX.400(1988)UAsがすぐユーザが適切にDECnet Phase Vの利用可能なX.400(1988)サービスを利用するのを許容するために利用可能になる強い運転する要素です。
7. Benefits of migrating to X.400(1988) and the involved costs
7. X.400(1988)にわたる利益とかかわったコスト
The actual as compared to the potential benefits of migrating from one's existing mail system to a new mail protocol is very dependent on good products, good organisation of the migration and a degree of commitment that the transition is worth the cost. Quantifiable and accurate cost / benefit ratios for such a migration are not possible within the decentralised European R&D environment and as such are not generated.
人の既存のメールシステムから新しいメールプロトコルまで移動する潜在的利益と比較される実際は良い製品、移動の良い機構、および変遷は費用の価値があるという委任の1度に非常に依存しています。 そのような移動のための定量化可能で正確な費用/利益比は、分散ヨーロッパの研究開発環境の中で可能でなく、またそういうものとして発生しません。
We have in this chapter listed the benefits that such a migration to X.400(1988) achieves. We have also given an indication of the relative costs of such a migration. Provided that there are good products, and taken in conjunction with the recommendations of
私たちは本章にX.400(1988)へのそのような移動が実現する利益を記載しました。 また、私たちはそのような移動の相対的なコストのしるしを与えました。 良い製品があります、そして、推薦に関連して、取ります。
RARE WG-MSG Task Force 88 [Page 28] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[28ページ]RFC1616X.400(88)
Chapter 8 and Appendices A and B, the task force is confident that these potential benefits will translate into actual benefits and be worth the costs incurred.
第8章とAppendices AとB、特別委員会はこれらの潜在的利益が実利に翻訳して、被られたコストの価値があると確信しています。
*Benefits*
*利益*
Below is a list of non-technically oriented benefits and the features of X.400(1988) that enable these benefits to occur. The benefit of,
以下に、指向の非技術的に利益のリストとこれらの利益が起こるのを可能にするX.400(1988)の特徴があります。 利益を得ます。
- efficient and innovative communication within Europe is
assisted by establishing an X.400(1988) messaging service
that integrates European industry, government and academia;
- ヨーロッパの中の効率的で革新的なコミュニケーションはヨーロッパの産業、政府、およびアカデミーを統合するX.400(1988)メッセージングサービスを設立することによって、補助されます。
- an increase in business efficiency by the use of EDI (for
example automatic processing of business forms, exchange of
business contracts, etc.) is enhanced by the security aspects
of X.400(1988) i.e., non-repudiation, authentication,
confidentiality, integrity plus secure access between MHS
components.
- EDI(ビジネス形式の例えば、自動である処理、ビジネス契約の交換など)の使用による事業効率の増加はX.400(1988)のセキュリティ局面によってすなわち、非拒否する状態で機能アップされます、認証、秘密性、MHSの部品の間の保全のプラスの安全なアクセス。
- allowing European users to communicate in their native
European languages is brought about by the GeneralText body
part of X.400(1988).
- ヨーロッパ人のユーザが彼らの固有のヨーロッパの言語で交信するのを許容するのがX.400(1988)のGeneralText身体の部分によって引き起こされます。
- remote users and Small and Medium size Enterprises(SME)
using e-mail for electronic commerce is encouraged by
reducing the entry level costs for use of e-mail. An SME's
use of Remote UAs in conjunction with a service provider's MS
-instead of purchasing their own MTA - is accommodated by
X.400(1988).
- 電子商取引がエントリーを抑えることによって奨励されるので、メールを使用するリモート・ユーザー、Small、およびMediumサイズエンタープライズ(SME)はメールの使用のためにコストを平らにします。 の代わりにする、サービスプロバイダーのMSに関連したRemote UAsのSMEの使用、-、それら自身のMTAを購入します--X.400(1988)によって設備されます。
- providing global messaging for all e-mail users, but
recognising the existing market realities of heterogeneous e-
mail systems, would be enhanced by the establishment of
gateways to X.400(1988).
- グローバルなメッセージングをすべてのEメールの利用者に提供しますが、異種の電子メールシステムの既存市場現実を認識するのはX.400(1988)へのゲートウェイの設立によって高められるでしょう。
- being able to recover costs by charging and accounting for
messaging services back to users - this is especially
important for commercial service providers - is brought about
by the message auditing capabilities of X.400(1988).
- メッセージングサービスのための充電と会計で商業サービスプロバイダーに、これが特に重要であるというユーザにコストを取り戻して戻すことができるのはX.400(1988)のメッセージの監査の能力によって引き起こされます。
- communication with users that have no access to E-mail (for
example if such users are defined within Distribution Lists)
is enhanced by X.400(1988)'s support for gateways to physical
delivery, fax, telex, teletex, etc.
- メール(例えば、そのようなユーザがDistribution Listsの中で定義されるなら)に近づく手段を持っていないユーザとのコミュニケーションはX.400(1988)の物理的な配送、ファックス、テレックス、テレテックスなどへのゲートウェイのサポートで高められます。
RARE WG-MSG Task Force 88 [Page 29] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[29ページ]RFC1616X.400(88)
- building upon the existing X.400(1984) infrastructure (i.e.,
reduction of establishment costs) is brought about by
migrating the X.400(1984) infrastructure to X.400(1988).
- 既存のX.400(1984)インフラストラクチャ(すなわち、設立コストの減少)を当てにするのは移動するのによるX.400(1984)インフラストラクチャに関してX.400に持って来られます(1988)。
- a reduction in manpower (and thus costs) to manage a global
messaging service is brought about by the messaging service's
ability to utilise the global distributed directory for
management information.
- グローバルなメッセージングサービスを管理する労働力(そして、その結果、コスト)の減少は経営情報のためのグローバルな分配されたディレクトリを利用するメッセージングサービスの性能によって引き起こされます。
- the messaging infrastructure to meet new user requirements
is enhanced by the support for General Extensible Mechanism.
- 新しいユーザ要件を満たすメッセージングインフラストラクチャはExtensible Mechanism司令官のサポートで高められます。
- making E-mail more user friendly is brought about by a
messaging service that allows the use of the more natural
directory names in E-mail addresses.
- メールをよりユーザフレンドリーにするのはEメールアドレスにおける、より当然のディレクトリ名の使用を許すメッセージングサービスによって引き起こされます。
- increased effectiveness of messaging by the use of DLs is
brought about by X.400(1988)'s support of powerful nesting
capabilities and management for DLs.
- DLsの使用で通信する増加する有効性はDLsのためにX.400(1988)の強力な巣篭もり能力と管理のサポートで引き起こされます。
- an increase in global message delivery performance and
reliability is enhanced by the ability of X.400(1988) to use
X.500 for MTA routing.
- グローバルなメッセージ配送性能と信頼性の増加はX.400(1988)がMTAルーティングにX.500を使用する能力によって機能アップされます。
- more messages being successfully delivered to mobile or
transient users is enhanced by the provision of the Message
Store.
- 首尾よく可動の、または、一時的なユーザに渡すのがMessageストアの支給で高められるというより多くのメッセージ。
- multimedia use is enhanced by the ability to define new body
parts and to support multiple types of binary data such as
audio and video.
- マルチメディア使用は新しい身体の部分を定義して、複数のタイプのオーディオやビデオなどの2進のデータを支持する能力によって機能アップされます。
- establishing optimum and seamless conversion of messages
based upon the capabilities of a user is brought about by the
ability of X.400(1988) to act upon UA capabilities.
- ユーザの能力に基づくメッセージの最適でシームレスの変換を確立するのはX.400(1988)がUA能力に作用する能力によって引き起こされます。
*Costs*
*コスト*
The generic costs to establish an X.400(1988) pilot service can be broken down into:
X.400(1988)パイロットサービスを確立する一般的なコストは以下へ砕けている場合があります。
- a cost per backbone of RELAY MTAs (as used by the European
research community - the former Cosine MHS service),
- a cost per service provider,
- a cost per organisation,
- a cost per user and
- a cost per user MTA for migrating to X.400(1988).
- そして、RELAY MTAsの背骨あたり1つの費用に、(使用されるように、ヨーロッパ人は共同体について研究します--前のCosine MHSサービス)--aがサービスプロバイダー(1機構あたり1つの費用)単位で1ユーザあたり1つの費用かかった、--X.400(1988)にわたるためのユーザMTAあたり1つの費用。
RARE WG-MSG Task Force 88 [Page 30] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[30ページ]RFC1616X.400(88)
To bring about the benefits, mentioned above, certain costs will be incurred and they are summarised below:
前記のように利益を引き起こすために、あるコストは被られるでしょう、そして、以下にそれらについて略言します:
- Cost per backbone of RELAY MTAs (as used by the European
research community - the former Cosine MHS service)
- RELAY MTAsの背骨あたりの費用(ヨーロッパ人によって使用されるように、共同体について研究してください--前のCosine MHSサービス)
- The equipment costs of migrating backbone RELAY MTAs.
- 移動背骨RELAY MTAsの設備コスト。
- The establishment of some sort of organisational /
project group to oversee a backbone RELAY MTA pilot.
- ある種のorganisational/プロジェクトの設立は、背骨RELAY MTAパイロットを監督するために分類されます。
As most of the RELAY MTAs are already X.400(1988) capable, there
is already a MHS Co-ordination service in place that could be used
for this function and the number of backbone RELAY MTAs is less
than 100 in number the cost for migrating the RELAY MTA backbone
is considered relatively low.
RELAY MTAsの大部分が既にできるX.400(1988)であるので、この機能に利用できた適所にあるMHS Co-叙階式サービスが既にあります、そして、背骨RELAY MTAsの数は移動して、RELAY MTA背骨が比較的低いと考えられるので100未満が中で費用に付番するということです。
- Cost per service provider
- 1サービスプロバイダーあたりの費用
- If the RELAY MTA backbone (formerly Cosine MHS) is
migrated towards X.400(1988), then the remaining cost
for a service provider for migrating the infrastructure
towards X.400(1988) is relatively low.
- RELAY MTAであるなら、背骨(以前Cosine MHS)はそうです。移動して、X.400(1988)に向かったインフラストラクチャが比較的低いので、X.400(1988)、サービスプロバイダーのための当時の残っている費用に向かって移動しました。
- The operational costs for organisational issues, for
example dealing with OID registrations, is low if
national R&D service providers act as a clearinghouse
for their own national R&D institutions e.g.,
Universities.
- 国家の研究開発サービスプロバイダーがそれら自身の国家の研究開発団体のために情報センターとして例えば大学を機能させるなら、organisational問題のための運用コスト、例えば、OID登録証明書の取扱いは低いです。
- Cost per organisation, end user and MTA
- 1機構あたりの費用、エンドユーザ、およびMTA
- The operational costs of migrating end users and their
MTAs in management domains to X.400(1988) are higher
than the costs involved with migrating the
infrastructure. This is due to the order of at least 10
to 100 times more MTAs, as compared to the service
providers, that would be involved with a migration to
X.400(1988). As the infrastructure needs to migrate
first, the costs for the end user MTAs can be reduced
by profiting from the migration experience of the
service providers.
- 移動しているエンドユーザの運用コストとX.400(1988)への管理ドメインの彼らのMTAsはコストがインフラストラクチャに移動するのにかかわったより高いです。 サービスプロバイダーと比べて、これは少なくとも10〜100倍より多くのMTAsの注文のためであり、それはX.400(1988)への移動にかかわるでしょう。 インフラストラクチャが、最初に移動する必要があるのに従って、サービスプロバイダーの移動経験から利益を得ることによって、エンドユーザMTAsのためのコストを削減できます。
- The education and training costs for users and system
managers are significant, due to the amount of end
users and end user MTAs. Any marginal cost savings per
user which can be made, e.g., by deployment of automated
tools, should be considered due to the large overall
- ユーザとシステム・マネージャのための教育訓練コストはエンドユーザとエンドユーザMTAsの量のために重要です。 例えば、自動化されたツールの展開で作ることができるどんな1ユーザあたりの限界原価貯蓄も全体的に見て大きさのため考えられるべきです。
RARE WG-MSG Task Force 88 [Page 31] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[31ページ]RFC1616X.400(88)
savings that accrue.
生じる貯蓄。
- The costs of any potential disruption of the end user's
messaging service are high - due to the huge numbers of
end users involved - and as such only a very well
managed, phased and planned migration should be
considered.
- エンドユーザのメッセージングサービスのどんな潜在的分裂のコストもかかわるエンドユーザの巨大な数のために高いです--そして考えられて、非常によく管理されて、段階的で計画された移動だけがそうするべきであるそのようなものとして。
- Software costs
- ソフトウェアコスト
- The costs for software development are outside the
scope of this report. However it is clear that cost
needs to be incurred in order to provide software that
is easy to install and use. As a result of the work of
the task force a list of possibly needed components and
likely changes to existing components can be proposed,
- このレポートの範囲の外にソフトウェア開発のためのコストがあります。 しかしながら、費用が、インストールしやすくて、使用しやすいソフトウェアを提供するために被られる必要があるのは、明確です。 特別委員会の仕事の結果、ことによると必要なコンポーネントと既存のコンポーネントへのありそうな変化のリストを提案できます。
Modifications, but not new developments, to
software for:
新しい開発ではなく、以下のためのソフトウェアへの変更
- X.400(1988) MTAs, X.400(1988) UAs, DSAs,
DUAs and MSs.
- X.400(1988)MTAs、X.400(1988)UAs、DSAs、DUAs、およびMSs。
New software developments for:
以下のための新しいソフトウェア開発
- MIME to MHS Gateways, X.400(1988) network
management, mailbox conversion, PC LAN
directory synchronisation, PC LAN gateways
and UA capability registration.
- MHS GatewaysへのMIME、X.400(1988)ネットワークマネージメント、メールボックス変換、PC LANディレクトリ連動、PC LANゲートウェイ、およびUA能力登録。
- The distribution costs for any new software (for the
European R&D community) are low if usual academic
distribution methods - FTP servers, E-mail Based
servers, Gopher, World Wide Web and Archie - are used.
- 普通のアカデミックな分配方法(FTPサーバ、メールBasedサーバ、ゴーファー、WWW、およびアーチー)が使用されているなら、どんな新しいソフトウェア(ヨーロッパの研究開発共同体への)のための分配コストも低いです。
*Summary*
*概要*
Migration towards a X.400(1988) service needs to evolve from the inside (the messaging backbone) outward (to the end user MTAs and end users themselves). Due to the numbers involved both the costs and the benefits associated with the migration increase as the migration evolves towards the end users.
X.400(1988)サービスに向かった移動は、外側(エンドユーザMTAsとエンドユーザ自身に)で内部から(メッセージング背骨)を発展する必要があります。 移動がエンドユーザに向かって発展するので、数への支払われるべきものはコストと利益の移動増加に関連している両方にかかわりました。
The benefits of migrating to a X.400(1988) service are a feature rich well defined open standard with high functionality , scalability, use of directory, multimedia and secure messaging capability. The costs for migrating a RELAY MTA backbone can be considered relatively low whilst the migration of end user MTAs and the migration of the end
X.400(1988)サービスにわたる利益は高い機能性がある豊かなよく定義されたオープンスタンダード、スケーラビリティが使用するディレクトリ、マルチメディア、および安全なメッセージング能力の特徴です。 エンドユーザMTAsの移動と終わりの移動である間、比較的低いと移動しているa RELAY MTA背骨のためのコストを考えることができます。
RARE WG-MSG Task Force 88 [Page 32] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[32ページ]RFC1616X.400(88)
users themselves are relatively high. These costs should of course be balanced against the cost of a disrupted service that one might get if no migration occurs at all and the current service (e.g., X.400(1984)) reaches the limits of its scalability and/or functionality.
ユーザ自身は比較的高いです。 移動が全く起こらないで、当期の勤務(例えば、X.400(1984))がスケーラビリティ、そして/または、機能性の限界に達するなら、これらのコストはもちろん1つが得るかもしれない混乱させたサービスの費用に対してバランスをとるべきです。
It is important to realise that if end users themselves do not experience direct feedback of the benefits from X.400(1988), this may make the organisational motivation needed to effect such a migration difficult to achieve. In effect, the establishment of a pilot X.400(1988) service is and should be driven by the requirements of end users and thus achieving end user benefits - as listed above - must be given a higher priority within a X.400(1988) service than solely the extra service provider benefits.
これがエンドユーザ自身がX.400(1988)から利益のダイレクトフィードバックを経験しないなら、organisationalを達成するのが難しいそのような移動に作用するのに必要である動機にするかもしれないとわかるのは重要です。 事実上、パイロットX.400(1988)サービスの設立は、あって、エンドユーザの要件によって動かされるべきです、そして、その結果、上に記載されているようにエンドユーザ利益を達成するのはX.400(1988)サービスの中で優先しなければなりません追加サービスプロバイダーが唯一利益を得るより高い。
8. Main Recommendations
8. 主な推薦
The RARE WG-MSG Task Force on 'The Establishment of an X.400(1988)
Pan European Pilot Messaging Service' has identified a number of high
level recommendations for establishing such a
service. The main high level recommendations are listed within this
chapter. A more detailed elaboration of these main recommendations is
given in Appendix A. Appendix A is provided for policy makers wishing
more background on the main recommendations. As well, a list of very
detailed guidelines, plus some issues requiring further
investigation, is given in Appendix B. Appendix B will be especially
useful for personnel seeking detailed technical guidelines which are
consistent with the main high level recommendations.
'X.400(1988)のなべのヨーロッパのPilotメッセージサービスの特権階級'のRARE WG-MSG Task Forceはそのようなサービスを確立するための多くの高い平らな推薦を特定しました。 主な高い平らな推薦は本章の中に記載されています。 Appendix A.でこれらの主な推薦の、より詳細な労作を与えます。主な推薦により多くのバックグラウンドを押しつけている政策立案者にAppendix Aを提供します。 Appendixで井戸(非常に詳細なガイドラインのリスト、およびさらなる調査を必要とするいくつかの問題)を与えるとき、B.Appendix Bは特に主な高い平らな推薦と一致した技術的な詳細なガイドラインを求めている人員の役に立ちます。
*Recommendations*
*推薦*
- Establish a X.400(1988) pilot service encompassing European
Commercial, Government and Academic bodies. Such a pilot
service to be co-ordinated by using an industry forum where
all parties could meet. The use of an existing forum, where
user organisations are well represented, is desirable if
commercial end users organisation's requirements are to be
met. The forum should also be open to non-European
participants.
- ヨーロッパのCommercial、政府、およびAcademicボディーを取り囲むX.400(1988)パイロットサービスを確立してください。 そのようなすべてがパーティーへ行く産業フォーラムを使用することによって調整されるべきパイロットサービスは満たされることができました。 既存のフォーラムの使用は商業エンドユーザ機構の要件が会われることであるならユーザ機構がよく代表されるところで望ましいです。 また、非ヨーロッパ人の関係者にとって、フォーラムも開いているべきです。
- X.400(1988) end user services should be provided as well as
a X.400(1988) backbone RELAY MTA service within a X.400(1988)
pilot service. The end user services should be given a high
priority.
- X.400(1988)パイロットサービスの中のX.400(1988)背骨RELAY MTAサービスと同様にX.400(1988)エンドユーザサービスを提供するべきです。 エンドユーザサービスは優先するべきです高い。
- Help an already emerging market place in X.400(1988)
products to prosper by ensuring that a suitable supply of
high quality X.400(1988) public domain software is available.
- 高品質のX.400(1988)パブリックドメインソフトの適当な供給は既に確実にすることによって繁栄する新興成長市場の地域コネX.400(1988)製品ですが、助けてください。利用可能。
RARE WG-MSG Task Force 88 [Page 33] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[33ページ]RFC1616X.400(88)
The Internet has proven, that public domain software, free of
any commercial restrictions, is further rapidly developed, by
Small and Medium Size Enterprises (SMEs), into derivative
products suitable for the commercial market.
インターネットは、少しの商業制限も持っていないそのパブリックドメインソフトがさらに急速に開発されると立証しました、SmallとMedium Sizeエンタープライズ(SMEs)で、商業市場に適当な派生商品に。
- Any pilot service should be well co-ordinated and result
driven but utilise a distributed market oriented approach. It
is considered very difficult to organise and plan such a
pilot under the assumption of a single centrally funded body
i.e., driven from the 'top'. A more 'market driven' or
distributed organisation is considered feasible, and likely
to succeed, if all the market 'players' are fully involved
i.e., a 'bottom' up approach.
- どんなパイロットサービスもよく調整されるべきでした、そして、分配された市場を利用するのを除いて、追い立てられた結果はアプローチを適応させました。 それはすなわち、'先端'からの駆動の単一の中心へ資金を供給されたボディーの仮定でそのようなパイロットを構成していて、計画しているのが非常に難しいと考えられます。 '市場駆動'の、または、分配された機構は可能であって、成功しそうであると考えられます、すべての市場'プレーヤー'がすなわち、アプローチに'底a'で完全にかかわるなら。
- For the academic community - and ever more for the
commercial community - there is a business need to ensure near
total and 'perfect' integration with the existing and also
evolving RFC 822 based services.
- 学界(かつて商業共同体への以上)には、既存の、そして、また、発展しているRFCとの近い総、そして、'完全な'統合に822のベースのサービスを確実にするビジネス必要があります。
- For the academic community a rapid migration of the existing
X.400(1984) backbone RELAY MTAs, used within the European R&D
X.400(1984) service, - formerly the COSINE MHS service - is
considered urgent. This migration will provide a 'bootstrap'
path for academic organisations to internationally pilot
X.400(1988) services. Such end user piloting is not
considered feasible if X.400(1984) backbone RELAY MTAs are
used for an X.400(1988) service (see Reference [17] for
technical details).
- 学界において、ヨーロッパのR&D X.400(1984)サービスの中で使用された既存のX.400(1984)背骨RELAY MTAsの急速な移動(以前COSINE MHSサービス)は緊急であると考えられます。 学術機関がX.400(1988)サービスを国際的に操縦するように、この移動は'独力で進んでください'という経路を提供するでしょう。 X.400(1984)背骨RELAY MTAsがX.400(1988)サービスに使用されるなら(技術的詳細に関してReference[17]を見てください)、そのようなエンドユーザ操縦は可能であると考えられません。
The report does not include any recommendations on development and deployment of RFC 822 / MIME / PEM related (pilot) services, as these are outside of the scope of the Task Force. However, since both X.400(1988) and RFC 822 / MIME / PEM will be developed and used within the European R&D community, such a pilot should also be considered.
レポートは開発のときに少しの推薦も含んでいません、そして、RFC822/MIME/PEMの展開は(パイロット)サービスを関係づけました、これらがTask Forceの範囲の外にあるとき。 しかしながら、X.400(1988)とRFC822/MIME/PEMの両方がヨーロッパの研究開発共同体の中で開発されて、使用されるので、また、そのようなパイロットは考えられるべきです。
9. Security Considerations
9. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
RARE WG-MSG Task Force 88 [Page 34] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[34ページ]RFC1616X.400(88)
10. Reading List and Bibliography
10. 推薦図書と図書目録
This section contains a list of relevant reference documents that can be used for further reading.
このセクションはさらに読書するのに使用できる関連参考書類のリストを含みます。
[1] Kille;, S., "Mapping between X.400(1988) / ISO 10021
and RFC 822", RFC 1327/RTR 2, University College
London, May 1992.
[1]Kille;、S.、「X.400(1988)/ISO10021とRFC822インチ、RFC1327/RTR2、ユニバーシティ・カレッジロンドンの間で5月1992日を写像すること。
[2] Kille, S., "X.400 1988 to 1984 downgrading",
RFC 1328/RTR 3, University College London, May 1992.
[2]Kille、S.、「X.400 1988年から1984格下げ」、RFC1328/RTR3、ユニバーシティ・カレッジロンドン1992年5月。
[3] Adie, C., "A Survey on Multimedia Projects, Products
and Standards", RTR 5, Edinburgh University Computing
Centre, January 1993.
[3] エーディ、C.、「マルチメディアプロジェクト、製品、および規格における調査」、RTR5、エディンバラの大学計算センター、1993年1月。
[4] Alvestrand, H., and S. Thompson, "Equivalences between
1988 X.400 and RFC 822 Message Bodies", RFC 1494,
SINTEF DELAB, Soft*Switch Inc., August 1993.
[4] Alvestrand、H.、およびS.トンプソン、「1988X.400とメッセージが具体化させるRFC822の間の等価性」、RFC1494、SINTEF DELAB、柔らかい*が株式会社(1993年8月)を切り換えます。
[5] Alvestrand, H., Kille, S., Miles, R., Rose, M.,
and S. Thompson, "Mapping between X.400 and RFC 822
Message Bodies", RFC 1495, SINTEF DELAB, ISODE
Consortium, Soft*Switch, Inc., Dover Beach
Consulting, Inc., Soft*Switch, Inc., August 1993.
[5] Alvestrand、H.、Kille、S.、マイル、R.、ローズ、M.、およびS.トンプソン、「X.400とメッセージが具体化させるRFC822の間のマッピング」、RFC1495、SINTEF DELAB、ISODE共同体、柔らかい*はInc.を切り換えます、ドーヴァービーチコンサルティングInc.、柔らかい*スイッチInc.、1993年8月。
[6] Alvestrand, H., Romaguera, J., and K. Jordan,
"Rules for downgrading messages from X.400/88 to
X.400/84 when MIME content-types are present in the
messages", RFC 1496, SINTEF DELAB, NetConsult AG,
Control Data Systems, Inc., August 1993.
[6] Alvestrand(H.、Romaguera、J.、およびK.ジョーダン)は「MIMEの満足しているタイプがメッセージに出席しているときX.400/88からX.400/84までメッセージを格下げするために統治します」、RFC1496、SINTEF DELAB、NetConsult株式会社、ControlデータシステムズInc.、1993年8月。
[7] IETF MHS-DS Working Group, Works in Progress.
[7] IETF MHS-DS作業部会、執筆中の作品。
[8] Borenstein, N., and N. Freed, "MIME (Multipurpose
Internet Mail Extensions) Part One: Mechanisms for
Specifying and Describing the Format of Internet
Message Bodies", RFC 1521, Bellcore, Innosoft,
September 1993.
[8] Borenstein、N.、およびN.フリード、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。
[9] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Two: Message Header Extensions for
Non-ASCII Text", RFC 1522, University of Tennessee,
September 1993.
[9] ムーア、K.、「パートTwoをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC1522、テネシー大学、1993年9月。
RARE WG-MSG Task Force 88 [Page 35] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[35ページ]RFC1616X.400(88)
[10] Kaliski, B., "Privacy Enhancement for Internet
Electronic Mail: Part IV: Key Certification and
Related Services", RFC 1424, RSA Laboratories,
February 1993.
[10]Kaliski、B.、「インターネット電子メールのためのプライバシー増進:」 パートIV: 「主要な証明の、そして、関連のサービス」、RFC1424、RSA研究所、1993年2月。
[11] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and
Identifiers", RFC 1423, TIS, February 1993.
[11]Balenson、D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、TIS、2月1993日
[12] Kent, S., "Privacy Enhancement for Internet
Electronic Mail: Part II: Certificate Based Key
Management", RFC 1422, BBN, February 1993.
[12] ケント、S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書のベースのKey Management」、RFC1422、BBN、1993年2月。
[13] Linn, J., "Privacy Enhancement for Internet
Electronic Mail: Part I: Message Encryption and
Authentication Procedures", RFC 1421, IAB IRTF PSRG,
IETF PEM WG, February 1993.
[13] リン、J.、「インターネット電子メールのためのプライバシー増進:」 部分I: 「メッセージ暗号化と認証手順」、RFC1421、IAB IRTF PSRG、IETF PEM WG、2月1993日
[14] Jurg, P., and E. Huizer, "The SURFnet electronic mail
project", SURFnet, EH/PJ932307, July 1993.
[14] ジュルグ、P.とE.Huizer、「SURFnet電子メールプロジェクト」SURFnet、EH/PJ932307、1993年7月。
[15] Alvestrand, H., "X.400 Use of Extended Character
Sets", RFC 1502/RTR 7, SINTEF DELAB, August 1993.
[15]Alvestrand、H.、「拡張文字集合のX.400使用」、RFC1502/RTR7、SINTEF DELAB、1993年8月。
[16] Manros, C.-U., "The X.400 Blue Book Companion", ISBN
1 871802 00 8, Technology Appraisals Ltd, 1989.
[16]Manros、C.U.、「X.400紳士録仲間」、ISBN、1、871802 00、8、技術評価Ltd、1989
[17] Houttuin, J., and J. Craigie, "Migrating from
X.400(1984) to X.400(1988)", RFC 1615/RTR 9,
RARE, JNT, May 1994.
まれな[17]Houttuin、J.、およびJ.クレーギー、「X.400(1984)からX.400(1988)まで移動する」RFC1615/RTR9、JNT、5月1994日
[18] Nagelhus, I. et al., "Survey of E-mail systems with
X.400 capability".
[18]Nagelhus、I.他、「X.400能力があるメールシステムの調査。」
[19] "A White Paper on X.400(1988)", EMA Report.
[19] 「X.400(1988)に関する白書」と、EMAは報告します。
[20] IAB, IESG, "The Internet Standards Process --
Revision 2", RFC 1602, March 1994.
[20] IAB、IESG、「インターネット規格は処理されます--改正2インチ、RFC1602、1994年3月。」
RARE WG-MSG Task Force 88 [Page 36] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[36ページ]RFC1616X.400(88)
11. Terminology
11. 用語
ADMD Administration Management Domain
ASCII American Standard Code for Information Exchange
ASN.1 Abstract Syntax Notation One
AU Access Unit
CCITT Comite Consultatif International de Telegraphique et
Telephonique
CEN Comite Europeen de Normalisation
CENELEC Comite Europeen de Normalisation Electrotechnique
CEPT Conference Europeene des Postes et Telecommunications
CONS Connection Oriented Network Service
COSINE Co-operation for OSI networking in Europe
DL Distribution List
DIS Draft International Standard
EMA Electronic Messaging Association
EN European Norm
ENV Draft EN, European functional standard
IEC International Electrotechnical Commission
IETF Internet Engineering Task Force [20]
IPM Inter-Personal Message
IPMS Inter-Personal Messaging Service
IPN Inter-Personal Notification
ISO International Organisation for Standardisation
JNT Joint Network Team (UK)
JTC Joint Technical Committee (ISO/IEC)
MD Management Domain (either an ADMD or a PRMD)
MHS Message Handling System
MHS-DS Message Handling Systems use of Directory Service
Working Group from the IETF
MIME Multi-purpose Internet Mail Extensions (extensions to
RFC 822) [6]
MOTIS Message-Oriented Text Interchange Systems
MTA Message Transfer Agent
MTL Message Transfer Layer
MTS Message Transfer System
NBS National Bureau of Standardization
OSI Open Systems Interconnection
PEM Privacy Enhanced Mail [10]
PRMD Private Management Domain
RARE Reseaux Associes pour la Recherche Europeenne
RFC Request For Comments (series of Internet publications)
RFC 822 RFC describing Internet Message format for Electronic
mail
RTR RARE Technical Report (series of RARE publications)
RTS Reliable Transfer Service
WG-MSG RARE Working Group on Mail and Messaging
ADMD政権管理ドメインASCIIアメリカン・スタンダードは情報交換のためにASNをコード化します; 1 ヨーロッパDL Distribution List DIS国際規格案でEMA Electronic Messaging Association ENのヨーロッパのNorm ENV Draft ENをネットワークでつなぐOSIのための抽象的な国際Syntax Notation One AU Access Unitのヨーロッパ標準化機構Electrotechnique CEPTコンファレンスEuropeene des Postes et TelecommunicationsコンズCCITT Comite Consultatif de Telegraphique et Telephonique CENヨーロッパ標準化機構CENELEC Connection Oriented Network Service COSINE Co-事業; Standardisation JNT Joint Network Team(イギリス)JTC Joint Technical Committee(ISO/IEC)MD Management Domain(ADMDかPRMDのどちらか)MHS Message Handling System MHS-DS Message Handling Systems uのためのIPM Inter個人的なヨーロッパの機能的な標準のIEC国際電気標準化会議IETFインターネット・エンジニアリング・タスク・フォース20のMessage IPMS Inter個人的なメッセージサービスIPN Inter個人的なNotification ISO国際OrganisationStandardization OSIオープン・システム・インターコネクションPEM Privacy EnhancedメールのIETF MIME Multi-目的インターネットメールExtensions(RFC822への拡大)の6のMOTIS Messageが指向のText Interchange Systems MTA Message TransferエージェントMTL Message Transfer Layer MTS Message Transfer System NBS National事務局からのディレクトリサービス作業部会のse; 10 PRMD兵士のManagement Domain RARE Reseaux AssociesはElectronicメールRTR RARE Technical Report(RARE刊行物のシリーズ)RTS Reliable Transfer Service WG-MSG RARE作業部会のためにメールでインターネットMessage形式について説明するla Recherche Europeenne RFC Request For Comments(インターネット刊行物のシリーズ)RFC822RFCとMessagingを注ぎます。
RARE WG-MSG Task Force 88 [Page 37] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[37ページ]RFC1616X.400(88)
Appendix A - Elaboration on the main recommendations
付録A--主な推薦での労作
The main recommendations of the report are elaborated upon in more detail within this appendix.
レポートの主な推薦のときに、さらに詳細にこの付録の中に詳しく説明されます。
- In order to provide a globally pervasive messaging service,
it is recommended to establish a well operated Pan-European
X.400(1988) pilot backbone comprising MTAs and MSs,
connecting partners within Industry, Commercial Service
Providers, Academia and Public Bodies (CEC, National
Governments, etc.). The pilot should be open to global
participation.
- グローバルに普及しているメッセージングサービスを提供するために、MTAsとMSsを包括する上手に操作されたPanヨーロッパのX.400(1988)パイロット背骨を確立するのはお勧めです、Industry、Commercial Service Providers、Academia、およびPublic Bodies(CEC、National政府など)の中でパートナーに接して。 パイロットはグローバルな参加にオープンであるべきです。
- In order to maintain the widest connectivity with the
highest possible functionality, gateways should be installed
that gateway between X.400(1988) and RFC 822/MIME. These
gateways should follow the specifications of RFC 1327 [1] and
RFC 1494 et al. [4]. Experience with these gateways should be
fed back into the appropriate RARE and IETF Working Groups to
improve the standards.
- 可能な限り高い機能性、ゲートウェイがある最も広い接続性がそうするべきであると主張するためにインストールされてください。X.400(1988)とRFC822/MIMEの間のそのゲートウェイ。 これらのゲートウェイはRFC1327[1]とRFC1494他の仕様に従うはずです。 [4]. これらのゲートウェイの経験は、規格を改良するために適切なRAREとIETF Working Groupsにフィードバックされるべきです。
- In order that the 'business needs' of non-R&D organisations
can be inserted at an early stage into the goals of the pilot
and ensuring that the success of the pilot in meeting these
goals can be measured and disseminated i.e., to encourage the
active participation of non-R&D organisations within the
pilot, it is recommended that an open forum comprising
industry, service providers, public bodies and academia
should be used. Preferably an existing forum where end users
are heavily involved is desirable.
- 非研究開発機構の'ビジネスの必要性'がパイロットの中で非研究開発機構の積極的な参加を奨励するために初期のときにパイロットの目標に挿入されて、これらの目標を達成することにおけるパイロットの成功を測定して、すなわち、広めることができるのを確実にすることができるように、産業、サービスプロバイダー、公共団体、およびアカデミーを包括するオープン・フォーラムが使用されるのは、お勧めです。 望ましくは、エンドユーザが大いにかかわる既存のフォーラムは望ましいです。
- In order for meaningful co-operation between bodies affected
by the pilot to occur and thus hopefully reducing unnecessary
duplications, it is recommended that there are close liaisons
and contacts between at least the IETF, RARE, EARN, EUnet,
RIPE, Y-NET, EEMA, EMA, EWOS, OIW, CEN/CENELEC, ISO, CCITT,
CEC and European governmental bodies and those involved
within the pilot. The suggested mechanism for a meaningful
liaison is that enough participants of the above
organisations attend the common forum mentioned above. It is
also suggested that as much as possible e-mail distribution
lists be used to communicate between forum participants.
- パイロットで起こるように影響を受けて、その結果希望をいだいて不要な複製を抑えるボディーの間の重要な協力において整然とします、パイロットの中に少なくともIETFと、RAREと、EARNと、EUnetと、RIPEと、Y-ネットと、EEMAと、EMAと、EWOSと、OIWと、CEN/CENELECと、ISOと、CCITTと、CECと、ヨーロッパの政府のボディーと関係者との緊密な連携と接触があるのは、お勧めです。 重要な連絡係のための提案されたメカニズムは上の機構の十分な関係者が前記のように一般的なフォーラムに出席するということです。 それはそうです、また、そんなにできるだけ示されて、発送先リストをメールしてください。フォーラム関係者の間で交信するために、使用されます。
- In order that the pilot have measurable results, it is
recommended that the pilot shall be implemented in phases. It
is considered that at least two phases are needed:
- パイロットには測定できる結果があるように、パイロットがフェーズで実行されるものとするのは、お勧めです。 少なくとも二相が必要であると考えられます:
RARE WG-MSG Task Force 88 [Page 38] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[38ページ]RFC1616X.400(88)
- phase 1 - initial short start up phase with a small
number of participants. The result of this phase is
that any needed procedures, co-ordination mechanisms,
etc. are put into place for the large scale piloting of
phase 2.
- フェーズ1--少ない数の関係者との短い始動フェーズに頭文字をつけてください。 このフェーズの結果はフェーズ2の大規模操縦のためにどんな必要な手順、コーディネーションメカニズムなども場所に入れるということです。
- phase 2 - phase with a wide Pan-European participation.
The result of this phase should be a proof of scaling
of the pilot X.400(1988) service i.e., the goals of the
pilot as defined in Chapter 1 are met. It is expected
that upon successful completion of this phase a natural
evolution to a global deployment of a X.400(1988)
service will have started.
- 広いPanヨーロッパの参加で2--フェーズの位相を合わせてください。 このフェーズの結果はパイロットX.400(1988)サービスのスケーリングの証拠であるべきです、すなわち、第1章の定義されるとしてのパイロットの目標が達成されます。 このフェーズの無事終了に、グローバルなX.400(1988)サービスの展開への自然な発展が出かけてしまうだろうと予想されます。
- In order to rapidly complete phase 1 of the pilot and that
the pilot is at least Pan-European in scope, it is
recommended that; a number of R&D service providers, one each
from several European countries; at least 2 North American
R&D service providers; at least 1 Japanese R&D service
provider and a small number of commercial service providers
and commercial organisations are actively involved in phase
1.
- パイロットが急速にパイロットとそのフェーズ1を完成するために範囲で少なくともPanヨーロッパ人である、それはそれに推薦されます。 いくつかの欧州諸国からの多くの研究開発サービスプロバイダー、それぞれ1。 少なくとも2つの北米の研究開発サービスプロバイダー。 少なくとも1つの日本の研究開発サービスプロバイダーと少ない数の商業サービスプロバイダーと営利団体が活発にフェーズ1にかかわります。
- In order to stimulate the creation of an economically viable
market place for X.400(1988) products (i.e., MTAs, UAs, etc.)
(i.e., users are willing to purchase such products), it is
recommended that a suitable minimum number of new software
implementations and or modifications to existing software
implementations be funded. The resulting software to be
inserted into the Public Domain free of any financial
restrictions on further commercial exploitation. By using
this mechanism, Small and Medium Size Enterprises (SMEs) will
be encouraged to commercially exploit such products.
- 経済的に実行可能な市場の創設を刺激して、X.400(1988)製品(すなわち、MTAs、UAsなど)のために入賞してください。 (すなわち、ユーザは、そのような製品を購入しても構わないと思っています), そして、そのa適当な最小の番号の新しいソフトウェア実行がそれに推薦される、変更、既存のソフトウェア実行に、資金を供給してください。 さらなる商売人の搾取のときに少しの財政的な制限を有でないPublic Domainにも挿入されるべき結果として起こるソフトウェア。 このメカニズムを使用することによって、SmallとMedium Sizeエンタープライズ(SMEs)が商業的にそのような製品を開発するよう奨励されるでしょう。
- Due to the strong influence of the R&D community within the
pilot plus the desire to produce standardised products
quickly and pragmatically, it is recommended that any
standards proposed within the scope of an X.400(1988) pilot
(for example standards re: character sets and body parts
gatewayed to and from X.400(1988) and RFC 822 / MIME) are
conformant to and candidates for Internet standardisation. As
a concrete example of the standardisation process, this means
that at least two independent software implementations, for
each product category, (of which one product preferably in
the Public Domain) must be proven as interworking to a
proposed standard before the proposed standard can be
elevated to draft standard [20].
- パイロットの中の研究開発共同体の強い影響力と標準化された製品をすぐに、そして実践的に生産する願望のために、X.400(1988)のパイロット(RFCとX.400(1988)とRFC822/MIMEからgatewayedされた例えば、規格re:文字の組と身体の部分)の範囲の中で提案されたどんな規格もインターネット規格化のconformantと候補であることはお勧めです。 規格化の過程に関する具体的な実例として、これは、各製品カテゴリーのために提案された標準の前の提案された標準への織り込むことを草稿規格[20]に登用できるように少なくとも2つの独立しているソフトウェア実行を立証しなければならないことを(望ましくはPublic Domainのどの1個の製品について)意味します。
RARE WG-MSG Task Force 88 [Page 39] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[39ページ]RFC1616X.400(88)
- To ensure that there is a market driven demand for
X.400(1988) products within the commercial market place, it
is recommended that the maximum number of Public Domain
implementations that are funded, by any one public funding
organisation, is two. It is desirable that at least one other
product, preferably commercially based and not within the
Public Domain, is produced.
- 商業市場の中にX.400(1988)製品の市場の駆動需要があるのを保証するために、どんな公的資金機構によっても資金を供給されるPublic Domain実現の最大数が2であることはお勧めです。 他の少なくとも1個の製品が望ましくは商業的に基づいていてPublic Domainの中ではなく生産されないのは、望ましいです。
- In order that any necessary information required for the
effective operation of the X.400(1988) pilot, including not
least OID assignments, mapping rules, information about
interconnection partners, naming authority information be
made widely available, it is recommended that an
electronically accessible information base be established.
- どんな必要事項もX.400(1988)のパイロットの有効な操作に必要であるように、広く権威を情報と命名するインタコネクトパートナーに関して特にOID課題、配置規則、情報を含んでいるのを利用可能にして、電子的にアクセスしやすい情報ベースが確立されるのは、お勧めです。
- In order that any necessary organisational issues needed for
a deployment of an X.400(1988) service have a body in place
to deal with this issue, it is recommended that the pilot
either identify and list which bodies are responsible for
which issues or else actively ensure that a suitable body is
being put in place.
- X.400(1988)サービスの展開に必要であるorganisational問題がこの問題に対処するために適所にボディーを持って、パイロットがどのボディーを特定して、記載するかが、お勧めであることが必要ないずれもどの問題に責任があるかには、または、適当なボディーが適所に置かれているのを活発に確実にしてください。
Appendix B - A number of detailed guidelines.
付録B--多くの詳細なガイドライン。
The Task Force has the following detailed guidelines:
Task Forceには、以下の詳細なガイドラインがあります:
*Product and operational service guidelines*
*製品と操作上のサービスガイドライン*
- To ensure that there is no degradation of X.400(1988)
service between X.400(1988) originators and destinations, the
topology of the MTS must be such that no X.400(1984) MTA acts
as a relay between any two X.400(1988) users.
- そこでそれを確実にするのは、(1988)X.400創始者の間のX.400(1988)サービスの退行ではありません、そして、目的地、MTSのトポロジーがそのようなものであるに違いないので、どんなX.400(1984)MTAもどんな2X.400(1988)ユーザの間のリレーとして機能しません。
- As the existing R&D X.400(1984) service (formerly COSINE
MHS) now comprises a large number of X.400(1988) capable
RELAYs, it would be relatively straight forward that the
existing COSINE MHS RELAYs be one of the first communities
that are migrated to X.400(1988) capabilities. This would
ensure that X.400(1988) MTAs using the RELAY backbone
experience no loss of service.
- 既存のR&D X.400(1984)サービス(以前COSINE MHS)が現在多くのX.400(1988)のできるRELAYsを包括するので、既存のCOSINE MHS RELAYsによる最初の共同体の1つがX.400(1988)能力にわたったということであることは前方で比較的まっすぐでしょう。 これは、RELAY背骨を使用するX.400(1988)MTAsがサービスの損失を全く経験しないのを確実にするでしょう。
- To be able to operate an X.400(1988) service a properly
operated X.400(1988) infrastructure should be established,
consisting of X.400(1988) MTAs, X.400(1988) MTAs with
downgrading capabilities according to RTR 3, Message Store
services and gateways to RFC 822 based upon RTR 2 and
extended gatewaying functionality for multimedia mail.
- X.400(1988)サービスを操作できるように、適切に操作されたX.400(1988)インフラストラクチャは確立されるべきです、X.400(1988)MTAs(RTR3、Messageストアサービス、およびマルチメディアメールのためにRTR2に基づいていて、機能性をgatewayingしながら広げられたRFC822へのゲートウェイに従って能力を格下げするX.400(1988)MTAs)から成って
RARE WG-MSG Task Force 88 [Page 40] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[40ページ]RFC1616X.400(88)
- To ensure maximum use of the OSI supporting layers plus
support of normal mode RTS, it is recommended that a
migration to ISO 10021 is effected i.e., straight to use of
the full OSI stack with normal mode RTS.
- 層を支えるOSIの最大の使用と正規モードRTSのサポートを確実にするために、ISO10021への移動がすなわち、まっすぐ正規モードRTSとの完全なOSIスタックの使用に作用するのは、お勧めです。
- To ensure maximum quality of service as impacted by
implementation decisions related to the 'General Extension
Mechanism', it is recommended that no minimal X.400(1988)
MTAs, which relay the syntax but understand none of the
semantics of extensions, should be used.
- 最小量のX.400(1988)のそのノーMTAsは影響を与えられるとしての'Extension Mechanism司令官'に関連する実現決定による最大のサービスの質を確実にするのが使用されているべきであることがそれに勧められます。(構文をリレーしますが、MTAsは拡大の意味論のいずれも理解していません)。
- It is recommended that all X.400(1988) MTAs should generate
reports containing extensions copied from the subject message
and route reports through the DL expansion hierarchy where
appropriate.
- すべてのX.400(1988)MTAsが適切であるところに対象のメッセージとルートレポートからDL拡大階層構造までコピーされた拡大を含むレポートを作るはずであるのは、お勧めです。
- It is recommended that all X.400(1984) UAs are able to
generate and display DDAs. This will allow such systems to
address X.400(1988) Common Name Attribute users.
- すべてのX.400(1984)UAsがDDAsを発生して、表示できるのは、お勧めです。 これで、そのようなシステムはX.400(1988)俗称Attributeユーザに演説できるでしょう。
- To enhance connectivity to both X.400(1984 and 1988)
management domains without degradation of X.400(1988)
service, management domain entry points that support both
X.400(1984 and 1988) are recommended.
- X.400(1988)サービス、両方を支持する管理ドメインエントリー・ポイントの退行なしで両方のX.400(1984と1988)管理ドメインに接続性を高めるために、X.400(1984と1988)はお勧めです。
- To ensure total connectivity between RFC 822 domains
migrating to X.400(1988), it is recommended that a local
X.400-to-RFC-822 gateway is made operational or a reliable
service agreement for the external provision of such a
gateway is effected before any migration begins.
- X.400(1988)にわたりながらRFC822ドメインの間で総接続性を確実にするために、X.400からRFC-822への地方のゲートウェイを操作上にするのがお勧めである、またはどんな移動も始まる前にそのようなゲートウェイの外部の設備のための信頼できるサービス契約は作用しています。
*Migration utilities needed*
*移動ユーティリティは*を必要としました。
- It is considered very helpful if conversion utilities that
allow a flawless conversion of an RFC 822 user's existing
mail folders to a X.400(1988) product's folder system be
implemented. However further investigation is needed before
recommending that such tools be made a mandatory part of any
funded software development.
- それはX.400(1988)へのRFC822ユーザの存在メール・フォルダの疵のない変換に製品のフォルダーシステムを許容する変換ユーティリティであるなら非常に役立っていると考えられます。実行されます。 さらなる調査がそのようなツールが作られることを勧める前にどのように必要であっても、いずれの義務的な部分はソフトウェア開発に資金を供給しました。
- It is recommended that the ease of configuration of
X.400(1988) products is made as automatic as possible.
Consideration should be given to a) modern user interfaces b)
automatic processing of 'old RFC 822' configuration files
into the 'new X.400(1988)' configuration files i.e., a reuse
of the user's previous options and configurations should be
the result. If a 'simple' configuration interface is needed
it should be as compatible as possible with the present RFC
- X.400(1988)製品の構成の容易さをできるだけ自動にするのはお勧めです。 考慮はa)に考えて、現代のユーザが'古いRFC822'構成ファイルのb)自動処理を'新しいX.400(1988)'構成ファイルに連結して、すなわち、ユーザの前のオプションと構成の再利用が結果であるべきであるという、ことであるべきです。 '簡単な'構成インタフェースが必要であるなら、できるだけ現在のRFCと互換性があるべきです。
RARE WG-MSG Task Force 88 [Page 41] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[41ページ]RFC1616X.400(88)
822 mailer's i.e., this concretely means editing of ASCII
files.
すなわち、これが編集することを具体的に意味する822郵送者のASCIIファイルのもの。
*Issues for further study*
*さらなる研究*への問題
The pilot X.400(1988) messaging service must ensure that the issues listed below are either being investigated by an appropriate body or if not initiate actions to properly address them. The issues have been grouped under Products, Organisational and Deployment.
パイロットX.400(1988)メッセージングサービスは、適切にそれらを扱うために以下に記載された問題が適切なボディーによって調査されるか、まして、開始動作のどちらかであることを確実にしなければなりません。 問題はProducts、Organisational、およびDeploymentの下で分類されました。
- Products
- 製品
- Any X.500 DSAs, DUAs, APIs e.g., LDAP, etc. changes
needed to support X.400(1988) messaging.
- どんなX.500 DSAs、DUAs、例えば、API LDAP、など変化はX.400(1988)がメッセージングであるとサポートする必要がありました。
- X.400(1988) MTAs, UAs, MSs, gateways to RFC 822/MIME
and X.400(1984) plus gateways to other messaging
systems e.g., Microsoft Mail, Lotus cc:Mail, etc.
- X.400(1988)MTAsとUAsとMSsとRFC822/MIMEとX.400(1984)へのゲートウェイと例えば、マイクロソフトメール、他のメッセージシステムロータスへのゲートウェイ、cc:Mailなど
- User Interfaces that integrate X.400(1988) UAs and
X.500 DUAs with user applications such as Word
Processors, etc.
- X.400(1988)UAsとX.500 DUAsをWord Processorsなどのユーザアプリケーションと統合するユーザInterfaces
- E-mail network management software both for users and
administrators
- ユーザと管理者のためにネットワークマネージメントソフトウェアをメールしてください。
- Organisational
- Organisational
- trusted network for security (i.e., the distribution of
security keys) and whether this trusted network should
or can be the same as the PEM trusted network presently
under deployment.
- セキュリティ(すなわち、セキュリティキーの分配)のための信じられたネットワークとこれがネットワークを信じたかどうかが、展開で同じであるべきである、またはPEMが現在ネットワークを信じたのと同じである場合があります。
- usage of PEM within X.400(1988).
- X.400(1988)の中のPEMの使用法。
- PEM to and from X.400(1988) gatewaying.
- gatewayingとX.400(1988)gatewayingであることからのPEM。
- how to register and publicise object IDs for
X.400(1988).
- X.400(1988)のためにオブジェクトIDを登録して、宣伝する方法。
- addresses are well publicised of PRMD and ADMD
registration authorities.
- アドレスはPRMDとADMD登録局についてよく宣伝されます。
- creation and modification authority for X.400-to-RFC-
822 mapping rules is defined.
- X.400からRFC-822の配置規則のための作成と変更権威は定義されます。
- creation and modification authority for MTA routing
rules is defined.
- MTAルーティング規則のための作成と変更権威は定義されます。
RARE WG-MSG Task Force 88 [Page 42] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[42ページ]RFC1616X.400(88)
- what methods should be used to liaison to other bodies
like IETF, ISO, EEMA, EMA, etc.
- どんなメソッドがIETF、ISO、EEMA、EMAなどのような他のボディーへの連絡に使用されるべきですか。
- ensuring that any Public Domain software needed for the
X.400(1988) service is distributed widely, quickly and
efficiently.
- どんなPublic DomainソフトウェアもX.400(1988)にサービスを必要としたのを確実にするのが広さに、すぐに、効率的に分配されます。
- Deployment
- 展開
- which services should start such a migration (i.e.,
COSINE MHS RELAYs, Universities, other).
- どのサービスがそのような移行(すなわち、大学の、そして、他のCOSINE MHS RELAYs)を始めるべきですか?
- the topology of the X.400(1988) MTS.
- X.400(1988)MTSのトポロジー。
- addressing of users between X.400(1984 and 1988) and
RFC 822 e.g., how will X.400(1988) T.61 address
components be processed by X.400(1984) and RFC 822
systems.
- 扱って、X.400(1984と1988)とRFC822の間のユーザに、X.400(1988)T.61アドレス構成要素はX.400によってどのように例えば、加工処理されるだろうか。(1984) そして、RFC822システム。
- which X.400(1988) body parts MUST be supported by the
research community.
- 研究団体はX.400(1988)身体の部分をサポートしなければなりません。
- if any new APIs - or modified APIs - are needed for
X.400(1988) and messaging in general.
- 何か新しいAPI(変更されたAPI)がX.400(1988)と一般に、メッセージングに必要であるなら。
- the specifications and development of any needed Public
Domain software.
- いずれの仕様と開発はPublic Domainソフトウェアを必要としました。
- what existing Public Domain software should be modified
to accommodate X.400(1988) systems.
- どんな既存のPublic Domainソフトウェアが、X.400(1988)システムを収容するように変更されるべきですか?
- how rapidly to deploy the X.400(1988) service.
- X.400(1988)がサービスであるとどのように急速に配布しますか?
- ensuring that there is 'little or no loss of service'
in any migration from X.400(1984), or RFC 822, to
X.400(1988).
- そこでそれを確実にするのは、X.400(1984)、またはRFC822からのどんな移行でも'ほとんどサービスの損失がありません'です、X.400(1988)に。
- considering what Value Added Services, based upon
X.400(1988), could be started to encourage uptake of
X.400(1988).
- X.400(1988)に基づくValue Added ServicesがそうすることができたことがX.400(1988)の理解力を奨励するために出発すると考えます。
RARE WG-MSG Task Force 88 [Page 43] RFC 1616 X.400(88) for European Academics and Research May 1994
ヨーロッパ人のアカデミー会員と研究1994年5月のためのまれなWG-MSG特別委員会88[43ページ]RFC1616X.400(88)
Authors' Addresses
作者のアドレス
Only the two editors' complete addresses are listed here:
2人のエディタだけの完全なアドレスはここに記載されています:
Erik Huizer (Task Force chair) SURFnet bv P.O. Box 19035 NL-3501 DA Utrecht Europe
エリックHuizer(タスクForceいす)SURFnet bv私書箱19035NL-3501 DAユトレヒトヨーロッパ
Phone: +31 30 310 290 RFC 822: huizer@surfnet.nl X.400: S=huizer;O=SURFnet;PRMD=surf;ADMD=400net;C=nl;
以下に電話をしてください。 +31 30 310 290RFC822: huizer@surfnet.nl X.400: S=huizer; O=SURFnet; PRMD=サーフ; ADMD=400net; Cはnlと等しいです。
James A. (Jim) Romaguera NetConsult AG Berner Technopark Morgenstrasse 129 CH-3018 Bern Europe
ジェームス・A.(ジム)Romaguera NetConsult株式会社ベルナーアルプスTechnopark Morgenstrasse129CH-3018ベルンヨーロッパ
Phone: +41 31 998 4141 RFC 822: romaguera@netconsult.ch X.400: S=romaguera;O=netconsult;PRMD=SWITCH;ADMD=ARCOM;C=CH;
以下に電話をしてください。 +41 31 998 4141RFC822: romaguera@netconsult.ch X.400: S=romaguera; O=netconsult; PRMD=スイッチ; ADMD=ARCOM; CはCHと等しいです。
The Task Force as a whole can be reached per e-mail at the address:
メール単位で全体でTask Forceにアドレスで達することができます:
RFC 822: tf-88@SURFnet.nl X.400: S=tf-88;O=SURFnet;PRMD=surf;ADMD=400net;C=nl;
RFC822: tf-88@SURFnet.nl X.400: S=tf-88; O=SURFnet; PRMD=サーフ; ADMD=400net; Cはnlと等しいです。
RARE WG-MSG Task Force 88 [Page 44]
まれなWG-MSG特別委員会88[44ページ]
一覧
スポンサーリンク
