ネットワーク専門調査委員会 Y. Goland Request for Comments: 2518 Microsoft カテゴリ: 標準トラック E. Whitehead UC Irvine A. Faizi Netscape S. Carter Novell D. Jensen Novell 1999年2月 分散オーサリングのためのHTTP拡張-WEBDAV- このメモのステータス この文書は、インターネット・コミュニティのためのインターネット標準トラック・プロトコルを指定して、改良のために議論と提案を要求する。標準化状態のための「インターネット公式プロトコル標準」(STD 1)とこのプロトコルの状態の現在の版を参照のこと。このメモの配布に制限はない。 著作権表記 Copyright (C) The Internet Society (1999)。All Rights Reserved. 概要 　この文書はリソース・プロパティの管理、リソース・コレクションの作成と管理、名前空間の操作とリソースのロック(衝突回避)のために、HTTP/1.1に追加するメソッド、ヘッダとcontent-typesのセットを定義する。 目次 概要................................................................1 1 序論 ....... .....................................................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 序論 この文書は、クライアントがウェブサーバ上のコンテンツオーサリング操作を実行するために必要なHTTP/1.1のプロトコルへの拡張を記載する。この拡張は、メソッド、ヘッダ、リクエストのエンティティ・ボディのフォーマット、そしてレスポンスのエンティティ・ボディのフォーマットの首尾一貫したセットを提供する。操作する対象は以下のとおり。 プロパティ(Properties): ウェブページについて、作成や削除、もしくは、Webページに関する情報（例えば著者や作成日付やその他雑多な情報）についての問い合わせを行えるようにする。 　　また、関連するページへのあらゆるメディアタイプのページへのリンクを提供する。 コレクション(Collections): 一連の文書を作成し、（ファイルシステムの中のディレクトリ・リストのような）階層的なメンバーシップ・リストを検索できるようにする。 Locking： 複数の人が同時に1つの文書を処理しないようにする。 　　これは、最初の1人が変更した文書について、他の人が最初の変更をマージすることなく変更を書き込んだときに、最初の変更がなくなってしまうという「失われたアップデート問題」を防ぐ。 名前空間操作(Namespace Operations): サーバに対してWebリソースのコピーと移動を指示できるようにする。 これらのオペレーションのための要求と正当性は、"Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web" [RFC2291] という関連文書に記述されている。 以降のセクションで、リソースのプロパティ(セクション4)、リソースのコレクション(セクション5)とロックオペレーション(セクション6)について詳細な説明を行う。 　これらのセクションでは、セクション8("HTTP Methods for Distributed Authoring")で説明されるWebDAV特有のHTTPメソッドによる操作の概要を説明する。 HTTP/1.1において、メソッドのパラメータ情報は、HTTPヘッダでコード化されるだけだった。HTTP/1.1と違って、WebDAVは拡張可能なマークアップ言語(XML)[ REC-XML ]で記述されるリクエスト・エンティティ・ボディか、あるいは、HTTPヘッダのどちらででもメソッドのパラメータ情報をエンコードする。メソッドのパラメータをエンコードする際にXMLを使用することで、さらにXMLエレメントを追加して既存のデータ構造を拡張することが容易になった。そして、XMLは国際化サポートを提供する ISO 10646 文字セットを使用して情報をエンコードできるため、経験則として、限られていない長さを持っているとき、あるいは、それが人間のユーザーに示されてもよくて、それゆえに、ISO 10646の文字セットにおいて符号化を要求してもよい時に、XMLエンティティ・ボディを用いてパラメータはコード化される。それ以外はパラメータはHTTPヘッダの範囲内でコード化される。セクション9では、WebDAVメソッドで使われる新しいHTTPヘッダを説明する。 XMLはWebDAVにおいて、メソッドのパラメータをエンコードすることに加え、レスポンスのエンコードにも使用される。この結果、XML はメソッド入出力に対してその拡張性と国際化のための長所を提供する。 この仕様において使われるXMLエレメントは、セクション12において定義される。 他のエレメントと衝突する心配なしで加えることができる新しいXMLエレメントのために、XML名前空間拡張(Appendix 4)がこの仕様において使われる。 HTTP/1.1によって提供されるステータスコードは、WebDAVメソッドによるエラーステータスの大半を記述するのに十分である一方、小ぎれいに落ちない幾つかのエラーがある。WebDAVメソッドのために開発される新しいステータスコードは、セクション10において定義される。幾つかのWebDAVメソッドで多くのリソースを操作できるため、複数ステータス応答は、複数のリソースのためのステータス情報を返すために導入された。複数ステータス応答は、セクション11において記述される。 WebDAVは、リソースの現在の状態に関する情報を保存するためにプロパティ・メカニズムを使用する。例えば、リソースがロックされる時は、ロック情報のプロパティはロックの現在の状態を記述する。セクション13では、WebDAV仕様の範囲内で使われるプロパティを定義する。 仕様の仕上げは、どのようにすればDAVに準拠する事を意味するかの仕様(セクション15)、国際化サポートの仕様(セクション16)、セキュリティの仕様(セクション17)の各セクションである。 2. 表記法の慣例 この文書がHTTP/1.1プロトコルへの一連の拡張を記述しているので、[RFC2068]のセクション2.1で記述されるものと同じく拡張BNFがプロトコル要素を記述するために、ここから以下で使われる。この、拡張BNF記法は、[RFC2068]のセクション2.2 で提供される、基本的なプロダクション・ルールを使うので、これらの規則はこの文書にも適用される。 この文書の中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY"と"OPTIONAL"は [RFC2119]で記述されるように解釈されることになっている。 3. 用語 - URI/URL それぞれ、Uniform Resource IdentifierとUniform Resource Locator。これらの用語(と差異)は、[RFC2396]中で定義される。 - コレクション 一組のURIを含む、メンバURIと呼ばれる、メンバー・リソースとこの仕様のセクション5中で要求に出会うリソース。 - メンバーURI コレクションによって含まれるURIセットのメンバーである URI。 - 内部メンバーURI コレクションのURIと直接関連しているメンバーURI(直接関連の定義はセクション5.2で与えられる)。 - プロパティ リソースに関する記述的な情報を含む名前/値ペア。 - ライブプロパティ サーバーによって、意味と文法が強制されているプロパティ。例えば、生の「getcontentlength」プロパティはその値を持ち、GETリクエストによって返されるエンティティの長さを持ち、そして、サーバーで自動的に計算される。 - デッドプロパティ サーバーによって、意味と文法が強制されていないプロパティ。サーバーは、デッドプロパティの値を記録するだけである。クライアントは、デッドプロパティの意味と文法の整合性を維持する役割を果たしている。 - NullResource DAVメソッドのPUT、MKCOL、OPTIONSとLOCK を除いた、又は、任意のHTTP/1.1 に対する 404(Not Found)に関連するリソース。NULLリソースは、その親コレクションのメンバーとして現れてはならない。 4. リソース・プロパティのためのデータ・モデル 4.1 リソース・プロパティ・モデル プロパティは、リソースの状態を記述するデータの部分である。プロパティは、データについてのデータである。 プロパティは、効率的な発見と、リソースの管理のために提供される、分散オーサリング環境において使われる。例えば、'subject'プロパティは、その主題によってすべてのリソースの索引付けされてもよく、'auther' プロパティは、著者が文書に何を書いたかを検索されてもよい。 DAVプロパティ・モデルは、名前/値ペアから成る。プロパティの名前は、プロパティの構文と意味を識別して、その構文と意味を参照するアドレスを提供する。 プロパティの2つのカテゴリー "Live"と"Dead" がある。Liveプロパティは、サーバーで与えられる構文と意味を持っている。Liveプロパティは、a) プロパティの値がリードオンリで、サーバによって維持される、そして、b) プロパティの値がクライアントで維持されるが、サーバーは提供された値を文法チェックする。与えられたliveプロパティの全てのインスタンスは、そのプロパティ名と関連する定義に応じなければならない。dead プロパティは、クライアントから与えられる構文と意味を持っている。サーバーは、単に正確にことば通りにプロパティの値を記録するだけである。 4.2 存在するメタデータプロポーザル プロパティは長く大きい文書リポジトリのメンテナンスで重要な役割を演じ、そして、多くの現在の提案はプロパティの若干の概念を含むか、より一般にウェブメタデータを論議する。これらは、PICS [REC-PICS]、PICS-NG、XML、Web Collections、とHTML内で表現が関係するいくつかの提案を含む。PICS-NGとWeb Collectionsの研究は、W3CののResource Description Framework(RDF) メタデータ活動によって包含された。RDFは、ネットワークに基づくデータ・モデルとそのモデルのXML表現から成る。 いくつかの提案は、デジタル・ライブラリパースペクティブに由来する。これらは、ダブリンコア [RFC2413] メタデータセットとワーウィックフレームワーク [WF]を含み、それらは異なるメタデータスキーマのためのコンテナ・アーキテクチャである。文学は、多くのメタデータの例を含み、MARC [USMARC] を含み、それは文献目録のメタデータ形式であり、Dienstシステム[RFC1807]によって使用されるテクニカル・レポート文献目録のフォーマットである。さらに、最初のIEEE メタデータ会議からの会報は、多くのコミュニティに特有のメタデータセットを記述する。 UKのワーウィック[WF]の中の1996のMetadata II Workshopの参加者は「新しいメタデータセットは、ネットワークされた基盤を開発する」と、「異なるコミュニティは、提案して、設計して、異なる種類のメタデータに対して責任がある」と注意した。これらの観察はメタデータの多くのコミュニティ固有なセットがすでに存在し、そして、多くのコミュニティがますます彼らのデータをデジタル形式で利用できるようにするので、metadataの新しい形式の開発をする重要な動機がある点に注意することによって確証されることができる。そして、データ・ロケーションを援助するメタデータフォーマットを要求して、カタログ作りをする。 4.3 プロパティとHTTPヘッダ HTTPメッセージ・ヘッダ中で、限られた意味を持つプロパティはすでに存在する。しかし、分散オーサリング環境ではリソースの状態を記述するために多くのプロパティを使用する必要があり、それらの設定やステータス返却についてHTTPヘッダを通して行うのは効率が悪い。したがって、処理する主体と関連し、設定したり読み出したりすることが可能なプロパティのセットを定義できる仕組みが必要となる。 4.4 プロパティ値 XML表記されるプロパティの値は、よく形式化されなければならない。 XMLは、柔軟で、自己記述ができ、豊富なスキーマ定義をサポートする構造化データフォーマットであり、そして、複数の文字セットのサポートを行えるために選択された。XMLの自己記述の本質は、新しい要素を加えることによって広げられる任意のプロパティの値を認める。それが拡張に遭遇するとき、それがまだ本来のスキーマにおいて指定されるデータを持っていて、それが理解しない要素を無視するので、より古いクライアントはクラッシュしない。複数の文字セットのXMLのサポートは、コード化される任意の人間が可読なプロパティやユーザーになじみがある文字セットで読み込むことを許可する。「xml:lang」属性を使った複数の人間の言語のXMLのサポートは、同じ文字セットが複数の人間の言語によって使用されるケースを取り扱う。 4.5 プロパティ名 プロパティ名は、構文に関する情報とプロパティの意味を提供するスキーマと関連する普遍的にユニークな識別子である。 プロパティ名が普遍的にユニークであるので、同じ又は他のサーバーで、そのプロパティが問題のリソースの"Live"である限り、クライアントは複数のリソースに渡って特定のプロパティのために一貫した動作に依存することができる、そして、Liveプロパティのインプリメンテーションはその定義に忠実である。 プロパティの命名には(URI [RFC2396]に基づく)XML名前空間メカニズムが使われるが、それは名前空間衝突を防ぎ、管理上の制御の程度を変えることができるためである。 プロパティ名前空間は、フラットである。すなわち、プロパティの階層構造は、明確に認められない。そのため、もしもプロパティAとプロパティA/Bがリソースに存在しているならば、2つのプロパティの任意の関係の認知はない。問題を階層的なプロパティに関してアドレッシングする別々の仕様が最終的には提示すると予想される。 最後になるが、単一のリソースで二回同じプロパティを定義することは、可能ではない。このような場合、リソースのプロパティ名前空間において衝突が発生する。 4.6 メディア独立のリンク HTMLリソースはもう一方のリソースとのリンクをサポートするが、ウェブはより一般的なサポートを、任意のメディア・タイプ(メディア・タイプとは、MIMEタイプやコンテントタイプとして知られている)のリソース間のリンクのために必要とする。WebDAVは、そのようなリンクを提供する。WebDAVリンクはプロパティ値の特別なタイプであり、任意のメディア・タイプのリソース間の確立されるタイプされた接続を認めるセクション12.4において、正式に定義される。プロパティ値は、ソースとディストネーション Uniform Resource Identifiers(URI)から成る。プロパティ名前は、リンク・タイプを識別する。 5. Webリソースのコレクション このセクションでは、新しいタイプのウェブ・リソースであるコレクションについて述べ、HTTP URL名前空間配下での相互作用について論議する。コレクション・リソースの目的は、サーバーの名前空間の中でコレクション風のオブジェクト(例えばファイルシステム・ディレクトリ)をモデル化することである。 全てのDAVに準拠したリソースは、本文書で指定したHTTP URL名前空間モデルをサポートしなければならない。 5.1 HTTP URL名前空間モデル HTTP URL名前空間は、階層構造が「/」キャラクタで区切られる階層的な名前空間である。 HTTP URL名前空間は、以下の条件を満たす場合には一貫していると言われている。 　HTTP階層構造下のあらゆるURLは、そのURLを含むコレクションに含まれるメンバーとして存在する。（但し）ルートもしくは名前空間のトップレベルのコレクションについては、この規則は適用されない。 HTTP/1.1もWebDAVも、全HTTP URL名前空間が一貫していることを要求しない。しかし、あるWebDAVメソッドは、名前空間不一致を引き起こす結果を生むのを禁じられる。 [RFC2068]と[RFC2396]では暗黙だが、コレクション・リソースを含む任意のリソースで、1つ以上のURIによって識別されてもよい。例えば、1つのリソースは複数のHTTP URLを用いて識別させることが可能である。 5.2 コレクション・リソース コレクションは、少なくともその内部に含まれるメンバーURIとプロパティセットのリストから成るリソースである。しかし、GETによって返されるエンティティ・ボディのような追加の状態を持っていてもよい。 内部のメンバーURIは、コレクションのベースURIの相対であらわされなければならない。このことは、内部のメンバーURIは（いずれも）コレクションURIと非コレクションリソースのためのセグメントをあわせたものと等価であるか、追加のセグメントの末尾にスラッシュキャラクタ "/" を付加し、コレクションリソースをあらわすようにしたものと等価であることを意味する。セグメントについては、[RFC2396] のセクション3.3で説明されている。 そして、内部のメンバURIは、コレクションには1度しか所属できない。あるコレクションにおいて同じURIが複数のインスタンスを持っていることはあってはならない。コレクションに対して定義されるプロパティは、非コレクションリソースのプロパティと同様に扱われる。 WebDAVに準拠したリソースAとBについて、それぞれURI U と V で識別され、U は V の直接相対的な位置（訳注： U は、V/u みたいな感じで、1段の相対で表される）にある場合、B は Uを内部メンバURIとして含むコレクションでなければならない。 そのため、URL http://foo.com/bar/blah であらわされるリソースがWebDAV準拠のもので、URL http://foo.com/bar/ であらわされるリソースもWebDAV準拠のものならば、URL http://foo.com/bar/ であらわされるリソースはコレクションでなければならず、内部のメンバーとして URL http://foo.com/bar/blah を含まなければならない。 コレクション・リソースは、内部のメンバーとして、HTTP URL名前空間の階層構造上は含まれるが非WebDAV対応の子供URLをリストしても良い。しかし、それは必ずしも必要ではない。例えば、URL http://foo.com/bar/blahリソースがWebDAV非対応で、URL http://foo.com/bar/がコレクションであるならば、URL http://foo.com/bar/blahは、URL http://foo.com/bar/ であらわされるコレクションの内部のメンバーであってもなくてもよい。 もし、WebDAV対応のリソースがHTTP URL名前空間の階層構造上、その配下にWebDAV対応のリソース等を持っていないならば、そのリソースは必ずしもコレクションである必要はない。 あるコレクションは、後ろに従っているスラッシュなしでその名前によって参照されるとき、後ろに従っているスラッシュが、自動的に追加されるという慣例がある。これのために、リソースはコレクション後に「/」なしでURIをアクセプトしてもよい。この場合、SHOULDはURI「/」で終わることを示している応答において、コンテント-ロケーション・ヘッダを返す。例えば、クライアントがhttp://foo.bar/blah（スラッシュが後ろにない）というURIを用いてメソッドを呼び出された場合、http://foo.bar/blah/ （スラッシュが後ろに付加されている）が呼び出されたように動作しても良い。そして、でhttp://foo.bar/blah/が呼び出されたときのcontent-location ヘッダを返すべきである。一般的に、クライアントはコレクション名を指定する時には、"/"を最後に付加してやるべきである。 リソースはコレクションであってもよいが、、WebDAV準拠ではない。すなわち、コレクションが対応するリソースが要求されるWebDAVがサポートする全てのメソッドを必然的にサポートすることなくふるまうことになっている方法に関して、リソースはこの仕様において規則セットがありながら外へ応じてもよい。そのような場合、リソースは値DAV：コレクションによるDAV：resourcetypeプロパティを返してもよいが、OPTIONSレスポンスで値"1"を含んでいるDAVヘッダを返さなければならない。 5.3 コレクション・リソースの作成と取得 この文書は、新しいコレクション・リソースを作成するためにMKCOLメソッドについて説明する。以下の理由で、既存のHTTP/1.1のPUTまたはPOSTメソッドではなくMKCOLメソッドを使う。 HTTP/1.1において、PUTメソッドは、Request-URIによって指定されるロケーションに、リクエスト・ボディを保存するために定義されている。PUTを使用してのコレクション作成を行うための記述フォーマットを容易に構成することはできるが、サーバーにそのようなリクエストを送ることになるのは望ましくない。例えば、既存の若干のリソースを省略したコレクションの記述がサーバーへのPUTリクエストとして送られた場合、これはそれらのメンバーを削除しなさいという命令と解釈される可能性がある。これから、PUTが機能的にはDELETE機能を実行するよう拡張されうるが、そのようなことはPUTのセマンティクスを変更をともない、そして、メソッドベースのアクセスコントロールのしくみではDELETE を機能的に制御することが難しくなることから望ましいことではない。 POSTメソッドは十分にはっきりした制限のない「コレクション作成」を構成することができるが、これもまた望ましいことではない。というのも、コレクション作成のためのPOSTメソッドと他の用途のPOSTメソッドをアクセス制御上切り離すことは難しくなると思われるからだ。 コレクションに対する GET メソッドおよび PUT メソッドの挙動について、その正確な定義については後述する。 5.4 ソース・リソースと出力リソース 　多くのリソースについて、GETメソッドによって返されるエンティティは、正確にリソースの持つステータスと一致する。例えば、ディスクの上で保存されるGIFファイルがそれにあたる。このシンプルなケースにおいて、リソースがアクセスされるURIは、リソースがアクセスされる元（リソースの持つ状態）に等しい。これは、伝送に先立ちサーバーで処理されないHTMLソース・ファイルのためのケースでもある。 しかし、サーバは時折それが戻りのエンティティ・ボディとして送られる前に、HTMLリソースを処理することができる。例えば、HTMLファイルの範囲内で指定されるなサーバサイドインクルード（SSI）は、サーバーにそのディレクティブを別の値（例えば現在の日付）と取り替えるように指示できる。この場合、GETによって返されるもの（HTML＋日付）は、リソースの状態(HTML＋ディレクティブ)とは異なる。一般的に、未処理のディレクティブを含んでいるHTMLリソースにアクセスする手段はない。 時々、GETによって返されるエンティティは、一つ以上のソース・リソース(それは、URI名前空間においてロケーションを持ってさえいなくてもよい)で記述されるデータ生成プロセスの出力である。単一のデータ生成プロセスは、動的に巨大な出力リソースを出力することがある。例えばhttp://www.foo.bar.org/finger_gateway/user@host のような例は、fingerゲートウェイのCIGスクリプトであり、このリクエストは指定した名前空間の一部を finger リクエストにマップする。 分散オーサリングの機能がない場合、URI名前空間にソースリソースへのマッピングを持たないことは許容される。実際には、ソースリソースへのアクセスを防ぐことは、セキュリティ上望ましい。しかし、ソースリソースのリモート編集が要求されるならば、ソースリソースはURI名前空間においてロケーションを与えられるべきである。このソース・ロケーションは、生成された出力が取得できるロケーションの1つであるべきではない。というのも、一般的にはソースリソースへのリクエストと、プロセスが出力したリソースを判別するのは不可能だからである。ソース・リソースと出力リソースは、多対多の関係を持つことが多い。 WebDAV準拠のサーバーにおいて、ソースリソースのURIは、出力されたリソースのDAV：sourceタイプ(セクション13.10のsource link プロパティの記述を参照のこと）とのリンクに保存されてもよい。ソースURIを、出力されたリソースのリンクに保存することは、オーサリング・クライアントでソースを発見することを主眼にしている。ソース・リンクの値が正しいソースを示しているという保証がない点に注意しなさい。ソース・リンクは壊れることもあり、あるいは、不正確な値は入れられることもある。また、全てのサーバーが、source link プロパティの値をセットするクライアントを使えるというわけでない。例えば、CGIファイルのためにsource linkを生成するようなサーバーは、クライアントがsource linkの値を設定することを認めないだろう。 6. ロック リソースをロックする機能は、そのリソースへのアクセスを順番に並べるためのメカニズムを提供する。ロックを使って、オーサリング・クライアントは、あるリソースが編集される間、もう一人がそれを修正しない合理的保証を提供することができる。このように、クライアントは「失われたアップデート」問題を防ぐことができる。 　この仕様は、2つ以上のクライアント（関係する多くの主体）が指定するパラメータや許可されるアクセスタイプに応じた多様なロックを許可する。本文書は、書き込みという単一のアクセスタイプに対するロックを定義する。しかしながら、構文は拡張可能であり、他のアクセスタイプのためのロックの偶発的な仕様定義を許す。 6.1 排他ロック対共有ロック ロックの最も基本的な形態は、排他ロックである。これは、アクセス権が単一の主体にのみ与えられるものである。このような調停の必要性は、複数の結果をマージすることを避けたいという要求に起因する。 しかし、ロックの目標が他からのアクセス権の行使を排除することではなく、アクセス権の行使を意図しているためである場合がある共有ロックは、このようなケースにおいて提供されるメカニズムである。シェアードロックは、複数の主体がロックを受け取ることを許容する。結果として、どの主体も特定のロックを取得することができる。 　共有されたロックとともに、リソースに影響を及ぼす2つの信用セットがある。 　最初の信用セットは、アクセス許可によって作成される。例えば、信用される主体は、リソースに対する書き込み許可を持っていてもよい。リソースに書き込みにアクセス権を持っている人々のうち、共有ロックを取得した主体の組は、その中でお互いに信用しなければならない。書き込みのアクセス権限の中に、それより小さい信頼セットを作成する。 インターネット上で考えられるあらゆる主体から始まり、大部分の状況において、主体の大半は、与えられたリソースへの書き込みアクセスを持っていない。一部の主体が書き込みアクセスを持っており、何人かの主体が排他ロックを使うことでリソース上書きから解放されることを保証されている。他の主体は、他はそれが彼らの共編者が彼らの仕事（書き込み許可を持っている主体のセットである共編者の潜在的なセット）に上書きしなくて、共有ロックを使わないと思うと決めてもよい。そして、それは主体がリソースに取り組んでいてもよいことを彼らの共編者に知らせる。 HTTPへのWebDAV拡張は、彼らの活動をコーディネートするために主体に必要なコミュニケーション・パスの全てを提供する必要がない。共有されたロックを使うとき、主体は彼らの仕事(例えば、向かい合っての相互作用(注、スクリーンについてのポストイットによる注釈、電話会話、電子メール、その他))をコーディネートするためにバンド・コミュニケーション・チャネル以外のいかなる手段を使ってもよく、共有ロックの意図は、共編者に誰が他にリソースに取り組んでいてもよいかについて知らせることになっている。 ウェブ上の分散オーサリング・システムからの経験上、排他ロックがしばしばあまりに厳しすぎるために、共有ロックが仕様に含まれる排他ロックは、特定の編集プロセスを実施するために、以下のように使われる： 　排他ロックを実施し、リソースの読み出し、編集の実行、リソースの書き込み、ロックのリリースを行う。この編集プロセスは、プログラムが暴走する、あるいは、ロック所有者がリソースのロックを解放することないような場合に、ロックが必ずしも正しくリリースされるわけではないという問題を帯びている。タイムアウトと管理操作は、不適切なロックを解放することができる一方、そのしくみが必要な時に利用できないことがある。タイムアウトが長いか、システム管理者がつかまらない時なんかがそれにあたる。 6.2 要求されるサポート WebDAV準拠のサーバーは、いかなる形においてもロックのサポートを要求されない。サーバーがロックをサポートするならば、任意のアクセスタイプのために、排他的または共有ロックの任意の組合せをサポートしてもよい。 この柔軟性の理由は、ロックのポリシーは、いろいろな記憶装置リポジトリによって使用されるリソース管理とバージョニング・システムの核心に触れるためである。これらのリポジトリは、使用できるロックの方法を制御するしくみを要求する。例えば、あるリポジトリは共有の書き込みロックをサポートする一方、他のリポジトリは排他的な書き込みロックをサポートし、また他のリポジトリではロックを使用しないというようなものである。各システムがあるロックの長所を排除することとは全く異なるので、本仕様では WebDAVにおけるネゴシエーションの唯一の軸としてロックを残す 6.3 ロック・トークン ロック・トークンは一種の状態トークンである。URIとして表現される。そして、そのURIは特定のロックを認識する。ロック・トークンは、LOCK操作が成功した時に、レスポンスボディ中のlockdiscoveryプロパティの中に含まれる。そして、リソースのロックディスカバリを通じても見つけることが可能である。 ロック・トークンURIは、永久に全てのリソースに渡ってユニークでなければならない。このユニーク制約は、混乱する危険性なしにリソースとサーバーに渡って使用されるロック・トークンをゆるす。 この仕様は、ユニーク要求に応ずるopaquelocktokenと呼ばれているロック・トークンURIスキームを提供する。しかしながら、それがユニークである限り、リソースは自由に任意のURIスキームを返すことができる。 ロック・トークンを持っていることによる特別なアクセス権は提供されない。誰でも、ロックディスカバリを実行することによって外の他の誰のロック・トークンも見いだすことができる。ロックはロックトークンの値の秘密性にではなく、サーバーによって使われるどんな認証メカニズムにでも基づいて実施されなければならない。 6.4 opaquelocktokenロック・トークンURIスキーム opaquelocktoken URIスキームは、永久に全てのリソースを横断してユニークに設計されている。そのユニーク性を確保するために、クライアントはそれを返したもの以外のリソースで、Ifヘッダでopaque lock tokenを提出してもよい。 全てのリソースは、opaquelocktokenスキームを認めなければならず、最低限、ロック・トークンがリソースで顕著なロックを参照しないと認めなければならない。 永久に全てのリソースを通じてしてユニーク性を保証するために、opaquelocktokenは[ISO-11578]中で記述されるUniversal Unique Identifier(UUID)メカニズムの使用を必要とする。 しかしながら、Opaquelocktokenジェネレーターは、どのようにトークンを生成するか選択できる。全てのロックトークンについて新しいUUIDを生成するか、1つのUUIDを生成して拡張キャラクタを付加するか、いずれかの方式をもってトークンを生成することができる。後者の方法が選択された場合、拡張キャラクタを生成するプログラムは同じ拡張キャラクタが2度にわたって使用されないことを保証しなければならない。 OpaqueLockToken-URI = "opaquelocktoken：" UUID [拡張キャラクタ]；UUID生成は、[ISO-11578]中で定義されているようにUUIDの文字列表現そのものである。スペース文字[LWS]はこのエレメントの間に入ることは許可されないことに注意されたい。 Extension = path；pathは、RFC 2068 [RFC2068]のセクション3.2.1において定義される。 6.4.1 IEEE 802アドレスを使わないノードフィールドの生成 [ISO-11578]中で定義されているように、UUIDは"node"というサーバマシンが持つIEEE802アドレスのうちの1つを含むフィールドを持っている。セクション17.8において注意しているが、マシンのIEEE 802アドレスを公開するに関連するいくつかのセキュリティ上のリスクがある。このセクションは、IEEE 802アドレスを使用しないUUIDの"node"フィールドを生成するための代替メカニズムを提供する。UUIDを生成する際に、WebDAVサーバーは"node"フィールドを作成するためにこのアルゴリズムを使用してもよい。このセクション中の文書は元々Paul LeachとRich Salzのによるインターネットドラフトによる。その成果を適切に評価するためにここに付記する。 理想的な解決は、47ビットの暗号化品質乱数を取得し、それをノードIDの下位47bitとして使用し、最初のオクテッドのMSB(Most Significant Bit)を1にすることである。このビットは、ユニキャスト／マルチキャストの設定ビットであり、こうすることで、ネットワークカードがIEEE802アドレスとして絶対に持たない値を設定する。結果として、ネットワークカードのIEEE802アドレスを使った場合と使わない場合で重複しないUUIDが生成できる。 システムが暗号の品質乱数を生み出すためのプリミティブを持っていないならば、ほとんどのシステムにおい取得可能な値をて乱数の素となる大きな数字として使用する。そのような素は、システム固有であるが、よく使用されるものは以下のようなものである。 - パーセント表記のメモリ使用率 - バイト表記されたメイン・メモリのサイズ - バイト表記されたメインメモリの空き領域サイズ - バイト表記されたページングファイルもしくはスワップファイルのサイズ - バイト表記されたページングファイルもしくはスワップファイルの空き領域サイズ - バイト表記されたユーザー仮想アドレス空間の総サイズ - バイト表記された総利用できるユーザーアドレス空間 - バイト表記されたブートディスク・ドライブのサイズ - バイト表記されたブートドライブの空きディスク容量 - 現在の時刻 - システムがブートしてからの経過時間 - いろいろなシステム・ディレクトリのファイルの個々のサイズ - いろいろなシステム・ディレクトリのファイルの作成／最終参照／変更時間 - いろいろなシステム資源(ヒープ、その他)の使用率 - 現在のマウスカーソル位置 - 現在のキャレット位置 - 現在の走行プロセスやスレッドの数 - デスクトップ・ウインドウもしくはアクティブ・ウインドウのハンドルまたはID - 呼び出し元のスタック・ポインタの値 - 呼び出し元のプロセスIDやスレッドID - いろいろなプロセッサ・アーキテクチャに特有のパフォーマンス・カウンター (実行された命令、キャッシュヒットミス、TLBミス) (特別なハードウェア構成が無い状態で、システム上で暗号の品質乱数ジェネレーターのランダムシードが使われるランダム性の素の種類がまさに上記のものであることに注意されたい。) それに加えて、厳密に言うとランダムでないが、コンピュータの名前やオペレーティング・システムの名前のような項目は、他のシステムで得られるそれらの項目とは異なるようにすることを助ける。 これらのデータを使ってノードIDを生成する正確なアルゴリズムは、システムに特有である。というのも、取得可能なデータを取得するための機能はシステム特有のものである場合が多いからだ。しかしながら、乱数の素から取得した値を連結してバッファに送り込み、MD5による暗号化ハッシュ機能を連携させることができると仮定するならば、あらゆる6バイトのMD5ハッシュが生成可能である。そして、マルチキャストビット（最初の1バイトの最上位ビット）をセットすると、適切なランダムノードIDが作成される。 その他のハッシュ機能(例えばSHA-1)も使用できる。要求が、適切な乱数が得られることというだけである。感覚的には、入力と出力が均一に分散しており、入力のビットを1つ変更することで出力のビットの半分が変更されるイメージである。 6.5 Lock Capability Discovery サーバー・ロック・サポートがオプションであるので、サーバー上のリソースをロックしようとしているクライアントはロックをトライして良い結果を祈るか、サーバがサポートするロック機能にどんなものがあるかを問い合わせることができる。この機能は、lock capability discovery として知られている。lock capability discovery は、サポートされているアクセスコントロールの形式の問い合わせとは異なる。というのも、適切なロック形式のないアクセスコントロールの形式がありうるからである。クライアントはsupportedlockプロパティを取得することで、サーバがサポートしているロックタイプを知ることができる。 LOCKメソッドをサポートするDAV準拠のリソースは、supportedlockプロパティをサポートしなければならない。 6.6 アクティブなロックの発見 ある主体がアクセスをしたいリソースに対して別の主体がロックしている場合、最初にロックをした主体が誰であるかわかることは、ロックをした以外の主体にとって役立つ。このような目的のために、lockdiscoveryプロパティが提供されている。このプロパティは、全ての有効なロックをリストし、それらのタイプや取得可能な場所を記述し、ロックトークンを提供する。 　LOCKメソッドをサポートするDAV準拠のリソースは、lockdiscoveryプロパティをサポートしなければならない。 6.7 使用上重要な点 ここで定義されるロック機構が「失われたアップデート」を防ぐ際に何らかの助けにはなるが、それは「失われたアップデート」が絶対発生しないという保証はできない。以下のシナリオを考えてみよう。: 2つのクライアントAとBは、リソース『index.html』を編集しようとしている。クライアントAは、WebDAVクライアントというよりはむしろHTTPクライアントであって、ロックを実行する方法を知らない。 クライアントAは文書をロックせずに GETをして、編集を開始する。 クライアントBはLOCKをして、GETを実行して、編集を開始する。 クライアントBは編集した文書をPUTして、UNLOCKする。 クライアントAはPUTを実行する。そして、Bが変更した全てを上書きして、失う。 WebDAVプロトコルがこの状態を防ぐことができないいくつかの理由がある。最初の理由としては、ロックを理解しないHTTPクライアントと互換性をもたせなければならないため、全てのクライアントにロックを使わせることを強制できないということが挙げられる。次に、さまざまなリポジトリの実装があるためにサーバに対するロックサポートをリクエストできないというのが挙げられる。リポジトリの実装としては、ロックではなく予約とマージを使用する。最後に、プロトコルがステートレスであるため、LOCK / GET / PUT / UNLOCK の操作の順序を強制できないということが挙げられる。 　ロックをサポートするWebDAVサーバは、リソース更新をする前にリソースをロックすることで、お互いの変更を偶発的に上書きしてしまう可能性を減らすことができる。そのようなサーバは、HTTP 1.0 と HTTP 1.1 のクライアントがリソースを更新することを効果的に避けることができる。 　WebDAVクライアントは、ロックをサポートしたWebDAVサーバと通信する際に、ロック／取得／書き込み／ロック解除という操作の順序を守ることで良いクライアントとなる。 　HTTP 1.1 クライアントは、リソースを更新するあらゆるリクエストを発行する際に、If-Match ヘッダ中のentityタグを用いることによって上書きを回避する良いクライアントとなる。 情報管理者は、WebDAVリソースを更新する前にロックを要求するようなクライアントサイドの手続きを実装することで、上書き回避を試みても良い。 7 書き込みロック このセクションは、書き込みロックのタイプに固有なセマンティクスを記述する。書き込みロックは、ロック・タイプの特定の例であって、この仕様において記述される唯一のロック・タイプである。 7.1 書き込みロックで制限されるメソッド 書き込みロックは、ロックなしの主体によるロックされたリソースへのPUT、POST、PROPPATCH、LOCK、UNLOCK、MOVE、DELETEまたはMKCOLの実行を防がなければならない。それ以外のメソッド(特にGET)は、ロックとは関係なく機能する。 　しかしながら、新しいメソッドが作成された際に、書き込みロックがどのように影響するかを定義することは必要であることに注意されたい。 7.2 書き込みロックとロック・トークン 書き込みの排他ロックもしくは共有ロックのリクエストに成功した場合、リクエストをした主体に対して関連したユニークなロックトークンを生成しなければならない。その結果、5つの主体が同じリソースに対する共有ロックを持っている場合、それぞれの主体に対応した5つのトークンが存在する。 7.3 書き込みロックとプロパティ 書き込みロックのないリソース上のプロパティを変更することはないかもしれないが、Liveプロパティの値は変更される可能性がある。もしロックされていたとしても、Liveプロパティのスキーマの要求条件を考えると変更されることはありうる。 Deadプロパティおよびリスペクトロックが定義されたLiveプロパティのみが書き込みロックがかかっている間は変更されないことを保証される。 7.4 書き込みロックと無効なリソース 　名前をロックするために、存在しないリソース（ヌルリソース）に対する書き込みロックを実施することは可能である。 　書き込みロックされたヌルリソースはヌルロックリソースとして参照されるが、PUT,MKCOL,OPTIONS,PROPFIND,LOCK,UNLOCK以外の任意のHTTP/1.1もしくはDAVメソッドがヌルリソースに対して発行された場合、レスポンスとして404 (Not Found) もしくは 405(Method Not Allowed) が返却されなければならない。ロックされたヌルリソースは、親コレクションのメンバになっていなくてはならない。加えて、ロックされたヌルリソースは、ヌルリソースのために定義されたDAVプロパティを全て持っていなくてはならない。全てのget*プロパティのようなこれらのプロパティの大半は値を持たない。というのも、ロックされたヌルリソースは、GETメソッドをサポートしないからである。ロックされたヌルリソースは、lockdiscoveryとsupportedlockの値を定義されていなければならない。 PUTやMKCOLがロックされたヌルリソースに対して実行され、そしてそれが成功するまでは、リソースは lock-null な状態に置かれなければならない。しかしながら、ロックされたヌルリソースに対するPUTやMKCOLが一度成功したらば、リソースはlock-nullな状態であることを終了しなくてはならない。 　いかなる理由によっても、PUT,MKCOLもしくは類似のメソッドがロックされたヌルリソースに対して実行、成功することがなくリソースのロックが解除された場合、リソースはヌル（何もない元のとおり）の状態に戻らなければならない。 7.5 書き込みロックとコレクション 　コレクションの書き込みロックが"Depth:0"もしくは"Depth: infinity"のロックリクエストで作成される場合、ロックをしていないオーナによってコレクションのメンバURIが追加されたり削除されたりすることを回避する。結果として、何らかの主体が新しいリソースを作成するために、HTTP名前空間の一貫性を維持するために書き込みロックをされたコレクションの内部メンバとなるURIに対するPUTやPOSTを発行しようとしたり、内部メンバを消すためにそのようなコレクション配下のURIにDELETEを発行しようとしたりした場合、主体がコレクションに対する書き込みロックを持っていないならばこのリクエストは失敗しなければならない。 　しかしながら、すでに行儀よく書き込みロックがされているリソースが含まれるコレクションに対する書き込みロックを行おうとすると、ロックが衝突することから、このようなリクエストは失敗し、423(Locked)ステータスコードが返却されなければならない。 　ロックオーナがすでにロックされているコレクションに対してリソースを追加する場合、このリソースには自動的に新しいロックが追加されなければならない。これは、ロック済みのコレクション配下のリソースに対して（新たに）書き込みロックが追加される唯一の仕組みである。従って、例えばコレクション /a/b/ が書き込みロックがかけられており、リソース /c を/a/b/c として移動させた場合、/a/b/c は、書き込みロックが（自動的に）追加される。 7.6 書き込みロックとIfリクエスト・ヘッダ 　ユーザエージェントがロックリソースへの操作を要求する際に、ロックに関する情報を保持することが要求されていないならば、以下のような事象が起こりうる。 　（ユーザAによって起動される）プログラムAは、リソースの書き込みロックを取得する。プログラムBもまたユーザAによって起動され、プログラムAによって取得されたロックの情報をもたない。にもかかわらず、ロックされたリソースに対するPUTを実行する。 　この事象において、ロックがプログラム（具体的にはプログラムB）ではなく主体（ユーザA）についていて、主体（ユーザA）のクレデンシャルをもってPUTの実行が許可されているならばPUTは成功する。プログラムBはロックについて知っているにもかかわらず、リソースを上書きせず、替わりにコンフリクトを示すダイアログボックスを表示する傾向にある。このシナリオより、異なるプログラムが同じ承認を経て他のプログラムにロックを持ち出されたのを偶発的に無視するのを回避するためのしくみが必要となる。 　このような衝突を回避するためには、ロックトークンは、メソッドによって操作できる全てのロックされたリソースについて、Ifヘッダ内の承認された主体によって送信されるか、もしくはメソッドが失敗しなければならない。例えば、リソースが移動されなければならず、移動元と移動先がロックされているならば、2つのロックトークンが送信されなければならない。1つは移動元に対応したものであり、もう1つは移動先に対応したものである。 これらの衝突を防ぐために、メソッドが相互に作用してもよい全てのロックされたリソースのために、ロック・トークンはIfヘッダで許可された主体によって提出されなければならない、あるいは、メソッドは失敗しなければならない。例えば、リソースが動かされることになっている、そして、ソースと目的地がロックされるならば、2つのロック・トークンが、提出されなければならない(1つはソースで、もう一つはディストネーション)。 7.6.1 Write Lock の例 >>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: () >>Response HTTP/1.1 204 No Content この例では、たとえソースとデスティネーションがロックされてたとしても、デスティネーションのロックについて1つのロック・トークンだけが送信されなければならない。というのも、ソース・リソースはCOPYによって更新されず、その結果書き込みロックの影響を受けないからである。この例では、ユーザエージェントの認証は、トランスポートより下のレイヤにおいて、HTTP以外のしくみを用いてすでに実施されている。 7.7 書き込みロックとCOPY/MOVE 　COPYメソッドの実行は、コピー元にて有効ないかなる書き込みロックも複製してはならない。しかしながら、COPYメソッドにより、"Depth: infinity"としてロックされたコレクションに対してリソースをコピーすると、コピー先のリソースに対してロックが追加される。 　書き込みロックされたリソースに対するMOVEリクエストが成功した場合でも、移動元においてかかっていたリソースロックは移動してはならない。しかしながら、セクション7.5で説明されているような場合においては、ロックは自動的に付加される。例えば、MOVEリクエストが"Depth: infinity"指定でロックされたコレクションの下に移動されたら、リソースにはコレクションのロックが付加されるさらに加えて、"Depth: infinity"指定でロックされたコレクション配下のリソースを、同じロック範囲内にある移動先にMOVEする場合（ロックでカバーされた名前空間の範囲内でMOVEが発生した場合）、移動されたリソースは再びロックされる。セクション7.6で説明したように、これらのどちらの例においても移動元と移動先の両方についてロックトークンを含んだIfヘッダが送信される必要がある。 7.8 Write Locksのリフレッシュ 　クライアントは、2回同じ書き込みロックリクエストを送信してはならない。クライアントは、すでにロックされたリソースへのリクエストをするために、Ifヘッダ中にロックトークンを含まなければならないため、同じロックリクエストが送信される際にはそれを常に気づいてることに注意しなくてはならない。 　しかしながら、クライアントはボディなしでIfヘッダをともなったLOCKメソッドを送信してもよい。この形式で送信されるLOCKリクエストは、ロックのリフレッシュを行うためだけに使用されなければならない。この操作は少なくとも、ロックに関連したいかなるタイマもリセットされなければならないということを意味する。 　サーバは、ロックのリフレッシュにともない、最初にロックが要求された時のものと異なる場合にはTimeoutヘッダを返却しても良い。加えて、クライアントはロックをリフレッシュするリクエストを送信する際に、任意の値を含むTimeoutヘッダを付加してもよい。また、サーバは常に、クライアントから送信されたリクエスト中のTimeoutヘッダを無視しても良い。 　リフレッシュのためのLOCKリクエストのレスポンスがエラーを示すものだった場合、クライアントはロックがリフレッシュされなかったとみなすべきである。 8. 分散オーサリングのためのHTTPメソッド 　以下に述べるHTTPメソッドは、XMLをリクエストとレスポンスの フォーマットに使用する。全てのDAV準拠クライアントとリソース は、[REC-XML]に準拠したXMLパーサを使用しなければならない。リ クエストやレスポンスで使用される全てのXMLデータは、少なくと も整形式(well-formed)XML文書でなければならない。サーバが ill-formed XML 文書を受け取った場合、サーバはそのリクエストを 拒否し、レスポンスとして 400(Bad Request) を返却しなければな あらない。クライアントが ill-formed XML 文書を受け取った場合、 実行されたメソッドの出力について何も評価してはならず、そして サーバが誤動作しているとして扱うべきである。 8.1 PROPFIND PROPFIND メソッドは、プロパティを取得する。リソースが内部メン バを持っていない場合、Request-URI で指定されたリソースにて定義 されているプロパティを取得し、リソースが内部メンバURIを含むコ レクションである場合は、コレクションリソースのプロパティと、コ レクションに含まれるリソースのプロパティを取得する。 全てのDAVに準拠したリソースは、そのエレメントの用途に、定義され る全てのXMLエレメントとともに、PROPFINDメソッドとpropfind XMLエ レメント(セクション12.14)をサポートしなければならない。 クライアントは、内部のメンバーURIでコレクション・リソースで PROPFINDで「0」、「1」または「infinity」の値で、Depthヘッダを 付加できる。DAVに準拠したサーバーは、「0」、「1」と「infinity」 動作をサポートしなければならない。既定値によって、Depthヘッダが 省略されたPROPFINDリクエストは、"Depth: infinity"ヘッダが含ま れたものとして扱わなければならない。 クライアントは、どんな情報が欲しいかを記述したXMLエレメントを リクエスト・ボディとして送信できる。特定のプロパティの値をリク エストしたり、全てのプロパティの値をリクエストしたり、リソース のプロパティの名前リストをリクエストしたりできる。クライアント は、リクエストボディを送信しないようにもできる。PROPFINDのリク エスト・ボディが送信されなかったときは、名前のためのリクエストと 全てのプロパティの値が指定されたものとみなされなければならない。 全てのサーバーは、content-type:text/xmlのレスポンスもしくはい ろいろなプロパティを取得するリクエストの結果を記述するマルチス テータスXMLエレメントを含むapplication/xmlを返すことをサポート しなければならない。 　レスポンスにマルチステータスXMLエレメントを使用した場合におい て、プロパティ取得時にエラーが発生したならば、適切なエラー結果を 応答の中に含まなければならない。存在しないプロパティの値を取得 するリクエストはエラーとなり、404(Not Found)ステータス値を含む レスポンスXMLエレメントを使用して通知されなければならない。 従って、いかなるdepth指定でリクエストされたとしても、メンバURIを 伴ったコレクション・リソースのためのマルチステータスXMLエレメン トは、コレクションの各メンバURIのレスポンスXMLエレメントを含まな ければならない。各レスポンスXMLエレメントは、 prop XML エレメ ント内のプロパティが定義されているリソースのURIを指定するための href XMLエレメントを含まなければならない。内部メンバURIを伴うコ レクションに対するPROPFINDメソッドの結果は、フラットなリストで 返され、その順序には特に意味はない。 allpropとpropnameの場合、主体が特定のプロパティが存在するかど うか知る権利を持っていないならば、プロパティは黙って応答から除外 するべきである。 このメソッドの結果は、キャッシュされるべきでない。 8.1.1 例−Named Propertyを検索すること >>Request PROPFIND /file HTTP/1.1 Host: www.foo.bar Content-type: text/xml; charset="utf-8" Content-Length: xxxx >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.foo.bar/file Box type A J.J. Johnson HTTP/1.1 200 OK HTTP/1.1 403 Forbidden The user does not have access to the DingALing property. There has been an access violation error. この例では、PROPFINDは非コレクションリソースhttp://www.foo.bar/fileに対して実行される。propfind XMLエレメントは、値が要求されている4つのプロパティの名前を指定する。この場合、リクエストを出している主体が第3で第4のプロパティを見る十分なアクセス権利を持っていなかったので、2つのプロパティだけは返された。 8.1.2 例−全てのプロパティ取得にallpropを使う >>Request PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Depth: 1 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.foo.bar/container/ Box type A Hadrian 1997-12-01T17:42:21-08:00 Example collection HTTP/1.1 200 OK http://www.foo.bar/container/front.html Box type B 1997-12-01T18:27:21-08:00 Example HTML resource 4525 text/html zzyzx Monday, 12-Jan-98 09:25:56 GMT HTTP/1.1 200 OK この例では、PROPFINDは Depthヘッダを1にして、リソースhttp://www.foo.bar/container/の上で呼び出され、それはリクエストがリソースとそのメンバに適用することを意味し、propfind XMLエレメントが allprop XMLエレメントを含んでいることと、リクエストが各リソースで定義される全てのプロパティの名前と値を返さなければならないことを意味している。 リソース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. 最後の4つのプロパティはWebDAVに特有である。そして、セクション13において定義される。 このリソースではGETはサポートされていないため、get* プロパティ（例:getcontentlength）が定義されていない。DAV 特有のプロパティにより、「コンテナ」は、December 1 ,1997 の 5:42:21PM（タイムゾーンはGMT-8）に作成されたと示されており、"Example collection"という名前をもっていて(displayname)、リソースタイプはコレクションであり(resourcetype)、排他ロックとシェアードロックをサポート(supportedlock)していると記述されている。 リソース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. DAVに特有のプロパティは「front.html」が1997年12月1日、6:27：21PM GMT-8 に作成されたと示され(creationdate)、名前は「Example HTML Resource」 (displayname)、4525バイトのコンテントサイズ(getcontentlength)、コンテン トタイプが「text/html」(getcontenttype)、「zzyzx」というエンティティタグ (getetag)、 Monday, January 12, 1998, at 09:25:56 GMTに最終更新された (getlastmodified)、という情報である。その他、それがコレクション (resourcetype)でなくて、排他的な書き込みと共有された書き込みロック (supportedlock)をサポートすることを意味して、空のリソース・タイプを 持っている。 8.1.3 例−全てのプロパティ名を取得するためにpropnameを使う >>Request PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Type: text/xml; charset="utf-8" Content-Length: xxxx >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.foo.bar/container/ HTTP/1.1 200 OK http://www.foo.bar/container/front.html HTTP/1.1 200 OK この例では、PROPFINDはpropname XMLエレメントを含んでいるpropfind XMLエレメントで、コレクション・リソースhttp://www.foo.bar/container/ の上で呼び出される。そして、全てのプロパティの名前が返されるべきことを意味する。Depthヘッダが存在しないので、それは「infinity」のそのデフォルト値を仮定する。そして、コレクションとその配下のリソース全てのプロパティの名前が返されるべきことを意味する。 前の例で一貫した、リソースhttp://www.foo.bar/container/は、それの上で定義される以下の6つのプロパティを持っている。 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/index.html は「コンテナ」コレクションのメンバーで、それの上で定義される以下の9つのプロパティを持っている。 http://www.foo.bar/boxschema/bigbox, DAV:creationdate, DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock. この例も、XML名前空間スコーピングと既定値名前空間の使用法を示す。「xmlns」属性が明確な「短縮形名前」(接頭辞)文字を含まないので、名前空間はデフォルトで全ての囲まれた要素にあてはまる。それゆえに、明確にそれがふさわしい名前空間を述べない全ての要素は、「DAV:」名前空間スキーマのメンバーである。 8.2 PROPPATCH PROPPATCHメソッドは、Request-URIによって識別されるリソースで定義されるプロパティをセット／削除するためにリクエスト・ボディで指定される命令を処理する。全てのDAV準拠のリソースは、PROPPATCHメソッドをサポートしなければならず、DAVスキーマのXMLエレメントpropertyupdate,set,removeで指定される命令を処理しなければならない。もちろんメソッドでのディレクティブ実行は、アクセスコントロールの制御をうける。DAV準拠のリソースは、任意のDeatプロパティの設定をサポートすべきである。 PROPPATCH リクエストのメッセージボディは、XMLエレメントpropertyupdateを含まなければならない。命令実行は、命令を受信した順番（先頭から最後尾の順）でなければならない。命令は、全てが実行されるか、全く実行されないかのいずれかでなければならない。その結果、リクエストボディの処理中に何らかのエラーが発生したら、全ての実行済み命令については実行されなかったことになり、エラーリサルトが返却される。命令実行の小足は、セクション12.13の設定／削除命令の定義において詳細に述べる。 8.2.1 ステータスコード 207(Multi-Status) 以下のレスポンスコードの例は、1つのコードがこのメソッドのために207(Multi-Status)レスポンスにおいて使われるのを期待しようとする例である。しかし、明確に禁止されない限り、任意の2/3/4/5xxシリーズレスポンスコードが207の(マルチStatus)応答において使われてもよい点に注意しなさい。 200 (OK) コマンド成功。ボディ中で、set と remove のステータスは混在できるが、この場合でも201(Created)は不適当である。 403(Forbitten) サーバーが指定しないほうを選んだというために、クライアントはプロパティを変更できない。 409(Conflict) クライアントが、プロパティ設定に不適切な値を指定した。このステータスには、リードオンリーなプロパティを設定しようとした際にも返却される。 423 (Locked) リソースがロックされており、クライアントがロックのオーナでないか、ロックトークンを必要とするロックにもかかわらずクライアントがそれを提示しなかった場合に返却されるステータスコード。 507(Insufficient Storage) 　サーバーがプロパティを設定するのに十分な領域を持っていなかった。 8.2.2 PROPPATCH の例 >>Request PROPPATCH /bar.html HTTP/1.1 Host: www.foo.com Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Jim Whitehead Roy Fielding >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.foo.com/bar.html HTTP/1.1 424 Failed Dependency HTTP/1.1 409 Conflict Copyright Owner can not be deleted or altered. この例では、クライアントはhttp://www.w3.com/standards/z39.50/Authorsプロパティの値をセットして、プロパティhttp://www.w3.com/standards/z39.50/Copyright-Ownerを削除するためにサーバーにリクエストを出す。Copyright-Owner プロパティが削除できなかったため、何のプロパティ変更もされなかった。Authors プロパティについての 424(Failed Dependency) ステータスコードは、Copyright-Ownerプロパティの削除についてのコンフリクトがなかったならば、リクエストが成功していたことを示す。 8.3 MKCOLメソッド MKCOLメソッドが、新しいコレクションを作成するために使われる。全てのDAV準拠のリソースは、MKCOLメソッドをサポートしなければならない。 8.3.1 リクエスト MKCOLは、Request-URIによって指定されるロケーションで、新しいコレクション・リソースを作成する。Request-URIによって識別されるリソースがすでに存在するならば、MKCOLは失敗しなければならない。MKCOL処理の間、Request-URIが「/」でない限り、サーバーはRequest-URIをその親コレクションのメンバーにしなければならない。親が存在しないならば、メソッドは失敗しなければならない。MKCOLオペレーションが新しいコレクション・リソースを作成するとき、全ての親がすでに存在しなければならない、あるいは、メソッドは409の(Conflict)ステータスコードで失敗しなければならない。例えば、コレクション /a/b/c/d/ を作成するリクエストを発行するが、/a/b/ も /a/b/c/も存在しない場合、そのリクエストは失敗しなければならない。 MKCOLがリクエストボディなしで呼び出されるとき、新しく作成されたコレクションはメンバーを持っているべきでない。 MKCOL リクエストメッセージは、メッセージボディを含んでもよい。メッセージボディが与えられたMKCOLリクエストの動作は、コレクション作成、コレクションのメンバの作成、メンバのボディの作成、そしてコレクションやメンバのプロパティの設定に限定される。サーバがサポートしない（もしくは解釈できない）MKCOLリクエストのエンティティタイプを受け取った場合、サーバは415(Unsupprted Media Type)ステータスコードを返却しなければならない。さまざまなリクエストメディアタイプに対するMKCOLの実際の挙動は、本ドキュメントでは特に定義しない。別の文書で規定されるだろう。 8.3.2 状態コード MKCOLが等冪でない(non-idempotent)セマンティクスを持っているので、MKCOLリクエストからの応答はキャッシュされてはならない。 201 (Created) - コレクションまたは組み立てられたリソースは、全部作成された。 403 (Forbidden) - これは、2つの状況のうちの少なくとも1つを示す： 1)、サーバーはその名前空間において与えられたロケーションでコレクションの作成を認めない、あるいは、2)、Request-URIの親コレクションが、存在するが、メンバーをアクセプトすることができない。 405 (Method Not Allowed) - MKCOLは、削除された/存在しないリソースで実行された。 409(Conflict) - コレクションはRequest-URIで作られることができない。そして、一つ以上の中間コレクションは作成された。 415(Unsupported Media Type) - サーバーは、ボディのリクエストタイプをサポートしない。 507(Insufficient Storage) - リソースは、このメソッドの実行の後、状態を記録するために十分なスペースを持っていない。 8.3.3 MKCOLの例 この例は、www.server.org 上で /webdisc/xfiles/ と呼ばれるコレクションを作成する。 >>Request MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.server.org >>Response HTTP/1.1 201 Created 8.4 コレクションのためのGET, HEAD コレクションに対して発行される GET のセマンティクスは変更されない。というのも、GET は「Request-URIにて特定される（エンティティの形式の）情報はなんでも取得する」と定義されているからである。コレクションに対して発行されたGETに対して、サーバは"index.html"の内容を返却してもよいし、人間が見ることのできる形式でのコレクションの内容一覧を返してもよい。また、他に考えられる何かを返してもよい。結果として、コレクションに対するGETの結果は、コレクションのメンバシップとは何の関係もなく返却される。 同様に、HEADの定義はGETの定義からレスポンスメッセージボディを抜いたものなので、コレクションに対するHEADのセマンティクスも変更されない。 8.5 コレクションのための POST POSTの実際の機能の定義はサーバによって決定され、よく特定のリソースに依存し、大部分が定義されていないために、コレクションに対するPOSTの動作は有意な変更は出来ない。その結果、コレクションに対するPOSTのセマンティクスは変更されない。 8.6 DELETE 8.6.1 非コレクションリソースのためのDELETE DELETEメソッドが非コレクションリソースに発行され、かつそのリソースが1つ以上のコレクションのメンバである場合、DELETEを処理する時にサーバはRequest-URIで指定されたリソースについて、全ての所属するコレクションからURIを除去しなければならない。 8.6.2 コレクションのためのデリート コレクションに対するDELETEメソッドの発行は、Depth: infinity ヘッダが使用されているように動作しなければならない。また、クライアントはコレクションに対するDELETEメソッドの発行時には、Depth: ヘッダに infinity 以外の値を指定してはならない DELETEは、Request-URIで指定されたコレクションおよびその内部メンバURIで指定されるリソースをすべて削除するように指示する。 コレクションのメンバURIで指定されるリソースのいずれかが削除できない場合、そのメンバの親については削除してはならない。これは、名前空間の一貫性を保持するために必要なことである。 DELETEで含まれる任意のヘッダは、削除されるあらゆるリソースを処理する際に適用されなければならない。 DELETEメソッドが処理を完了した際に、一貫した名前空間が存在している必要がある。 Requested-URIで指定される以外のリソースについてエラーが発生したら、レスポンスとしては 207(Multi-Status)ステータスコードが返却される必要がある。そして、424(Failed Dependency)エラーは207(Multi-Status)で返却されるレスポンスボディ中に含まれていてはならない。クライアントは、ある親リソース（コレクション）配下のリソースが削除できなかったために、そのリソースの親コレクションを削除できなかったという通知を受けるので、親リソースは安全に残される。加えて 204(No Content)エラーは207(Multi-Status)ステータスコードのレスポンスボディ中で返却されるべきではない。これを禁じる理由は、204(No Content)ステータスコードは、DELETEメソッドのデフォルトの成功ステータスであるからだ。 8.6.2.1 DELETEの例 >>Request DELETE /container/ HTTP/1.1 Host: www.foo.bar >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.foo.bar/container/resource3 HTTP/1.1 423 Locked この例では、http://www.foo.bar/container/resource3を削除する試みは、それがロックされており、かつロック・トークンはリクエストとともに送信されなかったために失敗した。従って、http://www.foo.bar/container/ も削除する試みは、失敗した。このように、クライアントは親を削除されることができないので、その子供がまた、削除されなかった限り、http://www.foo.bar/container/を削除する試みがまた、失敗するにちがいなかったということを知っている。たとえDepthヘッダが含まれなかったとしても、メソッドがコレクションの上にあるので、Depth: Infinity とみなされる。 8.7 PUT 8.7.1 非コレクションリソースのためのPUT 　存在するリソースに対してPUTが実行されると、リソースのGETレスポンスエンティティを置き換える。当該リソースに対して定義されたプロパティはPUT処理時に再計算されるが、他の部分は影響を受けない。例えば、サーバがリクエストボディのコンテントタイプを認識しているならば、自動的に展開される有益な剥き出しの情報をプロパティとして抽出してもよい。 適切な範囲制限をされた親コレクションなしにPUTによるリソースの作成を試みた場合は、409(Conflict)ステータスコードが返却され、エラー終了しなければならない。 8.7.2 Collectionsのための PUT HTTP/1.1の仕様[RFC2068]("PUT method requests that the enclosed entity be stored under the supplied Request-URI)において定義されているように、コレクションを表しているエンティティの送信は、暗黙のうちにリソースの作成と削除をエンコードしようとするので、この仕様はPUTを使ってコレクションを作成するためのフォーマットをあえて定義しない。その代わりに、コレクションを作成するためのメソッドとしてはMKCOLが定義される。 PUTオペレーションが新しい非コレクションリソースを作成するとき、全ての親コレクションがすでに存在しなければならない。全ての親が存在するというわけではないならば、メソッドが失敗しなければならず、409 (Conflict) ステータスコードが返却される。例えば、コレクション /a/b/c/ が存在しない状態でリソース/a/b/c/d.htmlを作成するような場合は、そのリクエストは失敗しなければならない。 8.8 COPYメソッド COPYメソッドはソース・リソース（Request-URIで認識される）の複製ををデスティネーションリソース（Destinationヘッダで指定される）として作成する。Destinationヘッダは指定されなければならない。COPYメソッドの実際の挙動は、ソース・リソースのタイプに依存する。 全てのWebDAV準拠のリソースは、COPYメソッドをサポートしなければならない。しかし、COPYメソッドのサポートは、リソースをコピーする能力を保証しない。例えば、同じサーバの上で、別々のプログラムでリソースを制御できる。結果として、同じサーバの上にあるように見えるロケーションへのリソースコピーはできないこともある。 8.8.1 HTTP/1.1のリソースのためのCOPY ソース・リソースがコレクションでないとき、COPYメソッドの結果デスティネーションに新しいリソースが作成される。このとき、デスティネーションのリソースの状態や挙動はソースリソースと可能な限り同じになるようにされる。COPYが成功した後に、ソースリソースのプロパティは、ヘッダやXMLエレメントを更新するなど、以下のプロパティコピーの定義に従ってデスティネーションリソースに複製されなければならない。正しい操作のためのリソースの要求条件が満たされないなど、サーバコントロールの範囲外の理由でデスティネーションの環境がソースと異なるために、完全にデスティネーションリソースに複製を行えないことがある。次に、デスティネーションリソースの手直しが行われるが、これについてソースリソースが更新されることはない。次に、ソースリソースの手直しが行われるが、これがデスティネーションリソースの更新につながることはない。 8.8.2 プロパティのための COPY 以下のセクションは、COPY操作時にリソースのプロパティがどのように取り扱われるかを定義する。 Liveプロパティは、デスティネーションリソースにおいて（ソースと）同様に扱えるような形で複製されるべきである。プロパティがLiveコピーできない場合は、同じ名前のプロパティに値をコピー(octet-for-octet)し、デスティネーションリソースのDeadプロパティは、propertybehavior XMLエレメントの効果に従属する propertybehavior XMLエレメントは、プロパティがベストエフォートでコピーされるか、全てのLiveプロパティのコピーがされない場合はメソッドが失敗するか、指定したLiveプロパティのコピーがされない場合はメソッドが失敗するかを選ぶことができる。propertybehavior XMLエレメントは、セクション12.12で定義される。 8.8.3 コレクションのためのCOPY 　Depthヘッダのないコレクションに対するCOPYメソッドは、値"infinity"が設定されたDepthヘッダを含んでいるように動作しなければならない。クライアントは、コレクションのCOPYの時に、Depthヘッダの値を"0"もしくは"infinity"と設定できる。DAV準拠のサーバは、Depthヘッダの値が"0"の時と"infinity"の時の動作をサポートしなければならない。 　Depth が infinity のCOPYは、Request-URIで指定されるコレクションリソースは、Destinationヘッダに格納されたURIで指定されたリソースにコピーされなければならず、この時点でコピー元のコレクションの内部メンバもコピー元と同じコレクションの階層構造を保った状態でコピーされることになっている。 　"Depth: 0"のコピーは、コレクションとプロパティはコピーされるが、その内部メンバまではコピーされない。 　COPYメソッド発行時に含まれるヘッダは、Destinationヘッダを除いてコピー時に各リソースの処理時に適用されなければならない。 Destinationヘッダは、Request-URIのコピー先URIを指定するだけである。Request-URIによって指定されるコレクションのメンバに適用される時は、現在のロケーション階層を反映して更新されるということである。すなわち、Request-URIが /a/ であり、Hostヘッダの値が http://fun.com/ で、Destination が http://fun.com/b/ であるならば、http://fun.com/a/c/d が処理される時、http://fun.com/b/c/d がDestinationとして使われなければならない。 　COPYメソッドが処理を完了したら、コピー元とコピー先の両方について整合性を持った名前空間が作成されなければならない（名前空間の整合性の定義については、セクション5.1を参照のこと）。しかしながら、内部コレクションのコピー時にエラーが発生したら、そのまま処理を継続すると整合性のとれない名前空間ができる恐れがあるため、サーバは失敗したコレクションのメンバとして指定されるいかなるリソースもコピーしてはならない（サーバは、エラーが発生したサブツリーをスキップしなければならない）。このような場合、エラーを検出した後は、COPY処理は、できるだけ多くのものを終えようとするべきである（サーバは他のサブツリーやそのツリーのメンバリソースのコピーを試みるべきである。それらのリソースやサブツリーはエラーが発生しているコレクションに従属しない）。例えば、/a/b/ および /a/c/ というコレクションが含まれる /a/ というコレクションに対し、Depth: infinity な COPYメソッドが発行され、/a/b/ のコピー中にエラーが発生したら、/a/c/ のコピーを試みるべきである。同じように、Depth: infinity な MOVE 最中に非コレクションリソースのコピーでエラーが発生したら、サーバは可能な限り多くのコピー操作を行うべきである。 　COPYメソッド実行時に、Resource-URI で指定されたURI以外のところでエラーが発生したら、レスポンスとして 207 (Multi-Status) が返却される。 　424 (Failed Dependency) ステータスコードは、COPYメソッドのレスポンスとしての207 (Multi-Status) の中で返却されるべきではない。これらのレスポンスは、安全に省略される。というのも、クライアントは親リソースのエラーを受け取ったときに、その子リソースがコピーできないことを知っているからだ。加えて、201 (Created) / 204 (No Content)ステータスコードも COPYメソッドの207 (Multi-Status) レスポンスの中で返却されるべきではない。これらのステータスコードは、成功のステータスコードとして規定されているため、安全に省略される。 8.8.4 コピーとOverwrite ヘッダ 　コピー先にリソースが存在し、Overwriteヘッダの値が"T"の場合は、コピーを実行する前に、サーバはデスティネーションリソースを "Depth: infinity"指定でDELETEしなければならない。Overwrite ヘッダの値が"F"に設定されているならば、オペレーションは失敗する。 8.8.5 状態コード 201 (Created) - ソース・リソースのコピーは成功した。コピー・オペレーションの結果、新しいリソースの作成が行われた。 204 (No Content) - ソースリソースのすでに存在するデスティネーションリソースへのコピーは成功した。 ソース・リソースは、うまく既存の目的地リソースへコピーされた。 403 (Forbidden) - ソースURIとデスティネーションURIが同じである。 409 (Conflict) - 一つ以上の中間に存在するコレクションが作成されておらず、リソースをデスティネーションに作成できない。 412 (Precondition Failed) - サーバは、propertybehavior XMLエレメントに列挙されたプロパティのLive性を維持できなかった。もしくは、Overwrite ヘッダがFであり、コピー先が非ヌルである。 423 (Locked) - デスティネーションリソースは、ロックされている。 502 (Bad Gateway) - デスティネーションが別のサーバ上に存在し、デスティネーションサーバがリソースの受け入れを拒否する場合に発生しうる。 507(Insufficient Storage) - ディストネーションリソースは、このメソッドの実行後に状態を記録するために十分なスペースを持っていない。 8.8.6 例−OverwriteによるCOPY この例では、リソースhttp://www.ics.uci.edu/~fielding/index.htmlがロケーションhttp://www.ics.uci.edu/users/f/fielding/index.htmlへコピーされる。 204 (No Content) ステータスコードは、デスティネーションに存在するリソースが上書きされていることを示す。 >>Request COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html >>Response HTTP/1.1 204 No Content 8.8.7 例−No OverwriteによるCOPY 以下の例は、Overwriteヘッダの値が "F" である以外は（8.8.6と）同じコピー操作をしている。412 (Precondition Failed) ステータスコードが返却されているが、これはデスティネーションリソースが非ヌルだからである。 >>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 >>Response HTTP/1.1 412 Precondition Failed 8.8.8 例−CollectionのCOPY >>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 * >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.foo.bar/othercontainer/R2/ HTTP/1.1 412 Precondition Failed コレクションのCOPY時の挙動として、"Depth: infinity"と指定されてるとみなすのが規定されているのでDepthヘッダは必要ない。この例では、コレクションと一緒に、大部分のリソースは、うまくコピーされている。しかしながら、コレクションR2が失敗している。おそらくプロパティのLive性（これは、propertybehavior XMLエレメントで指定されている）を維持できなかったためであろうと考えられる。R2のコピーが失敗したため、R2のメンバはコピーされなかった。しかし、これらのメンバのコピーにエラーは発生しなかった。というのも、セクション8.8.3で規定されているエラー最小化のためのルールが適用されているためである。 8.9 MOVE メソッド 非コレクションリソースのMOVEオペレーションはコピー(COPY)と論理的には同じであり、次に一貫性のメンテナンスを行い、そして移動元の削除を行う。この3つのアクションは、アトミックに実施される。一貫性のメンテナンスステップは、ソースリソースとして指定されるRequested-URI以外の全てのURIを更新して移動先の新しいURIを指すようにするなど、MOVEによって発生した更新をサーバが実行することを許す。 従って、Destination ヘッダは全てのMOVEメソッドについて指定されなければならなず、MOVEメソッドのCOPY部分のために全てのCOPYの条件を満たす必要がある。しかしながら、MOVEメソッドのサポートは特定の移動先へのリソースの移動を実施する能力を保証するものではない。 例えば、別々のプログラムは、同じサーバーで実際にリソースの異なるセットを制御してもよい。したがって、同じサーバーに属しているように見える名前空間の中で、リソースを動かすことは、可能とならないことがある。 リソースが移動先に目的地に存在するならば、ディストネーションリソースはMOVEオペレーション(Overwriteヘッダの制限に依存する)の副次効果として削除される。 8.9.1 プロパティのための移動 　MOVEにおけるプロパティの扱いは、propertybehavior XMLエレメントの効果に含まれるが、セクション8.8.2で規定したのと同じでなければならない。 8.9.2 コレクションのための MOVE "Depth: infinity"によるMOVEは、Request-URIによって指定されるコレクションをDestinationヘッダで指定するURIに移動させ、移動元のコレクションの内部メンバURIを移動先のコレクションに再帰的に移動させ、コレクションの階層構造を移す。 コレクションに対するMOVEメソッドは、"Depth: infinity"ヘッダが使用されてるかのように動作しなければならない。クライアントは、MOVEメソッド実行時に、Depthヘッダの値として "infinity"以外のいかなる値も採用してはならない。 MOVEで含まれる任意のヘッダは、Destinationヘッダを除いては移動するあらゆるリソースを処理する際に適用されなければならない。 Destinationヘッダの動作は、コレクションのCOPYのために与えられるものと同様である。 　MOVEメソッドが処理を完了したら、移動元と移動先の両方について整合性を持った名前空間が作成されなければならない（名前空間の整合性の定義については、セクション5.1を参照のこと）。しかしながら、内部コレクションの移動時にエラーが発生したら、そのまま処理を継続すると整合性のとれない名前空間ができる恐れがあるため、サーバは失敗したコレクションのメンバとして指定されるいかなるリソースも移動してはならない（サーバは、エラーが発生したサブツリーをスキップしなければならない）。このような場合、エラーを検出した後は、MOVE処理は、できるだけ多くのものを終えようとするべきである（サーバは他のサブツリーやそのツリーのメンバリソースの移動を試みるべきである。それらのリソースやサブツリーはエラーが発生しているコレクションに従属しない）。例えば、/a/b/ および /a/c/ というコレクションが含まれる /a/ というコレクションに対し、Depth: infinity な MOVEメソッドが発行され、/a/b/ の移動中にエラーが発生したら、/a/c/ の移動を試みるべきである。同じように、Depth: infinity な MOVE 最中に非コレクションリソースの移動でエラーが発生したら、サーバは可能な限り多くの移動操作を行うべきである。 エラーがRequest-URIで識別されるリソース以外のリソースで発生するならば、応答が207 (Multi-Statusでなければならない)。 　424 (Failed Dependency) ステータスコードは、MOVEメソッドのレスポンスとしての207 (Multi-Status) の中で返却されるべきではない。これらのレスポンスは、安全に省略される。というのも、クライアントは親リソースのエラーを受け取ったときに、その子リソースが移動できないことを知っているからだ。加えて、201 (Created) / 204 (No Content)ステータスコードも COPYメソッドの207 (Multi-Status) レスポンスの中で返却されるべきではない。これらのステータスコードは、MOVE 成功のステータスコードとして規定されているため、安全に省略される。 8.9.3 MOVEとOverwrite ヘッダ 　リソースが移動先に存在し、Overwrite ヘッダの値が "T" であるならば、移動を実行する前に"Depth: infinity"指定のDELETEを移動先のリソースに対して実行しなければならない。Overwrite ヘッダの値が"F"の場合は、操作は失敗する。 8.9.4 状態コード 201 (Created) - ソース・リソースはうまく移動され、新しいリソースが移動先に作成された。 204 (No Content) - ソース・リソースは、うまく既存の移動先リソースに移動された。 403 (Forbidden) - 移動元のURIと移動先のURIが同じである。 409 (Conflict) - 一つ以上の中間に位置するコレクションが存在しないため、リソースを移動先に作成できない。 412 (Precondition Failed) - サーバは、propertybehavior XMLエレメントに列挙されたプロパティのLive性を維持できなかった。もしくは、Overwrite ヘッダがFであり、移動先が非ヌルである。 423 (Locked) - ソースまたはディスティネーションリソースは、ロックされている。 502 (Bad Gateway) - デスティネーションが別のサーバ上に存在し、デスティネーションサーバがリソースの受け入れを拒否する場合に発生しうる。 8.9.5 例−非コレクションリソースのMOVE この例は、リソースhttp://www.ics.uci.edu/~fielding/index.htmlがロケーションhttp://www.ics.uci.edu/users/f/fielding/index.htmlに移動されている。移動先のリソースのコンテンツが非ヌルならば、移動先は上書きされる。今回の場合は、移動先リソースとしては何もないために、レスポンスコードは201 (Created) になる。 >>Request MOVE /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: 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 8.9.6 例−コレクションのMOVE >>Request MOVE /container/ HTTP/1.1 Host: www.foo.bar Destination: http://www.foo.bar/othercontainer/ Overwrite: F If: () () Content-Type: text/xml; charset="utf-8" Content-Length: xxxx * >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.foo.bar/othercontainer/C2/ HTTP/1.1 423 Locked 　この例では、クライアントは複数のロックトークンをリクエストとともに送信しちえる。メソッドの範囲内でロックされているリソースがあった場合、ロックトークンは、移動元と移動先の各リソースごとに送信することを必要とする。今回のケースでは、移動先 http://www.foo.bar/othercontainer/C2/ について適切なロックトークンが送信されなかった。 　/container/C2の移動でエラーが発生したため、/container/C2/ のメンバは移動されなかった。しかしながら、これらのメンバについてエラーは列挙されていない。というのも、セクション8.8.3で規定したエラー最小化ルールが機能しているからである。ユーザエージェントの認証が、根底にあるトランスポート層でHTTPプロトコルの範囲外のしくみで行われている。 8.10 LOCK メソッド 以下のセクションでは、LOCKメソッドについて説明すし、LOCKメソッドはあらゆるアクセスタイプに対するロックを行うために使用される。LOCKメソッドに関するこれらのセクションは、LOCKメソッドの仕様とリクエストされたロックのアクセスタイプの独立性についてのセマンティクスのみを記述する。 　LOCKメソッドをサポートするリソースは、少なくともここで定義されるXMLのリクエストフォーマットとレスポンスフォーマットをサポートしなければならない。 8.10.1 オペレーション LOCKメソッドの実行は、Request-URIの上でlockinfo XMLエレメントによって指定されるロックを作成する。LOCKメソッドのリクエストは、このロック・リクエストのためにowner XMLエレメントを含むXMLリクエスト・ボディを持っているべきである。但し、リフレッシュリクエストの場合はこの限りではない。LOCKリクエストは、Timeoutヘッダを持っていてもよい。 クライアントは、Timeoutヘッダで与えられる値に関係なく、ロックがいつでも消えるかもしれないとみなさなければならない。「並外れた」状況が起こらない限り、Timeoutヘッダはサーバーの動作を示すだけである。例えば、管理者はいつでもロックを削除してもよく、あるいは、システムはそれがロックの情報を失うような形で暴走してもよい。レスポンスは、prop XMLエレメントにおいてlockdiscoveryプロパティの値を含まなければならない。 新しく作成されたロックと関連するロック・トークンを示すために、Lock-Tokenレスポンスヘッダは、新しいロックのための成功したLOCKリクエスト全てに含まれなければならない。Lock-Tokenヘッダは、リフレッシュのためのLOCKリクエストが成功した場合には返却されないことに注意せよ。というのも、このリクエストは新しいロックを作成するわけではない。 8.10.2 プロパティとコレクションのロックの効果 ロックの範囲は、ボディおよび関連するプロパティを含むリソースの全ての状態である。その結果、リソースのロックは、また、リソースのプロパティをもロックしなければならない。 コレクションについては、ロックはメンバを追加したり削除したるするところにも影響する。効果の本質は、含まれるアクセス制御の種類に依存する。 8.10.3 写しを作られたリソースをロックすること リソースは、1つ以上のURIを通して取得できる。しかし、ロックはリソースに対して適用され、URIに対して適用されるわけではない。その結果、リソースをアドレス可能な全てのURIによって尊重されるのでなければ、リソースに対するLOCKリクエストは成功してはならない。 8.10.4 Depth とロック Depthヘッダが、LOCKメソッドで使われてもよい。LOCKメソッドにおいて、Depthヘッダに設定される値として、0またはinfinity以外のものが使われてはならない。LOCKメソッドをサポートする全てのリソースは、Depthヘッダをサポートしなければならない。 値0のDepthヘッダは、Request-URIによって指定されるリソースそのものをロックすることを意味する。 Depthヘッダが infinity にセットされたら、Request-URIで指定されたリソースおよびその内部のメンバ（階層構造上、指定されたRequest-URI配下のリソース）全てがロックされる。リクエストが成功した場合、結果としてロックされた全てのリソースのための単一のロックトークンが返却されなければならない。UNLOCKがこのトークンを用いて実行されたら、全ての関連するリソースはロック解除される。ロックが全てのリソースに与えられることができるというわけでないことがあるが、そんな場合は、どのリソースがロックを付与されていないかというのを記述するために、 409 (Conflict)、ステータスコードを、multistatus XMLエレメントを含んでいるレスポンスのエンティティ・ボディの中で返されなければならない。それゆえに、部分的に成功することはない。全ての階層構造がロックされるか、あるいはどのリソースもロックされないかのどちらかが結果となる。 DepthヘッダがLOCKリクエストに関して提出されない場合、"Depth:infinity"が指定されたとみなしてリクエストを実行しなければならない。 8.10.5 他のメソッドに対する相互作用 いろいろなメソッドによるLOCKの相互作用は、ロック・タイプに依存する。しかしながら、ロックタイプに関係なく、リソースに対するDELETEメソッドが成功した場合は全てのロックは削除されなければならない。 8.10.6 ロック互換性表 下のテーブルは、ロック・リクエストがリソースに対して行われる場合に発生する挙動を記述している。 現在のロック状態/|共有ロック　　　|排他ロック ロック要求 | | =================+================+============== 何もなし | True | True -----------------+----------------+-------------- 共有ロック | True | False -----------------+----------------+-------------- 排他ロック | False | False* ------------------------------------------------- 項目の意味 True: ロックが許可される False: ロックは許可されない *: 主体が同じものが二度をロックするリクエストは不正である。 リソースの現在のロック状態は最も左のカラムにおいて与えられる（何もなし／共有ロック／排他ロック）、そして、ロック・リクエストは最初の列にリストされる（共有ロック／排他ロック）。列とコラムの交差は、ロック・リクエストの結果を示す。例えば、リソースに対して共有ロックかかっており、その状態で排他ロックがリクエストされたら、テーブル・エントリは"False"となる。そして、ロックされてはならないことを示す。 8.10.7 ステータスコード 200 (OK) - ロックリクエストは成功し、lockdiscoveryプロパティの値はレスポンスボディに含まれる。 412 (Precondition Failed) - 含まれたロック・トークンはこのリソースに適用ができなかった。あるいは、サーバに送られたリクエストに含まれるlockinfo XMLエレメントが、満足なものではなかった。 423 (Locked) リソースがロックされており、メソッドが拒絶された。 8.10.8 例−シンプルなLock Request >>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="..." http://www.ics.uci.edu/~ejw/contact.html >>Response HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Infinity http://www.ics.uci.edu/~ejw/contact.html Second-604800 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 この例は、リソースhttp://webdav.sb.aol.com/workspace/webdav/proposal.doc に対して書き込みの排他ロックが成功した場合を示している。リソースhttp://www.ics.uci.edu/~ejw/contact.htmlは、ロックのオーナへの連絡先を含む。サーバーはこのリソースの置かれているところにおいて、アクティビティベースのタイムアウト・ポリシーを設定しており、そのため1週間(604800秒)で、ロックを自動的に削除することになっている。 nonce,response,opaqueの各フィールドがAuhoroization リクエストヘッダにて計算されていないことに注意せよ。 8.10.9 Write Lockリフレッシュの例 >>Request LOCK /workspace/webdav/proposal.doc HTTP/1.1 Host: webdav.sb.aol.com Timeout: Infinite, Second-4100000000 If: () Authorization: Digest username="ejw", realm="ejw@webdav.sb.aol.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..." >>Response HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Infinity http://www.ics.uci.edu/~ejw/contact.html Second-604800 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 このリクエストはロックをリフレッシュし、任意のタイム・アウトをリセットする。クライアントが無限のタイムアウト値を指定したのに大使、サーバはそのリクエストを無視した部分に注目しなさい。 クライアントがサーバー以外の外へ時間が要請を無視するように選ぶ無限を求めたと気がつく。この例では、nonce, response,とopaqueフィールドは、Authorizationリクエスト・ヘッダで計算されていない。 8.10.10 複数のリソースロックのリクエストの例 >>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="..." http://www.ics.uci.edu/~ejw/contact.html >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://webdav.sb.aol.com/webdav/secret HTTP/1.1 403 Forbidden http://webdav.sb.aol.com/webdav/ HTTP/1.1 424 Failed Dependency この例は、コレクションと全ての子リソースに対する書き込みの排他ロックのためのリクエストを示す。このリクエストにおいて、もしできるならばクライアントは無限長のロックタイムアウトを指定し、無限のタイムアウトを設定できない場合は可能であれば4.1億秒のタイムアウト値を設定するようリクエストしている。リクエストのエンティティボディは、ロックをしようとしている主体の連絡先を含む。今回の場合はWebページのURLを指定している。 　エラーは、リソース http://webdav.sb.aol.com/webdav/secret のレスポンス 403(Forbidden) である。このリソースがロックされなかったため、指定したリソースは全くロックされなかった。Request-URI に対するlockdiscoveryプロパティが含まれることに注意せよ。この例においては、リソースに対して実行されるロックがないため、lockdiscoveryプロパティは空である。 この例では、nonce, responseとopaqueフィールドは、Authorizationリクエスト・ヘッダにて計算されていない。 8.11 UNLOCKメソッド UNLOCKメソッドは、Lock-Tokenリクエストヘッダ内のロック・トークンによって識別されるロックを Request-URI およびそのURIをロックした時にいっしょにロックされたリソースから削除する。送信されたロックトークンで全てのリソースのロックを削除できない場合は、UNLOCKリクエストは失敗しなくてはならない。 LOCKメソッドをサポートするDAV準拠のリソースは、UNLOCKメソッドをサポートしなければならない。 8.11.1 UNLOCKの例 >>Request UNLOCK /workspace/webdav/info.doc HTTP/1.1 Host: webdav.sb.aol.com Lock-Token: Authorization: Digest username="ejw", realm="ejw@webdav.sb.aol.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..." >>Response HTTP/1.1 204 No Content この例では、ロック・トークン"opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7"によって識別されるロックは、首尾よくリソースhttp://webdav.sb.aol.com/workspace/webdav/info.docから削除される。このロックがちょうど1つ以上のリソースを含むならば、そのロックに含められる全てのリソースからロックが削除される。204 (No Content)ステータスコードが、200 (OK)の代わりに使われる。というのも、レスポンスのエンティティボディがないからである。 　この例では、nonce, responseとopaqueフィールドは、Authorizationリクエスト・ヘッダにて計算されていない。 9.分散オーサリングのためのHTTPヘッダ 9.1 DAVヘッダ DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend] 　このヘッダは、リソースがDAVスキーマと指定されたプロトコルをサポートすることを意味する。全てのDAV準拠のリソースは、DAVヘッダをOPTIONSメソッドの全てのレスポンスに付加しなければならない。 　設定される値は、リソースがサポートする全てのDAV準拠クラスの一覧である。上記において、2の前にコンマ(",")がすでに付加されているが、これは準拠レベル1の条件は満たさないが準拠レベル2の条件を満たすDAV準拠リソースは存在しないからである。詳細については、セクション15を参照のこと。しかしながら、一般的に 値は、リソースがサポートする全ての迎合性クラスのリストである。コンマより上にすでに増された2。これは、それがまた、に準拠したレベル1でない限り、リソースがに準拠したレベル2ではありえないからである。詳細はセクション15を参照してください。 　しかしながら、一般的には、ある準拠クラスをサポートするために他の準拠クラスをサポートしなければならないということはない。 9.2 Depthヘッダ Depth = "Depth" ":" ("0" | "1" | "infinity") 　Depthヘッダは、 内部のメンバを潜在的に持ちうるリソースに対してメソッドの効果をどこまで及ぼすかを指示するため、実行されるメソッドとともに用いられる。指定は3通りあり、それぞれ指定したリソースだけに効果を及ぼすか(Depth:1)、リソースおよびその直下のリソースにメソッドの効果を及ぼす(Depth:1)か、配下のリソース全てに効果を及ぼす(Depth:infinity)というものである。 　Depthヘッダは、そのようなサポートを明示的に提供すると定義したメソッドにおいてのみサポートされる。 　以下のルールは、Depthヘッダがサポートする全てのメソッドにおける規定の動作である。しかしながら、規定のものとは異なる動作を個々のメソッドで定義することで、この規定の動作を無効にできる。 　原則的には、場合に応じてDepthヘッダをサポートするメソッドは、ヘッダの値として全てをサポートしないことを選択し、Depthヘッダが与えられない場合の動作を定義することを許されている。例えば、MOVEメソッドは"Depth: infinity"のみサポートし、Depth ヘッダが与えられない場合は"Depth: infinity"が指定されたものとみなす。 クライアントは、任意の特別の順にそれらの階層のメンバー上で実行するメソッドや、メソッドのアトミックな実行に依存してはならない。 　実行において、Depthヘッダをともなうメソッドは、割り当てられた範囲で可能な限り多くのタスクを実行する。そして、何が成功し、何が失敗したかを示すレスポンスを返す。 　このため、例えば、階層のCOPYの実行は、コピーできたメンバとそうでないものについての結果を返却する。 　メソッドにおいて、Depthヘッダと協調して動くよう定義されたヘッダは、メソッドの範囲内において全てのリソースに対して適用されなければならない。但し、他の動作が明示的に定義されている場合を除く。例えば、If-Matchヘッダは、メソッドの範囲内ですべてのリソースに適用される値を持っており、ヘッダが一致しない場合はメソッドの実行は失敗する。 　ソースもしくはデスティネーションにおいて、Dメソッドの適用範囲に含まれ、Depthヘッダをともなうリソースが、メソッド実行を成功させることを妨げるような目的でロックされるならば、それらのリソースのロックトークンはリクエスト中のIfヘッダの要求に従って提供されなければならない。 　Depthヘッダは、内部の子リソースについてのメソッドの挙動を指定するのみである。もしリソースが内部の子リソースを持っていない場合は、Depthヘッダは無視されなければならない。 　しかしながら、メソッドの定義で許可されていないDepthヘッダを送った場合は、常にエラーとなることに注意されたい。結果として、COPYメソッドにおいて "Depth: 1"を指定した場合、指定したリソースが子リソースを持っていなくても、400 (Bad Request) ステータスコードが返却される。メソッドは、リソースが内部のメンバを持っているからではなく、ヘッダに不正な値が入ってるために失敗する。 9.3 ディストネーションヘッダ Destination = "Destination" ":" absoluteURI DestinationヘッダはCOPYとMOVEのようにパラメータとして2つのURIをとるメソッドのためにディストネーションリソースを識別するURIを指定する。absoluteURIの生成法は、[RFC2396]によって定義される。 9.4 Ifヘッダ 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 ">" 　IFヘッダは、[RFC2068]のセクション14.25にて定義されるIf-Matchヘッダと類似の機能を持つことを意図している。しかしながら、Ifヘッダは、状態トークンを参照するように、Etagsのようなリソースの状態を表現するあらゆるURIとともに使われることを意図している。状態トークンの典型的な例は、ロックトークンであり、ロックトークンは本仕様の中で定義される唯一の状態トークンである。 全てのDAV準拠のリソースは、Ifヘッダを尊重しなければならない。 　Ifヘッダの目的は、一連の状態リストを記述することである。ヘッダが適用されているリソースの状態が、列挙されているいかなる状態とも一致しない場合は、リクエストは412 (Precondition Failed) ステータスコードを返却され、失敗しなければならない。状態リストに列挙されているいずれかに一致した場合は、リクエストは成功する。 　absoluteURIの作成法については、[RFC2396]にて定義されていることに注意せよ。 9.4.1 No-tag-list Production 　No-tag-list プロダクションは、一連の状態トークンとEtagを記述する。複数のNo-tag-listプロダクションが使用されている場合、メソッドが実行継続を許可されるためにはその中の1つだけ一致すればよい。 DepthまたはDestinationヘッダの存在のために、メソッドが複数のリソースに対して適用される場合には、No-tag-list プロダクションはメソッドが適用される各リソースに対して適用されなければならない。 9.4.1.1 No-tag-list If Headerの例 If: ( ["I am an ETag"]) (["I am another ETag"]) 　上記のヘッダは、要求する。 　メソッドの範囲内のリソースは「指定したロックトークンでロックされていて、かつ"I am an ETag" というETagで示される状態」であるか、「2番目のETag "I am another ETag"で示される状態」であるかということを要求する。 ロックされる 前のヘッダはメソッドの範囲内でとても少しもリソースを要求しようとするどちらか、指定されたロック・トークンで、そして、識別される状態にはロックする「私は、ETagである」ETag、あるいは、第二のETagによって識別される状態には、「私は、もう一つのETagである」。形式であるので、より率直に一つの問題を置くことは、前のIfヘッダについて考えることができる(あるいは、(そして発行する、 [「私は、ETagである」])(そして、[「私は、もう一つのETagである」]))。さらに追加したい場合は、上記のIf ヘッダの形式が以下のような解釈をされるので参考にしてほしい。 (or (and ["I am an ETag"]) (and ["I am another ETag"])). 9.4.2 Tagged-list プロダクション 　tagged-listプロダクションは、プロダクションの一覧を定める。それは、指定されたリソースに対してのみ適用するリソース指定のリストを指定する。リソースプロダクションの範囲は、いかなる場合においてもリソースプロダクションに続くプロダクションの一覧にはじまり、次のリソースプロダクションで終了する。 　Ifヘッダが特定のリソースに適用される場合、tagged-listプロダクションは列挙されたリソースのいずれかが現在のメソッドのオペランドリソースと一致するかどうかを検査しなければならない。現在のリソースとリソースプロダクションが一致しない場合、ヘッダは無視される。もしリソースプロダクションの1つが現在のリソースと一致した場合は、リソースプロダクションに続くリストプロダクションは、前のセクションでの定義に従い、リソースに対して適用されなければならない。 Ifヘッダ内で、同じURIは2度以上リソース・プロダクションに現れてはならない。 9.4.2.1 Tagged-List Ifヘッダ の例 COPY /resource1 HTTP/1.1 Host: www.foo.bar Destination: http://www.foo.bar/resource2 If: ( [W/"A weak ETag"]) (["strong ETag"]) (["another strong ETag"]) この例では、http://www.foo.bar/resource1はhttp://www.foo.bar/resource2.へコピーされる。 　メソッドがhttp://www.foo.bar/resource1 に最初に適用される時、resource1は、"( [W/"A weak ETag"])(["strong ETag"])"であらわされる状態になければならず、これは、"locktoken:a-write-lock-token" というロックトークンをもっており、弱いエンティティタグ W/"A weak ETag" というエンティティタグを持っているか、強いエンティティタグ "strong ETag"を持っていなくてはならない。 resource http://www.bar.bar/random は、適用されるメソッドをリクエストの中に含まないため、上記の条件は唯一の成功条件である。（他のリソースのみがIfヘッダにリストされている）。そして、http://www.foo.bar/resource2 はIfヘッダ内に列挙されていない。 9.4.3 not プロダクション あらゆる状態トークンまたはETagがカレントで、結果としてリソースの状態をあらわしているか、カレントでなくリソースの状態を記述していないかのいずれかである。その結果、状態トークンを一致させる論理演算もしくは、リソースのカレントの状態へのEtagは、真もしくは偽であると解決される。"not"プロダクションは、値を反転させる。not プロダクションの扱う範囲は、状態トークンもしくはエンティティタグであり、以下に例を示す。 If: (Not ) 　リクエストにともなって送信されるとき、このIfヘッダは全てのオペランドリソースがlocktoken:write1というロックトークンではなく、locktoken:write2 というロックトークンでロックされていなければならないということを要求する。 9.4.4 Matchng 機能 　Ifヘッダの処理を実行する際に、リソースの状態トークンもしくはエンティティタグのマッチングの定義は以下のようになる。 Ifヘッダ処理を実行するとき、一致している状態トークンまたはエンティティ・タグの定義は次の通りである。 エンティティ・タグと一致: エンティティ・タグがそのリソースと関連するエンティティ・タグに一致する。 状態トークンと一致: Ifヘッダ内の状態トークンとリソース内の任意の状態トークンが完全一致する。 9.4.5 If HeaderとNon-DAV Compliant Proxies 非DAV準拠のプロキシはIfヘッダを尊重しない。というのも、それらのプロキシはIfヘッダを理解せず、HTTPは理解できないヘッダは無視するということを要求しているからだ。HTTP/1.1プロキシと通信する際に、"Cache-Control: no-cache"リクエストヘッダが使用されなければならない。というのも、プロキシがキャッシュからのサービスリクエストを不適切に試行するのを避けるためである。HTTP/1.0 プロキシを使用する際に、"Pragma: no-cache"リクエストヘッダを使用しなければならないのも同様の理由である。 9.5 Lock-Token ヘッダ Lock-Token = "Lock-Token" ":" Coded-URL Lock-Tokenリクエスト・ヘッダは、UNLOCKメソッドとともに、除去されるロックを識別するために使用される。Lock-Tokenリクエストヘッダ中のロックトークンは、Request-URIによって識別されるリソースをメンバとして含むロックであることを認識しなければならない。 　Lock-Tokenレスポンスヘッダは、新しいロックを作成するためのLOCKリクエストが成功した結果として、ロックトークンが生成されたことを示すためにLOCKメソッドとともに使用される。 9.6 Overwrite ヘッダ Overwrite = "Overwrite" ":" ("T" | "F") 　Overwriteヘッダは、COPYメソッドやMOVEメソッドにおいて、サーバが非ヌルの状態であるデスティネーションリソースを上書きするかどうかを指定する。ヘッダの値が"F"の場合、サーバは非ヌルの状態であるデスティネーションリソースに対するCOPYやMOVEの操作を実行してはならない。overwriteヘッダがCOPYやMOVEメソッドのリクエストヘッダに含まれない場合、overwriteヘッダ値として"T"が指定されたものとして処理しなければならない。Overwriteヘッダは、HTTP/1.1 における "If-Match: *" ヘッダと機能的には重複する部分がある一方、If-MatchヘッダはRequest-URIに対して機能するものであり、COPYメソッドやMOVEメソッドに対しては機能しない。 　COPYメソッドやMOVEメソッドがoverwriteヘッダの値の指定に起因して（"F"が指定されて）実行できなかった場合には、メソッド実行は失敗し、412 (Precondition Failed) ステータスコードが返却されなければならない。 　全てのDAV準拠のリソースは、Overwriteヘッダをサポートしなければならない。 9.7 Status-URI レスポンスヘッダ 　Status-URI レスポンスヘッダは、102 (Processing) ステータスコードとともに使うことが出来、クライアントにメソッドのステータスを通知する。 Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Codeについては、[RFC2068]の6.1.1で定義されている。 ヘッダに列挙されるURIは、実行中のメソッドによって影響を受けているソースリソースである。ステータスコードは、指定されたリソースにおけるメソッドの解決状況を示す。例を上げると、コレクションのMOVEメソッドが実行中であり、Status-URIレスポンスヘッダをともなって102 (Processing) ステータスコードが返却されるならば、そこに含まれるURIについては、移動が試行されたリソース　クライアントは、 とその結果が示されている。 9.8 Timeout リクエストヘッダ TimeOut = "Timeout" ":" 1#TimeType TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other) DAVTimeOutVal = 1*digit Other = "Extend" field-value ; [RFC2068] を参照 　クライアントは、LOCKリクエストにTimeoutヘッダを含めて良い。しかしながら、サーバ側はそのリクエストを扱ったり、認識したりする必要はない。クライアントは、LOCKメソッド以外のいかなるメソッドにおいてもTimeoutヘッダを送信してはならない。 　Timeoutリクエストヘッダは、最低限1つのTimeTypeを含まなくてはならないが、複数のTimeTypeエントリを含んでも良い。複数のTimeTypeを列挙する目的は、クライアントが受け入れられる複数の異なる値と型を示すためである。クライアントは、優先度に従ってTimeTypeエントリを列挙する。 　Timeout レスポンス値は、秒単位の値、Infinite、もしくはクライアントが親和性を提示したTimeTypeによる値を使わなければならない。サーバは、Timeoutヘッダで送信した任意のTimeTypeを解釈できるとみなしてよい。 　"Second" TimeTypeは、サーバにおいてロックが付与され、そして自動的にロックが除去されるまでに経過する秒数を指定する。"Second" TimeTypeで指定されるtimeout値は、2^32-1を超えてはならない。 　タイムアウトカウンタは、ロックのオーナがロックされているメンバに対するメソッドを送った時はいつでも再起動されるべきである。なお、実行するメソッドについてはTimeoutヘッダをサポートしないメソッドや、実行が失敗するメソッドも含む。しかしながら、リフレッシュのためのLOCKメソッドが正常に受信されたならば、ロックは必ず再起動されなければならない。 　ロックがタイムアウトしたら、ロックは消失してもよい。特に、サーバがタイムアウト時にロックを刈り取りたいならば、サーバはタイムアウトしたロックに対応するロックトークンを用いて、承認を無視してサーバーがUNLOCKメソッドをリソースに実行したかのような動きをすべきである。その結果、ログについてはUNLOCKリクエストが発行された時のようにてロックの配置について更新し、通知したりその他必要な動作をする必要がある。 　サーバーは、クライアントによって提出された値に細心の注意を払うように指示される。というのも、それらの値クライアントの動作にあたってのアクティビティのタイプを示しているからである。例えば、ブラウザ上で動作しているアプレットがリソースロックを要求しても良い。しかし、アプレットが動作している環境が不安定であるため、アプレットは、何の警告もなしに終了することがある。その結果アプレットは、異常終了しても早期にロックを刈り取れるように、相対的に小さい値のタイムアウト値を要求しようとする。しかしながら、ドキュメント管理システムは、ユーザがオフラインになることを見込んでいるため、非常に大きいタイムアウト値を要求しようとする。 クライアントは、タイムアウトが期限切れになったからといって、ロックが消失したとみなしてはならない。 10. HTTP/1.1から拡張されたステータスコード 以下のステータスコードは、HTTP/1.1 [RFC2068]において定義されたものに追加される。 10.1 102 Processing 102 (Processing)ステータスコードは、リクエストを受け取ったがまだ処理が完了していないことをクライアントに対して通知するために使用される一時的なレスポンスである。このステータスコードは、サーバ側にリクエストが完了するまでにかなりの時間がかかる正当な理由があるときにのみ使われるべきである。ガイダンスによれば、メソッドの処理に20秒（正当HTTPが無視されるnon-understoodヘッダを要求するので、Ifヘッダを尊敬しない。HTTP/1.1のプロキシと通信するとき、「キャッシュ-Control：no-cache」リクエスト・ヘッダがサービスに不適当にためすことからプロキシを防ぐために使われなければならなくて、そのキャッシュからリクエスト。HTTP/1.0のプロキシを扱うとき、「Pragma：no-cache」リクエスト・ヘッダが同じ理由のために使われなければならない。 な任意の値）かかる場合に、サーバは102(Processing)のレスポンスを返すべきである。サーバは、リクエストの処理が完了した後に、最終的なレスポンスを返さなければならない。 　メソッドは、潜在的に特にDepthヘッダをサポートするメソッドについて処理に長い時間がかかる可能性を持っている。そのような場合、クライアントはレスポンスを待っている間にタイムアウトするかもしれない。このようなことを回避するために、サーバは102(Processing)ステータスコードを返却することで、サーバがまだメソッドの処理中であることをクライアントに通知する。 10.2 207 Multi-Status 207(Multi-Status)ステータスコードは、複数の独立な操作のステータスを提供する（詳細についてはセクション11を参照のこと）。 10.3 422 Unprocessable Entity 422 (Unprocessable Entity)ステータスコードは、サーバはリクエストエンティティのコンテントタイプは解釈できて（このため、415(Unsupported Media Type)ステータスコードは適切ではない）、エンティティの文法も正しい（この結果、400(Bad Request)ステータスコードは適切ではない）が、エンティティに含まれる命令を処理できない場合に返却される。例えば、XMLリクエストボディが整形型（文法的には正しい）であるが、XMLの命令がセマンティカルにおかしい場合にこのエラー状態が発生する。 10.4 423 Locked 423 (Locked) ステータスコードは、メソッドのソースまたはデスティネーションリソースがロックされていることを意味する。 10.5 424 Failed Dependency 424 (Failed Dependency) ステータスコードは、リクエストされた動作がまた別の動作に依存しており、かつその別の動作が失敗したために、リクエストした動作がリソースを操作できなかったことを意味する。例えば、少なくともPROPPATCHメソッド中に含まれるコマンド実行が失敗したら、残りのコマンド実行も（それにひきずられて）失敗し、424 (Failed Dependency) ステータスを返却される。 10.6 507 Insufficient Storage 507 (Insufficient Storage)ステータスコードは、 サーバに対し、リクエストが正常に完了するために必要なものを保存できず、その結果としてリソースに対するメソッド実行ができなかったことを意味する。この状態は一時的なものとして認識される。ユーザの操作の結果としてこのステータスコードを受け取った場合、個々のユーザがリクエストを発行するまでは当該リクエストを繰り返すべきではない。 11 Multi-Status レスポンス 207 (Multi-Status) の規定のレスポンス・ボディは、text/xmlまたはapplication/xml なHTTPエンティティであり、multistatusと呼ばれる単一のXMLエレメントを含む。そして、そのレスポンスボディには、メソッド実行の結果生成されるステータスコード200,300,400,500の系列のステータスコードを含む。100系列のステータスコードは、レスポンスのXMLエレメントに含まれるべきでない。 12 XML Element Definitions 本セクションでは、各セクションの最後の行に[REC-XML]で定義されたフォーマットを使用したエレメントタイプの宣言を揚げている。"Value"フィールドが存在している場合、そこではBNF書法を用いてXMLエレメントの内容として選択可能なものを指定してある（例えばPCDATA エレメントのValueは追加の制限が記述してある）。 12.1 activelock XMLエレメント Name: activelock Namespace: DAV: Purpose: リソースのロックを記述する。 12.1.1　depth XMLエレメント Name: depth Namespace: DAV: Purpose: Depth ヘッダの値を指定する。 Value: "0" | "1" | "infinity" 12.1.2 locktoken XMLエレメント Name: locktoken Namespace: DAV: Purpose: The lock token associated with a lock. Description: hrefは、全く同じロックを参照する一つ以上の opaque lock token URIを含む(OpaqueLockToken-URIは、セクション6.4を参照のこと)。 12.1.3 timeout XMLエレメント Name: timeout Namespace: DAV: Purpose: lock のタイムアウト値 Value: TimeType ;セクション9.8にて定義されている。 12.2 collection XML Element Name: collection Namespace: DAV: Purpose: コレクションとして関連するリソースを識別する。コレクション・リソースのresourcetypeプロパティは、この値を持っていなければならない。 12.3 href XMLエレメント Name: href Namespace: DAV: Purpose: エレメントの内容をURIとして指定する。 Value: URI ; [RFC2068]のセクション3.2.1を参照のこと 12.4 Link XMLエレメント Name: link Namespace: DAV: Purpose: リンクとしてのプロパティを識別して、そのリンクのソースとデスティネーションを含む。 Description: link XMLエレメントは、リンクのソースとデスティネーションを与えるのに用いられる。link XMLエレメントを含むプロパティの名前は、リンクのタイプを与える。linkは同じタイプの複数の値をとるエレメントである。もしlink XMLエレメントの中のsrc XMLエレメントと dst XMLエレメント内に位置する href XMLエレメントの値として、存在しないリソースが指定されていたとしても、それを拒否してはならない。 12.4.1 dst XMLエレメント Name: dst Namespace: DAV: Purpose: リンクのデスティネーションを示す Value: URI 12.4.2 src XMLエレメント Name: src Namespace: DAV: Purpose: リンクのソースを示す。 Value: URI 12.5 lockentry XMLエレメント Name: lockentry Namespace: DAV: Purpose: リソースで使えるロックの種類を定義する。 12.6 lockinfo XMLエレメント Name: lockinfo Namespace: DAV: Purpose: LOCKメソッドとともに使われ、クライアントが作成することを期待しているロックの種類を指定する。 12.7 lockscope XMLエレメント Name: lockscope Namespace: DAV: Purpose: ロックが排他ロックか共有ロックかを指定する。 12.7.1 exclusive XMLエレメント Name: exclusive Namespace: DAV: Purpose: 排他ロックを指定する 12.7.2 shared XMLエレメント Name: shared Namespace: DAV: Purpose: 共有ロックを指定する 12.8 locktype XML Element Name: locktype Namespace: DAV: Purpose: ロックのアクセスタイプを指定する。現在は、この指定は1つのロックタイプwrite lockしか指定しない。 12.8.1 write XMLエレメント Name: write Namespace: DAV: Purpose: 書き込みロックを指定する。 12.9 multistatus XMLエレメント Name: multistatus Namespace: DAV: Purpose: 複数のレスポンスメッセージを含む。 Description: トップレベルの responsedescription は、支配的な性質を持つ一般的なメッセージを提供するのに用いられる。この値が取得された場合、アプリケーションは（複数の）レスポンスに含まれる個々の記述のかわりにその値を使っても良い。 12.9.1 response XMLエレメント Name: response Namespace: DAV: Purpose: リソースもしくはリソースとプロパティに対してメソッドが及ぼす高価を記述するための単一の応答を保持する。 Description: multistatus XMLエレメントの下にresponse XMLエレメントがある場合、その中で特定の href は、1度以上あらわれてはならない。 　この要求は、レスポンスのための処理コストがリニアにおさまるために必要である。 この要求は、リニア時間に対する応答のために処理コストを保つために必要である。本質的に、これはhrefによって全ての応答をまとめるために捜すために持っていることを防ぐ。しかし、基礎を形成される順序に関する要求が、href値の上にない。本質的には、このことはhrefの全てのレスポンスのグルーピングのための検索を避けることになる。しかしながら、hrefの値に基づいたオーダリングに従う必要はない。 12.9.1.1 propstat XML Element Name: propstat Namespace: DAV: Purpose: 特定のhrefエレメントと関連する propエレメントとstatusエレメントをまとめる。 Description: propstat XMLエレメントは、1つの prop XMLエレメントと1つの status XMLエレメントを含まなければならない。prop XMLエレメントの内容は、status エレメントでの結果をどれを適用するかについて、プロパティの名前をリストしなければならないだけである。 12.9.1.2 status XMLエレメント Name: status Namespace: DAV: Purpose: 単一のHTTP status-lineを保持する。 Value: status-line; status-line は[RFC2068]中で定義されている。 12.9.2 responsedescription XMLエレメント Name: responsedescription Namespace: DAV: Purpose: ユーザーに表示されることができるメッセージを含み、レスポンスの種類を説明する。 Description: このXMLエレメントは、ユーザーに提示される適切な情報を提供する。 12.10 owner XMLエレメント Name: owner Namespace: DAV: Purpose: ロックを保持している主体に関する情報を提供する。 Description: owner XMLエレメントは、直接ロックを保持する主体とコンタクトを取るための情報（例えば電話番号や電子メールURI）もしくはロックを保持する主体を発見するための情報を提供する。 12.11 prop XMLエレメント Name: prop Namespace: DAV: Purpose: リソースと関係するプロパティを含む。 Description: prop XMLエレメントは、リソースで定義されるプロパティのための一般的なコンテナである。prop XMLエレメントの内側の全てのエレメントは、リソースと関係するプロパティを定義しなければならない。他のいかなるエレメントも、prop エレメントの内側で使われてはならない。 12.12 propertybehavior XMLエレメント Name: propertybehavior Namespace: DAV: Purpose:プロパティがCOPYかMOVEの間、どのように取り扱われるかについて指定する。 Description: propertybehavior XMLエレメントは、プロパティがコピーか移動の間、どのように取り扱われるかについて指定する。このXMLエレメントがリクエスト・ボディで含まれないならば、関連するメソッドのデフォルトのプロパティ操作の定義に従ってサーバは処理を行う。DAVに準拠した全てのWebDAVリソースは、propertybehavior XMLエレメントをサポートする。 12.12.1 keepalive XMLエレメント Name: keepalive Namespace: DAV: Purpose: Liveプロパティのコピー/移動のための要求条件を指定する。 Description: keepaliveの値としてURIのリストが含まれる場合、COPY(MOVE)メソッドによりコピー（移動）先へのコピー（移動）が終了した後に、指定されたプロパティは"Live"にならなければならない。keepalive XMLエレメントに"*"という値が与えられた場合、全てのLiveプロパティがコピー（移動）されなければならない。もしkeepaliveエレメントによる要求が満たされない場合、メソッドは412(Precondition)ステータスコードを返却して失敗しなければならない。全てのDAV準拠のリソースは、COPYメソッドやMOVEメソッドの使用にあたりkeepalive XMLエレメントをサポートしなければならない。 Value: 「*」；#PCDATA値は、「*」でありえるだけである 12.12.2 omit XMLエレメント Name: omit Namespace: DAV: Purpose: omit XMLエレメントは、プロパティを可能な限りコピーするが、プロパティコピーが失敗した場合にもメソッドの実行が失敗したとしてはならないようにサーバに指定する。 　 Descriptions: COPY や MOVE メソッドの規定の動作は、全てのプロパティがコピー／移動されるかメソッドが失敗するかのいずれかである。しかし、FTPのように他のプロトコル経由でリソースコピーを行う場合などは、リソースに付随したプロパティをコピー／移動するのは不可能です。その結果、FTPを介したコピー／移動は、全てのプロパティが（それがDeadプロパティであろうとも）移動できず、常に失敗します。全てのDAV準拠のリソースは、COPY/MOVEメソッドにおいてomit XMLエレメントをサポートしなければなりません。 12.13 propertyupdate XMLエレメント Name: propertyupdate Namespace: DAV: Purpose: リソースのプロパティを変更するリクエストを含む。 Description: このXMLエレメントは、リソースでプロパティを変更するために必要な情報のためのコンテナである。このXMLエレメントは、複数の値をとりうる。 12.13.1 remove XMLエレメント Name: remove Namespace: DAV: Purpose: リソースから削除されるDAVプロパティをリストする。 Description: propエレメントで指定したプロパティを削除するように指示する。存在しないプロパティの削除はを指定することは、エラーではない。remove XMLエレメント内のでは、削除されるプロパティの名前だけが必要なので、 prop XMLエレメント内ではXMLエレメントは空でなければならない。 12.13.2 set XMLエレメント Name: set Namespace: DAV: Purpose: リソースに設定されるDAVプロパティの値を列挙する。 Description：set XMLエレメントは、prop XMLエレメントだけを含まなければならない。set XMLエレメント中のprop XMLエレメントに含まれるエレメントは、Request-URIによって指定されるリソースに設定されるプロパティと設定値でなければならない。すでにプロパティが存在する場合、そのプロパティの値が置き換えられる。プロパティの値中の言語タグ情報（xml:lang 属性が提供される場合はそれ）は、プロパティ中に継続的に保持されなければならず、PROPFINDを用いることで副次的に取得されなければならない。 12.14 propfind XMLエレメント Name: propfind Namespace: DAV: Purpose: PROPFINDメソッドの結果返却されるプロパティを指定する。2つの特別なエレメント "allprop" と "propname" は、propfind エレメントとともに使用される。propエレメントがpropfindの中で使われるならば、そこにはプロパティ名を含まなければならないだけである。プロパティ値はその限りではない。 12.14.1 allprop XMLエレメント Name: allprop Namespace: DAV: Purpose: allprop XMLエレメントは、リソースが持つ全てのプロパティ名と値を返却するように指定する。 12.14.2 propname XMLエレメント Name: propname Namespace: DAV: Purpose: propname XMLエレメントは、リソースが持つプロパティ名の一覧を返却するように指定する。 13 DAVプロパティ 　DAVプロパティについて、プロパティ名もまた値を含むXMLエレメントの名前と同様に記述される。以下のセクションでは、セクションの最後の行に、[REC-XML]で定義された形式を用いて、エレメント型の宣言を示す。"Value"フィールドが与えられている場合、BNF記法を用いて制限を指定している（例：PCDATAエレメントの値の制限）。 13.1 creationdateなプロパティ Name: creationdate Namespace: DAV: Purpose: リソースが作成された日時と時間を記録する。 Value: data-time 日付-時間；Appendix 2を参照のこと。 Description: creationdateプロパティは、全てのDAV準拠のリソースにて定義されるべきである。もしあるならば、リソースが作成された時のタイムスタンプがそこに含まれる。 13.2 displayname プロパティ Name: displayname Namespace: DAV: Purpose: ユーザーに提示するのに適切なリソース名を提供する。 Description: displaynameプロパティは、全てのDAVに準拠したリソースで定義されるべきである。もしあるならば、プロパティはユーザーに提示するのにふさわしいリソースの記述がその中に含まれる。 13.3 getcontentlanguage プロパティ Name: getcontentlanguage Namespace: DAV: Purpose: ヘッダをアクセプトすることがなくても、GETのレスポンス中で、Content-Languageヘッダの内容を含む。 Description: getcontentlanguageプロパティは、GET 時に Content-Languageヘッダが返却されるDAV準拠リソースにおいて定義されなければならない。 Value: language-tag；language-tagは、[RFC2068]のセクション14.13にて定義される 13.4 getcontentlength プロパティ Name: getcontentlength Namespace: DAV: Purpose: ヘッダをアクセプトすることがなくても、GETのレスポンス中で、Content-Lengthヘッダの内容を含む。 Description: getcontentlengthプロパティは、GETのレスポンス中にてContent-Lengthヘッダが返却されるDAV準拠リソースにて定義される必要がある。 Value: content-length ;セクション14.14を見なさい[RFC2068] 13.5 getcontenttype プロパティ Name: getcontenttype Namespace: DAV: Purpose: ヘッダを受け入れないGETにて返却されるContent-Typeヘッダの内容を含む。 Description: このgetcontenttypeプロパティは、任意のDAVの上でContent-Typeヘッダを返却するDAV準拠のリソースにて定義されなければならない。 Value: media-type；[RFC2068]の3.7セクションにて定義される 13.6 getetag プロパティ Name: getetag Namespace: DAV: Purpose: ヘッダを受け入れない場合のGETにてETagヘッダの内容を含む。 Description: Etagヘッダを返す任意のDAV準拠のリソースで、getetagプロパティは、定義されなければならない。 Value: entity-tag；[RFC2068]のセクション3.11にて定義される。 13.7 getlastmodified プロパティ Name: getlastmodified Namespace: DAV: Purpose: ヘッダを受け入れないGETのレスポンスにおいて、Last-Modifiedヘッダの内容を含む。 Description :リソースのlast-modified の日付は、リソースの状態のあらゆる部分の変更（された時間）を反映しても良く、必ずしもGETメソッドのレスポンスに対する変更がともなわないことに注意しうてほしい。例えば、プロパティの内容の変更は、last-modified の値の変更をを引き起こしてもよい。getlastmodified プロパティは、GETのレスポンス中に Last-Modified ヘッダを含むDAV準拠リソースにおいて定義されなければならない。 Value: HTTP-date；[RFC2068]のセクション3.3.1にて定義される 13.8 lockdiscovery プロパティ Name: lockdiscovery Namespace: DAV: Purpose: リソースにおいてアクティブなロックを記述する Description: lockdiscoveryプロパティは、誰がロックを持っているか、ロックのタイプはどんなものか、タイムアウトのタイプとタイムアウトまでの残り時間、そして関連するロックトークンを記述する。主体がリクエストしたデータへのアクセス権を有さない場合には、サーバは、任意（もしくは全て）の情報を与えないことができる。 13.8.1 lockdiscovery プロパティ検索の例 >>Request PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Length: xxxx Content-Type: text/xml; charset="utf-8" >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.foo.bar/container/ 0 Jane Smith Infinite opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 HTTP/1.1 200 OK 　このリソースは、タイムアウト値が無限であり、排他的な単一の書き込みロックをかけられている。 13.9 resourcetype プロパティ Name: resourcetype Namespace: DAV: Purpose: リソースの種類を指定する。 Description: resourcetypeプロパティは、全てのDAV準拠のリソースで定義されなければならない。デフォルト値は空である。 13.10 source プロパティ Name: source Namespace: DAV: Purpose: ソース・リンクのデスティネーションは、リンク元を生成するための未処理のソース（プログラム）を含むリソースを識別する。 Description: リンクのソース(src)は一般的にリンクが定義される出力されたリソースのURIである、そして、典型的にはリンクの一つのデスティネーション(dst)だけがある。そして、それはリソースの未処理のソース（プログラム）がアクセスされてもよいURIである。1つ以上のリンクデスティネーションが存在するとき、この仕様は順序について何のポリシーもない。 13.10.1 sourece プロパティの例 Source http://foo.bar/program http://foo.bar/src/main.c Library http://foo.bar/program http://foo.bar/src/main.lib Makefile http://foo.bar/program http://foo.bar/src/makefile 　この例においては、リソース http://foo.bar/program は、3つのリンクを含むsource プロパティを持っている。各リンクは、3つのエレメントを持っており、3つのうち2つのエレメント src,dst は、この文書において定義されているDAVスキーマの一部である。そして、1つは、スキーマ http://www.foocorp.com/project/ （Source, Library,そして Makefile）にて定義される。DAVで定義されるエレメントのみが実装されたクライアントは、foocorpエレメントは解釈できないため無視される。結果として、クライアントはソースとデスティネーションリンクを見ることになる。拡張されたクライアントは、foocorpエレメントを知っていることがあり、ユーザに対してリンクに関する追加情報を提供できる。この例においては、XMLのマークアップ力や、古いクライアントを誤動作させることなくエレメントの拡張を許すことのサンプルである。 13.11 supportedlockプロパティ Name: supportedlock Namespace: DAV: Purpose: リソースでサポートされているロック機能の一覧を提供する。 Description: リソースのsupportedlockプロパティは、リソースでロック・リクエストにおいて指定される範囲とアクセス・タイプの組合せのリストを返す。実際の内容は、アクセスコントロールによって制御され、その時サーバはクライアントが認証されないという情報提供を要求されないことに注意すべきである。 13.11.1 supportedlock プロパティ検索の例 >>Request PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Length: xxxx Content-Type: text/xml; charset="utf-8" >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.foo.bar/container/ HTTP/1.1 200 OK 14. DAVでXMLを処理するためのコマンド 全てのDAV準拠のリソースは、その命令言語としてXMLを使うDAVメソッドを処理する間、エレメントと全てのその子たちが遭遇した任意の未知のXMLを無視しなければならない。 　この制限は、クライアント処理にもDAVプロパティ値にもあてはまる。プロパティのスキーマが他の手段で宣言されない限り、未知のXMLエレメントを無視すべきである。 　この制限は、未知のXMLエレメントを保存しなければならないサーバ上にDead DAV プロパティを設定する場合には当てはまらない。 　さらに、この制限はXMLがエンティティボディのコンテントタイプとして現れるような場合にはあてはまらない。例えば、PUTのボディにXML言語が現れるような場合が考えられる。 　XMLは、text/xmlもしくはapplication/xmlのタイプとして転送されるため、DAVサーバは、XMLによるパラメータ指定が行われるDAVメソッドのリクエストをtext/xml もしくは application/xml のタイプとして受け入れなければならない。そして、DAVクライアントは、XMLレスポンスを text/xml もしくは application/xml のタイプとして受け入れなければならない。 15. DAV準拠クラス DAV準拠したリソースは、の2つの準拠クラスを選択可能である。 　クライアントはリソースに対してOPTIONSメソッドを発行し、返却される"DAV"ヘッダをチェックすることで、リソースの準拠クラスを知ることができる。 　この文書は、HTTP/1.1に対する拡張を記述しているため、全てのDAV準拠リソースやクライアント、プロキシは[RFC2068]に準拠している必要がある。 　準拠クラスは、必ずしも連続である必要はない。クラス2に準拠するリソースは、クラス1に準拠してなければならないが、後に追加して準拠クラスが定義された場合、クラス1,2,4に準拠したリソースがクラス3にも準拠していなくてもよい。また、数字以外のクラス識別子が使われる可能性があることにも注意すべきである。 15.1 クラス1 　クラス1準拠のリソースは、本文書の全セクションのうち、"MUST"とされている要求を満たさなければならない。 　クラス1準拠のリソースは、OPTIONSメソッドで返却されるDAVヘッダに"1"という値を最低限返却しなければならない。 15.2 クラス2 最低限(OPTIONSメソッドに対する全てのレスポンスのDAVヘッダでの値"1"と"2")で、クラス2つのに準拠したリソースは、返らなければならない。 　クラス2準拠のリソースは、全てのクラス1の要求に加え、LOCKメソッドのサポート、supportedlockプロパティ、lockdiscoveryプロパティ、Time-Outレスポンスヘッダ、LockToken リクエストヘッダのサポートを行う必要がある。また、クラス"2"準拠のリソースは、さらにTime-Outリクエストヘッダおよびowner XMLエレメントもサポートしなければならない。 　クラス2準拠のリソースは、OPTIONSメソッドで返却されるDAVヘッダに値"1","2"を最低限含まなければならない。 16 国際化の考慮 　国際化の分野では、本仕様は IETF Character Set Policy[RFC2277] に準拠する。 　本仕様では、人間の可読フィールドは、プロパティ値もしくはレスポンスエンティティ中に現れるエラーメッセージとして現れる。どちらの場合も、人間が可読な内容はXMLを用いてエンコードされており、その中では明示的に文字セットタグ付与とエンコーディングが提供されている。そして、XMLエレメントを読み込むXMLプロセッサは、最低限ISO 10646 多言語空間のUTF-8[UTF-8]エンコードを読み込める必要がある。この仕様の中でのXMLの例は、XML"encoding"属性と同じように、[RFC2376]で定義されているような Content-Type の文字セットの仕様を使用して記述している。そして、この属性は、MIMEやXMLプロセッサに文字セットの情報を提供する時にも使用される。 　XMLは、特定のXMLエレメントの内容で使用されている言語を特定するために、言語タギングの機能も提供する。XMLは、IANAに登録された言語タグ([RFC1766]を参照のこと)もしくはISO639言語タグ([ISO-639]を参照のこと)を XMLエレメント中の"xml:lang"属性で使用し、言語の内容と属性を指定する。 　WebDAVアプリケーションは、文字セットタギング機能、文字セットのエンコーディング、そしてXMLの仕様における言語タギングの機能をサポートしなければならない。WebDAVアプリケーションの実装を行う際には、XMLの転送時に使用するMIME メディアタイプの指定やContent-Typeヘッダの文字セットパラメータを使用にあたり、"XML Media Types"[RFC2376]を読むことを奨励する。 　本仕様の範囲内で使われる名前は、3つのカテゴリに分類される。 　メソッドやヘッダのようなプロトコルエレメント名、XMLエレメント名、そしてプロパティ名がそれである。プロトコルエレメントの命名については、HTTPの先例に従い、メソッドやヘッダにはUSASCIIエンコードされた英語名が仕様される。これらのプロトコルエレメントは、ユーザには見えず、実際には単に長い予約識別子であるため、これらについては複数の文字セットによるエンコードはサポートされない。同様に、本仕様の中で使用されているXMLエレメント名についてもUTF-8でエンコードされた英語名が用いられるが、これらの名前もユーザには見えないため、結果として複数の文字セットエンコーディングはサポートの必要はない。 　リソースで定義されるプロパティ名はURIである。アプリケーションの中にはプロパティのURIを直接ユーザに見せるものがある（例：汎用のプロパティビューア）が、典型的なアプリケーションは、プロパティ名をユーザに対して見せるときには、決まったプロパティのセットを使用し、プロパティ名のURIを人間が読むことのできるフィールドに対応付けることが期待されている。これは、プロパティのセットがアプリケーションがプロパティ名のURIをユーザに見せる必要がある時より前にプロパティセットは知られていない場合のみである。アプリケーションは、可能な限りユーザが読めるプロパティ名を提供することが推奨される。 　エラーレポーティングについては、各ステータス・コードでコードの短い、英語の記述を含むHTTP/1.1のステータス・コードの慣例を踏襲している（例：423(Locked)）。貧弱な実装のユーザエージェントは、このようなメッセージをそのままユーザに提示するい一方、国際化されたアプリケーションはこのようなメッセージは無視してユーザの使用する言語や文字セットに応じて適切なメッセージを表示する。 　クライアントとサーバの相互運用は、地域情報を必要としないため、本仕様ではこのような情報を転送するためのいかなるしくみも規定しない。 17 セキュリティの重要性 　このセクションは、WebDAV アプリケーションが必要とするセキュリティに 関連して気をつけなければならないことについて詳細を述べる。 　HTTP/1.1 （RFC2068）およびXML（RFC2068）に関連した全てのセキュリテ ィの重要性については、全て WebDAV にもあてはまる。それらに加え て、リモートオーサリングにおける固有のセキュリティ上のリスクに対処する 意味で、強力な認証技術が必要とされている。また、貧弱なサーバデザインに より危険は増大する。 　以後、これらのことについて述べさせていただく。 17.1 クライアント認証 　オーサリングに重点を置くことにより、WebDAVサーバはネットワーク リソースやリソースの完全性を保護するために認証技術を使用する必要 がある。さらに、ロックについては認証のサポートを必要とする。 　セキュアでない回線を通じてパスワードがクリアテキストで送られる ようなことは、パスワードが途中で盗聴されることを考えるとアクセス 保護やリソースの完全性を保証する上で非常に不適当なことである。 HTTP/1.1による認証については、パスワードの転送をクリアテキストで 実施するため、コネクションがセキュアでない場合には WebDAV クライ アントの認証に使用してはならない。コネクションがセキュアでない場 合には、WebDAVサーバもWWW-Authenticateヘッダ内にベーシック認証の クレデンシャルを入れて送ってはならない。セキュアなコネクションの 例ととしては、TLS コネクション上が開設された上での強力な暗号化実 装を用いたサーバとクライアントの相互認証が挙げられる。もしくは、 入場制限された建物の中に構築された、物理的に分離されたネットワー ク等がセキュアなネットワークの例として挙げられる。 　WebDAV アプリケーションは、ダイジェスト認証(RFC2069)をサポート しなければならない。というのも、ダイジェスト認証はお互いが同じ秘 密情報（パスワード）を持っていることを、クリアテキストによる秘密 情報の送信なしで確認する方法なので、認証段階でダイジェスト認証を 使うことによって、ベーシック認証の持つ問題を回避することが可能で ある。また、この方法は広い範囲で応用をきかせることが可能である。 17.2 Denial of Service 　DoS アタックは、WebDAVサーバについて特に考慮する必要がある。 　WebDAV + HTTP は、システムリソースのあらゆる個所に対するアタックを 可能にする。 　ストレージについては、非常に大きなファイルを PUT されることでアタッ クされる。 　多くの（巨大な）コレクションに対する再帰的な操作要求（PROPFIND等） は、処理時間にアタックされる。 　複数のコネクションでのパイプライン状のリクエストは、ネットワークコ ネクションリソースに対するアタックになる。 　WebDAV サーバは、全てのレベルにおいて DoS アタックの可能性を考慮す る必要がある。 17.3 Security through Obscurity 　WebDAV は、PROPFIND メソッドを通じてコレクションに含まれるリソースの 一覧を取得できる機能を提供する。この機能は、セキュリティの効果を薄れ させたり、ネットワークリソースの隠蔽をしてる効果を小さくしたりする。 　WebDAVサーバのユーザについては、相対的にわかりにくい名前をリソース名 としてつけてリソース隠蔽を計るよりは、リソースに対する不要なアクセスを させないためにアクセスコントロールを使用することを奨励する。 17.4 LOCK に直結するプライバシの問題 　LOCKリクエストを送信する場合、ユーザエージェントは XML データにオーナ 情報を載せて送信する。この情報は、リソースのlockdiscoveryプロパティに記 録され、他の共同作業社がリソースアクセスネゴシエーションを開始した時に 使用される。しかしながら、多くのケースにおいてこのコンタクト情報は非常に プライベートなものであり、広い範囲で流れては困るものである。サーバは適 切な手段で lockdiscovery プロパティに対する読み取り制限をかけるべきで ある。さらに、ユーザエージェントはコンタクト情報を送るべきかどうかにつ いて制御できなくてはならず、もし送られるのであれば、どのような情報が送 られるのかを制御できなくてはならない。 17.5 プロパティに直結したプライバシ問題 　プロパティの値は、典型的にはドキュメントの著者のような情報を保持す るために使われる。しかし、これはプライバシ情報がリソースプロパティよ り広い範囲で読み取られる可能性がある。このように、プロパティを経由し た無意識のプライベート公開のリスクを減らすには、サーバ側でリソースボ ディの読み取り制限とプロパティの読み取り制限を個別にかけられることが 奨励されている。このようにすることで、リソースの本体そのものに過剰な 制限をかけることなく、プロパティ情報の（不要な）拡散を制御することが 可能となる。 17.6 Source Link によるセキュリティの縮小 　HTTP/1.1は、それがセンシティブな情報を含んでいる可能性を考慮して、 スクリプト・コードへの読み取りアクセスを提供することについて警告し ている。しかしながら、WebDAV は Source Link 機能を経由して、潜在的 にスクリプトリソースを編集できるような URI を提供します。HTTP/1.1 においては、リードオンリーアクセスであるが故にソースリソースに対す るアクセスは回避される。WebDAV については、ソースリソースに対する 読み書きアクセスが可能であり、リソースを特定するための Source Link 機能を提供する。このことは、ソースリソースに対してのアクセスを制限 することにより確保されている（はずの）セキュリティが保たれなくなる ということを意味する。WebDAV サーバのユーザと管理者は、スクリプトの リモートオーサリングを実施するときには特に注意を払い、ソースリソー スに対する読み書きアクセスは認証された権限でのみ可能にするよう制限 しなければならない。 17.7 Implications of XML External Entities 　XML は、[REC-XML] の 4.2.2 にて定義されている External Entities として知られる機能をサポートしている。これはXMLプロセッサに対して 特定のURIに配置された XML をインラインに含むように指示する機能だが、 これを利用することで、外部のXMLエンティティを用いてドキュメントタイ プの定義（DTD）を追加／変更することが可能になる。外部のXMLエンティ ティは、XMLドキュメントの中にXMLを含めるためにも使用される。この規 定の中で使用されるXMLのように、有効にしないXMLについては、外部のXML エンティティを含むことが[REC-XML] によって要求されない。しかしなが ら、[REC-XML] は、XMLプロセッサーが分類処理を実施する際に、外部の XML実体を含むかもしれないと知らせる。 　外部のXMLエンティティは、（呼び出し元から）何の信頼も引き継がない。 そして、あらゆる HTTP GET リクエストに特有のアタックの影響を受けや すい。 　さらに、外部のXMLエンティティは、DTDを変更することが可能であり、 結果としてXMLドキュメントの最終的な形式に影響を与える。最悪の場合、 そのXMLのセマンティクスを変更し、XMLプロセッサを [RFC2376] で議論 されているようなセキュリティ上の危険にさらすことになる。結果として、 実装を行う際には、外部のXMLエンティティを信用できないものとして扱 うように注意する必要がある。 　また、このリスクは、外部のXMLエンティティを使用するアプリケー ションを広く展開した際に伴って拡大するリスクでもある。このような 場合、1つの外部のXMLエンティティに対する著しい数のリクエストが発 生することは充分考えられ、この場合、潜在的にあらゆるサーバに対し て外部XMLエンティティを含むリソースに対するリクエストにともなう 過負荷を引き起こす。 17.8 Lock Token に直結したリスク 　セクション6.4にもあるように、ロックトークンを生成するためには Universal Unique Identifier（UUID）を必要とする。これは、ロック トークンがユニークであるということを保証するために必要なことであ る。UUID は [ISO-11578] にて定義されているように、IEEEアドレス （通常はホストアドレス）からなる"node"フィールドを含む。複数の IEEE802アドレスを持つシステムにおいては、いずれも使用可能である。 　WebDAV サーバは、稼動している間に多くのロックを扱うが、このこ とはそのサーバが持つIEEEアドレスを公にするという意味をも持つ。 　IEEE802アドレスがわかることにより、いくつかのリスクが考えられ る。例えば、IEEE802アドレスを用いることで… * サブネット間のハードウェアの挙動を追跡することが可能。 * WebDAVサーバのハードウェアベンダを特定することが可能。 * WebDAVサーバが稼動している各タイプのコンピュータの数を決定 　することが可能かもしれない。 　セクション6.4.1では、UUID の "node"フィールドを決定するにあ たってIEEE802アドレスを使用しない方法を述べている。この方法を使 うことによって、IEEE802アドレスが公になるリスクを軽減している。 18 IANA Considerations この文書は、プロパティ名の名前空間と、プロパティ値の範囲内で使用される WebDAVに特有のXMLエレメントの名前空間の2つの名前空間を定義する。 いくつかの理由のために、URIが両方の名前のために使われる。URIの任務は、権威に名をつけている本部へのリクエストを要求しなくて、それゆえに、任意のWebDAVユーザーまたはアプリケーションによって速く定義されるためにWebDAVプロパティ名とXMLエレメントを認めない。URIも固有のアドレス空間を提供する。そして、WebDAVの分散されたユーザーがプロパティ名前の中の衝突とそれが作成するXMLエレメントを持っていないことを確実にする。 この仕様は、プロパティ名前の優れたセットと全てのWebDAVアプリケーションで理解されるXMLエレメントを定義する。この仕様の中のプロパティ名前とXMLエレメントは(例えばDAV)、ベースURI DAV：接尾辞をこのURIにそばに加えることにすっかり由来してある："creationdate"プロパティのためにcreationdateする。 この仕様もロック・トークンをコード化するためにURIスキームを定義する。そして、opaquelocktoken URIスキームがセクション6.4において記述される。 この仕様に基づく正しいinteroperationにIANA不可欠を保証することは、この仕様、その改訂と関係するWebDAV仕様によって使用法のために"opaquelocktoken:"で"DAV: "andから始めているURI名前空間を予約する。 19 知的なプロパティ 以下の注意は、RFC 2026 [ RFC2026 ](セクション10.4)からコピーされて、この文書に対してされる知的所有権要求に関して、IETFの位置を記述する。 IETFは、正当性に関する位置またはインプリメンテーションまたは使用法もう一方に付随すると主張されるかもしれない任意の知的なプロパティまたはもう一方権利の範囲にこの文書で記述されるテクノロジーまたはそのような権利の下の任意の許可が利用できるかもしれないか、利用できないかもしれない範囲を持っていかない；そして、それはそれがそのような任意の権利を識別する任意の努力をしたと述べない。standards-trackと標準に関連したドキュメンテーションでの権利に関するIETFの手続きに関する情報は、BCP-11で見いだされることができる。権利の要求のコピーは作った作られる免許の出版物と任意の保証のために利用できる可能な、あるいは、一般的な許可を得るために作られる試みまたはインプリメンタによるそのような所有権またはこの仕様のユーザーの使用法のための許可の結果はIETF事務局から得られることができる。 IETFは、任意の著作権、特許または特許アプリケーションまたはそれが要求されてもよいテクノロジーをカバーしてもよいもう一方所有権が行うその注意を引くように示す任意の興味を持っているパーティーを招くこの標準。IETFに情報をアドレッシングします‖専務取締役。 20 Acknowledgements これのような仕様は、冷淡な怠慢から刺し通す批評の批評と肩甲骨間の隆起によって成育する。著者は、感謝して洞察が我々の仕事のあらゆる舞台でそれほど価値があった以下の人々の貢献を認める。 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. このリストからの2は、特別な言及に値する。専門調査委員会の編成を助けることにおいて、そして、手段に沿って著者を根気よくコーチすることにおいて、ラリーMasinterによる投稿は、かけがえのなかった。それほど多くの手段では、彼は我々が持っている高い標準が会うために骨を折って働いたセットを持っている。そして、草案の後、草案を根気よく批評することにおいて、要求を明らかにすることでのジュディスSleinの貢献は、この仕様を改善して、文書管理に関して我々の心を広げた。 我々は、また、ジョン・ターナーにXML DTDを開発することに対して感謝するのが好きになろうとする。 21 References 21.1 Normative References [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [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-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/ [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. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [ISO-639] ISO (International Organization for Standardization). ISO 639:1988. "Code for the representation of names of languages." [ISO-8601] ISO (International Organization for Standardization). ISO 8601:1988. "Data elements and interchange formats - Information interchange - Representation of dates and times." [ISO-11578] ISO (International Organization for Standardization). ISO/IEC 11578:1996. "Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)" [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, January 1998. 21.2 Informational References [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996. [RFC1807] Lasher, R. and D. Cohen, "A Format for Bibliographic Records", RFC 1807, June 1995. [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 [USMARC] Network Development and MARC Standards, Office, ed. 1994. "USMARC Format for Bibliographic Data", 1994. Washington, DC: Cataloging Distribution Service, Library of Congress. [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. [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. [RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin Core Metadata for Resource Discovery", RFC 2413, September 1998. [RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, July 1998. 22 著者のアドレス Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: yarong@microsoft.com E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 EMail: ejw@ics.uci.edu 23のAppendices 23.1 付録1(WebDAV文書型定義) プロトコル流れで使われるXMLエレメントのために、そして、プロパティの値において規則に中で[ REC-XML ]従って、このセクションは、文書型定義を提供する。それは、セクション12と13において与えられる要素定義を集める。 Goland, et al. Standards Track [Page 86] RFC 2518 WEBDAV February 1999 ]> 23.2 Appendix 2(ISO 8601人の日付とTime Profile) creationdateなプロパティは、ISO 8601の日付表示形式[ ISO-8601 ]の使用法を指定する。このセクションは、この仕様の用途に、ISO 8601の日付表示形式のプロフィールを定義する。このプロフィールは、クリス・ニューマンによるインターネット-Draftから引用されて、正しく彼の仕事を帰するためにここで言及される。 date-time = full-date "T" full-time full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset 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 partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] 数のオフセットは、UTC(Universal Timeをコーディネートした)なしで現地時間として計算される。それで、UTCの中の等しい時間は、オフセットを現地時間から減ずることによって決定されることができる。例えば、18：50：00-は、04:00、22：58：00Zと同じ時間である。 中で時間ならばUTCは知られている、しかし、現地時間の埋め合わせは未知である、これは「-00：00」のオフセットで表されることができる。これは、UTCが指定された時間の間の好まれた参照点であることを意味する「Z」のオフセットと異なる。 23.3 Appendix 3(XML ElementsをProcessingすることのNotes) 23.3.1 空のXMLエレメントについての注釈 XMLは、2台のメカニズムをXMLエレメントが任意のコンテントを持っていないことを示すことに対してサポートする。第一は、形式のXMLエレメントを宣言することになっている。第二は、形式のXMLエレメントを宣言することになっている。2つのXMLエレメントは、意味論的に同一である。 それは、関連するDTDが要素がEMPTYであると断言するならば、が作り上げる使用法へのXML仕様の違反である(<に例えば！ELEMENT A EMPTY>)。そのような声明が含まれる、(それから空の要素フォーマット)、が、使われなければならない。要素がEMPTYであると断言されないならば、形式かが空の要素のために使われてもよい。 23.3.2 イリーガルなXML処理のノート XMLは、法的に見えるが、実際あるデータを提出することを簡単にする柔軟なデータ・フォーマットである。哲学のまだ「あなたがアクセプトするものにおいて柔軟であなたが送るものにおいて厳しい」、それが不適当に適用されてはならないことを適用する。XMLは、ホワイトスペース、要素順序、挿入している新しい要素、その他の問題を扱う際にとても柔軟である。特に要素を意味することではでない、この柔軟性は、拡張を要求しない。 XMLエレメントのイリーガルな組合せをアクセプトすることでの親切が、ない。せいぜい、それは不必要な結果を引き起こす、そして、最悪の場合で、それは本当の損害を引き起こすことがありえる。 23.3.2.1 XML Syntax Error の例 PROPFINDメソッドのための以下のリクエスト・ボディは、イリーガルである。 propfind要素の定義は、要素(両方とも)をallpropまたはpropnameのために認めるだけである。このように、上記はエラーであって、応答されなければならないで400(悪いRequest)。 サーバーが「親切な」ことを望んで、本当のエレメントとしてのallpropエレメントを選んで、それに応答することに決めたとしかし想像しなさい。 サーバーが命令をallpropとみなすならば、propnameを実行するつもりだったバンド幅限られた線に広まっているクライアントが大きい驚きのためににおいてあろうとする。 その上に、サーバーが寛大で、このリクエストに返事をすることに決めるならば、allpropディレクティブ、その他を実行している若干のサーバーで、propnameディレクティブを実行して、結果はサーバーにランダムにサーバーからそれようとする。これは、それを増やすことよりむしろインターオペラビリティを減らす。 23.3.2.2 未知のXML 要素の例 それが明確にpropfind要素の中に一緒に現れるのを禁止された2つの要素を含んだので、前の例はイリーガルだった。しかし、XMLは拡大可能な言語であるので、人はpropfindの用途に、定義されている新しい要素を想像することができる。下記は、PROPFINDのリクエスト・ボディであって、前の例の様に、拒絶されなければならないで400(悪いRequest)expired-props要素を理解しないサーバーによって。 理由を理解する400(悪いRequest)そうさせられて返す我々expired-propsに慣れていないサーバーがそれを見るので、リクエスト・ボディを見る。 サーバーが期限切れになられた支え要素を理解しないので、それはそれを無視しなければならない。と、WebDAVに特有のXML処理に従って、規則がセクション14において示した。このように、サーバーは空のpropfindを見る。そして、propfind要素の定義によるそれはイリーガルである。 それが拡張を持っていた点に注意します‖それが必ずしも終わろうとするというわけではなかった添加物にある400(悪いRequest)。例えば、以下のリクエストをPROPFINDのためのボディと想像する： *boss* 前の例は、架空の要素leave-outを含む。その目的は、名前が提出されたパターンにマッチする任意のプロパティで戻りのものを防ぐことになっている。前の例がleave-outに慣れていないサーバーに提出されるならば、唯一の結果はleave-out要素が無視されようとするということで、そして、propnameが実行されようとするということであろうとする。 23.4 Appendix 4(WebDAVのためのXML Namespaces) 23.4.1 紹介 MUSTがXML名前空間拡張を支持するに準拠したシステムが明記した[ REC-XML NAMES ]全てのDAV。 23.4.2 修飾された名前の意味 [読者への手紙：このセクションは、中に[ REC-XML NAMES ]現れないしかし、WebDAV XMLプロセッサのために曖昧さを避けるために必要である。] に準拠したXMLプロセッサMUSTが名前空間にLocalPartを追加して、修飾された名前を構成されるURIと解釈するWebDAVは、URIに名をつける。 例 Johnny Updraft この例では、資格を与えられた要素名前「del：グライダー」は、URL「http://www.del.jensen.org/glider」と解釈される。 Johnny Updraft たとえこの例が構文的に前の例と異なるとしても、それは意味論的に同一である。名前空間名前「バー」の各例は、「http://www.del.jensen.org/"」と取り替えられて、それから各要素タグのローカル名前に追加される。結果として生じるタグ名は、この例では前の例に関しての正確に同じものである。 Johnny Updraft この例は、2人の前の人に意味論的に同一である。 名前空間名前「foo」の各例は、それから各要素タグのローカル名前に追加される、結果として生じるタグ名が同一である「http://www.del.jensen.org/glide"」と取り替えられる前の例でそれら。 24. Full Copyright Statement 版権を有する(C)Theインターネット学会(1999)。著作権所有。 それのこの文書と翻訳はコピーされてもよくて、他の人に与えられてもよい、そして、コメントするか、一方それを説明するか、そのインプリメンテーションを援助する、いかなる種類の制限なしで上記の著作権注意とこのパラグラフが全てのそのようなコピーと派生的な作品の上で含まれるならば、全体または一部の派生的な作品が、コピーされて、発行されて、分散されて、準備されてあってもよい。しかし、この文書は、著作権の手続きがインターネットStandardsプロセスにおいて定義したケースが続かれなければならないインターネット標準を開発する目的で必要な場合を除いて、著作権注意またはインターネット学会またはもう一方インターネット組織の参照を削除することによってどんな形であれ、例えば修正されてはならない必要に応じてそれを英語以外の言語に翻訳するために、あるいは。 同意される限られた許可は、永久で、インターネット学会またはその後継者によって無効にされない、あるいは、受託者。 これは、文書化する、そして、ここで含まれる情報は、提供される「AS IS」基礎、そして、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.