RFC2717 日本語訳

2717 Registration Procedures for URL Scheme Names. R. Petke, I. King. November 1999. (Format: TXT=19780 bytes) (Obsoleted by RFC4395) (Also BCP0035) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          R. Petke
Request for Comments: 2717                           UUNET Technologies
BCP: 35                                                         I. King
Category: Best Current Practice                   Microsoft Corporation
                                                          November 1999

Petkeがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2717UUNET技術BCP: 35I.Category王: 最も良い現在の練習マイクロソフト社1999年11月

              Registration Procedures for URL Scheme Names

URL計画名のための登録手順

Status of this Memo

このMemoの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

要約

   This document defines the process by which new URL scheme names are
   registered.

このドキュメントは新しいURL計画名が登録されている過程を定義します。

1.0 Introduction

1.0 序論

   A Uniform Resource Locator (URL) is a compact string representation
   of the location for a resource that is available via the Internet.
   RFC 2396 [1] defines the general syntax and semantics of URIs, and,
   by inclusion, URLs.  URLs are designated by including a "<scheme>:"
   and then a "<scheme-specific-part>".  Many URL schemes are already
   defined, however, new schemes may need to be defined in the future in
   order to accommodate new Internet protocols and/or procedures.

Uniform Resource Locator(URL)はインターネットを通して利用可能なリソースのための位置のコンパクトなストリング表現です。 RFC2396[1]はURIの一般的な構文と意味論、および包含によるURLを定義します。 URLはaを含んでいることによって指定されて、「<は>を計画する」ということです。そして、「<の計画特有の部分>。」多くのURL計画が既に定義されて、しかしながら、新しい計画は、将来新しいインターネットプロトコル、そして/または、手順に対応するために定義される必要があるかもしれません。

   A registration process is needed to ensure that the names of all such
   new schemes are guaranteed not to collide.  Further, the registration
   process ensures that URL schemes intended for wide spread, public use
   are developed in an orderly, well-specified, and public manner.

登録手続が、そのようなすべての新しい計画の名前が衝突しないように保証されるのを保証するのに必要です。さらに、登録手続は、広い普及のために意図するURL計画、公共の使用が規則的で、よく指定されて、公共の方法で開発されるのを確実にします。

   This document defines the registration procedures to be followed when
   new URL schemes are created.  A separate document, RFC 2718,
   Guidelines for URL Schemes [2], provides guidelines for the creation
   of new URL schemes.  The primary focus of this document is on the
   <scheme> portion of new URL schemes, referred to as the "scheme name"
   throughout this document.

このドキュメントは、新しいURL計画が作成されるとき、続かれるように登録手順を定義します。別々のドキュメント(RFC2718、URL Schemes[2]のためのGuidelines)は新しいURL計画の創造のためのガイドラインを提供します。このドキュメントの焦点がこのドキュメント中に「計画名」と呼ばれた新しいURL計画の<計画>部分にあります。

Petke & King             Best Current Practice                  [Page 1]

RFC 2717      Registration Procedures for URL Scheme Names November 1999

PetkeとCurrent最も良い王は1999年11月にURL計画名のためにRFC2717登録手順を練習します[1ページ]。

1.1 Notation

1.1 記法

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。

2.0 URL Scheme Name Registration Trees

2.0 URL計画名前登録木

2.1 General

2.1 一般

   In order to increase the efficiency and flexibility of the URL scheme
   name registration process, the need is recognized for multiple
   registration "trees".  The registration requirements and specific
   registration procedures for each tree differ, allowing the overall
   registration procedure to accommodate the different natural
   requirements for URL schemes.  For example, a scheme that will be
   recommended for wide support and implementation by the Internet
   community requires a more complete review than a scheme intended to
   be used for resources associated with proprietary software.

登録手続というURL計画名の効率と柔軟性を高めるために、必要性は複数の登録「木」として認識されます。各木のための登録要件と特定の登録手順は異なります、総合的な登録手順がURL計画のための異なった自然な要件を収容するのを許容して。例えば、幅広い支持と実現のためにインターネットコミュニティによって推薦される計画は独占ソフトウェアに関連しているリソースに使用されることを意図する計画より完全なレビューを必要とします。

   The first step in registering a new URL scheme name is to determine
   which registration tree the scheme should be registered in.
   Determination of the proper registration tree is based on the
   intended use for the new scheme and the desired syntax for the scheme
   name.

新しいURL計画名を登録することにおける第一歩は計画がどの登録木で登録されるべきであるかを決定することです。適切な登録木の決断は計画名のための新しい計画と必要な構文の意図している使用に基づいています。

   This document will discuss in detail the tree that reflects current
   practice, under IETF ownership and control.  It will also set forth
   an outline to assist authors in creating new trees to address
   differing needs for wide acceptance and interoperability, ease of
   creation and use, and type and "strength" of ownership.

このドキュメントは詳細にIETF所有と支配の下で現在の習慣を反映する木について議論するでしょう。また、それは、先へアウトラインに広い承認と相互運用性の異なった必要性、創造、使用、およびタイプの容易さ、および所有権の「強さ」を記述するために新しい木を作成するのに作者を助けるように設定するでしょう。

2.2 The IETF Tree

2.2 IETF木

   The IETF tree is intended for URL schemes of general interest to the
   Internet community.  The tree exists for URL schemes that require a
   substantive review and approval process.  It is expected that
   applicability statements for particular applications will be
   published from time to time that recommend implementation of, and
   support for, URL schemes that have proven particularly useful in
   those contexts.

IETF木は一般的にインターネットコミュニティへの関心のURL計画のために意図します。木は実質的なレビューと承認審査方式を必要とするURL計画のために存在しています。それが予想される、特定用途のための声明が時々発行されて、それが実現を推薦するということであるために望んでいるその適用性、およびサポート、それらの文脈で特に役に立つと判明したURL計画。

Petke & King             Best Current Practice                  [Page 2]

RFC 2717      Registration Procedures for URL Scheme Names November 1999

PetkeとCurrent最も良い王は1999年11月にURL計画名のためにRFC2717登録手順を練習します[2ページ]。

2.3 Additional Registration Trees

2.3 追加登録木

   From time to time and as required by the community, the IESG may
   create new top-level registration trees.  These trees may require
   significant, little or no registration, and may allow change control
   to rest in the hands of individuals or groups other than IETF.  A new
   tree should only be created if no existing tree can be shown to
   address the set of needs of some sector of the community.

時々、必要に応じて、共同体のそばでは、IESGが新しいトップレベル登録木を作成するかもしれません。これらの木が必要であるかもしれない、重要である、登録、変化コントロールが個人かIETF以外のグループの手に静止しているのをまず許容しないかもしれません。共同体の何らかのセクターの必要性のセットに演説するためにどんな既存の木も見せることができない場合にだけ、新しい木は作成されるべきです。

3.0 Requirements for Scheme Name Registration

計画のための3.0の要件が登録を命名します。

3.1 General Requirements

3.1 一般要件

   All new URL schemes, regardless of registration tree, MUST conform to
   the generic syntax for URLs as specified in RFC 2396.

登録木にかかわらず、すべての新しいURL計画がRFC2396の指定されるとしてのURLのための一般的な構文に従わなければなりません。

3.2 The IETF Tree

3.2 IETF木

   Registration in the IETF tree requires publication of the URL scheme
   syntax and semantics in either an Informational or Standards Track
   RFC. In general, the creation of a new URL scheme requires a
   Standards Track RFC.  An Informational RFC may be employed for
   registration only in the case of a URL scheme which is already in
   wide usage and meets other standards set forth in RFC 2718, such as
   "demonstrated utility" within the Internet Architecture; the IESG
   shall have broad discretion in determining whether an Informational
   RFC is suitable in any given case, and may either recommend changes
   to such document prior to publication, or reject it for publication.
   An Informational RFC purporting to describe a URL scheme shall not be
   published without IESG approval.  This is a departure from practice
   for Informational RFCs as set forth in RFC 2026, for the purpose of
   ensuring that the registration of URL schemes shall serve the best
   interests of the Internet community.

IETF木での登録はInformationalかStandards Track RFCのどちらかのURL計画構文と意味論の公表を必要とします。一般に、新しいURL計画の創造はStandards Track RFCを必要とします。 Informational RFCは広い用法で既にあって、RFC2718に詳しく説明された他の規格を満たすURL計画の場合だけにおける登録に使われるかもしれません、インターネットArchitectureの中の「示されたユーティリティ」などのように。 IESGはInformational RFCが何か与えられた場合で適当であるかどうか決定する際に大幅な自由裁量を持って、公表の前にそのようなドキュメントへの変化を推薦するか、または公表のためにそれを拒絶するかもしれません。 IESG承認なしでURL計画について説明することを意味するInformational RFCを発行しないものとします。これはRFC2026に詳しく説明されるようにInformational RFCsのための習慣からの出発です、URL計画の登録がインターネットコミュニティの利益のために役立つだろうというのを確実にする目的のために。

   The NAMES of schemes registered in the IETF tree MUST NOT contain the
   dash (also known as the hyphen and minus sign) character ('-')
   USASCII value 2Dh.  Use of this character can cause confusion with
   schemes registered in alternative trees (see section 3.3).

IETF木に登録された計画のNAMESはダッシュ(また、ハイフンとマイナス記号として、知られている)キャラクタ('--')USASCII値の2Dhを含んではいけません。このキャラクタの使用は代替の木に登録される計画への混乱を引き起こす場合があります(セクション3.3を見てください)。

   An analysis of the security issues inherent in the new URL scheme is
   REQUIRED. (This is in accordance with the basic requirements for all
   IETF protocols.) URL schemes registered in the IETF tree should not
   introduce additional security risks into the Internet Architecture.
   For example, URLs should not embed information which should remain
   confidential, such as passwords, nor should new schemes subvert the
   security of existing schemes or protocols (i.e. by layering or
   tunneling).

新しいURL計画の固有である安全保障問題の分析はREQUIREDです。 (すべてのIETFプロトコルのための基本的な要件に従って、これはあります。) IETF木に登録されたURL計画はインターネットArchitectureに追加担保危険を紹介するべきではありません。例えば、URLはパスワードなどのように秘密のままで残るべきである情報を埋め込むはずがありません、そして、新しい計画は既存の計画かプロトコル(すなわち、レイヤリングかトンネリングによる)のセキュリティを打倒するべきではありません。

Petke & King             Best Current Practice                  [Page 3]

RFC 2717      Registration Procedures for URL Scheme Names November 1999

PetkeとCurrent最も良い王は1999年11月にURL計画名のためにRFC2717登録手順を練習します[3ページ]。

   The "owner" of a URL scheme name registered in the IETF tree is
   assumed to be the IETF itself.  Modification or alteration of the
   specification requires the same level of processing (e.g.
   Informational or Standards Track RFC) as used for the initial
   registration.  Schemes originally defined via an Informational RFC
   may, however, be replaced with Standards Track documents.

IETF木に登録されたURL計画名の「所有者」はIETF自身であると思われます。仕様の変更か変更が新規登録に使用されるように処理の同じレベルを必要とします(例えば、InformationalかStandards Track RFC)。しかしながら、元々Informational RFCを通して定義された計画をStandards Trackドキュメントに取り替えるかもしれません。

3.3  Alternative Trees

3.3 代替の木

   While public exposure and review of a URL scheme created in an
   alternative tree is not required, using the IETF Internet-Draft
   mechanism for peer review is strongly encouraged to improve the
   quality of the specification.  RFC publication of alternative tree
   URL schemes is encouraged but not required.  Material may be
   published as an Informational RFC by sending it to the RFC Editor
   (please follow the instructions to RFC authors, RFC 2223 [3]).

代替の木で作成されたURL計画の公共の露出とレビューは必要ではありませんが、同輩レビューにIETFインターネット草稿メカニズムを使用すると仕様の品質が改良されるよう強く奨励されます。代替の木のURL計画のRFC公表は、奨励されますが、必要ではありません。材料は、Informational RFCとしてそれをRFC Editorに送ることによって、発行されるかもしれません。(RFC作者(RFC2223[3]))に指示に従ってください。

   The defining document for an alternative tree may require public
   exposure and/or review for schemes defined in that tree via a
   mechanism other than the IETF Internet-Draft mechanism.

代替の木のための定義文書はその木でIETFインターネット草稿メカニズム以外のメカニズムで定義された計画のために公共の露出、そして/または、レビューを必要とするかもしれません。

   URL schemes created in an alternative tree must conform to the
   generic URL syntax, RFC 2396.  The tree's defining document may set
   forth additional syntax and semantics requirements above and beyond
   those specified in RFC 2396.

RFC2396、代替の木で作成されたURL計画は一般的なURL構文に従わなければなりません。木の定義文書はRFC2396で指定されたものを超えて追加構文と意味論要件について詳しく説明するかもしれません。

   All new URL schemes SHOULD follow the Guidelines for URL Schemes, set
   forth in RFC 2718 [2].

すべての新しいURL計画SHOULDがRFC2718[2]に詳しく説明されたURL SchemesのためのGuidelinesに続きます。

   An analysis of the security issues inherent in the new URL scheme is
   encouraged.  Regardless of what security analysis is or is not
   performed, all descriptions of security issues must be as accurate as
   possible.  In particular, a statement that there are "no security
   issues associated with this scheme" must not be confused with "the
   security issues associates with this scheme have not been assessed"
   or "the security issues associated with this scheme cannot be
   predicted because of <reason>".

新しいURL計画の固有である安全保障問題の分析は奨励されます。どんな証券分析があるか、または実行されないかにかかわらず、安全保障問題のすべての記述ができるだけ正確でなければなりません。特に、「この計画に関連している安全保障問題がありません」があるという声明が「この計画の安全保障問題関連は評価されていないこと」に混乱してはいけない、さもなければ、「<理由>のためにこの計画に関連している安全保障問題を予測できません」。

   There is absolutely no requirement that URL schemes created in an
   alternative tree be secure or completely free from risks.
   Nevertheless, the tree's defining document must set forth the
   standard for security considerations, and in any event all known
   security risks SHOULD be identified.

代替の木で作成されたURL計画が安全であるか、または完全に無料であるという要件は全くリスクから絶対に来ていません。それにもかかわらず、定義が記録する木は、セキュリティ問題の規格について詳しく説明しなければならなくて、セキュリティリスクSHOULDが特定されるのをすべてとにかく知っていました。

   Change control must be defined for a new tree.  Change control may be
   vested in the IETF, or in an individual, group or other entity.  The
   change control standard for the tree must be approved by the IESG.

新しい木のために変化コントロールを定義しなければなりません。変化コントロールはIETF、個人、グループまたは他の実体で衣服を着せられるかもしれません。 IESGは木のための変化制御基準を承認しなければなりません。

Petke & King             Best Current Practice                  [Page 4]

RFC 2717      Registration Procedures for URL Scheme Names November 1999

PetkeとCurrent最も良い王は1999年11月にURL計画名のためにRFC2717登録手順を練習します[4ページ]。

   The syntax for alternative trees shall be as follows: each tree will
   be identified by a unique prefix, which must be established in the
   same fashion as a URL scheme name in the IETF tree, except that the
   prefix must be defined by a Standards Track document.  Scheme names
   in the new tree are then constructed by prepending the prefix to an
   identifier unique to each scheme in that tree, as prescribed by that
   tree's identifying document:

代替の木のための構文は以下の通りになるでしょう: 各木はユニークな接頭語によって特定されるでしょう、Standards Trackドキュメントで接頭語を定義しなければならないのを除いて。(IETF木でURL計画名と同じファッションに接頭語を確立しなければなりません)。次に、新しい木の計画名はその木での各計画にユニークな識別子に接頭語をprependingすることによって、構成されます、その木がドキュメントを特定することによって処方されるように:

      <prefix>'-'<tree-specific identifier>

'<接頭語>'--'<木の特有の識別子>'

   For instance, the "foo" tree would allow creation of scheme names of
   the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes
   an arbitrary USASCII string following the tree's unique prefix.

例えば、"foo"木はフォームの計画名の創造を許すでしょう: 「foo-blahblah:」木のユニークな接頭語に従って、木が任意のUSASCIIストリングを定めるところで「以下をfoo禁じます」。

4.0 Registration Procedures

4.0 登録手順

4.1 The IETF Tree

4.1 IETF木

   The first step in registering a new URL scheme in the IETF tree is to
   publish an IETF Internet-Draft detailing the syntax and semantics of
   the proposed scheme.  The draft must, minimally, address all of the
   items covered by the template provided in section 6 of this document.

IETF木に新しいURL計画を登録することにおける第一歩は提案された計画の構文と意味論を詳しく述べながらIETFインターネット草稿を発表することです。草稿はこのドキュメントのセクション6に提供されたテンプレートでカバーされた項目のすべてを最少量で記述しなければなりません。

   After all issues raised during a review period of no less than 4
   weeks have been addressed, submit the draft to the IESG for review.

少なくとも4週間のレビューの期間、提起されたすべての問題を記述してある後に、レビューのためにIESGに草稿を提出してください。

   The IESG will review the proposed new scheme and either refer the
   scheme to a working group (existing or new) or directly present the
   scheme to the IESG for a last call.  In the former case, the working
   group is responsible for submitting a final version of the draft to
   the IESG for approval at such time as it has received adequate review
   and deliberation.

IESGは提案された新しい計画を見直して、ワーキンググループに(既存であるか新しい)で計画を任せるか、または最後の呼び出しのために直接IESGに計画を提示するでしょう。前の場合では、ワーキンググループは適切なレビューと熟考を受け取ったのでそのような時に承認のために草稿の最終版をIESGに提出するのに責任があります。

4.2 Alternative Trees

4.2 代替の木

   Registration of URL schemes created in an alternative tree may be
   formal, through IETF documents, IANA registration, or other
   acknowledged organization; informal, through a mailing list or other
   publication mechanism; or nonexistent.  The registration mechanism
   must be documented for each alternative tree, and must be consistent
   for all URL scheme names created in that tree.

代替の木で作成されたURL計画の登録は正式であるかもしれません、IETFドキュメント、IANA登録、または他の承認された組織で。メーリングリストか他の公表メカニズムを通して非公式。または、実在しません。登録メカニズムは、それぞれの代替の木のために記録しなければならなくて、その木で作成されたすべてのURL計画名において、一貫しているに違いありません。

   It is the responsibility of the creator of the tree's registration
   requirements to establish that the registration mechanism is workable
   as described; it is within the discretion of the IESG to reject the
   document describing a tree if it determines the registration
   mechanism is impractical or creates an undue burden on a party who

それは木の登録要件の創造者が登録メカニズムが説明されるように実行可能であると証明する責任です。登録メカニズムが非実用的であることを決定するか、または不当な負担をパーティーに作成するなら木について説明するドキュメントを拒絶するためにIESGの思慮深さの中にそれがある、だれ

Petke & King             Best Current Practice                  [Page 5]

RFC 2717      Registration Procedures for URL Scheme Names November 1999

PetkeとCurrent最も良い王は1999年11月にURL計画名のためにRFC2717登録手順を練習します[5ページ]。

   will not accept it.  (For instance, if an IANA registration mechanism
   is proposed, IESG might reject the tree if its mechanism would create
   undue liability on the part of IANA.)

それを受け入れないでしょう。 (例えば、IANA登録メカニズムが提案されるなら、メカニズムがIANA側の過度の責任を作成するなら、IESGは木を拒絶するかもしれません。)

   While the template in section 6 of this document is intended to apply
   to URL scheme names in the IETF tree, it is also offered as a
   guideline for those documenting alternative trees.

このドキュメントのセクション6のテンプレートはIETF木のURL計画名に適用されるつもりですが、また、代替の木を記録するもののためにガイドラインとしてそれを提供します。

5.0 Change Control

5.0 変化コントロール

5.1 Schemes in the IETF Tree

5.1 IETF木での計画

   URL schemes created in the IETF tree are "owned" by the IETF itself
   and may be changed, as needed, by updating the RFC that describes
   them.  Schemes described by Standards Track RFC but be replaced with
   new Standards Track RFCs.  Informational RFCs may be replaced by new
   Informational RFCs or Standards Track RFCs.

IETF木で作成されたURL計画を、IETF自身が「所有し」て、変えるかもしれません、必要に応じて、それらについて説明するRFCをアップデートすることによって。 Standards Track RFCによって説明されて、計画しますが、新しいStandards Track RFCsに取り替えます。情報のRFCsを新しいInformational RFCsかStandards Track RFCsに取り替えるかもしれません。

5.2 Schemes in Alternative Trees

5.2 代替の木での計画

   URL schemes in an alternative tree that are undocumented (as allowed
   by that tree's rules) may be changed by their owner at any time
   without notifying the IETF.

IETFに通知しないで、代替の木での正式書類のない(その木の規則で許容されているように)URL計画はいつでも、彼らの所有者によって変えられるかもしれません。

   URL schemes created in an alternative tree that have been documented
   by an Informational RFC, may be changed at any time by the owner,
   however, an updated Informational RFC which details the changes made,
   must be submitted to the IESG.

しかしながら、Informational RFCによって記録されて、いつでも所有者によって変えられるかもしれない代替の木で作成されたURL計画(変化がそれの詳細を作ったアップデートされたInformational RFC)をIESGに提出しなければなりません。

   The owner of a URL scheme registered in an alternative tree and
   documented by an Informational RFC may pass responsibility for the
   registration to another person or agency by informing the IESG.

代替の木に登録されて、Informational RFCによって記録されたURL計画の所有者は、IESGに知らせることによって、別の人か政府機関に登録への責任を渡すかもしれません。

   The IESG may reassign responsibility for a URL scheme registered in
   an alternative tree and documented by an Informational RFC.  The most
   common case of this will be to enable changes to be made to schemes
   where the scheme name is privately owned by the rules of its tree,
   and the owner of the scheme name has died, moved out of contact or is
   otherwise unable to make changes that are important to the community.

IESGは代替の木に登録されて、Informational RFCによって記録されたURL計画への責任を再選任するかもしれません。この最も一般的なケースが計画名が木の規則で個人的に所有されているところで変更を計画にするのを可能にすることであり、有という計画名の所有者は、死ぬか、接触から引っ越すか、またはそうでなければ、共同体に重要な変更を行うことができません。

   The IESG may reclassify a URL scheme created in an alternative tree
   and documented via an Informational RFC as "historic" if it
   determines that the scheme is no longer in use.

IESGは計画がもう使用中でないことを決定するなら、代替の木で作成されて、「歴史的である」としてのInformational RFCを通して記録されたURL計画に分類し直すかもしれません。

Petke & King             Best Current Practice                  [Page 6]

RFC 2717      Registration Procedures for URL Scheme Names November 1999

PetkeとCurrent最も良い王は1999年11月にURL計画名のためにRFC2717登録手順を練習します[6ページ]。

6.0  Registration Template

6.0 登録テンプレート

   The following issues should be addressed when documenting a new URL
   scheme:

新しいURL計画を記録するとき、以下の問題は記述されるべきです:

      URL scheme name.

URL計画名。

      URL scheme syntax.  This should be expressed in a clear and
      concise manner.  The use of ABNF is encouraged.  Please refer to
      RFC 2718 for guidance on designing and explaining your scheme's
      syntax.

URL計画構文。これは明確で簡潔な方法で言い表されるべきです。 ABNFの使用は奨励されます。あなたの計画の構文を設計して、説明するときの指導についてRFC2718を参照してください。

      Character encoding considerations.  It is important to identify
      what your scheme supports in this regard.  It is obvious that for
      interoperability, it is best if there is a means to support
      character sets beyond USASCII, but especially for private schemes,
      this may not be the case.

問題をコード化するキャラクター。あなたの計画がこの点で支持することを特定するのは重要です。相互運用性に、USASCIIを超えて文字の組をサポートする手段があれば最も良いのが、明白ですが、特に個人的な計画のために、これはそうでないかもしれません。

      Intended usage.  What sort of resource is being identified?  If
      this is not a 'resource' type of URL (e.g. mailto:), explain the
      action that should be initiated by the consumer of the URL.  If
      there is a MIME type associated with this resource, please
      identify it.

意図している用法。どういうリソースが特定されていますか? これがURL(例えば、以下をmailtoする)の'リソース'タイプでないなら、URLの消費者によって開始されるべきである動作について説明してください。このリソースに関連しているMIMEの種類があれば、それを特定してください。

      Applications and/or protocols which use this URL scheme name.
      Including references to documentation which defines the
      applications and/or protocols cited is especially useful.

このURL計画名を使用するアプリケーション、そして/または、プロトコル。アプリケーションを定義するドキュメンテーションの参照、そして/または、プロトコルが引用した包含は特に役に立ちます。

      Interoperability considerations.  If you are aware of any details
      regarding your scheme which might impact interoperability, please
      identify them here.  For example: proprietary or uncommon encoding
      method; inability to support multibyte character sets;
      incompatibility with types or versions of underlying protocol (if
      scheme is tunneled over another protocol).

相互運用性問題。何か相互運用性に影響を与えるかもしれないあなたの計画に関する詳細を意識しているなら、ここでそれらを特定してください。例えば: 独占であるか珍しいコード化方法。多バイト文字をサポートできないことはセットします。タイプがある不一致か基本的さバージョンが議定書を作ります(計画が別のプロトコルの上でトンネルを堀られるなら)。

      Security considerations.

セキュリティ問題。

      Relevant publications.

一覧

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

RFC2717 日本語訳

一覧

リンク

メニュー

コメント

お問い合わせ

プライバシーポリシー