Network Working Group Y. Goland
Request for Comments: 2518 Microsoft
Category: Standards Track E. Whitehead
UC Irvine
A. Faizi
Netscape
S. Carter
Novell
D. Jensen
Novell
February 1999
HTTP Extensions for Distributed Authoring -- WEBDAV
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance).
この文書は、メソッド、ヘッダ、及びコンテンツ・タイプ・リソース・プロパティ、資源のコレクションの作成と管理、名前空間操作、およびリソースロック（衝突回避）の管理のためのHTTP / 1.1に付随のセットを指定します。
Table of Contents
目次
ABSTRACT............................................................1
1 INTRODUCTION .....................................................5
2 NOTATIONAL CONVENTIONS ...........................................7
3 TERMINOLOGY ......................................................7
4 DATA MODEL FOR RESOURCE PROPERTIES ...............................8
4.1 The Resource Property Model ...................................8
4.2 Existing Metadata Proposals ...................................8
4.3 Properties and HTTP Headers ...................................9
4.4 Property Values ...............................................9
4.5 Property Names ...............................................10
4.6 Media Independent Links ......................................10
5 COLLECTIONS OF WEB RESOURCES ....................................11
5.1 HTTP URL Namespace Model .....................................11
5.2 Collection Resources .........................................11
5.3 Creation and Retrieval of Collection Resources ...............12
5.4 Source Resources and Output Resources ........................13
6 LOCKING .........................................................14
6.1 Exclusive Vs. Shared Locks ...................................14
6.2 Required Support .............................................16
6.3 Lock Tokens ..................................................16
6.4 opaquelocktoken Lock Token URI Scheme ........................16
6.4.1 Node Field Generation Without the IEEE 802 Address ........17
6.5 Lock Capability Discovery ....................................19
6.6 Active Lock Discovery ........................................19
6.7 Usage Considerations .........................................19
7 WRITE LOCK ......................................................20
7.1 Methods Restricted by Write Locks ............................20
7.2 Write Locks and Lock Tokens ..................................20
7.3 Write Locks and Properties ...................................20
7.4 Write Locks and Null Resources ...............................21
7.5 Write Locks and Collections ..................................21
7.6 Write Locks and the If Request Header ........................22
7.6.1 Example - Write Lock ......................................22
7.7 Write Locks and COPY/MOVE ....................................23
7.8 Refreshing Write Locks .......................................23
8 HTTP METHODS FOR DISTRIBUTED AUTHORING ..........................23
8.1 PROPFIND .....................................................24
8.1.1 Example - Retrieving Named Properties .....................25
8.1.2 Example - Using allprop to Retrieve All Properties ........26
8.1.3 Example - Using propname to Retrieve all Property Names ...29
8.2 PROPPATCH ....................................................31
8.2.1 Status Codes for use with 207 (Multi-Status) ..............31
8.2.2 Example - PROPPATCH .......................................32
8.3 MKCOL Method .................................................33
8.3.1 Request ...................................................33
8.3.2 Status Codes ..............................................33
8.3.3 Example - MKCOL ...........................................34
8.4 GET, HEAD for Collections ....................................34
8.5 POST for Collections .........................................35
8.6 DELETE .......................................................35
8.6.1 DELETE for Non-Collection Resources .......................35
8.6.2 DELETE for Collections ....................................36
8.7 PUT ..........................................................36
8.7.1 PUT for Non-Collection Resources ..........................36
8.7.2 PUT for Collections .......................................37
8.8 COPY Method ..................................................37
8.8.1 COPY for HTTP/1.1 resources ...............................37
8.8.2 COPY for Properties .......................................38
8.8.3 COPY for Collections ......................................38
8.8.4 COPY and the Overwrite Header .............................39
8.8.5 Status Codes ..............................................39
8.8.6 Example - COPY with Overwrite .............................40
8.8.7 Example - COPY with No Overwrite ..........................40
8.8.8 Example - COPY of a Collection ............................41
8.9 MOVE Method ..................................................42
8.9.1 MOVE for Properties .......................................42
8.9.2 MOVE for Collections ......................................42
8.9.3 MOVE and the Overwrite Header .............................43
8.9.4 Status Codes ..............................................43
8.9.5 Example - MOVE of a Non-Collection ........................44
8.9.6 Example - MOVE of a Collection ............................44
8.10 LOCK Method ..................................................45
8.10.1 Operation .................................................46
8.10.2 The Effect of Locks on Properties and Collections .........46
8.10.3 Locking Replicated Resources ..............................46
8.10.4 Depth and Locking .........................................46
8.10.5 Interaction with other Methods ............................47
8.10.6 Lock Compatibility Table ..................................47
8.10.7 Status Codes ..............................................48
8.10.8 Example - Simple Lock Request .............................48
8.10.9 Example - Refreshing a Write Lock .........................49
8.10.10 Example - Multi-Resource Lock Request ....................50
8.11 UNLOCK Method ................................................51
8.11.1 Example - UNLOCK ..........................................52
9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ..........................52
9.1 DAV Header ...................................................52
9.2 Depth Header .................................................52
9.3 Destination Header ...........................................54
9.4 If Header ....................................................54
9.4.1 No-tag-list Production ....................................55
9.4.2 Tagged-list Production ....................................55
9.4.3 not Production ............................................56
9.4.4 Matching Function .........................................56
9.4.5 If Header and Non-DAV Compliant Proxies ...................57
9.5 Lock-Token Header ............................................57
9.6 Overwrite Header .............................................57
9.7 Status-URI Response Header ...................................57
9.8 Timeout Request Header .......................................58
10 STATUS CODE EXTENSIONS TO HTTP/1.1 ............................59
10.1 102 Processing ...............................................59
10.2 207 Multi-Status .............................................59
10.3 422 Unprocessable Entity .....................................60
10.4 423 Locked ...................................................60
10.5 424 Failed Dependency ........................................60
10.6 507 Insufficient Storage .....................................60
11 MULTI-STATUS RESPONSE .........................................60
12 XML ELEMENT DEFINITIONS .......................................61
12.1 activelock XML Element .......................................61
12.1.1 depth XML Element .........................................61
12.1.2 locktoken XML Element .....................................61
12.1.3 timeout XML Element .......................................61
12.2 collection XML Element .......................................62
12.3 href XML Element .............................................62
12.4 link XML Element .............................................62
12.4.1 dst XML Element ...........................................62
12.4.2 src XML Element ...........................................62
12.5 lockentry XML Element ........................................63
12.6 lockinfo XML Element .........................................63
12.7 lockscope XML Element ........................................63
12.7.1 exclusive XML Element .....................................63
12.7.2 shared XML Element ........................................63
12.8 locktype XML Element .........................................64
12.8.1 write XML Element .........................................64
12.9 multistatus XML Element ......................................64
12.9.1 response XML Element ......................................64
12.9.2 responsedescription XML Element ...........................65
12.10 owner XML Element ...........................................65
12.11 prop XML element ............................................66
12.12 propertybehavior XML element ................................66
12.12.1 keepalive XML element ....................................66
12.12.2 omit XML element .........................................67
12.13 propertyupdate XML element ..................................67
12.13.1 remove XML element .......................................67
12.13.2 set XML element ..........................................67
12.14 propfind XML Element ........................................68
12.14.1 allprop XML Element ......................................68
12.14.2 propname XML Element .....................................68
13 DAV PROPERTIES ................................................68
13.1 creationdate Property ........................................69
13.2 displayname Property .........................................69
13.3 getcontentlanguage Property ..................................69
13.4 getcontentlength Property ....................................69
13.5 getcontenttype Property ......................................70
13.6 getetag Property .............................................70
13.7 getlastmodified Property .....................................70
13.8 lockdiscovery Property .......................................71
13.8.1 Example - Retrieving the lockdiscovery Property ...........71
13.9 resourcetype Property ........................................72
13.10 source Property .............................................72
13.10.1 Example - A source Property ..............................72
13.11 supportedlock Property ......................................73
13.11.1 Example - Retrieving the supportedlock Property ..........73
14 INSTRUCTIONS FOR PROCESSING XML IN DAV ........................74
15 DAV COMPLIANCE CLASSES ........................................75
15.1 Class 1 ......................................................75
15.2 Class 2 ......................................................75
16 INTERNATIONALIZATION CONSIDERATIONS ...........................76
17 SECURITY CONSIDERATIONS .......................................77
17.1 Authentication of Clients ....................................77
17.2 Denial of Service ............................................78
17.3 Security through Obscurity ...................................78
17.4 Privacy Issues Connected to Locks ............................78
17.5 Privacy Issues Connected to Properties .......................79
17.6 Reduction of Security due to Source Link .....................79
17.7 Implications of XML External Entities ........................79
17.8 Risks Connected with Lock Tokens .............................80
18 IANA CONSIDERATIONS ...........................................80
19 INTELLECTUAL PROPERTY .........................................81
20 ACKNOWLEDGEMENTS ..............................................82
21 REFERENCES ....................................................82
21.1 Normative References .........................................82
21.2 Informational References .....................................83
22 AUTHORS' ADDRESSES ............................................84
23 APPENDICES ....................................................86
23.1 Appendix 1 - WebDAV Document Type Definition .................86
23.2 Appendix 2 - ISO 8601 Date and Time Profile ..................88
23.3 Appendix 3 - Notes on Processing XML Elements ................89
23.3.1 Notes on Empty XML Elements ...............................89
23.3.2 Notes on Illegal XML Processing ...........................89
23.4 Appendix 4 -- XML Namespaces for WebDAV ......................92
23.4.1 Introduction ..............................................92
23.4.2 Meaning of Qualified Names ................................92
24 FULL COPYRIGHT STATEMENT ......................................94
1 Introduction
1はじめに
This document describes an extension to the HTTP/1.1 protocol that allows clients to perform remote web content authoring operations. This extension provides a coherent set of methods, headers, request entity body formats, and response entity body formats that provide operations for:
この文書では、クライアントがリモートWebコンテンツのオーサリング操作を実行することを可能にするHTTP / 1.1プロトコルの拡張について説明します。この拡張は、メソッド、ヘッダ、要求エンティティボディフォーマット、及びための操作を提供する応答エンティティボディフォーマットのコヒーレントなセットを提供します。
Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc. Also, the ability to link pages of any media type to related pages.
プロパティ：作成、削除、および、また、関連するページへの任意のメディアタイプのページをリンクする機能を、そのような彼らの作者などのWebページ、作成日などの情報を照会する機能。
Collections: The ability to create sets of documents and to retrieve a hierarchical membership listing (like a directory listing in a file system).
コレクション：文書のセットを作成すると、（ファイルシステム内のディレクトリリストのような）階層的なメンバーシップの一覧を取得する機能。
Locking: The ability to keep more than one person from working on a document at the same time. This prevents the "lost update problem," in which modifications are lost as first one author then another writes changes without merging the other author's changes.
ロック：同時に文書に取り組んでから、複数の人を維持する能力。これは、変更が他の著者の変更をマージすることなく、最初の1本の著者として、別の書き込みの変更を失わされている「失われた更新の問題を、」防ぐことができます。
Namespace Operations: The ability to instruct the server to copy and move Web resources.
名前空間の操作：コピーして、Webリソースを移動するために、サーバーに指示する機能。
Requirements and rationale for these operations are described in a companion document, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web" [RFC2291].
これらの操作のための要件と根拠は仲間ドキュメント、「ワールド・ワイド・ウェブのための分散オーサリングとバージョン管理プロトコルのための要件」[RFC2291]で説明されています。
The sections below provide a detailed introduction to resource properties (section 4), collections of resources (section 5), and locking operations (section 6). These sections introduce the abstractions manipulated by the WebDAV-specific HTTP methods described in section 8, "HTTP Methods for Distributed Authoring".
以下のセクションでは、特性（セクション4）、リソースのコレクション（セクション5）リソースする詳細な導入を提供し、ロック操作（セクション6）。これらのセクションは、セクション8に記載のWebDAV固有のHTTPメソッド、「分散オーサリングするためのHTTPメソッド」によって操作抽象化を導入します。
In HTTP/1.1, method parameter information was exclusively encoded in HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter information either in an Extensible Markup Language (XML) [REC-XML] request entity body, or in an HTTP header. The use of XML to encode method parameters was motivated by the ability to add extra XML elements to existing structures, providing extensibility; and by XML's ability to encode information in ISO 10646 character sets, providing internationalization support. As a rule of thumb, parameters are encoded in XML entity bodies when they have unbounded length, or when they may be shown to a human user and hence require encoding in an ISO 10646 character set. Otherwise, parameters are encoded within HTTP headers. Section 9 describes the new HTTP headers used with WebDAV methods.
HTTP / 1.1では、メソッドパラメータ情報は、専らHTTPヘッダに符号化されました。 HTTP / 1.1とは異なり、WebDAVは、拡張マークアップ言語（XML）[REC-XML]要求エンティティ本体内、またはHTTPヘッダーのいずれかの方法パラメータ情報を符号化します。メソッドパラメータを符号化するXMLの使用は、拡張性を提供し、既存の構造に追加のXML要素を追加する能力によって動機づけられました。そして、国際化サポートを提供し、ISO 10646文字セット内の情報を符号化するためにXMLの能力によって。彼らは無限の長さを有するときに経験則として、パラメータは、XMLエンティティ体でエンコードされ、またはそれらが人間のユーザに示すことができる場合、したがって、ISO 10646文字セットのエンコードを必要とします。そうでない場合、パラメータは、HTTPヘッダ内に符号化されます。第9章は、WebDAVメソッドで使用される新しいHTTPヘッダを記述しています。
In addition to encoding method parameters, XML is used in WebDAV to encode the responses from methods, providing the extensibility and internationalization advantages of XML for method output, as well as input.
メソッドパラメータを符号化することに加えて、XMLは、メソッドの出力、ならびに入力をXMLの拡張及び国際利点を提供し、方法からの応答をエンコードするためのWebDAVに使用されます。
XML elements used in this specification are defined in section 12.
本明細書で使用されるXML要素は、セクション12で定義されています。
The XML namespace extension (Appendix 4) is also used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names.
XML名前空間拡張（付録4）は、他の要素名と衝突の恐れなしに追加される新しいXML要素を可能にするために、本明細書で使用されます。
While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebDAV methods, there are some errors that do not fall neatly into the existing categories. New status codes developed for the WebDAV methods are defined in section 10. Since some WebDAV methods may operate over many
HTTP / 1.1が提供するステータスコードは、WebDAVメソッドによって発生する最もエラー条件を記述するのに十分であるが、既存のカテゴリにきちんと分類されない多少の誤差があります。 WebDAVメソッドのために開発された新しいステータスコードは、多くの上に動作することができるいくつかのWebDAVメソッドので、セクション10で定義されています
resources, the Multi-Status response has been introduced to return status information for multiple resources. The Multi-Status response is described in section 11.
リソースは、マルチステータス応答は、複数のリソースのステータス情報を返すために導入されました。マルチステータス応答がセクション11に記載されています。
WebDAV employs the property mechanism to store information about the current state of the resource. For example, when a lock is taken out on a resource, a lock information property describes the current state of the lock. Section 13 defines the properties used within the WebDAV specification.
WebDAVは、リソースの現在の状態についての情報を格納するためのプロパティのメカニズムを採用しています。例えば、ロックがリソース上で取り出す際、ロック情報プロパティは、ロックの現在の状態を記述する。セクション13は、WebDAV仕様の範囲内で使用されるプロパティを定義します。
Finishing off the specification are sections on what it means to be compliant with this specification (section 15), on internationalization support (section 16), and on security (section 17).
仕様をオフに仕上げすることは、国際化サポート（セクション16）に、この仕様（セクション15）に準拠するように何を意味するのかのセクションであり、セキュリティ上（セクション17）。
2 Notational Conventions
2つの表記規則
Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used herein to describe protocol elements is exactly the same as described in section 2.1 of [RFC2068]. Since this augmented BNF uses the basic production rules provided in section 2.2 of [RFC2068], these rules apply to this document as well.
この文書はHTTP / 1.1プロトコルの拡張セットを記述しているので、[RFC2068]のセクション2.1に記載されているように、プロトコル要素を記述するために本明細書で使用される拡張BNFは全く同じです。この拡張BNFは[RFC2068]のセクション2.2に提供される基本的なプロダクションルールを使用するので、これらの規則は、同様に、この文書に適用されます。
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 [RFC2119].
キーワードは "MUST" は、 "MUST NOT"、 "REQUIRED" は、 "SHOULD" "ないもの" "ものと" べきではありません」、 "推奨"、 "MAY"、および "" OPTIONALこの文書に記載されているにしていますRFC 2119 [RFC2119]に記載されているように解釈されます。
3 Terminology
3用語
URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, respectively. These terms (and the distinction between them) are defined in [RFC2396].
URI / URL - 統一資源識別子と、それぞれユニフォームリソースロケータ、。これらの用語（およびそれらの間の区別）が[RFC2396]で定義されています。
Collection - A resource that contains a set of URIs, termed member URIs, which identify member resources and meets the requirements in section 5 of this specification.
コレクション - URIのセットが含まれているリソースは、メンバーのリソースを特定し、この仕様のセクション5で要件を満たしているメンバーURIを、と呼ばれます。
Member URI - A URI which is a member of the set of URIs contained by a collection.
メンバーURI - URIのコレクションに含まれるURIのセットのメンバーです。
Internal Member URI - A Member URI that is immediately relative to the URI of the collection (the definition of immediately relative is given in section 5.2).
内部メンバーURI - コレクションのURI（すぐ相対の定義セクション5.2で与えられている）のすぐ相対的であるメンバーURI。
Property - A name/value pair that contains descriptive information about a resource.
プロパティ - リソースについての記述情報を含む名前/値のペア。
Live Property - A property whose semantics and syntax are enforced by the server. For example, the live "getcontentlength" property has its value, the length of the entity returned by a GET request, automatically calculated by the server.
ライブプロパティ - その意味と構文のサーバによって強制されているプロパティ。例えば、ライブ「getcontentlength」プロパティは、その値が、自動的にサーバで計算GETリクエストによって返されるエンティティの長さを有します。
Dead Property - A property whose semantics and syntax are not enforced by the server. The server only records the value of a dead property; the client is responsible for maintaining the consistency of the syntax and semantics of a dead property.
デッドプロパティ - その意味と構文サーバーによって強制されていない財産。サーバは死んでプロパティの値を記録します。クライアントは死んプロパティの構文とセマンティクスの一貫性を維持する責任があります。
Null Resource - A resource which responds with a 404 (Not Found) to any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK. A NULL resource MUST NOT appear as a member of its parent collection.
ヌルリソース - PUT、MKCOL、OPTIONSとLOCK以外の任意のHTTP / 1.1またはDAVメソッドへの404（見つかりません）で応答リソース。 NULLリソースは、その親コレクションのメンバーとして現れてはなりません。
4 Data Model for Resource Properties
リソースプロパティのための4データモデル
Properties are pieces of data that describe the state of a resource. Properties are data about data.
プロパティは、リソースの状態を記述するデータの一部です。プロパティは、データに関するデータです。
Properties are used in distributed authoring environments to provide for efficient discovery and management of resources. For example, a 'subject' property might allow for the indexing of all resources by their subject, and an 'author' property might allow for the discovery of what authors have written which documents.
プロパティは、リソースの効率的な検出と管理を提供するために、分散オーサリング環境で使用されています。たとえば、「件名」プロパティには、その対象がすべてのリソースのインデックス付けを可能かもしれない、と「著者」プロパティには、著者がどの文書を書かれているものの発見を可能にすることがあります。
The DAV property model consists of name/value pairs. The name of a property identifies the property's syntax and semantics, and provides an address by which to refer to its syntax and semantics.
DAVプロパティモデルは、名前/値のペアで構成されています。プロパティの名前は、プロパティの構文とセマンティクスを識別し、その構文と意味を参照するためのアドレスを提供します。
There are two categories of properties: "live" and "dead". A live property has its syntax and semantics enforced by the server. Live properties include cases where a) the value of a property is read-only, maintained by the server, and b) the value of the property is maintained by the client, but the server performs syntax checking on submitted values. All instances of a given live property MUST comply with the definition associated with that property name. A dead property has its syntax and semantics enforced by the client; the server merely records the value of the property verbatim.
「ライブ」と「死んで」：プロパティの2つのカテゴリがあります。ライブプロパティは、サーバによって強制その構文と意味を持っています。ライブのプロパティは、プロパティの）値は読み取り専用で、サーバーによって維持、およびb）プロパティの値がクライアントによって維持されている例が挙げられるが、これらのサーバは、送信された値に構文チェックを実行します。与えられた生のプロパティのすべてのインスタンスは、そのプロパティ名に関連付けられた定義に準拠しなければなりません。死者プロパティは、クライアントによって施行その構文と意味を持っています。サーバは単にそのままプロパティの値を記録します。
Properties have long played an essential role in the maintenance of large document repositories, and many current proposals contain some notion of a property, or discuss web metadata more generally. These include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several proposals on representing relationships within HTML. Work on PICS-NG and Web Collections has been subsumed by the Resource Description Framework (RDF) metadata activity of the World Wide Web Consortium. RDF consists of a network-based data model and an XML representation of that model.
プロパティは、長い大規模なドキュメントリポジトリの維持に重要な役割を果たしている、と多くの現在の提案は、プロパティのいくつかの概念が含まれている、またはより一般的にウェブメタデータを議論します。これらは、PICS [REC-PICS]、PICS-NG、XML、ウェブコレクション、およびHTML内の関係を表現する上でいくつかの提案が含まれます。 PICS-NGとWebコレクションの作業は、World Wide Web Consortiumのリソース記述フレームワーク（RDF）メタデータ活動によって包含されています。 RDFは、ネットワークベースのデータ・モデルと、そのモデルのXML表現から成ります。
Some proposals come from a digital library perspective. These include the Dublin Core [RFC2413] metadata set and the Warwick Framework [WF], a container architecture for different metadata schemas. The literature includes many examples of metadata, including MARC [USMARC], a bibliographic metadata format, and a technical report bibliographic format employed by the Dienst system [RFC1807]. Additionally, the proceedings from the first IEEE Metadata conference describe many community-specific metadata sets.
いくつかの提案は、デジタルライブラリの観点から来ます。これらは、ダブリンコア[RFC2413]メタデータセットとワーウィックフレームワーク[WF]、異なるメタデータスキーマのコンテナアーキテクチャを含みます。文献は、MARC [USMARC]、書誌メタデータフォーマット、及びDienstシステム[RFC1807]で採用技術報告書誌フォーマットを含むメタデータの多くの例を含みます。また、最初のIEEEメタデータ会議からの議事録には、多くのコミュニティ固有のメタデータ・セットを記述する。
Participants of the 1996 Metadata II Workshop in Warwick, UK [WF], noted that "new metadata sets will develop as the networked infrastructure matures" and "different communities will propose, design, and be responsible for different types of metadata." These observations can be corroborated by noting that many community-specific sets of metadata already exist, and there is significant motivation for the development of new forms of metadata as many communities increasingly make their data available in digital form, requiring a metadata format to assist data location and cataloging.
ワーウィック、イギリスの[WF] 1996年のメタデータIIワークショップの参加者は、および「ネットワーク・インフラが成熟するにつれ、新たなメタデータセットを開発する」と述べ、「異なるコミュニティは、提案、設計、およびメタデータの種類ごとに責任を負うことになります。」これらの観察は、メタデータの多くのコミュニティ固有のセットがすでに存在していることに注目することによって裏付けられ、多くのコミュニティがますますデジタル形式でそのデータを利用できるようにするとして重要な動機は、データを支援するためのメタデータ形式を必要とする、メタデータの新しい形態の開発のためにそこにいることができます場所やカタログ。
Properties already exist, in a limited sense, in HTTP message headers. However, in distributed authoring environments a relatively large number of properties are needed to describe the state of a resource, and setting/returning them all through HTTP headers is inefficient. Thus a mechanism is needed which allows a principal to identify a set of properties in which the principal is interested and to set or retrieve just those properties.
プロパティは、既にHTTPメッセージのヘッダーに、限定的な意味で、存在します。しかし、分散オーサリングのプロパティの比較的多数のリソースの状態を記述するために必要とされる環境、および設定/ HTTPヘッダを介してそれらのすべてを返すことは非効率的です。こうして機構は主に主に関心のあるプロパティのセットを識別し、ちょうどそれらのプロパティを設定または取得することを可能にするに必要とされます。
The value of a property when expressed in XML MUST be well formed.
XMLで表現さプロパティの値は、十分に形成されなければなりません。
XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self-describing nature allows any property's value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand. XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml:lang" attribute, handles cases where the same character set is employed by multiple human languages.
XMLは、それは、豊かなスキーマ定義をサポートする柔軟な、自己記述、構造化データ形式であるため、選択しているため、複数の文字セットのサポートのされています。 XMLの自己記述の性質は、任意のプロパティの値は、新しい要素を追加することによって拡張することができます。彼らは拡張子が発生したとき、彼らはまだ元のスキーマで指定されたデータを持っていますし、彼らは理解していない要素を無視するので、古いクライアントは中断されません。複数の文字セットのためのXMLのサポートは、すべての人間が読めるプロパティは、ユーザーになじみの文字セットでエンコードして読み取ることができます。 「XML：LANG」を使用して、複数の人間の言語のためのXMLのサポート、属性は、同じ文字セットは、複数の人間の言語で採用されている例を処理します。
A property name is a universally unique identifier that is associated with a schema that provides information about the syntax and semantics of the property.
プロパティ名は、プロパティの構文とセマンティクスについての情報を提供してスキーマに関連付けられている汎用一意識別子です。
Because a property's name is universally unique, clients can depend upon consistent behavior for a particular property across multiple resources, on the same and across different servers, so long as that property is "live" on the resources in question, and the implementation of the live property is faithful to its definition.
プロパティの名前は普遍的に一意であるため、クライアントはので、プロパティが問題になっているリソースの「ライブ」である限り、との実装、同じで、異なるサーバー間で、複数のリソース間で、特定のプロパティに対して一貫した動作に依存することができますライブプロパティは、その定義に忠実です。
The XML namespace mechanism, which is based on URIs [RFC2396], is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control.
これは名前空間の衝突を防ぎ、管理制御の程度を変化させることを提供するためのURI [RFC2396]に基づいているXML名前空間機構は、名前プロパティに使用されます。
The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. Thus, if a property A and a property A/B exist on a resource, there is no recognition of any relationship between the two properties. It is expected that a separate specification will eventually be produced which will address issues relating to hierarchical properties.
プロパティの名前空間は平坦です。つまり、プロパティのない階層は明示的に認識されません。プロパティAとプロパティA / Bがリソースに存在する場合したがって、2つのプロパティの間の任意の関係のない認識はありません。個別の仕様は最終的に、階層的な特性に関連する問題に対処しますが製造されることが期待されます。
Finally, it is not possible to define the same property twice on a single resource, as this would cause a collision in the resource's property namespace.
これは、リソースのプロパティの名前空間での衝突を引き起こすよう最後に、単一のリソースに二度同じプロパティを定義することはできません。
Although HTML resources support links to other resources, the Web needs more general support for links between resources of any media type (media types are also known as MIME types, or content types). WebDAV provides such links. A WebDAV link is a special type of property value, formally defined in section 12.4, that allows typed connections to be established between resources of any media type. The property value consists of source and destination Uniform Resource Identifiers (URIs); the property name identifies the link type.
他のリソースへのHTMLリソースのサポートリンクが、ウェブは、任意のメディアタイプのリソース間のリンクのためのより一般的なサポートを（メディアタイプはまた、MIMEタイプ、またはコンテンツタイプとして知られている）必要があります。 WebDAVは、このようなリンクを提供します。 WebDAVのリンクは、入力された接続が任意のメディアタイプのリソース間で確立することを可能にする正式セクション12.4で定義されたプロパティ値の特殊なタイプ、です。プロパティ値は、送信元と宛先のユニフォームリソース識別子（URIの）からなります。プロパティ名は、リンクタイプを識別します。
5 Collections of Web Resources
Webリソースの5つのコレクション
This section provides a description of a new type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace. The purpose of a collection resource is to model collection-like objects (e.g., file system directories) within a server's namespace.
このセクションでは、Webリソース、コレクションの新しいタイプの説明を提供し、HTTPのURL名前空間との相互作用について説明します。コレクションリソースの目的は、サーバーの名前空間内のコレクションのようなオブジェクト（例えば、ファイルシステムディレクトリ）をモデル化することです。
All DAV compliant resources MUST support the HTTP URL namespace model specified herein.
全てのDAV準拠したリソースは、ここで指定されたHTTP URL名前空間モデルをサポートしなければなりません。
The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character.
HTTPのURL名前空間は階層が「/」文字で区切られた階層的な名前空間です。
An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member. The root, or top-level collection of the namespace under consideration is exempt from the previous rule.
HTTPのURL名前空間は、それが以下の条件を満たしている場合には一貫性があると言われている：HTTP階層内のすべてのURLのために内部メンバーとしてそのURLを含むコレクションが存在します。検討中の名前空間のルート、またはトップレベルのコレクションは、以前のルールを免除されています。
Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL namespace be consistent. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies.
どちらもHTTP / 1.1やWebDAVは、全体のHTTP URL名前空間が一致している必要があります。しかし、特定のWebDAVメソッドは、名前空間の不整合が生じる結果を生成することは禁止されています。
Although implicit in [RFC2068] and [RFC2396], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.
[RFC2068]と[RFC2396]で暗黙のが、回収資源などのリソースは、複数のURIによって識別することができます。たとえば、リソースが複数のHTTP URLで識別することができます。
A collection is a resource whose state consists of at least a list of internal member URIs and a set of properties, but which may have additional state such as entity bodies returned by GET. An internal member URI MUST be immediately relative to a base URI of the collection. That is, the internal member URI is equal to a containing collection's URI plus an additional segment for non-collection resources, or additional segment plus trailing slash "/" for collection resources, where segment is defined in section 3.3 of [RFC2396].
コレクションは、その状態が少なくとも内部メンバーURIのリストとプロパティのセットで構成され、そのようなGETによって返されるエンティティ体として追加の状態を有することができるリソースです。内部部材URIは、コレクションのベースURIに対して直ちに相対的でなければなりません。すなわち、セグメントは[RFC2396]のセクション3.3で定義されているコレクションのリソースのURIが含むコレクションのURIに等しい内部部材プラス非コレクションリソースの追加セグメント、または追加のセグメントに加えて後続のスラッシュ「/」です。
Any given internal member URI MUST only belong to the collection once, i.e., it is illegal to have multiple instances of the same URI in a collection. Properties defined on collections behave exactly as do properties on non-collection resources.
URIのみ、すなわち、一度コレクションに属していなければならない任意の内部部材は、コレクションに同じURIの複数のインスタンスを有することは違法です。コレクションに定義されたプロパティは、非コレクションリソースのプロパティがそうであるように正確に動作します。
For all WebDAV compliant resources A and B, identified by URIs U and V, for which U is immediately relative to V, B MUST be a collection that has U as an internal member URI. So, if the resource with URL http://foo.com/bar/blah is WebDAV compliant and if the resource with URL http://foo.com/bar/ is WebDAV compliant then the resource with URL http://foo.com/bar/ must be a collection and must contain URL http://foo.com/bar/blah as an internal member.
UがVのすぐ相対されたURIのU及びVによって識別されるすべてのWebDAV準拠リソースAおよびBについては、Bは、内部部材URIとしてUを有するコレクションでなければなりません。だから、URLのhttp://foo.com/bar/blahのリソースは、WebDAV準拠している場合やURLのhttp://foo.com/bar/のリソースは、URLはhttpのリソースのWebDAV準拠している場合：// fooの.COM /バー/コレクションである必要があり、内部のメンバーとしてURL http://foo.com/bar/blahが含まれている必要があります。
Collection resources MAY list the URLs of non-WebDAV compliant children in the HTTP URL namespace hierarchy as internal members but are not required to do so. For example, if the resource with URL http://foo.com/bar/blah is not WebDAV compliant and the URL http://foo.com/bar/ identifies a collection then URL http://foo.com/bar/blah may or may not be an internal member of the collection with URL http://foo.com/bar/.
コレクションのリソースは、内部のメンバーとしてのHTTP URL名前空間階層内の非のWebDAV準拠した子どものURLを一覧表示してもよいが、その必要はありません。例えば、URLのhttp://foo.com/bar/blahのリソースがWebDAVを準拠していないとURLのhttp://foo.com/bar/は、コレクションを識別した場合、URL http://foo.com/bar /何とかは、またはURL http://foo.com/bar/とコレクションの内部メンバであってもなくてもよいです。
If a WebDAV compliant resource has no WebDAV compliant children in the HTTP URL namespace hierarchy then the WebDAV compliant resource is not required to be a collection.
WebDAVの準拠のリソースは、HTTP URL名前空間の階層にはWebDAVの対応の子供を持っていない場合は、その後のWebDAV準拠のリソースを収集する必要はありません。
There is a standing convention that when a collection is referred to by its name without a trailing slash, the trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it SHOULD return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form of collection names.
コレクションは、末尾のスラッシュなしで、その名前で呼ばれたとき、最後のスラッシュが自動的に付加されていることを立慣習があります。このため、リソースは、コレクションを指すように「/」末尾ずにURIを受け入れることができます。この場合、「/」で終わるURIに応答ポインティングコンテンツロケーションヘッダを返すべきです。クライアントが応答できるhttp://foo.bar/blah上の方法（末尾のスラッシュ）、リソースhttp://foo.bar/blah/（末尾のスラッシュ）を呼び出す場合、例えば、操作は上で呼び出されたかのようにまた、それにhttp://foo.bar/blah/とコンテンツロケーションヘッダを返すべきです。一般のクライアントでは、コレクション名の「/」フォームを使用する必要があります。
A resource MAY be a collection but not be WebDAV compliant. That is, the resource may comply with all the rules set out in this specification regarding how a collection is to behave without necessarily supporting all methods that a WebDAV compliant resource is required to support. In such a case the resource may return the DAV:resourcetype property with the value DAV:collection but MUST NOT return a DAV header containing the value "1" on an OPTIONS response.
リソースは、収集することができるが、互換でWebDAVされません。これは、リソースがコレクションは必ずしもWebDAVの準拠のリソースをサポートするために必要なすべてのメソッドをサポートせずに動作することがいかにについてのこの仕様に定めるすべての規則を遵守すること、です。値DAVとresourcetypeのプロパティ：この場合、リソースは、DAV返すことができるコレクションをもののOPTIONS応答に値「1」を含むDAVヘッダを返してはいけません。
This document specifies the MKCOL method to create new collection resources, rather than using the existing HTTP/1.1 PUT or POST method, for the following reasons:
このドキュメントではなく、次のような理由から、既存のHTTP / 1.1 PUTまたはPOSTメソッドを使用するよりも、新しいコレクション・リソースを作成するMKCOLメソッドを指定します。
In HTTP/1.1, the PUT method is defined to store the request body at the location specified by the Request-URI. While a description format for a collection can readily be constructed for use with PUT, the implications of sending such a description to the server are undesirable. For example, if a description of a collection that omitted some existing resources were PUT to a server, this might be interpreted as a command to remove those members. This would extend PUT to perform DELETE functionality, which is undesirable since it changes the semantics of PUT, and makes it difficult to control DELETE functionality with an access control scheme based on methods.
HTTP / 1.1では、PUT方法が要求URIで指定された場所にリクエストボディを格納するために定義されています。コレクションの記述形式を容易PUTで使用するために構築することができるが、サーバにそのような記述を送るの影響は望ましくありません。いくつかの既存のリソースを省略し、コレクションの記述がサーバーに置かれた場合、例えば、これは、それらのメンバーを削除するには、コマンドとして解釈される可能性があります。これは、PUTのセマンティクスを変更し、それが困難な方法に基づいてアクセス制御方式を採用したDELETE機能を制御することを可能にするため、望ましくないDELETE機能を実行するためにPUT延長します。
While the POST method is sufficiently open-ended that a "create a collection" POST command could be constructed, this is undesirable because it would be difficult to separate access control for collection creation from other uses of POST.
POSTメソッドは、十分にオープンエンド「コレクションを作成し、」POSTコマンドを構築することができることですが、それはPOSTの他の用途からコレクションを作成するための独立したアクセス制御が困難になるので、これは望ましくありません。
The exact definition of the behavior of GET and PUT on collections is defined later in this document.
GETやコレクションに置くの行動の正確な定義は、この文書の後半で定義されています。
For many resources, the entity returned by a GET method exactly matches the persistent state of the resource, for example, a GIF file stored on a disk. For this simple case, the URI at which a resource is accessed is identical to the URI at which the source (the persistent state) of the resource is accessed. This is also the case for HTML source files that are not processed by the server prior to transmission.
多くのリソースについては、GETメソッドによって返されるエンティティは、正確に、例えば、ディスク上に保存されたGIFファイルをリソースの永続的な状態に一致します。この単純なケースでは、リソースがアクセスされるURIは、リソースのソース（永続状態）がアクセスされるURIと同じです。これはまた、送信前にサーバで処理されていないHTMLソースファイルの場合です。
However, the server can sometimes process HTML resources before they are transmitted as a return entity body. For example, a server-side-include directive within an HTML file might instruct a server to replace the directive with another value, such as the current date. In this case, what is returned by GET (HTML plus date) differs from the persistent state of the resource (HTML plus directive). Typically there is no way to access the HTML resource containing the unprocessed directive.
彼らはリターンのエンティティボディとして送信される前に、しかし、サーバーは時々HTMLリソースを処理することができます。たとえば、現在の日付などの別の値を持つディレクティブを置き換えるために、サーバーに指示する可能性があるHTMLファイル内のディレクティブをサーバ側には、含まれています。この場合、何をGET（HTMLプラス日付）によって返されたリソース（HTMLプラスディレクティブ）の永続的な状態とは異なります。通常、未処理のディレクティブを含むHTMLリソースにアクセスする方法はありません。
Sometimes the entity returned by GET is the output of a data-producing process that is described by one or more source resources (that may not even have a location in the URI namespace). A single data-producing process may dynamically generate the state of a potentially large number of output resources. An example of this is a CGI script that describes a "finger" gateway process that maps part of the namespace of a server into finger requests, such as http://www.foo.bar.org/finger_gateway/user@host.
時々GETによって返されるエンティティは、（たとえURI名前空間内の位置を有していなくてもよい）1つまたは複数のソース・リソースによって記述されたデータ生成工程の出力です。単一のデータ・製造プロセスは、動的出力リソースの潜在的に多数の状態を生成することができます。この例は、このようなhttp://www.foo.bar.org/finger_gateway/user@hostとして指要求へのサーバーの名前空間の一部をマップする「指」のゲートウェイ・プロセスを説明CGIスクリプトです。
In the absence of distributed authoring capabilities, it is acceptable to have no mapping of source resource(s) to the URI namespace. In fact, preventing access to the source resource(s) has desirable security benefits. However, if remote editing of the source resource(s) is desired, the source resource(s) should be given a location in the URI namespace. This source location should not be one of the locations at which the generated output is retrievable, since in general it is impossible for the server to differentiate requests for source resources from requests for process output resources. There is often a many-to-many relationship between source resources and output resources.
分散オーサリング機能の非存在下では、URI名前空間にソースリソース（単数または複数）のないマッピングがないことが許容されます。実際には、ソースリソース（複数可）へのアクセスを防止することが望ましいセキュリティ上の利点を持っています。ソースリソース（単数または複数）のリモート編集が望まれる場合は、ソースリソース（単数または複数）は、URI名前空間内の場所を与えられるべきです。このソース位置は、サーバーがプロセス出力リソースに対する要求からソース・リソースに対する要求を区別するために、一般的には不可能であるため、生成された出力は、回収された場所のいずれかであってはなりません。ソースのリソースと出力リソース間の多対多の関係がしばしばあります。
On WebDAV compliant servers the URI of the source resource(s) may be stored in a link on the output resource with type DAV:source (see section 13.10 for a description of the source link property). Storing the source URIs in links on the output resources places the burden of discovering the source on the authoring client. Note that the value of a source link is not guaranteed to point to the correct source. Source links may break or incorrect values may be entered. Also note that not all servers will allow the client to set the source link value. For example a server which generates source links on the fly for its CGI files will most likely not allow a client to set the source link value.
WebDAVの準拠サーバーにソースリソース（単数または複数）のURIは、タイプDAVと出力リソースのリンクに格納することができる：ソース（ソースリンクプロパティの説明については、セクション13.10を参照します）。出力リソース上のリンクのソースURIを格納すると、オーサリングクライアント上のソースを発見するの負担を配置します。ソースリンクの値が正しいソースを指すように保証されないことに留意されたいです。ソースのリンクが破損したり、不正な値を入力することができます。また、すべてのサーバーは、クライアントがソースリンク値を設定することができますないことに注意してください。例えば、そのCGIファイル用のオンザフライでソースのリンクを生成するサーバーは、ほとんどのクライアントは、ソースリンク値を設定することはできません。
6 Locking
6ロック
The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can prevent the "lost update" problem.
リソースをロックする機能は、そのリソースへのアクセスをシリアル化するためのメカニズムを提供します。ロックを使用して、オーサリングクライアントは、それが編集されている間、別のプリンシパルがリソースを変更しないという合理的な保証を提供することができます。このように、クライアントは、「失われた更新」の問題を防ぐことができます。
This specification allows locks to vary over two client-specified parameters, the number of principals involved (exclusive vs. shared) and the type of access to be granted. This document defines locking for only one access type, write. However, the syntax is extensible, and permits the eventual specification of locking for other access types.
この仕様は、ロックは2つのクライアントが指定したパラメータに亘って変化することを可能に関わる主体の数（排他対が共有される）とアクセスの種類を付与します。この文書では、唯一のアクセスタイプのロックを定義し、書きます。しかし、構文は拡張可能であり、他のアクセスタイプのロックの最終的な仕様を可能にします。
The most basic form of lock is an exclusive lock. This is a lock where the access right in question is only granted to a single principal. The need for this arbitration results from a desire to avoid having to merge results.
ロックの最も基本的な形は排他ロックです。これは、問題のアクセス権は、単一のプリンシパルに付与されたロックです。この仲裁の必要性は、結果をマージすることを避けるために欲求に起因します。
However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple principals to receive a lock. Hence any principal with appropriate access can get the lock.
ロックの目標は、アクセス権の行使から他の人を除外するのではなく、彼らは彼らのアクセス権を行使しようとすることを示すために、プリンシパルのためのメカニズムを提供していない場合しかし、時間があります。共有ロックは、このような場合のために提供されています。共有ロックは、複数の主体がロックを受け取ることができます。したがって、適切なアクセス権を持つすべてのプリンシパルは、ロックを取得することができます。
With shared locks there are two trust sets that affect a resource. The first trust set is created by access permissions. Principals who are trusted, for example, may have permission to write to the resource. Among those who have access permission to write to the resource, the set of principals who have taken out a shared lock also must trust each other, creating a (typically) smaller trust set within the access permission write set.
共有ロックとリソースに影響を与える2つの信頼セットがあります。最初の信頼セットはアクセス権限によって作成されます。信頼されているプリンシパルは、例えば、リソースへの書き込み権限を持つことができます。リソースへの書き込みアクセス許可を持っている人の中で、また共有ロックを取り出しているプリンシパルのセットは、アクセス許可の書き込みセット内の設定（通常は）小さな信頼を作成し、お互いを信頼する必要があります。
Starting with every possible principal on the Internet, in most situations the vast majority of these principals will not have write access to a given resource. Of the small number who do have write access, some principals may decide to guarantee their edits are free from overwrite conflicts by using exclusive write locks. Others may decide they trust their collaborators will not overwrite their work (the potential set of collaborators being the set of principals who have write permission) and use a shared lock, which informs their collaborators that a principal may be working on the resource.
インターネット上のあらゆる可能な校長をはじめ、ほとんどの状況でこれらのプリンシパルの大半は、特定のリソースへの書き込みアクセス権を持っていません。書き込みアクセス権を持っている少数のうち、いくつかの校長は、排他的な書き込みロックを使用して、編集は上書きコンフリクトフリーである保証することもできます。他の人は彼らの協力者が自分の仕事を上書き（共同研究者の潜在的なセットは、書き込み権限を持つ主体の集合である）と、プリンシパルがリソースで作業することができることを彼らの協力者に知らせる共有ロックを、使用することはありません信頼して決めることができます。
The WebDAV extensions to HTTP do not need to provide all of the communications paths necessary for principals to coordinate their activities. When using shared locks, principals may use any out of band communication channel to coordinate their work (e.g., face-to-face interaction, written notes, post-it notes on the screen, telephone conversation, Email, etc.) The intent of a shared lock is to let collaborators know who else may be working on a resource.
HTTPのWebDAV拡張は、彼らの活動を調整するために、プリンシパルのために必要な通信パスのすべてを提供する必要はありません。共有ロックを使用する場合、プリンシパルは自分の仕事を調整するために、バンド通信チャネルのうちいずれかを使用することができる（例えば、フェイスツーフェイスの対話、書かれたノート、ポストイットは、スクリーン、電話での会話、電子メールなどでノート）の意図共有ロックは協力者がリソース上で作業することができる他の誰知らせることです。
Shared locks are included because experience from web distributed authoring systems has indicated that exclusive locks are often too rigid. An exclusive lock is used to enforce a particular editing process: take out an exclusive lock, read the resource, perform edits, write the resource, release the lock. This editing process has the problem that locks are not always properly released, for example when a program crashes, or when a lock owner leaves without unlocking a resource. While both timeouts and administrative action can be used to remove an offending lock, neither mechanism may be available when needed; the timeout may be long or the administrator may not be available.
Web分散オーサリングシステムからの経験が排他ロックは、多くの場合、あまりにも剛性であることが示されたため、共有ロックが含まれています。排他ロックは、特定の編集プロセスを強制するために使用されています、排他ロックを取り出しリソースを読み、編集を実行し、リソースを作成し、ロックを解除します。この編集処理は、例えば、ロックが常に適切に解放されていない問題があるときに、プログラムがクラッシュした、またはロック所有者がリソースのロックを解除せずに離れたとき。両方のタイムアウトや行政措置は、問題のロックを解除するために使用することができますが、必要なときに、どちらのメカニズムが利用可能であってもよいです。タイムアウトが長くあってもよいし、管理者が使用できない場合があります。
A WebDAV compliant server is not required to support locking in any form. If the server does support locking it may choose to support any combination of exclusive and shared locks for any access types.
WebDAVの準拠のサーバーは、いかなる形でロックをサポートする必要はありません。サーバがロックサポートしない場合には、任意のアクセスタイプのための排他的共有ロックの任意の組み合わせをサポートすることもできます。
The reason for this flexibility is that locking policy strikes to the very heart of the resource management and versioning systems employed by various storage repositories. These repositories require control over what sort of locking will be made available. For example, some repositories only support shared write locks while others only provide support for exclusive write locks while yet others use no locking at all. As each system is sufficiently different to merit exclusion of certain locking features, this specification leaves locking as the sole axis of negotiation within WebDAV.
この柔軟性の理由は、資源管理の非常に心にポリシーストライキをロックし、バージョン管理システムは、さまざまなストレージリポジトリで採用されているものです。これらのリポジトリを利用できるようになり、ロックの種類を超える制御を必要とします。まだ他はまったくロックを使用していないながら、他の人が唯一の排他的な書き込みロックのサポートを提供しながら、例えば、いくつかのリポジトリは、共有書き込みロックをサポートしています。各システムは、特定のロック機能のメリット排除に十分に異なっているように、この仕様は、WebDAV内交渉の唯一の軸としてのロックを残します。
A lock token is a type of state token, represented as a URI, which identifies a particular lock. A lock token is returned by every successful LOCK operation in the lockdiscovery property in the response body, and can also be found through lock discovery on a resource.
ロックトークンは、特定のロックを識別するURI、として表され、状態のトークンのタイプです。ロックトークンはレスポンスボディ内lockdiscoveryプロパティに成功するたびにLOCK操作で返され、また、リソースのロックの発見を通じて見つけることができます。
Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion.
ロックトークンURIは、すべての時間のためにすべてのリソースで一意である必要があります。この一意性制約は、ロックトークンは混乱を恐れることなくリソースとサーバー間で提出することができます。
This specification provides a lock token URI scheme called opaquelocktoken that meets the uniqueness requirements. However resources are free to return any URI scheme so long as it meets the uniqueness requirements.
この仕様は、一意性の要件を満たしていopaquelocktokenと呼ばれるロック・トークンURIスキームを提供します。しかし、リソースがあれば、一意の要件を満たしているとして、任意のURIスキームを返すことは自由です。
Having a lock token provides no special access rights. Anyone can find out anyone else's lock token by performing lock discovery. Locks MUST be enforced based upon whatever authentication mechanism is used by the server, not based on the secrecy of the token values.
ロック・トークンを持つことは、特別なアクセス権を提供していません。誰もがロックの発見を実行することにより、誰も他人のロック・トークンを見つけることができます。ロックは、どのような認証メカニズムに基づいて実施されなければならないトークン値の機密性に基づいていない、サーバーによって使用されます。
The opaquelocktoken URI scheme is designed to be unique across all resources for all time. Due to this uniqueness quality, a client may submit an opaque lock token in an If header on a resource other than the one that returned it.
opaquelocktoken URIスキームはすべての時間のためにすべてのリソース間で一意になるように設計されています。これによって一意の品質に、クライアントはそれを返されたもの以外のリソースであればヘッダ内の不透明なロックトークンを提出することができます。
All resources MUST recognize the opaquelocktoken scheme and, at minimum, recognize that the lock token does not refer to an outstanding lock on the resource.
すべてのリソースがopaquelocktokenスキームを認識し、最低でも、ロックトークンは、リソース上の優れたロックを参照していないことを認識しなければなりません。
In order to guarantee uniqueness across all resources for all time the opaquelocktoken requires the use of the Universal Unique Identifier (UUID) mechanism, as described in [ISO-11578].
[ISO-11578]に記載されているように、すべての時間opaquelocktokenすべてのリソースにわたって一意性を保証するために、汎用一意識別子（UUID）機構の使用を必要とします。
Opaquelocktoken generators, however, have a choice of how they create these tokens. They can either generate a new UUID for every lock token they create or they can create a single UUID and then add extension characters. If the second method is selected then the program generating the extensions MUST guarantee that the same extension will never be used twice with the associated UUID.
Opaquelocktoken発生器は、しかし、彼らはこれらのトークンを作成する方法の選択肢があります。彼らは、彼らが作成したり、彼らは、単一のUUIDを作成し、拡張文字を追加することができ、すべてのロック・トークンのための新しいUUIDを生成することができます。第二の方法が選択されている場合は、拡張子を生成するプログラムは、同じ拡張子が関連付けられたUUIDで二回使用されることはありませんことを保証しなければなりません。
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID production is the string representation of a UUID, as defined in [ISO-11578]. Note that white space (LWS) is not allowed between elements of this production.
OpaqueLockToken-URI = "opaquelocktoken：" UUID [拡張]。 [ISO-11578]で定義されるようにUUID生産は、UUIDのストリング表現です。空白（LWS）は、この生産の要素の間に許可されていないことに注意してください。
Extension = path ; path is defined in section 3.2.1 of RFC 2068 [RFC2068]
拡張=パス。パスは、RFC 2068 [RFC2068]のセクション3.2.1で定義されています
UUIDs, as defined in [ISO-11578], contain a "node" field that contains one of the IEEE 802 addresses for the server machine. As noted in section 17.8, there are several security risks associated with exposing a machine's IEEE 802 address. This section provides an alternate mechanism for generating the "node" field of a UUID which does not employ an IEEE 802 address. WebDAV servers MAY use this algorithm for creating the node field when generating UUIDs. The text in this section is originally from an Internet-Draft by Paul Leach and Rich Salz, who are noted here to properly attribute their work.
[ISO-11578]で定義されたUUIDは、サーバマシンのIEEE 802アドレスのいずれかを含む「ノード」フィールドを含みます。セクション17.8で述べたように、マシンのIEEE 802のアドレスをさらすことに関連するいくつかのセキュリティ上のリスクがあります。ここでは、IEEE 802アドレスを使用しないUUIDの「ノード」フィールドを生成するための代替メカニズムを提供します。 WebDAVサーバは、UUIDを生成するときにノードフィールドを作成するために、このアルゴリズムを使用するかもしれません。このセクション内のテキストは、適切に自分の仕事を帰するここで注目されているポール・リーチとリッチ・サルズにより、インターネットドラフト、出身です。
The ideal solution is to obtain a 47 bit cryptographic quality random number, and use it as the low 47 bits of the node ID, with the most significant bit of the first octet of the node ID set to 1. This bit is the unicast/multicast bit, which will never be set in IEEE 802 addresses obtained from network cards; hence, there can never be a conflict between UUIDs generated by machines with and without network cards.
理想的なソリューションは、このビットは、ユニキャストである1にノードIDのセットの最初のオクテットの最上位ビットと、47ビットの暗号品質の乱数を取得し、ノードIDの下位47ビットとしてそれを使用することです/ネットワークカードから取得したIEEE 802アドレスに設定されることはありませんマルチキャストビット、。したがって、ネットワークカードとないマシンで生成されたUUIDとの間に矛盾があることはありません。
If a system does not have a primitive to generate cryptographic quality random numbers, then in most systems there are usually a fairly large number of sources of randomness available from which one can be generated. Such sources are system specific, but often include:
システムは、暗号の品質乱数を生成するプリミティブを持っていない場合は、ほとんどのシステムでは通常、1つを生成することができ、そこから入手できるランダム性の源のかなり数が多いです。このようなソースは、システム固有のものですが、多くの場合、次のとおりです。
- the percent of memory in use - the size of main memory in bytes - the amount of free main memory in bytes - the size of the paging or swap file in bytes - free bytes of paging or swap file - the total size of user virtual address space in bytes - the total available user address space bytes - the size of boot disk drive in bytes - the free disk space on boot drive in bytes - the current time - the amount of time since the system booted - the individual sizes of files in various system directories - the creation, last read, and modification times of files in various system directories - the utilization factors of various system resources (heap, etc.) - current mouse cursor position - current caret position - current number of running processes, threads - handles or IDs of the desktop window and the active window - the value of stack pointer of the caller - the process and thread ID of caller - various processor architecture specific performance counters (instructions executed, cache misses, TLB misses)
- 使用中のメモリのパーセント - バイトのメインメモリのサイズ - バイト内の空きメインメモリの量 - ページングまたはスワップファイルの空きバイト - - バイトページングまたはスワップファイルのサイズの仮想ユーザの合計サイズバイト単位のアドレス空間 - 総利用可能なユーザーのアドレス空間のバイト - バイト単位でブートディスクドライブのサイズ - バイト単位でブートドライブの空きディスク領域 - 現在の時間 - システムが起動してからの時間の量 - ファイルの個々のサイズ現在のマウスカーソルの位置 - - 現在のキャレット位置 - さまざまなシステム・リソース（ヒープなど）の利用率 - さまざまなシステムディレクトリ内のファイルの作成、最後の読み込み、および修正時刻 - さまざまなシステムディレクトリ内の実行中のプロセスの現在の数、スレッド - ハンドルまたはデスクトップウィンドウのIDと、アクティブウィンドウ - 呼び出し元のスタックポインタの値 - 呼び出し元のプロセスおよびスレッドID - 様々なプロセッサアーキテクチャの特定のパフォーマンスカウンタ（命令が実行され、キャッシュ・M isses、TLBミス）
(Note that it is precisely the above kinds of sources of randomness that are used to seed cryptographic quality random number generators on systems without special hardware for their construction.)
（それが正確にそれらの構築のための特別なハードウェアなしにシステム上の暗号化品質の乱数発生器をシードするために使用されるランダム性の源の上記の種類であることに注意してください。）
In addition, items such as the computer's name and the name of the operating system, while not strictly speaking random, will help differentiate the results from those obtained by other systems.
また、このようなコンピュータ名とオペレーティングシステムの名前などの項目は、厳密に言えばランダムではないが、他のシステムによって得られたものの中から結果を区別するのに役立ちます。
The exact algorithm to generate a node ID using these data is system specific, because both the data available and the functions to obtain them are often very system specific. However, assuming that one can concatenate all the values from the randomness sources into a buffer, and that a cryptographic hash function such as MD5 is available, then any 6 bytes of the MD5 hash of the buffer, with the multicast bit (the high bit of the first byte) set will be an appropriately random node ID.
これらのデータを用いて、ノードIDを生成するための正確なアルゴリズムは、利用可能なデータおよび機能の両方を得ることがので、それらはしばしば非常にシステムに特異的であり、システム固有です。しかし、バッファのMD5ハッシュの任意の6つのバイトは、（マルチキャストビットで、次いで、高ビットを一つのバッファにランダムソースからのすべての値を連結することができると仮定すると、このようなMD5のような暗号ハッシュ関数が利用可能であること最初のバイトの）セットが適切にランダムなノードIDであろう。
Other hash functions, such as SHA-1, can also be used. The only requirement is that the result be suitably random _ in the sense that the outputs from a set uniformly distributed inputs are themselves uniformly distributed, and that a single bit change in the input can be expected to cause half of the output bits to change.
そのようなSHA-1などの他のハッシュ関数を使用することもできます。唯一の要件は、結果セットに均一に分布し、入力から出力を均一に分布自体であるという意味で_適切にランダムであること、及び入力における単一のビットの変化が出力ビットの半分を変化させることが期待できるということです。
Since server lock support is optional, a client trying to lock a resource on a server can either try the lock and hope for the best, or perform some form of discovery to determine what lock capabilities the server supports. This is known as lock capability discovery. Lock capability discovery differs from discovery of supported access control types, since there may be access control types without corresponding lock types. A client can determine what lock types the server supports by retrieving the supportedlock property.
サーバーロックのサポートはオプションなので、サーバー上のリソースをロックしようとしているクライアントは、サーバがサポートするロック機能を決定するために最善のロックと希望を試す、または発見のいくつかのフォームを行うことができます。これは、ロック機能の発見として知られています。ロック機能の発見は、ロックの種類に対応することなく、アクセス制御のタイプが存在する可能性があるため、サポートされるアクセス制御タイプの発見とは異なります。クライアントは、サーバがsupportedlockプロパティを取得することでサポートしているロックの種類を判別することができます。
Any DAV compliant resource that supports the LOCK method MUST support the supportedlock property.
LOCKメソッドをサポートする任意のDAV準拠のリソースはsupportedlockプロパティをサポートしなければなりません。
If another principal locks a resource that a principal wishes to access, it is useful for the second principal to be able to find out who the first principal is. For this purpose the lockdiscovery property is provided. This property lists all outstanding locks, describes their type, and where available, provides their lock token.
第2主は最初のプリンシパルが誰であるかを知ることができるようにするために別のプリンシパルロックプリンシパルがアクセスしたいリソースなら、それは便利です。この目的のためにlockdiscoveryプロパティが用意されています。このプロパティは、すべての未解決のロックを一覧表示し、その種類を説明し、利用可能な場合、そのロック・トークンを提供します。
Any DAV compliant resource that supports the LOCK method MUST support the lockdiscovery property.
LOCKメソッドをサポートする任意のDAV準拠のリソースはlockdiscoveryプロパティをサポートしなければなりません。
Although the locking mechanisms specified here provide some help in preventing lost updates, they cannot guarantee that updates will never be lost. Consider the following scenario:
ここで指定されたロック機構は、失われた更新を防止する上でいくつかの助けを提供しますが、彼らは更新が失われないことを保証することはできません。以下のシナリオを考えます：
Two clients A and B are interested in editing the resource ' index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking. Client A doesn't lock the document, but does a GET and begins editing. Client B does LOCK, performs a GET and begins editing. Client B finishes editing, performs a PUT, then an UNLOCK. Client A performs a PUT, overwriting and losing all of B's changes.
2つのクライアントAとBは、リソース「のindex.html」を編集するに興味を持っています。クライアントAは、HTTPクライアントではなく、WebDAVクライアントであり、従ってロックを実行する方法を知りません。クライアントAは、文書をロックしますが、GETを行い、編集を開始しません。クライアントBは、LOCKは、GETを実行し、編集を開始しますありません。クライアントBは、編集を終了し、次にPUT、UNLOCKを行います。クライアントAは、Bのすべての変更を上書きし、失う、PUTを実行します。
There are several reasons why the WebDAV protocol itself cannot prevent this situation. First, it cannot force all clients to use locking because it must be compatible with HTTP clients that do not comprehend locking. Second, it cannot require servers to support locking because of the variety of repository implementations, some of which rely on reservations and merging rather than on locking. Finally, being stateless, it cannot enforce a sequence of operations like LOCK / GET / PUT / UNLOCK.
WebDAVプロトコル自体がこのような状況を防ぐことができない理由はいくつかあります。まず、それがロックを理解していないHTTPクライアントとの互換性がなければならないため、ロックを使用するすべてのクライアントを強制することはできません。第二に、それがために予約およびロックの上にではなく、合併に依存しているそのうちのいくつかはリポジトリの実装、各種のロックをサポートするためのサーバーを必要とすることはできません。最後に、ステートレスであること、それがLOCK / GET / PUT / UNLOCKのような一連の操作を強制することはできません。
WebDAV servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requiring clients to lock resources before modifying them. Such servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources.
ロックをサポートするWebDAVサーバは、クライアントが誤ってそれらを変更する前に、リソースをロックするようにクライアントを必要とすることによって、お互いの変更を上書きする可能性を減らすことができます。このようなサーバーでは、効果的にリソースを変更するからHTTP 1.0とHTTP 1.1クライアントを防止するであろう。
WebDAV clients can be good citizens by using a lock / retrieve / write /unlock sequence of operations (at least by default) whenever they interact with a WebDAV server that supports locking.
WebDAVクライアントは、彼らがロックをサポートWebDAVサーバーと対話するたびに（少なくともデフォルトでは）操作のロック/取得/書き込み/ロック解除シーケンスを使用して善良な市民することができます。
HTTP 1.1 clients can be good citizens, avoiding overwriting other clients' changes, by using entity tags in If-Match headers with any requests that would modify resources.
HTTP 1.1クライアントがリソースを変更する任意の要求であればマッチヘッダーのエンティティタグを使用することにより、他のクライアントの変更を上書き避け、善良な市民ことができます。
Information managers may attempt to prevent overwrites by implementing client-side procedures requiring locking before modifying WebDAV resources.
情報マネージャは、WebDAVリソースを変更する前にロックを要求するクライアント側のプロシージャを実装することによって上書きすることを防止しようと試みることができます。
7 Write Lock
7書き込みロック
This section describes the semantics specific to the write lock type. The write lock is a specific instance of a lock type, and is the only lock type described in this specification.
このセクションでは、書き込みロックのタイプに固有の意味を説明しています。書き込みロックは、ロック・タイプの特定のインスタンスであり、そして本明細書に記載さだけロックタイプです。
A write lock MUST prevent a principal without the lock from successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, DELETE, or MKCOL on the locked resource. All other current methods, GET in particular, function independently of the lock.
書き込みロックが正常PUTを実行することからロックすることなく、主を防ぐ、POST、PROPPATCH、LOCK、UNLOCK、移動、削除、またはロックされたリソース上でMKCOLしなければなりません。他のすべての現在の方法は、独立してロックの特定の機能にGET。
Note, however, that as new methods are created it will be necessary to specify how they interact with a write lock.
新しいメソッドが作成されると、彼らが書き込みロックとの対話方法を指定する必要がありますこと、しかし、注意してください。
A successful request for an exclusive or shared write lock MUST result in the generation of a unique lock token associated with the requesting principal. Thus if five principals have a shared write lock on the same resource there will be five lock tokens, one for each principal.
排他的または共有書き込みロックの成功した要求は、要求元プリンシパルに関連付けられた一意のロック・トークンの生成をもたらさなければなりません。 5つのプリンシパルが同じリソースの共有書き込みロックを持っている場合、このように5つのロック・トークン、各主体の1が存在します。
While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas.
書き込みロックのないものは、リソースのプロパティを変更しないかもしれませんが、ライブプロパティの値を変更することは、そのスキーマの要件に、ロックされながらも、まだ可能です。
Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked.
ロックを尊重するために定義されている唯一の死者の特性やライブプロパティは書き込みがロックされている間変化しないことが保証されています。
It is possible to assert a write lock on a null resource in order to lock the name.
名前をロックするためにヌルリソースの書き込みロックを主張することが可能です。
A write locked null resource, referred to as a lock-null resource, MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and UNLOCK. A lock-null resource MUST appear as a member of its parent collection. Additionally the lock-null resource MUST have defined on it all mandatory DAV properties. Most of these properties, such as all the get* properties, will have no value as a lock-null resource does not support the GET method. Lock-Null resources MUST have defined values for lockdiscovery and supportedlock properties.
書き込みは、ヌル資源をロックし、ロックヌルリソースと呼ばれる、MKCOL、OPTIONS、PROPFIND、LOCK、PUT以外の任意のHTTP / 1.1またはDAV方法（方法不可）404（見つかりません）または405で応答しなければなりません、およびUNLOCK。ロックヌルリソースは、その親コレクションのメンバーとして現れなければなりません。さらに、ロックヌルリソースはそれにすべての必須DAVプロパティを定義している必要があります。こうしたすべてのget *プロパティとしてこれらのプロパティのほとんどは、GETメソッドをサポートしていないロックヌルリソースとして何の価値もありません。ロックヌルリソースはlockdiscoveryとsupportedlockのプロパティの値を定義しておく必要があります。
Until a method such as PUT or MKCOL is successfully executed on the lock-null resource the resource MUST stay in the lock-null state. However, once a PUT or MKCOL is successfully executed on a lock-null resource the resource ceases to be in the lock-null state.
このようPUTやMKCOLの方法までは成功し、リソースがロックヌル状態に滞在しなければならないロックヌルリソース上で実行されます。しかし、一度PUTやMKCOLが正常にリソースがロックヌル状態であることをやめるロックヌルリソース上で実行されます。
If the resource is unlocked, for any reason, without a PUT, MKCOL, or similar method having been successfully executed upon it then the resource MUST return to the null state.
リソースがPUT、MKCOL、又は類似の方法なしで、何らかの理由で、ロック解除されている場合は正常に、リソースがヌル状態に戻る必要があり、その上に実行されました。
A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners. As a consequence, when a principal issues a PUT or POST request to create a new resource under a URI which needs to be an internal member of a write locked collection to maintain HTTP namespace consistency, or issues a DELETE to remove a resource which has a URI which is an existing internal member URI of a write locked collection, this request MUST fail if the principal does not have a write lock on the collection.
または「深さ：無限」：「0深さ」により作成されたかどうかのコレクションの書き込みロック、ロック要求、非ロックオーナーがコレクションのメンバーURIの追加や削除を防ぐことができます。持っているリソースを削除するプリンシパルがDELETE HTTP名前空間の一貫性、または問題を維持するために、書き込みロックされたコレクションの内部メンバである必要がありURIの下に新しいリソースを作成するために、PUTやPOSTリクエストを発行結果として、プリンシパルは、コレクションの書き込みロックを持っていない場合、書き込みロックされたコレクションの既存の内部メンバーURIでURIは、この要求は失敗しなければなりません。
However, if a write lock request is issued to a collection containing member URIs identifying resources that are currently locked in a manner which conflicts with the write lock, the request MUST fail with a 423 (Locked) status code.
ライトロック要求が現在書き込みロックと競合するようにロックされたリソースを識別メンバーURIを含むコレクションに発行された場合は、要求は423（ロック）状態コードで失敗しなければなりません。
If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource MUST be automatically added to the lock. This is the only mechanism that allows a resource to be added to a write lock. Thus, for example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c then resource /a/b/c will be added to the write lock.
ロック所有者は、ロックされたコレクションの内部メンバーURIとして追加するリソースのURIが発生した場合は、新しいリソースが自動的にロックに加えなければなりません。これは、リソースが書き込みロックに追加することを可能にする唯一のメカニズムです。従って、例えば、もし収集/ A / B /書き込みでロックされ、リソース/ Cは次いで/ A / B / Cは、書き込みロックに追加されるリソース/ A / B / Cに移動されます。
If a user agent is not required to have knowledge about a lock when requesting an operation on a locked resource, the following scenario might occur. Program A, run by User A, takes out a write lock on a resource. Program B, also run by User A, has no knowledge of the lock taken out by Program A, yet performs a PUT to the locked resource. In this scenario, the PUT succeeds because locks are associated with a principal, not a program, and thus program B, because it is acting with principal A's credential, is allowed to perform the PUT. However, had program B known about the lock, it would not have overwritten the resource, preferring instead to present a dialog box describing the conflict to the user. Due to this scenario, a mechanism is needed to prevent different programs from accidentally ignoring locks taken out by other programs with the same authorization.
ユーザーエージェントは、ロックされたリソース上の操作を要求するときにロックについての知識を持っている必要がない場合は、次のシナリオが発生することがあります。プログラムAは、ユーザーAが運営する、リソースの書き込みロックを取り出します。また、ユーザーAが実行するプログラムBは、プログラムAによって取り出されたロックの知識がない、まだロックされたリソースにPUTを実行します。このシナリオでは、それは主Aの信任状で作用しているので、ロックは、主ではなく、プログラム、及びそのプログラムBに関連付けられているので、PUTが成功し、PUTを実行させることができます。しかし、ロックについて知らプログラムBは、それがユーザーに紛争を記述するダイアログボックスを提示する代わりに好む、リソースを上書きされていませんでした。このシナリオには、メカニズムが偶然同じ権限を持つ他のプログラムによって取り出されたロックを無視してから別のプログラムを防止するために必要とされます。
In order to prevent these collisions a lock token MUST be submitted by an authorized principal in the If header for all locked resources that a method may interact with or the method MUST fail. For example, if a resource is to be moved and both the source and destination are locked then two lock tokens must be submitted, one for the source and the other for the destination.
これらの衝突にロックトークンを防止するために、方法が相互作用することができる、またはメソッドが失敗する必要があるすべてのロックされたリソースの場合のヘッダの正規主によって提出されなければなりません。例えば、リソースがある場合に移動すると、送信元と宛先の両方が、2つのロックトークンを提出する必要があり、送信元および宛先のために他のための1つにロックされます。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html If: <http://www.ics.uci.edu/users/f/fielding/index.html> (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
COPY /~fielding/index.html HTTP / 1.1ホスト：www.ics.uci.edu先：http://www.ics.uci.edu/users/f/fielding/index.htmlの場合：<のhttp：// www.ics.uci.edu/users/f/fielding/index.html>（<opaquelocktoken：f81d4fae-7dec-11D0-a765-00a0c91e6bf6>）
>>Response
>>回答
HTTP/1.1 204 No Content
HTTP / 1.1 204コンテンツなし
In this example, even though both the source and destination are locked, only one lock token must be submitted, for the lock on the destination. This is because the source resource is not modified by a COPY, and hence unaffected by the write lock. In this example, user agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in the underlying transport layer.
この例では、送信元と宛先の両方がロックされているにもかかわらず、唯一のロックトークンが先にロックするために、提出しなければなりません。ソースリソースがCOPYによって修飾され、書き込みロックによって、したがって影響を受けないためです。この例では、ユーザエージェント認証は以前に、基礎となるトランスポート層では、HTTPプロトコルの範囲外の機構を介して発生しています。
A COPY method invocation MUST NOT duplicate any write locks active on the source. However, as previously noted, if the COPY copies the resource into a collection that is locked with "Depth: infinity", then the resource will be added to the lock.
COPYメソッドの呼び出しは、ソース上のアクティブなすべての書き込みロックを複製してはなりません。前述のようにCOPYコピー「深さ：無限」でロックされているコレクションにリソースしかし、もし、そのリソースは、ロックに追加されます。
A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. However, the resource is subject to being added to an existing lock at the destination, as specified in section 7.5. For example, if the MOVE makes the resource a child of a collection that is locked with "Depth: infinity", then the resource will be added to that collection's lock. Additionally, if a resource locked with "Depth: infinity" is moved to a destination that is within the scope of the same lock (e.g., within the namespace tree covered by the lock), the moved resource will again be a added to the lock. In both these examples, as specified in section 7.6, an If header must be submitted containing a lock token for both the source and destination.
書き込みロックされたリソースに成功したMOVE要求は、リソースと書き込みロックを移動してはなりません。しかしながら、リソースはセクション7.5で指定されるように、先の既存のロックに追加される対象です。 MOVEは、リソースにロックされているコレクションの子行う場合たとえば、「深さ：無限大」を、そのリソースはそのコレクションのロックに追加されます。 「深さ：無限」でロックされたリソースがあればまた、（ロックによってカバーされた名前空間ツリー内の、例えば）同じロックの範囲内で目的地に移動し、移動リソースは再びロックに追加されます。これらの例の両方で、セクション7.6で指定されるように、もしヘッダは送信元と宛先の両方のためのロック・トークンを含む提出されなければなりません。
A client MUST NOT submit the same write lock request twice. Note that a client is always aware it is resubmitting the same lock request because it must include the lock token in the If header in order to make the request for a resource that is already locked.
クライアントは二回同じ書き込みロック要求を提出してはなりません。クライアントは常にそれが既にロックされているリソースに対する要求を行うためにもしヘッダ内のロック・トークンを含める必要がありますので、それが同じロック要求を再送信されて認識していることに注意してください。
However, a client may submit a LOCK method with an If header but without a body. This form of LOCK MUST only be used to "refresh" a lock. Meaning, at minimum, that any timers associated with the lock MUST be re-set.
ただし、クライアントは、Ifヘッダーではなく、本体なしでLOCK方法を提出することができます。 LOCKのこの形式は、ロックを「リフレッシュ」するために使用しなければなりません。ロックに関連する任意のタイマーを再設定する必要があり、最低でも、意味します。
A server may return a Timeout header with a lock refresh that is different than the Timeout header returned when the lock was originally requested. Additionally clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers submitted by the client.
サーバーは、ロックが最初に要求されたときに返されたTimeoutヘッダーと異なるロックリフレッシュにTimeoutヘッダーを返すことがあります。さらに、クライアントはロックリフレッシュ要求を任意の値のタイムアウトヘッダを提出することができます。サーバは、いつものように、クライアントから提出されたタイムアウトヘッダを無視することができます。
If an error is received in response to a refresh LOCK request the client SHOULD assume that the lock was not refreshed.
エラーがリフレッシュLOCK要求に応答して受信された場合、クライアントは、ロックがリフレッシュされなかったことを想定する必要があります。
8 HTTP Methods for Distributed Authoring
分散オーサリングのための8つのHTTPメソッド
The following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources MUST use XML parsers that are compliant with [REC-XML]. All XML used in either requests or responses MUST be, at minimum, well formed. If a server receives ill-formed XML in a request it MUST reject the entire request with a 400 (Bad Request). If a client receives ill-formed XML in a response then it MUST NOT assume anything about the outcome of the executed method and SHOULD treat the server as malfunctioning.
次の新しいHTTPメソッドは、リクエストとレスポンスのフォーマットとしてXMLを使用します。すべてのDAV対応のクライアントとリソースは[REC-XML]に準拠したXMLパーサを使用しなければなりません。要求または応答のいずれかで使用されるすべてのXMLは、最低でも、十分に形成されなければなりません。サーバがリクエストで病気に成形されたXMLを受信した場合には、400（不正な要求）で全体の要求を拒絶しなければなりません。クライアントが応答で病気に成形されたXMLを受信した場合、それは実行されたメソッドの結果については何も仮定してはいけませんし、誤動作などのサーバーを扱うべきです。
The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URIs. All DAV compliant resources MUST support the PROPFIND method and the propfind XML element (section 12.14) along with all XML elements defined for use with that element.
リソースが有する集合である場合PROPFINDメソッドは、リソースは、任意の内部部材を有していない場合、Request-URIによって識別されるリソースに定義されたプロパティを取得し、またはリクエストURIおよび潜在そのメンバー・リソースによって識別されたリソースに内部メンバーのURI。全てのDAV準拠したリソースは、その要素で使用するために定義されたすべてのXML要素と一緒にPROPFINDメソッドとPROPFIND XML要素（セクション12.14）をサポートしなければなりません。
A client may submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND on a collection resource with internal member URIs. DAV compliant servers MUST support the "0", "1" and "infinity" behaviors. By default, the PROPFIND method without a Depth header MUST act as if a "Depth: infinity" header was included.
クライアントは、内部部材のURIに収集リソース上のPROPFINDと「0」、「1」、または「無限」の値を有する奥行きヘッダを提出することができます。 DAV準拠したサーバーには、「0」、「1」と「無限大」の行動をサポートしなければなりません。デフォルトでは、深さヘッダーなしのPROPFINDメソッドがあるかのように行動しなければならない「深さ：無限」ヘッダが含まれていました。
A client may submit a propfind XML element in the body of the request method describing what information is being requested. It is possible to request particular property values, all property values, or a list of the names of the resource's properties. A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as a request for the names and values of all properties.
クライアントが要求されている情報記述リクエストメソッドの本体にPROPFIND XML要素を提出することができます。特定のプロパティ値を、すべてのプロパティ値、またはリソースのプロパティの名前のリストを要求することが可能です。クライアントがリクエストボディを提出しないこともできます。空PROPFIND要求体は、すべてのプロパティの名前と値の要求として処理されなければなりません。
All servers MUST support returning a response of content type text/xml or application/xml that contains a multistatus XML element that describes the results of the attempts to retrieve the various properties.
すべてのサーバーは、さまざまなプロパティを取得しようとする試みの結果を記述するmultistatus XML要素が含まれているコンテンツタイプtext / xmlまたはapplication / xmlの応答を返すサポートしなければなりません。
If there is an error retrieving a property then a proper error result MUST be included in the response. A request to retrieve the value of a property which does not exist is an error and MUST be noted, if the response uses a multistatus XML element, with a response XML element which contains a 404 (Not Found) status value.
プロパティを取得中にエラーがある場合、適切なエラー結果は、応答に含まれなければなりません。存在しないプロパティの値を取得するための要求がエラーであると応答が404（見つかりません）ステータス値を含む応答XML要素と、multistatus XML要素を使用する場合、注意しなければなりません。
Consequently, the multistatus XML element for a collection resource with member URIs MUST include a response XML element for each member URI of the collection, to whatever depth was requested. Each response XML element MUST contain an href XML element that gives the URI of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource with internal member URIs are returned as a flat list whose order of entries is not significant.
これにより、メンバーURIに収集リソースのmultistatus XML要素は、要求されたどのような深さまで、コレクションの各メンバーURIの応答XML要素を含まなければなりません。各応答XML要素は、支柱XML要素のプロパティが定義されているリソースのURIを与えるHREF XML要素を含まなければなりません。内部メンバーURIを持つコレクションリソースのPROPFINDの結果は、そのためのエントリの重要ではないフラットリストとして返されます。
In the case of allprop and propname, if a principal does not have the right to know whether a particular property exists then the property should be silently excluded from the response.
allpropとPROPNAMEの場合には、主は、特定のプロパティは、次に存在するプロパティはサイレント応答から除外すべきかどうかを知る権利を持っていない場合。
The results of this method SHOULD NOT be cached.
この方法の結果はキャッシュされるべきではありません。
>>Request
>>リクエスト
PROPFIND /file HTTP/1.1 Host: www.foo.bar Content-type: text/xml; charset="utf-8" Content-Length: xxxx
PROPFIND /ファイルHTTP / 1.1ホスト：www.foo.barコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop xmlns:R="http://www.foo.bar/boxschema/"> <R:bigbox/> <R:author/> <R:DingALing/> <R:Random/> </D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：のxmlns小道具：R = "http://www.foo.bar/boxschema / "> <R：bigbox /> <R：著者/> <R：DingALing /> <R：ランダム/> </ D：プロップ> </ D：PROPFIND>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.foo.bar/file</D:href> <D:propstat> <D:prop xmlns:R="http://www.foo.bar/boxschema/"> <R:bigbox> <R:BoxType>Box type A</R:BoxType> </R:bigbox> <R:author> <R:Name>J.J. Johnson</R:Name> </R:author> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> <D:propstat> <D:prop><R:DingALing/><R:Random/></D:prop>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.foo.bar/ファイル</ D：HREF> <D：propstat> <D：プロペラのxmlns：R = "http://www.foo.bar/boxschema/"> <R：bigbox> <R：BoxType>ボックスタイプA </ R：BoxType> </ R：bigbox> <R：著者> <R：名> JJジョンソン</ R：名前> </ R：著者> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> <D：propstat> <D：小道具> <R：DingALing /> <R：ランダム/> </ D：小道具>
<D:status>HTTP/1.1 403 Forbidden</D:status> <D:responsedescription> The user does not have access to the DingALing property. </D:responsedescription> </D:propstat> </D:response> <D:responsedescription> There has been an access violation error. </D:responsedescription> </D:multistatus>
<D：状態> HTTP / 1.1 403禁止</ D：状態> <D：responsedescription>ユーザーがDingALingプロパティにアクセスすることはできません。 </ D：responsedescription> </ D：propstat> </ D：レスポンス> <D：responsedescription>アクセス違反エラーが発生しました。 </ D：responsedescription> </ D：multistatus>
In this example, PROPFIND is executed on a non-collection resource http://www.foo.bar/file. The propfind XML element specifies the name of four properties whose values are being requested. In this case only two properties were returned, since the principal issuing the request did not have sufficient access rights to see the third and fourth properties.
この例では、PROPFINDは、非コレクションリソースhttp://www.foo.bar/file上で実行されます。 PROPFINDのXML要素は、値が要求されている4つのプロパティの名前を指定します。リクエストを発行する元本は、第3および第4のプロパティを参照するには十分なアクセス権を持っていなかったので、ここでは2つだけのプロパティは、返されました。
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Depth: 1 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
PROPFIND /コンテナ/ HTTP / 1.1ホスト：www.foo.bar深さ：1のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:allprop/> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：= "DAV：" D> <D：allprop /> </ D：PROPFIND>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.foo.bar/container/</D:href> <D:propstat> <D:prop xmlns:R="http://www.foo.bar/boxschema/"> <R:bigbox> <R:BoxType>Box type A</R:BoxType> </R:bigbox> <R:author>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.foo.bar/容器/ </ D：HREF> <D：propstat> <D：のxmlns小道具：R = "http://www.foo.bar/boxschema/"> <R：bigbox> <R：BoxType>ボックスタイプA < / R：BoxType> </ R：bigbox> <R：著者>
<R:Name>Hadrian</R:Name> </R:author> <D:creationdate> 1997-12-01T17:42:21-08:00 </D:creationdate> <D:displayname> Example collection </D:displayname> <D:resourcetype><D:collection/></D:resourcetype> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>http://www.foo.bar/container/front.html</D:href> <D:propstat> <D:prop xmlns:R="http://www.foo.bar/boxschema/"> <R:bigbox> <R:BoxType>Box type B</R:BoxType> </R:bigbox> <D:creationdate> 1997-12-01T18:27:21-08:00 </D:creationdate> <D:displayname> Example HTML resource </D:displayname> <D:getcontentlength> 4525 </D:getcontentlength> <D:getcontenttype> text/html </D:getcontenttype> <D:getetag> zzyzx </D:getetag> <D:getlastmodified> Monday, 12-Jan-98 09:25:56 GMT </D:getlastmodified>
<R：名>ハドリアヌス</ R：名前> </ R：著者> <D：CreationDateプロパティ> 1997-12-01T17：42：21から08：00 </ D：CreationDateプロパティ> <D：のDisplayName>例収集< / D：表示名> <D：resourcetypeの> <D：コレクション/> </ D：resourcetypeの> <D：supportedlock> <D：lockentry> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> < D：種類のLockType> <D：書き込み/> </ D：たlocktype> </ D：lockentry> <D：lockentry> <D：LOCKSCOPE> <D：共有/> </ D：LOCKSCOPE> <D：種類のLockType> < D：/> </ D書き込み：たlocktype> </ D：lockentry> </ D：supportedlock> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat > </ D：レスポンス> <D：レスポンス> <D：HREF> http://www.foo.bar/container/front.html </ D：HREF> <D：propstat> <D：R：のxmlnsプロプ= "http://www.foo.bar/boxschema/"> <R：bigbox> <R：BoxType>ボックスタイプB </ R：BoxType> </ R：bigbox> <D：CreationDateプロパティ> 1997-12- 01T18：27：21から08：00 </ D：CreationDateプロパティ> <D：のDisplayName>実施例HTMLリソース</ D：表示名> <D：getcontentlength> 4525 </ D：getcontentlength> <D：GETCONTENTTYPE>テキスト/ HTMLの< / D：GETCONTENTTYPE> <D：getetag> zzyzx </ D：getetag> <D：getlastmodified>月曜日、12-JAN-98 09：25：5 6 GMT </ D：getlastmodified>
<D:resourcetype/> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
<D：resourcetypeの/> <D：supportedlock> <D：lockentry> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：たlocktype> <D：書き込み/> </ D：種類のLockType> </ D：lockentry> <D：lockentry> <D：LOCKSCOPE> <D：共有/> </ D：LOCKSCOPE> <D：たlocktype> <D：書き込み/> </ D：たlocktype> </ D：lockentry > </ D：supportedlock> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ D：multistatus>
In this example, PROPFIND was invoked on the resource http://www.foo.bar/container/ with a Depth header of 1, meaning the request applies to the resource and its children, and a propfind XML element containing the allprop XML element, meaning the request should return the name and value of all properties defined on each resource.
この例では、PROPFINDリクエストは、リソースとその子、およびallprop XML要素を含むPROPFIND XML要素に適用される意味、1の深さヘッダーで資源http://www.foo.bar/container/に呼び出されました、要求を意味する各リソースで定義されたすべてのプロパティの名前と値を返す必要があります。
The resource http://www.foo.bar/container/ has six properties defined on it:
リソースhttp://www.foo.bar/container/はそれに定義された6つのプロパティがあります。
http://www.foo.bar/boxschema/bigbox, http://www.foo.bar/boxschema/author, DAV:creationdate, DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
http://www.foo.bar/boxschema/bigbox、http://www.foo.bar/boxschema/author、DAV：のCreationDate、DAV：displaynameは、DAV：resourcetypeの、およびDAV：supportedlock。
The last four properties are WebDAV-specific, defined in section 13. Since GET is not supported on this resource, the get* properties (e.g., getcontentlength) are not defined on this resource. The DAV-specific properties assert that "container" was created on December 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT (creationdate), has a name of "Example collection" (displayname), a collection resource type (resourcetype), and supports exclusive write and shared write locks (supportedlock).
最後の4つの特性がWebDAVの固有、GETがこのリソースでサポートされていないので、セクション13で定義され、*得る特性（例えば、getcontentlength）は、このリソースで定義されていません。 DAV-固有の性質は、「コンテナ」が8時間西GMT（のCreationDate）の時間帯で、5時42分21秒PMで、1997年12月1日に作成されたことを主張し、「例集」（表示名）の名前を持ち、コレクションのリソースタイプ（resourcetypeの）、および排他的な書き込みと共有書き込みロック（supportedlock）をサポートしています。
The resource http://www.foo.bar/container/front.html has nine properties defined on it:
リソースhttp://www.foo.bar/container/front.htmlはそれに定義された9つのプロパティがあります。
http://www.foo.bar/boxschema/bigbox (another instance of the "bigbox" property type), DAV:creationdate, DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
http://www.foo.bar/boxschema/bigbox（ "bigbox" プロパティタイプの別のインスタンス）、DAV：CreationDateプロパティ、DAV：表示名、DAV：getcontentlength、DAV：GETCONTENTTYPE、DAV：getetag、DAV：getlastmodified、DAV ：resourcetypeの、およびDAV：supportedlock。
The DAV-specific properties assert that "front.html" was created on December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT (creationdate), has a name of "Example HTML resource" (displayname), a content length of 4525 bytes (getcontentlength), a MIME type of "text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), was last modified on Monday, January 12, 1998, at 09:25:56 GMT (getlastmodified), has an empty resource type, meaning that it is not a collection (resourcetype), and supports both exclusive write and shared write locks (supportedlock).
DAV-固有の性質は、「front.htmlが」8時間西GMT（のCreationDate）のタイムゾーンで、午前6時27分21秒PMで、1997年12月1日に作成されたことを主張し、（「例HTMLリソース」の名前を持っています表示名）、4525バイト（getcontentlength）のコンテンツ長、 "テキスト/ HTML"（GETCONTENTTYPE）のMIMEタイプ、 "zzyzx"（getetag）のエンティティタグは、1998年1月12日（月曜日）に最後に変更された、09で：25：56 GMT（getlastmodified）、それはコレクション（resourcetypeの）ではありません、そして排他的書き込みと共有書き込みロック（supportedlock）の両方をサポートしていることを意味し、空のリソースタイプがあります。
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
PROPFIND /コンテナ/ HTTP / 1.1ホスト：www.foo.barのコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <propfind xmlns="DAV:"> <propname/> </propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <PROPFINDのxmlns = "DAV："> <PROPNAME /> </ PROPFIND>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:"> <response> <href>http://www.foo.bar/container/</href> <propstat> <prop xmlns:R="http://www.foo.bar/boxschema/"> <R:bigbox/> <R:author/> <creationdate/> <displayname/> <resourcetype/> <supportedlock/> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>http://www.foo.bar/container/front.html</href>
<？xml version = "1.0" エンコード= "UTF-8"？> <multistatusのxmlns = "DAV："> <レスポンス> <HREF> http://www.foo.bar/container/ </ HREF> <propstat > <支柱のxmlns：R = "http://www.foo.bar/boxschema/"> <R：bigbox /> <R：著者/> <CreationDateプロパティ/> <DisplayNameに/> <resourcetypeの/> <supportedlock /> </小道具> <状態> HTTP / 1.1 200 OK </ステータス> </ propstat> </レスポンス> <レスポンス> <HREF> http://www.foo.bar/container/front.html </ HREF>
<propstat> <prop xmlns:R="http://www.foo.bar/boxschema/"> <R:bigbox/> <creationdate/> <displayname/> <getcontentlength/> <getcontenttype/> <getetag/> <getlastmodified/> <resourcetype/> <supportedlock/> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus>
<propstat> <小道具のxmlns：R = "http://www.foo.bar/boxschema/"> <R：bigbox /> <CreationDateプロパティ/> <DisplayNameに/> <getcontentlength /> <GETCONTENTTYPE /> <getetag /> <getlastmodified /> <resourcetypeの/> <supportedlock /> </小道具> <状態> HTTP / 1.1 200 OK </ステータス> </ propstat> </レスポンス> </ multistatus>
In this example, PROPFIND is invoked on the collection resource http://www.foo.bar/container/, with a propfind XML element containing the propname XML element, meaning the name of all properties should be returned. Since no Depth header is present, it assumes its default value of "infinity", meaning the name of the properties on the collection and all its progeny should be returned.
この例では、PROPFINDは、すべてのプロパティの名前が返されるべきである意味、PROPNAMEのXML要素を含むPROPFIND XML要素で、コレクションリソースhttp://www.foo.bar/container/に呼び出されます。何の深さヘッダーが存在しないので、それは、コレクションのプロパティの名前を意味し、「無限大」のデフォルト値を想定し、そのすべての子孫が返されます。
Consistent with the previous example, resource http://www.foo.bar/container/ has six properties defined on it, http://www.foo.bar/boxschema/bigbox, http://www.foo.bar/boxschema/author, DAV:creationdate, DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
前の例と一致して、リソースhttp://www.foo.bar/container/が上で定義された6つの特性を有する、http://www.foo.bar/boxschema/bigbox、http://www.foo.bar/ boxschema /著者、DAV：のCreationDate、DAV：displaynameは、DAV：resourcetypeの、およびDAV：supportedlock。
The resource http://www.foo.bar/container/index.html, a member of the "container" collection, has nine properties defined on it, http://www.foo.bar/boxschema/bigbox, DAV:creationdate, DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
リソースhttp://www.foo.bar/container/index.html、「コンテナ」コレクションのメンバーは、それに定義された9つの性質を持っている、http://www.foo.bar/boxschema/bigbox、DAV： CreationDate、DAV：displaynameは、DAV：getcontentlength、DAV：GETCONTENTTYPE、DAV：getetag、DAV：getlastmodified、DAV：resourcetypeの、およびDAV：supportedlock。
This example also demonstrates the use of XML namespace scoping, and the default namespace. Since the "xmlns" attribute does not contain an explicit "shorthand name" (prefix) letter, the namespace applies by default to all enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace schema.
また、この例では、XML名前空間スコープ、およびデフォルトの名前空間の使用方法を示しています。 「のxmlns」属性は、明示的な「速記名」（接頭辞）文字が含まれていないので、名前空間は、すべての囲まれた要素にデフォルトで適用されます。名前空間のスキーマ：このため、明示的にそれらが属する名前空間を述べていないすべての要素は、「DAV」のメンバーです。
The PROPPATCH method processes instructions specified in the request body to set and/or remove properties defined on the resource identified by the Request-URI.
PROPPATCHメソッドは、設定および/またはRequest-URIによって識別されるリソース上で定義されたプロパティを削除する要求本体に指定された命令を処理します。
All DAV compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements of the DAV schema. Execution of the directives in this method is, of course, subject to access control constraints. DAV compliant resources SHOULD support the setting of arbitrary dead properties.
すべてのDAV対応のリソースがPROPPATCHメソッドをサポートしなければならないとpropertyupdateを使用して、指定された命令を処理しなければならない、セット、およびDAVスキーマのXML要素を削除します。この方法のディレクティブの実行は、当然のことながら、制御の制約にアクセスすることがあります。準拠したリソースをDAVすることは、任意の死者のプロパティの設定をサポートする必要があります。
The request message body of a PROPPATCH method MUST contain the propertyupdate XML element. Instruction processing MUST occur in the order instructions are received (i.e., from top to bottom). Instructions MUST either all be executed or none executed. Thus if any error occurs during processing all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in section 12.13.
PROPPATCHメソッドのリクエストメッセージ本体はpropertyupdate XML要素を含まなければなりません。発注指示に発生しなければならない命令処理（すなわち、上から下に）受信されます。命令は、どちらかのすべての実行されなければならないか、どれも実行されません。何らかのエラーがすべて実行された命令を処理中に発生した場合したがって取り消し、適切なエラー結果を返さなければなりません。命令処理の詳細は、セットの定義に見出され、セクション12.13の指示を除去することができます。
The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response.
以下は、1つのこの方法のための207（マルチステータス）応答で使用することが予想される応答コードの例です。ただし、明示的に禁止しない限り、任意の2/3/4 / 5xxの一連の応答コード207（マルチステータス）応答に使用することができること。
200 (OK) - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 (Created) seems inappropriate.
200（OK） - コマンドが成功しました。そこセットの混合物であることと、体内で除去することができるように、（作成）201が不適切と思われます。
403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.
403（禁止） - クライアントは、サーバが指定しないことを選択した理由のために、プロパティのいずれかを変更することはできません。
409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property. This includes trying to set read-only properties.
409（競合） - クライアントは、その意味論性のために適切でない値を提供しました。これは読み取り専用のプロパティを設定しようとしています。
423 (Locked) - The specified resource is locked and the client either is not a lock owner or the lock type requires a lock token to be submitted and the client did not submit it.
423（ロック） - 指定されたリソースがロックされ、クライアントがロック所有者やロックタイプを提出するロック・トークンを必要とされていないか、クライアントはそれを提出しませんでした。
507 (Insufficient Storage) - The server did not have sufficient space to record the property.
507（ストレージ不足） - サーバがプロパティを記録するのに十分なスペースがありませんでした。
>>Request
>>リクエスト
PROPPATCH /bar.html HTTP/1.1 Host: www.foo.com Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
PROPPATCH /bar.html HTTP / 1.1ホスト：www.foo.comのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:propertyupdate xmlns:D="DAV:" xmlns:Z="http://www.w3.com/standards/z39.50/"> <D:set> <D:prop> <Z:authors> <Z:Author>Jim Whitehead</Z:Author> <Z:Author>Roy Fielding</Z:Author> </Z:authors> </D:prop> </D:set> <D:remove> <D:prop><Z:Copyright-Owner/></D:prop> </D:remove> </D:propertyupdate>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：propertyupdateのxmlns：D = "DAV：" のxmlns：Z = "http://www.w3.com/standards/z39.50/ 「> <D：セット> <D：小道具> <Z：著者> <Z：著者>ジム・ホワイトヘッド</ Z：著者> <Z：著者>ロイ・フィールディング</ Z：著者> </ Z：著者> < / D：プロップ> </ D：セット> <D：削除> <D：> <Zプロパ：著作権、所有者/> </ D：プロップ> </ D：削除> </ D：propertyupdate>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:" xmlns:Z="http://www.w3.com/standards/z39.50"> <D:response> <D:href>http://www.foo.com/bar.html</D:href> <D:propstat> <D:prop><Z:Authors/></D:prop> <D:status>HTTP/1.1 424 Failed Dependency</D:status> </D:propstat> <D:propstat> <D:prop><Z:Copyright-Owner/></D:prop> <D:status>HTTP/1.1 409 Conflict</D:status> </D:propstat> <D:responsedescription> Copyright Owner can not be deleted or altered.</D:responsedescription> </D:response> </D:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV：" のxmlns：Z = "http://www.w3.com/standards/z39.50" > <D：レスポンス> <D：HREF> http://www.foo.com/bar.html </ D：HREF> <D：propstat> <D：プロペラ> <Z：著者/> </ D：小道具> <D：状態> </ D：propstat> <D：propstat> <D：> <Z小道具：著作権-所有者/> </ D：小道具> <状態> HTTP / 1.1 424は、依存関係</ D失敗しました。 D：ステータス> HTTP / 1.1 409競合</ D：状態> </ D：propstat> <D：responsedescription>著作権所有者は、削除または変更することができない</ D：responsedescription> </ D：レスポンス> </ D ：multistatus>
In this example, the client requests the server to set the value of the http://www.w3.com/standards/z39.50/Authors property, and to remove the property http://www.w3.com/standards/z39.50/Copyright-Owner. Since the Copyright-Owner property could not be removed, no property modifications occur. The 424 (Failed Dependency) status code for the Authors property indicates this action would have succeeded if it were not for the conflict with removing the Copyright-Owner property.
この例では、クライアントがhttp://www.w3.com/standards http://www.w3.com/standards/z39.50/Authorsプロパティの値を設定し、プロパティを削除するためにサーバに要求します/z39.50/Copyright-Owner。著作権-Ownerプロパティを削除することができなかったので、何のプロパティの変更は行われません。著者のプロパティの424（失敗した依存）ステータスコードは、それが著作権所有者プロパティを削除するとの競合がなければ、このアクションが成功しただろうを示しています。
The MKCOL method is used to create a new collection. All DAV compliant resources MUST support the MKCOL method.
MKCOLメソッドは、新しいコレクションを作成するために使用されます。全てのDAV準拠したリソースは、MKCOLメソッドをサポートしなければなりません。
MKCOL creates a new collection resource at the location specified by the Request-URI. If the resource identified by the Request-URI is non-null then the MKCOL MUST fail. During MKCOL processing, a server MUST make the Request-URI a member of its parent collection, unless the Request-URI is "/". If no such ancestor exists, the method MUST fail. When the MKCOL operation creates a new collection resource, all ancestors MUST already exist, or the method MUST fail with a 409 (Conflict) status code. For example, if a request to create collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/ exists, the request must fail.
MKCOLは、Request-URIで指定された場所に新しいコレクション・リソースを作成します。 Request-URIによって識別されるリソースが非nullの場合、MKCOLは失敗しなければなりません。要求URIは「/」でない限り、MKCOL処理中に、サーバーは、要求URIその親コレクションのメンバーにする必要があります。そのような祖先が存在しない場合、メソッドは失敗しなければなりません。 MKCOL操作が新しいコレクションのリソースを作成するとき、すべての祖先は、すでに存在している必要があり、又は方法409（競合）ステータスコードを失敗しなければなりません。リクエストが収集/ A / B / C / Dを作成するために/構成されており、どちらも/ A / B /も/ A / B / C /存在している場合たとえば、要求は失敗しなければなりません。
When MKCOL is invoked without a request body, the newly created collection SHOULD have no members.
MKCOLがリクエストボディなしで呼び出された場合、新しく作成されたコレクションにはメンバーを持っていないはずです。
A MKCOL request message may contain a message body. The behavior of a MKCOL request when the body is present is limited to creating collections, members of a collection, bodies of members and properties on the collections or members. If the server receives a MKCOL request entity type it does not support or understand it MUST respond with a 415 (Unsupported Media Type) status code. The exact behavior of MKCOL for various request media types is undefined in this document, and will be specified in separate documents.
MKCOL要求メッセージは、メッセージ本文を含んでいてもよいです。体が存在するMKCOL要求の挙動はコレクションやメンバーのメンバーおよびプロパティのコレクション、コレクションのメンバー、遺体を作成するに制限されています。サーバはMKCOL要求エンティティタイプを受信した場合、それは415（サポートされていないメディアタイプ）ステータスコードで応じなければなりませんサポートしたり、理解していません。様々な要求のメディアタイプのMKCOLの正確な動作は、このドキュメントで定義されていない、と別の文書で指定されます。
Responses from a MKCOL request MUST NOT be cached as MKCOL has non-idempotent semantics.
MKCOLが非冪等の意味を持つようMKCOL要求からの応答をキャッシュしてはなりません。
201 (Created) - The collection or structured resource was created in its entirety.
201（作成者） - コレクションまたは構造化されたリソースは、その全体で作成されました。
403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its namespace, or 2) the parent collection of the Request-URI exists but cannot accept members.
403（禁止） - これは、2つの条件の少なくともいずれかを示します。1）サーバーは、その名前空間内の指定された場所でコレクションの作成を許可しない、または2）のRequest-URIの親コレクションが存在しますが、メンバーを受け入れることはできませんが。
405 (Method Not Allowed) - MKCOL can only be executed on a deleted/non-existent resource.
405（メソッドが許可されていません） - MKCOLはのみ削除/非存在しないリソース上で実行することができます。
409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created.
409（競合） - 一点の以上の中間コレクションが作成されるまでのコレクションがRequest-URIで行うことはできません。
415 (Unsupported Media Type)- The server does not support the request type of the body.
415（サポートされていないメディアタイプ） - サーバーは、身体の要求タイプをサポートしていません。
507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of this method.
507（ストレージ不足） - リソースは、この方法を実行した後、リソースの状態を記録するための十分なスペースがありません。
This example creates a collection called /webdisc/xfiles/ on the server www.server.org.
この例では、サーバー上のwww.server.org / webdisc / XFILES /と呼ばれるコレクションを作成します。
>>Request
>>リクエスト
MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.server.org
MKCOL / webdisc / XFILES / HTTP / 1.1ホスト：www.server.org
>>Response
>>回答
HTTP/1.1 201 Created
作成されたHTTP / 1.1 201
The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is identified by the Request-URI" [RFC2068]. GET when applied to a collection may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether. Hence it is possible that the result of a GET on a collection will bear no correlation to the membership of the collection.
コレクションに適用した場合GETは、[RFC2068]「のRequest-URIによって識別されるどんな情報（エンティティの形で）検索」として定義されているので、GETのセマンティクスは、不変です。コレクションに適用されたときにGET「のindex.html」リソース、コレクションの内容の判読可能なビュー、または完全に何か他のものの内容を返すことがあります。したがって、コレクションのGETの結果は、コレクションのメンバーシップには相関関係を負いません可能性があります。
Similarly, since the definition of HEAD is a GET without a response message body, the semantics of HEAD are unmodified when applied to collection resources.
HEADの定義は、応答メッセージのボディせずGETであるため、収集リソースに適用した場合、同様に、ヘッドのセマンティクスが変更されません。
Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus the semantics of POST are unmodified when applied to a collection.
定義によりPOSTによって実行される実際の機能はサーバによって決定され、多くの場合、特定のリソースに依存するので、それは主に未定義であるので、コレクションに適用されるPOSTの挙動が有意変更することができません。コレクションに適用されたときにこのようにPOSTのセマンティクスは変更されません。
If the DELETE method is issued to a non-collection resource whose URIs are an internal member of one or more collections, then during DELETE processing a server MUST remove any URI for the resource identified by the Request-URI from collections which contain it as a member.
DELETEメソッドは、そのURIの一つ以上のコレクションの内部メンバである非コレクションリソースに発行された場合、その後時としてそれを含むコレクションからのRequest-URIによって識別されたリソースのための任意のURIを削除する必要があり、サーバの処理DELETEメンバー。
The DELETE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header with a DELETE on a collection with any value but infinity.
「：無限の深さ」ヘッダそれに使用されたかのように、コレクションに対するDELETEメソッドが行動しなければなりません。クライアントは、任意の値が、無限で、コレクションにDELETEと深さのヘッダーを提出してはなりません。
DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URIs are to be deleted.
DELETEは、Request-URIで指定されたコレクションとその内部のメンバーのURIで識別されるすべてのリソースが削除されることを指示します。
If any resource identified by a member URI cannot be deleted then all of the member's ancestors MUST NOT be deleted, so as to maintain namespace consistency.
メンバーURIで識別されるすべてのリソースが削除できない場合は、名前空間の一貫性を維持するように、その後メンバーの祖先のすべては、削除しないでください。
Any headers included with DELETE MUST be applied in processing every resource to be deleted.
DELETEに含まれている任意のヘッダを削除するすべてのリソースの処理に適用されなければなりません。
When the DELETE method has completed processing it MUST result in a consistent namespace.
DELETEメソッドが処理を完了したとき、それは一貫性のある名前空間をもたらさなければなりません。
If an error occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status). 424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-Status). They can be safely left out because the client will know that the ancestors of a resource could not be deleted when the client receives an error for the ancestor's progeny. Additionally 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.
エラーがRequest-URIで識別されたリソース以外のリソースに発生した場合、応答は207（マルチ状態）でなければなりません。 424（失敗した依存）エラーは207（マルチ状態）にするべきではありません。クライアントは、クライアントが祖先の子孫のためにエラーを受信したときに、リソースの祖先は削除できなかったことを知っていますので、彼らは安全に除外することができます。さらに204（コンテンツなし）エラーは207（マルチステータス）で返されるべきではありません。この禁止の理由は、204（コンテンツなし）は、デフォルトの成功コードであるということです。
>>Request
>>リクエスト
DELETE /container/ HTTP/1.1 Host: www.foo.bar
DELETE /コンテナ/ HTTP / 1.1ホスト：www.foo.bar
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <d:multistatus xmlns:d="DAV:"> <d:response> <d:href>http://www.foo.bar/container/resource3</d:href> <d:status>HTTP/1.1 423 Locked</d:status> </d:response> </d:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.foo.bar/コンテナ/ resource3 </ D：のhref> <D：状態> HTTP / 1.1 423ロック</ D：状態> </ D：レスポンス> </ D：multistatus>
In this example the attempt to delete http://www.foo.bar/container/resource3 failed because it is locked, and no lock token was submitted with the request. Consequently, the attempt to delete http://www.foo.bar/container/ also failed. Thus the client knows that the attempt to delete http://www.foo.bar/container/ must have also failed since the parent can not be deleted unless its child has also been deleted. Even though a Depth header has not been included, a depth of infinity is assumed because the method is on a collection.
それがロックされているため、この例ではhttp://www.foo.bar/container/resource3を削除しようとする試みは失敗し、何のロックトークンは、要求を提出しませんでした。その結果、http://www.foo.bar/container/を削除しようとする試みも失敗しました。したがって、クライアントは、その子も削除されていない限り、親を削除することはできませんので、http://www.foo.bar/container/を削除しようとする試みも失敗していなければならないことを知っています。深ヘッダが含まれていないにもかかわらず、メソッドがコレクションにあるため、無限の深さを想定しています。
A PUT performed on an existing resource replaces the GET response entity of the resource. Properties defined on the resource may be recomputed during PUT processing but are not otherwise affected. For example, if a server recognizes the content type of the request body, it may be able to automatically extract information that could be profitably exposed as properties.
既存のリソース上で実行さPUTはリソースのGET応答実体を置き換えます。リソースで定義されたプロパティはPUT処理時に再計算することができるが、それ以外の影響を受けません。サーバはリクエストボディのコンテンツタイプを認識した場合、例えば、自動的に有益な特性として公開することができる情報を抽出することができるかもしれません。
A PUT that would result in the creation of a resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict).
適切なスコープの親コレクションせずにリソースの作成につながるPUTは409（競合）で失敗しなければなりません。
As defined in the HTTP/1.1 specification [RFC2068], the "PUT method requests that the enclosed entity be stored under the supplied Request-URI." Since submission of an entity representing a collection would implicitly encode creation and deletion of resources, this specification intentionally does not define a transmission format for creating a collection using PUT. Instead, the MKCOL method is defined to create collections.
HTTP / 1.1仕様書[RFC2068]で定義されるように、「囲まれたエンティティが供給されるのRequest-URIの下に格納されるメソッド要求を置きます。」収集物を表すエンティティの提出が暗黙的リソースの作成と削除をコードするであろうから、この仕様は意図的にPUTを使用してコレクションを作成するための送信フォーマットを定義していません。代わりに、MKCOLメソッドは、コレクションを作成するために定義されています。
When the PUT operation creates a new non-collection resource all ancestors MUST already exist. If all ancestors do not exist, the method MUST fail with a 409 (Conflict) status code. For example, if resource /a/b/c/d.html is to be created and /a/b/c/ does not exist, then the request must fail.
PUT操作が新たな非コレクションリソースを作成すると、すべての祖先はすでに存在しなければなりません。すべての先祖が存在しない場合は、この方法は、409（競合）ステータスコードで失敗しなければなりません。リソース/a/b/c/d.htmlが作成されると、/ A / B / Cの/が存在しない場合、例えば、その要求は失敗しなければなりません。
The COPY method creates a duplicate of the source resource, identified by the Request-URI, in the destination resource, identified by the URI in the Destination header. The Destination header MUST be present. The exact behavior of the COPY method depends on the type of the source resource.
COPYメソッドは、宛先ヘッダにURIによって識別される宛先リソース内のRequest-URIによって識別されたソース・リソースの重複を、作成します。宛先ヘッダが存在しなければなりません。 COPYメソッドの正確な動作は、ソースリソースの種類によって異なります。
All WebDAV compliant resources MUST support the COPY method. However, support for the COPY method does not guarantee the ability to copy a resource. For example, separate programs may control resources on the same server. As a result, it may not be possible to copy a resource to a location that appears to be on the same server.
すべてのWebDAV準拠したリソースは、COPYメソッドをサポートしなければなりません。しかし、COPYメソッドのサポートは、リソースをコピーする機能を保証するものではありません。例えば、別々のプログラムは、同じサーバー上のリソースを制御することができます。その結果、同じサーバ上にあるように見える場所にリソースをコピーすることはできないかもしれません。
When the source resource is not a collection the result of the COPY method is the creation of a new resource at the destination whose state and behavior match that of the source resource as closely as possible. After a successful COPY invocation, all properties on the source resource MUST be duplicated on the destination resource, subject to modifying headers and XML elements, following the definition for copying properties. Since the environment at the destination may be different than at the source due to factors outside the scope of control of the server, such as the absence of resources required for correct operation, it may not be possible to completely duplicate the behavior of the resource at the destination. Subsequent alterations to the destination resource will not modify the source resource. Subsequent alterations to the source resource will not modify the destination resource.
ソースリソースがコレクションでない場合はCOPYメソッドの結果は、状態や行動できるだけ密接にソースリソースのものと一致先の新しいリソースの作成です。成功したCOPYの起動後、ソースリソース上のすべてのプロパティは、プロパティのコピーの定義以下、ヘッダおよびXML要素を変更する対象、宛先リソースに複製されなければなりません。先の環境は、正しい動作のために必要なリソースが存在しないようなサーバの制御の範囲外の要因に起因するソースには異なるかもしれないので、完全にリソースの動作を複製することはできないかもしれません先。先リソースへの以降の変更は、ソースのリソースを変更しません。ソースリソースへの以降の変更は先のリソースを変更しません。
The following section defines how properties on a resource are handled during a COPY operation.
次のセクションでは、リソースのプロパティがコピー動作中に処理される方法を定義します。
Live properties SHOULD be duplicated as identically behaving live properties at the destination resource. If a property cannot be copied live, then its value MUST be duplicated, octet-for-octet, in an identically named, dead property on the destination resource subject to the effects of the propertybehavior XML element.
ライブプロパティは、同様に先リソースでのライブの性質を行動として複製されるべきです。プロパティは、ライブコピーできない場合は、その値がpropertybehavior XML要素の影響を先リソース対象に同一の名前、死者プロパティで、オクテットのためのオクテットを複製する必要があります。
The propertybehavior XML element can specify that properties are copied on best effort, that all live properties must be successfully copied or the method must fail, or that a specified list of live properties must be successfully copied or the method must fail. The propertybehavior XML element is defined in section 12.12.
propertybehavior XML要素は、プロパティがすべてのライブのプロパティが正常にコピーされなければならないかの方法が失敗しなければならない、またはライブプロパティの指定されたリストが正常にコピーされなければならないことやメソッドが失敗しなければならないことを、ベストエフォートにコピーされるように指定することができます。 propertybehavior XML要素は、セクション12.12で定義されています。
The COPY method on a collection without a Depth header MUST act as if a Depth header with value "infinity" was included. A client may submit a Depth header on a COPY on a collection with a value of "0" or "infinity". DAV compliant servers MUST support the "0" and "infinity" Depth header behaviors.
奥行きヘッダ無しコレクション上のコピー方法は、値「無限」の奥行きヘッダが含まれていたかのように行動しなければなりません。クライアントは、「0」または「無限」の値で、コレクションのCOPYの深さヘッダーを提出することができます。 DAV準拠したサーバーは、「0」と「無限」の深さヘッダーの動作をサポートしなければなりません。
A COPY of depth infinity instructs that the collection resource identified by the Request-URI is to be copied to the location identified by the URI in the Destination header, and all its internal member resources are to be copied to a location relative to it, recursively through all levels of the collection hierarchy.
深さ無限のCOPYは、Request-URIによって識別されるコレクションリソースが宛先ヘッダにURIによって識別された位置にコピーされることを指示し、そのすべての内部メンバー・リソースは、再帰的、それに対する位置にコピーされますコレクション階層のすべてのレベルを介して。
A COPY of "Depth: 0" only instructs that the collection and its properties but not resources identified by its internal member URIs, are to be copied.
「深さ：0」のCOPYは、コレクションとそのプロパティではなく、内部のメンバーのURIで識別されるリソースは、コピーされることを指示します。
Any headers included with a COPY MUST be applied in processing every resource to be copied with the exception of the Destination header.
コピーに含まれる任意のヘッダは宛先ヘッダを除いてコピーするすべてのリソースを処理する際に適用されなければなりません。
The Destination header only specifies the destination URI for the Request-URI. When applied to members of the collection identified by the Request-URI the value of Destination is to be modified to reflect the current location in the hierarchy. So, if the Request- URI is /a/ with Host header value http://fun.com/ and the Destination is http://fun.com/b/ then when http://fun.com/a/c/d is processed it must use a Destination of http://fun.com/b/c/d.
宛先ヘッダーは唯一のRequest-URIのための先URIを指定します。 Request-URIによって識別されるコレクションのメンバーに適用される場合宛先の値は、階層内の現在の位置を反映するように変更されます。要求 - URIがホストヘッダー値http://fun.com/と/ /あるとあれば、先はhttp://fun.com/b/その後、ときhttp://fun.com/a/cです/ Dそれはhttp://fun.com/b/c/dの先を使用する必要があります処理されます。
When the COPY method has completed processing it MUST have created a consistent namespace at the destination (see section 5.1 for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server MUST NOT copy any resources identified by members of this collection (i.e., the server must skip this subtree), as this would create an inconsistent namespace. After detecting an error, the COPY operation SHOULD try to finish as much of the original copy operation as possible (i.e., the server should still attempt to copy other subtrees and their members, that are not descendents of an error-causing collection). So, for example, if an infinite depth copy operation is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs copying /a/b/, an attempt should still be made to copy /a/c/. Similarly, after encountering an error copying a non-collection resource as part of an infinite depth copy, the server SHOULD try to finish as much of the original copy operation as possible.
COPYメソッドが完了すると、それは先の一貫した名前空間を作成しておく必要があり、処理（名前空間の一貫性の定義についてはセクション5.1を参照）。内部コレクションをコピー中にエラーが発生した場合、これは一貫性のない名前空間を作成しますしかし、サーバーは、このコレクション（すなわち、サーバはこのサブツリーをスキップしなければならない）のメンバーによって識別されるすべてのリソースをコピーしてはなりません。エラーを検出した後、コピー操作が可能な限りオリジナルのコピー操作の多くを完了するために試してみてください（すなわち、サーバは、さらに他のサブツリーと、エラーの原因となるコレクションの子孫でない彼らのメンバーを、コピーしようとすべきです）。したがって、たとえば、無限の深さのコピー操作は、コレクション/ A / B /と/ A / C /を含むコレクション/ /上で実行され、エラーは、コピー/ A / B /を発生し、試みはまだする必要がありますされている場合/ A / C /をコピーするために作られました。同様に、無限の深さのコピーの一部として非コレクションリソースのコピーエラーが発生した後、サーバーは、可能な限りオリジナルのコピー操作の多くを完了するために試してみてください。
If an error in executing the COPY method occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status).
COPYメソッドを実行中にエラーがRequest-URIで識別されたリソース以外のリソースに発生した場合、応答は207（マルチ状態）でなければなりません。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a COPY method. These responses can be safely omitted because the client will know that the progeny of a resource could not be copied when the client receives an error for the parent. Additionally 201 (Created)/204 (No Content) status codes SHOULD NOT be returned as values in 207 (Multi-Status) responses from COPY methods. They, too, can be safely omitted because they are the default success codes.
424（失敗した依存）ステータスコードCOPY法から207（マルチステータス）応答で返されるべきではありません。クライアントは、クライアントが親のためのエラーを受信したときに、リソースの子孫をコピーすることができなかったことを知っていますので、これらの応答は、安全に省略することができます。さらに201（作成）/ 204（コンテンツなし）ステータスコードは、COPYメソッドから207（マルチステータス）応答の値として返されないことべきではありません。彼らは、デフォルトの成功コードであるので、彼らは、あまりにも、安全に省略することができます。
If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F" then the operation will fail.
宛先リソースに関する：リソースが先に存在し、上書きヘッダが「T」である場合、前のコピーを実行するサーバは、「無限の深さ」とDELETEを実行しなければなりません。上書きヘッダーが「F」に設定されている場合、操作は失敗します。
201 (Created) - The source resource was successfully copied. The copy operation resulted in the creation of a new resource.
201（作成） - ソースリソースは正常にコピーされました。コピー操作は、新しいリソースの作成になりました。
204 (No Content) - The source resource was successfully copied to a pre-existing destination resource.
204（いいえコンテンツ） - ソースリソースが正常に既存の宛先リソースにコピーされました。
403 (Forbidden) _ The source and destination URIs are the same.
403（禁止）_ソースおよび宛先URIが同じです。
409 (Conflict) _ A resource cannot be created at the destination until one or more intermediate collections have been created.
409（競合）は、1つの以上の中間コレクションが作成されるまで_リソースが先に作成することができません。
412 (Precondition Failed) - The server was unable to maintain the liveness of the properties listed in the propertybehavior XML element or the Overwrite header is "F" and the state of the destination resource is non-null.
412（前提条件が失敗しました） - サーバーがpropertybehavior XMLエレメントにリストされたプロパティの生存性を維持することができなかった、または上書きヘッダが「F」で、宛先リソースの状態が非ヌルです。
423 (Locked) - The destination resource was locked.
423（ロック） - 先のリソースがロックされました。
502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource.
502（不正なゲートウェイ） - 宛先が別のサーバ上にあり、宛先サーバがリソースを受け入れることを拒否した場合に発生する可能性があります。
507 (Insufficient Storage) - The destination resource does not have sufficient space to record the state of the resource after the execution of this method.
507（ストレージ不足） - 先のリソースは、この方法を実行した後、リソースの状態を記録するための十分なスペースがありません。
This example shows resource http://www.ics.uci.edu/~fielding/index.html being copied to the location http://www.ics.uci.edu/users/f/fielding/index.html. The 204 (No Content) status code indicates the existing resource at the destination was overwritten.
この例ではhttp://www.ics.uci.edu/~fielding/index.htmlが位置http://www.ics.uci.edu/users/f/fielding/index.htmlにコピーされるリソースを示しています。 204（コンテンツなし）ステータスコードは、先に既存のリソースが上書きされたことを示していません。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html
COPY /~fielding/index.html HTTP / 1.1ホスト：www.ics.uci.edu先：http://www.ics.uci.edu/users/f/fielding/index.html
>>Response
>>回答
HTTP/1.1 204 No Content
HTTP / 1.1 204コンテンツなし
The following example shows the same copy operation being performed, but with the Overwrite header set to "F." A response of 412 (Precondition Failed) is returned because the destination resource has a non-null state.
次の例では、実行される同一のコピー動作を示しているが、「F.」に設定上書きヘッダと宛先リソースが非ヌル状態を有するので、412の応答は、（前提条件が失敗）が返されます。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html Overwrite: F
COPY /~fielding/index.html HTTP / 1.1ホスト：www.ics.uci.edu先：http://www.ics.uci.edu/users/f/fielding/index.html上書き：F
>>Response
>>回答
HTTP/1.1 412 Precondition Failed
HTTP / 1.1 412前提条件が失敗しました。
>>Request
>>リクエスト
COPY /container/ HTTP/1.1 Host: www.foo.bar Destination: http://www.foo.bar/othercontainer/ Depth: infinity Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
COPY /コンテナ/ HTTP / 1.1ホスト：www.foo.bar先：http://www.foo.bar/othercontainer/深さ：無限のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <d:propertybehavior xmlns:d="DAV:"> <d:keepalive>*</d:keepalive> </d:propertybehavior>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：propertybehaviorのxmlns：D = "DAV："> <D：キープアライブ> * </ D：キープアライブ> </ D：propertybehavior>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <d:multistatus xmlns:d="DAV:"> <d:response> <d:href>http://www.foo.bar/othercontainer/R2/</d:href> <d:status>HTTP/1.1 412 Precondition Failed</d:status> </d:response> </d:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.foo.bar/ othercontainer / R2 / </ D：HREF> <D：ステータス> HTTP / 1.1 412前提条件が失敗しました</ D：状態> </ D：レスポンス> </ D：multistatus>
The Depth header is unnecessary as the default behavior of COPY on a collection is to act as if a "Depth: infinity" header had been submitted. In this example most of the resources, along with the collection, were copied successfully. However the collection R2 failed, most likely due to a problem with maintaining the liveness of properties (this is specified by the propertybehavior XML element). Because there was an error copying R2, none of R2's members were copied. However no errors were listed for those members due to the error minimization rules given in section 8.8.3.
コレクションのCOPYのデフォルトの動作があるかのように行動することであるとして、深さヘッダーは不要である「深さ：無限」ヘッダが送信されました。この例では、資源のほとんどは、コレクションと一緒に、正常にコピーされました。しかし、コレクションR2（これはpropertybehavior XML要素によって指定されている）による特性の生存性を維持することに問題があるため、ほとんどの場合失敗しました。 R2のコピーエラーが発生したので、R2のメンバーはいずれもコピーされませんでした。しかし、エラーがセクション8.8.3で与えられた誤差最小化規則に起因するそれらのメンバーのためにリストされませんでした。
The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed atomically. The consistency maintenance step allows the server to perform updates caused by the move, such as updating all URIs other than the Request-URI which identify the source resource, to point to the new destination resource. Consequently, the Destination header MUST be present on all MOVE methods and MUST follow all COPY requirements for the COPY part of the MOVE method. All DAV compliant resources MUST support the MOVE method. However, support for the MOVE method does not guarantee the ability to move a resource to a particular destination.
非収集リソース上で移動操作は、すべての3つのアクションがアトミックに実行されたソースの削除続い一貫メンテナンス処理、続いて、コピー（COPY）の論理等価です。一貫性維持ステップは、新しい宛先リソースを指すように、サーバは、ソースリソースを識別するリクエストURI以外のすべてのURIを更新するように移動することによって引き起こされる更新を実行することを可能にします。これにより、宛先ヘッダは、すべてのMOVEメソッドに存在する必要があり、移動方法のCOPY部分の全てのコピー要求に従わなければなりません。全てのDAV準拠したリソースはMOVEメソッドをサポートしなければなりません。しかし、MOVEメソッドのサポートは、特定の宛先にリソースを移動する能力を保証するものではありません。
For example, separate programs may actually control different sets of resources on the same server. Therefore, it may not be possible to move a resource within a namespace that appears to belong to the same server.
例えば、別々のプログラムは、実際には、同じサーバー上のリソースの異なるセットを制御することができます。したがって、同じサーバに属しているように見える名前空間内のリソースを移動することはできないかもしれません。
If a resource exists at the destination, the destination resource will be DELETEd as a side-effect of the MOVE operation, subject to the restrictions of the Overwrite header.
リソースが目的地に存在する場合、宛先リソースは上書きヘッダの制限を受け、MOVE動作の副作用として削除されます。
The behavior of properties on a MOVE, including the effects of the propertybehavior XML element, MUST be the same as specified in section 8.8.2.
propertybehavior XML要素の効果を含むMOVEのプロパティの挙動は、セクション8.8.2で指定されたと同じでなければなりません。
A MOVE with "Depth: infinity" instructs that the collection identified by the Request-URI be moved to the URI specified in the Destination header, and all resources identified by its internal member URIs are to be moved to locations relative to it, recursively through all levels of the collection hierarchy.
「深さ：無限」のMOVEは、Request-URIによって識別されるコレクションが宛先ヘッダで指定され、その内部部材のURIによって識別されるすべてのリソースが再帰を介して、それへの相対的な位置に移動されるURIに移動することを指示しますコレクション階層のすべてのレベル。
The MOVE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header on a MOVE on a collection with any value but "infinity".
コレクションのMOVEメソッドがあるかのように行動しなければならない「深さ：無限」ヘッダーは、それに使用されました。クライアントは、任意の値が、「無限」でコレクションのMOVEの深さヘッダーを提出してはなりません。
Any headers included with MOVE MUST be applied in processing every resource to be moved with the exception of the Destination header.
MOVEに含まれている任意のヘッダは宛先ヘッダを除いて移動するすべてのリソースを処理する際に適用されなければなりません。
The behavior of the Destination header is the same as given for COPY on collections.
コレクションにコピーするために与えられる宛先ヘッダの動作は同じです。
When the MOVE method has completed processing it MUST have created a consistent namespace at both the source and destination (see section 5.1 for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server MUST NOT move any resources identified by members of the failed collection (i.e., the server must skip the error-causing subtree), as this would create an inconsistent namespace. In this case, after detecting the error, the move operation SHOULD try to finish as much of the original move as possible (i.e., the server should still attempt to move other subtrees and the resources identified by their members, that are not descendents of an error-causing collection). So, for example, if an infinite depth move is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs moving /a/b/, an attempt should still be made to try moving /a/c/. Similarly, after encountering an error moving a non-collection resource as part of an infinite depth move, the server SHOULD try to finish as much of the original move operation as possible.
MOVEメソッドは、ソースと宛先の両方で一貫した名前空間を作成しておく必要があり、処理完了した場合（名前空間一貫性の定義についてはセクション5.1を参照）。内部コレクションを移動中にエラーが発生した場合、これは一貫性のない名前空間を作成しますしかし、サーバーは、失敗したコレクション（つまり、サーバーがエラーの原因となるサブツリーをスキップしなければならない）のメンバーによって識別されるすべてのリソースを移動してはなりません。この場合は、エラーを検出した後、移動操作、すなわち（可能な限りオリジナルの動きの限りを終了しようとする必要があり、サーバーがまだの子孫ではありません、他のサブツリーとそのメンバーによって識別されるリソースを、移動しようとすべきですエラーの原因となるコレクション）。したがって、たとえば、無限の深さの動きはコレクション/ A / B /と/ A / C /を含むコレクション/ /上で実行された場合、エラーが動い/ A / B /を発生し、試みがまだなされるべきです/ A / C /を移動しようとします。同様に、無限の深さの動きの一環として、非コレクションリソースを移動するエラーが発生した後、サーバーは、可能な限りオリジナルの移動操作の多くを完了するために試してみてください。
If an error occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status).
エラーがRequest-URIで識別されたリソース以外のリソースに発生した場合、応答は207（マルチ状態）でなければなりません。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a MOVE method. These errors can be safely omitted because the client will know that the progeny of a resource could not be moved when the client receives an error for the parent. Additionally 201 (Created)/204 (No Content) responses SHOULD NOT be returned as values in 207 (Multi-Status) responses from a MOVE. These responses can be safely omitted because they are the default success codes.
424（失敗した依存）ステータスコードはMOVEメソッドから207（マルチステータス）応答で返されるべきではありません。クライアントは、クライアントが親のためのエラーを受信したときに、リソースの子孫を移動することができなかったことを知っていますので、これらのエラーは安全に省略することができます。さらに201（作成）/ 204（いいえコンテンツ）応答は、MOVEから207（マルチステータス）応答の値として返されるべきではありません。彼らは、デフォルトの成功コードであるため、これらの応答は、安全に省略することができます。
If a resource exists at the destination and the Overwrite header is "T" then prior to performing the move the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F" then the operation will fail.
宛先リソースに関する：リソースが先に存在し、上書きヘッダが「T」である場合、前の動きを実行するサーバは、「無限の深さ」とDELETEを実行しなければなりません。上書きヘッダーが「F」に設定されている場合、操作は失敗します。
201 (Created) - The source resource was successfully moved, and a new resource was created at the destination.
201（作成） - ソースリソースが正常に移動し、新しいリソースが先に作成しました。
204 (No Content) - The source resource was successfully moved to a pre-existing destination resource.
204（いいえコンテンツ） - ソースリソースが正常に既存の宛先リソースに移されました。
403 (Forbidden) _ The source and destination URIs are the same.
403（禁止）_ソースおよび宛先URIが同じです。
409 (Conflict) _ A resource cannot be created at the destination until one or more intermediate collections have been created.
409（競合）は、1つの以上の中間コレクションが作成されるまで_リソースが先に作成することができません。
412 (Precondition Failed) - The server was unable to maintain the liveness of the properties listed in the propertybehavior XML element or the Overwrite header is "F" and the state of the destination resource is non-null.
412（前提条件が失敗しました） - サーバーがpropertybehavior XMLエレメントにリストされたプロパティの生存性を維持することができなかった、または上書きヘッダが「F」で、宛先リソースの状態が非ヌルです。
423 (Locked) - The source or the destination resource was locked.
423（ロック） - 送信元または宛先リソースがロックされました。
502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource.
502（不正なゲートウェイ） - 宛先が別のサーバ上にあり、宛先サーバがリソースを受け入れることを拒否した場合に発生する可能性があります。
This example shows resource http://www.ics.uci.edu/~fielding/index.html being moved to the location http://www.ics.uci.edu/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination resource had been non-null. In this case, since there was nothing at the destination resource, the response code is 201 (Created).
この例ではhttp://www.ics.uci.edu/~fielding/index.htmlが位置http://www.ics.uci.edu/users/f/fielding/index.htmlに移動されるリソースを示しています。先のリソースがnullであった場合は、宛先リソースの内容が上書きされていたであろう。何も先のリソースに存在しなかったので、この場合には、応答コードが201である（作成されます）。
>>Request
>>リクエスト
MOVE /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html
MOVE /~fielding/index.html HTTP / 1.1ホスト：www.ics.uci.edu先：http://www.ics.uci.edu/users/f/fielding/index.html
>>Response
>>回答
HTTP/1.1 201 Created Location: http://www.ics.uci.edu/users/f/fielding/index.html
HTTP / 1.1 201作成された場所：http://www.ics.uci.edu/users/f/fielding/index.html
>>Request
>>リクエスト
MOVE /container/ HTTP/1.1 Host: www.foo.bar Destination: http://www.foo.bar/othercontainer/ Overwrite: F If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>) (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>) Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
MOVE /コンテナ/ HTTP / 1.1ホスト：www.foo.bar先：http://www.foo.bar/othercontainer/上書き：Fの場合：（<opaquelocktoken：fe184f2e-6eec-41d0-c765-01adc56e6bb4>）（< opaquelocktoken：e454f3f3-ACDC-452A-56c7-00a5c91e4b77>）のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <d:propertybehavior xmlns:d='DAV:'> <d:keepalive>*</d:keepalive> </d:propertybehavior>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：propertybehaviorのxmlns：D = 'DAV：'> <D：キープアライブを> * </ D：キープアライブ> </ D：propertybehavior>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <d:multistatus xmlns:d='DAV:'> <d:response> <d:href>http://www.foo.bar/othercontainer/C2/</d:href> <d:status>HTTP/1.1 423 Locked</d:status> </d:response> </d:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = 'DAV：'> <D：レスポンス> <D：HREF> http://www.foo.bar/ othercontainer / C2 / </ D：HREF> <D：ステータス> HTTP / 1.1 423ロック</ D：状態> </ D：レスポンス> </ D：multistatus>
In this example the client has submitted a number of lock tokens with the request. A lock token will need to be submitted for every resource, both source and destination, anywhere in the scope of the method, that is locked. In this case the proper lock token was not submitted for the destination http://www.foo.bar/othercontainer/C2/. This means that the resource /container/C2/ could not be moved. Because there was an error copying /container/C2/, none of /container/C2's members were copied. However no errors were listed for those members due to the error minimization rules given in section 8.8.3. User agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in an underlying transport layer.
この例では、クライアントが要求したロック・トークンの数を提出しました。ロックトークンはどこにもロックされている方法、の範囲で、すべてのリソースのために提出されるように、送信元と宛先の両方が必要になります。この場合、適切なロックトークンが先http://www.foo.bar/othercontainer/C2/のために提出されませんでした。これは、リソース/コンテナ/ C2 /移動することができなかったことを意味します。エラーコピー/コンテナ/ C2 /があったので、/コンテナのいずれも/ C2のメンバーがコピーされませんでした。しかし、エラーがセクション8.8.3で与えられた誤差最小化規則に起因するそれらのメンバーのためにリストされませんでした。ユーザエージェント認証は以前に、基礎となるトランスポート層では、HTTPプロトコルの範囲外の機構を介して発生しています。
The following sections describe the LOCK method, which is used to take out a lock of any access type. These sections on the LOCK method describe only those semantics that are specific to the LOCK method and are independent of the access type of the lock being requested.
以下のセクションでは、いずれかのアクセスタイプのロックを取り出すために使用されるLOCK方法を記載しています。 LOCKメソッドにこれらのセクションは、LOCKメソッドに固有のものであり、要求されたロックのアクセスタイプから独立しているのみ意味を説明します。
Any resource which supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein.
LOCKメソッドをサポートする任意のリソースは、最低でも、本明細書で定義されるXML要求および応答のフォーマットをサポートしなければなりません。
A LOCK method invocation creates the lock specified by the lockinfo XML element on the Request-URI. Lock method requests SHOULD have a XML request body which contains an owner XML element for this lock request, unless this is a refresh request. The LOCK request may have a Timeout header.
LOCKメソッド呼び出しは、Request-URIにLOCKINFO XML要素によって指定されたロックを作成します。これは、リフレッシュ要求されない限り、ロックメソッド要求は、このロック要求のための所有者のXML要素を含むXMLリクエストボディを持つべきである（SHOULD）。 LOCK要求がタイムアウトヘッダを有していてもよいです。
Clients MUST assume that locks may arbitrarily disappear at any time, regardless of the value given in the Timeout header. The Timeout header only indicates the behavior of the server if "extraordinary" circumstances do not occur. For example, an administrator may remove a lock at any time or the system may crash in such a way that it loses the record of the lock's existence. The response MUST contain the value of the lockdiscovery property in a prop XML element.
クライアントがロックを任意にかかわらず、タイムアウトヘッダーに与えられた値の、任意の時点で消失することを想定しなければなりません。 「異常な」状況が発生しない場合はタイムアウトヘッダーは、サーバーの動作を示します。たとえば、管理者はいつでもロックを解除したりシステムは、それがロックの存在の記録を失うような方法でクラッシュすることがあります。応答は、支柱XML要素にlockdiscoveryプロパティの値を含まなければなりません。
In order to indicate the lock token associated with a newly created lock, a Lock-Token response header MUST be included in the response for every successful LOCK request for a new lock. Note that the Lock-Token header would not be returned in the response for a successful refresh LOCK request because a new lock was not created.
新しく作成されたロックに関連付けられているロック・トークンを示すために、ロック・トークンレスポンスヘッダは、新しいロックのために成功するたびにLOCK要求に対する応答に含まれなければなりません。新しいロックが作成されていないので、ロックトークンヘッダが成功リフレッシュLOCK要求に対する応答で返されることはないことに注意してください。
The scope of a lock is the entire state of the resource, including its body and associated properties. As a result, a lock on a resource MUST also lock the resource's properties.
ロックの範囲は、その本体と関連するプロパティを含むリソースの全体の状態、です。その結果、リソースのロックは、リソースのプロパティをロックする必要があります。
For collections, a lock also affects the ability to add or remove members. The nature of the effect depends upon the type of access control involved.
コレクションの場合、ロックはまた、メンバーを追加または削除する能力に影響を与えます。効果の性質が関係するアクセス制御の種類に依存します。
A resource may be made available through more than one URI. However locks apply to resources, not URIs. Therefore a LOCK request on a resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable.
リソースは、複数のURIを通じて利用できるようにすることができます。しかし、ロックはリソースではなく、URIに適用されます。リソースがアドレス指定可能で、それを通してすべてのURIで表彰することができない場合にはそのためのリソースのロック要求は成功してはなりません。
The Depth header may be used with the LOCK method. Values other than 0 or infinity MUST NOT be used with the Depth header on a LOCK method. All resources that support the LOCK method MUST support the Depth header.
奥行きヘッダは、LOCKメソッドで使用されてもよいです。 0又は無限以外の値は、LOCKメソッドに奥行きヘッダで使用してはいけません。 LOCKメソッドをサポートするすべてのリソースは、深ヘッダをサポートしなければなりません。
A Depth header of value 0 means to just lock the resource specified by the Request-URI.
値0の奥行きヘッダだけのRequest-URIで指定されたリソースをロックすることを意味します。
If the Depth header is set to infinity then the resource specified in the Request-URI along with all its internal members, all the way down the hierarchy, are to be locked. A successful result MUST return a single lock token which represents all the resources that have been locked. If an UNLOCK is successfully executed on this token, all associated resources are unlocked. If the lock cannot be granted to all resources, a 409 (Conflict) status code MUST be returned with a response entity body containing a multistatus XML element describing which resource(s) prevented the lock from being granted. Hence, partial success is not an option. Either the entire hierarchy is locked or no resources are locked.
奥行きヘッダが無限大に設定されている場合、すべての方法階層下の、そのすべての内部メンバーと一緒のRequest-URIで指定されたリソースがロックされます。成功した結果は、ロックされているすべてのリソースを表す単一のロック・トークンを返さなければなりません。 UNLOCKが正常にこのトークンで実行されている場合は、関連するすべてのリソースのロックが解除されています。ロックは、すべてのリソースに付与することができない場合は、409（競合）ステータスコードが付与されてからロックがどのリソース（単数または複数）を記述するmultistatus XML要素を含む応答エンティティボディに防止戻さなければなりません。そのため、部分的な成功はオプションではありません。どちらの階層全体がロックされているか、何のリソースがロックされていません。
If no Depth header is submitted on a LOCK request then the request MUST act as if a "Depth:infinity" had been submitted.
提出された：何の深さヘッダーはLOCK要求で提出されていない場合、リクエストは「無限の深さは」かのように行動しなければなりません。
The interaction of a LOCK with various methods is dependent upon the lock type. However, independent of lock type, a successful DELETE of a resource MUST cause all of its locks to be removed.
種々の方法とLOCKの相互作用は、ロック・タイプに依存しています。ただし、ロックタイプとは無関係に、リソースの成功DELETEは、そのロックのすべてが削除される可能性がなければなりません。
The table below describes the behavior that occurs when a lock request is made on a resource.
以下の表は、ロック要求がリソースに対して行われたときに発生する動作を説明します。
Current lock state/ | Shared Lock | Exclusive
Lock request | | Lock
=====================+=================+==============
None | True | True
---------------------+-----------------+--------------
Shared Lock | True | False
---------------------+-----------------+--------------
Exclusive Lock | False | False*
------------------------------------------------------
Legend: True = lock may be granted. False = lock MUST NOT be granted. *=It is illegal for a principal to request the same lock twice.
凡例：= Trueでロックが付与されることがあります。偽=ロックが許可されてはなりません。校長は二度同じロックを要求するため* =それは違法です。
The current lock state of a resource is given in the leftmost column, and lock requests are listed in the first row. The intersection of a row and column gives the result of a lock request. For example, if a shared lock is held on a resource, and an exclusive lock is requested, the table entry is "false", indicating the lock must not be granted.
リソースの現在のロック状態は、一番左の列に示され、ロック要求が最初の行に記載されています。行と列の交点は、ロック要求の結果を与えます。共有ロックがリソース上に保持され、かつ排他ロックが要求された場合、例えば、テーブルエントリが許可されてはならないロックを示す「偽」です。
200 (OK) - The lock request succeeded and the value of the lockdiscovery property is included in the body.
200（OK） - ロック要求が成功したとlockdiscoveryプロパティの値が本文に含まれています。
412 (Precondition Failed) - The included lock token was not enforceable on this resource or the server could not satisfy the request in the lockinfo XML element.
412（前提条件に失敗しました） - 含まロックトークンは、このリソースまたはLOCKINFOのXML要素で要求を満たすことができませんでしたサーバー上の強制力はなかったです。
423 (Locked) - The resource is locked, so the method has been rejected.
423（ロック） - リソースがロックされているので、方法が拒否されました。
>>Request
>>リクエスト
LOCK /workspace/webdav/proposal.doc HTTP/1.1 Host: webdav.sb.aol.com Timeout: Infinite, Second-4100000000 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="ejw", realm="ejw@webdav.sb.aol.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..."
LOCK /workspace/webdav/proposal.docのHTTP / 1.1ホスト：webdav.sb.aol.comタイムアウト：無限、セカンド41億のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX許可：ダイジェストユーザ名= "EJW"、領域= "ejw@webdav.sb.aol.com"、ナンス=」... "URI =" /ワークスペース/ webdavの/proposal.doc "レスポンス=" ... "不透明=" ...」
<?xml version="1.0" encoding="utf-8" ?> <D:lockinfo xmlns:D='DAV:'> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> <D:owner> <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href> </D:owner> </D:lockinfo>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のxmlns LOCKINFO：D = 'DAV：'> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：種類のLockType> <D：書き込み/> </ D：たlocktype> <D：所有者> <D：HREF> http://www.ics.uci.edu/~ejw/contact.html </ D：HREF> </ D：所有者> </ D：LOCKINFO>
>>Response
>>回答
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 200 OKのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:prop xmlns:D="DAV:"> <D:lockdiscovery> <D:activelock> <D:locktype><D:write/></D:locktype> <D:lockscope><D:exclusive/></D:lockscope> <D:depth>Infinity</D:depth>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のxmlns小道具：D = "DAV："> <D：lockdiscovery> <D：activelock> <D：たlocktype> <D：/書き込み> </ D：たlocktype> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：深さ>無限</ D：深さ>
<D:owner> <D:href> http://www.ics.uci.edu/~ejw/contact.html </D:href> </D:owner> <D:timeout>Second-604800</D:timeout> <D:locktoken> <D:href> opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 </D:href> </D:locktoken> </D:activelock> </D:lockdiscovery> </D:prop>
<D：所有者> <D：HREF> http://www.ics.uci.edu/~ejw/contact.html </ D：HREF> </ D：所有者> <D：タイムアウト>第-604800 </ D：タイムアウト> <D：locktoken> <D：HREF> opaquelocktoken：e71d4fae-5dec-22d6-fea5-00a0c91e6be4 </ D：HREF> </ D：locktoken> </ D：activelock> </ D：lockdiscovery> < / D：小道具>
This example shows the successful creation of an exclusive write lock on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The resource http://www.ics.uci.edu/~ejw/contact.html contains contact information for the owner of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). Note that the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、リソースのhttp://webdav.sb.aol.com/workspace/webdav/proposal.docに対する排他書き込みロックの作成に成功したことを示しています。リソースhttp://www.ics.uci.edu/~ejw/contact.htmlは、ロックの所有者の連絡先情報が含まれています。サーバが自動的に1週間（604800秒）後に削除するロックが発生し、このリソース、上の場所でアクティビティベースのタイムアウトポリシーを持っています。ナンス、応答、及び不透明なフィールドが認可要求ヘッダで算出されていないことに留意されたいです。
>>Request
>>リクエスト
LOCK /workspace/webdav/proposal.doc HTTP/1.1 Host: webdav.sb.aol.com Timeout: Infinite, Second-4100000000 If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>) Authorization: Digest username="ejw", realm="ejw@webdav.sb.aol.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..."
LOCK /workspace/webdav/proposal.docのHTTP / 1.1ホスト：webdav.sb.aol.comタイムアウト：無限、セカンド41億の場合：（<opaquelocktoken：e71d4fae-5dec-22d6-fea5-00a0c91e6be4>）認証：ダイジェストユーザ名= "EJW"、領域= "ejw@webdav.sb.aol.com"、ナンス= "... " URI ="/ワークスペース/ webdavの/ proposal.doc"、レスポンス=」... "不透明=" ...」
>>Response
>>回答
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 200 OKのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:prop xmlns:D="DAV:"> <D:lockdiscovery> <D:activelock> <D:locktype><D:write/></D:locktype>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のxmlns小道具：D = "DAV："> <D：lockdiscovery> <D：activelock> <D：たlocktype> <D：/書き込み> </ D：種類のLockType>
<D:lockscope><D:exclusive/></D:lockscope> <D:depth>Infinity</D:depth> <D:owner> <D:href> http://www.ics.uci.edu/~ejw/contact.html </D:href> </D:owner> <D:timeout>Second-604800</D:timeout> <D:locktoken> <D:href> opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 </D:href> </D:locktoken> </D:activelock> </D:lockdiscovery> </D:prop>
<D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：深さ>無限</ D：深さ> <D：所有者> <D：HREF> http://www.ics.uci.edu /~ejw/contact.html </ D：HREF> </ D：所有者> <D：タイムアウト>第-604800 </ D：タイムアウト> <D：locktoken> <D：HREF> opaquelocktoken：e71d4fae-5dec-22d6 -fea5-00a0c91e6be4 </ D：HREF> </ D：locktoken> </ D：activelock> </ D：lockdiscovery> </ D：小道具>
This request would refresh the lock, resetting any time outs. Notice that the client asked for an infinite time out but the server choose to ignore the request. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この要求は、任意のタイムアウトをリセットし、ロックをリフレッシュします。無限のタイムアウトが、サーバーを求めたクライアントが要求を無視することを選択することに注意してください。この例では、一回だけ、応答、及び不透明なフィールドが認可要求ヘッダで算出されていません。
>>Request
>>リクエスト
LOCK /webdav/ HTTP/1.1 Host: webdav.sb.aol.com Timeout: Infinite, Second-4100000000 Depth: infinity Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="ejw", realm="ejw@webdav.sb.aol.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..."
LOCK / webdavの/ HTTP / 1.1ホスト：webdav.sb.aol.comタイムアウト：無限、セカンド41億深さ：無限のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX許可：ダイジェストユーザ名= "EJW"、領域= "ejw@webdav.sb.aol.com"、ナンス=」... "URI =" /ワークスペース/ webdavの/proposal.doc "レスポンス=" ... "不透明=" ...」
<?xml version="1.0" encoding="utf-8" ?> <D:lockinfo xmlns:D="DAV:"> <D:locktype><D:write/></D:locktype> <D:lockscope><D:exclusive/></D:lockscope> <D:owner> <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href> </D:owner> </D:lockinfo>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のxmlns LOCKINFO：D = "DAV："> <D：たlocktype> <D：書き込み/> </ D：たlocktype> <D： LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：所有者> <D：HREF> http://www.ics.uci.edu/~ejw/contact.html </ D：HREF> </ D：所有者> </ D：LOCKINFO>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://webdav.sb.aol.com/webdav/secret</D:href> <D:status>HTTP/1.1 403 Forbidden</D:status> </D:response> <D:response> <D:href>http://webdav.sb.aol.com/webdav/</D:href> <D:propstat> <D:prop><D:lockdiscovery/></D:prop> <D:status>HTTP/1.1 424 Failed Dependency</D:status> </D:propstat> </D:response> </D:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://webdav.sb.aol。 COM / webdavの/秘密</ D：のhref> <D：状態> HTTP / 1.1 403禁止</ D：状態> </ D：レスポンス> <D：応答> <D：HREF> http://webdav.sb .aol.com / WebDAVの/ </ D：HREF> <D：propstat> <D：プロペラ> <D：lockdiscovery /> </ D：プロペラ> <D：ステータス> HTTP / 1.1 424依存性</ D失敗しました：ステータス> </ D：propstat> </ D：レスポンス> </ D：multistatus>
This example shows a request for an exclusive write lock on a collection and all its children. In this request, the client has specified that it desires an infinite length lock, if available, otherwise a timeout of 4.1 billion seconds, if available. The request entity body contains the contact information for the principal taking out the lock, in this case a web page URL.
この例では、コレクションとそのすべての子に排他書き込みロックの要求を示しています。可能な場合は利用可能な場合、この要求では、クライアントは、それが無限の長さのロックを望んでいることを41億秒のそれ以外の場合は、タイムアウトを指定しています。リクエストのエンティティボディは、この場合には、WebページのURLをロックを取り出す主体の連絡先情報が含まれています。
The error is a 403 (Forbidden) response on the resource http://webdav.sb.aol.com/webdav/secret. Because this resource could not be locked, none of the resources were locked. Note also that the lockdiscovery property for the Request-URI has been included as required. In this example the lockdiscovery property is empty which means that there are no outstanding locks on the resource.
エラーは、リソースhttp://webdav.sb.aol.com/webdav/secret上の403（禁止）応答です。このリソースをロックすることができませんでしたので、リソースのどれもロックされませんでした。必要に応じて、要求URIのためのlockdiscoveryプロパティが含まれていることにも注意してください。この例ではlockdiscoveryプロパティは、リソース上の未解決のロックがないことを意味して空になっています。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、一回だけ、応答、及び不透明なフィールドが認可要求ヘッダで算出されていません。
The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail.
UNLOCKメソッドは、Request-URIからのロック・トークン要求ヘッダーのロック・トークンによって識別されるロックを削除し、他のすべてのリソースは、ロックに含まれます。提出したロック・トークンの下でロックされているすべてのリソースのロックが解除できない場合は、UNLOCK要求は失敗しなければなりません。
Any DAV compliant resource which supports the LOCK method MUST support the UNLOCK method.
LOCKメソッドをサポートする任意のDAV準拠のリソースは、UNLOCKメソッドをサポートしなければなりません。
>>Request
>>リクエスト
UNLOCK /workspace/webdav/info.doc HTTP/1.1 Host: webdav.sb.aol.com Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7> Authorization: Digest username="ejw", realm="ejw@webdav.sb.aol.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..."
/workspace/webdav/info.docのHTTP / 1.1ホストをUNLOCK：webdav.sb.aol.comロックトークンを<opaquelocktoken：a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>認証：ダイジェストユーザ名= "EJW"、領域=」 ejw@webdav.sb.aol.com "ナンス=" ... "URI =" /ワークスペース/ webdavの/ proposal.doc "レスポンス=" ... "不透明=" ...」
>>Response
>>回答
HTTP/1.1 204 No Content
HTTP / 1.1 204コンテンツなし
In this example, the lock identified by the lock token "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock included more than just one resource, the lock is removed from all resources included in the lock. The 204 (No Content) status code is used instead of 200 (OK) because there is no response entity body.
この例では、ロック・トークン「opaquelocktoken：a515cfa4-5da4-22e1-f5b5-00a0451e6bf7」で識別されるロックは成功し、リソースhttp://webdav.sb.aol.com/workspace/webdav/info.docから削除されます。このロックは、ただ一つのリソース以上のものを含まれている場合、ロックはロックに含まれるすべてのリソースから削除されます。 204（いいえコンテンツ）ステータスコードは、応答エンティティ体が存在しないため、200（OK）の代わりに使用されています。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、一回だけ、応答、及び不透明なフィールドが認可要求ヘッダで算出されていません。
9 HTTP Headers for Distributed Authoring
分散オーサリングのための9つのHTTPヘッダ
DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
DAVは= "DAV" "：" "1" [ "" "2"] [ "" ＃1が延在]
This header indicates that the resource supports the DAV schema and protocol as specified. All DAV compliant resources MUST return the DAV header on all OPTIONS responses.
このヘッダは、指定されたリソースは、DAVスキーマとプロトコルをサポートしていることを示しています。全てのDAV準拠したリソースは、すべてのOPTIONS応答にDAVヘッダを返さなければなりません。
The value is a list of all compliance classes that the resource supports. Note that above a comma has already been added to the 2. This is because a resource can not be level 2 compliant unless it is also level 1 compliant. Please refer to section 15 for more details. In general, however, support for one compliance class does not entail support for any other.
値は、リソースがサポートするすべてのコンプライアンス・クラスのリストです。コンマが既に2に追加されたものであり、それはまた、レベル1に準拠していない限り、リソースが準拠レベル2とすることができないためであることに留意されたいです。詳細については、セクション15を参照してください。しかしながら、一般的には、1つのコンプライアンスクラスのサポートは、他のサポートを必要としません。
Depth = "Depth" ":" ("0" | "1" | "infinity")
深さ= "深さ" "："（ "0" | "1" | "無限大"）
The Depth header is used with methods executed on resources which could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its immediate children, ("Depth: 1"), or the resource and all its progeny ("Depth: infinity").
奥行きヘッダは、潜在的方法は、唯一のリソース（「深さ：0」）に適用されるかどうかを示すために内部部材を有することができるリソース上で実行される方法で使用され、リソースとその直接の子、（「深さ：1 「）、またはリソースとそのすべての子孫（」深さ：無限大 "）。
The Depth header is only supported if a method's definition explicitly provides for such support.
メソッドの定義が明示的にそのようなサポートを提供した場合に深さヘッダーのみがサポートされています。
The following rules are the default behavior for any method that supports the Depth header. A method may override these defaults by defining different behavior in its definition.
以下のルールが深度ヘッダーをサポートする任意のメソッドのデフォルトの動作です。この方法は、その定義に異なる振る舞いを定義することによって、これらのデフォルトをオーバーライドすることができます。
Methods which support the Depth header may choose not to support all of the header's values and may define, on a case by case basis, the behavior of the method if a Depth header is not present. For example, the MOVE method only supports "Depth: infinity" and if a Depth header is not present will act as if a "Depth: infinity" header had been applied.
奥行きヘッダをサポートする方法は、ケース場合によって基づいて、方法の動作は、深さヘッダーが存在しない場合、ヘッダーのすべての値をサポートしないことを選択することができると規定してもよいです。例えば、MOVEメソッドは、唯一の「深さ：無限大」をサポートしており、深さヘッダーが存在しない場合はいるかのように行動するだろう「深さ：無限」ヘッダーが適用されていました。
Clients MUST NOT rely upon methods executing on members of their hierarchies in any particular order or on the execution being atomic unless the particular method explicitly provides such guarantees.
特定の方法は、明示的な保証を提供しない限り、クライアントは、特定の順序でその階層のメンバー上で実行される方法によりまたは原子であること実行当てにしてはいけません。
Upon execution, a method with a Depth header will perform as much of its assigned task as possible and then return a response specifying what it was able to accomplish and what it failed to do.
実行されると、深さヘッダーを持つ方法は、可能な限りその割り当てられたタスクの多くを実行し、それを達成することができたものを指定する応答とそれが行うには失敗したが返されます。
So, for example, an attempt to COPY a hierarchy may result in some of the members being copied and some not.
したがって、たとえば、階層をコピーしようとすると、コピーされ、いくつかのではないされているメンバーの一部になることがあります。
Any headers on a method that has a defined interaction with the Depth header MUST be applied to all resources in the scope of the method except where alternative behavior is explicitly defined. For example, an If-Match header will have its value applied against every resource in the method's scope and will cause the method to fail if the header fails to match.
奥行きヘッダと定義された相互作用を有している方法の任意のヘッダは別の動作が明示的に定義されている場合を除き、方法の範囲内のすべてのリソースに適用されなければなりません。例えば、もし-Matchヘッダは、その値はメソッドのスコープ内のすべてのリソースに対して適用されますと、ヘッダが一致しない場合、このメソッドは失敗します。
If a resource, source or destination, within the scope of the method with a Depth header is locked in such a way as to prevent the successful execution of the method, then the lock token for that resource MUST be submitted with the request in the If request header.
奥行きヘッダと方法の範囲内でリソース、ソースまたは宛先は、メソッドの実行が成功することを防止するような方法でロックされている場合、そのリソースのロック・トークンは、IFに要求と共に提出しなければなりません要求ヘッダー。
The Depth header only specifies the behavior of the method with regards to internal children. If a resource does not have internal children then the Depth header MUST be ignored.
深ヘッダーは、内部の子どもに関してメソッドの動作を指定します。リソースが内部の子供を持っていない場合は、深ヘッダは無視しなければなりません。
Please note, however, that it is always an error to submit a value for the Depth header that is not allowed by the method's definition. Thus submitting a "Depth: 1" on a COPY, even if the resource does not have internal members, will result in a 400 (Bad Request). The method should fail not because the resource doesn't have internal members, but because of the illegal value in the header.
メソッドの定義によって許可されていない深さのヘッダーの値を提出することを常に誤りであること、しかし、注意してください。したがって、「深さ：1」を提出COPYに、リソースが内部のメンバーを持っていない場合でも、400（悪いRequest）になります。この方法は、リソースが内部部材を有していないためではない失敗、しかし理由ヘッダで不正な値のはずです。
Destination = "Destination" ":" absoluteURI
先= "目的地" "：" absoluteURIで
The Destination header specifies the URI which identifies a destination resource for methods such as COPY and MOVE, which take two URIs as parameters. Note that the absoluteURI production is defined in [RFC2396].
宛先ヘッダは、パラメータとして2つのURIを取り、コピー、移動などの方法、の宛先リソースを識別するURIを指定します。 absoluteURIで生産は[RFC2396]で定義されていることに留意されたいです。
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) No-tag-list = List Tagged-list = Resource 1*List Resource = Coded-URL List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")" State-token = Coded-URL Coded-URL = "<" absoluteURI ">"
もし=「「もし」：」（1 *無タグリスト| 1 *タグリスト）いいえタグリスト=リストタグリスト=リソース1 *リストのリソース=コード化され、URLのリスト=「（」1 * （[ "しない"]（ステート・トークン| "[" エンティティタグ "]"）） "）" 状態トークン=符号化-URLコード化された-URL = "<" absoluteURIで ">"
The If header is intended to have similar functionality to the If-Match header defined in section 14.25 of [RFC2068]. However the If header is intended for use with any URI which represents state information, referred to as a state token, about a resource as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification.
もしヘッダは[RFC2068]のセクション14.25に定義されたIf-Matchヘッダに同様の機能を有することが意図されています。しかし、もしヘッダが状態情報を表す任意のURIで使用するために意図され、リソースならびにてETagについて、状態トークンと呼びます。状態のトークンの典型的な例は、ロックトークンで、ロックトークンは、本明細書で定義されているだけの状態トークンです。
All DAV compliant resources MUST honor the If header.
全てのDAV準拠したリソースがあればヘッダを尊重しなければなりません。
The If header's purpose is to describe a series of state lists. If the state of the resource to which the header is applied does not match any of the specified state lists then the request MUST fail with a 412 (Precondition Failed). If one of the described state lists matches the state of the resource then the request may succeed.
もしヘッダの目的は、状態の一連のリストを記述することです。ヘッダが適用されたリソースの状態が指定された状態のリストのいずれにも一致しない場合、要求は412（前提条件が失敗）で失敗しなければなりません。この状態リストの1がリソースの状態と一致した場合は、要求が成功する可能性があります。
Note that the absoluteURI production is defined in [RFC2396].
absoluteURIで生産は[RFC2396]で定義されていることに留意されたいです。
The No-tag-list production describes a series of state tokens and ETags. If multiple No-tag-list productions are used then one only needs to match the state of the resource for the method to be allowed to continue.
無タグリストの生産は状態トークンとてETagのシリーズを記述しています。複数の無タグリストの制作が使用されている場合は、1だけ継続させるべき方法のためのリソースの状態を一致させる必要があります。
If a method, due to the presence of a Depth or Destination header, is applied to multiple resources then the No-tag-list production MUST be applied to each resource the method is applied to.
深さまたは宛先ヘッダの存在に方法は、複数のリソースに適用される場合、無タグリスト生産は方法が適用される各リソースに適用されなければなりません。
If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another ETag"])
もし：（<locktoken：-書き込みlocktoken> [ "私はETagをしています"]）（[ "私は別のETagです"]）
The previous header would require that any resources within the scope of the method must either be locked with the specified lock token and in the state identified by the "I am an ETag" ETag or in the state identified by the second ETag "I am another ETag". To put the matter more plainly one can think of the previous If header as being in the form (or (and <locktoken:a-write-lock-token> ["I am an ETag"]) (and ["I am another ETag"])).
前のヘッダは方法の範囲内の任意のリソースはいずれかの指定されたロック・トークンとし、「私はのETag」のETagによって、または第二のETagによって同定状態で同定された状態でロックされなければならないことを必要とするであろう「私は別の午前ETag」。場合1が前を考えることができ、より分かりやすく問題を置くために、ヘッダー形態である（または（および<locktoken：-書き込みlocktoken>として私は "）[「私はETagをしています」]（および[別ETag "]））。
The tagged-list production scopes a list production. That is, it specifies that the lists following the resource specification only apply to the specified resource. The scope of the resource production begins with the list production immediately following the resource production and ends with the next resource production, if any.
タグ付けされたリストの生産は、リストの生成をスコープ。つまり、それはリソースの指定を次のリストのみが指定されたリソースに適用されることを指定します。資源生産の範囲は、リストの生産はすぐに資源の生産を、以下で始まり、もしあれば、次のリソースの生産を終了します。
When the If header is applied to a particular resource, the Tagged-list productions MUST be searched to determine if any of the listed resources match the operand resource(s) for the current method. If none of the resource productions match the current resource then the header MUST be ignored. If one of the resource productions does match the name of the resource under consideration then the list productions following the resource production MUST be applied to the resource in the manner specified in the previous section.
もしヘッダが特定のリソースに適用した場合、タグリストプロダクションは列挙されたリソースのいずれかが、現在の方法のためのオペランドリソース（単数または複数）と一致するかどうかを決定するために探索しなければなりません。リソース・プロダクションのいずれも現在のリソースと一致しない場合、ヘッダは無視されなければなりません。リソースプロダクションの一つは、検討中のリソースの名前と一致しない場合は、リソースの生産を以下のリストの制作は、前のセクションで指定された方法でリソースに適用されなければなりません。
The same URI MUST NOT appear more than once in a resource production in an If header.
同じURIは、Ifヘッダーで資源生産における回以上現れてはなりません。
COPY /resource1 HTTP/1.1 Host: www.foo.bar Destination: http://www.foo.bar/resource2 If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token> [W/"A weak ETag"]) (["strong ETag"]) <http://www.bar.bar/random>(["another strong ETag"])
COPY /リソース1 HTTP / 1.1ホスト：www.foo.bar先：http://www.foo.bar/resource2の場合：<http://www.foo.bar/resource1>（<locktoken：書き込みロック-token>）[ "弱のETag" / W]（[ "強いのETag"]）<http://www.bar.bar/random>（[ "別の強いのETag"]）
In this example http://www.foo.bar/resource1 is being copied to http://www.foo.bar/resource2. When the method is first applied to http://www.foo.bar/resource1, resource1 must be in the state specified by "(<locktoken:a-write-lock-token> [W/"A weak ETag"]) (["strong ETag"])", that is, it either must be locked with a lock token of "locktoken:a-write-lock-token" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag".
この例では、http://www.foo.bar/resource1 http://www.foo.bar/resource2にコピーされています。 「（：[ "弱のETag / W] <書き込み-locktoken locktoken>」）メソッドは、最初http://www.foo.bar/resource1に印加されると、リソース1は、で指定された状態でなければなりません（[「強いのETag」]）」、すなわち、そのいずれかのロック・トークンにロックされなければならない 『locktoken：書き込み-locktoken』と弱いエンティティタグW /持っている 『弱のETagの』またはそれがなければなりません強いエンティティタグ「強いのETag」を持っています。
That is the only success condition since the resource http://www.bar.bar/random never has the method applied to it (the only other resource listed in the If header) and http://www.foo.bar/resource2 is not listed in the If header.
すなわち、リソースhttp://www.bar.bar/randomが（もしヘッダに記載されている唯一の他のリソース）とhttp://www.foo.bar/resource2に適用方法を有することはないので、唯一の成功条件でありますもしヘッダに記載されていません。
Every state token or ETag is either current, and hence describes the state of a resource, or is not current, and does not describe the state of a resource. The boolean operation of matching a state token or ETag to the current state of a resource thus resolves to a true or false value. The not production is used to reverse that value. The scope of the not production is the state-token or entity-tag immediately following it.
トークンまたはETagのすべての状態のいずれかの電流であるため、リソースの状態を記述する、または現在ではなく、リソースの状態を記載していません。リソースの現在の状態に状態がトークンまたはETagの一致のブール演算は、このように真または偽の値に解決されます。ない生産は、その値を反転させるために使用されています。ない生産の範囲は、すぐ次の状態トークンまたはエンティティタグです。
If: (Not <locktoken:write1> <locktoken:write2>)
もし：（<locktoken：書き込み1>ない<locktoken：2の書き込み>）
When submitted with a request, this If header requires that all operand resources must not be locked with locktoken:write1 and must be locked with locktoken:write2.
リクエストを送信した場合、この場合はヘッダーは、すべてのオペランドのリソースがlocktokenでロックされてはならないことを要求：WRITE1とlocktokenでロックする必要がありますWRITE2。
When performing If header processing, the definition of a matching state token or entity tag is as follows.
もしヘッダ処理を行う場合、整合状態トークンまたはエンティティタグの定義は以下の通りです。
Matching entity tag: Where the entity tag matches an entity tag associated with that resource.
エンティティタグがそのリソースに関連付けられたエンティティタグに一致する：エンティティタグをマッチング。
Matching state token: Where there is an exact match between the state token in the If header and any state token on the resource.
一致状態トークン：もしヘッダーの状態トークンとリソース上の任意の状態のトークンの間の正確な一致があります。
Non-DAV compliant proxies will not honor the If header, since they will not understand the If header, and HTTP requires non-understood headers to be ignored. When communicating with HTTP/1.1 proxies, the "Cache-Control: no-cache" request header MUST be used so as to prevent the proxy from improperly trying to service the request from its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache" request header MUST be used for the same reason.
彼らはもしヘッダを理解することはありませんので、非DAV準拠したプロキシは、もしヘッダを尊重せず、HTTPは無視されるように非理解のヘッダーが必要です。 HTTP / 1.1プロキシ「のCache-Control：キャッシュなし」と通信するときに不適切にそのキャッシュからの要求にサービスを提供しようとするから、プロキシを防止するようにリクエストヘッダを使用しなければなりません。 HTTP / 1.0プロキシを扱うときは、「プラグマ：キャッシュなし」リクエストヘッダは、同じ理由のために使用しなければなりません。
Lock-Token = "Lock-Token" ":" Coded-URL
ロック・トークンは= "ロック・トークン" "：" コード化-URL
The Lock-Token request header is used with the UNLOCK method to identify the lock to be removed. The lock token in the Lock-Token request header MUST identify a lock that contains the resource identified by Request-URI as a member.
ロックトークン要求ヘッダが除去されるロックを識別するために、UNLOCKメソッドで使用されています。ロックトークン要求ヘッダーのロックトークンが部材としてのRequest-URIによって識別されたリソースが含まれているロックを識別しなければなりません。
The Lock-Token response header is used with the LOCK method to indicate the lock token created as a result of a successful LOCK request to create a new lock.
ロック・トークンレスポンスヘッダは、新しいロックを作成するために、成功したLOCK要求の結果として作成されたロック・トークンを示すために、LOCKメソッドで使用されています。
Overwrite = "Overwrite" ":" ("T" | "F")
上書き= " "上書き"："（ "T" | "F"）
The Overwrite header specifies whether the server should overwrite the state of a non-null destination resource during a COPY or MOVE. A value of "F" states that the server must not perform the COPY or MOVE operation if the state of the destination resource is non-null. If the overwrite header is not included in a COPY or MOVE request then the resource MUST treat the request as if it has an overwrite header of value "T". While the Overwrite header appears to duplicate the functionality of the If-Match: * header of HTTP/1.1, If-Match applies only to the Request-URI, and not to the Destination of a COPY or MOVE.
上書きヘッダは、サーバがコピーまたは移動中に非ヌル宛先リソースの状態を上書きするかどうかを指定します。 「F」の値は、先のリソースの状態が非nullの場合、サーバーコピーまたは移動操作を実行してはならないと述べています。上書きヘッダをコピーまたは移動要求に含まれていない場合は、値の上書きヘッダ「T」を有するかのように、リソースは、要求を処理しなければなりません。マッチした場合、コピーまたは移動の先にのみのRequest-URIに適用され、そしてない、* HTTP / 1.1のヘッダー：上書きヘッダは、If-マッチの機能を複製に見えるが。
If a COPY or MOVE is not performed due to the value of the Overwrite header, the method MUST fail with a 412 (Precondition Failed) status code.
コピーまたは移動を伴う上書きヘッダの値に対して実行されていない場合は、方法412（前提条件が失敗した）ステータスコードを失敗しなければなりません。
All DAV compliant resources MUST support the Overwrite header.
すべてのDAV対応のリソースが上書きヘッダをサポートしなければなりません。
The Status-URI response header may be used with the 102 (Processing) status code to inform the client as to the status of a method.
ステータス-URIレスポンスヘッダは、メソッドの状態に、クライアントに通知する102（処理）ステータスコードを使用してもよいです。
Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code is defined in 6.1.1 of [RFC2068]
ステータス-URI = "ステータス-URI" "：" *（ステータスコード符号化-URL）;ステータスコードは[RFC2068]の6.1.1で定義されています
The URIs listed in the header are source resources which have been affected by the outstanding method. The status code indicates the resolution of the method on the identified resource. So, for example, if a MOVE method on a collection is outstanding and a 102 (Processing) response with a Status-URI response header is returned, the included URIs will indicate resources that have had move attempted on them and what the result was.
ヘッダにリストされたURIは、未処理の方法の影響を受けているソースリソースです。ステータスコードは、識別されたリソース上の方法の解像度を示します。コレクションのMOVEメソッドが優れているとステータス-URIレスポンスヘッダと102（処理）、応答が返されるのであれば、例えば、含まれるURIが動きを持っていたリソースは、それらに試みたと表示され、その結果はどうでした。
TimeOut = "Timeout" ":" 1#TimeType TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other) DAVTimeOutVal = 1*digit Other = "Extend" field-value ; See section 4.2 of [RFC2068]
タイムアウトが= "タイムアウト" "：" 1＃TimeType TimeType =（ "2番目に" DAVTimeOutVal | "無限" |その他）DAVTimeOutVal = 1 *ケタその他= "" フィールド値を拡張。 [RFC2068]のセクション4.2を参照
Clients may include Timeout headers in their LOCK requests. However, the server is not required to honor or even consider these requests. Clients MUST NOT submit a Timeout request header with any method other than a LOCK method.
クライアントは、LOCK要求でタイムアウトヘッダを含むことができます。ただし、サーバーは、名誉、あるいはこれらの要求を考慮することが必要とされていません。クライアントは、LOCKメソッド以外の方法でタイムアウトリクエストヘッダを提出してはなりません。
A Timeout request header MUST contain at least one TimeType and may contain multiple TimeType entries. The purpose of listing multiple TimeType entries is to indicate multiple different values and value types that are acceptable to the client. The client lists the TimeType entries in order of preference.
タイムアウト要求ヘッダは、少なくとも一つのTimeTypeを含まなければなりませんし、複数TimeTypeエントリを含んでいてもよいです。複数TimeTypeエントリをリストの目的は、クライアントに受け入れられる複数の異なる値と値の種類を示すためです。クライアントは、優先順にTimeTypeエントリを示しています。
Timeout response values MUST use a Second value, Infinite, or a TimeType the client has indicated familiarity with. The server may assume a client is familiar with any TimeType submitted in a Timeout header.
タイムアウト応答値は、クライアントが精通を示した2番目の値、無限、またはTimeTypeを使用しなければなりません。サーバーは、クライアントがタイムアウトヘッダに提出されたTimeTypeに精通していると仮定します。
The "Second" TimeType specifies the number of seconds that will elapse between granting of the lock at the server, and the automatic removal of the lock. The timeout value for TimeType "Second" MUST NOT be greater than 2^32-1.
「第二」TimeTypeは、サーバでのロックの付与の間に経過する秒数、およびロックの自動削除を指定します。 TimeType「セカンド」のタイムアウト値は2 ^ 32-1を超えてはなりません。
The timeout counter SHOULD be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received.
タイムアウトカウンタは、ロックの所有者がサポートされていない方法、または失敗である方法を含むロックの任意のメンバーにする方法を送信するいつでも再起動する必要があります。リフレッシュLOCKメソッドが正常に受信された場合はロックがリフレッシュされなければなりません。
If the timeout expires then the lock may be lost. Specifically, if the server wishes to harvest the lock upon time-out, the server SHOULD act as if an UNLOCK method was executed by the server on the resource using the lock token of the timed-out lock, performed with its override authority. Thus logs should be updated with the disposition of the lock, notifications should be sent, etc., just as they would be for an UNLOCK request.
タイムアウトが満了した場合、ロックが失われる可能性があります。サーバがタイムアウト時にロックを収穫することを望む場合、具体的に、サーバは、UNLOCKメソッドは、そのオーバーライド権限で実行タイムアウトロックのロック・トークンを使用してリソース上のサーバによって実行されたかのように行動しなければなりません。したがって、ログは、彼らがUNLOCK要求のためのものと同じように、など、通知が送られるべきである、ロックの処分で更新する必要があります。
Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going off-line.
サーバは、彼らは、クライアントが行おうとする活動の種類を示すことになるとして、クライアントから送信された値に細心の注意を払うことをお勧めします。例えば、ブラウザで実行中のアプレットは、リソースをロックする必要があるかもしれませんが、理由は、アプレットが実行されている内環境の不安定性のため、アプレットは警告なしにオフにすることができます。その結果、アプレットは、アプレットが死んだ場合、ロックが早く収穫できるように、比較的小さなタイムアウト値をお願いすることがあります。しかし、文書管理システムは、そのユーザーがオフラインに行くことを計画することができるので、非常に長いタイムアウトをお願いすることがあります。
A client MUST NOT assume that just because the time-out has expired the lock has been lost.
クライアントがタイムアウトが満了しているという理由だけでロックが失われたと仮定してはいけません。
10 Status Code Extensions to HTTP/1.1
HTTP / 1.1から10のステータスコードの拡張機能
The following status codes are added to those defined in HTTP/1.1 [RFC2068].
次のステータスコードは、HTTP / 1.1 [RFC2068]で定義されたものに追加されます。
The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed.
102（処理）ステータスコードは、サーバが完全な要求を受け入れたが、まだそれを完了していないことをクライアントに通知するために使用暫定応答です。サーバは、要求が完了するまでにかなりの時間がかかります合理的な期待を持っているときに、このステータスコードは、送ってください。ガイダンスとして、方法102（処理）レスポンスを返すべきサーバーを処理するために20秒より長く（合理的な、しかし任意の値）を取っている場合。要求が完了した後、サーバーは最終的な応答を送らなければなりません。
Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 (Processing) status code to indicate to the client that the server is still processing the method.
方法は、潜在的に処理する時間の長い期間、深ヘッダをサポートし、特に方法を取ることができます。このような場合、クライアントは、タイムアウトも接続応答を待っている間。これを防止するために、サーバは、サーバがまだ方法を処理しているクライアントに示すために102（処理）ステータス・コードを戻すことができます。
The 207 (Multi-Status) status code provides status for multiple independent operations (see section 11 for more information).
207（マルチステータス）ステータスコード（詳細については、セクション11を参照）は、複数の独立した操作のステータスを提供します。
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions.
422（処理不可能なエンティティ）ステータスコードは、サーバは、要求エンティティ（したがって415（サポートされていないメディアタイプ）ステータスコードは不適切である）のコンテンツタイプを把握手段、及び要求エンティティの構文は、このように（400（不正な要求正しいです）ステータスコードは不適切である）が、含まれる命令を処理できませんでした。例えば、このエラー状態は、XMLリクエストボディが整形式（すなわち、構文的に正しい）が含まれている場合に発生するが、意味的に誤ったXML命令してもよいです。
The 423 (Locked) status code means the source or destination resource of a method is locked.
423（ロック）状態コードは、メソッドのソースまたは宛先リソースがロックされていることを意味します。
The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. For example, if a command in a PROPPATCH method fails then, at minimum, the rest of the commands will also fail with 424 (Failed Dependency).
424（失敗した依存）ステータスコードは、要求されたアクションは別のアクションに依存し、そのアクションが失敗したため、この方法は、リソース上で実行することができなかったことを意味します。 PROPPATCH方法でコマンドに失敗した場合たとえば、最低でも、コマンドの残りの部分はまた、424（失敗した依存）で失敗します。
The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request which received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.
507（ストレージ不足）ステータスコードは、サーバーが正常に要求を完了するために必要な表現を保存することができないので、この方法は、リソース上で実行することができなかったことを意味します。この状態は一時的であると考えられています。このステータスコードを受信した要求がユーザーアクションの結果であった場合、それが別のユーザアクションによって要求されるまで、要求が繰り返されてはなりません。
11 Multi-Status Response
11マルチステータス応答
The default 207 (Multi-Status) response body is a text/xml or application/xml HTTP entity that contains a single XML element called multistatus, which contains a set of XML elements called response which contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a response XML element.
デフォルト207（マルチステータス）応答本体がtext / xmlまたはapplication / xmlのHTTPエンティティ200、300、400を含む応答と呼ばれるXML要素のセットを含むmultistatusと呼ばれる単一のXML要素が含まれ、そして500シリーズでありますステータスコードは、メソッド呼び出しの間に発生します。 100シリーズのステータスコードは、応答XML要素に記録されるべきではありません。
12 XML Element Definitions
12のXML要素定義
In the section below, the final line of each section gives the element type declaration using the format defined in [REC-XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element).
以下のセクションでは、各セクションの最後の行は、[REC-XML]で定義されたフォーマットを使用して要素型宣言を与えます。 「値」フィールドは、存在する場合、BNF（すなわち、さらにPCDATA要素の値を制限する）を使用してXML要素の許容コンテンツにさらなる制限を指定します。
Name: activelock Namespace: DAV: Purpose: Describes a lock on a resource.
名前：activelock名前空間：DAV：目的：リソースのロックを記述します。
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?) >
<！ELEMENTのactivelock（LOCKSCOPE、種類のLockType、深さ、所有者？、？、タイムアウトlocktoken？）>
Name: depth Namespace: DAV: Purpose: The value of the Depth header. Value: "0" | "1" | "infinity"
名前：深さ名前空間：DAV：目的：奥行きヘッダの値。値： "0" | "1" | 「無限大」
<!ELEMENT depth (#PCDATA) >
<！ELEMENTの深さ（#PCDATA）>
Name: locktoken Namespace: DAV: Purpose: The lock token associated with a lock. Description: The href contains one or more opaque lock token URIs which all refer to the same lock (i.e., the OpaqueLockToken-URI production in section 6.4).
名前：locktoken名前空間：DAV：目的：ロックに関連付けられたロック・トークン。説明：HREFがすべて同じロックを参照して一の以上の不透明なロックトークンURIを含んでいる（すなわち、セクション6.4でOpaqueLockToken-URI生産）。
<!ELEMENT locktoken (href+) >
<！ELEMENT locktoken（HREF +）>
Name: timeout Namespace: DAV: Purpose: The timeout associated with a lock Value: TimeType ;Defined in section 9.8
名前：タイムアウト名前空間：DAV：目的：ロック値に関連付けられたタイムアウト：TimeType、セクション9.8で定義され
<!ELEMENT timeout (#PCDATA) >
<！ELEMENTタイムアウト（#PCDATA）>
Name: collection Namespace: DAV: Purpose: Identifies the associated resource as a collection. The resourcetype property of a collection resource MUST have this value.
名前：コレクションの名前空間：DAV：目的：コレクションとして関連付けられたリソースを識別します。コレクションリソースのresourcetypeのプロパティは、この値を持つ必要があります。
<!ELEMENT collection EMPTY >
<！ELEMENTコレクションEMPTY>
Name: href Namespace: DAV: Purpose: Identifies the content of the element as a URI. Value: URI ; See section 3.2.1 of [RFC2068]
名前：hrefの名前空間：DAV：目的：URIとして要素の内容を識別します。値：URI。 [RFC2068]のセクション3.2.1を参照してください。
<!ELEMENT href (#PCDATA)>
<！ELEMENTのHREF（#PCDATA）>
Name: link Namespace: DAV: Purpose: Identifies the property as a link and contains the source and destination of that link. Description: The link XML element is used to provide the sources and destinations of a link. The name of the property containing the link XML element provides the type of the link. Link is a multi-valued element, so multiple links may be used together to indicate multiple links with the same type. The values in the href XML elements inside the src and dst XML elements of the link XML element MUST NOT be rejected if they point to resources which do not exist.
名前：リンクの名前空間：DAV：目的：リンクとしてプロパティを識別し、そのリンクの送信元と送信先が含まれています。説明：リンクXML要素がリンクのソースとデスティネーションを提供するために使用されます。リンクのXML要素を含むプロパティの名前は、リンクの種類を提供します。リンクは、多値要素であるので、複数のリンクが同じタイプの複数のリンクを示すために一緒に使用されてもよいです。彼らは存在しないリソースを指している場合、リンクのXML要素のsrcとdst XML要素内のhrefのXML要素の値は拒否してはなりません。
<!ELEMENT link (src+, dst+) >
<！ELEMENTリンク（SRC +、DST +）>
Name: dst Namespace: DAV: Purpose: Indicates the destination of a link Value: URI
名前：DST名前空間：DAV：目的：リンク値の送信先を示します：URI
<!ELEMENT dst (#PCDATA) >
<！ELEMENTなど（#PCDATA）>
Name: src Namespace: DAV: Purpose: Indicates the source of a link.
名前：SRC名前空間：DAV：目的：リンクのソースを示します。
Value: URI
値：URI
<!ELEMENT src (#PCDATA) >
<！ELEMENTのSRC（#PCDATA）>
Name: lockentry Namespace: DAV: Purpose: Defines the types of locks that can be used with the resource.
名前：lockentry名前空間：DAV：目的：リソースで使用できるロックの種類を定義します。
<!ELEMENT lockentry (lockscope, locktype) >
<！ELEMENTのlockentry（LOCKSCOPE、種類のLockType）>
Name: lockinfo Namespace: DAV: Purpose: The lockinfo XML element is used with a LOCK method to specify the type of lock the client wishes to have created.
名前：名前空間LOCKINFO：DAV：目的：LOCKINFOのXML要素は、クライアントが作成しているしたいロックの種類を指定するには、LOCKメソッドで使用されています。
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
<！ELEMENTのLOCKINFO（LOCKSCOPE、種類のLockType、所有者？）>
Name: lockscope Namespace: DAV: Purpose: Specifies whether a lock is an exclusive lock, or a shared lock.
名前：LOCKSCOPE名前空間：DAV：目的：ロックが排他ロック、または共有ロックであるかどうかを指定します。
<!ELEMENT lockscope (exclusive | shared) >
<！ELEMENTのLOCKSCOPE（排他|共有）>
Name: exclusive Namespace: DAV: Purpose: Specifies an exclusive lock
名前：排他的な名前空間：DAV：目的：排他ロックを指定します。
<!ELEMENT exclusive EMPTY >
<！ELEMENT排他EMPTY>
Name: shared Namespace: DAV: Purpose: Specifies a shared lock
名前：共有の名前空間：DAV：目的：共有ロックを指定します。
<!ELEMENT shared EMPTY >
<！ELEMENTはEMPTY共有しました>
Name: locktype Namespace: DAV: Purpose: Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock.
名前：LockTypeの名前空間：DAV：目的：ロックのアクセスタイプを指定します。現時点では、この仕様は、唯一のロックタイプ、書き込みロックを定義します。
<!ELEMENT locktype (write) >
<！ELEMENT LockTypeに（書き込み）>
Name: write Namespace: DAV: Purpose: Specifies a write lock.
名前：DAV：目的：名前空間を作成するには、書き込みロックを指定します。
<!ELEMENT write EMPTY >
<！ELEMENT EMPTY書きます>
Name: multistatus Namespace: DAV: Purpose: Contains multiple response messages. Description: The responsedescription at the top level is used to provide a general message describing the overarching nature of the response. If this value is available an application may use it instead of presenting the individual response descriptions contained within the responses.
名前：multistatus名前空間：DAV：目的：複数の応答メッセージが含まれています。説明：トップレベルresponsedescriptionは、応答の包括的な性質を記述する一般的なメッセージを提供するために使用されます。この値が利用可能な場合は、アプリケーションの応答に含まれる個々の応答の説明を提示するのではなく、それを使用することができます。
<!ELEMENT multistatus (response+, responsedescription?) >
<！ELEMENTマルチ状態（応答、応答の説明？）>
Name: response Namespace: DAV: Purpose: Holds a single response describing the effect of a method on resource and/or its properties. Description: A particular href MUST NOT appear more than once as the child of a response XML element under a multistatus XML element. This requirement is necessary in order to keep processing costs for a response to linear time. Essentially, this prevents having to search in order to group together all the responses by href. There are, however, no requirements regarding ordering based on href values.
名前：応答の名前空間：DAV：目的：リソースおよび/またはその特性に方法の効果を説明する単一の応答を保持します。説明：特定のhrefはmultistatus XML要素の下の応答XML要素の子として複数回現れてはなりません。この要件は、線形時間への応答のための処理コストを維持するために必要です。基本的に、これはHREFで一緒にグループ化するために、すべての回答を検索しなくても済みます。 hrefの値に基づいて発注に関していかなる要件は、しかし、ありません。
<!ELEMENT response (href, ((href*, status)|(propstat+)), responsedescription?) >
<！ELEMENT応答（HREF、（（HREFの*、ステータス）|？（propstatの+））、responsedescription）>
Name: propstat Namespace: DAV: Purpose: Groups together a prop and status element that is associated with a particular href element. Description: The propstat XML element MUST contain one prop XML element and one status XML element. The contents of the prop XML element MUST only list the names of properties to which the result in the status element applies.
名前：propstat名前空間：DAV：目的：一緒にグループ特定HREF要素に関連付けられている支柱とステータス要素。説明：propstat XML要素には、1本の支柱XML要素と1つのステータスXML要素を含まなければなりません。支柱XML要素の内容は、ステータスのみ要素で結果が適用されるプロパティの名前をリストする必要があります。
<!ELEMENT propstat (prop, status, responsedescription?) >
<！ELEMENTのpropstat（小道具、ステータス、responsedescription？）>
Name: status Namespace: DAV: Purpose: Holds a single HTTP status-line Value: status-line ;status-line defined in [RFC2068]
名前：ステータス名前空間：DAV：目的：単一のHTTPステータスライン値保持：ステータスラインと、[RFC2068]で定義されたステータスライン
<!ELEMENT status (#PCDATA) >
<！ELEMENTステータス（#PCDATA）>
Name: responsedescription Namespace: DAV: Purpose: Contains a message that can be displayed to the user explaining the nature of the response. Description: This XML element provides information suitable to be presented to a user.
名前：responsedescription名前空間：DAV：目的：応答の性質を説明する、ユーザーに表示できるメッセージが含まれています。説明：このXML要素をユーザに提示するのに適した情報を提供します。
<!ELEMENT responsedescription (#PCDATA) >
<！ELEMENTのresponsedescription（#PCDATA）>
Name: owner Namespace: DAV: Purpose: Provides information about the principal taking out a lock. Description: The owner XML element provides information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the principal (such as the URL of a homepage) who owns a lock.
名前：所有者の名前空間：DAV：目的：ロックを取り出す元本についての情報を提供します。説明：所有者XML要素は、直接（電話番号やメールURIなど）校長に連絡、またはロックを所有している（例えば、ホームページのURLなど）元本を発見するためのいずれかのために十分な情報を提供します。
<!ELEMENT owner ANY>
<！ELEMENT所有者ANY>
Name: prop Namespace: DAV: Purpose: Contains properties related to a resource. Description: The prop XML element is a generic container for properties defined on resources. All elements inside a prop XML element MUST define properties related to the resource. No other elements may be used inside of a prop element.
名前：小道具名前空間：DAV：目的：リソースに関連するプロパティが含まれています。説明：小道具XML要素がリソースに定義されたプロパティのための一般的なコンテナです。支柱XML要素内のすべての要素は、リソースに関連するプロパティを定義しなければなりません。他の要素は、支柱エレメントの内部で使用することはできません。
<!ELEMENT prop ANY>
<！ELEMENT ANYを支えます>
Name: propertybehavior Namespace: DAV: Purpose: Specifies how properties are handled during a COPY or MOVE. Description: The propertybehavior XML element specifies how properties are handled during a COPY or MOVE. If this XML element is not included in the request body then the server is expected to act as defined by the default property handling behavior of the associated method. All WebDAV compliant resources MUST support the propertybehavior XML element.
名前：propertybehavior名前空間：DAV：目的：プロパティをコピーまたは移動中にどのように扱われるかを指定します。説明：propertybehavior XML要素のプロパティをコピーまたは移動中にどのように扱われるかを指定します。このXML要素がリクエストボディに含まれていない場合、サーバは、関連する方法のデフォルトプロパティの処理動作によって定義されるように行動することが期待されます。すべてのWebDAV準拠したリソースはpropertybehavior XML要素をサポートしなければなりません。
<!ELEMENT propertybehavior (omit | keepalive) >
<！ELEMENT propertybehavior（省略|キープアライブを）>
Name: keepalive Namespace: DAV: Purpose: Specifies requirements for the copying/moving of live properties. Description: If a list of URIs is included as the value of keepalive then the named properties MUST be "live" after they are copied (moved) to the destination resource of a COPY (or MOVE). If the value "*" is given for the keepalive XML element, this designates that all live properties on the source resource MUST be live on the destination. If the requirements specified by the keepalive element can not be honored then the method MUST fail with a 412 (Precondition Failed). All DAV compliant resources MUST support the keepalive XML element for use with the COPY and MOVE methods. Value: "*" ; #PCDATA value can only be "*"
名前：キープアライブ名前空間：DAV：目的：ライブプロパティのコピー/移動するための要件を指定します。説明：彼らがコピーされた後、キープアライブの値はその後、名前付きプロパティは、「ライブ」でなければならないとして、URIのリストが含まれている場合はCOPY（またはMOVE）の先リソースへ（移動）。値「*」はキープアライブXML要素のために与えられた場合、これはソースリソース上のすべてのライブのプロパティは、先にライブでなければならないことを指定します。キープアライブ要素で指定された要件を光栄にすることができない場合は、この方法は、412（前提条件に失敗しました）で失敗しなければなりません。全てのDAV準拠したリソースは、COPYとMOVEメソッドで使用するためにキープアライブXML要素をサポートしなければなりません。値： "*"; #PCDATA値は「*」することができ
<!ELEMENT keepalive (#PCDATA | href+) >
<！ELEMENTキープアライブ（#PCDATA | HREFの+）>
Name: omit Namespace: DAV: Purpose: The omit XML element instructs the server that it should use best effort to copy properties but a failure to copy a property MUST NOT cause the method to fail. Description: The default behavior for a COPY or MOVE is to copy/move all properties or fail the method. In certain circumstances, such as when a server copies a resource over another protocol such as FTP, it may not be possible to copy/move the properties associated with the resource. Thus any attempt to copy/move over FTP would always have to fail because properties could not be moved over, even as dead properties. All DAV compliant resources MUST support the omit XML element on COPY/MOVE methods.
名前：DAV：目的：オミットXML要素は、それがプロパティをコピーするために最善の努力を使用する必要がありますが、プロパティをコピーするための失敗が失敗する方法を引き起こしてはならないサーバに指示名前空間を省略します。説明：COPYまたはMOVEのデフォルト動作では、コピー/すべてのプロパティを移動したりする方法を失敗することです。そのようなサーバコピーFTPなど他のプロトコル上のリソースとして特定の状況では、リソースに関連付けられたプロパティを移動/コピーすることが可能ではないかもしれません。したがって/ FTP経由の動きをコピーしようとすると、常に性質がさえ死んプロパティとして、上に移動することができなかったために失敗しなければならないでしょう。全てのDAV準拠したリソースは、COPY / MOVEメソッドのオミットXML要素をサポートしなければなりません。
<!ELEMENT omit EMPTY >
<！ELEMENT EMPTY省略>
Name: propertyupdate Namespace: DAV: Purpose: Contains a request to alter the properties on a resource. Description: This XML element is a container for the information required to modify the properties on the resource. This XML element is multi-valued.
名前：propertyupdate名前空間：DAV：目的：リソースのプロパティを変更するための要求が含まれています。説明：このXML要素は、リソースのプロパティを変更するために必要な情報のコンテナです。このXML要素は、多値です。
<!ELEMENT propertyupdate (remove | set)+ >
<！ELEMENTのpropertyupdate（削除|セット）+>
Name: remove Namespace: DAV: Purpose: Lists the DAV properties to be removed from a resource. Description: Remove instructs that the properties specified in prop should be removed. Specifying the removal of a property that does not exist is not an error. All the XML elements in a prop XML element inside of a remove XML element MUST be empty, as only the names of properties to be removed are required.
名前：DAV：目的：名前空間を削除するリソースから削除するDAVのプロパティを一覧表示します。説明：削除は小道具で指定されたプロパティを削除することを指示します。存在しないプロパティの削除を指定すると、エラーではありません。除去されるプロパティの名前だけが必要とされるように削除XML要素の内部支柱XML要素内のすべてのXML要素は、空でなければなりません。
<!ELEMENT remove (prop) >
<！ELEMENT削除（プロパ）>
Name: set Namespace: DAV: Purpose: Lists the DAV property values to be set for a resource.
名前：DAV：目的：名前空間を設定し、リソースに設定するDAVプロパティ値を一覧表示します。
Description: The set XML element MUST contain only a prop XML element. The elements contained by the prop XML element inside the set XML element MUST specify the name and value of properties that are set on the resource identified by Request-URI. If a property already exists then its value is replaced. Language tagging information in the property's value (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND.
説明：set XML要素のみ支柱XML要素を含まなければなりません。設定されたXML要素内支柱XML要素に含まれる要素は、Request-URIによって識別されたリソースで設定されるプロパティの名前と値を指定する必要があります。プロパティが既に存在する場合は、その値が置き換えられます。プロパティの値に情報をタグ付け言語（「XML：LANG」に存在する場合、属性は）永続的プロパティと一緒に保存されなければならない、とPROPFINDを使用して、その後検索可能でなければなりません。
<!ELEMENT set (prop) >
<！ELEMENT設定（小道具）>
Name: propfind Namespace: DAV: Purpose: Specifies the properties to be returned from a PROPFIND method. Two special elements are specified for use with propfind, allprop and propname. If prop is used inside propfind it MUST only contain property names, not values.
名前：PROPFIND名前空間：DAV：目的：PROPFINDメソッドから返されるプロパティを指定します。二つの特別な要素がPROPFIND、allpropとPROPNAMEで使用するように指定されています。小道具は、内部で使用PROPFINDされた場合にのみ、プロパティ名ではなく、値を含まなければなりません。
<!ELEMENT propfind (allprop | propname | prop) >
<！ELEMENT PROPFIND（allprop | PROPNAME |小道具）>
Name: allprop Namespace: DAV: Purpose: The allprop XML element specifies that all property names and values on the resource are to be returned.
名前：allprop名前空間：DAV：目的：allpropのXML要素は、リソース上のすべてのプロパティ名と値が返されることを指定します。
<!ELEMENT allprop EMPTY >
<EMPTY allprop！ELEMENT>
Name: propname Namespace: DAV: Purpose: The propname XML element specifies that only a list of property names on the resource is to be returned.
名前：PROPNAME名前空間：DAV：目的：PROPNAMEのXML要素は、リソースのプロパティ名のリストのみが返されることを指定します。
<!ELEMENT propname EMPTY >
<！ELEMENTのPROPNAME EMPTY>
13 DAV Properties
13のDVプロパティ
For DAV properties, the name of the property is also the same as the name of the XML element that contains its value. In the section below, the final line of each section gives the element type declaration using the format defined in [REC-XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element).
DAVのプロパティでは、プロパティの名前も、その値を含むXML要素の名前と同じです。以下のセクションでは、各セクションの最後の行は、[REC-XML]で定義されたフォーマットを使用して要素型宣言を与えます。 「値」フィールドは、存在する場合、BNF（すなわち、さらにPCDATA要素の値を制限する）を使用してXML要素の許容コンテンツにさらなる制限を指定します。
Name: creationdate Namespace: DAV: Purpose: Records the time and date the resource was created. Value: date-time ; See Appendix 2 Description: The creationdate property should be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created (i.e., the moment it had non-null state).
名前：のCreationDate名前空間：DAV：目的：リソースが作成された日付と時刻を記録します。値：日時;全てのDAV準拠したリソース上で定義されるべきであるのCreationDateプロパティ：付録2の説明を参照してください。リソースが作成されたときに存在する場合、それは瞬間のタイムスタンプが含まれている（すなわち、それがnull以外の状態を持っていた瞬間）。
<!ELEMENT creationdate (#PCDATA) >
<！ELEMENTののCreationDate（#PCDATA）>
Name: displayname Namespace: DAV: Purpose: Provides a name for the resource that is suitable for presentation to a user. Description: The displayname property should be defined on all DAV compliant resources. If present, the property contains a description of the resource that is suitable for presentation to a user.
名前：DisplayNameに名前空間：DAV：目的：ユーザーへの表示に適しているリソースの名前を提供します。説明：のDisplayNameプロパティは、すべてのDAV対応のリソースで定義されるべきです。存在する場合、プロパティは、ユーザーへの表示に適しているリソースの記述が含まれています。
<!ELEMENT displayname (#PCDATA) >
<！ELEMENTの表示名（#PCDATA）>
Name: getcontentlanguage Namespace: DAV: Purpose: Contains the Content-Language header returned by a GET without accept headers Description: The getcontentlanguage property MUST be defined on any DAV compliant resource that returns the Content-Language header on a GET. Value: language-tag ;language-tag is defined in section 14.13 of [RFC2068]
名前：getcontentlanguage名前空間：DAV：目的：GET上のContent-Languageヘッダを返す任意のDAV準拠のリソースに定義されなければならないgetcontentlanguageプロパティ：ヘッダの説明を受け入れずにGETで返されるヘッダのContent-言語が含まれています。値：言語タグ、言語タグは[RFC2068]のセクション14.13に定義されています
<!ELEMENT getcontentlanguage (#PCDATA) >
<！ELEMENTのgetcontentlanguage（#PCDATA）>
Name: getcontentlength Namespace: DAV: Purpose: Contains the Content-Length header returned by a GET without accept headers. Description: The getcontentlength property MUST be defined on any DAV compliant resource that returns the Content-Length header in response to a GET.
名前：getcontentlength名前空間：DAV：目的：ヘッダを受け入れずにGETで返されるContent-Lengthヘッダが含まれています。説明：getcontentlengthプロパティはGETに応答して、Content-Lengthヘッダを返す任意のDAV準拠のリソース上で定義されなければなりません。
Value: content-length ; see section 14.14 of [RFC2068]
値：コンテンツ長。 [RFC2068]のセクション14.14を参照してください
<!ELEMENT getcontentlength (#PCDATA) >
<！ELEMENTのgetcontentlength（#PCDATA）>
Name: getcontenttype Namespace: DAV: Purpose: Contains the Content-Type header returned by a GET without accept headers. Description: This getcontenttype property MUST be defined on any DAV compliant resource that returns the Content-Type header in response to a GET. Value: media-type ; defined in section 3.7 of [RFC2068]
名前：GETCONTENTTYPE名前空間：DAV：目的：受け入れるヘッダーなしでGETによって返されたContent-Typeヘッダが含まれています。説明：このGETCONTENTTYPEプロパティはGETに応じて、Content-Typeヘッダを返す任意のDAV準拠のリソースに定義されなければなりません。値：メディアタイプ。 [RFC2068]のセクション3.7で定義されています
<!ELEMENT getcontenttype (#PCDATA) >
<！ELEMENTのGETCONTENTTYPE（#PCDATA）>
Name: getetag Namespace: DAV: Purpose: Contains the ETag header returned by a GET without accept headers. Description: The getetag property MUST be defined on any DAV compliant resource that returns the Etag header. Value: entity-tag ; defined in section 3.11 of [RFC2068]
名前：getetag名前空間：DAV：目的：ヘッダを受け入れずにGETで返されるETagヘッダが含まれています。説明：getetagプロパティはのEtagヘッダを返す任意のDAV準拠のリソース上で定義されなければなりません。値：エンティティタグ; [RFC2068]のセクション3.11に定義され
<!ELEMENT getetag (#PCDATA) >
<！ELEMENTのgetetag（#PCDATA）>
Name: getlastmodified Namespace: DAV: Purpose: Contains the Last-Modified header returned by a GET method without accept headers. Description: Note that the last-modified date on a resource may reflect changes in any part of the state of the resource, not necessarily just a change to the response to the GET method. For example, a change in a property may cause the last-modified date to change. The getlastmodified property MUST be defined on any DAV compliant resource that returns the Last-Modified header in response to a GET. Value: HTTP-date ; defined in section 3.3.1 of [RFC2068]
名前：getlastmodified名前空間：DAV：目的：ヘッダを受け入れることなく、GETメソッドによって返されたのLast-Modifiedヘッダーが含まれています。説明：リソース上の最終更新日時は、リソースの状態の任意の部分の変化、GETメソッドに応答しない必ずしもだけ変更を反映することができることに留意されたいです。例えば、特性の変化は、最終更新日時を変更することがあります。 getlastmodifiedプロパティは、GETに応答して最終-Modifiedヘッダを返す任意のDAV準拠のリソース上で定義されなければなりません。値：HTTP-日付。 [RFC2068]のセクション3.3.1で定義されています
<!ELEMENT getlastmodified (#PCDATA) >
<！ELEMENT getlastmodified（#PCDATA）>
Name: lockdiscovery Namespace: DAV: Purpose: Describes the active locks on a resource Description: The lockdiscovery property returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. The server is free to withhold any or all of this information if the requesting principal does not have sufficient access rights to see the requested data.
名前：lockdiscovery名前空間：DAV：目的：リソースの説明にアクティブなロックについて説明します。lockdiscoveryプロパティがロックを持っている人のリストを返し、彼が持っているロックの種類、タイムアウトの種類とタイムアウトの残り時間、および関連するロック・トークン。サーバーは、要求プリンシパルが要求されたデータを参照するための十分なアクセス権を持っていない場合、この情報の一部またはすべてを保留して自由です。
<!ELEMENT lockdiscovery (activelock)* >
<！ELEMENTのlockdiscovery（activelock）*>
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Length: xxxx Content-Type: text/xml; charset="utf-8"
PROPFIND /コンテナ/ HTTP / 1.1ホスト：www.foo.barのコンテンツ長：XXXXのContent-Type：text / xmlで、 charset = "UTF-8" を
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D='DAV:'> <D:prop><D:lockdiscovery/></D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = 'DAVを'> <D：プロペラ> <D：lockdiscovery /> </ D：プロップ> </ D ：PROPFIND>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D='DAV:'> <D:response> <D:href>http://www.foo.bar/container/</D:href> <D:propstat> <D:prop> <D:lockdiscovery> <D:activelock> <D:locktype><D:write/></D:locktype> <D:lockscope><D:exclusive/></D:lockscope> <D:depth>0</D:depth> <D:owner>Jane Smith</D:owner> <D:timeout>Infinite</D:timeout> <D:locktoken>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = 'DAV：'> <D：レスポンス> <D：HREF>をhttp://www.foo.bar/容器/ </ D：HREF> <D：propstat> <D：プロペラ> <D：lockdiscovery> <D：activelock> <D：たlocktype> <D：書き込み/> </ D：たlocktype> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：深さ> 0 </ D：深さ> <D：所有者>ジェーン・スミス</ D：所有者> <D：タイムアウト>無限</ D：タイムアウト> < D：locktoken>
<D:href> opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 </D:href> </D:locktoken> </D:activelock> </D:lockdiscovery> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
<D：HREF> opaquelocktoken：f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 </ D：HREF> </ D：locktoken> </ D：activelock> </ D：lockdiscovery> </ D：プロペラ> <D：状態> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ D：multistatus>
This resource has a single exclusive write lock on it, with an infinite timeout.
このリソースは無限のタイムアウトで、その上に単一の排他的書き込みロックを持っています。
Name: resourcetype Namespace: DAV: Purpose: Specifies the nature of the resource. Description: The resourcetype property MUST be defined on all DAV compliant resources. The default value is empty.
名前：resourcetypeの名前空間：DAV：目的：リソースの性質を指定します。説明：resourcetypeのプロパティは、すべてのDAV対応のリソースに定義されなければなりません。デフォルト値は空です。
<!ELEMENT resourcetype ANY >
<！ELEMENT resourcetypeのANY>
Name: source Namespace: DAV: Purpose: The destination of the source link identifies the resource that contains the unprocessed source of the link's source. Description: The source of the link (src) is typically the URI of the output resource on which the link is defined, and there is typically only one destination (dst) of the link, which is the URI where the unprocessed source of the resource may be accessed. When more than one link destination exists, this specification asserts no policy on ordering.
名前：元の名前空間：DAV：目的：ソースリンクの先には、リンクの元の未処理のソースを含むリソースを識別します。説明：リンク（SRC）のソースは、典型的には、リンクが定義されている出力リソースのURIであり、そして唯一の宛先リソースの場合、未処理のソースURIであるリンクの（DST）は、典型的に存在しますアクセスされてもよいです。複数のリンク先が存在する場合、この仕様は、発注に何のポリシーをアサートしません。
<!ELEMENT source (link)* >
<！ELEMENTソース（リンク）*>
<?xml version="1.0" encoding="utf-8" ?> <D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/"> <D:source> <D:link> <F:projfiles>Source</F:projfiles> <D:src>http://foo.bar/program</D:src>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のxmlns小道具：Dは= "DAV：" のxmlns：F = "http://www.foocorp.com/Project/"> <D ：ソース> <D：リンク> <F：projfiles>ソース</ F：projfiles> <D：SRC> http://foo.bar/program </ D：SRC>
<D:dst>http://foo.bar/src/main.c</D:dst> </D:link> <D:link> <F:projfiles>Library</F:projfiles> <D:src>http://foo.bar/program</D:src> <D:dst>http://foo.bar/src/main.lib</D:dst> </D:link> <D:link> <F:projfiles>Makefile</F:projfiles> <D:src>http://foo.bar/program</D:src> <D:dst>http://foo.bar/src/makefile</D:dst> </D:link> </D:source> </D:prop>
<D：DST> http://foo.bar/src/main.c </ D：DST> </ D：リンク> <D：リンク> <F：projfiles>ライブラリ</ F：projfiles> <D： SRC> http://foo.bar/program </ D：SRC> <D：DST> http://foo.bar/src/main.lib </ D：DST> </ D：リンク> <D：リンク> <F：projfiles>のMakefile </ F：projfiles> <D：SRC> http://foo.bar/program </ D：SRC> <D：DST> http://foo.bar/src/makefile </ D：DST> </ D：link>を</ D：ソース> </ D：小道具>
In this example the resource http://foo.bar/program has a source property that contains three links. Each link contains three elements, two of which, src and dst, are part of the DAV schema defined in this document, and one which is defined by the schema http://www.foocorp.com/project/ (Source, Library, and Makefile). A client which only implements the elements in the DAV spec will not understand the foocorp elements and will ignore them, thus seeing the expected source and destination links. An enhanced client may know about the foocorp elements and be able to present the user with additional information about the links. This example demonstrates the power of XML markup, allowing element values to be enhanced without breaking older clients.
この例では、リソースhttp://foo.bar/programは3つのリンクが含まれているソースプロパティを持っています。各リンクは、このドキュメントで定義されたDAVスキーマの一部である2つが、srcとdstの3つの要素が含まれ、および（ソース、ライブラリのスキーマhttp://www.foocorp.com/project/によって定義される1、そして、のMakefile）。唯一のDAV仕様で要素を実装したクライアントは、foocorp要素を理解することはありませんので、期待される送信元と送信先のリンクを見て、それらを無視します。強化されたクライアントは、foocorp要素について知っているとのリンクに関する追加情報をユーザに提示することができるかもしれません。この例では、要素の値が古いクライアントを壊すことなく高めることができるように、XMLマークアップの威力を発揮します。
Name: supportedlock Namespace: DAV: Purpose: To provide a listing of the lock capabilities supported by the resource. Description: The supportedlock property of a resource returns a listing of the combinations of scope and access types which may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls so a server is not required to provide information the client is not authorized to see.
名前：supportedlock名前空間：DAV：目的：リソースによってサポートされたロック機能のリストを提供します。説明：リソースのsupportedlockプロパティは、リソースのロック要求で指定することができる範囲とアクセスタイプの組み合わせのリストを返します。サーバはクライアントが見ることが許可されていない情報を提供するために必要とされていないので、実際の内容は、自身がアクセス制御によって制御されていることに注意してください。
<!ELEMENT supportedlock (lockentry)* >
<！ELEMENTのsupportedlock（lockentry）*>
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
PROPFIND /コンテナ/ HTTP / 1.1
Host: www.foo.bar Content-Length: xxxx Content-Type: text/xml; charset="utf-8"
ホスト：www.foo.barのContent-Length：XXXXのContent-Type：text / xmlで、 charset = "UTF-8" を
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop><D:supportedlock/></D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：プロペラ> <D：supportedlock /> </ D：プロップ> </ D ：PROPFIND>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.foo.bar/container/</D:href> <D:propstat> <D:prop> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.foo.bar/容器/ </ D：HREF> <D：propstat> <D：プロペラ> <D：supportedlock> <D：lockentry> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：種類のLockType> <D：書き込み/> </ D：たlocktype> </ D：lockentry> <D：lockentry> <D：LOCKSCOPE> <D：共有/> </ D：LOCKSCOPE> <D：たlocktype> <D：/書き込み> </ D：たlocktype> </ D：lockentry> </ D：supportedlock> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D ：レスポンス> </ D：multistatus>
14 Instructions for Processing XML in DAV
DAVでのXML処理用の14回の手順
All DAV compliant resources MUST ignore any unknown XML element and all its children encountered while processing a DAV method that uses XML as its command language.
全てのDAV準拠したリソースは、不明なXML要素とそのコマンド言語としてXMLを使用してDAVメソッドの処理中に発生したすべての子を無視しなければなりません。
This restriction also applies to the processing, by clients, of DAV property values where unknown XML elements SHOULD be ignored unless the property's schema declares otherwise.
この制限は、プロパティのスキーマがそう宣言しない限り、未知のXML要素は無視されるべきであるDAVプロパティ値を、クライアントによって、処理に適用されます。
This restriction does not apply to setting dead DAV properties on the server where the server MUST record unknown XML elements.
この制限は、サーバーが不明なXML要素を記録しなければなりませんサーバー上で死んでDAVプロパティの設定には適用されません。
Additionally, this restriction does not apply to the use of XML where XML happens to be the content type of the entity body, for example, when used as the body of a PUT.
PUTのボディとして使用される場合、さらに、この制限は、例えば、XMLは、エンティティ本体のコンテンツタイプであることを起こるXMLの使用には適用されません。
Since XML can be transported as text/xml or application/xml, a DAV server MUST accept DAV method requests with XML parameters transported as either text/xml or application/xml, and DAV client MUST accept XML responses using either text/xml or application/xml.
XMLは、DAVサーバーは、text / xmlまたはapplication / xmlのどちらかとして輸送XMLパラメータでDAVメソッドの要求を受け入れなければならない、text / xmlまたはapplication / xmlとして輸送することができ、DAVクライアントは、テキスト/ xmlまたはアプリケーションのいずれかを使用してXML応答を受け入れなければならないので、 / XML。
15 DAV Compliance Classes
15のDAV準拠クラス
A DAV compliant resource can choose from two classes of compliance. A client can discover the compliance classes of a resource by executing OPTIONS on the resource, and examining the "DAV" header which is returned.
DAV準拠のリソースは、コンプライアンスの二種類から選択することができます。クライアントはリソースのオプションを実行し、返された「DAV」ヘッダを調べることによって、リソースのコンプライアンスクラスを発見することができます。
Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV compliant resources, clients, and proxies MUST be compliant with [RFC2068].
この文書はHTTP / 1.1プロトコルの拡張機能を説明しているので、最小限のすべてのDAV対応のリソース、クライアント、およびプロキシは、[RFC2068]に準拠しなければなりません。
Compliance classes are not necessarily sequential. A resource that is class 2 compliant must also be class 1 compliant; but if additional compliance classes are defined later, a resource that is class 1, 2, and 4 compliant might not be class 3 compliant. Also note that identifiers other than numbers may be used as compliance class identifiers.
コンプライアンスクラスは必ずしもシーケンシャルではありません。クラス2に準拠しているリソースは、クラス1に準拠しなければなりません。しかし場合は、追加のコンプライアンスクラスは、後でクラス1、2であるリソースを定義している、と4に準拠し、クラス3に準拠していない可能性があります。また、数字以外の識別子は、コンプライアンスのクラス識別子として使用することができることに注意してください。
A class 1 compliant resource MUST meet all "MUST" requirements in all sections of this document.
クラス1準拠のリソースは、このドキュメントのすべてのセクションにあるすべての「MUST」の要件を満たす必要があります。
Class 1 compliant resources MUST return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.
クラス1に準拠したリソースは、OPTIONSメソッドへのすべての応答のDAVヘッダーに「1」、最低でも、値を返さなければなりません。
A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the supportedlock property, the lockdiscovery property, the Time-Out response header and the Lock-Token request header. A class "2" compliant resource SHOULD also support the Time-Out request header and the owner XML element.
クラス2準拠のリソースは、すべてのクラス1つの要件を満たし、LOCKメソッド、プロパティsupportedlock、lockdiscoveryプロパティ、タイムアウトレスポンスヘッダとロック・トークンリクエストヘッダをサポートしなければなりません。クラス「2」準拠のリソースもタイムアウトリクエストヘッダと所有者のXML要素をサポートする必要があります。
Class 2 compliant resources MUST return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.
クラス2つの準拠のリソースは、値「1」と「2」OPTIONSメソッドへのすべての応答にDAVヘッダに、最低でも、返さなければなりません。
16 Internationalization Considerations
16の国際化に関する注意事項
In the realm of internationalization, this specification complies with the IETF Character Set Policy [RFC2277]. In this specification, human-readable fields can be found either in the value of a property, or in an error message returned in a response entity body. In both cases, the human-readable content is encoded using XML, which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header, as defined in [RFC2376], as well as the XML "encoding" attribute, which together provide charset identification information for MIME and XML processors.
国際化の分野では、この仕様は、IETF文字セットポリシー[RFC2277]に準拠しています。本明細書では、人間が読み取り可能なフィールドは、プロパティの値に、または応答実体本体に返されたエラーメッセージのいずれかで見ることができます。両方の場合において、人間が読み取り可能なコンテンツは、文字セットのタグ付けおよび符号化のための明示的な規定を持つXMLを使用して符号化され、XMLプロセッサが最小で、エンコードされたXML要素を読み取ることを要求する、UTF-8を使用して[UTF-8]の符号化されISO 10646多言語プレーン。本明細書におけるXMLの例は、[RFC2376]で定義されるように、Content-Typeヘッダのcharsetパラメータの使用を実証、ならびに一緒にMIMEおよびXMLプロセッサの文字セット識別情報を提供するXML「コードする」属性。
XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. XML uses either IANA registered language tags (see [RFC1766]) or ISO 639 language tags [ISO-639] in the "xml:lang" attribute of an XML element to identify the language of its content and attributes.
XMLは、特定のXML要素のコンテンツの言語を指定するための言語タグ付け機能を提供します。 XMLは、どちらかの使用IANAは、「XML：LANG」に[ISO-639]言語タグ（[RFC1766]を参照）またはISO 639言語タグを登録し、その内容と属性の言語を識別するためのXML要素の属性。
WebDAV applications MUST support the character set tagging, character set encoding, and the language tagging functionality of the XML specification. Implementors of WebDAV applications are strongly encouraged to read "XML Media Types" [RFC2376] for instruction on which MIME media type to use for XML transport, and on use of the charset parameter of the Content-Type header.
WebDAVのアプリケーションでは、文字セットのタグ付け、文字セットエンコーディング、およびXML仕様の言語タグ付け機能をサポートしなければなりません。 WebDAVのアプリケーションの実装者が強くMIMEメディアタイプがXMLの輸送に使用する上、およびContent-Typeヘッダのcharsetパラメータの使用上の指示のための「XMLのメディアタイプ」[RFC2376]を読むことをお勧めします。
Names used within this specification fall into three categories: names of protocol elements such as methods and headers, names of XML elements, and names of properties. Naming of protocol elements follows the precedent of HTTP, using English names encoded in USASCII for methods and headers. Since these protocol elements are not visible to users, and are in fact simply long token identifiers, they do not need to support encoding in multiple character sets. Similarly, though the names of XML elements used in this specification are English names encoded in UTF-8, these names are not visible to the user, and hence do not need to support multiple character set encodings.
本明細書内で使用される名前は、3つのカテゴリに分類され：そのような方法およびヘッダー、XML要素の名前、およびプロパティの名前のようなプロトコル要素の名前。プロトコル要素の命名方法およびヘッダのUSASCIIでエンコード英語名を使用して、HTTPの先例に従います。これらのプロトコル要素は、ユーザーには表示されません、と単純に長いトークン識別子実際にあるので、複数の文字セットでエンコードをサポートする必要はありません。本明細書中で使用されるXML要素の名前がUTF-8でエンコードされた英語名ですけれども同様に、これらの名前は、ユーザーには見えない、したがって、複数の文字セットエンコーディングをサポートする必要はありません。
The name of a property defined on a resource is a URI. Although some applications (e.g., a generic property viewer) will display property URIs directly to their users, it is expected that the typical application will use a fixed set of properties, and will provide a mapping from the property name URI to a human-readable field when displaying the property name to a user. It is only in the case where the set of properties is not known ahead of time that an application need display a property name URI to a user. We recommend that applications provide human-readable property names wherever feasible.
リソースで定義されたプロパティの名前はURIです。いくつかのアプリケーション（例えば、一般的なプロパティの視聴者が）自分のユーザーに直接プロパティのURIを表示しますが、典型的なアプリケーションは、プロパティの固定セットを使用し、人間が読めるにプロパティ名URIからのマッピングを提供することが期待されますフィールドには、ユーザーにプロパティ名を表示するとき。これは、アプリケーションがユーザーにプロパティ名URIを表示する必要があることだけプロパティのセットが事前に知られていない場合です。私たちはどこに実現可能なアプリケーションは、人間が読み取り可能なプロパティ名を提供することをお勧めします。
For error reporting, we follow the convention of HTTP/1.1 status codes, including with each status code a short, English description of the code (e.g., 423 (Locked)). While the possibility exists that a poorly crafted user agent would display this message to a user, internationalized applications will ignore this message, and display an appropriate message in the user's language and character set.
エラー報告のために、我々は、各ステータスコードコードの短い、英語の記述（例えば、423（ロック））を含むHTTP / 1.1ステータスコードの慣例に従います。可能性が不十分に細工されたユーザエージェントがユーザーにこのメッセージを表示することを存在するが、国際化されたアプリケーションは、このメッセージを無視し、ユーザーの言語と文字セットで適切なメッセージを表示します。
Since interoperation of clients and servers does not require locale information, this specification does not specify any mechanism for transmission of this information.
クライアントとサーバの相互運用がロケール情報を必要としないので、この仕様は、この情報を伝送するための任意のメカニズムを指定していません。
17 Security Considerations
17のセキュリティの考慮事項
This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware.
このセクションでは、WebDAVのアプリケーションが認識する必要があるのセキュリティへの影響に関する詳細な問題のために提供されます。
All of the security considerations of HTTP/1.1 (discussed in [RFC2068]) and XML (discussed in [RFC2376]) also apply to WebDAV. In addition, the security risks inherent in remote authoring require stronger authentication technology, introduce several new privacy concerns, and may increase the hazards from poor server design. These issues are detailed below.
HTTP / 1.1（[RFC2068]で説明）とXML（[RFC2376]で議論）のセキュリティ上の考慮事項のすべてものWebDAVに適用されます。また、リモートオーサリングに固有のセキュリティリスクは、より強力な認証技術を必要とするいくつかの新しいプライバシーの問題を紹介し、貧弱なサーバ設計から危険を増大させることができます。これらの問題は以下に詳述されています。
Due to their emphasis on authoring, WebDAV servers need to use authentication technology to protect not just access to a network resource, but the integrity of the resource as well. Furthermore, the introduction of locking functionality requires support for authentication.
オーサリング上での重点に、WebDAVサーバだけではなく、ネットワークリソースへのアクセスが、同様に、リソースの整合性を保護するために認証技術を使用する必要があります。さらに、機能をロックするの導入は、認証のためのサポートが必要です。
A password sent in the clear over an insecure channel is an inadequate means for protecting the accessibility and integrity of a resource as the password may be intercepted. Since Basic authentication for HTTP/1.1 performs essentially clear text transmission of a password, Basic authentication MUST NOT be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server MUST NOT send Basic authentication credentials in a WWW-Authenticate header unless the connection is secure. Examples of secure connections include a Transport Layer Security (TLS) connection employing a strong cipher suite with mutual authentication of client and server, or a connection over a network which is physically secure, for example, an isolated network in a building with restricted access.
安全でないチャネルを介して平文で送信されたパスワードは、パスワードを傍受することができるよう、リソースのアクセシビリティと完全性を保護するための不十分な手段です。接続が安全でない限り、パスワードのHTTP / 1.1行い、基本的にクリアテキストの伝送のための基本認証ので、基本認証では、サーバーへのWebDAVクライアントを認証するために使用してはいけません。接続が安全でない限り、また、WebDAVサーバーは、WWW-Authenticateヘッダ中に基本認証資格情報を送ってはいけません。セキュアな接続の例としては、アクセスが制限された建物の中に例えば、クライアントとサーバ、または物理的に安全であるネットワークを介した接続の相互認証と強力な暗号スイートを採用したトランスポート層セキュリティ（TLS）接続、分離されたネットワークが含まれます。
WebDAV applications MUST support the Digest authentication scheme [RFC2069]. Since Digest authentication verifies that both parties to a communication know a shared secret, a password, without having to send that secret in the clear, Digest authentication avoids the security problems inherent in Basic authentication while providing a level of authentication which is useful in a wide range of scenarios.
WebDAVのアプリケーションでは、ダイジェスト認証スキーム[RFC2069]をサポートしなければなりません。ダイジェスト認証は、通信の両当事者が明確にその秘密を送信することなく、共有秘密、パスワードを知っていることを確認しているので広いに有用である認証レベルを提供しながら、ダイジェスト認証は、基本認証に固有のセキュリティ上の問題を回避しますシナリオの範囲。
Denial of service attacks are of special concern to WebDAV servers. WebDAV plus HTTP enables denial of service attacks on every part of a system's resources.
サービス妨害攻撃は、WebDAVサーバへの特別な関心事です。 WebDAVのプラスHTTPは、システムのリソースのすべての部分にサービス拒否攻撃を可能にします。
The underlying storage can be attacked by PUTting extremely large files.
基礎となるストレージは非常に大きなファイルを置くことで攻撃することができます。
Asking for recursive operations on large collections can attack processing time.
大規模なコレクションに再帰的な操作のために頼む処理時間を攻撃することができます。
Making multiple pipelined requests on multiple connections can attack network connections.
ネットワーク接続を攻撃することができ、複数の接続に複数のパイプライン化要求を行います。
WebDAV servers need to be aware of the possibility of a denial of service attack at all levels.
WebDAVサーバは、すべてのレベルでサービス拒否攻撃の可能性を認識する必要があります。
WebDAV provides, through the PROPFIND method, a mechanism for listing the member resources of a collection. This greatly diminishes the effectiveness of security or privacy techniques that rely only on the difficulty of discovering the names of network resources. Users of WebDAV servers are encouraged to use access control techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.
WebDAVは、PROPFINDメソッドを使用して、コレクションのメンバーリソースをリストするためのメカニズムを提供します。これは、大幅にのみ、ネットワークリソースの名前を発見することの難しさに依存して、セキュリティやプライバシーの手法の有効性を減少させます。 WebDAVサーバのユーザは、むしろ彼らのリソース名の相対的なあいまいさに依存するよりも、リソースへの不要なアクセスを防止するために、アクセス制御技術を使用することをお勧めします。
When submitting a lock request a user agent may also submit an owner XML field giving contact information for the person taking out the lock (for those cases where a person, rather than a robot, is taking out the lock). This contact information is stored in a lockdiscovery property on the resource, and can be used by other collaborators to begin negotiation over access to the resource. However, in many cases this contact information can be very private, and should not be widely disseminated. Servers SHOULD limit read access to the lockdiscovery property as appropriate. Furthermore, user agents
ロック要求を提出する際に、ユーザーエージェントは、（一人ではなく、ロボットな場合のために、ロックを取り出している）ロックを取り出す人の連絡先情報を与えて、所有者のXMLフィールドを提出することができます。この連絡先情報は、リソース上のlockdiscoveryプロパティに格納され、リソースへのアクセスを介して交渉を開始するために他の共同作業で使用することができます。しかし、多くの場合、この連絡先情報は非常にプライベートなことができ、かつ広く普及すべきではありません。サーバーは、必要に応じてlockdiscoveryプロパティへの読み取りアクセスを制限する必要があります。さらに、ユーザーエージェント
SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.
連絡先情報は一切送信され、および連絡先情報が送信された場合、正確にどのような情報をコントロールが送信されるかどうかを制御を提供する必要があります。
Since property values are typically used to hold information such as the author of a document, there is the possibility that privacy concerns could arise stemming from widespread access to a resource's property data. To reduce the risk of inadvertent release of private information via properties, servers are encouraged to develop access control mechanisms that separate read access to the resource body and read access to the resource's properties. This allows a user to control the dissemination of their property data without overly restricting access to the resource's contents.
プロパティの値は、通常、文書の作成者などの情報を保持するために使用されているので、プライバシーの問題は、リソースのプロパティデータへの広範なアクセスに起因生じうる可能性があります。プロパティを介した個人情報の不注意な解放のリスクを軽減するために、サーバは、リソース本体への読み取りアクセスを分離アクセス制御メカニズムを開発し、リソースのプロパティへのアクセスを読むことをお勧めします。これは、ユーザーが過度にリソースのコンテンツへのアクセスを制限することなく、自分の財産データの普及を制御することができます。
HTTP/1.1 warns against providing read access to script code because it may contain sensitive information. Yet WebDAV, via its source link facility, can potentially provide a URI for script resources so they may be authored. For HTTP/1.1, a server could reasonably prevent access to source resources due to the predominance of read-only access. WebDAV, with its emphasis on authoring, encourages read and write access to source resources, and provides the source link facility to identify the source. This reduces the security benefits of eliminating access to source resources. Users and administrators of WebDAV servers should be very cautious when allowing remote authoring of scripts, limiting read and write access to the source resources to authorized principals.
HTTP / 1.1は、それが機密情報を含む可能性があるため、スクリプトコードへの読み取りアクセスを提供に対して警告しています。しかし、WebDAVは、そのソースリンク機能を経由して、潜在的にスクリプトリソースのURIを提供することができますので、執筆することができます。 HTTP / 1.1の場合、サーバーは合理的に起因する読み取り専用アクセスの優位にソースリソースへのアクセスを防ぐことができます。 WebDAVは、オーサリングを重視して、ソース・リソースへのアクセスを読み書き奨励し、ソースを識別するためのソースリンク機能を提供します。これは、ソースリソースへのアクセスを排除するセキュリティ上の利点を低減します。スクリプトのリモート作成を許可する際にWebDAVサーバのユーザと管理者が読んで、認可プリンシパルにソースリソースへの書き込みアクセスを制限し、非常に慎重でなければなりません。
XML supports a facility known as "external entities", defined in section 4.2.2 of [REC-XML], which instruct an XML processor to retrieve and perform an inline include of XML located at a particular URI. An external XML entity can be used to append or modify the document type declaration (DTD) associated with an XML document. An external XML entity can also be used to include XML within the content of an XML document. For non-validating XML, such as the XML used in this specification, including an external XML entity is not required by [REC-XML]. However, [REC-XML] does state that an XML processor may, at its discretion, include the external XML entity.
XMLインラインを取得し、実行するためにXMLプロセッサに命令[REC-XML]のセクション4.2.2で定義された「外部エンティティ」として知られる機能をサポートする特定のURIに位置するXMLで含みます。外部のXMLエンティティは、XML文書に関連付けられた文書型定義（DTD）を追加または変更するために使用することができます。外部のXMLエンティティは、XML文書のコンテンツ内のXMLを含めるために使用することができます。非検証するための外部のXMLエンティティを含むそのような本明細書中で使用されるXMLのようなXMLは、[REC-XML]によって必要とされません。しかし、[REC-XML]は、その裁量で、外部のXMLエンティティを含むことができるXMLプロセッサ状態い。
External XML entities have no inherent trustworthiness and are subject to all the attacks that are endemic to any HTTP GET request. Furthermore, it is possible for an external XML entity to modify the DTD, and hence affect the final form of an XML document, in the worst case significantly modifying its semantics, or exposing the XML processor to the security risks discussed in [RFC2376]. Therefore, implementers must be aware that external XML entities should be treated as untrustworthy.
外部のXMLエンティティには、固有の信頼性を持っていないし、任意のHTTP GETリクエストに流行しているすべての攻撃の対象となっています。外部のXMLエンティティはDTDを修正し、したがって、XML文書の最終形態に影響するまた、最悪の場合には著しく、そのセマンティクスを変更するか、[RFC2376]で説明したセキュリティリスクにXMLプロセッサを露出させることが可能です。そのため、実装者は外部のXMLエンティティは信用できないとして扱われるべきであることを認識する必要があります。
There is also the scalability risk that would accompany a widely deployed application which made use of external XML entities. In this situation, it is possible that there would be significant numbers of requests for one external XML entity, potentially overloading any server which fields requests for the resource containing the external XML entity.
外部のXMLエンティティを利用した、広く配備されたアプリケーションを伴うだろうスケーラビリティのリスクもあります。このような状況では、潜在的に外部のXMLエンティティを含むリソースの要求をフィールドの任意のサーバーが過負荷に、一つの外部のXMLエンティティに対する要求のかなりの数があるだろうということも可能です。
This specification, in section 6.4, requires the use of Universal Unique Identifiers (UUIDs) for lock tokens, in order to guarantee their uniqueness across space and time. UUIDs, as defined in [ISO-11578], contain a "node" field which "consists of the IEEE address, usually the host address. For systems with multiple IEEE 802 nodes, any available node address can be used." Since a WebDAV server will issue many locks over its lifetime, the implication is that it will also be publicly exposing its IEEE 802 address.
この仕様は、6.4節では、空間と時間を越えて彼らの一意性を保証するために、ロック・トークンのユニバーサル一意識別子（UUIDを）を使用する必要があります。 [ISO-11578]で定義されたUUIDは、「ノード」フィールド含有「IEEEアドレス、通常ホストアドレスで構成されている。複数のIEEE 802ノードを持つシステムでは、任意の利用可能なノードのアドレスを使用することができます」。 WebDAVサーバーがその寿命にわたって多くのロックを発行しますので、含意はそれはまた、公にそのIEEE 802アドレスを暴露されるということです。
There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address:
IEEE 802アドレスの曝露に関連するいくつかのリスクがあります。 IEEE 802アドレスを使用します：
* It is possible to track the movement of hardware from subnet to subnet.
*サブネットからサブネットにハードウェアの動きを追跡することが可能です。
* It may be possible to identify the manufacturer of the hardware running a WebDAV server.
* WebDAVサーバを実行するハードウェアの製造者を特定することが可能です。
* It may be possible to determine the number of each type of computer running WebDAV.
*実行しているコンピュータのWebDAVの各タイプの数を決定することが可能であってもよいです。
Section 6.4.1 of this specification details an alternate mechanism for generating the "node" field of a UUID without using an IEEE 802 address, which alleviates the risks associated with exposure of IEEE 802 addresses by using an alternate source of uniqueness.
本明細書のセクション6.4.1は、一意の代替ソースを使用して、IEEE 802のアドレスの暴露に関連するリスクを軽減するIEEE 802アドレスを使用せずにUUIDの「ノード」フィールドを生成するための代替メカニズムを詳述します。
18 IANA Considerations
18のIANAの考慮事項
This document defines two namespaces, the namespace of property names, and the namespace of WebDAV-specific XML elements used within property values.
この文書では、2つの名前空間、プロパティ名の名前空間、およびプロパティ値内で使用されるのWebDAV固有のXML要素の名前空間を定義します。
URIs are used for both names, for several reasons. Assignment of a URI does not require a request to a central naming authority, and hence allow WebDAV property names and XML elements to be quickly defined by any WebDAV user or application. URIs also provide a unique address space, ensuring that the distributed users of WebDAV will not have collisions among the property names and XML elements they create.
URIはいくつかの理由のために、両方の名前に使用されています。 URIの割り当ては、中央の命名機関への依頼が必要で、そのためのWebDAVプロパティ名とXML要素を迅速に任意のWebDAVのユーザーまたはアプリケーションによって定義することはできません。 URIはまた、WebDAVの分散のユーザーが作成したプロパティ名とXML要素間の衝突を持っていないことを保証し、ユニークなアドレス空間を提供しています。
This specification defines a distinguished set of property names and XML elements that are understood by all WebDAV applications. The property names and XML elements in this specification are all derived from the base URI DAV: by adding a suffix to this URI, for example, DAV:creationdate for the "creationdate" property.
この仕様は、すべてのWebDAVアプリケーションによって理解されるプロパティ名とXML要素の識別セットを定義します。本明細書におけるプロパティ名とXML要素が全て基底URI DAVから誘導される：例えば、このURIに接尾辞を追加することによって、DAV：「CreationDateプロパティ」プロパティのCreationDateプロパティ。
This specification also defines a URI scheme for the encoding of lock tokens, the opaquelocktoken URI scheme described in section 6.4.
本明細書はまた、ロックトークンの符号化のためのURIスキーム、セクション6.4で説明opaquelocktoken URIスキームを定義します。
To ensure correct interoperation based on this specification, IANA must reserve the URI namespaces starting with "DAV:" and with "opaquelocktoken:" for use by this specification, its revisions, and related WebDAV specifications.
そして「opaquelocktoken：」この仕様書、その改訂版、および関連のWebDAV仕様で使用するために：この仕様書に基づいて正しい相互運用性を確保するために、IANAは、「DAV」で始まるURI名前空間を確保しなければなりません。
19 Intellectual Property
19知的財産
The following notice is copied from RFC 2026 [RFC2026], section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document.
以下の通知は、RFC 2026 [RFC2026]、セクション10.4からコピーされ、この文書に対して行われた知的財産権の主張に関するIETFの位置を記載しています。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、実装に関連するか、そのような権限下で、ライセンスがまたは使用できない場合がありますしている。この文書または範囲に記載されている他の技術を使用することを主張している可能性のある知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません;また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
20 Acknowledgements
20の謝辞
A specification such as this thrives on piercing critical review and withers from apathetic neglect. The authors gratefully acknowledge the contributions of the following people, whose insights were so valuable at every stage of our work.
このような仕様は無関心怠慢から批判的なレビューと枯れを突き刺すで繁栄します。作者は感謝して洞察我々の仕事のすべての段階でとても貴重だった以下の人々の貢献を認めます。
Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood.
テリー・アレン、ハラルドAlvestrand、ジムAmsden、ベッキー・アンダーソン、アランBabich、サンフォードバール、ディランBarrell、バーナードチェスター、ティム・バーナーズ=リー、ダン・コノリー、ジム・カニンガム、ロンダニエル・ジュニア、ジム・デイビス、キース・ドーソン、マーク・デイ、ブライアン・デーン、マーティンDuerst、デビッド・デュラン、リー・ファレル、チャック・フェイ、ウェズリーFelter、ロイ・フィールディング、マーク・フィッシャー、アラン・フライアー、ジョージ・フィレンツェ、ジム・ゲティーズ、フィルハラム - ベイカー、デニス・ハミルトン、スティーブ・ヘニング、ミードHimelstein、アレックスHopmann、アンドレ・ファン・デル・ホーク、ベン・ローリー、ポールリーチ、オーラ・ラシラ、カレン・マッカーサー、スティーブ・マーティン、ラリーMasinter、マイケル・メオーリング、キースムーア、トーマスNartes、ヘンリック・ニールセン、健二太田、ボブ・パーカー、グレン・ピーターソン、ジョン・ラドフ、Saveenレディ、ヘンリー・サンダース、クリストファーSeiwald、ジュディスは、マイク・スプレイッツァー、はEinar Stefferud、グレッグ・スタイン、ラルフ・スウィック、高橋健司、リチャード・N.・テイラー、ロバート・トー、ジョン・ターナー、SankarのVirdhagriswaran、ファビオ・ビタリ、グレゴリー・ウッドハウス、およびローレン・ウッドを襲いました。
Two from this list deserve special mention. The contributions by Larry Masinter have been invaluable, both in helping the formation of the working group and in patiently coaching the authors along the way. In so many ways he has set high standards we have toiled to meet. The contributions of Judith Slein in clarifying the requirements, and in patiently reviewing draft after draft, both improved this specification and expanded our minds on document management.
このリストの二つは特筆に値します。ラリーMasinterの貢献は、ワーキンググループの形成を助けることにし、辛抱強く道に沿って作者コーチングの両方で、非常に貴重でした。非常に多くの方法で彼は我々が満たすために苦労している高い基準を設定しています。要件を明確にする、と辛抱強くドラフト後のドラフトを検討中ジュディスSleinの貢献、両方がこの仕様を改善し、文書管理上の私たちの心を拡大しました。
We would also like to thank John Turner for developing the XML DTD.
また、XMLのDTDを開発するためのジョン・ターナーに感謝したいと思います。
21 References
21の参考文献
[RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC1766] Alvestrand、H.、 "言語識別のためのタグ"、RFC 1766、1995年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[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月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible Markup Language (XML)." World Wide Web Consortium Recommendation REC-xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210.
[REC-XML] T.ブレイ、J.パオリ、C. M. Sperberg-マックイーン、 "拡張マークアップ言語（XML）"。 World Wide Web Consortium（W3C）の勧告REC-XML-19980210。 http://www.w3.org/TR/1998/REC-xml-19980210。
[REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in XML". World Wide Web Consortium Recommendation REC-xml-names-19990114. http://www.w3.org/TR/1999/REC-xml-names-19990114/
[REC-XML-NAMES] T.ブレイ、D.オランダ、A.素人、 "XMLにおける名前空間"。 World Wide Web Consortium（W3C）の勧告REC-XML-名-19990114。 http://www.w3.org/TR/1999/REC-xml-names-19990114/
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P, Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997.
[RFC2069]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、リーチ、P、Luotonen、A.、シンク、E.およびL.スチュワート、 "HTTPへの拡張：ダイジェストアクセス認証"、RFC 2069年、1997年1月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2068]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
[ISO-639] ISO (International Organization for Standardization). ISO 639:1988. "Code for the representation of names of languages."
[ISO-639] ISO（国際標準化機構）。 ISO 639：1988。 「言語の名前の表現のためのコード。」
[ISO-8601] ISO (International Organization for Standardization). ISO 8601:1988. "Data elements and interchange formats - Information interchange - Representation of dates and times."
[ISO-8601] ISO（国際標準化機構）。 ISO 8601：1988。 「データ要素と交換フォーマット - 情報交換 - 日付と時刻の表現。」
[ISO-11578] ISO (International Organization for Standardization). ISO/IEC 11578:1996. "Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)"
[ISO-11578] ISO（国際標準化機構）。 ISO / IEC 11578：1996。 「情報技術 - 開放型システム間相互接続 - リモートプロシージャコール（RPC）」
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]堀、R.、 "URN構文"、RFC 2141、1997年5月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, January 1998.
[UTF-8] Yergeau、F.、 "UTF-8、UnicodeとISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC1807] Lasher, R. and D. Cohen, "A Format for Bibliographic Records", RFC 1807, June 1995.
[RFC1807]ラシャー、R.とD.コーエン、 "書誌レコードのフォーマット"、RFC 1807、1995年6月。
[WF] C. Lagoze, "The Warwick Framework: A Container Architecture for Diverse Sets of Metadata", D-Lib Magazine, July/August 1996. http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
[WF] C. Lagoze、「ワーウィックフレームワーク：メタデータの多様なセットのコンテナアーキテクチャ」、D-Libのマガジン7月/ 1996年8月http://www.dlib.org/dlib/july96/lagoze/07lagoze。 HTML
[USMARC] Network Development and MARC Standards, Office, ed. 1994. "USMARC Format for Bibliographic Data", 1994. Washington, DC: Cataloging Distribution Service, Library of Congress.
[USMARC]ネットワーク開発およびMARC標準化、オフィス、エド。 1994年、「書誌データのUSMARCフォーマット」、1994年ワシントンD.C.：カタログ配信サービス、米国議会図書館。
[REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS Label Distribution Label Syntax and Communication Protocols" Version 1.1, World Wide Web Consortium Recommendation REC-PICS-labels-961031. http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
[REC-PICS] J.ミラー、T. Krauskopf、P.レズニック、W. Treese、 "PICSラベル配布ラベルの構文と通信プロトコル" のバージョン1.1、World Wide Web Consortium（W3C）の勧告REC-PICS-ラベル-961031。 http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html。
[RFC2291] Slein, J., Vitali, F., Whitehead, E. and D. Durand, "Requirements for Distributed Authoring and Versioning Protocol for the World Wide Web", RFC 2291, February 1998.
[RFC2291] Slein、J.、ビタリ、F.、ホワイトヘッド、E.およびD.デュラン、 "ワールド・ワイド・ウェブのための分散オーサリングとバージョン管理プロトコルのための要件"、RFC 2291、1998年2月。
[RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin Core Metadata for Resource Discovery", RFC 2413, September 1998.
[RFC2413]ヴァイベル、S.、クンツェ、J.、Lagoze、C.及びM.ウルフ、 "リソース発見のためのDublin Coreメタデータ"、RFC 2413、1998年9月。
[RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, July 1998.
[RFC2376]ホワイトヘッド、E.およびM.村田、 "XMLのメディアタイプ"、RFC 2376、1998年7月。
22 Authors' Addresses
22本の著者のアドレス
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Y. Y. Golandマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399
EMail: yarong@microsoft.com
メールアドレス：yarong@microsoft.com
E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425
E. J.ホワイトヘッド、情報のジュニア部門とカリフォルニアのコンピュータサイエンス大学、アーヴァイン、CA 92697-3425
EMail: ejw@ics.uci.edu
メールアドレス：ejw@ics.uci.edu
A. Faizi Netscape 685 East Middlefield Road Mountain View, CA 94043
A.フェッチネットスケープ685東ミドルロード、マウンテンビュー、CA 94043
EMail: asad@netscape.com
メールアドレス：asad@netscape.com
S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399
S. R.カーターノベル1555 N.技術ウェイM / S ORM F111オレム、ユタ州84097から2399
EMail: srcarter@novell.com
メールアドレス：srcarter@novell.com
D. Jensen Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399
D.ジェンセンノベル1555 N.技術ウェイM / S ORM F111オレム、ユタ州84097から2399
EMail: dcjensen@novell.com
メールアドレス：dcjensen@novell.com
23 Appendices
23本の付録
This section provides a document type definition, following the rules in [REC-XML], for the XML elements used in the protocol stream and in the values of properties. It collects the element definitions given in sections 12 and 13.
このセクションでは、プロトコルストリームおよびプロパティの値に使用されるXML要素について、[REC-XML]で規則に従って、文書型定義を提供します。これは、セクション12及び13で指定された要素の定義を収集します。
<!DOCTYPE webdav-1.0 [
<！DOCTYPEのWebDAVの-1.0 [
<!--============ XML Elements from Section 12 ==================-->
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?) >
<！ELEMENTのactivelock（LOCKSCOPE、種類のLockType、深さ、所有者？、？、タイムアウトlocktoken？）>
<!ELEMENT lockentry (lockscope, locktype) > <!ELEMENT lockinfo (lockscope, locktype, owner?) >
<！ELEMENTのlockentry（LOCKSCOPE、種類のLockType）> <！ELEMENTのLOCKINFO（LOCKSCOPE、種類のLockType、所有者？）>
<!ELEMENT locktype (write) > <!ELEMENT write EMPTY >
<！ELEMENT LockTypeに（書き込み）> <！ELEMENTはEMPTY書きます>
<!ELEMENT lockscope (exclusive | shared) > <!ELEMENT exclusive EMPTY > <!ELEMENT shared EMPTY >
<ELEMENTのLOCKSCOPE（排他|共有）！> <！ELEMENT排他EMPTY> <！ELEMENTはEMPTY共有>
<!ELEMENT depth (#PCDATA) >
<！ELEMENTの深さ（#PCDATA）>
<!ELEMENT owner ANY >
<！ELEMENT所有者ANY>
<!ELEMENT timeout (#PCDATA) >
<！ELEMENTタイムアウト（#PCDATA）>
<!ELEMENT locktoken (href+) >
<！ELEMENT locktoken（HREF +）>
<!ELEMENT href (#PCDATA) >
<！ELEMENTのHREF（#PCDATA）>
<!ELEMENT link (src+, dst+) > <!ELEMENT dst (#PCDATA) > <!ELEMENT src (#PCDATA) >
<！ELEMENTリンク（SRC +、DST +）> <！ELEMENTのDST（#PCDATA）> <！ELEMENTのSRC（#PCDATA）>
<!ELEMENT multistatus (response+, responsedescription?) >
<！ELEMENTマルチ状態（応答、応答の説明？）>
<!ELEMENT response (href, ((href*, status)|(propstat+)), responsedescription?) > <!ELEMENT status (#PCDATA) > <!ELEMENT propstat (prop, status, responsedescription?) > <!ELEMENT responsedescription (#PCDATA) >
<ELEMENT応答（HREF、（（HREF *、ステータス）|？（propstat +））、responsedescription）！> <！（？小道具、状態、responsedescription）ELEMENTのpropstat>！<！ELEMENTステータス（#PCDATA）> <ELEMENTのresponsedescription （#PCDATA）>
<!ELEMENT prop ANY >
<！ELEMENT ANYを支えます>
<!ELEMENT propertybehavior (omit | keepalive) > <!ELEMENT omit EMPTY >
<！ELEMENT propertybehavior（省略|キープアライブを）> <！ELEMENTがEMPTY省略>
<!ELEMENT keepalive (#PCDATA | href+) >
<！ELEMENTキープアライブ（#PCDATA | HREFの+）>
<!ELEMENT propertyupdate (remove | set)+ > <!ELEMENT remove (prop) > <!ELEMENT set (prop) >
<！ELEMENTのpropertyupdate（削除|セット）+> <！ELEMENT（プロパ）削除> <！ELEMENT設定（小道具）>
<!ELEMENT propfind (allprop | propname | prop) > <!ELEMENT allprop EMPTY > <!ELEMENT propname EMPTY >
<！ELEMENT PROPFIND（allprop | PROPNAME |小道具）> <ELEMENT allprop EMPTY> <！ELEMENTのPROPNAME EMPTY！>
<!ELEMENT collection EMPTY >
<！ELEMENTコレクションEMPTY>
<!--=========== Property Elements from Section 13 ===============-->
<!ELEMENT creationdate (#PCDATA) >
<!ELEMENT displayname (#PCDATA) >
<!ELEMENT getcontentlanguage (#PCDATA) >
<!ELEMENT getcontentlength (#PCDATA) >
<!ELEMENT getcontenttype (#PCDATA) >
<!ELEMENT getetag (#PCDATA) >
<!ELEMENT getlastmodified (#PCDATA) >
<!ELEMENT lockdiscovery (activelock)* >
<!ELEMENT resourcetype ANY >
<!ELEMENT source (link)* >
<!ELEMENT supportedlock (lockentry)* >
]>
The creationdate property specifies the use of the ISO 8601 date format [ISO-8601]. This section defines a profile of the ISO 8601 date format for use with this specification. This profile is quoted from an Internet-Draft by Chris Newman, and is mentioned here to properly attribute his work.
CreationDateプロパティは、ISO 8601の日付フォーマット[ISO-8601]の使用を指定します。このセクションでは、本明細書で使用するためのISO 8601日付形式のプロファイルを定義します。このプロファイルは、クリス・ニューマンによるインターネットドラフトから引用され、かつ適切に彼の仕事を属性にここに述べられています。
date-time = full-date "T" full-time
日時=フル日付「T」フルタイム
full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset
フル日付=日付fullyear「 - 」日付月「 - 」日付MDAYフルタイム=パーシャル時の時間オフセット
date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-second = 2DIGIT ; 00-59, 00-60 based on leap second rules time-secfrac = "." 1*DIGIT time-numoffset = ("+" / "-") time-hour ":" time-minute time-offset = "Z" / time-numoffset
日付fullyear = 4桁の日付ヶ月= 2DIGIT。 01-12日付MDAY = 2DIGIT。月/年の時間時間= 2DIGITに基づいて1月28日、1月29日、1月30日、1月31日; 00-23時間分= 2DIGIT。 00-59時間、秒= 2DIGIT。 00-59、うるう秒ルール時間secfrac =に基づいて00から60「」 1 * DIGITタイムnumoffset =（ "+" / " - "）時間時間 "：" 時間分の時間オフセット= "Z" /時間numoffset
partial-time = time-hour ":" time-minute ":" time-second [time-secfrac]
部分時間=時間時間「：」時間分「：」タイム次の[時間secfrac]
Numeric offsets are calculated as local time minus UTC (Coordinated Universal Time). So the equivalent time in UTC can be determined by subtracting the offset from the local time. For example, 18:50:00- 04:00 is the same time as 22:58:00Z.
数値オフセットは、現地時間のマイナスUTC（協定世界時）のように計算されています。だから、UTCでの等価時間は現地時間からのオフセットを減算することによって決定することができます。例えば、18：50：00〜4：00は、22と同じ時間である：58：00Z。
If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs from an offset of "Z" which implies that UTC is the preferred reference point for the specified time.
UTCの時間が知られているが、ローカル時間にオフセットされている場合は不明で、これは「-00：00」のオフセットで表現することができます。これは、UTCが指定された時間のために好適な基準点であることを意味する「Z」のオフセットは異なります。
XML supports two mechanisms for indicating that an XML element does not have any content. The first is to declare an XML element of the form <A></A>. The second is to declare an XML element of the form <A/>. The two XML elements are semantically identical.
XMLは、XML要素は、任意のコンテンツを持っていないことを示すために2つのメカニズムをサポートしています。最初は、フォーム<A> </A>のXML要素を宣言することです。第二は、フォーム<A/>のXML要素を宣言することです。 2つのXML要素は、意味的に同じです。
It is a violation of the XML specification to use the <A></A> form if the associated DTD declares the element to be EMPTY (e.g., <!ELEMENT A EMPTY>). If such a statement is included, then the empty element format, <A/> must be used. If the element is not declared to be EMPTY, then either form <A></A> or <A/> may be used for empty elements.
関連するDTDは、要素が空であると宣言している場合、（例えば、<！ELEMENT A EMPTY>）<A> </A>フォームを使用するXML仕様の違反です。そのような記述が含まれている場合は、空の要素の形式は、<A/>を使用する必要があります。要素が空であると宣言されていない場合、フォーム<A> </A>または<A/>のいずれかが空の要素のために使用することができます。
XML is a flexible data format that makes it easy to submit data that appears legal but in fact is not. The philosophy of "Be flexible in what you accept and strict in what you send" still applies, but it must not be applied inappropriately. XML is extremely flexible in dealing with issues of white space, element ordering, inserting new elements, etc. This flexibility does not require extension, especially not in the area of the meaning of elements.
XMLは法的表示されますが、実際にはないデータを提出することを容易にする柔軟なデータ形式です。 「あなたが受け入れるものに柔軟かつあなたが送るものに厳しく」の哲学はまだ適用されますが、それは不適切に適用してはいけません。 XMLは特にない要素の意味の領域で、拡張子を必要としないなど、この柔軟性を、ホワイトスペース、要素の順序の問題に対処する新しい要素を挿入する上で極めて柔軟です。
There is no kindness in accepting illegal combinations of XML elements. At best it will cause an unwanted result and at worst it can cause real damage.
XML要素の違法な組み合わせを受け入れるには優しさがありません。せいぜいそれは、不要な結果が発生し、最悪の場合、それは本当の損傷を引き起こす可能性があります。
The following request body for a PROPFIND method is illegal.
PROPFINDメソッドの次のリクエストボディは違法です。
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:allprop/> <D:propname/> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：allprop /> <D：PROPNAME /> </ D：PROPFIND>
The definition of the propfind element only allows for the allprop or the propname element, not both. Thus the above is an error and must be responded to with a 400 (Bad Request).
PROPFIND要素の定義は、allprop又はPROPNAME要素ではなく、両方を可能にします。従って、上記エラーであり、400（悪いRequest）で応答しなければなりません。
Imagine, however, that a server wanted to be "kind" and decided to pick the allprop element as the true element and respond to it. A client running over a bandwidth limited line who intended to execute a propname would be in for a big surprise if the server treated the command as an allprop.
サーバは「親切」になりたかった、真の要素としてallprop要素を選択し、それに対応することを決めた、しかし、想像してみてください。サーバがallpropとしてコマンドを扱う場合PROPNAMEを実行することを目的と帯域幅が制限されたライン上で実行しているクライアントは、大きな驚きのためにあるだろう。
Additionally, if a server were lenient and decided to reply to this request, the results would vary randomly from server to server, with some servers executing the allprop directive, and others executing the propname directive. This reduces interoperability rather than increasing it.
サーバは寛大だったし、この要求に応答することを決定した場合はさらに、その結果は、いくつかのサーバがallpropディレクティブを実行し、他の人がPROPNAMEディレクティブを実行すると、サーバからサーバにランダムに変化します。これは、それを増やすのではなく、相互運用性を低減します。
The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 (Bad Request) by a server that does not understand the expired-props element.
それが明示的PROPFIND要素に一緒に表示され禁止された2つの要素を含んでいるため、前の例では違法でした。しかし、XMLは拡張可能な言語なので、一つはPROPFINDで使用するために定義された新しい要素を想像することができます。以下は、前の例のように、期限切れの-小道具要素を理解していないサーバが400（悪いRequest）で拒絶されなければならない、PROPFINDのリクエストボディがあります。
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:" xmlns:E="http://www.foo.bar/standards/props/"> <E:expired-props/> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：Dは= "DAV：" のxmlns：E = "http://www.foo.bar/standards/props/"> <E：期限切れの-小道具/> </ D：PROPFIND>
To understand why a 400 (Bad Request) is returned let us look at the request body as the server unfamiliar with expired-props sees it.
400（不正なリクエスト）が期限切れの-小道具に精通していないサーバは、それを見て、私たちがリクエストボディを見てみましょう返された理由を理解します。
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:" xmlns:E="http://www.foo.bar/standards/props/"> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：Dは= "DAV：" のxmlns：E = "http://www.foo.bar/standards/props/"> </ D：PROPFIND>
As the server does not understand the expired-props element, according to the WebDAV-specific XML processing rules specified in section 14, it must ignore it. Thus the server sees an empty propfind, which by the definition of the propfind element is illegal.
サーバはセクション14で指定されたのWebDAV固有のXML処理規則に従って、期限切れの-小道具要素を理解していないとして、それはそれを無視しなければなりません。したがって、サーバは、PROPFIND要素の定義によって違法である空のPROPFINDを見ます。
Please note that had the extension been additive it would not necessarily have resulted in a 400 (Bad Request). For example, imagine the following request body for a PROPFIND:
それは必ずしも400（不正なリクエスト）が生じていないだろうという拡張子が添加されていたのでご注意ください。たとえば、PROPFINDについては、以下のリクエストボディを想像してみてください。
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:" xmlns:E="http://www.foo.bar/standards/props/">
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：Dは= "DAV：" のxmlns：E = "http://www.foo.bar/standards/props/">
<D:propname/> <E:leave-out>*boss*</E:leave-out> </D:propfind>
<D：PROPNAME /> <E：残しアウト> *ボス* </ E：残しアウト> </ D：PROPFIND>
The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with leave-out, the only result would be that the leave-out element would be ignored and a propname would be executed.
前の例では、架空の要素休暇アウトが含まれています。その目的は、名前提出パターンに一致するすべてのプロパティの戻りを防ぐためです。前の例は、休暇アウトに慣れていないサーバーに送信された場合は、結果だけは休暇アウト要素は無視されるだろうとPROPNAMEが実行されることになります。
All DAV compliant systems MUST support the XML namespace extensions as specified in [REC-XML-NAMES].
[REC-XML-NAMES]に指定されている全てのDAV準拠のシステムは、XML名前空間の拡張機能をサポートしなければなりません。
[Note to the reader: This section does not appear in [REC-XML-NAMES], but is necessary to avoid ambiguity for WebDAV XML processors.]
[：このセクションでは、[REC-XML-NAMES]には表示されませんが、のWebDAV XMLプロセッサのあいまいさを回避する必要がある読者に注意してください。]
WebDAV compliant XML processors MUST interpret a qualified name as a URI constructed by appending the LocalPart to the namespace name URI.
URIは、名前空間名URIにローカル部分を付加することによって構築としてのWebDAV準拠したXMLプロセッサは修飾名を解釈する必要があります。
Example
例
<del:glider xmlns:del="http://www.del.jensen.org/"> <del:glidername> Johnny Updraft </del:glidername> <del:glideraccidents/> </del:glider>
<デル：グライダーのxmlns = "http://www.del.jensen.org/" から>：ジョニー上昇気流</デル：glidername> <デル：glideraccidents /> <glidernameデル> </デル：グライダー>
In this example, the qualified element name "del:glider" is interpreted as the URL "http://www.del.jensen.org/glider".
この例では、修飾要素名は「デル：グライダー」URL「http://www.del.jensen.org/glider」と解釈されます。
<bar:glider xmlns:del="http://www.del.jensen.org/"> <bar:glidername> Johnny Updraft </bar:glidername> <bar:glideraccidents/> </bar:glider>
<バー：スライドのxmlns：パート= "http://www.del.jensen.org/"> <バー：名前をスリップ>ジョニーの上昇気流</バー：スリップ名> <バー：glideraccidents /> </バー：スライド>
Even though this example is syntactically different from the previous example, it is semantically identical. Each instance of the namespace name "bar" is replaced with "http://www.del.jensen.org/" and then appended to the local name for each element tag. The resulting tag names in this example are exactly the same as for the previous example.
この例は前の例と構文的に異なっているにもかかわらず、それが意味的に同一です。名前空間名「バー」の各インスタンスは、「http://www.del.jensen.org/」に置き換え、その後、各要素タグのローカル名に付加されます。この例では、得られたタグ名は、前の例とまったく同じです。
<foo:r xmlns:foo="http://www.del.jensen.org/glide"> <foo:rname> Johnny Updraft </foo:rname> <foo:raccidents/> </foo:r>
<FOO：のRのxmlns：FOO = "http://www.del.jensen.org/glide"> <FOO：RNAME>ジョニー上昇気流</ FOO：RNAME> <FOO：raccidents /> </ FOO：R>
This example is semantically identical to the two previous ones. Each instance of the namespace name "foo" is replaced with "http://www.del.jensen.org/glide" which is then appended to the local name for each element tag, the resulting tag names are identical to those in the previous examples.
この例では、2つの前のものと意味的に同じです。名前空間名「FOO」の各インスタンスは「http://www.del.jensen.org/glide」各要素タグのローカル名に付加している置換され、得られたタグ名はと同一であります前の例。
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。