RFC2017 日本語訳

Network Working Group                                         N. Freed
Request for Comments: 2017                      Innosoft International
Category: Standards Track                                     K. Moore
                                               University of Tennessee
                                                 A. Cargille, WG Chair
                                                          October 1996

ネットワークワーキンググループN.はコメントを求める要求を解放しました: 2017年のInnosoftの国際カテゴリ: テネシーA.Cargilleの標準化過程K.ムーア大学、WG議長1996年10月

                         Definition of the URL
                     MIME External-Body Access-Type

URL MIME外部のボディーアクセス型の定義

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

1.  Abstract

1. 要約

   This memo defines a new access-type for message/external-body MIME
   parts for Uniform Resource Locators (URLs).  URLs provide schemes to
   access external objects via a growing number of protocols, including
   HTTP, Gopher, and TELNET.  An initial set of URL schemes are defined
   in RFC 1738.

このメモはUniform Resource Locator(URL)のために外部のメッセージ/身体のMIME部分のための新しいアクセス型を定義します。 URLは、HTTP、ゴーファー、およびTELNETを含む増加している数のプロトコルで外部のオブジェクトにアクセスするために体系を提供します。 1人の始発のURL体系はRFC1738で定義されます。

2.  Introduction

2. 序論

   The Multipurpose Internet Message Extensions (MIME) define a facility
   whereby an object can contain a reference or pointer to some form of
   data rather than the actual data itself. This facility is embodied in
   the message/external-body media type defined in RFC 1521.  Use of
   this facility is growing as a means of conserving bandwidth when
   large objects are sent to large mailing lists.

MultipurposeインターネットMessage Extensions(MIME)はオブジェクトが実際のデータ自体よりむしろ何らかのフォームに関するデータに参照か指針を含むことができる施設を定義します。 この施設はRFC1521で定義された外部のメッセージ/ボディーメディアタイプに表現されます。 この施設の使用は大きいオブジェクトを大きいメーリングリストに送るとき帯域幅を保存する手段として成長しています。

   Each message/external-body reference must specify a mechanism whereby
   the actual data can be retrieved.  These mechanisms are called access
   types, and RFC 1521 defines an initial set of access types: "FTP",
   "ANON-FTP", "TFTP", "LOCAL-FILE", and "MAIL-SERVER".

それぞれの外部のメッセージ/ボディー参照は実際のデータを検索できるメカニズムを指定しなければなりません。 これらのメカニズムはアクセス型と呼ばれます、そして、RFC1521は1人の始発のアクセス型を定義します: 「FTP」、「やがて、-、FTP、」、"TFTP"、「ローカルファイル」、および「メールサーバ。」

Freed, et. al.              Standards Track                     [Page 1]

RFC 2017                    URL Access-Type                 October 1996

etフリード、アル。 規格はURLアクセス型1996年10月にRFC2017を追跡します[1ページ]。

   Uniform Resource Locators, or URLs, also provide a means by which
   remote data can be retrieved automatically.  Each URL string begins
   with a scheme specification, which in turn specifies how the
   remaining string is to be used in conjunction with some protocol to
   retrieve the data. However, URL schemes exist for protocol operations
   that have no corresponding MIME message/external-body access type.
   Registering an access type for URLs therefore provides
   message/external-body with access to the retrieval mechanisms of URLs
   that are not currently available as access types.  It also provides
   access to any future mechanisms for which URL schemes are developed.

また、Uniform Resource Locator、またはURLが自動的にリモートデータを検索できる手段を提供します。 それぞれのURLストリングは体系仕様で始まります。(順番に、それは、データを検索するのに何らかのプロトコルに関連して使用される残っているストリングがことである方法を指定します)。 しかしながら、URL体系は対応するMIME外部のメッセージ/本体アクセス型が全くいないプロトコル操作のために存在しています。 したがって、URLのためにアクセス型を示すと、現在アクセス型として利用可能でないURLの検索へのアクセスによる外部のメッセージ/ボディーのメカニズムは提供されます。 また、それはURL体系が開発されているどんな将来のメカニズムへのアクセスも提供します。

   This access type is only intended for use with URLs that actually
   retreive something. Other URL mechansisms, e.g.  mailto, may not be
   used in this context.

このアクセス型は実際に何かをretreiveするURLとの使用のために意図するだけです。 他のURL mechansisms(例えば、mailto)はこのような関係においては使用されないかもしれません。

3.  Definition of the URL Access-Type

3. URLアクセス型の定義

   The URL access-type is defined as follows:

URLアクセス型は以下の通り定義されます:

    (1)   The name of the access-type is URL.

(1) アクセス型の名前はURLです。

    (2)   A new message/external-body content-type parameter is
          used to actually store the URL string. The name of the
          parameter is also "URL", and this parameter is
          mandatory for this access-type. The syntax and use of
          this parameter is specified in the next section.

(2) 新しい外部のメッセージ/ボディーcontent typeパラメタは、実際にURLストリングを保存するのに使用されます。 また、パラメタの名前は「URL」です、そして、このパラメタはこのアクセス型に義務的です。 このパラメタの構文と使用は次のセクションで指定されます。

    (3)   The phantom body area of the message/external-body is
          not used and should be left blank.

(3) 外部のメッセージ/ボディーの幻影のボディー領域は、使用されていなくて、空白のままにされるべきです。

   For example, the following message illustrates how the URL access-
   type is used:

例えば、以下のメッセージはアクセスがタイプするURLがどう使用されているかを例証します:

    Content-type: message/external-body; access-type=URL;
                  URL="http://www.foo.com/file"

文書内容: 外部のメッセージ/ボディー。 アクセス型はURLと等しいです。 URL= " http://www.foo.com/file "

    Content-type: text/html
    Content-Transfer-Encoding: binary

文書内容: html Content転送テキスト/コード化: バイナリー

    THIS IS NOT REALLY THE BODY!

これが本当にそうでない、ボディー!

Freed, et. al.              Standards Track                     [Page 2]

RFC 2017                    URL Access-Type                 October 1996

etフリード、アル。 規格はURLアクセス型1996年10月にRFC2017を追跡します[2ページ]。

3.1.  Syntax and Use of the URL parameter

3.1. URLパラメタの構文とUse

   Using the ANBF notations and definitions of RFC 822 and RFC 1521, the
   syntax of the URL parameter Is as follows:

ANBF記法とRFC822とRFC1521の定義、以下のURLパラメタIsの構文を使用します:

     URL-parameter := <"> URL-word *(*LWSP-char URL-word) <">

URLパラメタ:=<、「>URL単語*(*URL単語をLWSP炭にする)<">"

     URL-word := token
                 ; Must not exceed 40 characters in length

URL単語:=トークン。 必須は長さで40のキャラクタを超えていません。

   The syntax of an actual URL string is given in RFC 1738.  URL strings
   can be of any length and can contain arbitrary character content.
   This presents problems when URLs are embedded in MIME body part
   headers that are wrapped according to RFC 822 rules. For this reason
   they are transformed into a URL-parameter for inclusion in a
   message/external-body content-type specification as follows:

RFC1738で実際のURLストリングの構文を与えます。 URLストリングは、どんな長さもあることができて、気紛れな質内容を含むことができます。 URLがRFC822規則に従って包装されるMIMEボディー部分ヘッダーに埋め込まれているとき、これは問題を提示します。 この理由で、それらは以下の外部のメッセージ/ボディーcontent type仕様での包含のためのURLパラメタに変えられます:

    (1)   A check is made to make sure that all occurrences of
          SPACE, CTLs, double quotes, backslashes, and 8-bit
          characters in the URL string are already encoded using
          the URL encoding scheme specified in RFC 1738. Any
          unencoded occurrences of these characters must be
          encoded.  Note that the result of this operation is
          nothing more than a different representation of the
          original URL.

(1) SPACE、CTLs、二重引用符、バックスラッシュ、およびURLストリングの8ビットのキャラクタのすべての発生がRFC1738で指定された体系をコード化するURLを使用することで既にコード化されるのを確実にするのをチェックをします。 これらのキャラクタのどんな暗号化されていない発生もコード化しなければなりません。 この操作の結果がただオリジナルのURLの異なった表現であることに注意してください。

    (2)   The resulting URL string is broken up into substrings
          of 40 characters or less.

(2) 結果として起こるURLストリングは40以下のキャラクタに関するサブストリングに壊れます。

    (3)   Each substring is placed in a URL-parameter string as a
          URL-word, separated by one or more spaces.  Note that
          the enclosing quotes are always required since all URLs
          contain one or more colons, and colons are tspecial
          characters [RFC 1521].

(3) 各サブストリングは1つ以上の空間によって切り離されたURL単語としてURLパラメタストリングに置かれます。 すべてのURLが1コロン以上を含んでいて、コロンがtspecialキャラクタ[RFC1521]であるので、同封引用文がいつも必要であることに注意してください。

   Extraction of the URL string from the URL-parameter is even simpler:
   The enclosing quotes and any linear whitespace are removed and the
   remaining material is the URL string.

URLパラメタからのURLストリングの抽出はさらに簡単です: 同封引用文とどんな直線的な空白も取り除かれます、そして、残っている材料はURLストリングです。

Freed, et. al.              Standards Track                     [Page 3]

RFC 2017                    URL Access-Type                 October 1996

etフリード、アル。 規格はURLアクセス型1996年10月にRFC2017を追跡します[3ページ]。

   The following example shows how a long URL is handled:

以下の例は長いURLがどう扱われるかを示しています:

     Content-type: message/external-body; access-type=URL;
                   URL="ftp://ftp.deepdirs.org/1/2/3/4/5/6/7/
                        8/9/10/11/12/13/14/15/16/17/18/20/21/
                        file.html"

文書内容: 外部のメッセージ/ボディー。 アクセス型はURLと等しいです。 URL= 「 ftp://ftp.deepdirs.org/1/2/3/4/5/6/7/ 8/9/10/11/12/13/14/15/16/17/18/20/21/file.html」

     Content-type: text/html
     Content-Transfer-Encoding: binary

文書内容: html Content転送テキスト/コード化: バイナリー

     THIS IS NOT REALLY THE BODY!

これが本当にそうでない、ボディー!

   Some URLs may provide access to multiple versions of the same object
   in different formats. The HTTP URL mechanism has this capability, for
   example.  However, applications may not expect to receive something
   whose type doesn't agree with that expressed in the
   message/external-body, and may in fact have already made irrevocable
   choices based on this information.

いくつかのURLが同じオブジェクトの複数のバージョンへのアクセスを異なった形式に提供するかもしれません。 HTTP URLメカニズムには、例えばこの能力があります。 しかしながら、アプリケーションは、タイプが外部のメッセージ/ボディーで言い表されたそれに同意しない何かを受けると予想しないで、事実上既にこの情報に基づく呼び戻せない選択をしたかもしれません。

   Due to these considerations, the following restriction is imposed:
   When URLs are used in the context of an access-type only those
   versions of an object whose content-type agrees with that specified
   by the inner message/external-body header can be retrieved and used.

これらの問題のため、以下の制限は課されます: URLがアクセス型の文脈で使用されるとき、content typeが内側の外部のメッセージ/ボディーヘッダーによって指定されたそれに同意するオブジェクトのそれらのバージョンだけを検索して、使用できます。

4.  Security Considerations

4. セキュリティ問題

   The security considerations of using URLs in the context of a MIME
   access-type are no different from the concerns that arise from their
   use in other contexts. The specific security considerations
   associated with each type of URL are discussed in the URL's defining
   document.

MIMEアクセス型の文脈の使用URLのセキュリティ問題は他の文脈における彼らの使用から起こる関心と異なっていません。 URL定義文書でそれぞれのタイプのURLに関連している特定のセキュリティ問題について議論します。

   Note that the Content-MD5 field can be used in conjunction with any
   message/external-body access-type to provide an integrity check. This
   insures that the referenced object really is what the message
   originator intended it to be. This is not a signature service and
   should not be confused with one, but nevetheless is quite useful in
   many situations.

保全チェックを提供するのにどんな外部のメッセージ/ボディーアクセス型に関連してContent-MD5分野を使用できることに注意してください。 これは、参照をつけられたオブジェクトが本当にメッセージ創始者がそれは意図したものであることを保障します。 これは、署名サービスでなく、1つに混乱しているべきではありませんが、nevethelessは多くの状況でかなり役に立ちます。

5.  Acknowledgements

5. 承認

   The authors are grateful for the feedback and review provided by John
   Beck and John Klensin.

作者はジョン・べックとジョンKlensinによって提供されたフィードバックとレビューに感謝しています。

Freed, et. al.              Standards Track                     [Page 4]

RFC 2017                    URL Access-Type                 October 1996

etフリード、アル。 規格はURLアクセス型1996年10月にRFC2017を追跡します[4ページ]。

6.  References

6. 参照

   [RFC-822]
        Crocker, D., "Standard for the Format of ARPA Internet
        Text Messages", STD 11, RFC 822, UDEL, August 1982.

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

   [RFC-1521]
        Borenstein, N. and N. Freed, "MIME (Multipurpose
        Internet Mail Extensions): Mechanisms for Specifying and
        Describing the Format of Internet Message Bodies", RFC
        1521, Bellcore, Innosoft, September, 1993.

[RFC-1521]Borenstein(N.と解放されたN.)は「以下をまね(マルチパーパスインターネットメールエクステンション)」。 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。

   [RFC-1590]
        Postel, J., "Media Type Registration Procedure", RFC
        1590, USC/Information Sciences Institute, March 1994.

[RFC-1590] ポステル、J.、「メディアは登録手順をタイプする」RFC1590、科学が1994年3月に設けるUSC/情報。

   [RFC-1738]
        Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
        Resource Locators (URL)", December 1994.

[RFC-1738] バーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」、1994年12月。

7.  Authors' Addresses

7. 作者のアドレス

   Ned Freed
   Innosoft International, Inc.
   1050 East Garvey Avenue South
   West Covina, CA 91790
   USA

ネッドは東ガーヴェーアベニューSouth West Innosoftの国際Inc.1050カリフォルニア91790コビーナ(米国)を解放しました。

   Phone: +1 818 919 3600
   Fax: +1 818 919 3614
   EMail: ned@innosoft.com

以下に電話をしてください。 +1 818 919、3600Fax: +1 3614年の818 919メール: ned@innosoft.com

   Keith Moore
   Computer Science Dept.
   University of Tennessee
   107 Ayres Hall
   Knoxville, TN 37996-1301
   USA

キースムーアコンピュータサイエンス部 テネシー大学107歌曲Hallテネシー37996-1301ノクスビル(米国)

   EMail: moore@cs.utk.edu

メール: moore@cs.utk.edu

Freed, et. al.              Standards Track                     [Page 5]

etフリード、アル。 標準化過程[5ページ]