Network Working Group G. Clemm Request for Comments: 3253 Rational Software Category: Standards Track J. Amsden T. Ellison IBM C. Kaler Microsoft J. Whitehead U.C. Santa Cruz March 2002 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract 　 このドキュメントは、HTTP/1.1プロトコルに対するWebDAV(Web Distributed 　 Authoring and Versioning)のバージョニング拡張メソッドやヘッダやリソース 　 タイプのセットを規定する。WebDAVによるバージョニングは、WebDAVバージョ 　 ニングサービスを利用することができるアプリケーションが広範囲の普及する 　 ように、さまざまなバージョニングリポジトリマネージャとの相互運用能力を 　 持たせるクライアントの複雑さを最小限にしている。WebDAVのバージョニング 　 は、バージョニングを意識しないクライアントやversion historyの管理、 　 workspaceの管理、baselineの管理、activityの管理、URL名前空間のバージョ 　 ニングのための自動的なバージョニングを含んでいる。 Table of Contents 1 Introduction.................................................... 6 1.1 Relationship to WebDAV........................................ 7 1.2 Notational Conventions........................................ 8 1.3 Terms......................................................... 8 1.4 Property Values............................................... 11 1.4.1 Initial Property Value..................................... 11 Clemm, et al. Standards Track [Page 1] RFC 3253 Versioning Extensions to WebDAV March 2002 1.4.2 Protected Property Value................................... 12 1.4.3 Computed Property Value.................................... 12 1.4.4 Boolean Property Value..................................... 12 1.4.5 DAV:href Property Value.................................... 12 1.5 DAV Namespace XML Elements.................................... 12 1.6 Method Preconditions and Postconditions....................... 12 1.6.1 Example - CHECKOUT request................................. 13 1.7 Clarification of COPY Semantics with Overwrite:T.............. 13 1.8 Versioning Methods and Write Locks............................ 14 2 Basic Versioning Features....................................... 14 2.1 Basic Versioning Packages..................................... 14 2.2 Basic Versioning Semantics.................................... 16 2.2.1 Creating a Version-Controlled Resource..................... 16 2.2.2 Modifying a Version-Controlled Resource.................... 17 2.2.3 Reporting.................................................. 19 3 Version-Control Feature......................................... 20 3.1 Additional Resource Properties................................ 20 3.1.1 DAV:comment................................................ 20 3.1.2 DAV:creator-displayname.................................... 20 3.1.3 DAV:supported-method-set (protected)....................... 20 3.1.4 DAV:supported-live-property-set (protected)................ 21 3.1.5 DAV:supported-report-set (protected)....................... 21 3.2 Version-Controlled Resource Properties........................ 21 3.2.1 DAV:checked-in (protected)................................. 21 3.2.2 DAV:auto-version........................................... 22 3.3 Checked-Out Resource Properties............................... 22 3.3.1 DAV:checked-out (protected)................................ 23 3.3.2 DAV:predecessor-set........................................ 23 3.4 Version Properties............................................ 23 3.4.1 DAV:predecessor-set (protected)............................ 23 3.4.2 DAV:successor-set (computed)............................... 23 3.4.3 DAV:checkout-set (computed)................................ 23 3.4.4 DAV:version-name (protected)............................... 24 3.5 VERSION-CONTROL Method........................................ 24 3.5.1 Example - VERSION-CONTROL.................................. 25 3.6 REPORT Method................................................. 25 3.7 DAV:version-tree Report....................................... 26 3.7.1 Example - DAV:version-tree Report.......................... 27 3.8 DAV:expand-property Report.................................... 29 3.8.1 Example - DAV:expand-property.............................. 30 3.9 Additional OPTIONS Semantics.................................. 31 3.10 Additional PUT Semantics..................................... 31 3.11 Additional PROPFIND Semantics................................ 32 3.12 Additional PROPPATCH Semantics............................... 33 3.13 Additional DELETE Semantics.................................. 33 3.14 Additional COPY Semantics.................................... 34 3.15 Additional MOVE Semantics.................................... 34 3.16 Additional UNLOCK Semantics.................................. 35 Clemm, et al. Standards Track [Page 2] RFC 3253 Versioning Extensions to WebDAV March 2002 4 Checkout-In-Place Feature....................................... 35 4.1 Additional Version Properties................................. 35 4.1.1 DAV:checkout-fork.......................................... 36 4.1.2 DAV:checkin-fork........................................... 36 4.2 Checked-Out Resource Properties............................... 36 4.2.1 DAV:checkout-fork.......................................... 36 4.2.2 DAV:checkin-fork........................................... 37 4.3 CHECKOUT Method............................................... 37 4.3.1 Example - CHECKOUT......................................... 38 4.4 CHECKIN Method................................................ 38 4.4.1 Example - CHECKIN.......................................... 40 4.5 UNCHECKOUT Method............................................. 40 4.5.1 Example - UNCHECKOUT....................................... 41 4.6 Additional OPTIONS Semantics.................................. 42 5 Version-History Feature......................................... 42 5.1 Version History Properties.................................... 42 5.1.1 DAV:version-set (protected)................................ 42 5.1.2 DAV:root-version (computed)................................ 42 5.2 Additional Version-Controlled Resource Properties............. 42 5.2.1 DAV:version-history (computed)............................. 43 5.3 Additional Version Properties................................. 43 5.3.1 DAV:version-history (computed)............................. 43 5.4 DAV:locate-by-history Report.................................. 43 5.4.1 Example - DAV:locate-by-history Report..................... 44 5.5 Additional OPTIONS Semantics.................................. 45 5.6 Additional DELETE Semantics................................... 46 5.7 Additional COPY Semantics..................................... 46 5.8 Additional MOVE Semantics..................................... 46 5.9 Additional VERSION-CONTROL Semantics.......................... 46 5.10 Additional CHECKIN Semantics................................. 47 6 Workspace Feature............................................... 47 6.1 Workspace Properties.......................................... 48 6.1.1 DAV:workspace-checkout-set (computed)...................... 48 6.2 Additional Resource Properties................................ 48 6.2.1 DAV:workspace (protected).................................. 48 6.3 MKWORKSPACE Method............................................ 48 6.3.1 Example - MKWORKSPACE...................................... 49 6.4 Additional OPTIONS Semantics.................................. 49 6.4.1 Example - OPTIONS.......................................... 51 6.5 Additional DELETE Semantics................................... 51 6.6 Additional MOVE Semantics..................................... 52 6.7 Additional VERSION-CONTROL Semantics.......................... 52 6.7.1 Example - VERSION-CONTROL.................................. 53 7 Update Feature.................................................. 53 7.1 UPDATE Method................................................. 53 7.1.1 Example - UPDATE........................................... 55 7.2 Additional OPTIONS Semantics.................................. 55 8 Label Feature................................................... 56 Clemm, et al. Standards Track [Page 3] RFC 3253 Versioning Extensions to WebDAV March 2002 8.1 Additional Version Properties................................. 56 8.1.1 DAV:label-name-set (protected)............................. 56 8.2 LABEL Method.................................................. 56 8.2.1 Example - Setting a label.................................. 58 8.3 Label Header.................................................. 58 8.4 Additional OPTIONS Semantics.................................. 59 8.5 Additional GET Semantics...................................... 59 8.6 Additional PROPFIND Semantics................................. 59 8.7 Additional COPY Semantics..................................... 60 8.8 Additional CHECKOUT Semantics................................. 60 8.9 Additional UPDATE Semantics................................... 61 9 Working-Resource Feature........................................ 62 9.1 Additional Version Properties................................. 62 9.1.1 DAV:checkout-fork.......................................... 62 9.1.2 DAV:checkin-fork........................................... 63 9.2 Working Resource Properties................................... 63 9.2.1 DAV:auto-update (protected)................................ 63 9.2.2 DAV:checkout-fork.......................................... 63 9.2.3 DAV:checkin-fork........................................... 63 9.3 CHECKOUT Method (applied to a version)........................ 63 9.3.1 Example - CHECKOUT of a version............................ 65 9.4 CHECKIN Method (applied to a working resource)................ 65 9.4.1 Example - CHECKIN of a working resource.................... 66 9.5 Additional OPTIONS Semantics.................................. 67 9.6 Additional COPY Semantics..................................... 67 9.7 Additional MOVE Semantics..................................... 67 10 Advanced Versioning Features.................................. 67 10.1 Advanced Versioning Packages................................. 68 10.2 Advanced Versioning Terms.................................... 68 11 MERGE Feature................................................. 70 11.1 Additional Checked-Out Resource Properties................... 70 11.1.1 DAV:merge-set............................................. 70 11.1.2 DAV:auto-merge-set........................................ 71 11.2 MERGE Method................................................. 71 11.2.1 Example - MERGE........................................... 74 11.3 DAV:merge-preview Report..................................... 75 11.3.1 Example - DAV:merge-preview Report........................ 76 11.4 Additional OPTIONS Semantics................................. 77 11.5 Additional DELETE Semantics.................................. 77 11.6 Additional CHECKIN Semantics................................. 77 12 Baseline Feature.............................................. 77 12.1 Version-Controlled Configuration Properties.................. 78 12.1.1 DAV:baseline-controlled-collection (protected)............ 78 12.2 Checked-Out Configuration Properties......................... 78 12.2.1 DAV:subbaseline-set....................................... 78 12.3 Baseline Properties.......................................... 78 12.3.1 DAV:baseline-collection (protected)....................... 79 12.3.2 DAV:subbaseline-set (protected)........................... 79 Clemm, et al. Standards Track [Page 4] RFC 3253 Versioning Extensions to WebDAV March 2002 12.4 Additional Resource Properties............................... 79 12.4.1 DAV:version-controlled-configuration (computed)........... 79 12.5 Additional Workspace Properties.............................. 80 12.5.1 DAV:baseline-controlled-collection-set (computed)......... 80 12.6 BASELINE-CONTROL Method...................................... 80 12.6.1 Example - BASELINE-CONTROL................................ 82 12.7 DAV:compare-baseline Report.................................. 84 12.7.1 Example - DAV:compare-baseline Report..................... 85 12.8 Additional OPTIONS Semantics................................. 86 12.9 Additional MKCOL Semantics................................... 86 12.10 Additional COPY Semantics................................... 86 12.11 Additional CHECKOUT Semantics............................... 86 12.12 Additional CHECKIN Semantics................................ 86 12.13 Additional UPDATE Semantics................................. 87 12.14 Additional MERGE Semantics.................................. 89 13 Activity Feature.............................................. 90 13.1 Activity Properties.......................................... 91 13.1.1 DAV:activity-version-set (computed)....................... 91 13.1.2 DAV:activity-checkout-set (computed)...................... 92 13.1.3 DAV:subactivity-set....................................... 92 13.1.4 DAV:current-workspace-set (computed)...................... 92 13.2 Additional Version Properties................................ 92 13.2.1 DAV:activity-set.......................................... 93 13.3 Additional Checked-Out Resource Properties................... 93 13.3.1 DAV:unreserved............................................ 93 13.3.2 DAV:activity-set.......................................... 93 13.4 Additional Workspace Properties.............................. 93 13.4.1 DAV:current-activity-set.................................. 94 13.5 MKACTIVITY Method............................................ 94 13.5.1 Example - MKACTIVITY...................................... 95 13.6 DAV:latest-activity-version Report........................... 95 13.7 Additional OPTIONS Semantics................................. 96 13.8 Additional DELETE Semantics.................................. 96 13.9 Additional MOVE Semantics.................................... 97 13.10 Additional CHECKOUT Semantics............................... 97 13.10.1 Example - CHECKOUT with an activity...................... 98 13.11 Additional CHECKIN Semantics................................ 99 13.12 Additional MERGE Semantics.................................. 99 14 Version-Controlled-Collection Feature.........................100 14.1 Version-Controlled Collection Properties.....................102 14.1.1 DAV:eclipsed-set (computed)...............................102 14.2 Collection Version Properties................................103 14.2.1 DAV:version-controlled-binding-set (protected)............103 14.3 Additional OPTIONS Semantics.................................103 14.4 Additional DELETE Semantics..................................103 14.5 Additional MKCOL Semantics...................................104 14.6 Additional COPY Semantics....................................104 14.7 Additional MOVE Semantics....................................104 Clemm, et al. Standards Track [Page 5] RFC 3253 Versioning Extensions to WebDAV March 2002 14.8 Additional VERSION-CONTROL Semantics.........................104 14.9 Additional CHECKOUT Semantics................................105 14.10 Additional CHECKIN Semantics................................105 14.11 Additional UPDATE and MERGE Semantics.......................106 15 Internationalization Considerations...........................106 16 Security Considerations.......................................107 16.1 Auditing and Traceability....................................107 16.2 Increased Need for Access Control............................108 16.3 Security Through Obscurity...................................108 16.4 Denial of Service............................................108 17 IANA Considerations...........................................109 18 Intellectual Property.........................................109 19 Acknowledgements..............................................109 20 References....................................................110 Appendix A - Resource Classification..............................111 A.1 DeltaV-Compliant Unmapped URL.................................111 A.2 DeltaV-Compliant Resource.....................................111 A.3 DeltaV-Compliant Collection...................................112 A.4 Versionable Resource..........................................112 A.5 Version-Controlled Resource...................................112 A.6 Version.......................................................113 A.7 Checked-In Version-Controlled Resource........................113 A.8 Checked-Out Resource..........................................113 A.9 Checked-Out Version-Controlled Resource.......................114 A.10 Working Resource.............................................114 A.11 Version History..............................................114 A.12 Workspace....................................................115 A.13 Activity.....................................................115 A.14 Version-Controlled Collection................................115 A.15 Collection Version...........................................115 A.16 Version-Controlled Configuration.............................116 A.17 Baseline.....................................................116 A.18 Checked-Out Version-Controlled Configuration.................116 Authors' Addresses................................................117 Full Copyright Statement..........................................118 1 Introduction 　 このドキュメントは、HTTP/1.1プロトコルに対するWebDAV(Web Distributed 　 Authoring and Versioning)の拡張を定義するメソッドやヘッダ、そしてプロ 　 パティを規定する。バージョニングは、「スタンドアロンのWebページのよう 　 なWebリソースの重要な情報の履歴へのトラッキングおよびアクセス」という 　 概念である。ワールドワイドウェブのコンテキストにおけるバージョニングの 　 恩恵は以下のものを含む。 Clemm, et al. Standards Track [Page 6] RFC 3253 Versioning Extensions to WebDAV March 2002 - リソースはその履歴の中でのさまざまな状態を通じ、明示的な履歴と 　　　持続的な同一性を持つ。それは、リソースの過去と代替のバージョンを通じ 　　　見ることができる。しばしば、リソースの変更および作成者の履歴は、重要 　　　な情報になる。（見直し必要（by WAKATONO） - リソースの状態（version）は、注釈およびリンクサーバサポートのために、 　　　外部に保存されたリンクをサポートできる安定した名前を提供される。注釈 　　　およびリンクサーバの両方ともしばしば安定した直接の制御下にないリソー 　　　スの一部へのリファレンスを保存するために必要である。リソースの安定し 　　　た状態を提供することによって、バージョンコントロールシステムはポイン 　　　タをそのリソースに埋め込むだけでなく、リソースのそれらの状態の関係を 　　　決定するためにメソッドを定義することを許す。 　 WebDAVバージョニングは、基本的なものとアドバンスドバージョニングの 　 機能を定義する。 　 基本的なバージョニングは、ユーザに以下のことを許す。 - リソースをバージョンコントロール配下に置く - リソースがバージョンコントロール配下にあるかどうか決定する - リソースアップデートが自動的に新しいバージョンとして捕捉されるか 　　　決定する。 - リソースの個別のバージョンを作成し、アクセスする。 　 アドバンスドバージョニングは、Webリソースのセットの並行開発と構成 　 管理に必要な機能追加を提供する。 　 本ドキュメントは、最初に基本的なバージョニングのためのプロパティ及び 　 メソッドのセマンティクスを定義し、それからアドバンスドバージョニング 　 機能のための追加のプロパティおよびメソッドのセマンティクスを定義する。 　 基本的なバージョニングにのみ興味がある実装者は、アドバンスドバージョ 　 ニングセクション（Section 10 から 14 まで）を読み飛ばすべきである。 1.1 Relationship to WebDAV 　 インタオペラビリティと既存のプロトコルの機能を最大限生かすのであれば、 　バージョニングサポートはWebDAVプロトコル[RFC2518]の拡張として設計される。 　そしてWebDAV自体は、HTTPプロトコル[RFC2616]の拡張である。バージョニン 　グを意識しないクライアントがバージョニングをサポートしたサーバとの間で 　のインタオペラビリティを確保できるように、RFC2518およびRFC2616で定義さ 　れた全てのメソッドの並びと"postcondition"は保持される。 　 バージョニング拡張は、WebDAVおよびHTTPプロトコルの概念と直交するよう 　にデザインされているが、RFC2518の明確化は効果的なバージョニングの相互運 　用上必須である。これについては、Section1.7に記述する。 Clemm, et al. Standards Track [Page 7] RFC 3253 Versioning Extensions to WebDAV March 2002 1.2 Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The term "protected" is placed in parentheses following the definition of a protected property (see Section 1.4.2). The term "computed" is placed in parentheses following the definition of a computed property (see Section 1.4.3). When an XML element type in the "DAV:" namespace is referenced in this document outside of the context of an XML fragment, the string "DAV:" will be prefixed to the element type. When a method is defined in this document, a list of preconditions and postconditions will be defined for that method. If the semantics of an existing method is being extended, a list of additional preconditions and postconditions will be defined. A precondition or postcondition is prefixed by a parenthesized XML element type that identifies that precondition or postcondition (see Section 1.6). 1.3 Terms 　 本ドキュメントは、RFC2616,RFC2518および本セクションで定義される用語を 　使う。Section2.2はこの用語の根本を成す（semantic) versioning modelを定 　義する。 Version Control, Checked-In, Checked-Out 　　"Version control"は、リソースの更新手段の仕様群である。 　　"version Control"下にあるリソースは、"check-in"もしくは"check-out" 　　状態であり、"version control"の仕様は、リソースが"check-in"の状態に 　　ある時にのみ適用される。 Versionable Resource 　　　"versionable resource"は、"version control"可能なリソースである。 Version-Controlled Resource 　　　"versionable resource"が"version control"配下に置かれると、 　　　"version-controlled resource"になる。"version-controlled resource" 　　　は、"check-out"ができるようになり、HTTPメソッドやWebDAVの標準メソッ 　　　ドを使うことでコンテンツやデッドプロパティの更新を許される。 Clemm, et al. Standards Track [Page 8] ^L RFC 3253 Versioning Extensions to WebDAV March 2002 Checked-Out Resource 　　　"checked-out resource"は、"version control"下に置かれ、"checked-out" 　　　状態にあるリソースである。 Version Resource 　　　"version resource"（もしくはシンプルに"version"と表記する）は、 　　　特定の状態（コンテンツおよびデッドプロパティ）にある 　　　"version-controlled resource"の複製である。"version"は、 　　　"checked-out resource"を"check-in"することで作成される。サーバは 　　　新しい"version"に応じた新しい別のURLを割り当て、当該バージョン以 　　　外のものを指すためにそのURLが使われることはない。その"version"の 　　　コンテンツおよびデッドプロパティは決して変更されることはない。 Version History Resource 　　　"version history resource"（もしくはシンプルに"version history"） 　　　は、特定の"version-controlled resource"について、全てのバージョ 　　　ンを含むリソースである。 Version Name 　　　"version name"は、"version history"中のある"version"を、同じ 　　　"version history"中に存在する他の"version"と区別するためにサー 　　　バによって選択される文字列である。異なるversion historyであれば、 　　　"version"は同じ名前をとることが許される(may)。 Predecessor, Successor, Ancestor, Descendant 　　　"version-controlled resource"が"check-out"され、その後にcheck-in 　　　されると、"check-out"された"version"は、"check-in"によって作成さ 　　　れた"version"の"predecessor"となる。新しい"version"が、論理的に複 　　　数の"predecessor"をマージしたものであれば、クライアントは新しい 　　　"version"に対応する複数の"predecessor"を特定できる。ある"version" 　　　(訳注：これをversionAとする)が1つ以上の"predecessor"の関係をトラ 　　　バースすることで他の"version"（訳注：これをversionBとする）と関 　　　係付けられた場合、（トラバースにより）関係付けられたversionBは 　　　versionAの"ancestor"と呼ばれる。 　　　「predecessorの逆」と「ancestorの逆」のrelationは、"successor"と 　　　"descendant"の関係になる。この結果、X が Y の predecessor ならば、 　　　Y は X の successor であり、X が Y の ancestor ならば、Y はX の 　　　descendant になる。 Root Version Resource 　　　"root version resource"（もしくはシンプルに"root version"）は、 　　　"version history"中に存在する"version"であり、かつ他の全ての 　　　"version"の"ancestor"にあたる。 Clemm, et al. Standards Track [Page 9] ^L RFC 3253 Versioning Extensions to WebDAV March 2002 Workspace Resource 　　　"workspace resource"（もしくはシンプルに"workspace"）は 　　　多くても１つの指定された"version history"に対応する 　　　"version-controlled resource"を含むコレクションである 　　　（Section 6を参照のこと）。 Working Resource 　　　"working resource"は、（"version-controlled resource"のかわりに） 　　　"version"がcheck-outされる際に、サーバ側が定義したURLにおいてサーバ 　　　が作成するcheck-outされるリソースである。 　　　"check-out"される"version-controlled resource"とは異なり、 　　　"working resource"は"check-in"される際に削除される。 Fork, Merge 　　　2番目の"successor"が"version"に追加されると、"version history" 　　　において"fork"が作成される。複数の"predecessor"から"version"が 　　　作成されると、"version history"において"merge"が作成される。 　　　サーバは"version history"がリニア（forkもmergeもない状態）に保つ 　　　ような制約をかけることができるが、相互運用を想定したバージョニング 　　　暗いなとは"version history"内に存在する"fork"や"merge"を取り扱 　　　えるようにしておくべきである(should)。 　　以下のダイアグラムは、これまでに定義したものについて標記している。 　　箱は"version"を表し、箱の間にひかれた線は"predecessor"/"successor"の 　　関係を表す。例えば、V3はV5の"predecessor"であり、V7はV5の"successor" 　　である。V1はV4の"ancestor"であり、V7はV4の"descendant"である。これは、 　　V2での"fork"およびV7での"merge"も存在することを示す。 History of foo.html +---+ Root Version -------> | | V1 +---+ ^ | | | | +---+ | Version Name ----> V2 | | | Ancestor +---+ | / \ | / \ | +---+ +---+ | | V3 | | V4 ^ +---+ +---+ | | | | Predecessor | | | | +---+ +---+ | | | V5 | | V6 | Descendant +---+ +---+ | Successor | \ / | | \ / | v +---+ v | | V7 +---+ Label 　　　"label"は、"version history"の中から"version"を選択するのに使われる 　　　名前である。"label"は、クライアントかサーバが付与する。異なる複数の 　　　"version history"で同じ"label"を使用することが可能である。 1.4 Property Values 1.4.1 Initial Property Value 　 本ドキュメントでプロパティの初期値が定義されていない場合には、プロパ 　ティの初期値は実装に依存する。 1.4.2 Protected Property Value 　 特定の種類のリソースについて、プロパティは保護されており（"protected"）、 このような種類のリソースにおいて、プロパティの値は更新できない。但し、 特定のプロパティを更新するように明示的に定義されたメソッドを使用する 場合においてはこの限りではない。特に、保護されているプロパティは、 PROPPATCHリクエストでは更新ができない。 ある種類のリソースで指定されたプロパティが保護されているからといって、 他の種類のリソースでは保護されないということに注意せよ。 1.4.3 Computed Property Value 　プロパティが計算される場合、その値はそのリソースもしくは他のリソース 　のコンテンツおよび付随する他のプロパティなどに基づいた計算で定義され 　る。メソッドのセマンティクスが本ドキュメントにて定義されている場合 　には、計算されないプロパティに対するメソッドの及ぼす効果は規定され、 　計算の結果算出されるプロパティに対するメソッドの及ぼす効果は規定さ 　れないが、それらのプロパティについて定義されるプロパティの演算から 　推測することが可能です。計算によって算出されるプロパティは、常に 　保護される。 1.4.4 Boolean Property Value 　 プロパティの中には、"false"もしくは"true"で表される論理値を取る 　ものがある。 1.4.5 DAV:href Property Value 　 DAV:href XMLエレメントはRFC2518のセクション12.3で定義されます。 1.5 DAV Namespace XML Elements in Request and Response Bodies 　 WebDAVリクエストボディおよびレスポンスボディは、任意のXMLボディ 　によって拡張可能であり、そのXMLボディはメッセージ受信者によって 　無視される可能性があるが、DAVの名前空間内のXMLエレメントは、バー 　ジョニングメソッドにおいては、RFCでXMLエレメントが明示的に定義 　されていない限り、リクエスト／レスポンスボディでは使用してはな 　らない(MUST NOT)。 1.6 Method Preconditions and Postconditions 　メソッドの"precondition"は、メソッドの実行前に満たされなければなら 　ないサーバの状態を示す。メソッドの"postcondition"は、メソッドの実 　行後に満たされなければならないサーバの状態を示す。 　メソッドの"precondition"が満足されない場合、そのメソッドによるリク 　エストのレスポンスは、リクエストが繰り返されるべきではない(SHOULD 　NOT)場合には、常に失敗するということで403(Forbidden)が返却され、 　ユーザがコンフリクトを解消し、リクエストを再び送れるようにできるの 　であれば409(Conflict)が返却される。 Clemm, et al. Standards Track [Page 12] RFC 3253 Versioning Extensions to WebDAV March 2002 　 クライアント側で403や409のレスポンスをより効率的に処理するために、 　 明確なXMLエレメント型を各メソッドの"precondition"やリクエストの 　 "postcondition"に関連したと連携させる。特定の"precondition"が満足 　されない場合や特定の"postcondition"が得られない場合、ネゴシエートの 　結果他の方法が提示されない限りにおいて、レスポンスボディ内でトップ 　レベルの DAV:error エレメントの子として適切なXMLエレメントが返され 　なければならない(MUST)。207 Multi-Status レスポンス内においては 　DAV:error エレメントは適切な DAV:responsedescription エレメント内 　に現れる。 1.6.1 Example - CHECKOUT request with DAV:must-be-checked-in response >>REQUEST CHECKOUT /foo.html HTTP/1.1 Host: www.webdav.org >>RESPONSE HTTP/1.1 409 Conflict Content-Type: text/xml; charset="utf-8" Content-Length: xxxx 　 この例では、リクエスト CHECKOUT /foo.html は、/foo.html が"check-in" 　されていないという理由で失敗している。 1.7 Clarification of COPY Semantics with Overwrite:T RFC 2518 の Section 8.8.4 によれば、 　「コピー先にリソースが存在し、Overwriteヘッダの値が"T"の場合は、コピーを 　実行する前に、サーバはデスティネーションリソースを "Depth: infinity"指定 　でDELETEしなければならない。」 　とある。 "If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server MUST perform a DELETE with "Depth: infinity" on the destination resource." 　 この部分の目的は、（以下の）COPY処理において、全てのデスティネーション 　リソースが、request-URL(where a resource with a given name relative to the Destination URL "corresponds" to a resource with the same name 　relative to the request-URL)で指定されるリソースと、同じ内容とデッド 　プロパティを持っていることを保証するということである。 　 　　リクエスト時に、コピー先にすでにリソースが存在していて、しかも 　request-URLと同じリソースタイプであれば、リソースは削除されては 　ならない(MUST NOT)が、（コピー先と）一致するメンバの内容とデッドプロ 　パティについては更新されなければならない(MUST)。クライアントがCOPYに 　先だってコピー先にあるすべてのリソースを削除したいならば、明示的に 　DELETEリクエストを発行しなければならない(MUST)。 Clemm, et al. Standards Track [Page 13] RFC 3253 Versioning Extensions to WebDAV March 2002 　 リソースの更新と新しいリソースへの置き換えの間にある違いは、 　 "resource history"を維持する際には特に重要になる（前者は存在する 　"history"に追加をするが、後者は新しい"history"を作成する）。加えて、 　 ロックとアクセスコントロールの制約条件は、リソースの更新は許可するが 削除してその跡に新しいリソースを作成するということは許していない。 　ここで明らかにしたことは、MOVEリクエストには適用されない。Overwrite:T 　 のMOVEリクエストは、MOVEを実行するに先立って、デスティネーションに対 　 して"Depth:Infinity"のDELETEを実行しなければならない(MUST)。 1.8 Versioning Methods and Write Locks 　 書き込みロックがなされたリソースが本ドキュメントで定義された非計算 　 プロパティをともなう場合は、適切なロックトークンがリクエストに含ま 　 れているのでなければ、プロパティ値はリクエストによって変更されては 　 ならない(MUST NOT)。本ドキュメントで紹介されているREPORTメソッド以 　 外のすべてのメソッドは、少なくとも本ドキュメントで定義されているプ 　 ロパティの1つを変更するため、REPORTメソッド以外のすべてのバージョ 　 ニングメソッドは、書き込みロックの影響を受ける。特に、リソースが 　 ロックされており、かつIfヘッダにより適切なロックトークンが指定され 　 ていない場合には、メソッドは423(Locked)ステータスとともに失敗しなけ 　 ればならない(MUST)。 2 Basic Versioning Features 　 それぞれの基本的なバージョニングの特徴は、新しいリソースタイプ、ライブ 　 プロパティ、メソッドおよび既存のHTTPおよびWebDAVメソッドの拡張をもって 　 定義される。 2.1 Basic Versioning Packages 　 サーバは、バージョニングの機能についてあらゆる組み合わせをサポート してもよい(MAY)。しかしながら、ベーシックなバージョニングをサポートす るWebDAVのクライアントについて、複雑さを最小限にとどめようとするならば、 基本的なバージョニング機能をサポートするWebDAVサーバは、以下の3つのパッ ケージ（機能セット）をサポートすべきである(SHOULD)。 　 - Core-Versioning パッケージ: version-control - Basic-Server-Workspace パッケージ: version-control, workspace, version-history, checkout - Basic-Client-Workspace パッケージ: version-control, working- resource, update, label Clemm, et al. Standards Track [Page 14] RFC 3253 Versioning Extensions to WebDAV March 2002 　 core-versioning パッケージは、バージョニングを意識したクライアントと 　バージョニングを意識しないクライアントの両方に対してリニアなバージョニン 　グをサポートする。バージョニングを意識したクライアントは、"version-controlled 　resource"に含まれる最新でないversionへのアクセスを行うための履歴やプロパ 　ティへのアクセスが可能である。 　 basic workspace パッケージは、複数の"version-controlled resource"の 　並行開発をサポートする。各クライアントは、共有された"version-controlled 　resource"に対する固有のconfigurationを持ち、同様にconfigurationされた他の 　クライアントに影響を及ぼすことなくconfigurationを変更することが可能となる。 　 basic-server-workspace パッケージでは、すべての持続する状態はサーバ 　によって維持される。各クライアントはサーバ上に配置された個々の"workspace 　resource"を持ち、サーバ上で各workspaceは、共有された "version-controlled 　resource"のconfigurationを認識する。各クライアントは当該クライアントの持 　つworkspaceに対する変更を実施するが、ある"workspace"から他の"workspace" 　への変更の転送が適切な場合にのみそれは行われる。server workspaceパッケー 　ジは、ローカルに持続的な状態を持たない場合に適切である。もしくはあるクラ 　イアントが他のクライアントに対し、そのクライアントの作業情報を公開したい 　場合に適切である。 basic-client-workspace パッケージにおいては、クライアントはローカルの 　持続的な記憶領域に共有された"version-controlled resource"のconfiguration 　の状態を保持する。あるクライアントがその変更を他のクライアントにも見える 　ようにする場合、クライアントはworking resource"をサーバに配置し、それらの 　"working resource"の内容とデッドプロパティを更新し、それらの"working 　resource"を"version-controlled resource"の更新のために使用する。"working 　resource"は、直接"version-controlled resource"を更新する代わりに使用さ 　れる。一貫した更新が複数のクライアントから並行で準備される可能性がある 　からだ。さらに、"working resource"は、クライアントが複数のサーバーに対 　するリクエストを必要とする単一の更新を準備することを可能にする（たとえ 　ば、リソースの内容とデッドプロパティ両方を更新するためには、PUTと 　PROPPATCHの発行が必要である）。client workspace パッケージは、各クライ 　アントに自分自身の名前空間を管理することを要求することで、サーバ側の実 　装をシンプルにしている。しかし、この（クライアントサイドへの）要求は、 　クライアントが（クライアント）ローカルの継続的な状態を持つことを要求し、 　また、クライアントが他のクライアントに作業中のconfigurationを公開するこ 　とを許可しない。 　 これらの2つの基本的なworkspaceパッケージを両方ともサポートするサーバは、 　すべての基本的なバージョニングクライアントとの間でインタオペラビリティを 　持つ。 Clemm, et al. Standards Track [Page 15] RFC 3253 Versioning Extensions to WebDAV March 2002 2.2 Basic Versioning Semantics 2.2.1 Creating a Version-Controlled Resource 　 "versionable resource"の内容とデッドプロパティの（更新）履歴を残すため、 ために、ユーザは"version-control"されているリソースをVERSION-CONTROLリク エストを用いて格納することが出来る。VERSION-CONTROLリクエストは、3つの 異なる操作を実行する。 　 1) 新しい"version history resource"を作成する。基本的なバージョニングに 　　おいて、"version history resource"はURLを与えられず、結果としてそれは 　　HTTPの枠組みのURL空間で表現することができない。しかしながら、 　　version-history 機能（Section5を参照のこと）がサポートされるならば、 　　この変更と各"version history resource"は新しく個別のユニークなサーバ 　　が定義したURLを割り当てられる。 　 2) 新しい"version resource"を作成し、新しい"version history resource" 　　に追加する。新しい"version resource"のボディとデッドプロパティは、 　 "versionable resource"のボディやデッドプロパティの複製である。 　　　サーバは、新しい"version resource"に新しく個別のユニークなサーバが 　　定義したURLを割り当てられる。 　 3) "versionable resource"を"version-controlled resource"へと変換する。 　　　"version-controlled resource"は、"versionable resource"として 　　 定義されたのと同じURLで同定される。この変換の部分処理として、この 　　 メソッドは"DAV:checked-in"プロパティを付加するが、このプロパティの 　　 値としては、新しい"version resource"のURLが含まれる。 　注意せよ。 　　"versionable resource"と"version-controlled resource"は、新しいリソース 　タイプではない（例：これらは、DAV:resourcetypeの新しい形としては紹介されて 　いない）が、 　しかし、もっと正確に言えば、これらはDAV:resourcetypeで実装されている 　すべてのメソッドおよびライブプロパティに加え、本文書中で定義されたメ 　ソッドやライブプロパティがサポートする任意のタイプのリソースである。 　たとえば、コレクション（DAV:resourcetypeはDAV:collectionである）は、 　VERSION-CONTROLメソッドをサポートするならば"versionable resource"で 　あるし、"version-controlled resource"のメソッドおよびライブプロパ 　ティをサポートするならば"version-controll resource"である。 　　以下の例において、foo.htmlは"version control"配下に置かれている 　"versionable resource"である。"VERSION-CONTROL"リクエストが成功した後、 　2つの追加のリソースが存在する。1つは新たな"version history resource" 　であり、もう1つは"version history"内の"version resource"である。 　　"versionable resource"は、"version-controlled resource"に変換され、 　その"DAV:checked-in"プロパティは新しい"version resource"を同定する。 Clemm, et al. Standards Track [Page 16] RFC 3253 Versioning Extensions to WebDAV March 2002 　 リソースの内容とデッドプロパティは、リソースを表現する箱の中に現れる 　シンボルとして表現される（例：以下の例の中の"S1"）。 ===VERSION-CONTROL==> | +----+ version | version- | | history versionable | controlled +----+ resource resource | resource | /foo.html | /foo.html | | v +----+ | +----+ checked-in +----+ version | S1 | | | S1 |----------->| S1 | resource +----+ | +----+ +----+ /his/73/ver/1 　 このように、VERSION-CONTROLリクエスト前には非"version-controlled resource" 　 1つしかないのが、VERSION-CONTROLリクエストの後は3つの別のリソースが存在 　 する。その3つは"version-controlled resource"、"version resource"、 　"version history resource"である。その後、"version-controlled resource" 　 および "version resource"は"version-controlled resource" に対してのみ適 　 用され、そして"version-controlled resource"の"DAV:checked-in"プロパティ 　 によって指し示される"version resource"には適用されない個別のリソースであ 　 る。 　 　 "checked-in version controlled resource"の内容とデッドプロパティは 　 現在の"DAV:checked-in"で指し示される"version resource"のものと同一で 　 ある必要があるが、ライブプロパティは異なっていてもよい。実装の最適化の 　 ために、"checked-in version-controlled resource"を、"version-controlled 　 resource"から直接取り出すのではなく現在の"DAV:checked-in"が指し示す 　 "version resource"から取得してもよい。しかしながら、これが唯一の実装 　 を最適化する方法である。 　 通常は、リソースは明示的なVERSION-CONTROLリクエストによって"version 　 control"配下に置かれる。サーバはすべての新しい"versionable resource"を 　 自動的にバージョンコントロール配下に置いてよい(MAY)。このケースでは、 　 サーバ上の結果は、クライアントが明示的に"VERSION-CONTROL"メソッドを 　 "versionable resource"に対して適用した時と同じでなければならない(MUST)。 2.2.2 Modifying a Version-Controlled Resource 　 PUTやPROPPATCHのようなメソッドを使って直接"version-controlled resource" 　 の内容やデッドプロパティを変更するためには、"version-controlled resource" 　 は最初に"check out"されなければならない。"check-out"されたリソースが 　 "check-in"されると、"version-controlled resource"中の"version history"に 　 新しい"version resource"が生成される。 Clemm, et al. Standards Track [Page 17] RFC 3253 Versioning Extensions to WebDAV March 2002 　 "check-out"された"version resource"は、新しい"version resource"の 　 "predecessor"として記憶される。 　 "check-in"された"version-controlled resource"の"DAV:auto-version" 　 プロパティ（Section 3.2.2を参照のこと）は、内容やデッドプロパティを 　 変更しようと試みたメソッド（リクエスト）へのレスポンスの仕方を決定 　 する。取りうるレスポンスは、以下のものを含む。 　 - リクエストは失敗した。リソースが更新されるためには、明示的に 　 CHECKOUTリクエストを要求する（Section 4 と 9.2.1を参照のこと） 　 - 自動的にリソースを"check-out"して、変更を実施し、自動的にリソースを 　　 "check-in"する。これは、リソースのすべての状態をサーバが把握している 　　 ことを保証するが、とほうもない数のversionが生成される可能性がある。 　 - 自動的にリソースを"check-out"して、変更を実施し、それからリソースが 　　 書き込みロックされていないされていない場合は自動的にリソースを"check-in" 　　 する。もしリソースが書き込みロックされていたら、リソースは書き込み 　　 ロックが外れる（明示的にUNLOCKリクエストの結果としてそうなるか、 　　 書き込みロックがタイムアウトするか）まで"check-out"されたままである。 　　 これは、ロックをかけたクライアントが"version resource"を無限増殖 　　 させるのを防ぐ一方で、ロックをかけていないクライアントからの更新を 　　 許可します。 　 - 自動的にリソースを"check-out"して、変更を実施し、リソースを"check-out" 　　 された状態にしておきます。リソースが書き込みロックされている場合には、 　　 書き込みロックが外れた時点で自動的に"check-in"されますが、ロックをかけ 　　 ていないリソースに対しては明示的な"CHECKIN"操作（Section4.4を参照の 　　 こと）が要求されます。これは、バージョニングを意識しないクライアント 　　 による新しいバージョンの生成を最小限にとどめますが、バージョニングを 　　 意識したクライアントだけしか書き込みロックのされていないリソースの新 　　 しいバージョンを生成することが出来ません。 - リソースが書き込みロックされていない限りリクエストが失敗します。 　　 もし書き込みロックがされていれば、自動的にリソースを"check-out"して、 　　 変更を実施します。書き込みロックが外れた時に、リソースは自動的に"check-in" 　　 されます。これは、バージョニングを意識しないクライアントが新しいバー 　　 ジョンを生成するのを最小限にとどめますが、決して自動的に"check-out"さ 　　 れることはありません。しかし続いて自動的に"check-in"されないリソースを 　　 自動的に"check-out"しません Clemm, et al. Standards Track [Page 18] RFC 3253 Versioning Extensions to WebDAV March 2002 　 以下のダイヤグラムは、"version-controlled resource"および"version history" 　 における"checkout/checkin"の過程を表現したものである。 　 箱の中にあるシンボル(S1,S2,S3)は、それぞれの箱によって表現されるリソースの 　 現在の内容およびデッドプロパティをあらわす。箱の横に記されたシンボル 　 (V1,V2,V3)は、このリソースのURLをあらわす。 ===checkout==> ===PUT==> ===checkin==> /foo.html (version-controlled resource) +----+ | +----+ | +----+ | +----+ | S2 | | | S2 | | | S3 | | | S3 | +----+ | +----+ | +----+ | +----+ Checked-In=V2|Checked-Out=V2|Checked-Out=V2|Checked-In=V3 /his/73 (version history for /foo.html) +----+ | +----+ | +----+ | +----+ | S1 | V1 | | S1 | V1 | | S1 | V1 | | S1 | V1 +----+ | +----+ | +----+ | +----+ | | | | | | | | | | | | | | +----+ | +----+ | +----+ | +----+ | S2 | V2 | | S2 | V2 | | S2 | V2 | | S2 | V2 +----+ | +----+ | +----+ | +----+ | | | | | | | | | | | +----+ | | | | S3 | V3 | | | +----+ 　 "version"は、リソースの状態の定義されたサブセットをとらえていることに 　 注意せよ。特に、ベーシックリソースの"version"は、その内容とデッドプロ 　 パティをとらえてはいるが、ライブプロパティはとらえていない。 2.2.3 Reporting 　 resourceに関するあるバージョニング情報は、その情報のリクエストと共に 　 パラメータが指定されることを必要とする。ベーシックバージョニングに含 　 まれる情報は、拡張されたレポーティングのサポートを必要とする。特定の 　 リソースによってどのようなレポートがサポートされるべきかを決定するた 　 めのライブプロパティやREPORTメソッドを含む。REPORTメソッドは、バージョ 　 ニングには必須であるが、バージョニング拡張をされないWebDAVにおいても 　 使用することは可能である Clemm, et al. Standards Track [Page 19] RFC 3253 Versioning Extensions to WebDAV March 2002 　 クライアントが指定された"version-controlled resource"の 　 "version history"内に存在する全てのバージョンのプロパティを要求する 　 ことを許可するためには、ベーシックバージョニングは"DAV:version-tree" 　 レポート（Section 3.7を参照のこと）を提供する。さらに強力な"version history" 　 のレポーティングのしくみは、"DAV:expand-property report"（Section 3.8を 　 参照のこと）を "version history resource"（Section 5を参照のこと）に 　 適用することで提供される。 　 3 Version-Control Feature 　 "version-control"機能は、"version control"配下へとリソースを配置し、 　関連するリソースとして、Section 2.2.1 で記述されているような 　"version-controlled resource"と"version history resource"を生成する 　しくみを提供する。 　 サーバは、"OPTIONSリクエストのレスポンス中に含まれるDAVヘッダのフィー 　ルドに、"version-control"の文字列を含めることで、"version-control" 　機能をサポートすることを示す。 　 他のいかなりバージョニング機能がサポートされる場合でも、"version-control" 　機能はサポートされなければならない(MUST)。 3.1 Additional Resource Properties 　 "version-control"機能は、任意のWebDAVリソースについて資源の以下に 　示す必須の(REQUIRED)プロパティを導入します。 3.1.1 DAV:comment 　 このプロパティは、リソースに関すて、ユーザに対する適切な説明を簡 　潔なコメントとして記録するのに用いられる。"version"の"DAV:comment" 　は、その"version"が何故作成されたかを示すのに用いられる。 PCDATA value: string 3.1.2 DAV:creator-displayname 　 このプロパティは、リソースの作成者に関して、ユーザに対する適切な 　説明の記述を含む。"version"の"DAV:creator-displayname"は、誰がその 　"version"を作成したかを示すのに用いられる。 This property contains a description of the creator of the resource that is suitable for presentation to a user. The DAV:creator- displayname of a version can be used to indicate who created that version. PCDATA value: string 3.1.3 DAV:supported-method-set (protected) 　 このプロパティは、リソースがサポートするメソッドを識別する。 　 メソッドの適用によって発生する全ての"postcondition"を満たし、 　 かつリソースがサポートする機能によって追加されるあらゆる"postcondition" 　 に含まれるリソースの状態が存在する場合、そのメソッドはリソースに 　 サポートされている。 Clemm, et al. Standards Track [Page 20] RFC 3253 Versioning Extensions to WebDAV March 2002 name value: a method name 3.1.4 DAV:supported-live-property-set (protected) 　 このプロパティは、リソースによってサポートされるライブプロパティを 　 識別する。そのプロパティが、そのプロパティのために定義されたセマン 　 ティクスを持つ場合、ライブプロパティはリソースにサポートされる。 　 このプロパティの値は、リソースによってサポートされる本ドキュメントに 　 て定義される全てのライブプロパティを識別しなければならない(MUST)。 　 そして、リソースによって全てのライブプロパティを識別すべきである 　 (SHOULD)。 ANY value: a property element type 3.1.5 DAV:supported-report-set (protected) 　 このプロパティは、リソースによってサポートされるレポートを識別する。 ANY value: a report element type 3.2 Version-Controlled Resource Properties 　 バージョンコントロール機能は、"version-controlled resource"につい 　 て、以下の必須プロパティを導入します。 3.2.1 DAV:checked-in (protected) 　 本プロパティは、"check-in"された"version-controlled resource"にあら 　 われ、"version-controlled resource"と同じ内容およびデッドプロパティを 　 持っている"version"を識別します。本プロパティは、リソースが"check-out" 　 された時に除去され、リソースが"check-in"されると追加されて元に戻ります 　（新しい"version"を識別します）。 Clemm, et al. Standards Track [Page 21] RFC 3253 Versioning Extensions to WebDAV March 2002 3.2.2 DAV:auto-version 　 "DAV:auto-version"の値が"DAV:checkout-checkin"の場合、（PUTや 　 PROPPATCHのような）更新要求が"check-in"される"version-controlled 　 resource"に対して適用されると、チェックアウトは自動的にリクエスト 　 に先行して実行され、チェックインはリクエストの後に（自動的に）実 　 行される。 　 "DAV:auto-version"の値が"DAV:checkout-unlocked-checkin"の場合、更 　 新要求が"check-in"される"version-controlled resource"に対して適用 　 されると、チェックアウトは自動的にリクエストに先行して実行される。 　 リソースがwrite-lockされていなければ、リクエストの後に自動的にチェッ 　 クインが行われる。 　 "DAV:auto-version"の値が"DAV:checkout"の場合、更新要求が"check-in" 　 される"version-controlled resource"に対して適用されると、チェック 　 アウトは自動的にリクエストに先行して実行される。 　 DAV:auto-versionの値が"DAV:locked-checkout"の場合、更新要求が 　 "write-lock"された"check-in"される"version-controlled resource"に 　 対して適用されると、チェックアウトは自動的にリクエストに先行して 　 実行される。 　 "write-lock"された"check-in"されるリソースの更新にそのリソースの 　 チェックアウトが先行する場合、チェックアウトは"write-lock"と関係する。 　 この"write-lock"が取り除かれる（例えばUNLOCKもしくはタイムアウトなど） 　 と、リソースがまだチェックインされていない場合は、"write-lock"の除去 　 に先行してチェックイン操作が行われます。 　 サーバは、"DAV:auto-version"プロパティの値がの更新許可を拒絶しても 　 良い(MAY)。もしくは、取りうる値の一部のみをサポートするようにしても 　 良い(MAY)。 3.3 Checked-Out Resource Properties 　 "version-control"機能は、"check-out"されるリソースのために以下の 　 プロパティを必要とする。 Clemm, et al. Standards Track [Page 22] RFC 3253 Versioning Extensions to WebDAV March 2002 3.3.1 DAV:checked-out (protected) 　 このプロパティは、リソースがチェックアウトされた時点の"DAV:checked-in" 　 プロパティによって特定される"version"を識別する。このプロパティは、 　 リソースが"check-in"される時に削除される。 3.3.2 DAV:predecessor-set 　 このプロパティは、このリソースを"check-in"した結果得られる"version"の 　 "DAV:predecessor-set"プロパティを決定する。 　 サーバは、"version-controlled resource"の"DAV:predecessor-set"の変更 　を拒否してもよい(MAY)。 3.4 Version Properties 　 "version-control"機能は、"version"について、以下のプロパティを必要と 　 する（REQUIRED）。 3.4.1 DAV:predecessor-set (protected) 　 このプロパティは、このバージョンの"predecessor"を識別する。root version 　 を除き、各"version"は、最低1つの"predecessor"を持つ。root version は 　 "predecessor"を持たない。 3.4.2 DAV:successor-set (computed) 　 このプロパティは、この"version"を識別する"DAV:predecessor-set"プロ 　 パティを持つバージョンを識別する（訳注：successorはpredecessorの逆 　 の関係）。 3.4.3 DAV:checkout-set (computed) 　 このプロパティは、このバージョンを識別する"DAV:checked-out"プロパ 　 ティを持つ"check-out"されたリソースを識別する。 Clemm, et al. Standards Track [Page 23] RFC 3253 Versioning Extensions to WebDAV March 2002 3.4.4 DAV:version-name (protected) 　 このプロパティは、サーバサイドで定義された"version hisotory"内で 　 "version"ごとに異なる文字列を含む。この文字列は、versionのURL 　 −通常はクライアントでのみ使用され、それがユーザに提示されること 　 はない−とは異なりユーザに提示することを意図している。 PCDATA value: string 3.5 VERSION-CONTROL Method 　 VERSION-CONTROLリクエストは、request-URLの場所に"version-controlled 　 resource"を作成するために用いられる。"versionable resource"もしくは 　 "version-controlled resource"に対して適用可能である。 　 request-URLが"versionable resource"を指す場合は、新しい"version history 　 resource"が作成され、内容とデッドプロパティが"versionable resource"から 　 コピーされて新しい"version"が生成される。そして、リソースに新しい"version" 　 を識別するように初期化された"DAV:checked-in"プロパティが付与される。 　 request-URLが"version-controlled resource"を指す場合ば、そのリソースは 　 "version-control"配下に置かれたままである。このようにすることで、クライ 　 アントは、サーバが自動的にリソース作成時にそのリソースを"version-control" 　 配下に置くかそうでないかを気にしないようにできる。 　 VERSION-CONTROLリクエストが失敗した場合は、リクエストに先行するサーバの 　 状態を回復しなくてはならない（訳注：リクエストで変更されそうになった状 　 態をもとに戻すことだろう）。 　 順序： Marshalling: 　　　リクエストボディが含まれる場合、それは"DAV:version-control"XMLエレメント 　　　でなくてはならない。 　　　成功したリクエストのレスポンスボディが含まれる場合、それは 　　　"DAV:version-control-response"XMLエレメントでなくてはならない。 　　　このドキュメントは、VERSION-CONTROLレスポンスボディについて何の定義も 　　　していないが、"DAV:version-control-response"エレメントはVERSION-CONTROL 　　　のレスポンスボディにてエレメントを定義するような将来的な拡張における 　　　相互運用性を保証するために定義されていることに注意せよ。 Clemm, et al. Standards Track [Page 24] RFC 3253 Versioning Extensions to WebDAV March 2002 Postconditions: 　　　(DAV:put-under-version-control): request-URLがリクエストの時点で 　　　"versionable resource"であれば、リクエストは新しい"version history" 　　　を作成しなければならず（MUST）、その"version history"の中に新しい 　　　"version"を作成しなければならない（MUST)。リソースは新しい"version" 　　　を識別する。"DAV:checked-in"プロパティを持たなくてはならない（MUST）。 　　　内容、デッドプロパティ、そして新しい"version"の"DAV:resourcetype"は 　　　そのリソースのものと同一でなくてはならない（MUST）。 　　　"version history"および"version resource"は、好きなところに配置する 　　　ような実装が出来ることに注意せよ。特に、それらは同じホストの同じサー 　　　バ上に配置したり、同じホスト上に存在する異なる仮想サーバに置いたり、 　　　異なるサーバで稼動している同じホストに置いたり、異なるサーバで異な 　　　るサーバに置いたりすることが可能である。 　　　(DAV:must-not-change-existing-checked-in-out): 　　　request-URLで識別されるリソースが、リクエスト時点ですでに 　　　"version control"配下に置かれていたならば、リクエストはその 　　　"version-controlled resource"の"DAV:checked-in"プロパティや 　　　"DAV:checked-out"プロパティを変更してはならない（MUST NOT）。 3.5.1 Example - VERSION-CONTROL >>REQUEST VERSION-CONTROL /foo.html HTTP/1.1 Host: www.webdav.org Content-Length: 0 >>RESPONSE HTTP/1.1 200 OK 　 この例では、/foo.htmlは"version control"配下に置かれる。このための 　 新しい"version history"が生成され、/foo.htmlの内容とデッドプロパティの 　 コピーを備えた新しい"version"が生成される。/foo.htmlの"DAV:checked-in" 　 プロパティは、新しい"version"を識別する。 3.6 REPORT Method 　 REPORTリクエストは、リソースに関する情報を取得するための拡張機構である。 　 単一の値を取るリソースプロパティとは違い、レポートの値はREPORTのリクエスト 　 ボディおよびリクエストヘッダで指定される追加情報に依存する。 Clemm, et al. Standards Track [Page 25] RFC 3253 Versioning Extensions to WebDAV March 2002 　 順序： Marshalling: 　　　REPORTメソッドのリクエストボディは、要求するレポートやレポートをカス 　　　タマイズするために用いられる追加情報を指定する。 　　　リクエストは、"Depth"ヘッダを含めても良い（MAY）。もし"Depth"ヘッダが 　　　ない場合には、"Depth:0"が指定されたとみなす。 　　　リクエストが成功すると、そのレスポンスボディには要求したレポートが含 　　　まれる。 　　　"Depth"リクエストヘッダが含まれる場合には、レスポンスは207 Multi-Status 　　　でなければならない（MUST）。リクエストは（指定されたコレクション）その 　　　ものおよび、Depthの値を満たす範囲のコレクションメンバに対して個々に 　　　適用されなければならない（MUST）。指定されたリソースに関する 　　　"DAV:response"の"DAV:prop"エレメントは、そのリソースに関する要求された 　　　レポートを含まなくてはならない（MUST）。 Preconditions: 　　　(DAV:supported-report):指定されたレポートは、request-URLで識別される 　　　リソースによって提供されなければならない（MUST）。 Postconditions: 　　　(DAV:no-modification): REPORTメソッドは、あらゆるリソースについて 　　　内容やデッドプロパティを変更してはならない（MUST）。 3.7 DAV:version-tree Report 　 "DAV:version-tree"レポートは、"version"の"version history"中にある全ての 　 "version"について、要求されたプロパティを書き出す。"version-controlled 　 resource"に対してレポートが要求された場合は、"DAV:checked-in"もしくは 　 "DAV:checked-out"で示される"version"にリクエストはリダイレクトされる。 　 "DAV:version-tree"レポートは、全ての"version resource"および全ての 　 "version-controlled resource"でサポートされなければならない（MUST）。 　 順序： Marshalling: 　　　リクエストボディは、DAV:version-tree XML エレメントでなくてはなら 　　　ない（MUST）。 ANY value: 0以上のエレメントの並びであり、最大1つの"DAV:prop"エレ 　　　　　　　　メントを伴う。 prop: RFC 2518のSection 12.11を参照のこと。 Clemm, et al. Standards Track [Page 26] RFC 3253 Versioning Extensions to WebDAV March 2002 　　　リクエストが成功した場合、レスポンスボディは"DAV:multistatus"XML 　　　エレメントでなくてはならない（MUST）。 　　　multistatus: RFC2518のSection 12.9を参照のこと。 　　　"DAV:version-tree" REPORTリクエストが成功した場合、レスポンスボディは 　　　request-URLで識別される"version"の"version history"内に存在する 　　　versionに関する"DAV:response"エレメントを含まなければならない（MUST）。 3.7.1 Example - DAV:version-tree Report 　 以下に記した"version history"は、その後に続くversion treeレポートを生成 　 する。 foo.html History +---+ | | V1 +---+ / \ / \ +---+ +---+ | | V2 | | V2.1.1 +---+ +---+ >>REQUEST REPORT /foo.html HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Clemm, et al. Standards Track [Page 27] RFC 3253 Versioning Extensions to WebDAV March 2002 >>RESPONSE HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://repo.webdav.org/his/23/ver/V1 V1 Fred http://repo.webdav.org/his/23/ver/V2 http://repo.webdav.org/his/23/ver/V2.1.1 HTTP/1.1 200 OK http://repo.webdav.org/his/23/ver/V2 V2 Fred HTTP/1.1 200 OK http://repo.webdav.org/his/23/ver/V2.1.1 V2.1.1 Sally HTTP/1.1 200 OK Clemm, et al. Standards Track [Page 28] RFC 3253 Versioning Extensions to WebDAV March 2002 3.8 DAV:expand-property Report 　 多くのプロパティ値がDAV:hrefとして定義されているかDAV:href エレメントの 　 セットとして定義されている。"DAV:expand-property"レポートは、これらの 　 DAV:hrefエレメントにより識別されるリソースからの一度のプロパティ要求で 　 取得するしくみを提供する。このレポートは必要なリクエストの数を減らすだ 　 けでなく、サーバがバージョン管理領域の根幹に対して読み込みトランザク 　 ションの分割を最小化することを可能にする。 　 "DAV:expand-property"レポートは、REPORTメソッドをサポートする全ての 　 リソースでサポートされるべきである（SHOULD）。 　 順序： Marshalling: 　　　リクエストボディは、"DAV:expand-property"XMLエレメントでなくては 　　　ならない（MUST）。 name value: a property element type namespace value: an XML namespace 　　　正しいリクエストに対するレスポンスボディは、"DAV:multistatus"XML 　　　エレメントでなくてはならない（MUST）。 　　　multistatus: RFC2518 の Section 12.9 を参照のこと。 　　　"DAV:multistatus"エレメントの"DAV:prop"エレメントにてレポートされる 　　　プロパティは、"DAV:expand-property"エレメント中の"DAV:property"エレ 　　　メントによって認識されるものでなくてはならない（MUST）。もし 　　　"DAV:property"エレメントの中にさらに"DAV:property"エレメントが入れ子 　　　にされた"DAV:property"エレメントがある場合、対応するプロパティの 　　　値の中に存在する全ての"DAV:href"は、入れ子の"DAV:property"エレメント 　　　で認識されるプロパティの値をレポートする"DAV:prop"エレメントを含む 　　　"DAV:response"エレメントにより置き換えられます。入れ子の 　　　"DAV:property"エレメントは、順番に"DAV:property"エレメントを含むこ 　　　とが出来る。その結果、複数のレベルの"DAV:href"拡張を要求出来る。 　　　 　　　有効なパーサは、"DAV:expand-property"レポートがDTD中の全ての"href"を 　　　"href | response"と置き換えることで、全てのプロパティのDTDを効果的 　　　に更新することを意識しなければならない（MUST）ことに注意せよ。 Clemm, et al. Standards Track [Page 29] RFC 3253 Versioning Extensions to WebDAV March 2002 3.8.1 Example - DAV:expand-property 　 この例は、"version-controlled resource"の"version history"中にある全 　 ての"version"のDAV:creator-display-nameおよびDAV:activity-setを決定 　 するためにはどのように"version-controlled resource"へのクエリをするか 　 について記述している。この例は、サーバは"version-history"機能をサポー 　 トしているとみなす（Section 5を参照のこと）。 >>REQUEST REPORT /foo.html HTTP/1.1 Host: www.webdav.org 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.webdav.org/foo.html http://repo.webdav.org/his/23 http://repo.webdav.org/his/23/ver/1 Fred Clemm, et al. Standards Track [Page 30] RFC 3253 Versioning Extensions to WebDAV March 2002 http://www.webdav.org/ws/dev/sally HTTP/1.1 200 OK http://repo.webdav.org/his/23/ver/2 Sally http://repo.webdav.org/act/add-refresh-cmd HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK 　 この例では、http://www.webdav.org/foo.htmlの"DAV:version-history"の 　"DAV:version-set"中の"version"の"DAV:creator-displayname"プロパティお 　よび"DAV:activity-set"プロパティがレポートされている。 3.9 Additional OPTIONS Semantics 　 サーバが"version-control"機能をサポートするならば、バージョニング 　 プロパティやレポートやメソッドをサポートする全てのリソースについて、 　 OPTIONSリクエストに対するDAVレスポンスヘッダ中のフィールドとして、 　 "version-control"を含まなければならない（MUST）。 3.10 Additional PUT Semantics Additional Preconditions: 　　　(DAV:cannot-modify-version-controlled-content): request-URLが 　　　"DAV:checked-in"プロパティをともなわないリソースを識別するな 　　　らば、"DAV:auto-version"セマンティクスがリソースを自動的にチェッ 　　　クアウトしようとしない限り、リクエストは失敗しなくてはならない 　　　（MUST）。 　　　(DAV:cannot-modify-version): request-URLが"version"を識別する 　　　ならば、リクエストは失敗しなくてはならない（MUST）。 　　　もしリクエストが"version control"配下に自動的に置かれる新しい 　　　リソースを作成するならば、VERSION-CONTROLメソッドのすべての 　　　preconditions（訳注：前提条件）が適用される。 Clemm, et al. Standards Track [Page 31] RFC 3253 Versioning Extensions to WebDAV March 2002 Additional Postconditions: 　　　(DAV:auto-checkout): リソースが"check-in"された"version-controlled 　　　resource"であり、さらにそのリソースが"DAV:auto-version"プロパティが 　　　更新のリクエスト時に、自動的にチェックアウトすべきであるが、自動的 　　　にチェックインすべきではないと示されているものであるならば、サーバ 　　　は、リクエストを実行するに先立って、リソースを自動的にチェックアウ 　　　トしなければならない。特に、 　　　リクエストに先立ってリソースの"DAV:checked-out"プロパティの値は" 　　　DAV:checked-in"プロパティの値でなければならず（MUST）、 　　　"DAV:checked-in"プロパティは削除されていなくてはならず（MUST）、 　　　そして"DAV:predecessor-set"プロパティはDAV:checked-outプロパティ 　　　と同じであるように初期化されなくてはならない（MUST）。 　　　もしcheckout/updateのシーケンスのどこかが失敗したら、リクエストの 　　　失敗した部分についてステータスが返却されなければならず（MUST）、 　　　リクエストシーケンスが進んだサーバの状態は回復されなければなら 　　　ない（MUST）。 　　　(DAV:auto-checkout-checkin): 　　　リソースが"check-in"された"version-controlled resource"であり、 　　　そのリソースの"DAV:auto-version"プロパティが更新のリクエスト時 　　　に自動的にチェックアウトして自動的にチェックインするように示さ 　　　れているならば、サーバはリクエストの実行に先立って自動的にリソー 　　　スをチェックアウトしなければならない（MUST）。特に、リソースの 　　　"DAV:checked-in"プロパティは、内容とデッドプロパティがリソース 　　　と同じである新しい"version"を指していなければならない（MUST）。 　　　新しい"version"の"DAV:predecessor-set"は、リクエストに先立って 　　　"DAV:checked-in"プロパティによって示される"version"を指さなけ 　　　ればならない（MUST）。もしcheckout/update/checkinのシーケンス 　　　において、いずれかのところが失敗したら、リクエストの失敗した部 　　　分についてステータスが返却されなければならず（MUST）、リクエス 　　　トシーケンスが進んだサーバの状態は回復されなければならない（MUST）。 3.11 Additional PROPFIND Semantics 　 "DAV:allprop"によるPROPFINDリクエストは、本ドキュメントで定義された 　 いかなるプロパティも返却すべきではない（SHOULD NOT)。これは、単純な 　 クライアント−サーバに対して全てのライブプロパティを計算させることを 　 要求するコストを理解していないクライアント−が"DAV:allprop" PROPFIND 　 リクエストを実行するような時に、バージョニングサーバが効率的に動作 　 することを実現する。 Clemm, et al. Standards Track [Page 32] RFC 3253 Versioning Extensions to WebDAV March 2002 Additional Preconditions: 　　　(DAV:supported-live-property): リクエストが本ドキュメントで定義され 　　　ているプロパティへのアクセスを試みるような場合、サーバはこのプロパ 　　　ティのセマンティクスをサポートしている必要がある。 3.12 Additional PROPPATCH Semantics Additional Preconditions: 　　　(DAV:cannot-modify-version-controlled-property): (DAV:cannot-modify-version-controlled-property): リクエストがデッ 　　　ドプロパティを更新しようとした場合に、PUTと同じセマンティクスを 　　　持つ（Section 3.10を参照のこと）。 (DAV:cannot-modify-version): リクエストがデッドプロパティを更新 　　　しようとした場合に、PUTと同じセマンティクスを持つ（Section 3.10を 　　　参照のこと）。 　　　(DAV:cannot-modify-protected-property): 本ドキュメントで定義されて 　　　いるプロパティの更新の試行は、この種のリソースは保護されているため 　　　に失敗しなければならない（MUST）。 　　　(DAV:supported-live-property): 本ドキュメントで定義されているがその 　　　セマンティクスがサーバによって強制されないようなプロパティの更新の 　　　試行は失敗しなければならない（MUST）。このことは、サーバによってサ 　　　ポートされないセマンティクスのプロパティを使おうと試みた時に、クラ 　　　イアントがそれを通知されるのを保証する。 Additional Postconditions: 　　　(DAV:auto-checkout): リクエストがデッドプロパティを更新したならば、 　　　PUTと同じセマンティクスを持つ（Section 3.10を参照のこと）。 　　　(DAV:auto-checkout-checkin): リクエストがデッドプロパティを更新し 　　　たならば、PUTと同じセマンティクスを持つ（Section 3.10を参照のこと）。 3.13 Additional DELETE Semantics Additional Preconditions: 　　　(DAV:no-version-delete): サーバは"version"のDELETE試行は失敗しなけ 　　　ればならない（MUST）。 Additional Postconditions: 　　　(DAV:update-predecessor-set): "version"が削除されたら、サーバは 　　　DAV:predecessor-set中の（削除された）"version"へのリファレンスを、 　　　削除された"version"の"DAV:predecessor-set"のコピーと置き換えなく 　　　てはならない（MUST）。 Clemm, et al. Standards Track [Page 33] RFC 3253 Versioning Extensions to WebDAV March 2002 3.14 Additional COPY Semantics Additional Preconditions: 　　　リクエストが"version control"配下に自動的に置かれる新しいリソースを 　　　作成したら、VERSION-CONTROLの全ての"precondition"はリクエストにあて 　　　はまる。 Additional Postconditions: 　　　(DAV:must-not-copy-versioning-property): 　　　本ドキュメントで定義されたプロパティは、本リクエストで作成される新し 　　　いリソースにコピーされてはならない（MUST NOT）。さらに、新しいリソー 　　　スがPUTやMKCOL等の非バージョニングメソッドによって作成された場合は、 　　　新しいリソースのプロパティは取りうる初期値を取らなければならない 　　　（MUST）。 　　　(DAV:auto-checkout): コピー先が"version-controlled resource"であった 　　　場合には、PUTと同様のセマンティクスを持つ（Section 3.10を参照の 　　　こと）。 (DAV:auto-checkout-checkin): コピー先が"version-controlled resource" 　　　であった場合には、PUTと同様のセマンティクスを持つ（Section 3.10を 　　　参照のこと）。 　　　(DAV:copy-creates-new-resource): コピー元が"version-controlled 　　　resource"もしくは"version"であり、そしてコピー先にリソースが存在 　　　しない場合、COPY処理は新しい"non-version-controlled resource"を 　　　コピー先に作成する。新しいリソースは、自動的に"version control" 　　　配下に置いてもよい（MAY）。しかしながら、生成される"version-controlled 　　　resource"は、その新しい"version-controlled resource"のために作ら 　　　れた新しい"version history"と関係してなくてはならず（MUST）、 　　　そして全てのVERSION-CONTROLのpostconditionは、リクエストにあて 　　　はまる。 3.15 Additional MOVE Semantics Additional Preconditions: 　　　(DAV:cannot-rename-version): request-URLが"version"を指定した時、 　　　リクエストは失敗しなければならない（MUST）。 Additional Postconditions: 　　　(DAV:preserve-versioning-properties): リソースが移動元URLから移動先 　　　URLへ移動させられた場合には、このドキュメントで定義されたプロパティ 　　　は移動元のそれと同じ値を移動先のプロパティも持っていなくてはならない 　　　（MUST）。 Clemm, et al. Standards Track [Page 34] RFC 3253 Versioning Extensions to WebDAV March 2002 3.16 Additional UNLOCK Semantics 　 これらのセマンティクスは明示的なUNLOCKリクエストとロックタイムアウトに 　 よるロックの除去の両方にあてはまることに注意せよ。もし"precondition" 　 や"postcondition"が満足されない場合は、ロックタイムアウトは発生しては 　 ならない（MUST NOT）。 Additional Preconditions: 　　　(DAV:version-history-is-tree): request-URLが"check-out"された 　　　"version-controlled resource"を指しており、そのresourceがlock除去時に 　　　自動的に"check-in"するようなものだった場合、"check-out"されたリソース 　　　の"DAV:predecessor-set"によって識別される"version"（複数ありうる）は、 　　　DAV:checked-out versionのために"version history"のroot versionの子孫 　　　にならなければならない。 Additional Postconditions: 　　　(DAV:auto-checkin): request-URLがcheck-outされた"version-controlled 　　　resource"を指し、しかもそのリソースが"DAV:auto-version"プロパティ 　　　のために自動的にチェックアウトされたものだったら、リクエストは 　　　DAV:checked-out versionの"version history"中に新しい"version"を 　　　作成しなければならない（MUST）。リクエストは、他のいかなるリソー 　　　スからも識別されてはならない（MUST NOT）"version"のためにURLを配 　　　置しなくてはならず（MUST）、この"version"以外のリソースを識別して 　　　はならない（MUST NOT）。新しい"version"の内容とデッドプロパティと 　　　"DAV:resourcetype"と"DAV:predecessor-set"については、"checked-out 　　　resource"からコピーされなくてはならない（MUST）。新しい"version"の 　　　"DAV:version-name"は、同じ"version history"中の他の"version"の他の 　　　全ての"DAV:version-name"の値と区別できるサーバが定義した値が設定さ 　　　れなければならない（MUST）。 　　　リクエストは、"version-controlled resource"の"DAV:checked-out"プロ 　　　パティを除去しなければならず（MUST）、新しい"version"を識別する 　　　"DAV:checked-in"プロパティを追加しなくてはならない。 4 CHECKOUT-IN-PLACE FEATURE 　 "version-control"機能とともに、WebDAVのロックは"version-controlled 　 resource"への各更新の結果として"version"が急増するのを回避するのに 　 用いられる。"checkout-in-place"機能は、新しい"version"作成のために、 　 リソースを明示的に"check-out"および"check-in"することをクライアント 　 に許可する別のしくみを提供する。（訳注：しくみが難なのかこれではわ 　 からない(WAKATONO)）。 With the version-control feature, WebDAV locking can be used to avoid the proliferation of versions that would result if every modification to a version-controlled resource produced a new version. The checkout-in-place feature provides an alternative mechanism that allows a client to explicitly check out and check in a resource to create a new version. 4.1 Additional Version Properties 　 checkout-in-place機能は、"version"について以下のプロパティが必要で 　 ある。 Clemm, et al. Standards Track [Page 35] RFC 3253 Versioning Extensions to WebDAV March 2002 4.1.1 DAV:checkout-fork 　 このプロパティは、"version"がすでに"check-out"されているか"successor"を 　 持つ場合に、"CHECKOUT"の挙動を制御する。"version"の"DAV:checkout-fork" 　 が"DAV:forbidden"である場合、もしそれが1つを越えるバージョンあるいは 　 "check-out"されたresourceの"DAV:predecessor-set"または"DAV:checked-out" 　 のプロパティに現われるそのバージョンに帰着するならば、CHECKOUTリクエス 　 トは失敗しなければならない（MUST）。 　 "DAV:checkout-fork"が"DAV:discouraged"の場合、"DAV:fork-ok"がCHECKOUTの 　 リクエストボディに指定されていない限りCHECKOUTのようなリクエストは失敗 　 しなければならない（MUST）。 　 　 サーバは、"version"の"DAV:checkout-fork"の更新を拒否してもよい（MAY）。 ANY value: A sequence of elements with at most one DAV:discouraged or DAV:forbidden element. 4.1.2 DAV:checkin-fork 　 このプロパティは、"version"がすでに"successor"である場合のCHECKINの 　 挙動を制御する。"version"の"DAV:checkin-fork"が"DAV:forbidden"だった 　 場合、もしそれが、1つを越える"version"の"DAV:predecessor-set"に現わ 　 れるそのバージョンに帰着するならばCHECKINリクエストは失敗しなければ 　 ならない（MUST）。"DAV:checkin-fork"が"DAV:discouraged"ならば、CHECKIN 　 のようなリクエストは、"DAV:fork-ok"がCHECKINのリクエストボディに指定 　 されていない限りCHECKOUTのようなリクエストは失敗しなければならない 　 （MUST）。 　 サーバは、"version"の"DAV:checkin-fork"の更新を拒否してもよい（MAY）。 　（訳注：原文は "A server MAY reject attempts to modify the 　 DAV:checkout-fork of a version."だが、明らかにDAV:checkout-forkはお 　 かしいので翻訳時に修正（WAKATONO）。） ANY value: A sequence of elements with at most one DAV:discouraged or DAV:forbidden element. 4.2 Checked-Out Resource Properties 　 "checkout-in-place"機能は、"check-out"されるリソースについて以下の 　 プロパティが必要である。 4.2.1 DAV:checkout-fork 　 このプロパティは、このリソースに"check-in"した結果として得られる 　 "version"の"DAV:checkout-fork"プロパティを決定する。 Clemm, et al. Standards Track [Page 36] RFC 3253 Versioning Extensions to WebDAV March 2002 4.2.2 DAV:checkin-fork 　 このプロパティは、このリソースに対して"check-in"した結果として得られる 　 "version"の"DAV:checkin-fork"プロパティを決定する。 4.3 CHECKOUT Method ("version-controlled resource"に適用される) 　 CHECKOUTリクエストは、"version-controlled resource"の内容とデッドプロパティ 　 の変更を許可するために、"check-in"された"version-controlled resource" 　 に対して適用される。 　 CHECKOUTリクエストが失敗すると、サーバは先行している状態をもとにもど 　 さなくてはならない（MUST）。 　 順序： Marshalling: 　　　リクエストボディが含まれる場合は、"DAV:checkout"XMLエレメントで 　　　なくてはならない（MUST）。 　　　ANY 値：多くても1つの"DAV:fork-ok"エレメントを含むエレメントの並び 　　　リクエストが成功した場合のレスポンスボディが含まれている場合は、 　　　それは"DAV:checkout-response"XMLエレメントでなくてはならない 　　　（MUST）。 　　　レスポンスは、"Cache-Control:no-cache"ヘッダを含まなくてはなら 　　　ない（MUST）。 Preconditions: 　　　(DAV:must-be-checked-in): "version-controlled resource"が 　　　"check-out"されるならば、"DAV:checked-in"プロパティを持た 　　　なくてはならない（MUST）。。 　　　(DAV:checkout-of-version-with-descendant-is-forbidden): 　　　チェックアウトされている"version"の"DAV:checkout-fork"プロパティが 　　　"DAV:forbidden"であるならば、もしその"version"が"DAV:predecessor-set" 　　　中の"version"で認識されるならばリクエストは失敗しなくてはならない 　　　（MUST）。 　　　(DAV:checkout-of-version-with-descendant-is-discouraged): 　　　チェックアウトされている"version"の"DAV:checkout-fork"プロパティが 　　　"DAV:discouraged"ならば、もしその"version"が"DAV:predecessor-set" 　　　中の"version"で認識されるならば、リクエストは失敗しなくて 　　　はならない（MUST）。しかし、"DAV:fork-ok"がリクエストボディに 　　　て指定されている場合はこの限りではない。 Clemm, et al. Standards Track [Page 37] RFC 3253 Versioning Extensions to WebDAV March 2002 　　　(DAV:checkout-of-checked-out-version-is-forbidden): 　　　チェックアウトされている"version"の"DAV:checkout-fork"プロパティが 　　　"DAV:forbidden"だった場合、もしその"version"が"DAV:checked-out" 　　　プロパティ中の"version"で認識されるならばリクエストは失敗しなく 　　　てはならない（MUST）。 　　　(DAV:checkout-of-checked-out-version-is-discouraged): 　　　チェックアウトされている"version"の"DAV:checkout-fork"プロパティが 　　　"DAV:discouraged"だった場合、もし"check-out"されたリソースが 　　　"DAV:checked-out"プロパティ中の"version"で認識されるならばリ 　　　クエストは失敗しなくてはならない（MUST）。しかし、"DAV:fork-ok" 　　　がリクエストボディにて指定されている場合はこの限りではない。 Postconditions: 　　　(DAV:is-checked-out): "check-out"されているリソースは、 　　　"DAV:checked-out"プロパティを持たなければならない（MUST）。その 　　　プロパティは、チェックアウトに先だって"DAV:checked-in"の"version"を 　　　識別する。"version-controlled resource"は、"DAV:checked-in"プロ 　　　パティを持っていてはならない（MUST）。 　　　(DAV:initialize-predecessor-set): "check-out"されるリソースの 　　　"DAV:predecessor-set"プロパティは、"DAV:checked-out"のバージョンで 　　　あるように初期化されなければならない（MUST）。 4.3.1 Example - CHECKOUT of a version-controlled resource >>REQUEST CHECKOUT /foo.html HTTP/1.1 Host: www.webdav.org Content-Length: 0 >>RESPONSE HTTP/1.1 200 OK Cache-Control: no-cache 　 この例では、"version-controlled resource"の/foo.htmlは、チェックアウト 　 される。 4.4 CHECKIN Method ("version-controlled resource"に適用される) 　 CHECKINリクエストは、"check-out"された"version-controlled resource"に 　 対し"check-out"されたリソースから内容とデッドプロパティがコピーされた 　 新しい"version"を生成するために適用される。 　 CHECKINリクエストが失敗すると、サーバは先行している状態をもとにもど 　 さなくてはならない（MUST）。 Clemm, et al. Standards Track [Page 38] RFC 3253 Versioning Extensions to WebDAV March 2002 　 順序： Marshalling: 　　　リクエストボディが含まれる場合、それは"DAV:checkin"XMLエレメント 　　　でなければならない（MUST）。 　　　ANY 値：多くても1つの"DAV:keep-checked-out"エレメントおよび多くても 　　　1つの"DAV:fork-ok"エレメントを含むエレメントの並び 　　　成功したリクエストのレスポンスボディが含まれる場合、それは 　　　"DAV:checkin-response"XMLエレメントでなくてはならない（MUST）。 　　　レスポンスは、"Cache-Control:no-cache"ヘッダを含まなければならない 　　　（MUST）。 Preconditions: 　　　(DAV:must-be-checked-out): request-URLは、"DAV:checked-out" 　　　プロパティをともなうリソースを指定しなければならない（MUST）。 　　　(DAV:version-history-is-tree): "check-out"されたリソースの 　　　"DAV:predecessor-set"で指定される"version"は、"DAV:checked-out" 　　　で指定される"version"の"version history"の"root version"の 　　　"descendants"でなければならない（MUST）。 　　　(DAV:checkin-fork-forbidden): CHECKINリクエストによって、 　　　"DAV:checkin-fork"が"DAV:forbidden"である"version"が、1つを 　　　超える"version"の"DAV:predecessort-set"に現れる場合、CHECKIN 　　　リクエストは失敗しなければならない（MUST）。 　　　(DAV:checkin-fork-discouraged): "DAV:checkin-fork"が 　　　"DAV:discouraged"である"version"が1つを超える"version"の 　　　"DAV:predecessor-set"中に現れると、CHECKINリクエストは失敗し 　　　なければならない（MUST）。但し、"DAV:fork-ok"がリクエストボディ 　　　中に指定されている場合はこの限りではない。 Postconditions: 　　　(DAV:create-version): リクエストは、"DAV:checked-out"で指定され 　　　る"version"の"version history"中に、新しい"version"を作成しなけ 　　　ればならない（MUST）。リクエストは、新しい"version"のための新し 　　　い個別のURLを配置しなければならず（MUST）、そのURLはその"version" 　　　以外のいかなるリソースともかぶってはならない（MUST NOT）。新しい 　　　"version"のためのURLは、"Location"レスポンスヘッダ内で返却されな 　　　ければならない（MUST）。 Clemm, et al. Standards Track [Page 39] RFC 3253 Versioning Extensions to WebDAV March 2002 　　　(DAV:initialize-version-content-and-properties): 　　　新しい"version"の内容、デッドプロパティDAV:resourcetype,そして 　　　DAV:predecessor-setは、"check out"されたリソースからコピーされな 　　　ければならない（MUST）。新しい"version"に対応した"DAV:version-name" 　　　は、同じ"version history"中にある他の"version"の全ての"DAV:version-name" 　　　と区別可能なサーバ定義のものでなくてはならない。 　　　(DAV:checked-in): request-URLが"version-controlled resource"を 　　　指定し、"DAV:keep-checked-out"がそのリクエストボディに指定され 　　　ていない場合は、"version-controlled resource"の"DAV:checked-out" 　　　プロパティは、削除されなければならず（MUST）、新しい"version"を 　　　指す"DAV:checked-in"プロパティが追加されなければならない（MUST）。 　　　(DAV:keep-checked-out): DAV:keep-checked-outがリクエストボディに 　　　指定された場合、"check-out"されたリソースの"DAV:checked-out"プロ 　　　パティは、新しい"version"を指すようにアップデートされなくてはな 　　　らない（MUST）。 4.4.1 Example - CHECKIN >>REQUEST CHECKIN /foo.html HTTP/1.1 Host: www.webdav.org Content-Length: 0 >>RESPONSE HTTP/1.1 201 Created Location: http://repo.webdav.org/his/23/ver/32 Cache-Control: no-cache 　 この例では、"version-controlled resource"である/foo.htmlがチェックインされ、 　 http://repo.webdav.org/his/23/ver/32 に新しい"version"が作成されている。 4.5 UNCHECKOUT Method 　 UNCHECKOUTリクエストは、"check-out"された"version-controlled resource" 　 のCHECKOUTをキャンセルし、"version-controlled resource"の状態を 　 CHECKOUT前の状態にもどすために用いられる。 　 UNCHECKOUTリクエストが失敗すると、サーバはUNCHECKOUTリクエストの 　 いかなる部分的な（実行結果）結果もアンドゥしなければならない（MUST）。 Clemm, et al. Standards Track [Page 40] RFC 3253 Versioning Extensions to WebDAV March 2002 　 順序： Marshalling: 　　　リクエストボディが含まれる場合、それは"DAV:uncheckout"XMLエレ 　　　メントでなければならない。 　　　リクエストが成功し、その結果レスポンスボディも返却されるなら、 　　　それは"DAV:uncheckout-response"XMLエレメントでなくてはならない 　　　（MUST）。 　　　レスポンスは"Cache-Control:no-cache"ヘッダを含まなければならな 　　　い（MUST）。 Preconditions: 　　　(DAV:must-be-checked-out-version-controlled-resource): 　　　request-URLは、"DAV:checked-out"プロパティをともなう"version-controlled 　　　resource"を指定しなくてはならない。 Postconditions: 　　　(DAV:cancel-checked-out): "DAV:checked-in"プロパティの値は、 　　　リクエスト前の"DAV:checked-out"プロパティの値であり、 　　　"DAV:checked-out"プロパティは削除される。 　　　(DAV:restore-content-and-dead-properties): 　　　"version-controlled resource"の内容とデッドプロパティは、そのリ 　　　ソースの"DAV:checked-in"で指定される"version"にコピーされる。 4.5.1 Example - UNCHECKOUT >>REQUEST UNCHECKOUT /foo.html HTTP/1.1 Host: www.webdav.org Content-Length: 0 >>RESPONSE HTTP/1.1 200 OK Cache-Control: no-cache 　 この例において、http://www.webdav.org/foo.html と指定された 　 "version-controlled resource"の内容とデッドプロパティは、その 　 "version-controlled resource"に対して最も最近実施されたCHECKOUTの実行 　 直前の値に復元される。 Clemm, et al. Standards Track [Page 41] RFC 3253 Versioning Extensions to WebDAV March 2002 4.6 Additional OPTIONS Semantics 　 "サーバが"checkout-in-place"機能をサポートするならば、いかなるバー 　 ジョニングプロパティ、レポート、メソッドをサポートするあらゆるリソー 　 スに対するOPTIONSリクエストに対するDAVレスポンスヘッダ中のフィールド 　 として、"checkout-in-place"を含まなければならない（MUST）。 5 Version-History Feature 　 その"version history"のための"version-controlled resources"がすべて 　 削除された後でも、"version history"にアクセスすることは多くの場合有 　 用である。サーバは、"version history resource"をサポートすることで 　 この機能性を提供する。 　 "version history resource"は、サーバが指定した名前空間に存在するリ 　 ソースであり、その結果"version-controlled resource"の削除や移動に 　 よる影響を受けない。"version history resource"は、リソースの全ての 　 状態に論理的に適合するようなプロパティを付加するのに適切な場所であ 　 る。"DAV:expand-property"レポート（Section 3.8を参照のこと）は、 　 その"version history"中の全てのバージョンに関していろいろと有用な 　 レポートを提供するために、"version history resource"の 　 "DAV:version-set"に対して適用できる。 5.1 Version History Properties 　 "version history"の"DAV:resourcetype"は、"DAV:version-history"でな 　 ければならない。 　 "version-history"機能は、"version history"について以下のプロパティを 　 必要とする(REQUIRED)。 5.1.1 DAV:version-set (protected) 　 このプロパティは、この"version history"の各バージョンを指定する。 5.1.2 DAV:root-version (computed) 　 このプロパティは、この"version history"の"root version"を指定する。 5.2 Additional Version-Controlled Resource Properties 　 "version-history"機能は、"version-controlled resource"について 　 以下のプロパティを必要とする(REQUIRED)。 Clemm, et al. Standards Track [Page 42] RFC 3253 Versioning Extensions to WebDAV March 2002 5.2.1 DAV:version-history (computed) 　 このプロパティは、この"version-controlled resource"の 　 "DAV:checked-in"もしくは"DAV:checked-out"で指定される"version"の 　 ための"version history resource"を指定する。 5.3 Additional Version Properties 　 "version-history"機能は、"version"について以下のプロパティを 　 必要とする(REQUIRED)。 5.3.1 DAV:version-history (computed) 　 このプロパティは、この"version"を含む"version history"を指定する。 5.4 DAV:locate-by-history Report 　 多くのプロパティが、ある"version history"から"version"を指定する。 　 これは、その"version history"に対応した"version-controlled resource" 　 の場所を効率的につきとめる（探し出す）ことが出来るため、非常に有 　 用である。 　 "DAV:locate-by-history"レポートはコレクションに対して適用され、 　 指定した"version history resource"に対応する"version-controlled 　 resource"であるコレクションのメンバ（の場所）をつきとめる（探し 　 出す）ことができるようになる。 　 順序： Marshalling: 　　　リクエストボディは、"DAV:locate-by-history"XMLエレメントでなけ 　　　ればならない（MUST）。 　　　prop: RFC2518の Section 12.11 を参照のこと。 　　　成功したリクエストのレスポンスボディは、"DAV:multistatus"XML 　　　エレメントでなければならない（MUST）。そしてそのXMLエレメント 　　　には、request-URLで指定されたコレクションのメンバである全ての 　　　"version controlled resource"が含まれる。そして、request-URLの 　　　"DAV:version-history"プロパティは、リクエストボディで指定される 　　　"version history resource"の1つを指定する。 　　　リクエストボディ中の"DAV:prop"エレメントは、どのプロパティがレ 　　　スポンスボディ中の"DAV:prop"エレメントでレポートされるべきかを 　　　指定する。 Clemm, et al. Standards Track [Page 43] RFC 3253 Versioning Extensions to WebDAV March 2002 Preconditions: 　　　(DAV:must-be-version-history): リクエストボディ中の 　　　"DAV:version-history-set"エレメントの各メンバは、"version history 　　　resource"を指定しなければならない（MUST）。 5.4.1 Example - DAV:locate-by-history Report >>REQUEST REPORT /ws/public HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://repo.webdav.org/his/23 http://repo.webdav.org/his/84 http://repo.webdav.org/his/129 >>RESPONSE HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.webdav.org/ws/public/x/test.html http://repo.webdav.org/his/23 HTTP/1.1 200 OK Clemm, et al. Standards Track [Page 44] RFC 3253 Versioning Extensions to WebDAV March 2002 　 この例では、3つ指定した"version history resource"のうち1つが 　 "version-controlled resource"である /ws/public の 　 "version-controlled"メンバが1つだけ存在する。特に、 /ws/public/x/test.htmlは、http://repo.webdav.org/his/23に対応した 　 "version-controlled resource"である。 5.5 Additional OPTIONS Semantics 　 サーバが"version-history"機能をサポートするならば、全てのバージョ 　 ニングプロパティやレポートやメソッドをサポートする全てのリソース 　 において、OPTIONSリクエストに対応したDAVレスポンスには、 　 "version-history"フィールドが含まれなければらない（MUST）。 　 "DAV:version-history-collection-set"エレメントは、リクエストボディに 　 含まれてもよく（MAY）、この時そのエレメントは"version history resource" 　 を含んでも良いコレクションを指定するために用いられる。 　 追加の順序： Additional Marshalling: 　　　XMLリクエストボディが含まれる場合、"DAV:options"XMLエレメントでな 　　　ければならない（MUST）。 　　　ANY 値：最大1つの"DAV:version-history-collection-set"エレメントを 　　　ともなうエレメントの並び 　　　リクエストが成功してXMLレスポンスボディが返ってくる場合、それは 　　　"DAV:options-response"XMLエレメントでなければならない（MUST）。 　　　ANY 値：最大1つの"DAV:version-history-collection-set"エレメントを 　　　ともなうエレメントの並び 　　　"DAV:version-history-collection-set"がリクエストボディに含まれる 　　　場合、成功したリクエストに対応するレスポンスボディは 　　　"DAV:version-history-collection-set"エレメントを含まなければなら 　　　ない（MUST）。そしてこのエレメントは、"version history"を含むかも 　　　しれないコレクションを指定する。指定されたコレクションは、コレク 　　　ションツリーのrootコレクションであっても良く（MAY）、そのツリー 　　　の全てのコレクションは"version history"を含むかもしれない。異な 　　　るサーバがURL名前空間の異なる部分を制御できるため、同じホスト上の 　　　異なるリソースが異なる"DAV:version-history-collection-set"の値を 　　　持っていても良い（MAY）。指定したコレクションは、リソース（が置か 　　　れるの）とは異なるホストに置かれても良い（MAY）。 Clemm, et al. Standards Track [Page 45] RFC 3253 Versioning Extensions to WebDAV March 2002 5.6 Additional DELETE Semantics Additional Postconditions: 　　　(DAV:delete-version-set): リクエストが"version history"を削除 　　　したら、リクエストは"version history"中の"DAV:version-set"にあ 　　　る全ての"version"を削除しなければならず（MUST）、そして"version" 　　　の削除の"postconditions"（Section 3.13 を参照）を満足しなければ 　　　ならない（MUST）。 　　　(DAV:version-history-has-root):リクエストが"version history"の 　　　"root version"を削除したら、リクエストはその"version history"中に 　　　残された他の"version"全ての"ancestor"であるほかの"version"を参照 　　　するように"DAV:root-version"をアップデートしなければならない 　　　（MUST）。この"postcondition"の結果、全ての"version history"は 　　　最低1つの"version"を持ち、、全ての"version"を削除するためには 　　　"version history resource"を削除することである。 5.7 Additional COPY Semantics Additional Preconditions: 　　　(DAV:cannot-copy-history): request-URLが"version-history"を指定 　　　したら、リクエストは失敗しなければならない（MUST）。 　　　同じ内容とデッドプロパティを持つ"version"に対応した他の 　　　"version history"を作成するためには、適切な順序でVERSION-CONTROL、 　　　CHECKOUT、PUT、PROPPATCH、CHECKINリクエストが発行されなければ 　　　ならない（MUST）。 5.8 Additional MOVE Semantics Additional Preconditions: 　　　(DAV:cannot-rename-history): request-URLで"version history"が 　　　指定されたら、リクエストは失敗しなければならない（MUST）。 5.9 Additional VERSION-CONTROL Semantics Additional Postconditions: 　　　(DAV:new-version-history): リクエストが新しい"version history"を 　　　生成したら、リクエストはその"version history"に対応した新しいサー 　　　バ定義のURLを割り当てなければならない（MUST）。このURLは、他のい 　　　かなるリソースも認識するものであってはならず（MUST NOT）、そして 　　　この"version history"以外のリソースを認識してはならない（MUST NOT）。 Clemm, et al. Standards Track [Page 46] RFC 3253 Versioning Extensions to WebDAV March 2002 5.10 Additional CHECKIN Semantics Additional Postconditions: 　　　(DAV:add-to-history): 新しい"version resource"に対応したURLは、 　　　"DAV:checked-out"で指定された"version"の"version history"の 　　　"DAV:version-set"に追加されなければならない（MUST）。 6 Workspace Feature 　 複数のユーザが同じ"version history"に並列に"version"を追加するのを 　 許可するために、同じ"version history"に対応した複数の"check-out"さ 　 れたリソースを サーバ上に配置することが必要となる。しかしながら、 　 もし一ユーザのみがリソースを変更する場合、そのユーザは時々「プライ 　 ベートな」"version"を作成したり、そのバージョンを後で公開したりす 　 ることを望むだろう。このような機能性を提供するための1つの方法は、 　 クライアントが"check-out"されたリソースのカレントセットの履歴を保 　 持しておくことだが、この方法はクライアントに依存する。これは、 　 Section 8 で定義される"working-resource"という機能である。この機能性 　 を提供するためのほかの方法は、クライアント側で持続的に状態を保持す 　 ることを避け、そのかわりに、サーバは、"check-out"されたリソースの 　 組に関連したユーザ（人間）にとって意味のある名前空間を維持する。こ 　 れは"workspace"機能であり、本Sectionにて定義される。 　 "workspace"機能は、"workspace resource"を導入する。"workspace resource" 　 は、メンバとして関連する"version-controlled resource"と 　 "non-version-controlled resource"を持つコレクションである。 　 同時に異なる"version"や"version-controlled resource"の組のコンフィ 　 グレーションを公開するために複数の"workspace" が使用可能である。 　 ある"workspace"内に見えるまた他の"workspace"中の"version-controlled 　 resource"に変更を加えるためには、その"version-controlled resource" 　 は、"check in"されなければならず、それから新しい"version"の内容と 　 デッドプロパティを表示するように他の"workspace"に存在する適切な 　 "version-controlled resource"がアップデートされる。 　 明白なマージ（Section 11 を参照のこと）および"baselining"セマンティ 　 クス（Section 12 を参照のこと）を保証するために、"workspace"は与え 　 られた"version history"に対応した"version-controlled resource"を最 　 大1つ含んでよい。これは、明白なマージを行うための必要条件である。 　 というのも、MERGEメソッドは、どの"version-controlled resource"が与 　 えられた"version"とマージされるのかを指定しなければならないからだ。 　 これは明白な"baselining"に必要な条件である。というのも、"baseline" 　 は、与えられた"version-controlled resource"に対応する1つの"version" 　 しか選べないからだ。 　 最初に、空の"workspace"が作成される。"non-version-controlled resource" 　 はPUTやMKCOLのような通常のWebDAVリクエストを発行することで"workspace"に 　 追加できる。"version-controlled resource"については、VERSION-CONTROL 　 リクエストを発行することで"workspace"に追加することが可能である。"baseline" 　 機能がサポートされる場合は、"workspace"内のコレクションは"baseline control" 　 配下に置かれ、それから既存の"baseline"によって初期化される。 Clemm, et al. Standards Track [Page 47] RFC 3253 Versioning Extensions to WebDAV March 2002 6.1 Workspace Properties 　 "workspace"機能は、"workspace"のプロパティとして以下のものを導入する。 6.1.1 DAV:workspace-checkout-set (computed) 　 このプロパティは、この"workspace"を指定する"DAV:workspace"プロパティを 　 持つ"check-out"された各リソースを指定する。 6.2 Additional Resource Properties 　 "workspace"機能は、WebDAVリソースに以下のプロパティを導入する。 6.2.1 DAV:workspace (protected) 　 "workspace resource"の"DAV:workspace"プロパティは、自分自身を指定 　 しなくてはならない（MUST）。他のタイプのリソースの"DAV:workspace" 　 プロパティは、そのリソースの親コレクションの"DAV:workspace"である 　 のと同様でなければならない（MUST）。 6.3 MKWORKSPACE Method 　 MKWORKSPACEリクエストは、新しい"workspace resource"を作成する。 　 サーバは、"workspace"の生成を特定のコレクションに制限してもよい（MAY）が、 　 クライアントは"DAV:workspace-collection-set"をともなうOPTIONSリクエスト 　 （Section 6.4 を参照のこと）からそれらのコレクションの場所を決定できる。 　 MKWORKSPACEリクエストが失敗したら、サーバの状態はリクエスト前の状態に 　 戻されなければならない（MUST）。 　 順序： Marshalling: 　　　リクエストボディが含まれるならば、"DAV:mkworkspace"XMLエレメントで 　　　ある必要がある（MUST）。 　　　リクエストが成功してレスポンスにレスポンスボディが含まれる場合、 　　　それは"DAV:mkworkspace-response"XMLエレメントでなくてはならない 　　　（MUST）。 Clemm, et al. Standards Track [Page 48] RFC 3253 Versioning Extensions to WebDAV March 2002 　　　レスポンスは、Cache-Control:no-cacheへっだを含まなければならない 　　　（MUST）。 Preconditions: 　　　(DAV:resource-must-be-null): リソースは、request-URLの場所に 　　　存在してはならない（MUST）。 　　　(DAV:workspace-location-ok): request-URLは、"workspace"が作成可能な 　　　場所を指定しなければならない（MUST）。 Postconditions: 　　　(DAV:initialize-workspace): 新しい"workspace"がrequest-URLに存在する。 　　　"workspace"の"DAV:resourcetype"は"DAV:collection"でなくてはならない 　　　（MUST）。"workspace"の"DAV:workspace"は、"workspace"を指定しなくて 　　　はならない（MUST）。 6.3.1 Example - MKWORKSPACE >>REQUEST MKWORKSPACE /ws/public HTTP/1.1 Host: www.webdav.org Content-Length: 0 >>RESPONSE HTTP/1.1 201 Created Cache-Control: no-cache 　 この例では、新しい"workspace"が http://www.webdav.org/ws/public に作成 　 された。 6.4 Additional OPTIONS Semantics 　 サーバが"workspace"機能をサポートするならば、全てのバージョニング 　 プロパティやレポートやメソッドをサポートする全てのリソースに対する 　 OPTIONSリクエストのレスポンスに含まれる"DAV"レスポンスヘッダのフィー 　 ルドに、"workspace"が含まれなければならない（MUST）。 　 サーバが"workspace"機能をサポートするならば、"checkout-in-place"機能と 　 "version-history"機能もサポートしなければならない（MUST）。 　 "DAV:workspace-collection-set"エレメントは、"workspace resource"を含める 　 ことができるコレクションを指定するために、リクエストボディに含めてもよい 　 （MAY）。 Clemm, et al. Standards Track [Page 49] RFC 3253 Versioning Extensions to WebDAV March 2002 　 追加の順序： Additional Marshalling: 　　　XMLリクエストボディが含まれるならば、"DAV:options"XMLエレメントで 　　　でなければならない（MUST）。 　　　ANY 値：最大1つの"DAV:workspace-collection-set"エレメントを伴う 　　　　　　　エレメントの並び 　　　リクエストが成功して返却されるXMLレスポンスボディがあれば、それは 　　　"DAV:options-response"XMLエレメントでなくてはならない（MUST）。 　　　ANY 値：最大1つの"DAV:workspace-collection-set"エレメントを伴う 　　　　　　　エレメントの並び 　　　"DAV:workspace-collection-set"がリクエストボディに含まれていると、 　　　レスポンスが成功した時のレスポンスボディには、"DAV:workspace-collection" 　　　エレメントが含まれなくてはならない（MUST）。このエレメントは、 　　　"workspace"を含んでもよいコレクションが指定されている。指定された 　　　コレクションは、ツリーコレクションの"root collection"であってもよく 　　　（MAY）、全てのコレクションは"workspace"を含むことができる（MAY）。 　　　異なるサーバは異なる名前空間を制御できるため、同じホスト上の異なる 　　　リソースは異なる"DAV:workspace-collection-set"の値を持っていてもよ 　　　い（MAY）。指定されたコレクションは、リソースとは異なるホストに配 　　　置されていてもよい（MAY）。 Clemm, et al. Standards Track [Page 50] RFC 3253 Versioning Extensions to WebDAV March 2002 6.4.1 Example - OPTIONS >>REQUEST OPTIONS /doc HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx >>RESPONSE HTTP/1.1 200 OK DAV: 1 DAV: version-control,checkout-in-place,version-history,workspace Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://repo.webdav.org/his http://www.webdav.org/public/ws http://www.webdav.org/private/ws 　 この例では、サーバはClass 1 DAVサポートおよび、"basic-server-workspace" バージョニングサポートを提供することを示している。さらにサーバーは、 　 リクエストしたversion-history-resourcesおよびworkspace-resourcesの位置を 　 示します。 6.5 Additional DELETE Semantics Additional Postconditions: 　　　(DAV:delete-workspace-members): "workspace"が削除されたら、 　　　削除された"workspace"の"DAV:workspace"プロパティ内の"workspace"で 　　　指定される全てのリソースは削除されなければならない（MUST）． Clemm, et al. Standards Track [Page 51] RFC 3253 Versioning Extensions to WebDAV March 2002 6.6 Additional MOVE Semantics Additional Postconditions: 　　　(DAV:workspace-member-moved): request-URLが"workspace"を指定しない 　　　場合は、移動先の"DAV:workspace"は移動先の親コレクションの"DAV:workspace" 　　　と同じ値を持つようにアップデートされなければならない（MUST）。 　　　(DAV:workspace-moved): request-URLが"workspace"を指定する場合は、 　　　"DAV:workspace"プロパティ中の"workspace"への全ての参照はこの 　　　"workspace"の新しい配置場所を参照するようにアップデートされなけれ 　　　ばならない。 6.7 Additional VERSION-CONTROL Semantics 　 VERSION-CONTROLリクエストは、存在する"version history"に対応する新しい 　 "version-controlled resource"を作成する。このことは、複数の"workspace" 　 中の同じ"version history"に対応する"version-controlled resource"を作成 　 することをゆるす。 　 追加の順序： Additional Marshalling: 　　　ANY 値：多くても1つの"DAV:version"エレメントを含むエレメントの並び Additional Preconditions: 　　　(DAV:cannot-add-to-existing-history): "DAV:version-control"リクエスト 　　　ボディエレメントが"DAV:version"エレメントを含む場合、request-URLは 　　　リソースを指定してはならない（MUST）。 　　　(DAV:must-be-version): "DAV:version"エレメントの"DAV:href"は、"version" 　　　を指定しなくてはならない。 　　　(DAV:one-version-controlled-resource-per-history-per-workspace): 　　　"DAV:version-control"リクエストボディが"version"を指定し、そして 　　　もしrequest-URLが"workspace"のメンバであるならば、リクエストボディ 　　　内で指定される"version"の"version history"からの全てのバージョンを 　　　識別する"DAV:checked-in"プロパティか"DAV:checked-out"プロパティを 　　　持つ"workspace"の"version-controlled member"はまだ存在してはなら 　　　ない（MUST NOT）。 Clemm, et al. Standards Track [Page 52] RFC 3253 Versioning Extensions to WebDAV March 2002 Additional Postconditions: 　　　(DAV:new-version-controlled-resource): request-URL がリソースを 　　　指定しない場合、新しい"version-controlled resource"はrequest-URLの 　　　ところに存在し、その内容とデッドプロパティはリクエストボディ内の 　　　"version"のもので初期化される。そしてその"DAV:checked-in"プロパティは、 　　　その"version"を指定する。 6.7.1 Example - VERSION-CONTROL (using an existing version history) >>REQUEST VERSION-CONTROL /ws/public/bar.html HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://repo.webdav.org/his/12/ver/V3 >>RESPONSE HTTP/1.1 201 Created Cache-Control: no-cache 　 この例では、新しい"version-controlled resource"が /ws/public/bar.html に 　 作成される。新しい"version-controlled resource"の内容とデッドプロパティは、 　 http://repo.webdav.org/his/12/ver/V3 で指定される"version"の内容とデッド 　 プロパティを用いて初期化される。 7 UPDATE Feature 　 "update"機能は、そのリソースの"version history"より他の"version"の 　 リソースになるために、"check-in"された"version-controlled resource"の 　 状態を変更するためのしくみを提供する。 7.1 UPDATE Method 　 UPDATEメソッドは、"version-controlled resource"の"version history"より 　 特定の"version"になるために、"check-in"された"version-controlled resource" 　 （"update target"）の内容とデッドプロパティを変更する。 　 UPDATEリクエストのレスポンスは、リクエストによって変更されたリソースを 　 指定する。その結果、クライアントは維持されている全てのキャッシュされた 　 状態を効果的にアップデートすることが出来る。UPDATEメソッドの拡張は、複数 　 のリソースが単一のUPDATEリクエストにより更新されることを許す（Section 　 12.13を参照のこと）。 Clemm, et al. Standards Track [Page 53] RFC 3253 Versioning Extensions to WebDAV March 2002 　 順序： Marshalling: 　　　リクエストボディは、"DAV:update"エレメントでなくてはならない（MUST）。 　　　ANY 値：最大1つの"DAV:version"エレメントおよび最大1つの"DAV:prop" 　　　　　　エレメントをともなうエレメントの並び。 　　　prop: RFC2518 の Section 12.11 を参照のこと。 　　　リクエストが成功した時、そのレスポンスは207 Multi-Statusでなくては 　　　ならず（MUST）、レスポンスボディ中の"DAV:multistatus"XMLエレメント 　　　は、リクエストで更新された全てのリソースが指定される。 　　　multistatus: RFC2518 の Section 12.9 を参照のこと。 　　　レスポンスには、"Cache-Control:no-cache"ヘッダを含まなければなら 　　　ない（MUST）。 Postconditions: 　　　(DAV:update-content-and-properties): リクエストボディ中の 　　　"DAV:version"エレメントが、request-URLで指定される"version-controlled 　　　resource"の"DAV:checked-in"の"version"と同じ"version history"である 　　　"version"を指定する時、"version-controlled resource"の内容とデッドプ 　　　ロパティ"DAV:version"エレメントで指定される"version"と同じもので 　　　なくてはならず（MUST）、そして"version-controlled resource"の 　　　"DAV:checked-in"プロパティは、この"version"を指定しなくてはならない 　　　（MUST）。request-URLは、レスポンスボディの中の"DAV:response"エレメ 　　　ントに出現しなくてはならない（MUST）。 　　　(DAV:report-properties): "DAV:prop"がリクエストボディで指定されたら、 　　　"DAV:prop"エレメントで指定されたプロパティはレスポンスボディ中の 　　　"DAV:response"エレメント内でレポートされなくてはならない（MUST）。 Clemm, et al. Standards Track [Page 54] RFC 3253 Versioning Extensions to WebDAV March 2002 7.1.1 Example - UPDATE >>REQUEST UPDATE /foo.html HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx http://repo.webdav.org/his/23/ver/33 >>RESPONSE HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Cache-Control: no-cache http://www.webdav.org/foo.html HTTP/1.1 200 OK 　 この例では、http://repo.webdav.org/his/23/ver/33 の内容とデッドプロ 　 パティが "version-controlled resource"である/foo.html にコピーされて 　 おり、/foo.html の "DAV:checked-in"プロパティが 　 http://repo.webdav.org/his/23/ver/33 を指し示すように更新されている。 7.2 Additional OPTIONS Semantics 　 サーバが"update"機能をサポートするならば、バージョニングプロパティや 　 レポートやメソッドをサポートする全てのリソースに対するOPTIONSリクエ 　 ストのレスポンス中に含まれる"DAV"レスポンスヘッダのフィールドに 　 "update"が含まれなければならない（MUST）。 Clemm, et al. Standards Track [Page 55] RFC 3253 Versioning Extensions to WebDAV March 2002 8 Label Feature 　 "version"の"label"は、"version history"中のある１つの"version"を、 　 同じ"version history"中の他のすべての"version"から区別する文字列 　 である。"label"は、サーバーによって自動的に割り当てられるか、"version" 　 にとって意味のある名前をつけるためにクライアントによって割り当て 　 られる。与えた"label"は、せいぜい1つの"version"にのみ割り当てる 　 ことができる。しかし、クライアントが割り当てた"label"は、いつでも 　 他の"version"に割り当てなおすことができる。同じ"version history" 　 において、"version"に割り当てることができる"label"はせいぜい1つ 　 である（訳注：同じ"version history"中で、複数の"version"に同じ 　 "label"文字列を割り当てることができないことを意味する）が、異なる 　 "version history"に存在する"version"が同じ"label"を持つことがある 　 ことは注意せよ。 　 あるメソッドにおいて、request-URLが"version-controlled resource"を 　 指定した場合は、"label"は、メソッドが"version-controlled resource" 　 の"version history"から"label"によって選択された"version"に対して 　 リクエストを適用するため"Label"リクエストヘッダ(Section 8.3を 　 参照のこと）内で指定される。 8.1 Additional Version Properties 　 "label"機能は、"version"に対して以下の必須（REQUIRED）プロパティを 　 導入する。 8.1.1 DAV:label-name-set (protected) 　 このプロパティは、この"version"を現在選択する"label"を含む。 PCDATA value: string 8.2 LABEL Method 　 LABELリクエストは"version"に対して適用され、選択した"version"の 　 "label"を変更する。"label"名が記録されたり取得されたりする際には、その 　 の大文字小文字の区別は保持されなければならない（MUST）。2つの"label"名 　 （に対応するもの）を一致するかしないか比較する時は、サーバは 　 URLエスケープされた"case-sensitive"なUTF-8エンコードのURLを2つの"label"名 　 の比較のために用いるべきである（SHOULD）。 　 LABELリクエストが"check-in"された"version-controlled resource"に対して 　 発行される場合、その操作は"version-controlled resource"の"DAV:checked-in" 　 で指定される"version"に対して適用されなければならない（MUST）。 Clemm, et al. Standards Track [Page 56] RFC 3253 Versioning Extensions to WebDAV March 2002 　 順列： Marshalling: 　　　リクエストボディは、"DAV:label"エレメントでなければならない（MUST）。 　　　ANY 値：せいぜい1つの"DAV:add"エレメントもしくは"DAV:set"エレメント 　　　　　　　もしくは"DAV:remove"エレメントをともなうエレメントの並び PCDATA value: string 　　　リクエストは、"Lable"ヘッダを含んでも良い（MAY）。 　　　リクエストは、"Depth"ヘッダを含んでも良い（MAY）。"Depth"ヘッダが 　　　含まれない場合は、"Depth:0"が指定されたとみなされる。通常の"Depth" 　　　のセマンティクスが適用され、リクエストはrequest-URLで指定されるコレ 　　　クションおよび"Depth"の範囲内にあるの全てのメンバに対して適用される。 　　　"Depth"ヘッダが含まれるリクエストが、リクエストの対象になったいずれ 　　　かのリソースで失敗した場合ｈあ、レスポンスは207 Multi-Statusを返し、 　　　リクエストが失敗したリソース全てについて指定しなくてはならない。 　　　リクエストが成功して、レスポンスにレスポンスボディが含まれるならば、 　　　それは"DAV:label-response"XMLエレメントでなくてはならない（MUST）。 　　　レスポンスには、"Cache-Control:no-cache"ヘッダを含まなくてはならな 　　　い（MUST）。 Preconditions: 　　　(DAV:must-be-checked-in): request-URLが"version-controlled resource"を 　　　指定するならば、"version-controlled resource"は"check-in"されてなければ 　　　ならない（MUST）。 　　　(DAV:must-select-version-in-history): "Label"リクエストヘッダが 　　　含まれており、request-URLが"version-controlled resource"を指定している 　　　ならば、指定された"label"は、"version-controlled resource"の 　　　"version history"から"version"を選択しなければならない（MUST）。 　　　(DAV:add-must-be-new-label): "DAV:add"がリクエストボディに指定されて 　　　いたら、指定された"label"は"version-controlled resource"の"version 　　　history"内にある全てのバージョンの"DAV:label-name-set"中に現れては 　　　ならない（MUST NOT）。 Clemm, et al. Standards Track [Page 57] RFC 3253 Versioning Extensions to WebDAV March 2002 　　　(DAV:label-must-exist): "DAV:remove"がリクエストボディに指定されて 　　　いたら、指定された"label"はそのバージョンの"DAV:label-name-set"に 　　　現れなくてはならない 　　　（MUST）。 Postconditions: 　　　(DAV:add-or-set-label): "DAV:add"もしくは"DAV:set"がリクエストボ 　　　ディに指定されていたら、指定された"label"は指定された"version"の 　　　"DAV:label-name-set"に現れなければならず（MUST）、その"version" 　　　の"version history"中に存在する他の全ての"version"の 　　　"DAV:label-name-set"に現れてはならない（MUST NOT）。 　　　(DAV:remove-label): "DAV:remove"がリクエストボディに指定されて 　　　いたら、指定された"label"は、その"version"の"version history"中に 　　　存在する全ての"version"の"DAV:label-name-set"に現れてはならない 　　　（MUST NOT）。 8.2.1 Example - Setting a label >>REQUEST LABEL /foo.html HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx default >>RESPONSE HTTP/1.1 200 OK Cache-Control: no-cache 　 この例では、"default"という"label"が/foo.htmlの"DAV:checked-in"で指定された 　 "version"に適用されている。 8.3 Label Header 　 あるメソッド（例：GET,PROPFIND）にて、request-URLが"version-controlled 　 resource"を指定したら、"Label"リクエストヘッダにおいて"label"を指定する 　 ことができ、その結果メソッドを"version-controlled resource"の"version 　 history"からその"label"で選択される"version"に対して適用することができる。 Clemm, et al. Standards Track [Page 58] RFC 3253 Versioning Extensions to WebDAV March 2002 　 "label"ヘッダの値は、"label"の名前であり、URLエスケープされたUTF-8で 　 エンコードされている。例えば、"release B.3"という"label"は、 　 以下のようなヘッダによって指定される。 Label: release%20B.3 　 "Label"ヘッダは、request-URLが"version-controlled resource"を指定しない 　 リクエストについては何の効果も及ぼさない。特に、request-URLが"version" 　 もしくは"version"を指定するリクエストについて、何の効果も及ぼしてはなら 　 ない（MUST）。 　 サーバは、"Label"ヘッダを含むキャッシュ可能なリクエスト（例：GET） 　 に対する成功レスポンス中に、"Label"を含むさまざまなHTTP-1.1ヘッダを 　 返却しなければならない。 8.4 Additional OPTIONS Semantics 　 サーバが"label"機能をサポートするならば、全てのバージョニングプロパティ、 　 レポートもしくはメソッドをサポートする全てのリソースに対するOPTIONSリク 　 エストで返却されるレスポンス中、"DAV"レスポンスヘッダのフィールドに 　 "label"を含まなければならない（MUST）。 8.5 Additional GET Semantics 　 追加の順序： Additional Marshalling: 　　　リクエストは、"Label"ヘッダを含んでも良い（MAY）。 The request MAY include a Label header. Additional Preconditions: 　　　(DAV:must-select-version-in-history): "Label"リクエストヘッダが 　　　含まれており、request-URLが"version-controlled resource"を指定して 　　　いるならば、指定された"label"は、"version-controlled resource"の 　　　"version history"中にある"version"を選択しなければならない（MUST）。 Additional Postconditions: 　　　(DAV:apply-request-to-labeled-version): request-URLが 　　　"version-controlled resource"を指定し、かつ"Label"リクエスト 　　　ヘッダが含まれる場合、レスポンスは"version-controlled resource"の 　　　内容よりはむしろ指定された"version"の内容を含まなければならない 　　　（MUST）。 8.6 Additional PROPFIND Semantics 　 追加の順序： Additional Marshalling: 　　　リクエストは、"Label"ヘッダを含んでもよい（MAY）。 Clemm, et al. Standards Track [Page 59] RFC 3253 Versioning Extensions to WebDAV March 2002 Additional Preconditions: 　　　(DAV:must-select-version-in-history): リクエストに"Label"リクエスト 　　　ヘッダが含まれており、request-URLが"version-controlled resource"を 　　　指定しているならば、指定した"label"は、"version-controlled resource" 　　　の"version history"中にある"version"を選択しなければならない（MUST）。 Additional Postconditions: 　　　(DAV:apply-request-to-labeled-version): request-URLが 　　　"version-controlled resource"を指定し、かつ"Label"リクエストヘッダが 　　　含まれる場合、レスポンスには"version-controlled resource"の 　　　ものよりはむしろ、指定された"version"のプロパティを含まなければ 　　　ならない（MUST）。 8.7 Additional COPY Semantics Additional Marshalling: 　　　リクエストは、"Label"ヘッダを含んでもよい（MAY）。 Additional Preconditions: 　　　(DAV:must-select-version-in-history): "Label"リクエストヘッダが含まれ、 　　　かつrequest-URLが"version-controled resource"を指定していたら、指定した 　　　"label"は"version-controlled resource"の"version history"内の"version"を 　　　選択しなければならない（MUST）。 Additional Postconditions: 　　　(DAV:apply-request-to-labeled-version): request-URLが 　　　"version-controlled resource"を指定して、かつ"Label"リクエストヘッダが 　　　含まれる場合、リクエストは"version-controlled resource"のものよりは 　　　むしろ、指定された"version"のプロパティと内容をコピーしなければ 　　　ならない（MUST）。 8.8 Additional CHECKOUT Semantics 　 サーバが"working-resource"オプションをサポートするならば、"LABEL"ヘッダ 　 は指定された"label"により選択される"version"をチェックアウトするために 　 含まれていてもよい。 Additional Marshalling: 　　　リクエストは"Label"ヘッダを含んでいても良い（MAY）。 Clemm, et al. Standards Track [Page 60] RFC 3253 Versioning Extensions to WebDAV March 2002 Additional Preconditions: 　　　(DAV:must-select-version-in-history): "Label"リクエストヘッダが含まれ、 　　　かつrequest-URLが"version-controlled resource"を指定するならば、指定 　　　された"label"は"version-controlled resource"の"version history"内の 　　　"version"を選択しなくてはならない（MUST）。 　　　(DAV:must-not-have-label-and-apply-to-version): "Label"リクエストヘッダ 　　　が含まれるならば、リクエストボディは"DAVA:apply-to-version"エレメントを 　　　含んではならない（MUST NOT）。 Additional Postconditions: 　　　(DAV:apply-request-to-labeled-version): request-URLが"check-in"された 　　　"version-controlled resource"を指定しており、かつ"Label"リクエストヘッダ 　　　が含まれるならば、CHECKOUTはその"version-controlled resource"そのものに 　　　ではなく"label"で指定された"version"に対して適用されなければならない 　　　（MUST）。 8.9 Additional UPDATE Semantics 　 UPDATEリクエストのリクエストボディが"DAV:label-name"エレメントを含んで 　 いたら、アップデートのターゲットはrequest-URLで指定されるリソースであり、 　 アップデート元はアップデートターゲットの"version history"から指定された 　 "label"で選択される"version"である。 Additional Marshalling: 　　　ANY 値：せいぜい1つの"DAV:label-name"もしくは"DAV:version"エレメント 　　　（両方とも出てこない）を伴ったエレメントの並び。 PCDATA value: string 　　　リクエストは"Depth"ヘッダを含んでもよい（MAY）。"Depth"ヘッダが 　　　含まれない場合は、"Depth:0"であるとみなされる。通常の"depth"の 　　　セマンティクスが適用され、そしてリクエストはrequest-URLで指定された 　　　コレクションおよび、そのコレクション内で"Depth"の値を満たす全ての 　　　メンバに対して適用される。"Depth"ヘッダが含まれ、かつリクエストが 　　　何かのリソースで失敗したら、レスポンスは207 Multi-Statusを返し、 　　　そのレスポンスの中ではリクエストが失敗したリソースについて指定を 　　　しなければならない。 　　　 Additional Preconditions: 　　　(DAV:must-select-version-in-history): リクエストが"DAV:label-name" 　　　エレメントをリクエストボディに含むならば、"label"はrequest-URLで指定 　　　される"version-controlled resource"の"version history"内の"version" 　　　を選択しなければならない（MUST）。 Clemm, et al. Standards Track [Page 61] RFC 3253 Versioning Extensions to WebDAV March 2002 　　　(DAV:depth-update): リクエストが"Depth"ヘッダを含むならば、通常の 　　　"depth のセマンティクスが適用され、そしてリクエストはrequest-URLで 　　　指定されるコレクションおよび"Depth"値を満たすコレクションの全ての 　　　メンバに対して適用される。リクエストは、コレクションのメンバに対して 　　　適用されるに先立ち、まずコレクションに対して適用されなければならない 　　　（MUST）。というのも、"version-controlled collection"のアップデートは、 　　　そのコレクションのメンバシップ（membership）も変更する可能性がある 　　　からだ。 Additional Postconditions: 　　　(DAV:apply-request-to-labeled-version): "DAV:label-name"エレメント 　　　がリクエストボディ中に現れたら、"version-controlled resource"の 　　　内容とデッドプロパティはその"label"によって選択される"version"の 　　　内容とデッドプロパティにアップデートされなければならない（MUST）。 9 Working-Resource Feature 　 "working-resource"機能は、並行した開発をサポートするための"workspace" 　 機能についての選択肢を提供する。必要な"version"や"check-out"されるリ 　 ソースの構成（configuration）はサーバ上で管理される"workspace"機能と 　 違い、"working-resource"機能はクライアント上の構成（configuration）を 　 管理する。このことは、サーバの実装を簡略化するが、ユーザが（他のオフィ 　 スからや家からや旅行中など）物理的に異なるロケーションにあるクライアン 　 トより構成（configuration）にアクセスすることを許さない。他の相違点は、 　 "workspace"機能は、論理的な変更が完了して検証が完了するまではクライアン 　 トを共用資源のリネームを含む論理的な変更から隔離する。しかし、"working 　 resource"機能を使うと、全てのクライアントは共通の共有"version-controlled 　 resource"を使用し、各クライアントはMOVEの結果を可能な限り早く見ること 　 ができる。 　 サーバが"working-resource"機能をサポートし、"checkout-in-place"をサポー 　 トしない場合は、CHECKOUTリクエストは"working resource"を作成するためだけに 　 のみ使用され、"version-controlled resource"をチェックアウトするために 　 使用することは出来ない。サーバが"checkout-in-place"機能をサポートし、 　 "working-resource"機能をサポートしない場合は、CHECKOUTは"version-controlled 　 resource"の状態を"checked-in"から"checked-out"に変更するためだけに 　 使用される。 9.1 Additional Version Properties 　 "working-resource"機能は、"version"について以下の必要なプロパティを導入 　 する。 9.1.1 DAV:checkout-fork 　 このプロパティは、Section 4.1.1 で定義されている。 Clemm, et al. Standards Track [Page 62] RFC 3253 Versioning Extensions to WebDAV March 2002 9.1.2 DAV:checkin-fork 　 このプロパティは、Section 4.1.2 で定義されている。 9.2 Working Resource Properties 　 "working-resource"機能は、"working resource"について以下の必要な 　 プロパティを導入する。"working resource"は"check-out"されたリソー 　 スのため、"checked-out"リソースのために本ドキュメントで定義された 　 全てのプロパティを持つ。 9.2.1 DAV:auto-update (protected) 　 このプロパティは、"working resource"がチェックインされた時にアップデート 　 される"version-controlled resource"を指定する。 9.2.2 DAV:checkout-fork 　 このプロパティは、Section 4.2.1 で定義されている。 9.2.3 DAV:checkin-fork 　 このプロパティは、Section 4.2.2 で定義されている。 9.3 CHECKOUT Method (applied to a version) 　 CHECKOUTリクエストは、新しい"working resource"を作成するために、 　 "version" に対して適用される。"working resource"の内容とデッド 　 プロパティは、チェックアウトされた"version"のコピーである。 　 順序： Marshalling: 　　　リクエストボディが含まれる場合は、"DAV:checkout"XMLエレメントを 　　　含まなければならない。 　　　ANY 値：せいぜい1つの"DAV:apply-to-version"およびせいぜい1つの 　　　　　　　"DAV:fork-ok"エレメントを伴うエレメントの並び 　　　リクエストの成功に対応してレスポンスボディが返ってくるならば、 　　　それは"DAV:checkout-response"XMLエレメントでなければならない（MUST）。 Clemm, et al. Standards Track [Page 63] RFC 3253 Versioning Extensions to WebDAV March 2002 　　　レスポンスには、"LocatioN"ヘッダを含まなければならない（MUST）。 　　　レスポンスには、"Cache-Control:no-cache"ヘッダを含まなければ 　　　ならない（MUST）。 Preconditions: (DAV:checkout-of-version-with-descendant-is-forbidden): Section 4.3 を参照のこと。 (DAV:checkout-of-version-with-descendant-is-discouraged): Section 4.3 を参照のこと。 (DAV:checkout-of-checked-out-version-is-forbidden): Section 4.3 を参照のこと。 (DAV:checkout-of-checked-out-version-is-discouraged): Section 4.3 を参照のこと。 Postconditions: 　　　(DAV:create-working-resource): request-URLが"version"を指定して 　　　いたら、"Location"レスポンスヘッダは新しい"working resource"の 　　　URLを指定していなくてはならない（MUST）。新しい"working resource"の 　　　"DAV:checked-out"プロパティは、チェックアウトされた"version"を 　　　指定していなくてはならない（MUST）。"working resource"の内容と 　　　デッドプロパティは、"DAV:checked-out"で指定される"version"の 　　　内容とデッドプロパティのコピーでなくてはならない（MUST）。 　　　"working resource"の"DAV:predecessor-set"プロパティは、request-URLで 　　　指定される"version"であるように初期化されなければならない（MUST）。 　　　"working resource"の"DAV:auto-update"プロパティは存在してはな 　　　らない（MUST NOT）。 　　　(DAV:create-working-resource-from-checked-in-version): 　　　request-URLが"version-controlled resource"を指定し、かつリクエスト 　　　ボディ中に"DAV:apply-to-version"が指定されていたら、CHECKOUTは 　　　"DAV:checked-in"で指定される"version"に対して適用され、request-URLで 　　　指定された"version-controlled resource"そのものには適用されない。 　　　新しい"working resource"は、チェックインされたままである。 　　　"working resource"の"DAV:auto-update"プロパティは、"version-controlled 　　　resource"を指定しなくてはならない（MUST）。 Clemm, et al. Standards Track [Page 64] RFC 3253 Versioning Extensions to WebDAV March 2002 9.3.1 Example - CHECKOUT of a version >>REQUEST CHECKOUT /his/12/ver/V3 HTTP/1.1 Host: repo.webdav.org Content-Length: 0 >>RESPONSE HTTP/1.1 201 Created Location: http://repo.webdav.org/wr/157 Cache-Control: no-cache 　 この例では、http://repo.webdav.org/his/12/ver/V3 で指定された"version"が 　 チェックアウトされ、新しい"working resource"がhttp://repo.webdav.org/wr/157 　 に配置される。 9.4 CHECKIN Method (applied to a working resource) 　 CHECKINリクエストは、内容とデッドプロパティが"working resource"の内容 　 とデッドプロパティのコピーである新しい"version"を作成するために"working 　 resource"に対して適用される。"DAV:apply-to-version"フラグが有効な 　 CHECKOUTを"version-controlled resource"に対して適用し"working resource" 　 が生成されたために"working resource"の"DAV:auto-update"プロパティが設 　 定されたら、CHECKINリクエストは"version-controlled resource"の内容と 　 デッドプロパティも、新しい"version"の内容とデッドプロパティの内容に 　 アップデートする。 　 順序： Marshalling: 　　　リクエストボディが含まれる場合、"DAV:checkin"XMLエレメントでなくて 　　　はならない（MUST）。 　　　ANY 値：せいぜい1つの"DAV:fork-ok"エレメントを伴うエレメントの並び 　　　リクエストが成功して返ってくるレスポンスボディがある場合、それは 　　　"DAV:checkin-response"XMLエレメントでなければならない（MUST）。 　　　レスポンスには、"Cache-Control:no-cache"ヘッダを含まなければなら 　　　ない（MUST）。 Clemm, et al. Standards Track [Page 65] RFC 3253 Versioning Extensions to WebDAV March 2002 Preconditions: (DAV:must-be-checked-out): Section 4.4 を参照のこと。 (DAV:version-history-is-tree) Section 4.4 を参照のこと。 (DAV:checkin-fork-forbidden): Section 4.4 を参照のこと。 (DAV:checkin-fork-discouraged): Section 4.4 を参照のこと。 (DAV:no-overwrite-by-auto-update): 　　　チェックアウトされたリソースの"DAV:auto-update"プロパティが 　　　"version-controll resource"を指定していたら、チェックアウト 　　　されたリソースの"DAV:predecessor-set"プロパティによって指定 　　　される"version"のうち最低1つはその"version-controlled 　　　resource"の"DAV:checked-in"プロパティで指定される"version" 　　　そのものか"descendant"の"version"を指定しなければならない（MUST）。 Postconditions: (DAV:create-version): Section 4.4 を参照のこと。 (DAV:initialize-version-content-and-properties): 　　　Section 4.4 を参照のこと。 　　　(DAV:auto-update): チェックアウトされたリソースの"DAV:auto-update" 　　　プロパティが"version-controlled resource"を指定していたら、新しい 　　　"version"を伴うUPDATEリクエストはその"version-controlled resource" 　　　に対して適用されなければならない。 　　　(DAV:delete-working-resource): request-URLが"working resource"を 　　　指定しており、かつ"DAV:keep-checked-out"がリクエストボディで指定 　　　されていなければ、"working resource"は削除される。 9.4.1 Example - CHECKIN of a working resource >>REQUEST CHECKIN /wr/157 HTTP/1.1 Host: repo.webdav.org Content-Length: 0 >>RESPONSE HTTP/1.1 201 Created Location: http://repo.webdav.org/his/23/ver/15 Cache-Control: no-cache Clemm, et al. Standards Track [Page 66] RFC 3253 Versioning Extensions to WebDAV March 2002 　 この例では、"working resource" /wr/157 がチェックインされ、新しい 　 "version"が http://repo.webdav.org/his/23/ver/15 に作成される。 9.5 Additional OPTIONS Semantics 　 サーバが"working-resource"機能をサポートしているならば、全てのバー 　 ジョニングプロパティ、レポート、もしくはメソッドをサポートする全て 　 のリソースに対するOPTIONSリクエストによって返却されるレスポンスに 　 含まれる"DAV"レスポンスヘッダのフィールドには"working-resource"と 　 いうフィールドが含まれなければならない（MUST）。 9.6 Additional COPY Semantics Additional Postconditions: 　　　(DAV:copy-creates-new-resource): "working resource"のコピーの結果は 　　　COPYメソッドで指定されるコピー先の新しい"non-version-controlled 　　　resource"である。新しいリソースは、自動的に"version control"配下に 　　　置かれるかもしれない（MAY）が、その結果として作成される 　　　"version-controlled resource"は、（訳注："version control"配下に置 　　　かれることで作成された）新しい"version-controlled resource"のため 　　　の新しい"version history"と結び付けられなくてはならない（MUST）。 　　　 9.7 Additional MOVE Semantics Additional Preconditions: 　　　(DAV:cannot-rename-working-resource): request-URLが 　　　"working resource"を指定した場合、リクエストは失敗しなければ 　　　ならない（MUST）。 Additional Postconditions: 　　　(DAV:update-auto-update): request-URLが"version-controlled resource" 　　　を指定したら、その"version-controlled resource"を指定する全ての 　　　"DAV:auto-update"はその"version-controlled resource"の新しい配置場所 　　　を含むようにアップデートされなくてはならない（MUST）。 10 Advanced Versioning Features 　 "advanced versioning"は、並列開発および相互に関係付けられたリソースの 　 複数の組についての構成管理の問題を扱う。伝統的に、要求、設計書、コード 　 とテストケースを含むソフトウェア開発の生産物は（今まで）構成管理 　 （configuration management）のフォーカスであった。Web サイト−多数の 　 連結されたリソース（ HTML 、グラフィックス、音、CGI その他）を含んで 　 いる−は、構成管理（configuration management）の適用から恩恵を受ける 　 複雑な情報を持つ生産物の他のクラスである。（複数）同時の変更を調整す 　 る"advanced versioning"の能力は、大きく進化しつづけているWebサイトの 　 効果的かつ制御された管理のためのインフラストラクチャを提供する。 Clemm, et al. Standards Track [Page 67] RFC 3253 Versioning Extensions to WebDAV March 2002 10.1 Advanced Versioning Packages 　 サーバはどのような組み合わせの"advanced versioning"機能をサポートし 　 てもよい（MAY）が、WebDAVの"advanced versioning"クライアントの複雑 　 さを最小限にとどめるためには、WebDAVの"advanced versioning"サーバは 　 以下のPackage の1つをサポートすべきである（SHOULD）。 　 Advanced-Server-Workspace Package: basic-server-workspace package 　 に加え、全ての"advanced"機能 Advanced-Client-Workspace Package: basic-client-workspace package 　 に加え、全ての"advanced"機能 　 "advanced-server-workspace" packageは、継続的な状態を持たないクライ 　 アントに対して"advanced versioning"の機能をサポートする。 　 "advanced-client-workspace" packageは、クライアント上で構成の状態を 　 管理するような場合に"advanced versioning"の機能をサポートする。両方 　 の"advanced workspace"packageをサポートするサーバは、全てのバージョ 　 ニングクライアントとの相互運用が可能となる。 10.2 Advanced Versioning Terms 　 以下の追加の用語は、"advanced versioning"機能で使用される。 Collection 　　　"collection"は、リソースであり、その状態は（その"collectionの） 　　　内容とプロパティだけでなく、"binding"と名づけられたセットにも 　　　依存する。"binding"は、RFC2518が"collection"の「内部メンバ」を 　　　宣言するものと定義している。 　　　"binding"はリソースではなく、どちらかというと"collection"につい 　　　て"binding name"（URLの部分）からリソース（"collection"の内部メ 　　　ンバ）への対応を定義する状態の一部であることに注意せよ。 Collection Version Resource 　　　"collection version resource"もしくはシンプルに"collection version"は、 　　　"collection"に所属する"version-controlled binding"の名前と同じように 　　　"version-controlled collection"（Section 14 を参照のこと）の 　　　デッドプロパティを取り込む。"version controlled binding"は、 　　　"version-controlled resource"に対する"binding"である。 　　　"checkout-in-place"機能がサポートされているならば、 　　　"collection version"は、"version-controlled collection"をチェッ 　　　クアウトしてチェックインすることで生成される。"working-resource" 　　　機能がサポートされていれば、"collection version"は、 　　　"collection version"をチェックアウトし、それから 　　　"working collection"をチェックインすることで作成される。 Clemm, et al. Standards Track [Page 68] RFC 3253 Versioning Extensions to WebDAV March 2002 Configuration 　　　"configuration"は、"root collection"と、"root collection"の全て 　　　のメンバ（内部メンバではない）のうち他の"configuration"のメンバ 　　　でないものから成り立つリソースの組である。"root collection"は、 　　　"configuration root"と呼ばれ、このメンバは"members of the 　　　configuration"と呼ばれる。"collection"（1つのリソース）は、 　　　"configuration"（リソースのセット）とは大きく異なることに注意せよ。 Baseline Resource 　　　"collection"の"baseline resource"もしくはシンプルに"baseline"は、 　　　そのコレクションに根付いている"configuration"の"version"である 　　　（Section 12を参照のこと）。特に、"baseline"は、その"configuration" 　　　の全ての"version-controlled member"の"DAV:checked-in"で指定される 　　　メンバを取り込む。 　　　"collection version"（これは、1つのリソースの状態を取り込む）は、 　　　"collection baseline"（これはリソースのセットの状態を取り込む） 　　　と大きく異なることに注意せよ。 Baseline-Controlled Collection 　　　"baseline-controlled collection"は、そこから"baseline"が作成される 　　　"collection"である（Section 12 を参照のこと）。 Version-Controlled Configuration Resource 　　　"version-controlled configuration resource"もしくはシンプルに 　　　"version-controlled configuration"は、"baseline-controlled 　　　collection"と結び付けられる特別な種類の"version-controlled 　　　resource"であり、"collection"の"baseline"を作成し、それにアクセス 　　　するために用いられる（Section 12 を参照のこと）。"collection"が、 　　　"version-controlled"であり、"baseline-controlled"であれば、クライ 　　　アントは新しい"collection"の"version"をその"collection"をチェック 　　　アウトしてチェックインすることで作成でき、そしてそのコレクションの 　　　新しい"baseline"をその"collection"の"version-controlled 　　　configuration"をチェックアウトしてチェックインすることで作成できる。 Activity Resource 　　　"activity resource"もしくはシンプルに"activity"は、1つの論理名変更に 　　　対応する（複数の）"version"の組を選択するリソースであり、（"activity" 　　　において）指定された"version history"から選択された（複数の）"version" 　　　は、その"version history"を通じて1本の系統を構成する。（Section 13 を 　　　参照のこと）。 Clemm, et al. Standards Track [Page 69] RFC 3253 Versioning Extensions to WebDAV March 2002 11 Merge Feature 　 ユーザが、誰かが作成した変更（新しい（複数の）"version"）を受け入れ 　 たい時は、これら新しい（複数の）"version"が存在するユーザの"workspace" 　 内の"version-controlled resource"を単に更新しないことが重要である。 　 というのも、このことは結果としてユーザが"version-controlled resource" 　 にほどこした変更を「取り消す」可能性があるからだ。かわりに、他の 　 "workspace"に作成された"version"は、ユーザの"version-controlled 　 resource"に「マージされる」べきである。 　 "version-controlled resource"の"version history"は、マージの結果を決定 　 するのに必要な情報を提供する。特に、マージについては "root version"から 　 の系統でどれがもっとも最近の"version"かを選ばれるべきである。マージされ 　 る（複数の）"version"が異なる系統に存在する（どちらの"version"も他の 　 "descendant"でない）場合、どちらの"version"も選択されるべきではなく、 　 そのかわりに、これらの"version"の内容とデッドプロパティの論理的なマー 　 ジを含んだ新しい"version"が作成されるべきである。MERGEリクエストは、 　 そのようなマージが必要な各"version-controlled resource"からチェックアウ 　 トを実施し、マージされるべき"version"を指定するために"DAV:merge-set" 　 プロパティを"check-out"されたリソースに対して設定を行うために使用さ 　れる。それがその"version"のそれが論理的なマージであるであることをあ 　 らわし、その"version"を"check-out"されたリソースの"DAV:predecessor-set" 　 に追加するように、ユーザは"check-out"されたリソースの内容とデッドプロ 　 パティの更新に責任を負う。 　 サーバが自動的にマージを実行することが可能ならば、"check-out"された 　 リソース自身の内容、デッドプロパティ、そして"DAV:predecessor-set" 　 （ the content, dead properties, and DAV:predecessor-set of the 　 checked-out resource itself）をアップデートしてもよい（MAY）。自動 　 的にマージされたリソースをチェックする前に、ユーザは自動的なマージが 　 正しいことを確認する責任がある。 　（一応確認する（WAKATONO）） 11.1 Additional Checked-Out Resource Properties 　 "merge"機能は、"check-out"されたリソースについて以下の必要なプロパ 　 ティを導入する。 11.1.1 DAV:merge-set 　 このプロパティは、この"check-out"されたリソースにマージされる各"version" 　 を指定する。 Clemm, et al. Standards Track [Page 70] RFC 3253 Versioning Extensions to WebDAV March 2002 11.1.2 DAV:auto-merge-set 　 このプロパティは、サーバが"check-out"されたリソースにマージした 　 各"version"を指定する。クライアントは、"check-out"されたリソースの 　 "DAV:auto-merge-set"から"check-out"されたリソースの"DAV:predecessor-set" 　 へとURLを移動する前に、正しくマージが行われているかどうかを承認すべき 　 である。 11.2 MERGE Method 　 MERGEメソッドは、指定した"version"（"merge source"）の、指定した 　 "version-controlled resource"（"merge target"）への論理的なマージを実行 　 する。"merge source"は、"DAV:checked-in"や"DAV:checked-out"で指定された 　 バージョンの"ancestor"でも"descendant"でもなく、MERGEは"merge target"を 　 （チェックアウトされていなければ）チェックアウトし、"merge source"のURLを 　 "merge target"の"DAV:merge-set"に追加する。現状の"merge target"への 　 "merge source"のマージを反映するために、"check-out"された"merge target" 　 の内容とデッドプロパティをアップデートするのはクライアントの責任である。 　 クライアントは、"check-out"された"merge target"の"DAV:merge-set"から 　 "merge source"のURLを削除し、そのURLを"DAV:predecessor-set"に追加する 　 ことで、"merge target"の更新が完了したことを示す。マージを完了するこ 　 とを忘れるクライアントのためのエラーチェックとして、サーバは空でない 　 "DAV:merge-set"をともなう"version-controlled resource"のCHECKINの試行は 　 失敗しなくてはならない（MUST）。 　 サーバが"merge source"の論理的なマージを反映するために"merge target"の 　 内容とデッドプロパティを自動的にアップデートする能力を持っているなら、 　 MERGEリクエストのリクエストボディに"DAV:no-auto-merge"が"merge source" 　 に指定されていない限りは自動的にマージは実行される。クライアントに 　 "merge source"は自動的にマージされていることを通知するために、MERGEリ 　 クエストは"merge target"の"DAV:auto-merge-set"プロパティに自動的にマー 　 ジされた"merge source"のURLを追加しなくてはならず（MUST）、 　 "DAV:merge-set"プロパティにはそれを追加してはならない（MUST NOT）。 　 クライアントは"DAV:auto-merge-set"から"merge source"のURLを削除し、 　 "DAV:predecessor-set"に追加することで自動マージは正しく行われたことを 　 検証した旨を示す。 　 1つのMERGEリクエストにおいて、複数の"merge source"を指定可能である。 　 MERGEリクエストにおける"merge source"のセットは、MERGEリクエストのリ 　 クエストボディ中の"DAV:source"エレメントから以下のようにして決定され 　 る。 - "DAV:source"が"version"を指定するならば、その"version"は 　　　"merge source"である。 - "DAV:source"が"version-controlled resource"を指定している 　　　ならば、"version-controlled resource"の"DAV:checked-in"で 　　　示される"version"が"merge source"である。 Clemm, et al. Standards Track [Page 71] RFC 3253 Versioning Extensions to WebDAV March 2002 - "DAV:source"が"collection"を指定しているならば、その"collection" 　　　のメンバである各"version-controlled resource"の"DAV:checked-in"で 　　　指定される"version"が"merge source"である。 　 request-URLは、指定可能な"merge target"の組を指定する。request-URLが 　 "collection"を指定するならば、request-URLを"root collection"とする 　 "configuration"の全てのメンバが、可能な（possible）"merge target"と 　 なる。特定の"merge source"の"merge target"は、"version controlled"か 　 "checked-out" リソースであり、そのリソースの"DAV:checked-in"あるいは 　 "DAV:checked-out"で指定される"version"は"merge source"と同じ"version 　 history"である。"merge source"が"merge target を持たない場合、 　 "merge source"は無視される。 　 MERGEレスポンスは、クライアントがマージを完了するために更新しなければ 　 ならないリソースを指定する。これは、リクエストによって更新されたリソー 　 スも指定し、その結果、クライアントは管理されているいかなるキャッシュ 　 された状態も効率的にアップデートできる。 　 順序： Marshalling: 　　　リクエストボディは、"DAV:merge"エレメントを持っていなくてはなら 　　　ない（MUST）。 　　　"merge source"のセットは、リクエストボディ内の"DAV:source"エレメント 　　　によって決定される。 　　　ANY 値：1つの"DAV:source"エレメントと最大1つの"DAV:no-auto-merge"エ 　　　レメントと最大1つの"DAV:no-checkout"エレメントと最大1つの"DAV:prop" 　　　エレメントと、"DAV:checkout"エレメント内に出てくる全ての正しいエレ 　　　メントのセットを伴うエレメントの並び。 　　　prop: RFC2518 の Section 12.11 を参照のこと。 prop: see RFC 2518, Section 12.11 　　　リクエストが成功した場合に帰ってくるレスポンスは、207 Multi-Status 　　　でなければならず（MUST）、そのレスポンスボディ中の"DAV:multistatus" 　　　XMLエレメントはリクエストによって更新された全てのリソースが指定され 　　　る。 　　　multistatus: RFC2518 の Section 12.9 を参照のこと。 　　　リクエストが成功した場合のレスポンスは、"Location"ヘッダを含まなくて 　　　はならない。このとき含まれる"Location"ヘッダには、チェックインにより 　　　作成された新しい"version"のURLが含まれる。 　　　レスポンスには、"Cache-Control:no-cache"ヘッダを含まなくてはならない 　　　（MUST）。 Clemm, et al. Standards Track [Page 72] RFC 3253 Versioning Extensions to WebDAV March 2002 Preconditions: 　　　(DAV:cannot-merge-checked-out-resource): "DAV:source"エレメントは、 　　　"check-out"されたリソースを指定してはならない（MUST NOT）。もし 　　　"DAV:source"エレメントが"collection"を指定したら、その"collection"は 　　　"check-out"されたリソースをメンバに持っていてはならない。 　　　(DAV:checkout-not-allowed): リクエストボディにて"DAV:no-checkout"が 　　　指定されたら、"merge target"のいずれもチェックアウトすることなく 　　　マージを実行することが可能にならなければならない（MUST）。 　　　CHECKOUT操作の全ての"preconditions"は、リクエストによって実行される 　　　チェックアウトに対して適用される。 (All preconditions of the CHECKOUT operation apply to the checkouts performed by the request.) Postconditions: 　　　(DAV:ancestor-version): "merge target"が"version-controlled resource" 　　　もしくは"check-out"されたリソースであり、"DAV:checked-in"もしくは 　　　"DAV:checked-out"の"version"が"merge source"のものもしくは"merge 　　　source"の"descendant"の場合には、"merge target"はMERGEによって更新 　　　されてはならない（MUST NOT）。 　　　(DAV:descendant-version): "merge target"が"check-in"された 　　　"version-controlled resource"であり、その"DAV:checked-in"の 　　　"version"が"merge source"の"ancestor"であった場合、UPDATE操作は 　　　その内容とデッドプロパティを"merge source"の内容とデッドプロパティ 　　　に設定するために"merge target"に対して適用される。UPDATEメソッドが 　　　サポートされない場合、"merge target"はチェックアウトされる必要があ 　　　り（MUST）、"merge target"の内容とデッドプロパティは"merge source" 　　　の内容とデッドプロパティに設定されるなければならず（MUST）、 　　　"merge source"は"merge target"の"DAV:auto-merge-set"に追加されな 　　　ければならない（MUST）。"merge target"は、レスポンスボディの 　　　"DAV:response"XMLボディに現れなければならない（MUST）。 　　　(DAV:checked-out-for-merge): "merge target"が"check-in"された 　　　"version-controlled resource"であり、その"DAV:checked-in"の"version"が 　　　"merge source"の"descendant"でも"ancestor"でもない場合には、 　　　CHECKOUTは"merge target"に対して適用されなければならない（MUST）。 　　　"DAV:checkout"XMLエレメントの中に現れる可能性のある"DAV:merge"XML 　　　エレメント内の全てのXMLエレメントCHECKOUTリクエストの引数として 　　　用いられなければならない（MUST）。"merge target"は、レスポンス 　　　ボディ中の"DAV:respnse"XMLエレメント内に現れなければならない（MUST）。 　　　(DAV:update-merge-set): "merge target"の"DAV:checked-out"の 　　　"version"が"merge source"と同じでもなければ"descendant"でもない 　　　場合には、"merge source"は"DAV:merge-set"もしくは 　　　"DAV:auto-merge-set"（merge targetにおいて）であるならば、 　　　"merge source"は"merge target"の"DAV:merge-set"もしくは 　　　"DAV:auto-merge-set"に追加されなければならない（MUST）。 　　　"merge target"は、レスポンスボディ中の"DAV:response"XMLエレメン 　　　トに現れなければならない（MUST）。 Clemm, et al. Standards Track [Page 73] RFC 3253 Versioning Extensions to WebDAV March 2002 　　　"merge source"が"DAV:auto-merge-set"に追加されているならば、 　　　"merge target"の内容とデッドプロパティは、"merge source"と 　　　"merge target"の論理的なマージの結果を反映するためにサーバによっ 　　　て変更されなければならない（MUST）。"merge source"が"DAV:merge-set" 　　　に追加されているならば、"merge target"の内容とデッドプロパティは 　　　サーバによって変更されてはならない（MUST NOT）。"DAV:no-auto-merge" 　　　がリクエストボディに指定されていたら、"merge source"は 　　　"DAV:auto-merge-set"に追加されてはならない（MUST NOT）。 　　　(DAV:report-properties): "DAV:prop"がリクエストボディに指定され 　　　たら、"DAV:prop"エレメント内で指定されたプロパティはレスポンス 　　　ボディ内の"DAV:response"エレメントでレポートされなくてはならな 　　　い（MUST）。 11.2.1 Example - MERGE >>REQUEST MERGE /ws/public HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx http://www.webdav.org/ws/dev/sally >>RESPONSE HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Cache-Control: no-cache http://www.webdav.org/ws/public/src/parse.c HTTP/1.1 200 OK http://www.webdav.org/ws/public/doc/parse.html HTTP/1.1 200 OK Clemm, et al. Standards Track [Page 74] RFC 3253 Versioning Extensions to WebDAV March 2002 　 この例においては、"workspace" http://www.webdav.org/ws/dev/sally の 　 "DAV:checked-in"の（複数の）"version"が"workspace" 　 http://www.webdav.org/ws/public 内の"version-controlled resource"へ 　 マージされている。リソース /ws/public/src/parse.c と 　 /ws/public/doc/parse.html はリクエストによって更新された。 11.3 DAV:merge-preview Report 　 "merge preview"は、リクエストボディ中の"DAV:source"エレメント（複数の） 　 "version"が"request-URL"によって指定されるリソース（通常は"collection"） 　 へマージされる場合に結果としておこる変更を記述する。 　 順序： Marshalling: 　　　リクエストボディは、"DAV:merge-preview"XMLエレメントでなければ 　　　ならない（MUST）。 　　　成功したリクエストに対するレスポンスボディは、"DAV:merge-preview-report" 　　　XMLエレメントでなければならない。 　　　"DAV:update-preview"エレメントは、 　　　"MERGE"の結果として変更される"DAV:checked-in property"をともなう 　　　"merge target"を指定し、そしてその"merge target"に対応する 　　　"merge source"を指定する。 　　　"DAV:conflict-preview"エレメントは、マージを必要とする"merge target" 　　　を指定する。 　　　"DAV:common-ancestor"エレメントは、"merge source"と"merge target" 　　　の"DAV:checked-in"もしくは"DAV:checked-out"の"version"の両者に共 　　　通な"ancestor"である"version"を指定する。 　　　"DAV:ignore-preview"エレメントは、"merge target"を持たない"version" 　　　を指定し、そしてその結果として（"DAV:ignore-preview"は）マージによっ 　　　て無視される。 Clemm, et al. Standards Track [Page 75] RFC 3253 Versioning Extensions to WebDAV March 2002 11.3.1 Example - DAV:merge-preview Report >>REQUEST REPORT /ws/public HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx http://www.webdav.org/ws/dev/fred >>RESPONSE HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.webdav.org/ws/public/foo.html http://repo.webdav.org/his/23/ver/18 http://repo.webdav.org/his/23/ver/42 http://www.webdav.org/ws/public/bar.html http://www.repo/his/42/ver/3 Clemm, et al. Standards Track [Page 76] RFC 3253 Versioning Extensions to WebDAV March 2002 　 この例では、"merge preview report"は 　 「"workspace" http://www.webdav.org/ws/dev/fred が "workspace" 　 http://www.webdav.org/ws/public へマージされるならば、"version" 　 /his/23/ver/42 は /ws/public/foo.html へマージされるだろう。そして、 　 "version" /his/42/ver/3 は /ws/public\bar.html を更新するだろう」と 　 示している。 11.4 Additional OPTIONS Semantics 　 サーバが"merge"機能をサポートするならば、バージョニングプロパティ、 　 レポート、もしくはメソッドをサポートする全てのリソースに対するOPTIONS 　 リクエストによるレスポンス中に含まれる"DAV"レスポンスヘッダに、"merge" 　 がフィールドとして含まれなければならない（MUST）。 11.5 Additional DELETE Semantics Additional Postconditions: 　　　(DAV:delete-version-reference): "version"が削除されたら、 　　　"DAV:merge-set"もしくは"DAV:auto-merge-set"プロパティに含まれる 　　　当該"version"への参照はすべて削除されなければならない（MUST）。 11.6 Additional CHECKIN Semantics Additional Preconditions: 　　　(DAV:merge-must-be-complete): "check-out"されたリソースの 　　　"DAV:merge-set"および"DAV:auto-merge-set"は、内容が空であるか 　　　それそのものが存在してないかでなければならない（MUST）。 12 Baseline Feature 　 "configuration"は、"root collection"と、"root collection"の全て 　 のメンバのうち他の"configuration"のメンバでないものから成り立つ 　 リソースの組である。多くのリソースを含む"configuration"は、サー 　 バ上の大きな領域を消費する。このことは、その"root collection"に 　 ついて"Depth:infinity"を指定してCOPYを作成することにより、存在す 　 る"configuration"の状態を記憶するために法外に高いコストになる可 　 能性を示している。 　 "baseline"は、"configuration"の各"version-controlled member"の状 　 態を取り込む。"version resource"である。"baseline history"は、 　 "baseline"である"version"の"version history"である。新しい"baseline" 　 が"version-controlled configuration"と呼ばれる特別な種類の 　 "version-controlled resource"をチェックアウトしてチェックインする 　 ことで、新しい"baseline"が作成される。 　 "baseline control"配下にある"collection"は、"baseline-controlled 　 collection"と呼ばれる。効果的な"baseline"の実装を許可するために、 　 "collection"の"baseline"の状態は（複数の）"version"のセットと 　 "collection"に対する相対名に制限されており、"baseline"の操作は 　 "collection"からの"baseline"の作成および"baseline"を"collection"に 　 戻したりマージしたりすることに限られている。 Clemm, et al. Standards Track [Page 77] RFC 3253 Versioning Extensions to WebDAV March 2002 　 サーバは、"collection"作成時にそれを自動的に"baseline control"配下 　 に置いてもよい（MAY）。もしくは、クライアントは指定した"collection"を 　 "baseline control"配下に置くためにBASELINE-CONTROLメソッドを用いるこ 　 とができる。 　 "configuration"が大きくなると、その大きくなった"configuration"を、 　 その"configuration"の論理的な「コンポーネント」によって構成される小さ 　 い"configuration"の組へと分解することは多くの場合有用である。 　 "configuration"の"baseline"が、コンポーネントの"configuration baseline" 　 によって論理的に拡張される事実を把握するために、コンポーネントの 　 "configuration baseline"は、"baseline"の"subbaseline"として把握される。 　 "configuration"の"root collection"は、その全てのコンポーネントの 　 "root collection"との関係について自由である。特に、"configuration" 　 の"root collection"は、その"configuration"中のコンポーネントの1つの 　 "root collection"をメンバとして持てる（例："configuration" /sys/x は、 　 コンポーネント /suys/x/foo を持てる）し、そのコンポーネントの1つの 　 "root collection"のメンバになりうる（例："configuration" /sys/y/z 　 は、コンポーネント /sys/y を持ちうる）し、あるいはそのどちらでもない 　 （例："configuration" /sys/x は、コンポーネント /comp/bar を持ちうる）。 12.1 Version-Controlled Configuration Properties 　 "version-controlled configuration"は、"version-controlled resource"で 　 あるため、"version-controlled resource"の全てのプロパティを持つ。 　 加えて、"baseline"機能は"version-controlled collection"に必要な以下の 　 プロパティを導入する。 12.1.1 DAV:baseline-controlled-collection (protected) 　 このプロパティは、"version-controlled configuration"によって記録されて 　 いる"DAV:checked-in"の"version"を持つ"version-controlled resource"を含 　 むコレクションを指定する。"version-controlled configuration"の 　 "DAV:baseline-controlled-collection"の 　 "DAV:version-controlled-configuration"は、 　 "version-controlled configuration"を指さなければならない（MUST）。 12.2 Checked-Out Configuration Properties 　 "check-out"された"configuration"は、"check-out"されたリソースである 　 ため、"check-out"されたリソースの全てのプロパティを持つ。それに加え、 　 "baseline"機能は、"check-out"された"configuration"に必要な以下のプロ 　 パティを導入する。 Clemm, et al. Standards Track [Page 78] RFC 3253 Versioning Extensions to WebDAV March 2002 12.2.1 DAV:subbaseline-set 　 このプロパティは、このリソースへのチェックインの結果である"baseline" 　 の"DAV:subbaseline-set"プロパティを決定する。 　 サーバは"check-out"された"configuration"の"DAV:subbaseline-set"を変更 　 しようとする試みをリジェクトしてもよい（MAY）。 12.3 Baseline Properties 　 "baseline"の"DAV:resourcetype"は、"DAV:baseline"でなければならない 　 （MUST）。"baseline"は"version resource"であるため、"version resource"の 　 プロパティを全て持っている。加えて、"baseline"機能は、"baseline"に必要な 　 以下のプロパティを導入する。 12.3.1 DAV:baseline-collection (protected) 　 このプロパティは、"collection"のためにサーバ側で定義されたURLを含み、 　 そのURLで示されるのコレクションの各メンバは、同じ"DAV:checked-in"の 　 "version"であり、"baseline"が作成された時点で"baseline-controlled 　 collection"の"version-controlled member"としての同じ相対名を持った 　 "version-controlled resource"であるか、"version-controlled resource" 　 のための相対名を提供するために必要な"collection"でなければならない。 12.3.2 DAV:subbaseline-set (protected) 　 "DAV:subbaseline-set"プロパティ内の（複数の）URLは、他の"baseline"の組を 　 指定しなければならない。"baseline"の（複数の）"subbaseline"は、（その 　 "baseline"の）"DAV:subbaseline-set"によって指定される"baseline"および、 　 その"DAV:subbaseline-set"で指定される"baseline"の全ての"subbaseline"で 　 ある。 12.4 Additional Resource Properties 　 "baseline"機能は、リソースに必要な以下のプロパティを導入する。 12.4.1 DAV:version-controlled-configuration (computed) 　 リソースが"version-controlled configuration"のメンバである（例：リソー 　 スが"baseline control"配下にあるコレクションであるか、"baseline control" 　 配下にあるコレクションのメンバである）ならば、このプロパティはその 　 "version-controlled configuration"を指す。 Clemm, et al. Standards Track [Page 79] RFC 3253 Versioning Extensions to WebDAV March 2002 12.5 Additional Workspace Properties 　 "baseline"機能は、"workspace"について、以下の必要なプロパティを導入する。 12.5.1 DAV:baseline-controlled-collection-set (computed) 　 このプロパティは、"baseline control"配下にあるコレクションである"workspace"の各メンバを指す（同様に、"workspace"自身が"baseline control"配下にある場合には、その"workspace"自身を指す）。 12.6 BASELINE-CONTROL Method 　 "collection"は、BASELINE-CONTROLリクエストにより"baseline control"配下に 　 置かれる。"collection"が"baseline control"配下に置かれると、新しい 　 "version-controlled configuration"を指定するために、そのコレクションの 　 "DAV:version-controlled-configuration"プロパティが設定される。 　 この"version-controlled configuration"は、その"collection"の新しい"baseline" 　 を作成するために、チェックアウトしてからチェックインすることが出来る。 　 リクエストボディ中に"baseline"が指定されると、新しい"version-controlled 　 configuration"の"DAV:checked-in"で指される"version"が新しい"baseline"と 　 なりうる。そして"collection"は、指定された"baseline"によって決定される 　 "DAV:checked-in"で指される（複数の）"version"と相対名を持つ（複数の） 　 "version-controlled member"によって初期化される。 　 "baseline"が指定されない場合は、新しい"baseline history"が"collection" 　 の"version-controlled member"の状態をとらえた"baseline"を含んで生成さ 　 れ、"version-controlled configuration"の"DAV:checked-in"の"version"が 　 その"baseline"となりうる。 　 順序： Marshalling: 　　　リクエストボディが含まれるならば、それは"DAV:baseline-control"XML 　　　エレメントでなければならない（MUST）。 　　　ANY 値：多くとも1つの"DAV:baseline"エレメントともなうエレメントの並び 　　　リクエストが成功してレスポンスボディが返ってくる場合、それは 　　　"DAV:baseline-control-response"XMLエレメントでなければならない 　　　（MUST）。 Clemm, et al. Standards Track [Page 80] RFC 3253 Versioning Extensions to WebDAV March 2002 　　　レスポンスには、"Cache-Control:no-cache"ヘッダを含まなければならない 　　　（MUST）。 Preconditions: 　　　(DAV:version-controlled-configuration-must-not-exist): 　　　request-URLで指定される"collection"の 　　　"DAV:version-controlled-configuration"プロパティは、存在しては 　　　ならない（MUST）。 　　　(DAV:must-be-baselien): リクエストボディ中の"DAV:baseline"エレ 　　　メントに含まれる "DAV:href"は、"baseline"を指定していなくては 　　　ならない（MUST）。 　　　(DAV:must-have-no-version-controlled-members): "DAV:baseline"エレ 　　　メントがリクエストボディで指定されたら、request-URLで指定される 　　　"collection"は"version-controlled member"を持っていてはならない 　　　（MUST）。 　　　(DAV:one-baseline-controlled-collection-per-history-per-workspace): 　　　request-URLが"workspace"もしくは"workspace"のメンバを指定しており、 　　　かつリクエストボディ中の"DAV:baseline"に"baseline"が指定されていた 　　　場合、その"baseline"の"baseline history"のために 　　　"version-controlled configuration"を指定する 　　　"DAV:version-controlled-configuration"を持つその"workspace"内には 　　　他の"collection"は存在してはならない（MUST）。 Postconditions: 　　　(DAV:create-version-controlled-configuration): 　　　新しい"version-controlled configuration"が作成されると、 　　　その"DAV:baseline-controlled-collection"プロパティは"collection"を 　　　指定する。 　　　(DAV:reference-version-controlled-configuration): 　　　"collection"の"DAV:version-controlled-configuration"は、新しい 　　　"version-controlled configuration"を指定する。 　　　(DAV:select-existing-baseline): リクエストボディが"baseline"を 　　　指定した場合、新しい"version-controlled configuration"の 　　　"DAV:checked-in"プロパティはこの"baseline"を指定するように設定 　　　される必要がある（MUST）。"colelction"の"version-controlled member" 　　　は、"baseline"の各バージョンごとに生成され、そして、その"baseline" 　　　において、"version-controlled member"は、そのバージョンの内容と 　　　デッドプロパティを持ち、"baseline"が生成された時に適切な 　　　"version-controlled resource"が持っていたように"collection"から 　　　の同じ相対名を持つ。"version-controlled member"に対して適切な名 　　　前を付与しなければならない全部階層になった"collection"が作成さ 　　　れる。（かなり不明:WAKATONO） Clemm, et al. Standards Track [Page 81] RFC 3253 Versioning Extensions to WebDAV March 2002 　　　(DAV:create-new-baseline): リクエストボディ中に"baselineが指定され 　　　ないならば、リクエストはサーバが定義した（server-defined）URLに対し 　　　て新しい"baseline history"を作成しなくてはならず（MUST）、 　　　"baseline history"に新しい"baseline"を作成しなくてはならない（MUST）。 　　　新しい"baseline"の"DAV:baseline-collection"は、リクエストされた 　　　"collection"の"version-controlled member"として同じ相対名と 　　　"DAV:checked-in"の"version"を持つメンバを有する"collection"を指定 　　　しなくてはならない（MUST）。新しい"version-controlled configuration" 　　　の"DAV:checked-in"プロパティは、新しい"baseline"を指定しなくてはな 　　　らない。 12.6.1 Example - BASELINE-CONTROL >>REQUEST BASELINE-CONTROL /src HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.webdav.org/repo/blh/13/ver/8 >>RESPONSE HTTP/1.1 200 OK Cache-Control: no-cache Content-Length: 0 Clemm, et al. Standards Track [Page 82] RFC 3253 Versioning Extensions to WebDAV March 2002 　 この例では、"collection" /src は"baseline control"配下に置かれており、 　 この"collection"は存在する"baseline"からのメンバで占められている。 　 新しい"version-controlled configuration" (/repo/vcc/128)が作成され、 　 /src と関係する。そして/src は指定した"baseline"(/repo/blh/13/ver/8) 　 の"DAV:baseline-collection"(/repo/bc/15)によって選択される（複数） 　 "version"である"DAV:checked-in"の"version"を持つ"version-controlled 　 member"で初期化される。以下のダイヤグラムは、サーバ上の結果の状態を 　 示す。 +-------------------------------------+ |Baseline-Controlled Collection |<------+ |/src | | |-------------------------------------| | |DAV:version-controlled-configuration +---+ | +-------------------------------------+ | | | | | | +-------------------------------------+ | | |Version-Controlled Configuration |<--+ | |/repo/vcc/128 | | |-------------------------------------| | |DAV:baseline-controlled-collection +-------+ |-------------------------------------| |DAV:checked-in +-------+ +-------------------------------------+ | |DAV:version-history +---+ | +-------------------------------------+ | | | | | | +------------------------+ | | |Baseline History |<---------------+ | |/repo/blh/13 | | |------------------------+ | |DAV:version-set +----------------+ | +------------------------+ | | | | | v | v v | | | +------------------------+ | | |Baseline |<-------+-----------+ |/repo/blh/13/ver/8 | |------------------------+ +--------------+ |DAV:baseline-collection +---->|Collection | +------------------------+ |/repo/bc/15 | +--------------+ Clemm, et al. Standards Track [Page 83] RFC 3253 Versioning Extensions to WebDAV March 2002 　 /src の新しい"baseline"を作成するためには、/repo/vcc/128がチェックアウ 　 トされ、新しい"versions"が作成されるか/srcの"version-controlled members" 　 によって選択され、それから/repo/vcc/128がこれらの"version-controlled 　 members"の現在の状態を捕捉するためにチェックインされる。 12.7 DAV:compare-baseline Report 　 "DAV:compare-baseline"レポートは、request-URLで指定される"baseline" 　 （"request baseline"と呼ぶ）と、リクエストボディで指定される"baseline" 　 （"compare baseline"と呼ぶ）との間の違いを含む Marshalling: 　　　リクエストボディは、"DAV:compare-baseline"XMLエレメントでなければ 　　　ならない（MUST）。 　　　成功したリクエストのレスポンスボディは"DAV:compare-baseline-report" 　　　XMLエレメントでなければならない。 　　　"DAV:added-version"エレメントは、"compare baseline"の 　　　"DAV:baseline-collection"のメンバの"DAV:checked-in"の"version" 　　　を指定するが、"request-baseline"の"DAV:baseline-collection" 　　　のメンバの"DAV:checked-in"な"version"である"version"の 　　　"version history"内にある"version"は指定しない。 　　　"DAV:deleted-version"エレメントは、"request baseline"の 　　　"DAV:baseline-collection"のメンバの"DAV:checked-in"の"version" 　　　を指定するが、"compare-baseline"の"DAV:baseline-collection" 　　　のメンバの"DAV:checked-in"な"version"である"version"の 　　　"version history"内にある"version"は指定しない。 　　　"DAV:changed-version"エレメントは、"request baseline"と" 　　　compare baseline"の"DAV:baseline-collection"の"DAV:checked-in"の 　　　"version"である同じ"version history"より2つの異なる"version"を指 　　　定する。 Clemm, et al. Standards Track [Page 84] RFC 3253 Versioning Extensions to WebDAV March 2002 Preconditions: (DAV:must-be-baseline): リクエストボディ中の"DAV:href"は、"baseline"を 　　　指定しなくてはならない。（MUST）。 (DAV:baselines-from-same-history): サーバは、同じ"baseline history"より 　　　比較対象となる"baseline"を要求してもよい（MAY）。 12.7.1 Example - DAV:compare-baseline Report >>REQUEST REPORT /bl-his/12/bl/14 HTTP/1.1 Host: repo.webdav.com Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://repo.webdav.org/bl-his/12/bl/15 >>RESPONSE HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://repo.webdav.org/his/23/ver/8 http://repo.webdav.org/his/29/ver/12 http://repo.webdav.org/his/29/ver/19 http://repo.webdav.org/his/12/ver/4 　 この例では、http://repo.webdav.org/bl-his/12 の "baseline" 14 と 　 "baseline" 15 との間の違いが指定される。 Clemm, et al. Standards Track [Page 85] RFC 3253 Versioning Extensions to WebDAV March 2002 12.8 Additional OPTIONS Semantics 　 サーバが"baseline"機能をサポートするならば、全てのバージョニングプロ 　 パティやレポート、メソッドをサポートする全てのリソースへのOPTIONSリク 　 エストから返ってくるレスポンスのレスポンスヘッダの"DAV"レスポンス 　 ヘッダのフィールドとして、"baseline"が含まれなければならない（MUST）。 12.9 Additional MKCOL Semantics Additional Postconditions: 　　　サーバが自動的に新しく作成された"collection"を"baseline control" 　　　配下に置くならば、BASELINE-CONTROLのための全ての"postconditions"は 　　　MKCOLに対して適用される。 12.10 Additional COPY Semantics Additional Postconditions: 　　　リクエストが新しい"collection"をコピー先に作成し、その新しく作成さ 　　　された"collection"を"baseline control"配下に自動的に置くような場合 　　　は、BASELINE-CONTROLのための全ての"postconditions"はCOPYに対して適 　　　用される。 12.11 Additional CHECKOUT Semantics Additional Preconditions: 　　　(DAV:must-not-update-baseline-collection): request-URLが 　　　"baseline"の"DAV:baseline-collection"に根付いた（rooted） 　　　"configuration root"のメンバを指定する場合、リクエストは失敗 　　　しなければならない（MUST）。 12.12 Additional CHECKIN Semantics Additional Preconditions: 　　　(DAV:no-checked-out-baseline-controlled-collection-members): 　　　request-URLが"version-controlled configuration"を指定する場合、 　　　その"version-controlled configuration"の 　　　"DAV:baseline-controlled-collection"の全ての 　　　"version-controlled members"は"check-in"されなければならない（MUST）。 　　　(DAV:one-version-per-history-per-baseline): request-URLが 　　　"version-controlled configuration"を指定するならば、 　　　"version-controlled configuration"によって選択される"version"のセット 　　　は他の"version history"からせいぜい多くても1つの"version"を含まなけ 　　　ればならず（MUST）、その"version-history"では、"version"がその" 　　　version-controlled configuration"の"DAV:baseline-controlled collection" 　　　に根付く（rooted）"configuration"の全てのメンバの"DAV:checked-in"プロ 　　　パティによって指定されるか、その"version-controlled configuration"の 　　　全ての"subbaseline"の"DAV:baseline-collection"に根付く（rooted） 　　　configurationの全てのメンバの"DAV:checked-in"プロパティによって 　　　指定される。 Clemm, et al. Standards Track [Page 86] RFC 3253 Versioning Extensions to WebDAV March 2002 　　　(DAV:cannot-modify-version-controlled-configuration):request-URLが 　　　"check-in"された"version-controlled configuration"を持つ 　　　"baseline-controlled collection""version-controlled member"を指定 　　　するならば、"version-controlled configuration"が更新された時点でそ 　　　の"DAV:auto-version"プロパティが自動的に"version-controlled 　　　configuration"をチェックアウトしない限り、リクエストは失敗しなけれ 　　　ばならない。 Additional Postconditions: 　　　(DAV:create-baseline-collection): request-URLが"version-controlled 　　　configurationを指定するならば、新しい"baseline"の 　　　"DAV:baseline-collection"は同じ相対名と"DAV:checked-in"の"version"を 　　　リクエスト時点の"version-controlled configuration"の 　　　"DAV:baseline-controlled-collection"のメンバとして持つメンバを含む 　　　"collection"を指定する。 　　　(DAV:modify-configuration): request-URLが"baselien-controlled 　　　collection"の"version-controlled member"を指定するならば、これは 　　　その"baseline-controlled collefction"の"version-controlled 　　　configuration"の更新であり、通常の自動バージョニングのセマンティクスが 　　　適用される。 12.13 Additional UPDATE Semantics Additional Preconditions: 　　　(DAV:baseline-controlled-members-must-be-checked-in): 　　　request-URLが"version-controlled configuration"を指定するならば、 　　　その"version-controlled configuration"の 　　　"DAV:baseline-controlled-collection"の全ての 　　　"version-controlled members"はチェックインされなければならない（MUST）。 　　　(DAV:must-not-update-baseline-collection): request-URLが 　　　"baseline"の"DAV:baseline-collection"に根付いている（rooted） 　　　"configuration"のメンバを指定するならば、その"version-controlled 　　　configuration"が変更された時に"version-controlled configuration"の 　　　"DAV:auto-version"プロパティがそれを自動的にチェックアウトしない限 　　　りは、そのリクエストは失敗しなければならない（MUST）。 Clemm, et al. Standards Track [Page 87] RFC 3253 Versioning Extensions to WebDAV March 2002 Additional Postconditions: 　　　(DAV:set-baseline-controlled-collection-members): 　　　リクエストが"version-controlled configuration"の"DAV:checked-in" 　　　プロパティをアップデートするならば、その"version-controlled 　　　configuration"の"DAV:baseline-controlled-collection"の 　　　"version-controlled members"はアップデートされなければならない。 　　　その結果、その"version-controlled members"は"baseline"の 　　　"DAV:baseline-collection"のメンバとして同じ相対名と内容とデッド 　　　プロパティを持つ。特に、 - "baseline"の"DAV:baseline-collection"内の"version history"に 　　　　 "version-controlled member"が存在しない場合には、指定された 　　　　 "version history"の"version-controlled member"は、削除されな 　　　　 ければならない（MUST）。 - 指定された"version history"の"version-controlled member"は、 　　　　 その"baseline-controlled collection"に対する相対名が"baseline" 　　　　 の"DAV:baseline-collection"中の"version history"の 　　　　 "version-controlled member"と異なる場合には、リネームされなく 　　　　 てはならない（MUST）。 - 新しい"version-controlled member"は、適切な"baseline-controlled 　　　　 collection"の"version-controlled member"が存在しないような 　　　　 "baseline"の"DAV:baseline-collection"の各メンバについて作成 　　　　 されなければならない（MUST）。 - UPDATEリクエストは、"baseline"の"DAV:baseline-collection"中の 　　　　 "version history"に対する"version-controlled member"とは異なる 　　　　 "DAV:checked-in"の"version"を持つ各"version-controlled member" 　　　　 に対して適用されなければならない（MUST）。 　　　(DAV:update-subbaselines): リクエストが"request baseline"の 　　　"subbaseline"の1つについての"baseline-controlled member"を含む 　　　"DAV:baseline-controlled-collection"を持つ"version-controlled 　　　configuration"をアップデートしたら、その"baseline-controlled 　　　member"の"version-controlled configuration"の"DAV:checked-in" 　　　プロパティは、その"subbaseline"になるよう更新されなければなら 　　　ない（MUST）。リクエストが"request baseline"の"subbaseline"の 　　　1つの"baseline-controlled member"を含む"workspace"のメンバであ 　　　る"DAV:baseline-controlled-collection"を持つ"version-controlled 　　　 configuration"をアップデートしたら、その"baseline-controlled 　　　member"の"version-controlled configuration"の"DAV:checked-in" 　　　プロパティは、その"subbaseline"になるようにアップデートされる 　　　必要がある（MUST） Clemm, et al. Standards Track [Page 88] RFC 3253 Versioning Extensions to WebDAV March 2002 　　　(DAV:modify-configuration): リクエストが 　　　"baseline-controlled collection"の"version-controlled member" 　　　のいずれかの"DAV:checked-in"プロパティを更新し、この"DAV:checked-in" 　　　プロパティが"baseline-controlled collection"の 　　　"DAV:version-controlled-configuration"の"DAV:checked-in baseline" 　　　の"DAV:baseline-collection"の適切な"version-controlled member"の 　　　"DAV:checked-in"プロパティと異なる場合、これはその"version-controlled 　　　configuration"の更新であり、通常の自動バージョニングのセマンティクス 　　　が適用される。 12.14 Additional MERGE Semantics 　 "merge source"が"baseline"であるならば、"merge target"はその"baseline" 　 の"baseline history"の"version-controlled configuration"であり、 　 その"baseline"では、その"version-controlled configuration"の 　 "baseline-controlled collection"はrequest-URLで指定される 　 "collection"のメンバである。 Additional Preconditions: 　　　(DAV:must-not-update-baseline-collection): UPDATEと同じセマン 　　　ティクスである（Section 12.13 を参照のこと）。 　　　(DAV:cannot-modify-version-controlled-configuration): UPDATE 　　　と同じセマンティクスである（Section 12.13 を参照のこと）。 Additional Postconditions: 　　　(DAV:merge-baseline): "merge target"が"merge baseline"の 　　　"descendant"でない"DAV:checked-out baseline"を持つ 　　　"version-controlled configuration"であるならば、"merge baseline"は、 　　　"version-controlled configuration"の"DAV:auto-merge-set"に追加 　　　されなければならない（MUST）。その"baseline"の 　　　"DAV:baseline-collection"の各メンバの"DAV:checked-in version"は、 　　　"version-controlled configuration"の 　　　"DAV:baseline-controlled-collection"にマージされなければならない 　　　（MUST）。 　　　(DAV:merge-subbaselines):"merge target"が"merge baseline"の 　　　"subbaseline"の1つの"baseline-controlled member"を含む 　　　"DAV:baseline-controlled-collection"を持つ"version-controlled 　　　configuration"であるならば、その"subbaselineはその 　　　"baseline-controlled member"の"version-controlled configuration" 　　　へとマージされなければならない（MUST）。"merge target"が 　　　"merge baseline"の"subbaseline"の1つの"baseline-controlled member"を 　　　含む"workspace"のメンバである"DAV:baseline-controlled-collection"を 　　　持つ"version-controlled configuration"であるならば、"subbaseline"は 　　　その"baseline-controlled member"の"version-controlled configuration" 　　　にマージされなければならない（MUST）。 Clemm, et al. Standards Track [Page 89] RFC 3253 Versioning Extensions to WebDAV March 2002 (DAV:set-baseline-controlled-collection-members): UPDATEと同じ 　　　セマンティクスを持つ（Section 12.13 を参照のこと）。 (DAV:modify-configuration): UPDATEと同じセマンティクスを持つ 　　　（Section 12.13 を参照のこと）。 13 Activity Feature 　 "activity"は1つの"descent"の系列である"version"のセットを選択する 　 リソースであり、そこの"descent"の系列とは"successor"の関係によって 　 つながっている"version"の並びである。"activity"が複数の"version 　 history"を選択するならば、各"version history"において選択された 　 （複数の）"version"は、"descent"の1つの系列でなくてはならない（MUST）。 　 "activity"を使用するようになる（動機としての）共通の問題は、1つの 　 "workspace"内の複数の異なる論理的な変更を表現することがよく必要と 　 されていたり、他の"workspace"に対するこれらの論理的な変更のサブセッ 　 トを選択的にマージすることが必要とされているということである。 　 "activity"は、一つの論理的な変更を表現するのに用いられ、そこでは 　 "activity"は、その単一の論理的な変更を達成するために修正される全ての 　 リソースを効果的にトラックする。"version-controlled resource"がチェッ 　 クアウトされると、ユーザはどの"activity"がその"version-controlled 　 resource"がチェックインされる時に作成される新しい"version"と関連付 　 けられるべきかというのを指定する。それから、MERGEリクエストにおいて、 　 適切な"activity"を指定することで、他の"workspace"にマージするために 　 特定の論理的な変更を選択することが可能である。 　 もう1つの共通的な問題は、"version-controlled resource"が"descent"の 　 複数の系列を持つことを必要としたとしても、指定されたチームのメンバ 　 によって実施された全ての結果は1つの"descent"の系列上になければなら 　 ない（チームメンバの間でのマージを避けるため）ということである 　 "activity"リソースは、この問題を解決するためのしくみを提供する。 　 "version-controlled resource"がチェックアウトされると、クライアント 　 は既存の"activity"が使用されるか、新しい"activity"が作成されることを 　 要求することができる。その時、"activity"のセマンティクスは、"activity" 　 と関連する指定された"version history"内の全ての"version"は、1つの 　 "descent"の系列上にあるということを保証する。チームの全てのメンバが 　 共通の"activity"（もしくは共通の"activity"の"sub-activity）を共有す 　 るならば、そのチームの（複数の）メンバが実施した全ての変更は、1本 　 の"descent"の系列に上にある。 Clemm, et al. Standards Track [Page 90] RFC 3253 Versioning Extensions to WebDAV March 2002 　 以下のダイアグラムは、"activity"をあらわす。"version" V5 は、"activity" 　 Act-2 によって選択された foo.html の最も新しい"version"であり、"version" 　 V8は "activity" Act-2 によって選択された bar.html の最も新しい"version" 　 である。 foo.html History bar.html History +---+ +---+ Act-1| |V1 Act-1| |V6 +---+ +---+ | | | | +---+ +---+ Act-1| |V2 Act-2| |V7 +---+ +---+ / \ | / \ | +---+ +---+ +---+ Act-1| |V3 Act-2| |V4 Act-2| |V8 +---+ +---+ +---+ | | | | +---+ +---+ Act-2| |V5 Act-3| |V9 +---+ +---+ 　 "activity"は、既存のバージョニング・システムに様々な名前の下で現わ 　 れる。"activity"が論理的な変更を捕捉するために使用される場合、それ 　 は一般に"change set"と呼ばれる。"activity"が"descent"の系列を捕捉す 　 るために使用される場合、それは一般に"branch"と呼ばれる。システムが 　 "branch"と"change set"をサポートするならば、特定の"change set"が特 　 定の"branch"上で発生することを要求するのにとても役立つ。この関係は、 　 この関係は、"change set"の"activity"を"branch"の"subactivity"にさせ 　 ることにより捕らえることができる。 13.1 Activity Properties 　 "activity"の"DAV:resourcetype"は、"DAV:activity"でなければなら 　 ない（MUST）。 　 "activity"機能は、"activity"に必要な以下のプロパティを導入する。 13.1.1 DAV:activity-version-set (computed) 　 このプロパティは、この"activity"を指定する"DAV:activity-set"プロ 　 パティを持つ各"version"を定義する。1つの"version history"の複数の 　 "version"は、"activity"の"DAV:activity-version-set"プロパティに 　 より選択されることを可能とする。しかし、与えられた"version history" 　 からくる全ての"DAV:activity-version-set"は、その"version history"の 　 "root version"からの"descent"の1本の系列上になければならない。 Clemm, et al. Standards Track [Page 91] RFC 3253 Versioning Extensions to WebDAV March 2002 13.1.2 DAV:activity-checkout-set (computed) 　 このプロパティは、この"activity"を指定する"DAV:activity-set"を持つ 　 各"check-out"されたリソースを指定する。 13.1.3 DAV:subactivity-set 　 このプロパティは、この"activity"により捕捉されている論理的な変更の部 　 分を形成する各"activity"を指定する。"activity"は、あたかもその 　 "DAV:activity-version-set"が"DAV:subactivity-set"内で指定されている 　 各"activity"の"DAV:activity-version-set"によって拡張されているかのよ 　 うに振舞う。特に、拡張されたセット内の（複数の）"version"は、"descent" 　 の単一の系列上になければならず（MUST）、そして"activity"がマージする 　 "version"を選択する時に、拡張されたセット内の最新の"version"がマージ 　 される1つである。 　 サーバは、"activity"の"DAV:subactivity-set"の変更の試みをリジェクトし 　 てもよい（MAY）。 13.1.4 DAV:current-workspace-set (computed) 　 このプロパティは、この"activity"が指定する"DAV:current-activity-set"を 　 持つ各"workspace"を指定する。 13.2 Additional Version Properties 　 "activity"機能は、"version"に以下の必要なプロパティを導入する。 Clemm, et al. Standards Track [Page 92] RFC 3253 Versioning Extensions to WebDAV March 2002 13.2.1 DAV:activity-set 　 このプロパティは、この"version"をどの論理的な変更に、そしてこの 　 "version"が出現するどの"descent"の系列に提供するかを決定する（複数の） 　 "activity"を指定する。サーバは、1つの"activity"を指定するよう 　 "DAV:activity-set"を制限してもよい。サーバは、変更される"version"の 　 "DAV:activity-set"プロパティの値の許可を拒絶してもよい。 13.3 Additional Checked-Out Resource Properties 　 "activity"機能は、"checked-out resource"のために、以下の必要なプロ 　 パティを導入する。 13.3.1 DAV:unreserved 　 "checked-out resource"のこのプロパティは、この"version-controlled 　 resource"の"version history"と関係する他の"checked-out resource"の 　 "DAV:activity-set"がこの"checked-out resource"の"DAV:activity-set" 　 プロパティ内にある"activity"を持つことができるかどうかを示す。"activity" 　 が与えられた"version history"について1本の"descent"の系列を形成し 　 なくてはならないという要求の結果は、無条件に1つの"activity"にチェッ 　 クアウトされ、最初のCHECKINのみが成功する。これらの"checked-out 　 resource"のもう一方は、チェックインされる前に、ユーザは最初に"version 　 history"の"activity"によって選択される最新"version"を"checked-out 　 resource"にマージしなくてはならず、それから"checked-out resource" 　 の"DAV:predecessor-set"をその"version"を指定するように変更する。 PCDATA value: boolean 13.3.2 DAV:activity-set 　 "checked-out resource"のこのプロパティは、このリソースをチェックイン 　 した結果の"version"の"DAV:activity-set"プロパティを決定する。 13.4 Additional Workspace Properties 　 "activity"機能は、"workspace"について以下の必要なプロパティを導入する。 Clemm, et al. Standards Track [Page 93] RFC 3253 Versioning Extensions to WebDAV March 2002 13.4.1 DAV:current-activity-set 　 このプロパティは、この"workspace"内で実行されている"activity"を指定する。 　 この"workspace"のメンバがチェックアウトされると、CHECKOUTリクエストにて 　 "activity"が指定されない場合には、"DAV:current-activity-set"が使用される。 　 このことは、"activity"を意識しない（"activity-unaware"な）クライアント 　 が"activity"の記録（tracking）が必要な"workspace"をアップデートするこ 　 とを許可する。"DAV:current-activity-set"は、最大1つの"activity"を指定 　 するように制限してもよい（MAY）。 13.5 MKACTIVITY Method 　 MKACTIVITYリクエストは、新しい"activity resource"を作成する。サーバは 　 特定の"collection"に対する"activity"の作成を制限してもよい（MAY）。しか 　 し、クライアントはOPTIONSリクエストの"DAV:activity-collection-set"から 　 これらの"collection"の配置を決定することができる。 　 順序： Marshalling: 　　　リクエストボディが含まれるならば、それは"DAV:mkactivity"XML 　　　エレメントでなくてはならない（MUST）。 　　　リクエストが成功して、レスポンスボディが含まれるならば、それは 　　　"DAV:mkactivity-response"XMLエレメントでなくてはならない（MUST）。 　　　レスポンスは、"Cache-Control:no-cache"ヘッダを含まなければならない 　　　（MUST）。 Preconditions: (DAV:resource-must-be-null): request-URLの場所にリソースは存在しては 　　　ならない（MUST NOT）。 (DAV:activity-location-ok): request-URLは、"activity"が作成可能な 　　　場所を指定しなくてはならない（MUST）。 Postconditions: 　　　(DAV:initialize-activity): 新しい"activity"がrequest-URLに存在する。 　　　"activity"の"DAV:resourcetype"は、"DAV:activity"でなければならない 　　　（MUST）。 Clemm, et al. Standards Track [Page 94] RFC 3253 Versioning Extensions to WebDAV March 2002 13.5.1 Example - MKACTIVITY >>REQUEST MKACTIVITY /act/test-23 HTTP/1.1 Host: repo.webdav.org Content-Length: 0 >>RESPONSE HTTP/1.1 201 Created Cache-Control: no-cache 　 この例では、新しい"activity"が http://repo.webdav.org/act/test-23 に 　 作成されている。 13.6 DAV:latest-activity-version Report 　 "DAV:latest-activity-version report"は、"version history"に対して適用 　 され、与えられた"activity"によってその"version history"から選択される 　 最新の"version"を指定する。 Marshalling: 　　　リクエストボディは、"DAV:latest-activity-version"XMLエレメントで 　　　なければならない（MUST）。 　　　リクエストが成功した際に帰ってくるレスポンスボディは、 　　　"DAV:latest-activity-version-report"XMLエレメントでなくてはならない 　　　（MUST）。 　　　レスポンスボディ中の"DAV:href"は、与えられた"version history"の 　　　"version"を指定する必要がある（MUST）。この"version"は、 　　　"DAV:activity-version-set"のメンバであり、その"activity"の 　　　"DAV:activity-version-set"のメンバである"descendant"を持たない。 Preconditions: (DAV:must-be-activity): リクエストボディ中の"DAV:href"は、"activity" 　　　を指定しなくてはならない（MUST）。 Clemm, et al. Standards Track [Page 95] RFC 3253 Versioning Extensions to WebDAV March 2002 13.7 Additional OPTIONS Semantics 　 サーバが"activity"機能をサポートするならば、全てのバージョニングプロ 　 パティ、レポートもしくはメソッドをサポートする全てのリソースに対する 　 OPTIONSリクエストに対するレスポンスに含まれる"DAV"レスポンスヘッダ中 　 のフィールドに、"activity"が含まれる必要がある（MUST）。 　 "DAV:activity-collection-set"エレメントは、"activity resource"を含ん 　 でもよい"collection"を指定するために、リクエストボディ中に含まれても 　 よい（MAY）。 Additional Marshalling: 　　　XMLリクエストボディが含まれるならば、それは"DAV:options"XMLエレ 　　　メントでなくてはならない（MUST）。 　　　ANY 値：最大1つの"DAV:activity-collection-set"エレメントをともなう 　　　エレメントの並び 　　　リクエストが成功して、XMLレスポンスボディが含まれるならば、それは 　　　"DAV:options-response"XMLエレメントでなければならない（MUST）。 　　　ANY 値：最大1つの"DAV:activity-collection-set"エレメントをともなう 　　　エレメントの並び 　　　"DAV:activity-collection-set"がリクエストボディに含まれるならば、 　　　リクエストが成功した場合のレスポンスボディには、"activity"を含ん 　　　でもよい"collection"を指定する"DAV:activity-collection-set"エレ 　　　メントを含まなくてはならない（MUST）。指定された"collection"は、 　　　"collection"のツリーの"root collection"であってもよく（MAY）、 　　　全ての"collection"は"activity"を含んでもよい。異なるサーバがURL 　　　名前空間の異なる部分を制御出来るため、同じホスト上の異なるリソー 　　　スは、異なる"DAV:activity-collection-set"の値を持っていてもよい 　　　（MAY）。指定された"collection"は、リソースとは異なるホストに置 　　　かれてもよい（MAY）。 13.8 Additional DELETE Semantics Additional Postconditions: 　　　(DAV:delete-activity-reference): "activity"が削除されたら、 　　　"DAV:activity-set"、"DAV:subactivity-set"もしくは 　　　"DAV:current-activity-set"中のその"activity"への参照は削除されな 　　　くてはならない（MUST）。 Clemm, et al. Standards Track [Page 96] RFC 3253 Versioning Extensions to WebDAV March 2002 13.9 Additional MOVE Semantics Additional Postconditions: 　　　(DAV:update-checked-out-reference): "checked-out resource"が移動され 　　　たら、"DAV:activity-checkout-set"プロパティ中のそのリソースへの全ての 　　　参照はそのリソースの新しい場所への参照へとアップデートされなければ 　　　ならない（MUST）。 　　　(DAV:update-activity-reference): request-URLが"activity"を指定する 　　　ならば、"DAV:activity-set"、"DAV:subactivity-set"もしくは 　　　"DAV:current-activity-set"中のその"activity"へのすべての参照は 　　　そのリソースの新しい場所への参照にアップデートされなければならない 　　　（MUST）。 　　　(DAV:update-workspace-reference): request-URLが"workspace"を指定 　　　するならば、"DAV:current-workspace-set"プロパティ内のその"workspace" 　　　への参照は、その"workspace"の新しい場所への参照にアップデートされ 　　　なければならない。 13.10 Additional CHECKOUT Semantics 　 CHECKOUTリクエストは、"checked-out resource"のための"DAV:activity-set"を 　 指定してもよい（MAY）。 Additional Marshalling: ANY 値：最大1つの"DAV:activity-set"と 　　 最大1つの"DAV:unreserved"をともなうエレメントの並び Additional Preconditions: 　　　(DAV:one-checkout-per-activity-per-history): "request activity set" 　　　があったら、"DAV:unreserved"が指定されない限り、その"version history" 　　　の"versionからの他の"checkoutはその"activity set"中の"activity"を選 　　　択してはならない（MUST NOT）。 　　　(DAV:linear-activity): "request activity set"があったら、 　　　"DAV:unreserved"が指定されない限り、選択された"version"はその 　　　"activity"を選択するその"version history"の他の全ての"version"の 　　　"descendant"であってはならない（MUST NOT）。 Clemm, et al. Standards Track [Page 97] RFC 3253 Versioning Extensions to WebDAV March 2002 Additional Postconditions: 　　　(DAV:initialize-activity-set): "checked-out resource"の 　　　"DAV:activity-set"は、以下のように設定される。 - "DAV:new"が"DAV:activity-set"としてリクエストボディ中に設定 　　　　 されたら、サーバによって生成ｓあれる新しい"activity"が使用される。 - もしくは、（複数の）"activity"がリクエストボディ中で指定されたら、 　　　　 それらの"activity"が使用される。 - もしくは、"version-controlled resource"が"workspace"のメンバであ 　　　　 り、そして"workspace"の"DAV:current-activity-set"が設定されていた 　　　　 ら、それらの"activity"が使用される。 - もしくは、"DAV:checked-out version"の"DAV:activity-set"が使用 　　　　 される。 (DAV:initialize-unreserved): "DAV:unreserved"がリクエストボディで 　　　指定されたら、"checked-out resource"の"DAV:unreserved"プロパティは 　　　"true"でなければならない（MUST）。 13.10.1 Example - CHECKOUT with an activity >>REQUEST CHECKOUT /ws/public/foo.html HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://repo.webdav.org/act/fix-bug-23 >>RESPONSE HTTP/1.1 200 OK Cache-Control: no-cache 　 この例では、CHECKOUTは "activity" http://repo.webdav.org/act/fix-bug-23 　 内で実行される。 Clemm, et al. Standards Track [Page 98] RFC 3253 Versioning Extensions to WebDAV March 2002 13.11 Additional CHECKIN Semantics Additional Preconditions: 　　　(DAV:linear-activity): "checked-out resource"の"version history"内 　　　にあったり、"checked-out resource"の"DAV:activity-set"からの 　　　"activity"を指定する"DAV:activity-set"を持つ全ての"version"は、 　　　"checked-out resource"の"ancestor"でなければならない（MUST）。 　　　(DAV:atomic-activity-checkin): request-URLが"activity"を指定する 　　　ならば、もしその"activity"もしくはのその"activity"のいずれかの 　　　"subactivity"の"DAV:activity-checkout-set"内の"checked-out resource" 　　　のいずれかがチェックインされないならば、サーバはそのリクエストを 　　　失敗してもよい（MAY）。 Additional Postconditions: 　　　(DAV:initialize-activity-set): 新しい"version"の"DAV:activity-set" 　　　は、"checked-out resource"の"DAV:activity-set"と同じになるように初 　　　期化されなければならない（MUST）。 　　　(DAV:activity-checkin): request-URLが"activity"を指定するならば、 　　　サーバはCHECKINリクエストをその"activity"および、その"activity"の 　　　全ての"activity"の"DAV:activity-checkout-set"中の各"checked-out 　　　resource"へ無事適用しなくてはならない（MUST）。 13.12 Additional MERGE Semantics 　 リクエストボディの"DAV:source"エレメントが"activity"を指定するならば、 　 その"activity"によって選択される"version"を含む各"version history"に 　 ついて、その"activity"で指定される最新の"version"が"merge source"とな 　 る。"activity"によって選択される（複数の）"version"は、その 　 "DAV:subactivity-set"によって選択される"version"と結合されるその 　 "DAV:activity-version-set"内の"version"であることに注意せよ。 Additional Marshalling: Additional Postconditions: 　　　(DAV:checkin-activity): "DAV:checkin-activity"がリクエストボディで 　　　指定され、そしてリクエストボディ内の"DAV:source"エレメントが 　　　"activity"を指定するならば、CHECKINリクエストは（複数の） 　　　"merge source"が決定される前にその"activity"に対して無事適用されな 　　　ければならない（MUST）。 Clemm, et al. Standards Track [Page 99] RFC 3253 Versioning Extensions to WebDAV March 2002 14 Version-Controlled-Collection Feature 　 任意の"versionable resource"でのように、"collection"が"version control" 　 配下に置かれると、その"version controlled collection"のための"version"を 　 含むように"version history resource"が作成される。通常のバージョニングの 　 セマンティクスを保護するために（"collection"の"version"は、変更されるべ 　 きではない）、"collection"の"version"はその"collection"の（複数の） 　 "version controlled binding"に関する情報のみを記録する。内容やデッド 　 プロパティの更新を名前空間の更新と簡潔に分割するために、"collection"の 　 "version"はメンバを持たないが、その代わりにその 　 "DAV:version-controlled-binding-set"プロパティに"binding name"および 　 "collection"の内部の各"version-controlled member"を記録する。 　 もしそうでなく、"collection"の"version"が（複数の）他の"version"に対す 　 る"binging"を含んでいたならば、 リソースの新しい"version"の作成は、そ 　 のリソースを含む"collection"の全ての（複数の）"version"の新しい"version" 　 の作成が必要となっただろう。そして、それは"activity"をもつれさせただ 　 ろう。 　 たとえば、"feature-12" という "activity" が/x/y/a.html の新しい 　 "version"を作成したと推測しよう。もし、"collection"の"version"が、その 　 メンバの"version"に対する"binding"を含んでいたら、/x/y の新しい"version" 　 は/x/y/a.htmlの新しい"version"を含むように作成されなければならず、/x 　 の新しい"version"は/x/yの新しい"version"を含むように作成されなければ 　 ならない。 　 今、"bugfix-47"という"activity"が/x/z/b.htmlの新しい"version"を作成した。 　 ふたたび、/x/zの新しい"version"および/xの新しい"version"が/x/y/b.html 　 （これ、/x/z/b.htmlの間違いじゃないのか？（by WAKATONO））の新しい 　 "version"を含むよう作成される。しかし、今や"bugfix-47"を"feature-12"の 　 ない別の"workspace"へマージするのは不可能である。というのも、/x/z/b.html 　 の要求された"version"を含む/x の "version"も、"feature-12"に作成された 　 /x/y/a.html の"version"を含むからである。さて、かわりに"collection"の 　 "version"が"binding name"および内部的な各"version-controlled member"の 　 "version history resource"のみを記録しているならば、その"collection"の 　 メンバによって選択される"version"の変更は、"collection"の新しい 　 "version"を必要としない。新しい"version"は、依然として同じ 　 "version history"内に存在するため、新しい"collection"の"version"は要求 　 されず、"feature-12"および"bugfix-47"はもつれない。 　 以下の例では、"collection"の"version"を含む"version history"が3つあり、 　 それぞれVH14,VH19,VH24と名づけられている。VH14は"collection"の 　 "version"を含む。"version-controlled collection"の/xは、"version history" 　 VH14 の "version" V2 を "DAV:checked-in" で示される"version"としてもって 　 いる。"V2は2つの"version controlled binding"を持っており、"binding name" 　 として"a"を付与されている方は"version history" VH19 をともなっており、 　 他方の"b"を付与されている方は"version history" VH24 をともなっている。 　 このため、/x は2つの"version-controlled binding"を持たなくてはならず 　 （MUST）、"a"と名づけられた方は "version history" VH19に対してのもの 　 であり、他の"b"と名づけられた方は"version history" VH24のものである。 　 "version-controlled resource" /x/a は、現在 "DAV:checked-in"の"version" 　 としてVH19のV4を現在保持しており、一方/x/b は、"DAV:checked-in"の 　 "version"として現在VH24のV8を保持している。 Clemm, et al. Standards Track [Page 100] RFC 3253 Versioning Extensions to WebDAV March 2002 VH19 +---------+ | +---+ | | | |V4 | | +---+ | | | | | | | | +---+ | | | |V5 | VH14 | +---+ | +---------+ | | | | +---+ | | | | a +---+ | | |V1 | | +---+ | ---->| |checked-in=V4 | +---+ | a | | |V6 | / +---+ | | ------>| +---+ | / | | / | +---------+ +---+ | +---+ | /x | |checked-in=V2 | | |V2 | +---+ | +---+ | VH24 \ | | \ | b +---------+ \ b +---+ | | ------>| +---+ | ---->| |checked-in=V8 | +---+ | | | |V7 | +---+ | | |V3 | | +---+ | | +---+ | | | | +---------+ | | | | +---+ | | | |V8 | | +---+ | | | | | | | | +---+ | | | |V9 | | +---+ | +---------+ 　 "checked-in"な"version-controlled collection"の 　 "version-controlled binding"を変更する任意のリクエスト 　 （例：DELETE,MOVE,COPY）については、リクエストは失敗しなければなら 　 ない。ただし、"version-controlled collection"がその"collection"が 　 変更された時に"version-controlled collection"を自動的にチェックア 　 ウトするような"DAV:auto-version"プロパティを持っている場合はこの 　 限りではない。 　 "collection"の"version"は"collection"の"version-controlled binding" 　 のみを記録するが、"version-controlled collection"は"version-controlled" 　 および"non-version-controlled"な"binding"を両方とも含んでよい（MAY）。 　 "non-version-controlled binding"は、"version control"配下にはなく、 　 その結果、"version-controlled collection"のチェックアウトをすること 　 なく追加や削除を行うことができる。 Clemm, et al. Standards Track [Page 101] RFC 3253 Versioning Extensions to WebDAV March 2002 　 "collection"の"version"は、"collection"の状態のうち定義されたサブセッ 　 トのみを捕捉することに注意せよ。特に、"collection"の"version"は、その 　 デッドプロパティと"version-controlled resource"への"binding"は捕捉す 　 るが、ライブプロパティおよび"non-version-controlled resource"に対する 　 "binding"は捕捉しない。 　 サーバが"working-resource"機能をサポートするならば、クライアントは 　 "working collection"を作成するために"collection"の"version"をチェッ 　 クアウトできる。 　 "version-controlled resource"への"binding"と"non-version-controlled 　 resource"への"binding"を含む"version-controlled collection"とは違い、 　 "working collection"は"version history resource"および 　 "non-version-controlled resource"への"binding"を含む。特に、 　 "working collection"はチェックアウトされた"collection"の"version"の 　 "DAV:version-controlled-binding-set"によって指定される"version history 　 resource"に対する"binding"を含むように初期化される。それから、 　 "working collection"のメンバは削除したり他の"working collection"へ 　 移動したりすることが出来る。"non-version-controlled resource"は、 　 PUTやCOPYやMKCOLのようなメソッドを使うことで"working collection"に追加 　 することが可能である。"working collection"ｇたチェックインされると、 　 VERSION-CONTROLリクエストは自動的に"working collection"の全ての 　 "non-version-controlled member"に適用され、各"non-version-controlled 　 member"は新たに作成されたそれらの"version history"によって置き換えら 　 れる。"working collection"をチェックインした結果作成される新しい 　 "version"の"DAV:version-controlled-binding-set"は、"working collection" 　 の各メンバのための"binding name"および"version history"のURLを含む。 14.1 Version-Controlled Collection Properties 　 "version-controlled collection"は、"collection"および 　 "version-controlled resource"の全てのプロパティを持つ。それに加え、 　 "version-controlled-collection"機能は、"version-controlled collection" 　 に必要な以下のプロパティを導入する。 14.1.1 DAV:eclipsed-set (computed) 　 このプロパティは、"collection"の"version-controlled internal member"の 　 影を現状薄くしていっている"collection"の"non-version-controlled 　 internal member"を指定する。 !ELEMENT eclipsed-set (binding-name*)> PCDATA value: URL segment Clemm, et al. Standards Track [Page 102] RFC 3253 Versioning Extensions to WebDAV March 2002 　 UPDATEもしくはMERGEリクエストは、"version-controlled collection"に 　 既存の"non-version-controlled internal member"と同じ名前を持つ 　 "version-controlled internal member"を与える。このケースでは、 　 "non-version-controlled internal member"は先行し、それは新しい 　 "version-controlled internal member"の「影を薄くする」と言われる。 　 "non-version-controlled internal member"が削除されると（例：DELETE 　 もしくはMOVEによる）、"version-controlled internal member"が表に 　 出てくる。 14.2 Collection Version Properties 　 "collection"の"version"は、"version"が持つ全てのプロパティを持つ。 　 それに加え、"version-controlled-collection"機能は"collection version"の 　 ために、以下の必要なプロパティを導入する。 14.2.1 DAV:version-controlled-binding-set (protected) 　 このプロパティは、"collection"の各"version-controlled internal member" 　 の名前と"version history"を捕捉する。 PCDATA value: URL segment 14.3 Additional OPTIONS Semantics 　 サーバが"version-controlled-collection"機能をサポートするならば、 　 任意のバージョニングプロパティ、レポートもしくはメソッドをサポートする 　 任意のリソースに対するOPTIONSリクエストの"DAV"レスポンスヘッダの 　 フィールドに"version-controlled-collection"を含まなければならない（MUST）。 14.4 Additional DELETE Semantics Additional Preconditions: 　　　(DAV:cannot-modify-checked-in-parent): request-URLが 　　　"version-controlled resource"を指定するならば、 　　　"version-controlled resource"を含む"collection"が"checked-in"な 　　　"version-controlled collection"な時には、"DAV:auto-version"セマ 　　　ンティクスが自動的に"version-controlled collection"をチェックア 　　　ウトしない限りはDELETEは失敗しなければならない（MUST）。 Clemm, et al. Standards Track [Page 103] RFC 3253 Versioning Extensions to WebDAV March 2002 14.5 Additional MKCOL Semantics Additional Preconditions: 　　　リクエストが"version control"配下に自動的に置かれる新しいリソースを 　　　作成するならば、全てのVERSION-CONTROLの"precondition"がリクエストに 　　　対して適用される。 Additional Postconditions: 　　　新しい"collection"が自動的に"version control"配下に置かれるならば、 　　　VERSION-CONTROLの全ての"postcondition"はリクエストに対して適用される。 14.6 Additional COPY Semantics Additional Preconditions: (DAV:cannot-copy-collection-version): リクエストのsourceが"collection"の 　　　"version"であるならば、リクエストは失敗しなければならない（MUST）。 14.7 Additional MOVE Semantics Additional Preconditions: (DAV:cannot-modify-checked-in-parent): リクエストのsourceが 　　　"version-controlled resource"だった場合、sourceを含む"collection"が 　　　"checked-in"な"version-controlled collection"である時には 　　　"DAV:auto-version"セマンティクスが自動的に"version-controlled 　　　collection"をチェックアウトしない限りはリクエストは失敗しなけれ 　　　ばならない（MUST）。 (DAV:cannot-modify-destination-checked-in-parent): リクエストの 　　　sourceが"version-controlled resource"ならば、destinationを含む 　　　"collection"が"checked-in"な"version-controlled collection"だった 　　　場合には、"DAV:auto-version"セマンティクスが自動的に"version-controlled 　　　collection"をチェックアウトしない限りはリクエストは失敗しなけれ 　　　ばならない（MUST）。 14.8 Additional VERSION-CONTROL Semantics Additional Preconditions: (DAV:cannot-modify-checked-in-parent): request-URLの親が 　　　"checked-in version-controlled collection"であるならば、 　　　"DAV:auto-version"セマンティクスが自動的に"version-controlled 　　　collection"をチェックアウトしない限りはリクエストは失敗しなけれ 　　　ばならない（MUST）。 Clemm, et al. Standards Track [Page 104] RFC 3253 Versioning Extensions to WebDAV March 2002 Additional Postconditions: 　　　(DAV:new-version-controlled-collection): リクエストボディが 　　　"collection"の"version"を指定するならば、request-URLの"collection" 　　　は"collection"の"version"の"DAV:version-controlled-binding-set"内で 　　　指定される各"DAV:version-controlled-binding"の"version-controlled 　　　internal member"を含まなければならず（MUST）、その"collection"の 　　　"internal member"の名前と"DAV:version-history"は 　　　"DAV:version-controlled-binding"によって指定される 　　　"DAV:binding-name"および"DAV:version-history"でなければならない 　　　（MUST）。"internal member"が"workspace"のメンバであり、同じ 　　　"version history"の"workspace"の他のメンバが存在するならば、これら 　　　の2つのメンバは同じ"version-controlled resource"を指定しなくてはな 　　　らない（MUST）。そうでなければ、"version history"nのサーバが選択し 　　　た"version"をともなうVERSION-CONTROLリクエストは、その"internal 　　　member"のURLに対して適用されなければならない（MUST）。 14.9 Additional CHECKOUT Semantics Additional Postconditions: 　　　(DAV:initialize-version-history-bindings): リクエストが"collection" 　　　の"version"に対して適用されるならば、新しい"working collection"はそ 　　　の"collection"の"version"の"DAV:version-controlled-binding-set"内で 　　　指定される各"history resource"（多分"version history"だと思う 　　　（by WAKATONO））に対する"binding"を含むよう初期化されなければならな 　　　い（MUST）。 14.10 Additional CHECKIN Semantics Additional Postconditions: 　　　(DAV:initialize-version-controlled-bindings): request-URLが 　　　"version-controlled-collection"を指定するならば、新しい"collection"の 　　　"version"の"DAV:version-controlled-binding-set"は"version-controlled 　　　collection"の各"version-controlled binding"のための"binding name"と 　　　"version history"を指定した"DAV:version-controlled-binding"を含まな 　　　くてはならない（MUST）。 (DAV:version-control-working-collection-members): request-URLが 　　　"working collection"を指定するならば、VERSION-CONTROLリクエストは 　　　"working collection"の全ての"non-version-controlled member"に対して 　　　自動的に適用されなければならず（MUST）、各"non-version-controlled 　　　member"は新しく作成された"version history"に置き換えられなければな 　　　らない（MUST）。もし、"working collection"のメンバが 　　　"non-version-controlled collection"であった場合、 　　　"non-version-controlled collection"の全てのメンバは、 　　　"non-version-controlled collection"が"version control"配下に置かれ 　　　る前に"version control"配下に置かれなければならない（MUST）。新しい 　　　"collection"の"version"の"DAV:version-controlled-binding-set"は、 　　　"working collection"の各メンバの"binding name"および"version 　　　history"のURLを指定する"DAV:version-controlled-binding"を含まなけ 　　　ればならない（MUST）。 Clemm, et al. Standards Track [Page 105] RFC 3253 Versioning Extensions to WebDAV March 2002 14.11 Additional UPDATE and MERGE Semantics Additional Postconditions: 　　　(DAV:update-version-controlled-collection-members):リクエストが 　　　"version-controlled collection"の"DAV:checked-in"の"version"を変 　　　更するならば、その"version-controlled collection"の 　　　"version-controlled member"はアップデートされなければならない 　　　（MUST）。特に： - もし、その"version history"が新しい"DAV:checked-in"の 　　　　 "version"の"DAV:version-controlled-binding-set"によって指定 　　　　 されない場合には、"version-controlled internal member"は、 　　　　 削除されなければならない（MUST）。 - "binding name"が新しい"DAV:checked-in"な"version"の 　　　　 "DAV:version-controlled-binding-set"内の"version history"の 　　　　 ための"DAV:biding-name"と異なる場合、与えられた"version history" 　　　　 の"version-controlled internal member"はリネームされなければ 　　　　 ならない（MUST）。 - "version history"が"DAV:checked-in"な"version"の 　　　　 "DAV:version-controlled-binding-set"によって指定され、しかし 　　　　 その"version history"のための"version-controlled collection"の 　　　　 メンバが存在しない。時、新しい"version-controlled internal member" 　　　　 は、作成されなければならない（MUST）。新しい"version-controlled 　　　　 member"がすでに"version history"に対応した"version-controlled 　　　　 resource"を持っている"workspace"である場合には、新しい 　　　　 "version-controlled member"は存在する"version-controlled 　　　　 resource"の単なる"binding"（例：そのための他の名前）でなくて 　　　　 はならない。もしくは、新しい"version-controlled member"の内容と 　　　　 デッドプロパティは、リクエストによってその"version history"で 　　　　 指定した"version"のそれを用いて初期化される必要がある。もしリク 　　　　 エストによって"version history"の"version"が指定されない場合に 　　　　 は、選択される"version"は、サーバが定義したものになる。 15 Internationalization Considerations 　 この仕様は、IETFポリシーであるキャラクターセットおよび言語[RFC2277]に 　 準拠するようにデザインされている。特に、human-readableな文字列がプロト 　 コル内のどこに存在するか、charsetが使用される場所を指定するために、 　 そのcharsetが明示的に定まっているか、XMLのしくみが使用されている。 　 くわえて、これらのhuman-readableな文字列全ては自然言語の文字列を表 　 現する能力がある。 Clemm, et al. Standards Track [Page 106] RFC 3253 Versioning Extensions to WebDAV March 2002 　 このプロトコル中のhuman-readableな文字列の大半は、 　 "DAV:creator-displayname"のようなプロパティ中に現れる。RFC2518で定義さ 　 れているように、プロパティはXMLのように並んだその値を持っている。XMLは 　 文字セットのタギング、エンコーディングに関する明確な規定を持っており、 　 XMLプロセッサは最低限ISO10646マルチリンガルプレーンのUTF-8[RFC2279]エン 　 コーディングを用いてエンコードされたXMLエレメントを読むことを要求する。 　 XMLの"encoding"アトリビュートとともに"Content-Type"ヘッダのcharsetパラ 　 メータは、MIMEおよびXMLプロセッサに対してcharsetを決定するための情報を 　 提供する。XMLとcharsetヘッダの適切な使用については、RFC3023に記述されて 　 いる。XMLは特定のXMLエレメントの内容の言語を指定する言語タグ能力も提供す 　 る。XMLはIANAに登録された言語タグ（RFC3066を参照のこと）もしくはISO639 　 言語タグをXMLエレメントの"xml:lang"属性中にて指定し、その言語の内容と 　 属性を指定する。 　 DeltaVアプリケーションは、WebDAVの上に構築されているために、RFC2518の 　 Section 16に記述されている国際化要求に従う。簡単に述べるならば、 　 これらの必要条件は、XMLキャラクタセットによるタギング、文字セットエン 　 コーディング、そして言語タギング能力の使用を命ずるものです。 　 加えて、XMLトランスポートのためのMIMEメディアタイプおよびcharsetヘッダ 　 の使用法の理解のために、RFC3023を読むことを推奨している。 　 この詳細では、ラベルは"Label"ヘッダおよびリクエストのエンティティボディ 　 内のXMLとして並んでいるhuman-readableな文字列である"Label"ヘッダ内で使用 　 される時には、その"label"の値はURLエスケープされ、UTF-8でエンコードされ 　 ている必要がある。 16 Security Considerations 　 RFC2518のSection 17 にて議論されたWebDAVにおける全てのセキュリティの 　 重要性は、WebDAV Versioningにもあてはまる。バージョニングプロトコルの 　 いくつかの面は、WebDAVによるセキュリティリスクを処置するのに役立つが、 　 他の面はセキュリティリスクを増大させる可能性がある。これらの問題につ 　 いては、以下で詳細を述べる。 　 16.1 Auditing and Traceability 　 WebDAVは、リモートクライアントがWebサイト上のリソースを変するのを容易 　 にするが、このことで、ユーザの間違いや悪意により重要な情報が上書きされ 　 たり失われたりする危険性も増大している。WebDVのバージョニングの使用は、 　 不変の"version"の構成により前の情報を保存するような保証をすることによ 　 り、この問題に対処することを助け、結果として情報の訂正や回復がより簡単 　 に出来るようになる。加えて、"version history"は、いつ誰による変更が行 　 われたかという記録を提供する。リクエストが適切に認証されているならば、 　 "history"の仕組みはWebリソースの変更を扱う明確な監査のしくみを提供す 　 る。これは、しばしば著しくセキュリティ問題の元を識別し、かつそのため 　 にそれに対する警戒を今後支援する能力を改善することができる。 Clemm, et al. Standards Track [Page 107] RFC 3253 Versioning Extensions to WebDAV March 2002 16.2 Increased Need for Access Control 　 WebDAVバージョニングは、情報の関連したピースの間をつなぐバリエーショ 　 ンを提供する。これは、これは、認証または認可のエラーがクライアントが 　 敏感な情報を見つけることを可能にするという危険を増加させる可能性があ 　 る。たとえば、もし"version history"に対してアクセスコントロールによる 　 適切な保護がされていなかったら、クライアントはパブリックリソースの 　 "version history"を用いて、ユーザがまだ公開していないリソースの最新 　 版を指定できる。このことは、信頼できる認証と正確な認可の必要性を増大 　 させる。 　 WebDAVのバージョニングクライアントは、リソースによって提供されるプロ 　 パティとレポートにアクセスする時の200(OK)と403(Forbidden)レスポンスの 　 混在を操作できるように設計されるべきである。たとえば、特定のユーザが 　 "version-controlled resource"の内容とデッドプロパティへのアクセス認 　 可を受けたが、そのリソースの"DAV:checked-in","DAV:checked-out",もし 　 くは"DAV:version-history"プロパティへのアクセス認可は受けていない。 16.3 Security Through Obscurity 　 「不明瞭さ」はセキュリティの有効な手段ではないと認められている一方、 　 正直な人々を正直にしておくことは多くの場合よいテクニックである。この 　 プロトコルにおいて、"version"のURLや"version history"のURLや"working 　 resource"のURLはサーバによって生成され、これはそれらに注意を引き付け 　 ないように適切に不明瞭にされる。たとえば、 　 "http://foobar.com/reviews/salaries.html"の"version"は、 　 "http://foobar.com/repo/4934943"のようなURLを割り当てられるかもしれ 　 ない。 16.4 Denial of Service 　 リソースに対する各アップデートが、潜在的に新しい"version resource"の 　 作成につながるため、WebDAVによって提供されるオートバージョニングのし 　 くみは、サーバ上に生成されるリソースの数が結果として大きくなりうる。 　 これは、サーバのストレージ容量の増大によるサービス妨害 　 （Denial of Services）攻撃のリスクを増大させる。編集クライアントによっ 　 て提供される積極的な自動保存機能のようなものによる予期せぬ結果として 　 このようなことが発生する可能性があるので、これは特に重要である。サー 　 バは、"version"追加のコストを最小化するためにデルタストレージテクニッ 　 クを用いたり、ロックをかけるクライアントに対するオートバージョニングを 　 制限したりすることで、このリスクを下げることが出来る。そして、そうす 　 ることで、不注意な多くの"version"の作成を減らす。 Clemm, et al. Standards Track [Page 108] RFC 3253 Versioning Extensions to WebDAV March 2002 17 IANA Considerations This document uses the namespace defined by RFC 2518 for XML elements. All other IANA considerations from RFC 2518 are also applicable to WebDAV Versioning. 18 Intellectual Property The following notice is copied from RFC 2026, Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the procedures of the IETF with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 19 Acknowledgements This protocol is the collaborative product of the authors and the rest of the DeltaV design team: Boris Bokowski, Bruce Cragun (Novell), Jim Doubek (Macromedia), David Durand (INSO), Lisa Dusseault (Xythos), Chuck Fay (FileNet), Yaron Goland, Mark Hale (Interwoven), Henry Harbury (Merant), James Hunt, Jeff McAffer (OTI), Peter Raymond (Merant), Juergen Reuter, Edgar Schwarz (Marconi), Eric Sedlar (Oracle), Bradley Sergeant, Greg Stein, and John Vasta (Rational). We would like to acknowledge the foundation laid for us by the authors of the WebDAV and HTTP protocols upon which this protocol is layered, and the invaluable feedback from the WebDAV and DeltaV working groups. Clemm, et al. Standards Track [Page 109] RFC 3253 Versioning Extensions to WebDAV March 2002 20 References [ISO639] ISO, "Code for the representation of names of languages", ISO 639:1988, 1998. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring - WEBDAV", RFC 2518, February 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. Clemm, et al. Standards Track [Page 110] RFC 3253 Versioning Extensions to WebDAV March 2002 Appendix A - Resource Classification 　 このドキュメントでは、"version-controlled resource","version", 　 "checked-out resource", "version history resource"のように、 　 いくつかの異なる種類のバージョニングリソースを導入している。 　 クライアントがサーバ上でリソースを探すときに、これらはリソースを 　 階層化するのに有用であることがわかる。（例：アイコンとメニュー 　 オプションの選択についてUIの決定を行う） 　 クライアントは、リソースの"DAV:supported-method-set"および 　 "DAV:supported-live-property-set"プロパティの値を見ることで 　 リソースの階層化を行うべきである（Section 3.1.3を参照のこと）。 　 以下のリストは、バージョニングリソースの種類ごとにサポートさ 　 れているライブプロパティとメソッドの一覧である。付加機能は新しい 　 種類のバージョニングリソースを紹介しており、その機能は、その種 　 類のバージョニングリソースの名前に続く括弧内に付記してある。ラ 　 イブプロパティやメソッドがあるバージョニングリソースの付加機能 　 である場合、そのライブプロパティやメソッドを紹介している機能は 　 そのライブプロパティやメソッド名に続く括弧内に付記してある。 A.1 DeltaV-Compliant Unmapped URL ( リソースを指定しない URL ) サポートされるメソッド： - PUT [RFC2616] - MKCOL [RFC2518] - MKACTIVITY (activity) - VERSION-CONTROL (workspace) - MKWORKSPACE (workspace) A.2 DeltaV-Compliant Resource サポートされるライブプロパティ： - DAV:comment - DAV:creator-displayname - DAV:supported-method-set - DAV:supported-live-property-set - DAV:supported-report-set - WebDAV [RFC2518] で定義される全てのプロパティ Clemm, et al. Standards Track [Page 111] RFC 3253 Versioning Extensions to WebDAV March 2002 サポートされるメソッド： - REPORT - WebDAV [RFC2518] で定義される全てのメソッド - HTTP/1.1 [RFC2616]で定義される全てのメソッド A.3 DeltaV-Compliant Collection サポートされるライブプロパティ： - 全ての DeltaV-compliant resource プロパティ サポートされるメソッド： - BASELINE-CONTROL (baseline) - 全ての DeltaV-compliant resource メソッド A.4 Versionable Resource サポートされるライブプロパティ： - DAV:workspace (workspace) - DAV:version-controlled-configuration (baseline) - 全ての DeltaV-compliant resource プロパティ サポートされるメソッド： - VERSION-CONTROL - 全ての DeltaV-compliant resource メソッド A.5 Version-Controlled Resource サポートされるライブプロパティ： - DAV:auto-version - DAV:version-history (version-history) - DAV:workspace (workspace) - DAV:version-controlled-configuration (baseline) - 全ての DeltaV-compliant resource プロパティ サポートされるメソッド： - VERSION-CONTROL - MERGE (merge) - 全ての DeltaV-compliant resource メソッド Clemm, et al. Standards Track [Page 112] RFC 3253 Versioning Extensions to WebDAV March 2002 A.6 Version サポートされるライブプロパティ： - DAV:predecessor-set - DAV:successor-set - DAV:checkout-set - DAV:version-name - DAV:checkout-fork (in-place-checkout or working resource) - DAV:checkin-fork (in-place-checkout or working resource) - DAV:version-history (version-history) - DAV:label-name-set (label) - DAV:activity-set (activity) - 全ての DeltaV-compliant resource プロパティ サポートされるメソッド： - LABEL (label) - CHECKOUT (working-resource) - 全ての DeltaV-compliant resource メソッド A.7 Checked-In Version-Controlled Resource サポートされるライブプロパティ： - DAV:checked-in - 全ての "version-controlled resource" プロパティ サポートされるメソッド： - CHECKOUT (checkout-in-place) - UPDATE (update) - 全ての "version-controlled resource" メソッド A.8 Checked-Out Resource サポートされるライブプロパティ： - DAV:checked-out - DAV:predecessor-set - DAV:checkout-fork (in-place-checkout もしくは working resource) - DAV:checkin-fork (in-place-checkout もしくは working resource) - DAV:merge-set (merge) - DAV:auto-merge-set (merge) - DAV:unreserved (activity) - DAV:activity-set (activity) Clemm, et al. Standards Track [Page 113] RFC 3253 Versioning Extensions to WebDAV March 2002 サポートされるメソッド： - CHECKIN (checkout-in-place or working-resource) - 全ての DeltaV-compliant resource メソッド A.9 Checked-Out Version-Controlled Resource (checkout-in-place) サポートされるライブプロパティ： - 全ての "version-controlled resource" プロパティ - 全ての "checked-out resource" プロパティ サポートされるメソッド： - UNCHECKOUT - 全ての "version-controlled resource" メソッド - 全ての "checked-out resource" メソッド A.10 Working Resource (working-resource) サポートされるライブプロパティ： - 全ての DeltaV-compliant resource プロパティ - 全ての "checked-out resource" プロパティ - DAV:auto-update. サポートされるメソッド： - 全ての "checked-out resource" メソッド A.11 Version History (version-history) サポートされるライブプロパティ： - DAV:version-set - DAV:root-version - 全ての DeltaV-compliant resource プロパティ サポートされるメソッド： - 全ての DeltaV-compliant resource メソッド Clemm, et al. Standards Track [Page 114] RFC 3253 Versioning Extensions to WebDAV March 2002 A.12 Workspace (workspace) サポートされるライブプロパティ： - DAV:workspace-checkout-set - DAV:baseline-controlled-collection-set (baseline) - DAV:current-activity-set (activity) - 全ての DeltaV-compliant collection プロパティ サポートされるメソッド： - 全ての DeltaV-compliant collection メソッド A.13 Activity (activity) サポートされるライブプロパティ： - DAV:activity-version-set - DAV:activity-checkout-set - DAV:subactivity-set - DAV:current-workspace-set - 全ての DeltaV-compliant resource プロパティ サポートされるメソッド： - 全ての DeltaV-compliant resource メソッド A.14 Version-Controlled Collection (version-controlled-collection) サポートされるライブプロパティ： - DAV:eclipsed-set - 全ての "version-controlled resource" プロパティ サポートされるメソッド： - 全ての "version-controlled resource" メソッド A.15 Collection Version (version-controlled-collection) サポートされるライブプロパティ： - DAV:version-controlled-binding-set - 全ての "version" プロパティ サポートされるメソッド： - 全ての "version" メソッド Clemm, et al. Standards Track [Page 115] RFC 3253 Versioning Extensions to WebDAV March 2002 A.16 Version-Controlled Configuration (baseline) サポートされるライブプロパティ： - DAV:baseline-controlled-collection - 全ての "version-controlled resource" プロパティ サポートされるメソッド： - 全ての "version-controlled resource" メソッド A.17 Baseline (baseline) サポートされるライブプロパティ： - DAV:baseline-collection - DAV:subbaseline-set - 全ての "version" プロパティ サポートされるメソッド： - 全ての "version" メソッド A.18 Checked-Out Version-Controlled Configuration (baseline) サポートされるライブプロパティ： - DAV:subbaseline-set - 全ての "version-controlled configuration" プロパティ サポートされるメソッド： - 全ての "version-controlled configuration" メソッド Clemm, et al. Standards Track [Page 116] RFC 3253 Versioning Extensions to WebDAV March 2002 Authors' Addresses Geoffrey Clemm Rational Software 20 Maguire Road, Lexington, MA 02421 EMail: geoffrey.clemm@rational.com Jim Amsden IBM 3039 Cornwallis, Research Triangle Park, NC 27709 EMail: jamsden@us.ibm.com Tim Ellison IBM Hursley Park, Winchester, UK S021 2JN EMail: tim_ellison@uk.ibm.com Christopher Kaler Microsoft One Microsoft Way, Redmond, WA 90852 EMail: ckaler@microsoft.com Jim Whitehead UC Santa Cruz, Dept. of Computer Science 1156 High Street, Santa Cruz, CA 95064 EMail: ejw@cse.ucsc.edu Clemm, et al. Standards Track [Page 117] RFC 3253 Versioning Extensions to WebDAV March 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Clemm, et al. Standards Track [Page 118]