RFC1137 日本語訳

1137 Mapping between full RFC 822 and RFC 822 with restrictedencoding. S. Kille. December 1989. (Format: TXT=6266 bytes) (Updates RFC0976) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                           S. Kille
Request for Comments:  1137                    University College London
Updates:  RFC 976                                          December 1989

Killeがコメントのために要求するワーキンググループS.をネットワークでつないでください: 1137のユニバーシティ・カレッジロンドンアップデート: RFC976 1989年12月

             Mapping Between Full RFC 822 and RFC 822 with
                          Restricted Encoding

制限されたコード化がある完全なRFC822とRFC822の間のマッピング

Status of this Memo

このMemoの状態

   This RFC suggests an electronic mail protocol mapping for the
   Internet community and UK Academic Community, and requests discussion
   and suggestions for improvements.  This memo does not specify an
   Internet standard.  Distribution of this memo is unlimited.

このRFCはインターネットコミュニティ、イギリスのAcademic Community、および要求のために改良のための議論と提案を写像する電子メールプロトコルを勧めます。 このメモはインターネット標準を指定しません。 このメモの分配は無制限です。

   This document describes a set of address mappings which will enable
   interworking between systems operating RFC 822 protocols in a general
   manner, and those environments where transfer of RFC 822 messages
   restricts the character set which can be used in addresses.  UUCP
   transfer of RFC 822 messages is an important case of this
   [Crocker82a, Horton86a].

このドキュメントはシステムの間で一般的な方法で操作RFC822プロトコルを織り込んで、RFC822メッセージの転送がアドレスで使用できる文字集合を制限するそれらの環境を可能にする1セットのアドレス・マッピングについて説明します。 RFC822メッセージのUUCP転送はこの[Crocker82a、Horton86a]重要な例です。

Specification

仕様

   This document specifies a mapping between two protocols.  This
   specification should be used when this mapping is performed on the
   Internet or in the UK Academic Community. This specification may be
   modified in the light of implementation experience, but no
   substantial changes are expected.

このドキュメントは2つのプロトコルの間のマッピングを指定します。 このマッピングがインターネットの上、または、イギリスのAcademic Communityで実行されるとき、この仕様は使用されるべきです。 この仕様は実装経験の見地から変更されるかもしれませんが、大きな変化は全く予想されません。

1.  Introduction

1. 序論

   Some mail networks which use RFC 822 cannot support the full
   character set required by all aspects of RFC 822.  This document
   describes a symmetrical mapping between full RFC 822 addressing, and
   a form for use on these networks.  Any addresses within the networks
   will not use the full RFC 822 addressing, and so any addresses
   encoded according to this standard will always represent remote
   addresses.  This document derives from a mapping originally specified
   in RFC 987 [Kille86a], where the domain of application was more
   restricted.  Two terms are now defined:

RFC822を使用するいくつかのメールネットワークはRFC822の全面によって必要とされた完全な文字集合をサポートすることができません。 このドキュメントはこれらのネットワークにおける使用のために完全なRFC822アドレシングと、フォームの間の対称のマッピングについて説明します。 ネットワークの中のどんなアドレスも完全なRFC822アドレシングを使用しないので、この規格に従ってコード化されたどんなアドレスもいつもリモートアドレスを表すでしょう。 このドキュメントが元々RFC987[Kille86a]で指定されたマッピングに由来しています。そこでは、アプリケーションのドメインがさらに制限されました。 2つの用語が現在、定義されます:

   Full RFC 822

完全なRFC822

      This implies full support for transfer to and from any legal RFC
      822 address.  In particular, the quoted-string form of local-part
      must be supported (e.g., <"Joe Soap"@foo.bar>).

これはアドレスとどんな法的なRFC822アドレスからも転送の全面的な支援を含意します。 特に、(例えば、<「ばかな奴」@foo.bar>)であると地方の部分の引用文字列フォームをサポートしなければなりません。

Kille                                                           [Page 1]

RFC 1137           E-Mail Address and Quoted Strings       December 1989

Kille[1ページ]RFC1137Eメールアドレスと引用文字列1989年12月

   Restricted RFC 822

制限されたRFC822

      This implies a subset of RFC 822 addressing.  The quoted-string
      form of local-part need not be supported.  Standard UUCP mail
      transfer falls into this category.  Restricted RFC 822 is
      undesirable, but in practice it exists in many places.

これはRFC822アドレシングの部分集合を含意します。 地方の部分の引用文字列フォームはサポートされる必要はありません。 標準のUUCP郵便為替はこのカテゴリになります。 制限されたRFC822は望ましくないのですが、実際には、それは多くの場所に存在しています。

      When a message is transferred from full RFC 822 to restricted RFC
      822, and address forms used in full RFC 822 are involved, message
      loss may occur (e.g., it may not be possible to return an error
      message).  This RFC describes a quoting mechanism which may be
      used to map between full RFC 822 and restricted RFC 822, in order
      to alleviate this problem.

完全なRFC822から制限されたRFC822までメッセージを移して、完全なRFC822で使用される呼びかけの形式がかかわるとき、メッセージの損失は発生するかもしれません(例えば、エラーメッセージを返すのは可能でないかもしれません)。 このRFCは完全なRFC822と制限されたRFC822の間で写像するのにおいて使用されるかもしれない引用メカニズムについて説明します、この問題を軽減するために。

2.  Encoding

2. コード化

   The RFC 822 EBNF meta notation is used.  Any EBNF definitions taken
   from RFC 822 are prefixed by the string "822.".

RFC822EBNFメタ記法は使用されています。 RFC822から取られたどんなEBNF定義もストリング「822」によって前に置かれています。

   The following EBNF is specified.

以下のEBNFは指定されます。

      atom-encoded    = *( a-char / a-encoded-char )
      a-char          = <any CHAR except specials (other than "@"
                              and "."), SPACE,
                              CTL, "_", and "#">
      a-encoded-char  = "_"                   ; (space)
                      / "#u#"                 ; (_)
                      / "#l#"                 ; <(>
                      / "#r#"                 ; <)>
                      / "#m#"                 ; (,)
                      / "#c#"                 ; (:)
                      / "#b#"                 ; (\)
                      / "#h#"                 ; (#)
                      / "#e#"                 ; (=)
                      / "#s#"                 ; (/)
                      / "#" 3DIGIT "#"

そして、そして、「原子でコード化された=*(aが炭をa-炭/コード化している)a-炭がどんなCHARも除く<と等しい、特別番組、("@"、」、」、)、スペース、CTL、"_"、「#「>コード化された炭="_"」。 (スペース) 「/」#u#、」、。 (_) 「/」#l#、」、。 「<、(>/、」 #r#、」、;、<)「>/」#m#、」、。 (,) 「/」#c#、」、。 (:) 「/」#b#、」、。 (\) 「/」#h#、」、。 (#) 「/」#e#、」、。 (=) 「/」#s#、」、。 (/) /「#」3DIGIT「#」

   The 822.3DIGIT in EBNF.a-encoded-char must have range 0-127, and is
   interpreted in decimal as the corresponding ASCII character.  The
   choice of special abbreviations (as opposed to decimal encoding)
   provided is based on the manner in which this mapping is most
   frequently used.  There are special encodings for each of the
   PrintableString characters not in EBNF.a-char, except ".".  Space is
   given a single character encoding, due to its (expected) frequency of
   use, and backslash as the RFC 822 single quote character.

EBNF.aが炭をコード化していたところの822.3DIGITは範囲0-127を持たなければならなくて、対応するASCII文字として小数で解釈されます。 提供された特別な略語(10進コード化と対照的に)の選択はこのマッピングが最も頻繁に使用される方法に基づいています。 「PrintableStringキャラクタ各人のための特別なencodingsがどんなEBNF.a-炭でもなくて、除いてください」、」 ただ一つの文字符号化をスペースに与えます、使用の(予想されます)頻度、およびRFC822の単独の引用文字としてのバックスラッシュのため。

   This mapping is used to transform between the two forms of 822.word:
   822.quoted-string (restricted RFC 822) and 822.atom (restricted RFC

このマッピングは822.wordの2つのフォームの間で変形するのに使用されます: 822. 引用文字列(RFC822を制限する)と822.atom、(RFCを制限します。

Kille                                                           [Page 2]

RFC 1137           E-Mail Address and Quoted Strings       December 1989

Kille[2ページ]RFC1137Eメールアドレスと引用文字列1989年12月

   822).  To encode (full RFC 822 -> restricted RFC 822), first remove
   any quoting from any 822.quoted-string.  Then, all EBNF.a-char are
   used directly and all other CHAR are encoded as EBNF.a-encoded-char.

822). (完全なRFC822の->の部外秘なRFC822)をコード化するために、いずれも最初に、どんな822.quoted-stringからも引用しながら、取り外されます。 そして、EBNF.aすべて焦げるのは、EBNF.aが炭をコード化していたとして他の中古のCHARがコード化されるということです。

   To decode (restricted RFC 822 -> full RFC 822): if the address can be
   parsed as EBNF.encoded-atom reverse the previous mapping.  If it
   cannot be so parsed, map the characters directly.

解読する(RFC822の->の完全なRFC822を制限する)ために: EBNF.encoded-原子としてアドレスを分析できるなら、前のマッピングを逆にしてください。 それをそう分析できないなら、直接キャラクタを写像してください。

3.  Application

3. アプリケーション

   This mapping should be used for all addresses, at the MTS or Header
   level.  It is applied to the 822.local-part of the addresses.  For
   example:

このマッピングはすべてのアドレスにMTSかHeaderレベルに使用されるべきです。 それはアドレスの822.local-部分に付けられます。 例えば:

      Full RFC 822                       Restricted RFC 822

完全なRFC822はRFC822を制限しました。

      Steve.Kille@cs.ucl.ac.uk     <->   Steve.Kille@cs.ucl.ac.uk
      "Steve Kille"@cs.ucl.ac.uk   <->   Steve_Kille@cs.ucl.ac.uk
      "argle#~"@blargle            <->   argle#h##126#@blargle

Steve.Kille@cs.ucl.ac.uk <-> Steve.Kille@cs.ucl.ac.uk "Steve Kille"@cs.ucl.ac.uk <-> Steve_Kille@cs.ucl.ac.uk "argle#~"@blargle <-> argle#h##126#@blargle

References

参照

   [Crocker82a]  Crocker, D., "Standard of the Format of ARPA Internet
   Text Messages", RFC 822, August 1982.

[Crocker82a] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、RFC822、1982年8月。

   [Horton86a]  Horton, M., "UUCP Mail Interchange Format Standard",
   RFC 976, February 1986.

[Horton86a] ホートン、M.、「UUCPは置き換え形式規格を郵送する」RFC976、1986年2月。

   [Kille86a]  Kille, S., "Mapping Between X.400 and RFC 822",
   UK Academic Community Report (MG.19), RFC 987, June 1986.

[Kille86a] Kille、S.が「X.400とRFC822の間で写像され」て、イギリスの学界は1986年6月に(mg.19)、RFC987を報告します。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Author's Address

作者のアドレス

   Steve Kille
   University College London
   Gower Street
   WC1E 6BT
   England

スティーブKilleユニバーシティ・カレッジロンドンWC1E 6BTイギリスガウアー・ストリート

   Phone: +44-1-380-7294

以下に電話をしてください。 +44-1-380-7294

   EMail: S.Kille@Cs.Ucl.AC.UK

メール: S.Kille@Cs.Ucl.AC.UK

Kille                                                           [Page 3]

Kille[3ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

CREATE USER ユーザーを作成する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る