Network Working Group J. Whitehead
Request for Comments: 4437 U.C. Santa Cruz
Category: Experimental G. Clemm
IBM
J. Reschke, Ed.
greenbytes
March 2006
Web Distributed Authoring and Versioning (WebDAV)
Redirect Reference Resources
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem.
この仕様では、クライアントは、そのデフォルト応答HTTP / 1.1 3XX（リダイレクト）状態コードである基準リソースをHTTPリダイレクトをオーサリングできるようにするWeb分散オーサリングとバージョン管理（WebDAV）の拡張を定義します。リダイレクト参照は、任意のURIを介して間接的に資源不足ターゲットにアクセスすることを可能にリダイレクト参照リソースにマッピングされます。この仕様は、リソースまたは正規表現ベースのリダイレクトの木々の再マッピングに対応していません。リダイレクト参照リソースに関連付けられた整合性の保証はありません。他のメカニズムも、この仕様と同じ機能を実現するために使用することができます。この仕様は、事業者は、この仕組みを使って実験し、問題への最善のアプローチであるかについての経験を開発することができます。
Table of Contents
目次
1. Introduction ....................................................3
2. Notational Conventions ..........................................4
3. Terminology .....................................................4
4. Overview of Redirect Reference Resources ........................5
5. Operations on Redirect Reference Resources ......................6
6. MKREDIRECTREF Method ............................................7
6.1. Example: Creating a Redirect Reference Resource
with MKREDIRECTREF .........................................8
7. UPDATEREDIRECTREF Method ........................................9
7.1. Example: Updating a Redirect Reference Resource with
UPDATEREDIRECTREF .........................................10
8. Operations on Collections That Contain Redirect
Reference Resources ............................................11
8.1. Example: PROPFIND on a Collection with Redirect
Reference .................................................11
8.2. Example: PROPFIND with Apply-To-Redirect-Ref on a
Collection with Redirect Reference Resources ..............13
9. Operations on Targets of Redirect Reference Resources ..........15
10. Relative References in DAV:reftarget ..........................15
10.1. Example: Resolving a Relative Reference in a
Multi-Status Response.....................................16
11. Redirect References to Collections ............................17
12. Headers .......................................................18
12.1. Redirect-Ref Response Header .............................18
12.2. Apply-To-Redirect-Ref Request Header .....................19
13. Redirect Reference Resource Properties ........................19
13.1. DAV:redirect-lifetime (protected) ........................19
13.2. DAV:reftarget (protected) ................................19
14. XML Elements ..................................................19
14.1. redirectref XML Element ..................................19
15. Extensions to the DAV:response XML Element for Multi-Status
Responses .....................................................20
16. Capability Discovery ..........................................20
16.1. Example: Discovery of Support for Redirect
Reference Resources ......................................20
17. Security Considerations .......................................21
17.1. Privacy Concerns .........................................21
17.2. Redirect Loops ...........................................21
17.3. Redirect Reference Resources and Denial of Service .......21
17.4. Revealing Private Locations ..............................22
18. Internationalization Considerations ...........................22
19. IANA Considerations ...........................................22
19.1. HTTP headers .............................................22
19.1.1. Redirect-Ref ......................................22
19.1.2. Apply-To-Redirect-Ref .............................23
20. Contributors ..................................................23
21. Acknowledgements ..............................................23
22. Normative References ..........................................23
This specification extends the Web Distributed Authoring Protocol (WebDAV) to enable clients to create new access paths to existing resources. This capability is useful for several reasons.
この仕様は既存のリソースへの新しいアクセス・パスを作成するには、クライアントを有効にするには、Web分散オーサリングプロトコル（WebDAVを）拡張します。この機能は、いくつかの理由のために有用です。
WebDAV makes it possible to organize HTTP resources into hierarchies, placing them into groupings, known as collections, that are more easily browsed and manipulated than a single flat collection. However, hierarchies require categorization decisions that locate resources at a single location in the hierarchy, a drawback when a resource has multiple valid categories. For example, in a hierarchy of vehicle descriptions containing collections for cars and boats, a description of a combination car/boat vehicle could belong in either collection. Ideally, the description should be accessible from both. Allowing clients to create new URIs that access the existing resource lets them put that resource into multiple collections.
WebDAVは、より簡単に、単一のフラットコレクションより閲覧、操作されているコレクションとして知られているグループ、にそれらを配置し、階層にHTTPリソースを整理することが可能となります。しかし、階層は、リソースが複数の有効なカテゴリを持っている場合、階層内の単一の場所で欠点がリソースを見つけ分類の決定を必要とします。例えば、車やボートのためのコレクションを含む車両記述の階層に、組み合わせの車/ボート車両の説明は、コレクションのいずれかに属している可能性があります。理想的には、説明は両方からアクセスできる必要があります。クライアントは、既存のリソースにアクセスする新しいURIを作成できるようにすると、それらが複数のコレクションにそのリソースを置くことができます。
Hierarchies also make resource sharing more difficult, since resources that have utility across many collections are still forced into a single collection. For example, the mathematics department at one university might create a collection of information on fractals that contains bindings to some local resources, but also provides access to some resources at other universities. For many reasons, it may be undesirable to make physical copies of the shared resources: to conserve disk space, to respect copyright constraints, or to make any changes in the shared resources visible automatically. Being able to create new access paths to existing resources in other collections or even on other unrelated systems is useful for this sort of case.
多くのコレクション全体の有用性を持っているリソースがまだシングルコレクションに強制されるので、階層はまた、リソース共有をより困難にします。例えば、ある大学で数学部門では、いくつかのローカルリソースへのバインディングが含まれているが、他の大学でいくつかのリソースへのアクセスを提供フラクタル上の情報の収集を作成することがあります。ディスクスペースを節約するために、著作権の制約を尊重する、または自動的に表示、共有リソースの変更を行うために：多くの理由から、共有リソースの物理的なコピーを作成するために望ましくないかもしれません。他のコレクションで、あるいは他の無関係なシステム上の既存のリソースへの新しいアクセス・パスを作成できることは、例、この種のために有用です。
The redirect reference resources defined here provide a mechanism for creating alternative access paths to existing resources. A redirect reference resource is a resource in one collection whose purpose is to redirect requests to another resource (its target), possibly in a different collection. In this way, it allows clients to submit requests to the target resource from another collection. It redirects most requests to the target resource using an HTTP status code from the 3xx range (Redirection), thereby providing a form of mediated access to the target resource.
ここで定義されたリダイレクト参照リソースは、既存のリソースへの代替アクセスパスを作成するためのメカニズムを提供します。リダイレクト参照リソースは、目的によっては異なるコレクションに、別のリソース（その標的）に要求をリダイレクトするのコレクション内のリソースです。これにより、クライアントは別のコレクションからターゲットリソースに要求を提出することができます。それによりターゲットリソースに媒介されるアクセスの形式を提供し、3XX範囲（リダイレクション）からHTTPステータスコードを使用して、ターゲットリソースへの最も要求をリダイレクトします。
A redirect reference is a resource with properties but with no body of its own. Properties of a redirect reference resource can contain information such as who created the reference, when, and why. Since redirect reference resources are implemented using HTTP 3xx responses, it generally takes two round trips to submit a request to the intended resource. Redirect references work equally well for local resources and for resources that reside on a different system from the reference.
リダイレクト参照は、特性を有するが、それ自身のない本体のリソースです。リダイレクト参照リソースのプロパティは、このような参照を作成し誰が、いつ、なぜなどの情報を含めることができます。リダイレクト参照リソースは、HTTPの3xx応答を使用して実装されているので、それは一般的に意図されたリソースへの要求を送信するために2件のラウンドトリップを取ります。参照は、ローカルリソースに対する基準とは異なるシステムに常駐するリソースに対して等しく良好に機能するリダイレクト。
The remainder of this document is structured as follows: Section 3 defines terms that will be used throughout the specification. Section 4 provides an overview of redirect reference resources. Section 5 defines the semantics of existing methods when applied to redirect reference resources. Section 6 discusses how to create a redirect reference resource, and Section 7 discusses updating redirect references. Section 8 discusses their semantics when applied to collections that contain redirect reference resources. Sections 9 through 11 discuss several other issues raised by the existence of redirect reference resources. Sections 12 through 15 define the new headers, properties, and XML elements required to support redirect reference resources. Section 16 discusses capability discovery. Sections 17 through 19 present the security, internationalization, and IANA concerns raised by this specification. The remaining sections provide a variety of supporting information.
次のように、この文書の残りの部分は構成されている：第3節では、本明細書を通して使用される用語を定義します。セクション4は、リダイレクト参照リソースの概要を提供します。参照リソースをリダイレクトするために適用される場合部5は、既存の方法のセマンティクスを定義します。第6節では、リダイレクト参照リソースを作成する方法について説明し、第7節について議論を参照のリダイレクト更新します。参照リソースをリダイレクト含むコレクションに適用された場合、セクション8には、その意味を説明します。セクション9〜11リダイレクト参照リソースの存在が提起した他のいくつかの問題について説明します。セクション12〜15は、リダイレクト参照リソースをサポートするために必要な新しいヘッダー、プロパティ、およびXML要素を定義します。第16節は、能力発見を説明します。セクション17〜19は、セキュリティ、国際化、およびこの仕様によって提起IANAの懸念を提示します。残りのセクションは、情報をサポートする多様を提供します。
Since this document describes a set of extensions to the WebDAV Distributed Authoring Protocol [RFC2518], itself an extension to the HTTP/1.1 protocol, the augmented BNF used here to describe protocol elements is exactly the same as described in Section 2.1 of [RFC2616]. Since this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], these rules apply to this document as well.
この文書は、オーサリングプロトコル[RFC2518]、自体HTTP / 1.1プロトコルの拡張分散のWebDAVの拡張セットを記述しているので、拡張BNFは、プロトコル要素を記述するためにここで使用される[RFC2616]のセクション2.1に記載したように正確に同じです。この拡張BNFは[RFC2616]のセクション2.2に提供される基本的なプロダクションルールを使用するので、これらの規則は、同様に、この文書に適用されます。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" [RFC2119]に記載されているように解釈されるべきです。
The terminology used here follows and extends that in the WebDAV Distributed Authoring Protocol specification [RFC2518]. Definitions of the terms resource, Uniform Resource Identifier (URI), and Uniform Resource Locator (URL) are provided in [RFC3986].
ここで使用される用語は、以下とWebDAVでオーサリングプロトコル仕様[RFC2518]を分散することを延びています。用語リソースの定義は、ユニフォームリソース識別子（URI）、およびユニフォームリソースロケータ（URL）は、[RFC3986]に提供されます。
Redirect Reference Resource
参考リソースのリダイレクト
A resource created to redirect all requests made to it, using an HTTP status code from the 3xx range, to a defined target resource.
作成されたリソースは、定義されたターゲットリソースに、3XXの範囲からHTTPステータスコードを使用して、それに対して行われたすべての要求をリダイレクトします。
Non-Reference Resource
非参照リソース
A resource that is not a reference to another resource.
別のリソースへの参照ではありませんリソース。
Target Resource
対象リソース
The resource to which requests are redirected by a redirect reference resource. A target resource can be anything that can be identified by an absolute URI (see [RFC3986], "absolute-URI").
要求がリダイレクト参照リソースによってリダイレクトされたリソース。ターゲットリソースは、絶対URI（「絶対URI」、[RFC3986]を参照）によって同定することができるものとすることができます。
This document uses the terms "precondition", "postcondition", and "protected property" as defined in [RFC3253]. Servers MUST report pre-/postcondition failures as described in Section 1.6 of this document.
[RFC3253]で定義されている。この文書では、「前提条件」、「事後条件」という用語を使用し、「保護されたプロパティ」。このドキュメントのセクション1.6で説明したようにサーバは事前/事後条件の失敗を報告しなければなりません。
For all operations submitted to a redirect reference resource, the default response is a 302 (Found), accompanied by the Redirect-Ref header (defined in Section 12.1, below) and the Location header ([RFC2616], Section 14.30) set to the URI of the target resource. With this information, the client can resubmit the request to the URI of the target resource.
リダイレクト参照リソースに送信されたすべての操作に対して、デフォルトの応答は302（以下、セクション12.1で定義される）リダイレクト-REFヘッダを伴う、（実測値）とLocationヘッダ（[RFC2616]、セクション14.30）は、に設定ターゲット・リソースのURI。この情報を使用して、クライアントがターゲットリソースのURIに要求を再送信することができます。
A redirect reference resource never automatically forwards requests to its target resource. Redirect resources bring the same benefits as links in HTML documents. They can be created and maintained without the involvement or even knowledge of their target resource. This reduces the cost of linking between resources.
リダイレクト参照リソースは、自動的にそのターゲット・リソースへの要求を転送することはありません。リダイレクトのリソースは、HTML文書内のリンクと同じ利益をもたらします。彼らは関与またはそのターゲットリソースのさえ知識なしで作成し、維持することができます。これは、リソース間のリンクのコストを削減します。
If the client is aware that it is operating on a redirect reference resource, it can resolve the reference by retrieving the reference resource's DAV:reftarget property (defined in Section 13.2, below), whose value contains the URI of the target resource. It can then submit requests to the target resource.
（以下、13.2節で定義される）reftargetプロパティ、値がターゲットリソースのURIが含まれています。クライアントは、それがリダイレクト参照リソース上で動作していることを認識している場合、それは参照リソースのDAVを検索することによって、参照を解決することができます。これは、ターゲット・リソースへの要求を提出することができます。
A redirect reference resource is a new type of resource. To distinguish redirect reference resources from non-reference resources, a new value of the DAV:resourcetype property (defined in [RFC2518]), DAV:redirectref, is defined in Section 14.1, below.
リダイレクト参照リソースは、リソースの新しいタイプです。非参照リソースからリダイレクト参照リソースを区別するために、DAVの新しい値：resourcetypeのプロパティが（[RFC2518]で定義される）、DAV：redirectref、以下のセクション14.1で定義されています。
Since a redirect reference resource is a resource, methods can be applied to the reference resource as well as to its target resource.
リダイレクト参照リソースはリソースであるため、この方法は、参照リソースにだけでなく、そのターゲットリソースに適用することができます。
The Apply-To-Redirect-Ref request header (defined in Section 12.2, below) is provided so that referencing-aware clients can control whether an operation is applied to the redirect reference resource or standard HTTP/WebDAV behaviour (redirection with a 3xx status code) should occur. The Apply-To-Redirect-Ref header can be used with most requests to redirect reference resources. This header is particularly useful with PROPFIND, to retrieve the reference resource's own properties.
適用-TO-リダイレクト-REF要求ヘッダ（セクション12.2で定義され、以下）クライアント認識を参照すると、動作が3XX状況にリダイレクト参照リソースまたは標準HTTP / WebDAVの挙動（リダイレクションに適用されるかどうかを制御することができるように設けられています。コード）が発生します。適用-TO-リダイレクト-REFヘッダは、参照リソースをリダイレクトするために、最も要求と共に使用することができます。このヘッダは、参照リソースの独自のプロパティを取得するために、PROPFINDに特に有用です。
Implementation Note: Operations on the target of a redirect reference usually do not affect the redirect reference itself. However, clients should not rely on this behaviour (for instance, some servers may update redirect references as a result of namespace operations on the reference's target).
実装上の注意：リダイレクト参照のターゲットに対する操作は、通常リダイレクト参照自体には影響を与えません。ただし、クライアントが（たとえば、一部のサーバーが参照のターゲットに名前空間操作の結果として、参照をリダイレクト更新する場合があります）、この動作に依存しないでください。
Although non-referencing-aware clients cannot create reference resources, they should be able to submit requests through the reference resources created by reference-aware WebDAV clients. They should be able to follow any references to their targets. To make this possible, a server that receives any request made via a redirect reference resource MUST return a 3xx range (Redirection) status code, unless the request includes an Apply-To-Redirect-Ref header specifying "T". The client and server MUST follow [RFC2616], Section 10.3, but with these additional rules:
非参照対応クライアントは、参照リソースを作成することはできませんが、彼らが参照対応のWebDAVクライアントによって作成された参照のリソースを要求書を提出することができるはずです。彼らは彼らのターゲットへの参照を追跡することができるはずです。リクエストが「T」を指定適用-TO-リダイレクト-REFヘッダが含まれていない限り、これを可能にするために、リダイレクト参照リソースを介して行われた要求を受信したサーバは、3XX範囲（リダイレクト）状態コードを返さなければなりません。クライアントとサーバは、これらの追加のルールと、[RFC2616]、セクション10.3に従う必要があります。
o The Location response header MUST contain a URI (see [RFC3986], Section 3) that identifies the target of the reference resource.
Oロケーション応答ヘッダは、参照リソースのターゲットを識別するURI（[RFC3986]を参照して、第3章）を含まなければなりません。
o The response MUST include the Redirect-Ref header. This header allows reference-aware WebDAV clients to recognize the resource as a reference resource and to understand the reason for the redirection.
Oレスポンスがリダイレクト-REFヘッダを含まなければなりません。このヘッダは、基準対応WebDAVクライアントは、参照リソースとしてリソースを認識するとリダイレクト理由を理解することを可能にします。
A reference-aware WebDAV client can, like a non-referencing client, resubmit the request to the URI in the Location header in order to operate on the target resource. Alternatively, it can resubmit the request to the URI of the redirect reference resource with the "Apply-To-Redirect-Ref: T" header in order to operate on the reference resource itself. In this case, the request MUST be applied to the reference resource itself, and a 3xx response MUST NOT be returned.
参照対応WebDAVクライアントは、非参照クライアントのような、ターゲットリソース上で動作するためにLocationヘッダにURIに要求を再送信することができます。参照リソース自体上で動作するために、ヘッダ：あるいは、「T適用-TO-リダイレクト-REF」のリダイレクト参照リソースのURIに要求を再送信することができます。この場合、要求は、参照リソース自体に適用されなければならない、と3xx応答を返してはいけません。
As redirect references do not have bodies, GET and PUT requests with "Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden).
リダイレクトとしての参照は、ボディを持ってGETし、「適用-TO-リダイレクト-REF：Tは」とのリクエスト入れていない状態403（禁じられた）で失敗しなければなりませんが。
The MKREDIRECTREF method requests the creation of a redirect reference resource.
MKREDIRECTREF方法は、リダイレクト参照リソースの作成を依頼します。
If a MKREDIRECTREF request fails, the server state preceding the request MUST be restored.
MKREDIRECTREF要求が失敗した場合は、リクエストの前にサーバの状態を復元する必要があります。
Responses from a MKREDIRECTREF request MUST NOT be cached, as MKREDIRECTREF has non-idempotent and non-safe semantics (see [RFC2616], Section 9.1).
MKREDIRECTREFは（[RFC2616]、セクション9.1を参照）非冪等と非安全な意味を持っているようMKREDIRECTREF要求からの応答は、キャッシュされてはなりません。
Marshalling
マーシャリング
The request body MUST be a DAV:mkredirectref XML element.
mkredirectref XML要素：リクエストボディは、DAVでなければなりません。
<!ELEMENT mkredirectref (reftarget, redirect-lifetime?)> <!ELEMENT reftarget (href)> <!ELEMENT redirect-lifetime (permanent | temporary)> <!ELEMENT permanent EMPTY> <!ELEMENT temporary EMPTY>
<！ELEMENTのmkredirectref（？reftarget、リダイレクト-寿命を）> <！ELEMENTのreftarget（HREF）> <ELEMENTリダイレクト-寿命（永久|一時的な）！> <！ELEMENT永久EMPTY> <！ELEMENT一時的EMPTY>
The DAV:href element is defined in [RFC2518] (Section 12.3) and MUST contain either a URI or a relative-ref (see [RFC3986], Sections 3 and 4.2).
DAV：HREF要素は[RFC2518]（セクション12.3）で定義され、URIまたは相対-REF（[RFC3986]を参照し、セクション3および4.2）のいずれかを含まなければなりません。
If no DAV:redirect-lifetime element is specified, the server MUST behave as if a value of DAV:temporary was specified.
何DAV場合：一時的に指定されました：リダイレクト一生の要素が指定されていないDAVの値があるかのように、サーバが動作しますしなければなりません。
If the request succeeds, the server MUST return 201 (Created) status.
リクエストが成功した場合、サーバは201（作成された）状態を返さなければなりません。
If a response body for a successful request is included, it MUST be a DAV:mkredirectref-response XML element. Note that this document does not define any elements for the MKREDIRECTREF response body, but the DAV:mkredirectref-response element is defined to ensure interoperability between future extensions that do define elements for the response body.
成功した要求に対するレスポンスボディが含まれている場合は、DAVでなければならない：mkredirectref応答XML要素。この文書はMKREDIRECTREFレスポンスボディのための任意の要素を定義していないことに注意してください、しかし、DAV：mkredirectref応答要素はレスポンスボディのための要素を定義行い、将来の拡張の間の相互運用性を確保するために定義されています。
<!ELEMENT mkredirectref-response ANY>
<！ELEMENTのmkredirectref応答ANY>
Preconditions
前提条件
(DAV:resource-must-be-null): A resource MUST NOT exist at the Request-URI.
（DAV：リソースは-でなければならないヌル）：リソースは、Request-URIに存在してはなりません。
(DAV:parent-resource-must-be-non-null): The Request-URI minus the last past segment MUST identify a collection.
（DAV：親リソース-でなければならない非ヌル）：要求URIマイナス最後の過去のセグメントは、コレクションを特定しなければなりません。
(DAV:name-allowed): The last segment of the Request-URI is available for use as a resource name.
（DAV：名可）：のRequest-URIの最後のセグメントは、リソース名として使用可能です。
(DAV:locked-update-allowed): If the collection identified by the Request-URI minus the last path segment is write-locked, then the appropriate token MUST be specified in an If request header.
（DAV：ロック更新可）：のRequest-URIによって識別されるコレクションマイナス最後のパスセグメントが書き込みロックされている場合、次いで適切なトークンがあれば要求ヘッダーで指定されなければなりません。
(DAV:redirect-lifetime-supported): If the request body contains a DAV:redirect-lifetime element, the server MUST support the specified lifetime. Support for DAV:temporary is REQUIRED, while support for DAV:permanent is OPTIONAL.
（DAV：リダイレクト-生涯サポート）：リクエストボディがDAV含まれている場合：リダイレクト-寿命を要素を、サーバーは、指定された寿命をサポートしなければなりません。恒久的なオプションです。DAVのサポート：DAVのサポートはしながら、一時的には、必要になります。
(DAV:legal-reftarget): The specified is a legal URI or relative-ref.
（DAV：リーガルreftarget）：指定された法的URIまたは相対-REF。
Postconditions
事後条件
(DAV:new-redirectref): a new redirect reference resource is created whose DAV:reftarget property has the value specified in the request body.
（DAV：新redirectref）：新しいリダイレクト参照リソースは、そのDAV作成され：reftargetプロパティは、要求本体に指定された値を有しています。
>> Request:
>>リクエスト：
MKREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 Host: www.example.com Content-Type: text/xml; charset="utf-8" Content-Length: xxx
MKREDIRECTREF /~whitehead/dav/spec08.ref HTTP / 1.1ホスト：www.example.comのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX
<?xml version="1.0" encoding="utf-8" ?> <D:mkredirectref xmlns:D="DAV:"> <D:reftarget> <D:href>/i-d/draft-webdav-protocol-08.txt</D:href> </D:reftarget> </D:mkredirectref>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：mkredirectrefのxmlns：D = "DAV："> <D：reftarget> <D：hrefが> / ID /ドラフトのWebDAVプロトコル-08 .txtファイル</ D：HREF> </ D：reftarget> </ D：mkredirectref>
>> Response:
>>回答：
HTTP/1.1 201 Created
作成されたHTTP / 1.1 201
This request resulted in the creation of a new redirect reference resource at http://www.example.com/~whitehead/dav/spec08.ref, which points to the resource identified by the DAV:reftarget property. In this example, the target resource is identified by the URI http://www.example.com/i-d/draft-webdav-protocol-08.txt. The redirect reference resource's DAV:resourcetype property is set to DAV:redirectref, and its DAV:redirect-lifetime property has the value DAV:temporary.
reftargetプロパティ：この要求は、DAVで識別されるリソースを指すhttp://www.example.com/~whitehead/dav/spec08.refで新しいリダイレクト参照リソースの作成をもたらしました。この例では、ターゲットリソースは、URI http://www.example.com/i-d/draft-webdav-protocol-08.txtによって識別されます。リダイレクト参照リソースのDAV：resourcetypeのプロパティはDAVに設定されています：redirectref、及びそのDAV：リダイレクト-寿命特性は、値DAVがあります：一時的。
The UPDATEREDIRECTREF method requests the update of a redirect reference resource.
UPDATEREDIRECTREF方法は、リダイレクト参照リソースの更新を要求します。
If a UPDATEREDIRECTREF request fails, the server state preceding the request MUST be restored.
UPDATEREDIRECTREF要求が失敗した場合は、リクエストの前にサーバの状態を復元する必要があります。
Responses from a UPDATEREDIRECTREF request MUST NOT be cached, as UPDATEREDIRECTREF has non-safe semantics (see [RFC2616], Section 9.1).
UPDATEREDIRECTREFが非安全なセマンティクス（[RFC2616]、セクション9.1を参照）を持っているようUPDATEREDIRECTREF要求からの応答は、キャッシュされてはなりません。
Marshalling
マーシャリング
The request body MUST be a DAV:updateredirectref XML element.
XML要素updateredirectref：リクエストボディは、DAVでなければなりません。
<!ELEMENT updateredirectref (reftarget?, redirect-lifetime?)>
<！ELEMENT（reftarget ?,リダイレクト-寿命を？）updateredirectref>
See Section 6 for a definition of DAV:reftarget and DAV:redirect-lifetime.
DAVの定義については、第6章を参照してください：reftargetとDAV：リダイレクト-寿命。
If no DAV:reftarget element is specified, the server MUST NOT change the target of the redirect reference.
何DAV場合：reftarget要素が指定されていない、サーバーは、リダイレクト参照のターゲットを変更しないでください。
If no DAV:redirect-lifetime element is specified, the server MUST NOT change the lifetime of the redirect reference.
何DAV場合：リダイレクト一生の要素が指定されていない、サーバーは、リダイレクトリファレンスの存続期間を変更しないでください。
If a response body for a successful request is included, it MUST be a DAV:updateredirectref-response XML element. Note that this document does not define any elements for the UPDATEREDIRECTREF response body, but the DAV:updateredirectref-response element is defined to ensure interoperability between future extensions that do define elements for the response body.
成功した要求に対するレスポンスボディが含まれている場合は、DAVでなければならない：updateredirectref応答XML要素。この文書はUPDATEREDIRECTREFレスポンスボディのための任意の要素を定義していないことに注意してください、しかし、DAV：updateredirectref応答要素はレスポンスボディのための要素を定義行い、将来の拡張の間の相互運用性を確保するために定義されています。
<!ELEMENT updateredirectref-response ANY>
<！ELEMENT updateredirectref応答ANY>
Preconditions
前提条件
(DAV:locked-update-allowed): if the resource is write-locked, then the appropriate token MUST be specified in an If request header.
（DAV：ロック更新可）：リソースが書き込みロックされている場合、適切なトークンがあれば要求ヘッダーで指定されなければなりません。
(DAV:must-be-redirectref): the resource identified by the Request-URI must be a redirect reference resource as defined by this specification.
（DAV：-でなければならない-redirectref）：本明細書で定義されるようRequest-URIによって識別されるリソースは、リダイレクト参照リソースでなければなりません。
(DAV:redirect-lifetime-supported): see Section 6.
（DAV：リダイレクト寿命サポート）：セクション6を参照。
(DAV:redirect-lifetime-update-supported): servers MAY support changing the DAV:redirect-lifetime property; if they don't, this condition code can be used to signal failure.
（DAV：リダイレクト-一生更新サポート）：サーバーは、DAVの変更をサポート可能性がありますリダイレクト-寿命特性を、そうでない場合は、この条件コードが失敗を知らせるために使用することができます。
(DAV:legal-reftarget): see Section 6.
（DAV：リーガルreftarget）：第6節を参照してください。
Postconditions
事後条件
(DAV:redirectref-updated): the DAV:reftarget and DAV:redirect-lifetime properties of the redirect reference have been updated accordingly.
（DAV：redirectref更新）：DAV：reftargetおよびDAV：リダイレクト参照のリダイレクト-寿命特性がそれに応じて更新されています。
7.1. Example: Updating a Redirect Reference Resource with UPDATEREDIRECTREF
7.1. 例：UPDATEREDIRECTREFのRedirectリファレンスリソースの更新
>> Request:
>>リクエスト：
UPDATEREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 Host: www.example.com Apply-To-Redirect-Ref: T Content-Type: text/xml; charset="utf-8" Content-Length: xxx
UPDATEREDIRECTREF /~whitehead/dav/spec08.ref HTTP / 1.1ホスト：www.example.comは適用-TO-リダイレクト-REF：Tのコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX
<?xml version="1.0" encoding="utf-8" ?> <D:updateredirectref xmlns:D="DAV:"> <D:reftarget> <D:href>/i-d/draft-webdav-protocol-08b.txt</D:href> </D:reftarget> </D:updateredirectref>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のxmlns updateredirectref：D = "DAV："> <D：reftarget> <D：HREF> / ID /ドラフトのWebDAVプロトコル-08B .txtファイル</ D：HREF> </ D：reftarget> </ D：updateredirectref>
>> Response:
>>回答：
HTTP/1.1 200 OK
HTTP / 1.1 200 OK
This request has updated the redirect reference's DAV:reftarget property to "/i-d/draft-webdav-protocol-08b.txt" and has not changed the DAV:redirect-lifetime value. Note that the "Apply-To-Redirect-
「/i-d/draft-webdav-protocol-08b.txt」reftargetプロパティおよびDAV変更されていません：この要求は、リダイレクトリファレンスのDAVを更新したリダイレクト・生涯価値を。なお、「適用-TO-Redirect-
Ref" request header must be used; otherwise, the request would result in a redirect (3xx) response status.
REF」リクエストヘッダを使用する必要があり、そうでない場合、要求はリダイレクト（3XX）応答状態をもたらすであろう。
According to [RFC2518], Section 9.2, methods that have defined interactions with the "Depth" request header should apply all other request headers to each resource in scope. However, applying this principle to the "Apply-To-Redirect-Ref" header uniformly would make it impractical to implement this specification on top of existing servers and also would result in unexpected server behaviour for clients that do not take the existence of redirect references into account. On the other hand, the definition of the "Depth" header allows alternate behaviours to be explicitly defined.
[RFC2518]、セクション9.2によれば、「深さ」要求ヘッダとの相互作用を定義した方法は、範囲内の各リソースに他のすべてのリクエストヘッダを適用すべきです。しかし、「適用-TO-リダイレクト-REF」ヘッダ均一に、それは非現実的で、既存のサーバの上にこの仕様を実装することになるだろうともリダイレクト参照の存在を取らないクライアントのために予期しないサーバーの動作につながるにこの原則を適用しますアカウントに。一方、「深さ」ヘッダの定義は、代替行動が明示的に定義されることを可能にします。
For this reason, this specification defines the interaction between "Depth" and "Apply-To-Redirect-Ref" request headers on a case-by-case basis and also provides a default for methods not mentioned here that do not specify the behaviour themselves.
このため、この仕様は、「深さ」と、ケースバイケースで、リクエストヘッダ「TO-リダイレクト-REF-適用」とも行動自体を指定していない、ここで言及されていないメソッドのデフォルトを提供間の相互作用を定義します。
+-------------+-----------------+------------------+-----------+
| method name | defined in | supported depths | behaviour |
+-------------+-----------------+------------------+-----------+
| COPY | [RFC2518], 8.9 | 0, infinity | "T" |
| DELETE | [RFC2518], 8.7 | infinity | "T" |
| LOCK | [RFC2518], 8.11 | 0, infinity | "T" |
| MOVE | [RFC2518], 8.10 | 0, infinity | "T" |
| PROPFIND | [RFC2518], 8.2 | 0, 1, infinity | inherit |
| REPORT | [RFC3253], 3.6 | 0, 1, infinity | inherit |
| default | | | "T" |
+-------------+-----------------+------------------+-----------+
When the behaviour is defined to be "inherit", the method should follow RFC2518's default behaviour for "Depth" operations, which means applying the value given for "Apply-To-Redirect-Ref" to each resource in scope. On the other hand, when it is defined to be "T", the method should behave as if a "Apply-To-Redirect-Ref: T" header was specified for each operation on child resources. The latter ensures that "Depth: infinity" operations will not fail unexpectedly just because there was a redirect reference resource in scope.
行動は「継承」になるように定義されている場合、この方法は、「適用-TO-リダイレクト-REF」スコープ内の各リソースにするために与えられた値を適用することを意味する、「深さ」の操作のためのRFC2518のデフォルトの動作に従ってください。それは「T」であると定義されている場合一方、この方法は振る舞うべきであるかのように「適用-TO-リダイレクト-REF：T」ヘッダは子リソース上の操作ごとに指定されました。スコープでのリダイレクト参照リソースがあったという理由だけで操作が予期せず失敗することはありません。後者は「無限の深さ」があることを保証します。
8.1. Example: PROPFIND on a Collection with Redirect Reference Resources
8.1. 例：リダイレクト参考資料とコレクションのPROPFIND
Suppose a PROPFIND request with Depth: infinity is submitted to the following collection, with the members shown here:
深さのPROPFIND要求を仮定：無限大はここに示した部材と、次のコレクションに提出されています。
/MyCollection/ (non-reference resource) diary.html (redirect reference resource) nunavut
/ MyCollection /（非参照リソース）diary.html（参照リソースをリダイレクト）ヌナブト
>> Request:
>>リクエスト：
PROPFIND /MyCollection/ HTTP/1.1 Host: example.com Depth: infinity Apply-To-Redirect-Ref: F Content-Type: text/xml Content-Length: xxxx
PROPFIND / MyCollection / HTTP / 1.1ホスト：example.com深さ：無限の適用-TO-リダイレクト-REF：Fのコンテンツタイプ：text / xmlでのコンテンツの長さ：XXXX
<?xml version="1.0" ?> <D:propfind xmlns:D="DAV: "> <D:prop xmlns:J="http://example.com/jsprops/"> <D:resourcetype/> <J:keywords/> </D:prop> </D:propfind>
<？xml version = "1.0"？> <D：PROPFINDのxmlns：D = "DAV： "> <D：のxmlns小道具：J =" http://example.com/jsprops/"> <D：resourcetypeの/> <J：キーワード/> </ D：プロップ> </ D：PROPFIND>
>> Response:
>>回答：
HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlでのコンテンツの長さ：XXXX
<?xml version="1.0" ?> <D:multistatus xmlns:D="DAV:" xmlns:J="http://example.com/jsprops/"> <D:response> <D:href>/MyCollection/</D:href> <D:propstat> <D:prop> <D:resourcetype><D:collection/></D:resourcetype> <J:keywords>diary, interests, hobbies</J:keywords> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/MyCollection/diary.html</D:href> <D:propstat> <D:prop> <D:resourcetype/> <J:keywords>diary, travel, family, history</J:keywords> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat>
<？xml version = "1.0"？> <D：multistatusのxmlns：D = "DAV：" のxmlns：J = "http://example.com/jsprops/"> <D：レスポンス> <D：HREF> / MyCollection / </ D：のhref> <D：propstat> <D：小道具> <D：resourcetypeの> <D：コレクション/> </ D：resourcetypeの> <J：キーワード>日記、興味、趣味</ J：キーワード> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> <D：レスポンス> <D：HREF> / MyCollection /日記。 HTMLの</ D：のhref> <D：propstat> <D：小道具> <D：resourcetypeの/> <J：キーワード>日記、旅行、家族、歴史</ J：キーワード> </ D：小道具> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat>
</D:response> <D:response> <D:href>/MyCollection/nunavut</D:href> <D:status>HTTP/1.1 302 Found</D:status> <D:location> <D:href>http://example.ca/art/inuit/</D:href> </D:location> </D:response> </D:multistatus>
</ D：レスポンス> <D：レスポンス> <D：HREF> / MyCollection /ヌナブット</ D：HREF> <D：ステータス> HTTP / 1.1 302実測</ D：状態> <D：場所> <D： HREF> http://example.ca/art/inuit/ </ D：HREF> </ D：場所> </ D：レスポンス> </ D：multistatus>
In this example, the Depth header is set to infinity, and the Apply-To-Redirect-Ref header is set to "F". The collection contains one URI that identifies a redirect reference resource. The response element for the redirect reference resource has a status of 302 (Found) and includes a DAV:location extension element to allow clients to retrieve the properties of its target resource. (The response element for the redirect reference resource does not include the requested properties. The client can submit another PROPFIND request to the URI in the DAV:location pseudo-property to retrieve those properties.)
この例では、奥行きヘッダは無限大に設定され、適用-TO-リダイレクト-REFヘッダが「F」に設定されています。コレクションは、リダイレクト参照リソースを特定する1つのURIが含まれています。リダイレクト参照リソースの応答要素（実測値）302の状態を有し、DAVを含む：場所拡張要素は、クライアントがそのターゲット・リソースのプロパティを取得することを可能にします。 （リダイレクトリファレンスリソースの応答要素は、要求された特性を備えていないクライアントは、DAVでURIに別のPROPFIND要求を送信することができる：これらのプロパティを取得する位置疑似性）
8.2. Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with Redirect Reference Resources
8.2. 例：PROPFINDと適用-TO-リダイレクト-REFリダイレクトリファレンスリソースとコレクションに
Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth: infinity is submitted to the following collection, with the members shown here:
と深さ：無限大は、次のコレクションに提出され、ここに示した部材と：「Tの適用-TO-リダイレクト-REF」とPROPFIND要求を仮定します。
/MyCollection/ (non-reference resource) diary.html (redirect reference resource) nunavut
/ MyCollection /（非参照リソース）diary.html（参照リソースをリダイレクト）ヌナブト
>> Request:
>>リクエスト：
PROPFIND /MyCollection/ HTTP/1.1 Host: example.com Depth: infinity Apply-To-Redirect-Ref: T Content-Type: text/xml Content-Length: xxxx
PROPFIND / MyCollection / HTTP / 1.1ホスト：example.com深さ：無限大に-リダイレクト-REF-適用：Tのコンテンツタイプ：テキスト/ XMLコンテンツ-長さ：XXXX
<?xml version="1.0" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:resourcetype/> <D:reftarget/> <D:redirect-lifetime/> </D:prop> </D:propfind>
<？xml version = "1.0"？> <D：PROPFINDのxmlns：D = "DAV："> <D：プロペラ> <D：resourcetypeの/> <D：reftarget /> <D：リダイレクト寿命/> </ D：小道具> </ D：PROPFIND>
>> Response:
>>回答：
HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlでのコンテンツの長さ：XXXX
<?xml version="1.0" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>/MyCollection/</D:href> <D:propstat> <D:prop> <D:resourcetype><D:collection/></D:resourcetype> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> <D:propstat> <D:prop> <D:reftarget/> <D:redirect-lifetime/> </D:prop> <D:status>HTTP/1.1 404 Not Found</D:status> </D:propstat> </D:response> <D:response> <D:href>/MyCollection/diary.html</D:href> <D:propstat> <D:prop> <D:resourcetype/> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> <D:propstat> <D:prop> <D:reftarget/> <D:redirect-lifetime/> </D:prop> <D:status>HTTP/1.1 404 Not Found</D:status> </D:propstat>
<？xml version = "1.0"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> / MyCollection / </ D：HREF> <D：propstat> <D：小道具> <D：resourcetypeの> <D：コレクション/> </ D：resourcetypeの> </ D：小道具> <D：状態> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> <D： propstat> <D：プロペラ> <D：reftarget /> <D：リダイレクト-寿命/> </ D：プロペラ> <D：ステータス> HTTP / 1.1 404見つかりません</ D：状態> </ D：propstat> </ D：レスポンス> <D：レスポンス> <D：HREF> /MyCollection/diary.html </ D：HREF> <D：propstat> <D：プロペラ> <D：resourcetypeの/> </ D：小道具> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> <D：propstat> <D：プロペラ> <D：reftarget /> <D：リダイレクト寿命/> </ D：小道具> <D：状態> HTTP / 1.1 404見つかりませんでした。</ D：状態> </ D：propstat>
</D:response> <D:response> <D:href>/MyCollection/nunavut</D:href> <D:propstat> <D:prop> <D:resourcetype><D:redirectref/></D:resourcetype> <D:reftarget> <D:href>http://example.ca/art/inuit/</D:href> </D:reftarget> <D:redirect-lifetime><D:temporary/></D:redirect-lifetime> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
</ D：レスポンス> <D：レスポンス> <D：HREF> / MyCollection /ヌナブット</ D：HREF> <D：propstat> <D：プロペラ> <D：resourcetypeの> <D：redirectref /> </ D ：resourcetypeの> <D：reftarget> <D：HREF> http://example.ca/art/inuit/ </ D：HREF> </ D：reftarget> <D：リダイレクト寿命> <D：一時/> </ D：リダイレクト寿命> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ D：multistatus>
Since the "Apply-To-Redirect-Ref: T" header is present, the response shows the properties of the redirect reference resource in the collection rather than reporting a 302 status.
以降「適用-TO-リダイレクト-REF：T」ヘッダが存在し、応答がコレクション内のリダイレクト参照リソースの特性を示すのではなく302件のステータスを報告します。
Operations on targets of redirect reference resources have no effect on the reference resource.
リダイレクト参照リソースのターゲットに対する操作は、参照リソースに影響を与えません。
The URI in the href in a DAV:reftarget property MAY be a relative reference. In this case, the base URI to be used for resolving it to absolute form is the URI used in the HTTP message to identify the redirect reference resource to which the DAV:reftarget property belongs.
DAVのhrefにURI：reftargetプロパティは、相対参照であるかもしれ。この場合には、絶対形式にそれを解決するために使用されるベースURIは、URIはDAVたリダイレクト参照リソースを識別するために、HTTPメッセージで使用されている：reftargetプロパティが属します。
When DAV:reftarget appears in the context of a Multi-Status response, it is in a DAV:response element that contains a single DAV:href element. The value of this DAV:href element serves as the base URI for resolving a relative reference in DAV:reftarget. The value of DAV:href may itself be relative, in which case it must be resolved first in order to serve as the base URI for the relative reference in DAV:reftarget. If the DAV:href element is relative, its base URI is constructed from the scheme component "http", the value of the Host header in the request, and the Request-URI.
DAVする場合：単一DAVを含む応答エレメント：hrefの要素reftargetマルチステータス応答のコンテキストで表示され、それがDAVです。このDAVの値：reftarget：HREF要素は、DAVの相対参照を解決するためのベースURIとして機能します。 DAVの値：HREF自体は相対的であってもよく、それはDAVの相対参照のベースURIとして機能するために、最初に解決されなければならない場合には：reftarget。 DAV場合：HREF要素は相対的なものである、そのベースURIは、「HTTP」スキームの構成要素から構成され、要求にホストヘッダの値、及びリクエストURI。
10.1. Example: Resolving a Relative Reference in a Multi-Status Response
10.1. 例：マルチステータス応答で相対参照を解決
>> Request:
>>リクエスト：
PROPFIND /geog/ HTTP/1.1 Host: example.com Apply-To-Redirect-Ref: T Depth: 1 Content-Type: text/xml Content-Length: nnn
PROPFIND / geog / HTTP / 1.1ホスト：example.comが適用-TO-リダイレクト-REF：Tの深さ：1つのContent-Type：text / xmlでのコンテンツ長：NNNを
<?xml version="1.0" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:resourcetype/> <D:reftarget/> </D:prop> </D:propfind>
<？xml version = "1.0"？> <D：PROPFINDのxmlns：D = "DAV："> <D：プロペラ> <D：resourcetypeの/> <D：reftarget /> </ D：プロップ> </ D： PROPFIND>
>> Response:
>>回答：
HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: nnn
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlでのコンテンツの長さ：NNN
<?xml version="1/0" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>/geog/</D:href> <D:propstat> <D:prop> <D:resourcetype><D:collection/></D:resourcetype> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> <D:propstat> <D:prop><D:reftarget/></D:prop> <D:status>HTTP/1.1 404 Not Found</D:status> </D:propstat> </D:response> <D:response> <D:href>/geog/stats.html</D:href> <D:propstat> <D:prop> <D:resourcetype><D:redirectref/></D:resourcetype> <D:reftarget> <D:href>statistics/population/1997.html</D:href>
<？xml version = "1/0"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> / geog / </ D：HREF> <D：propstat> < D：小道具> <D：resourcetypeの> <D：コレクション/> </ D：resourcetypeの> </ D：小道具> <D：状態> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> < D：propstat> <D：小道具> <D：reftarget /> </ D：小道具> <D：状態> HTTP / 1.1 404が見つかりません</ D：状態> </ D：propstat> </ D：応答> <D：レスポンス> <D：HREF> /geog/stats.html </ D：HREF> <D：propstat> <D：プロペラ> <D：resourcetypeの> <D：redirectref /> </ D：resourcetypeの> < D：reftarget> <D：HREF>統計/人口/ 1997.html </ D：のhref>
</D:reftarget> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
</ D：reftarget> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ D：multistatus>
In this example, the relative reference "statistics/population/1997.html" is returned as the value of the DAV:reftarget property for the reference resource identified by href /geog/stats.html. The href is itself a relative reference, which resolves to http://example.com/geog/stats.html. This is the base URI for resolving the relative reference in reftarget. The absolute URI of reftarget is http://example.com/geog/statistics/population/1997.html.
HREF /geog/stats.htmlによって識別基準リソースのreftarget性：この例では、相対的な基準「統計/人口/ 1997.html」はDAVの値として返されます。 HREFはhttp://example.com/geog/stats.htmlに解決相対参照、それ自体です。これはreftargetの相対参照を解決するためのベースURIです。 reftargetの絶対URIはhttp://example.com/geog/statistics/population/1997.htmlです。
In a Request-URI /segment1/segment2/segment3, any of the three segments may identify a redirect reference resource. (See [RFC3986], Section 3.3, for definitions of "path" and "segment".) If any segment in a Request-URI identifies a redirect reference resource, the response SHOULD be a 3xx. The value of the Location header in the response is as follows:
リクエストURI /セグメント1 / SEGMENT2 / segment3では、三つのセグメントのいずれかがリダイレクト参照リソースを識別することができます。 （「パス」と「セグメント」の定義については、セクション3.3、[RFC3986]を参照。）のRequest-URI内の任意のセグメントは、リダイレクト参照リソースを識別する場合、応答は3XXであるべきです。次のように応答しLocationヘッダの値です。
The leftmost path segment of the Request-URI that identifies a redirect reference resource, together with all path segments and separators to the left of it, is replaced by the value of the redirect reference resource's DAV:reftarget property (resolved to an absolute URI). The remainder of the Request-URI is concatenated to this path.
（絶対URIに解決）reftarget性：それの左側のすべてのパスセグメントとセパレータと一緒に、リダイレクト参照リソースを識別するリクエストURIの左端のパスセグメントは、リダイレクト参照リソースのDAVの値に置き換えられ。リクエストURIの残りの部分は、この経路に連結されています。
Note: If the DAV:reftarget property ends with a "/" and the remainder of the Request-URI is non-empty (and therefore must begin with a "/"), the final "/" in the DAV:reftarget property is dropped before the remainder of the Request-URI is appended.
DAVでreftargetプロパティは「/」で終わるとRequest-URIの残りの部分は空でない（したがって、「/」で始まる必要があります）、最後の「/」：注：DAVの場合reftarget特性でありますリクエストURIの残りの部分が追加される前に削除。
Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect reference resource, whose target resource is collection /a/, which contains redirect reference resource y whose target resource is collection /b/, which contains redirect reference resource z.html, whose target resource is /c/d.html.
要求URI /x/y/z.htmlを考えてみましょう。 / X /は、そのターゲットリソースそのターゲットリソースターゲットリソース/ Cである基準リソースz.htmlリダイレクト含むコレクション/ Bの/、、である基準リソースyをリダイレクト含むコレクション/ /、あるリダイレクト参照リソースであると仮定する/d.html。
/x/y/z.html
|
| /x -> /a
|
v
/a/y/z.html
|
| /a/y -> /b
|
v
/b/z.html
|
| /b/z.html -> /c/d.html
|
v
/c/d.html
In this case, the client must follow up three separate 3xx responses before finally reaching the target resource. The server responds to the initial request with a 3xx with Location: /a/y/z.html, and the client resubmits the request to /a/y/z.html. The server responds to this request with a 3xx with Location: /b/z.html, and the client resubmits the request to /b/z.html. The server responds to this request with a 3xx with Location: /c/d.html, and the client resubmits the request to /c/d.html. This final request succeeds.
この場合、クライアントは最終的にターゲットリソースに到達する前に、3つの別々の3xx応答をフォローアップしなければなりません。 /a/y/z.html、およびクライアントが/a/y/z.html要求を再送信します。サーバーは、場所と300番台との最初の要求に応答します。 /b/z.html、およびクライアントが/b/z.html要求を再送信します。サーバーは、場所との3xxと、この要求に応答します。 /c/d.html、およびクライアントが/c/d.html要求を再送信します。サーバーは、場所との3xxと、この要求に応答します。この最後の要求は成功します。
Note: The behaviour described above may have a very serious impact on the efficiency of mapping Request-URIs to resources in HTTP request processing. Therefore, servers MAY respond with a 404 status code if the cost of checking all leading path segments for redirect references seems prohibitive.
注：上記動作は、HTTPリクエストの処理にリソースへのマッピングのRequest-URIの効率に非常に深刻な影響を有していてもよいです。リダイレクトの参照のために、すべての主要なパスセグメントをチェックするコストは法外と思われる場合はそのため、サーバは404のステータスコードで応答することができます。
Redirect-Ref = "Redirect-Ref:" (URI | relative-ref) ; URI: see [RFC3986], Section 3 ; relative-ref: see [RFC3986], Section 4.2
リダイレクト-REF = "リダイレクト-REFを："（URI |相対-REF）; URI：[RFC3986]、セクション3を参照してください。相対-REF：参照[RFC3986]、セクション4.2
The Redirect-Ref header is used in all 3xx responses from redirect reference resources. The value is the link target as specified during redirect reference resource creation.
リダイレクト-REFヘッダをリダイレクト参照リソースからのすべての3xx応答に使用されます。リダイレクト参照リソースの作成時に指定された値は、リンクのターゲットです。
Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F")
適用-TO-リダイレクト-REF = "適用-TO-リダイレクト-REF" "："（ "T" | "F"）
The optional Apply-To-Redirect-Ref header can be used on any request to a redirect reference resource. When it is present and set to "T", the request MUST be applied to the reference resource itself, and a 3xx response MUST NOT be returned.
オプション適用-TO-リダイレクト-REFヘッダリダイレクト参照リソースへの要求に応じて使用することができます。それが存在し、「T」に設定されている場合、要求は、参照リソース自体に適用されなければならない、と3xx応答を返してはいけません。
If the Apply-To-Redirect-Ref header is used on a request to any other sort of resource besides a redirect reference resource, the server MUST ignore it.
適用-TO-リダイレクト-REFヘッダをリダイレクト参照リソース以外のリソースの任意の他の種類の要求に使用される場合、サーバはそれを無視しなければなりません。
The properties defined below are REQUIRED on redirect reference resources. A PROPFIND/allprop request SHOULD NOT return any of the properties defined in this document.
次に定義する特性は、リダイレクトリファレンスリソースに必要とされます。 PROPFIND / allprop要求は、この文書で定義されたプロパティのいずれかを返すべきではありません。
This property provides information about the lifetime of a redirect. It can be either DAV:permanent (HTTP status 301) or DAV:temporary (HTTP status 302). Future protocols may define additional values.
このプロパティは、リダイレクトの寿命に関する情報を提供します。永久（HTTPステータス301）またはDAV：一時的（HTTPステータス302）には、DAVのいずれかであり得ます。将来のプロトコルは、追加の値を定義することができます。
<!ELEMENT redirect-lifetime (permanent | temporary)> <!ELEMENT permanent EMPTY> <!ELEMENT temporary EMPTY>
<！ELEMENTリダイレクト-寿命（パーマネントを|一時的な）> <！ELEMENT永久EMPTY> <！ELEMENT一時的EMPTY>
This property provides an efficient way for clients to discover the URI of the target resource. This is a read-only property after its initial creation. Its value can only be set in a MKREDIRECTREF request. The value is a DAV:href element containing the URI of the target resource.
このプロパティは、クライアントがターゲットリソースのURIを発見するための効率的な方法を提供します。これは、その最初の作成後に読み取り専用のプロパティです。その値は、唯一MKREDIRECTREF要求に設定することができます。ターゲットリソースのURIを含むHREF要素：値は、DAVです。
<!ELEMENT reftarget href >
<！ELEMENTは、HREF reftarget>
Name: redirectref
名前：redirectref
Namespace: DAV:
名前空間：DAV：
Purpose: Used as the value of the DAV:resourcetype property to specify that the resource type is a redirect reference resource.
目的：DAVの値として使用：resourcetypeのプロパティは、リソースタイプがリダイレクト参照リソースであることを指定します。
<!ELEMENT redirectref EMPTY >
<！ELEMENT redirectref EMPTY>
15. Extensions to the DAV:response XML Element for Multi-Status Responses
DAVへ15.拡張：マルチステータス応答の応答XML要素
As described in Section 8, the DAV:location element may be returned in the DAV:response element of a 207 Multi-Status response, to allow clients to resubmit their requests to the target resource of a redirect reference resource.
セクション8に記載されているように、DAV：クライアントは、リダイレクト参照リソースのターゲットリソースへの要求を再送信することを可能にするために、207マルチステータス応答の応答エレメント：location要素は、DAVに戻すことができます。
Consequently, the definition of the DAV:response XML element changes to the following:
したがって、DAVの定義：次への応答XML要素の変更：
<!ELEMENT response (href, ((href*, status)|(propstat+)), responsedescription?, location?) > <!ELEMENT location (href) >
<ELEMENT応答！（HREF、（（HREF *、ステータス）|？（propstat +））、responsedescription ?,場所）> <！ELEMENT場所（HREF）>
Sections 9.1 and 15 of [RFC2518] describe the use of compliance classes with the DAV header in responses to OPTIONS, to indicate which parts of the WebDAV Distributed Authoring protocols the resource supports. This specification defines an OPTIONAL extension to [RFC2518]. It defines a new compliance class, called redirectrefs, for use with the DAV header in responses to OPTIONS requests. If a resource does support redirect references, its response to an OPTIONS request may indicate that it does, by listing the new redirectrefs compliance class in the DAV header and by listing the MKREDIRECTREF method as one it supports.
セクション9.1との15 [RFC2518] WebDAVの分散オーサリングの部分は、リソースがサポートするプロトコルを示すために、OPTIONSへの応答におけるDAVヘッダに準拠クラスの使用を記載しています。この仕様は、[RFC2518]にOPTIONAL拡張を定義します。これは、OPTIONS要求への応答でDAVヘッダーで使用するために、redirectrefsと呼ばれる新しいコンプライアンスクラスを定義します。リソースが参照をサポートリダイレクトしない場合は、OPTIONS要求への応答は、DAVヘッダに新しいredirectrefsコンプライアンスクラスを列挙することによって、それがサポートするものとしてMKREDIRECTREF方法を列挙することによって、それがないことを示してもよいです。
When responding to an OPTIONS request, any type of resource can include redirectrefs in the value of the DAV header. Doing so indicates that the server permits a redirect reference resource at the Request-URI.
OPTIONS要求に応答するときに、リソースの任意のタイプは、DAVヘッダの値にredirectrefsを含むことができます。そうすることで、サーバが要求URIにリダイレクト参照リソースを許可することを示しています。
>> Request:
>>リクエスト：
OPTIONS /somecollection/someresource HTTP/1.1 Host: example.org
OPTIONS / somecollection / someresource HTTP / 1.1ホスト：example.org
>> Response:
>>回答：
HTTP/1.1 200 OK Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREDIRECTREF DAV: 1, 2, redirectrefs
HTTP / 1.1 200 OKが許可：OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、COPYは、MOVEは許可：MKCOL、PROPFIND、PROPPATCH、LOCKを、UNLOCK、MKREDIRECTREF DAV：1、2、redirectrefs
The DAV header in the response indicates that the resource /somecollection/someresource is level 1 and level 2 compliant, as defined in [RFC2518]. In addition, /somecollection/someresource supports redirect reference resources. The Allow header indicates that MKREDIRECTREF requests can be submitted to /somecollection/someresource.
応答DAVヘッダーは[RFC2518]で定義されるように、リソース/ somecollection / someresourceは、レベル1とレベル2に準拠していることを示しています。また、/ somecollection / someresource支持体は、参照リソースをリダイレクトします。許可ヘッダーはMKREDIRECTREF要求が/ somecollection / someresourceに提出することができることを示しています。
This section is provided to make applications that implement this protocol aware of the security implications of this protocol.
このセクションでは、このプロトコルのセキュリティへの影響を認識して、このプロトコルを実装するアプリケーションを作成するために提供されます。
All of the security considerations of HTTP/1.1 and the WebDAV Distributed Authoring Protocol specification also apply to this protocol specification. In addition, redirect reference resources introduce several new security concerns and increase the risk of some existing threats. These issues are detailed below.
HTTP / 1.1のセキュリティ上の考慮事項とWebDAVの分散オーサリングプロトコル仕様のすべてのも、このプロトコル仕様に適用されます。また、参照リソースは、いくつかの新しいセキュリティ上の問題を紹介し、いくつかの既存の脅威のリスクを高めるリダイレクト。これらの問題は以下に詳述されています。
By creating redirect reference resources on a trusted server, it is possible for a hostile agent to induce users to send private information to a target on an unrelated system. This risk is mitigated somewhat, since clients are required to notify the user of the redirection for any request other than GET or HEAD. (See [RFC2616], Section 10.3.3, 302 Found.)
敵対的なエージェントは関係のないシステム上のターゲットに個人情報を送信するためにユーザを誘導するために信頼されたサーバー上の参照リソースをリダイレクト作成することにより、それが可能です。クライアントがGETまたはHEAD以外の要求に対してリダイレクトをユーザに通知する必要があるので、このリスクは、多少緩和されます。 （セクション10.3.3、302が見つかり、[RFC2616]を参照）。
Although redirect loops were already possible in HTTP 1.1, the introduction of the MKREDIRECTREF method creates a new avenue for clients to create loops accidentally or maliciously. If the reference resource and its target are on the same server, the server may be able to detect MKREDIRECTREF requests that would create loops. See also [RFC2616], Section 10.3, "Redirection 3xx."
リダイレクトループがHTTP 1.1で既に可能でしたが、MKREDIRECTREF方式の導入は、クライアントが誤って、または悪意を持ってループを作成するための新しい道を作成します。参照リソースとそのターゲットが同じサーバー上にある場合、サーバーは、ループを作成しますMKREDIRECTREF要求を検出することができます。参照してください[RFC2616]、セクション10.3、 "リダイレクション3XX。"
Denial of service attacks were already possible by posting URLs that were intended for limited use at heavily used Web sites. The introduction of MKREDIRECTREF creates a new avenue for similar denial of service attacks. Clients can now create redirect reference resources at heavily used sites to target locations that were not designed for heavy usage.
サービス妨害攻撃は、使用頻度の高いWebサイトで限定された使用のために意図されたURLを掲載することにより、既に可能でした。 MKREDIRECTREFの導入は、サービス攻撃の同様の拒否のための新しい道を作成します。クライアントは、今大量使用のために設計されていない場所をターゲットに使用頻度の高いサイトにリダイレクト参照リソースを作成することができます。
There are several ways that redirect reference resources may reveal information about collection structures. First, the DAV:reftarget property of every redirect reference resource contains the URI of the target resource. Anyone who has access to the reference resource can discover the collection path that leads to the target resource. The owner of the target resource may have wanted to limit knowledge of this collection structure.
コレクション構造に関する情報を明らかにすることができる、参照リソースをリダイレクトするいくつかの方法があります。まず、DAV：すべてののreftargetプロパティが参照リソースがターゲットリソースのURIが含まれてリダイレクトします。参照リソースへのアクセス権を持っている誰もがターゲットリソースにつながる回収経路を発見することができます。ターゲット・リソースの所有者は、このコレクションの構造の知識を制限したかったかもしれません。
Sufficiently powerful access control mechanisms can control this risk to some extent. Property-level access control could prevent users from examining the DAV:reftarget property. (The Location header returned in responses to requests on redirect reference resources reveals the same information, however.)
十分に強力なアクセス制御メカニズムは、ある程度までこのリスクを制御することができます。プロパティ・レベルのアクセス制御は、DAVを調べるからユーザーを防ぐことができます：reftargetプロパティを。 （リダイレクトリファレンスリソースの要求に対する応答で返されるロケーションヘッダは、しかし、同一の情報を明らかにする。）
This risk is no greater than the similar risk posed by HTML links.
このリスクは、HTMLリンクによってもたらさ同様の危険性よりも大きくありません。
All internationalization considerations mentioned in [RFC2518] also apply to this document.
[RFC2518]で言及されるすべての国際化の考慮も、この文書に適用されます。
All IANA considerations mentioned in [RFC2518] also apply to this document.
[RFC2518]で述べたすべてのIANA問題も、この文書に適用されます。
This document specifies the two new HTTP headers listed below.
この文書では、下記の二つの新しいHTTPヘッダを指定します。
Header field name: Redirect-Ref
ヘッダフィールド名：リダイレクト-REF
Applicable protocol: http
該当するプロトコル：HTTP
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document: this specification (Section 12.1)
仕様書：この仕様書（12.1節）
Header field name: Apply-To-Redirect-Ref
ヘッダフィールド名：適用-TO-リダイレクト-REF
Applicable protocol: http
該当するプロトコル：HTTP
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document: this specification (Section 12.2)
仕様書：この仕様書（12.2節）
Many thanks to Jason Crawford, Jim Davis, Chuck Fay, and Judith Slein, who can take credit for big parts of the original design of this specification.
この仕様のオリジナルデザインの大部分のための信用を取ることができジェイソン・クロフォード、ジム・デイビス、チャック・フェイ、そしてジュディスSlein、に感謝します。
This document has benefited from thoughtful discussion by Jim Amsden, Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin Wiggen, and others.
この文書は、ジム・Amsden、ピーター・カールソン、スティーブ・カーター、タイソン千早、ケン・コアー、エリス・コーエン、ブルースCragun、スペンサードーキンス、マーク・デイ、ラジブDulepet、デビッド・デュラン、リサDusseault、ステファンEissing、ロイ・フィールディングで思慮深い議論から恩恵を受けていますヤロンGoland、フレッドHITT、アレックスHopmann、ジェームス・ハント、マーカス・イェーガー、クリスKaler、ManojさんKasichainula、ロフィット・クヘア、ダニエル・リベルテ、スティーブ・マーティン、ラリーMasinter、ジェフMcAffer氏、ジョー・オートン、スレンドラKoduruレディ、ユルゲン・ロイター、マックスRible、サムルビー、ブラッドリー軍曹、ニックShelness、ジョンStracke、ジョンTigue、ジョン・ターナー、ケビン・Wiggen、などがあります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[RFC2518] Goland、Y.、ホワイトヘッド、E.、フェッチ、A.、カーター、S.、およびD.ジェンセン、 "分散オーサリングのHTTP拡張 - WEBDAV"、RFC 2518、1999年2月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002.
[RFC3253] Clemm、G.、Amsden、J.、エリソン、T.、Kaler、C.、およびJ.ホワイトヘッド "のWebDAV（Web分散オーサリングとバージョン）のバージョンの拡張"、RFC 3253、2002年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
Authors' Addresses
著者のアドレス
Jim Whitehead UC Santa Cruz, Dept. of Computer Science 1156 High Street Santa Cruz, CA 95064 US
ジム・ホワイトヘッドUCサンタクルス、コンピュータサイエンス学科1156ハイストリートサンタクルーズ、カリフォルニア州95064米国
EMail: ejw@cse.ucsc.edu
メールアドレス：ejw@cse.ucsc.edu
Geoff Clemm IBM 20 Maguire Road Lexington, MA 02421 US
ジェフClemm IBM 20マグワイアの道レキシントン、マサチューセッツ02421米国
EMail: geoffrey.clemm@us.ibm.com
メールアドレス：geoffrey.clemm@us.ibm.com
Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
ジュリアンF. Reschke（エディタ）greenbytes社Hafenweg 16ミュンスター、NW 48155ドイツ
Phone: +49 251 2807760 Fax: +49 251 2807761 EMail: julian.reschke@greenbytes.de URI: http://greenbytes.de/tech/webdav/
電話：+49 251 2807760ファックス：+49 251 2807761 Eメール：julian.reschke@greenbytes.de URI：http://greenbytes.de/tech/webdav/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。