[要約] RFC 2718は、新しいURLスキームのためのガイドラインであり、URLスキームの設計と実装に関する指針を提供します。その目的は、新しいURLスキームの一貫性と互換性を確保し、インターネット上のリソースの効果的な利用を促進することです。
Network Working Group L. Masinter
Request for Comments: 2718 Xerox Corporation
Category: Informational H. Alvestrand
Maxware, Pirsenteret
D. Zigmond
WebTV Networks, Inc.
R. Petke
UUNET Technologies
November 1999
Guidelines for new URL Schemes
新しいURLスキームのガイドライン
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. This document provides guidelines for the definition of new URL schemes.
ユニフォームリソースロケーター（URL）は、インターネットを介して利用可能なリソースの場所のコンパクトな文字列表現です。このドキュメントは、新しいURLスキームの定義に関するガイドラインを提供します。
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.
ユニフォームリソースロケーター（URL）は、インターネットを介して利用可能なリソースの場所のコンパクトな文字列表現です。RFC 2396 [1]は、URIの一般的な構文とセマンティクスを定義し、包含によりURLを定義します。URLは、「<scheme>：」を含むことによって指定され、次に「<スキーム固有のパート>」が含まれます。多くのURLスキームがすでに定義されています。
This document provides guidelines for the definition of new URL schemes, for consideration by those who are defining and registering or evaluating those definitions.
このドキュメントは、それらの定義を定義および登録または評価している人々による検討のために、新しいURLスキームの定義に関するガイドラインを提供します。
The process by which new URL schemes are registered is defined in RFC 2717 [2].
新しいURLスキームが登録されるプロセスは、RFC 2717で定義されています[2]。
Because new URL schemes potentially complicate client software, new schemes must have demonstrable utility and operability, as well as compatibility with existing URL schemes. This section elaborates these criteria.
新しいURLスキームは潜在的にクライアントソフトウェアを複雑にする可能性があるため、新しいスキームは、既存のURLスキームとの互換性と同様に、実証可能な有用性と操作性を持つ必要があります。このセクションでは、これらの基準を詳しく説明します。
New URL schemes should follow the same syntactic conventions of existing schemes when appropriate. If a URI scheme that has embedded links in content accessed by that scheme does not share syntax with a different scheme, the same content cannot be served up under different schemes without rewriting the content. This can already be a problem, and with future digital signature schemes, rewriting may not even be possible. Deployment of other schemes in the future could therefore become extremely difficult.
新しいURLスキームは、必要に応じて既存のスキームの同じ構文規則に従う必要があります。そのスキームによってアクセスされたコンテンツにリンクが組み込まれているURIスキームが別のスキームと構文を共有していない場合、コンテンツを書き換えずに同じコンテンツを異なるスキームで提供することはできません。これはすでに問題になる可能性があり、将来のデジタル署名スキームでは、書き換えさえできない場合があります。したがって、将来の他のスキームの展開は非常に困難になる可能性があります。
Why should new URL schemes share as much of the generic URI syntax (that makes sense to share) as possible? Consider the following:
新しいURLスキームが、可能な限り（共有するのが理にかなっている）多くの一般的なURI構文を共有する必要があるのはなぜですか？以下を検討してください。
o If fragment syntax isn't shared between two schemes, (e.g. "<a href="#foo">"), you can't move individual completely self referential documents between schemes without rewriting the embedded references within the document. In the Web, the fragment syntax is a property of the media type, and evaluated by the client.
o フラグメント構文が2つのスキーム間で共有されていない場合（例： "<a href="#foo">"）、ドキュメント内の埋め込み参照を書き換えずに、スキーム間で個人を完全に自己参照ドキュメントに移動することはできません。Webでは、フラグメント構文はメディアタイプのプロパティであり、クライアントによって評価されます。
o If fragment syntax is not shared between different media types of the same capability (e.g. HTML, XML, Word, or image types such as GIF, JPEG, PNG) then you can't have a URI reference that can evolve to superior media types as they become available, or even likely work properly today with content negotiation.
o フラグメント構文が同じ機能の異なるメディアタイプ（例：HTML、XML、単語、またはGIF、JPEG、PNGなどの画像タイプ）間で共有されていない場合、優れたメディアタイプに進化できるURI参照を持つことはできません。それらは利用可能になるか、コンテンツの交渉で今日適切に機能する可能性があります。
o If relative syntax (to the extent of understanding the URI is relative, and what part of the URI string is relative) isn't shared between two schemes, (e.g. "<a href="foo">"), you can't move sets of documents that are internally self referential between schemes without rewriting the embedded URIs.
o 相対的な構文（URIを理解する範囲では相対的であり、URI文字列のどの部分が相対）は2つのスキーム間で共有されていない場合（例： "<a href="foo">"）、できません埋め込まれたURIを書き換えずに、スキーム間で内部的に自己参照されるドキュメントのセットを移動します。
o If the ".." syntax as a path component in relative URI's isn't shared between schemes, you can't easily have sets of document sets and refer to them between schemes without rewriting the embedded references.
o 相対URIのパスコンポーネントとしての「..」構文がスキーム間で共有されていない場合、埋め込まれた参照を書き換えることなく、ドキュメントセットのセットを簡単に参照してスキーム間でそれらを参照することはできません。
o If the "/" syntax (to the extent of understanding that the URI refers to a path relative to the current naming authority, see section 2.1.1) isn't shared, you can't have multiple sets of documents easily be moved up or down in a relative hierarchy of names and share a common set of documents between them, without rewriting the content, shared either in that scheme or between schemes. The best example is a site that has a common set of GIF's, JPEG and PNG images, and you want to reorganize the site changing the depth of a subtree from one depth to another, or from one directory to another where the depth isn't the same.
o 「/」構文（URIが現在の命名権限に対するパスを指すことを理解する程度まで、セクション2.1.1を参照）が共有されていない場合、複数のドキュメントセットを簡単に上げることはできませんまたは、名前の相対的な階層でダウンし、コンテンツを書き換えることなく、そのスキームまたはスキーム間で共有することなく、それらの間の共通のドキュメントセットを共有します。最良の例は、GIF、JPEG、およびPNG画像の共通セットを備えたサイトです。サブツリーの深さをある深さから別のディレクトリに変更するサイトを再編成したい同じ。
o If naming authority syntax (e.g. what comes after "//" in most URL schemes, see section 2.1.1) and relative path syntax is shared, to the extent of understanding that the URI has a naming authority, and what part of the URI string is the naming authority vs. path), isn't shared between two schemes, you can't share identical name spaces and serve them up via different schemes. (The naming authority syntax is a property of the scheme). The fact that HTTP, and FTP have the same syntax, for example, has often been exploited by sites transitioning from ftp archive service to HTTP archive service so that the URL's can be identical between schemes except for the scheme; the same content can be served via two schemes simultaneously.
o 命名機関の構文（例：ほとんどのURLスキームで「//」の後に来るもの、セクション2.1.1を参照）と相対パスの構文が共有されている場合、URIには命名権限があり、URIのどの部分があるかを理解する程度まで共有されます文字列は命名機関とパス）であり、2つのスキーム間で共有されておらず、同一の名前スペースを共有したり、異なるスキームで提供することはできません。（命名機関の構文はスキームのプロパティです）。たとえば、HTTPとFTPが同じ構文を持っているという事実は、FTPアーカイブサービスからHTTPアーカイブサービスに移行するサイトによって悪用されることが多いため、スキームを除くSCHEMの間でURLが同一になるようにします。同じコンテンツを2つのスキームで同時に提供できます。
Contrary to some examples set in past years, the use of double slashes as the first component of the <scheme-specific-part> of a URL is not simply an artistic indicator that what follows is a URL: Double slashes are used ONLY when the syntax of the URL's <scheme-specific-part> contains a hierarchical structure as described in RFC 2396. In URLs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See section 3 of RFC 2396 for more details.) URL schemes which do not contain a conformant hierarchical structure in their <scheme-specific-part> should not use double slashes following the "<scheme>:" string.
過去数年間に設定されたいくつかの例とは反対に、URLの<スキーム固有のパート>の最初のコンポーネントとしての二重スラッシュの使用は、単にURLであるという芸術的指標ではありません。URLの<スキーム固有のパート>の構文には、RFC 2396に記載されている階層構造が含まれています。このようなスキームのURLでは、二重スラッシュの使用は、次のことが命名権限の最上位階層要素であることを示しています。（詳細については、RFC 2396のセクション3を参照してください。）<スキーム固有のパート>にコンフォーマルな階層構造を含めないURLスキームは、「<scheme>：」文字列に続いて二重スラッシュを使用しないでください。
URL schemes should use the generic URL syntax if they are intended to be used with relative URLs. A description of the allowed relative forms should be included in the scheme's definition. Many applications use relative URLs extensively. Specifically,
URLスキームは、相対URLで使用することを意図している場合は、一般的なURL構文を使用する必要があります。許可された相対形式の説明は、スキームの定義に含める必要があります。多くのアプリケーションは、相対的なURLを広範囲に使用しています。具体的には、
o Can the scheme be parsed according to RFC 2396 - for example, if the tokens "//", "/", ";", or "?" are used, do they have the meaning given in RFC 2396?
o スキームは、RFC 2396に従って解析できますか？たとえば、トークン「//」、「/」、「;」、または「？」使用されていますが、RFC 2396に与えられた意味がありますか？
o Does the scheme make sense to use it in relative URLs like those RFC 2396 specifies?
o スキームは、それらのRFC 2396のような相対的なURLでそれを使用することは理にかなっていますか？
o If the scheme syntax is designed to be broken into pieces, does the documentation for the scheme's syntax specify what those pieces are, why it should be broken in this way, and why the breaks aren't where RFC 2396 says that they usually should be?
o スキームの構文が断片に分割されるように設計されている場合、スキームの構文のドキュメントは、それらのピースが何であるか、なぜこのように壊れるべきか、なぜRFC 2396が通常はそうであると言う場所ではない理由を指定します。？
o If the scheme has a hierarchy, does it go left-to-right and with slash separators like RFC 2396?
o スキームに階層がある場合、RFC 2396のようなスラッシュセパレーターを使用して、左から右に進みますか？
It is important that the semantics of the "resource" that a URL "locates" be well defined. This might mean different things depending on the nature of the URL scheme.
「リソース」のセマンティクスが「URL」が「明確に定義されている」という意味が重要です。これは、URLスキームの性質によって異なることを意味する場合があります。
In many cases, new URL schemes are defined as ways to translate other protocols and name spaces into the general framework of URLs. The "ftp" URL scheme translates from the FTP protocol, while the "mid" URL scheme translates from the Message-ID field of messages.
多くの場合、新しいURLスキームは、他のプロトコルと名前スペースをURLの一般的なフレームワークに変換する方法として定義されています。「FTP」URLスキームはFTPプロトコルから翻訳され、「Mid」URLスキームはメッセージのメッセージフィールドから変換されます。
In either case, the description of the mapping must be complete, must describe how characters get encoded or not in URLs, must describe exactly how all legal values of the base standard can be represented using the URL scheme, and exactly which modifiers, alternate forms and other artifacts from the base standards are included or not included. These requirements are elaborated below.
どちらの場合でも、マッピングの説明は完全である必要があり、URLで文字がエンコードされるかどうかを記述する必要があり、Base標準のすべての法的価値をURLスキームを使用して表現する方法、およびどの修飾子、代替フォームを正確に表現するかを記述する必要があります。基本基準からのその他のアーティファクトが含まれているか、含まれていません。これらの要件は以下で詳しく説明されています。
Most new URL schemes are associated with network resources that have one or several network protocols that can access them. The 'ftp', 'news', and 'http' schemes are of this nature. For such schemes, the specification should completely describe how URLs are translated into protocol actions in sufficient detail to make the access of the network resource unambiguous. If an implementation of the URL scheme requires some configuration, the configuration elements must be clearly identified. (For example, the 'news' scheme, if implemented using NTTP, requires configuration of the NTTP server.)
ほとんどの新しいURLスキームは、それらにアクセスできる1つまたは複数のネットワークプロトコルを持つネットワークリソースに関連付けられています。「FTP」、「ニュース」、および「HTTP」スキームは、この性質のものです。このようなスキームの場合、仕様は、URLがプロトコルアクションにどのように変換され、ネットワークリソースのアクセスを明確にするかを完全に説明する必要があります。URLスキームの実装に何らかの構成が必要な場合、構成要素を明確に識別する必要があります。（たとえば、「ニュース」スキームは、NTTPを使用して実装されている場合、NTTPサーバーの構成が必要です。）
In some cases, URL schemes do not have particular network protocols associated with them, because their use is limited to contexts where the access method is understood. This is the case, for example, with the "cid" and "mid" URL schemes. For these URL schemes, the specification should describe the notation of the scheme and a complete mapping of the locator from its source.
場合によっては、URLスキームには、アクセス方法が理解されるコンテキストに制限されるため、URLスキームには特定のネットワークプロトコルが関連付けられていません。これは、たとえば、「CID」および「Mid」URLスキームに当てはまります。これらのURLスキームについては、仕様には、スキームの表記とそのソースからのロケーターの完全なマッピングを説明する必要があります。
Most URL schemes locate Internet resources that correspond to data objects that can be retrieved or modified. This is the case with "ftp" and "http", for example. However, some URL schemes do not; for example, the "mailto" URL scheme corresponds to an Internet mail address.
ほとんどのURLスキームは、取得または変更できるデータオブジェクトに対応するインターネットリソースを見つけます。これは、たとえば「FTP」と「HTTP」の場合です。ただし、一部のURLスキームはそうではありません。たとえば、「MailTo」URLスキームは、インターネットメールアドレスに対応しています。
If a new URL scheme does not locate resources that are data objects, the properties of names in the new space must be clearly defined.
新しいURLスキームがデータオブジェクトであるリソースを見つけられない場合、新しいスペース内の名前のプロパティを明確に定義する必要があります。
When describing URL schemes in which (some of) the elements of the URL are actually representations of sequences of characters, care should be taken not to introduce unnecessary variety in the ways in which characters are encoded into octets and then into URL characters. Unless there is some compelling reason for a particular scheme to do otherwise, translating character sequences into UTF-8 (RFC 2279) [3] and then subsequently using the %HH encoding for unsafe octets is recommended.
URLの要素が実際にキャラクターのシーケンスの表現である（その一部）を説明する場合、キャラクターがオクテットにエンコードされてからURL文字にエンコードされる方法で不必要な多様性を導入しないように注意する必要があります。特定のスキームが別の方法を行うための説得力のある理由がない限り、文字シーケンスをUTF-8（RFC 2279）[3]に変換し、その後、安全でないオクテットの％HHエンコードを使用することをお勧めします。
In some contexts (for example, HTML forms) it is possible to specify any one of a list of operations to be performed on a specific URL. (Outside forms, it is generally assumed to be something you GET.)
一部のコンテキスト（たとえば、HTMLフォーム）では、特定のURLで実行される操作のリストのいずれかを指定することができます。（外側のフォーム、それは一般的にあなたが得るものであると想定されています。）
The URL scheme definition should describe all well-defined operations on the URL identifier, and what they are supposed to do.
URLスキーム定義は、URL識別子のすべての明確に定義された操作と、それらがすべきことを説明する必要があります。
Some URL schemes (for example, "telnet") provide location information for hooking onto bi-directional data streams, and don't fit the "infoaccess" paradigm of most URLs very well; this should be documented.
一部のURLスキーム（たとえば、「Telnet」）は、双方向のデータストリームに接続するための位置情報を提供し、ほとんどのURLの「InfoAccess」パラダイムに非常によく適合しません。これを文書化する必要があります。
NOTE: It is perfectly valid to say that "no operation apart from GET is defined for this URL". It is also valid to say that "there's only one operation defined for this URL, and it's not very GET-like". The important point is that what is defined on this type is described.
注：「このURLについては、GET以外の操作は定義されていない」と言うのは完全に有効です。また、「このURLに対して定義されている操作は1つだけであり、それはあまりgetのようではない」と言うことも有効です。重要な点は、このタイプで定義されているものが説明されていることです。
URL schemes should have demonstrated utility. New URL schemes are expensive things to support. Often they require special code in browsers, proxies, and/or servers. Having a lot of ways to say the same thing needless complicates these programs without adding value to the Internet.
URLスキームは、ユーティリティを実証する必要があります。新しいURLスキームは、サポートする高価なものです。多くの場合、ブラウザ、プロキシ、および/またはサーバーの特別なコードが必要です。同じことを不必要なことを言う方法がたくさんあることは、インターネットに価値を追加することなく、これらのプログラムを複雑にします。
The kinds of things that are useful include:
役立つものの種類は次のとおりです。
o Things that cannot be referred to in any other way.
o 他の方法で言及できないもの。
o Things where it is much easier to get at them using this scheme than (for instance) a proxy gateway.
o プロキシゲートウェイよりも（たとえば）このスキームを使用する方がはるかに簡単なこと。
One way to provide a demonstration of utility is via a gateway which provides objects in the new scheme for clients using an existing protocol. It is much easier to deploy gateways to a new service than it is to deploy browsers that understand the new URL object.
ユーティリティのデモンストレーションを提供する1つの方法は、既存のプロトコルを使用してクライアントに新しいスキームでオブジェクトを提供するゲートウェイを介してです。新しいURLオブジェクトを理解するブラウザーを展開するよりも、ゲートウェイを新しいサービスに展開する方がはるかに簡単です。
Things to look for when thinking about a proxy are:
プロキシについて考えるときに探すべきことは次のとおりです。
o Is there a single global resolution mechanism whereby any proxy can find the referenced object? o If not, is there a way in which the user can find any object of this type, and "run his own proxy"? o Are the operations mappable one-to-one (or possibly using modifiers) to HTTP operations? o Is the type of returned objects well defined? - as MIME content-types? - as something that can be translated to HTML? o Is there running code for a proxy?
o プロキシが参照されるオブジェクトを見つけることができる単一のグローバル解像度メカニズムはありますか？oそうでない場合、ユーザーがこのタイプのオブジェクトを見つけることができ、「自分のプロキシを実行する」方法はありますか？o操作は1対1（または修飾子を使用）にHTTP操作にマップ可能ですか？o返されたオブジェクトのタイプは明確に定義されていますか？ - MIMEコンテンツタイプとして？ - HTMLに翻訳できるものとして？oプロキシ用の実行中のコードはありますか？
Above and beyond the security considerations of the base mechanism a scheme builds upon, one must think of things that can happen in the normal course of URL usage.
スキームが構築する基本メカニズムのセキュリティ上の考慮事項を超えて、通常のURL使用量で起こる可能性のあることを考える必要があります。
In particular:
特に：
o Does the user need to be warned that such a thing is happening without an explicit request (GET for the source of an IMG tag, for instance)? This has implications for the design of a proxy gateway, of course.
o ユーザーは、そのようなことが明示的なリクエストなしで起こっていることを警告する必要がありますか（たとえば、IMGタグのソースを取得）？これは、もちろん、プロキシゲートウェイの設計に影響を与えます。
o Is it possible to fake URLs of this type that point to different things in a dangerous way?
o 危険な方法で異なることを指すこのタイプのURLを偽造することは可能ですか？
o Are there mechanisms for identifying the requester that can be used or need to be used with this mechanism (the From: field in a mailto: URL, or the Kerberos login required for AFS access in the AFS: URL, for instance)?
o このメカニズムで使用できる、または使用する必要がある要求者を識別するメカニズムはありますか（From：field in a Mailto：URL、またはAFSのAFSアクセスに必要なKerberosログイン：URLなど）？
o Does the mechanism contain passwords or other security information that are passed inside the referring document in the clear (as in the "ftp" URL, for instance)?
o メカニズムには、クリアの参照ドキュメント内に渡されるパスワードまたはその他のセキュリティ情報が含まれていますか（たとえば、「FTP」URLのように）？
Any scheme starting with the letters "U" and "R", in particular if it attaches any of the meanings "uniform", "universal" or "unifying" to the first letter, is going to cause intense debate, and generate much heat (but maybe little light).
「u」と「r」という文字から始まるスキームは、特に「均一」という意味のいずれかを添付した場合、最初の文字に「ユニバーサル」または「統一」が激しい議論を引き起こし、多くの熱を生み出すでしょう（しかし、多分小さな光）。
Any such proposal should either make sure that there is a large consensus behind it that it will be the only scheme of its type, or pick another name.
そのような提案は、それがそのタイプの唯一のスキームであるという大きなコンセンサスがその背後にあることを確認するか、別の名前を選択する必要があります。
Some issues that are often raised but are not relevant to new URL schemes include the following.
しばしば提起されますが、新しいURLスキームに関連しないいくつかの問題には、以下が含まれます。
Can all objects in the world that are validly identified by a scheme be accessed by any UA implementing it?
スキームによって有効に識別される世界のすべてのオブジェクトは、それを実装するUAによってアクセスできますか？
Sometimes the answer will be yes and sometimes no; often it will depend on factors (like firewalls or client configuration) not directly related to the scheme itself.
答えはイエスになり、時にはいいえになります。多くの場合、スキーム自体に直接関係しない要因（ファイアウォールやクライアントの構成など）に依存します。
New URL schemes are required to address all security considerations in their definitions.
定義のすべてのセキュリティに関する考慮事項に対処するには、新しいURLスキームが必要です。
[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[1] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[2] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[2] Petke、R。およびI. King、「URLスキーム名の登録手順」、BCP 35、RFC 2717、1999年11月。
[3] Yergeau, F., "UTF-8, A Transformation Format of Unicode and ISO 10646", RFC 2279, January 1998.
[3] Yergeau、F。、「UTF-8、UnicodeおよびISO 10646の変換形式」、RFC 2279、1998年1月。
Larry Masinter Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304
Larry Masinter Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto、CA 94304
URL: http://purl.org/NET/masinter
EMail: masinter@parc.xerox.com
Harald Tveit Alvestrand Maxware, Pirsenteret N-7005 Trondheim NORWAY
Harald Tveit Alvestrand Maxware、Pirsenteret N-7005 Trondheim Norway
Phone: +47 73 54 57 00
EMail: harald.alvestrand@maxware.no
Dan Zigmond WebTV Networks, Inc. 305 Lytton Avenue Palo Alto, CA 94301 USA
Dan Zigmond Webtv Networks、Inc。305 Lytton Avenue Palo Alto、CA 94301 USA
Phone: +1-650-614-6071
EMail: djz@corp.webtv.net
Rich Petke UUNET Technologies 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000
Rich Petke Uunet Technologies 5000 Britton Road P. O. Box 5000 Hilliard、OH 43026-5000
Phone: +1-614-723-4157
Fax: +1-614-723-8407
EMail: rpetke@wcom.net
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。