Network Working Group J. Slein Request for Comments: 2291 Xerox Corporation Category: Informational F. Vitali University of Bologna E. Whitehead U.C. Irvine D. Durand Boston University February 1998 World Wide Web のための分散オーサリング/バージョン管理プロトコル への要求 このメモの状態 このメモは、情報をインターネット・コミュニティのために提供する。それは、いかなる種類のインターネット標準を指定しない。このメモの配布は、無制限である。 著作権 Copyright (C) The Internet Society (1998). All Rights Reserved. 概要 現在のワールドワイド・ウェブ(WWWまたはウェブ)標準は、入力されたデータの遠隔編集を許すアプリケーションのシンプルなサポートを提供する。実際問題として、既存のWWWの能力は、上書きを衝突しないで、効率的かつスケーラブルな遠隔編集をサポートするために不適当であると判明した。この文書は、インプリメントされるならば、Web 分散オーサリングとバージョン管理プロトコルの要求の形の特徴のリストとして、遠隔編集している操作の効率の改善、上書きの衝突を避けるロック機構の提供、非HTMLデータタイプの改善されたリンクメカニズム、シンプルな属性-値メタデータ機能、コンテナ・データ型の作成と読み出し、統合されたWWWバージョン管理を提供する。 1. 序論 この文書は、標準の[HTTP]既存のHTTP proposedに、拡張として組み込まれるならば、対応するウェブ・サーバーで相互操作可能な、WWW上でのリモート・ロード、編集といろいろなメディアのセーブ(パブリッシング)ツール機能を可能にすることを記述する。 可能な限り、この機能は、WWWフレームワークの範囲内で機能を実行する数多くの方法があるため、、提案されたインプリメンテーションを提案することなく記述される。また、可能な限り、一つのメカニズムが同時にいくつかの要求を満たすことは可能である。 ウェブの上でのサポート分散オーサリングとバージョン管理に標準化すべきである機能に関して、この文書は、WWW 分散オーサリング/バージョン管理専門調査委員会（WebDAV）のコンセンサスを反映する。要求のどんなセットと同様に、実際的な考慮は、全くそれらを満足させることを不可能にするかもしれない。WebDAVプロトコルの仕様を作ることにおいて、それを満足させることにできるだけ近くなることは、WebDAV専門調査委員会の意図である。 2. 正当性 現在のウェブ標準は、オペレーティング・システムを経た記憶媒体への直接のアクセスなしで、リモート・ロケーションでウェブ内容の編集を可能にする機能を含む。この機能は、既存のいくつかのHTML分散オーサリング・ツールと、ユーザーがHTTPサーバに彼らの仕事を書く(発表する)のを許す、増大する主流アプリケーション(例えばワープロ)で利用される。現在まで、HTMLオーサリング・ツールからの経験で、それらがウェブ標準の機能を使っているユーザーのニーズに応ずることができないことを示した。この結果は、後回しの、分散オーサリング機能の紹介か、追加された非標準のHTTPプロトコル拡張または他のウェブ標準である。これらの拡張は独立して開発されたが、操作は共通でない。 他のオーサリング・アプリケーションは、ウェブ・ゲートウェイによる文書リポジトリまたはバージョン・コントロールシステムへのアクセスを希望したが、同じようにうまくいかなかった。このアクセスが全て利用できる所で、非標準のHTTP拡張か他の標準を使うように、各ベンダーのサービスのために異なるインタフェースを使用するクライアントを強制する。 この文書は、分散ウェブ・オーサリング・ツールを、全ての対応するサーバーにわたって、同じ標準文法によってユーザが必要とされる機能を提供させる、HTTPへの一組の標準の拡張のために、要求を記載する。標準化される必要がある機能の大まかなカテゴリーは、以下の通りである プロパティ(Properties) リンク(Links) ロック(Locking) 確保(Reservations) 未処理のソースの検索(Retrieval of Unprocessed Source) 部分書き込み(Partial Write) 名前空間操作(Name Space Manipulation) コレクション(Collections) バージョン管理(Versioning) 異形(Variants) セキュリティ(Security) 国際化(Internationalization) 3. 用語 重複がある所は、使用法はHTTP 1.1の仕様[HTTP]と一致しているつもりである。 Client HTTP要求を発行し、レスポンスを受け取るプログラム。 Collection collectionは、直接あるいはリファレンスで他のリソースを含むリソースである。 Distributed Authoring Tool HTTP経由でソースエンティティを検索できるプログラムで、そのエンティティの編集が可能で、このエンティティをサーバにHTTPを使ってセーブ/公開できる。 Entity リクエストまたはレスポンスにおいて移動する情報 Hierarchical Collection 階層的に構成されたリソース。階層的なコレクションは、直接あるいは、リファレンスによって、コレクションを含む他のリソースを含むリソースである。 Link 少なくとも2つのリソース間のタイプの接続。 Lock リソースへのアクセスからロックの所有者以外からのアクセスを妨げるメカニズム。 Member of Version Graph バージョン・グラフの中でノードで、かつグラフにおいてそれに先行するリソースに由来して、それに続くもののベースであるリソース。 Property リソースに関する名をつけられた記述的な情報。 Reservation 人がをリソースを編集させるつもりである宣言。 Resource URIによって識別することができるネットワーク・データ・オブジェクトまたはサービス。 Server HTTPリクエストを受けて、応答するプログラム。 User Agent リクエストを始めるクライアント。 Variant リソースの表現。リソースは、任意の与えられた時間にそれと関連する一つ以上の表現を持つかもしれない。 Version Graph 各ノードがその先祖たちに由来する所の、リソース付きの指示された非周期的なグラフ。 Write Lock 適用するリソースを修正することを、所有者を除いて防止するロック。 4. 一般的な原則 このセクションは、以下で、WebDAV拡張の一般的な原則の組を記述する。これらの原則は、複数の機能のカテゴリーに渡っている。 4.1. ユーザーエージェントの相互操作性 全てのWebDAVクライアントは、任意のWebDAVに対応したHTTPサーバで働くべきである。いくつかのクライアント／サーバーの組み合わせが、普遍的に利用できない特殊な機能を提供することは受け入れられるが、プロトコルは基本的な機能レベルは十分に汎用であるべきである。 4.2. クライアント単純 WebDAV拡張は、クライアント・インプリメンテーションをシンプルにさせるようにすべきである。 4.3. レガシー・クライアント・サポート 非WebDAVクライアントでも相互操作可能な、WebDAVに対応したサーバーを実装すべきである。そのようなサーバーは、WebDAV拡張のない普通のWebクライアントからのどんな有効なHTTP 1.1の要求でも理解して、クライアントに拡張を理解することを要求しない有効なHTTP 1.1のレスポンスを提供する。 4.4. データ・フォーマット互換性 WebDAVに対応したサーバーは、既存のリソースとURI[URL]で働くべきである。特別な追加の情報は、文書フォーマットの必須の部分になるべきでない。 4.5. 写しがある分散システム 配布と複写は、インターネットの中心である。全てのWebDAV拡張は、配布と複写を考慮に入れるようにすべきである。バージョン木は、複数のサーバーに渡って分割可能であるべきである。コレクションは、異なるサーバーでメンバーを持つかもしれない。 任意のリソースは、モバイル・コンピューティングまたは他の理由のためにキャッシュされるか複写されるかもしれない。従って、WebDAV拡張は、配布された、あるいは複写された環境において働かなければならない。 4.6 クライアント-サーバー相互作用の中のParsimony WebDAV拡張は、クライアントとサーバーの間で共通の機能を実行することが必要な、相互作用の数の最低限を守るべきである。例えば、ウェブに文書を発行することは、しばしば関連したプロパティと共に内容を発行することを意味する。クライアントは、しばしば特定のリソースがどのバージョン・グラフに属しているかに見つけることを必要とするか、あるいは、バージョン・グラフの中のどのリソースが発行されたものであるか知ることを必要とするかもしれない。拡張は、効率的にこれらの作業を可能にすべきである。 4.7. HTTPへの変更 WebDAVは、たくさんの新しい種類のオブジェクトをウェブに加える：プロパティ、コレクション、バージョン・グラフ、やその他。DELETEとPUTのような既存のHTTPメソッドは、この拡張された環境においてはっきりした手段において働かなければならない。WebDAVは、明確に新しいメソッド、ヘッダとMIMEタイプだけでなく既存のHTTPメソッドとヘッダへの任意の必要な変更もアドレッシングするべきである。 4.8. 代替転送メカニズム HTTPに加えて他のメカニズム(特にEMail)で、WebDAVリクエストの転送に応答することがに望ましい。WebDAVプロトコル仕様は、将来は、実体をEMailを通して接続がない状態での操作のためにインターオペラビリティ仕様を開発することから除外するべきでない。 5. 要求 以下の要求記述において、要求は記述され、その正当性が続く。 5.1. プロパティ 5.1.1. 機能の要求 任意のメディア・タイプのリソースの任意のプロパティの作成、変更、読み込み、削除が可能でなければならない。 5.1.2. 正当性 プロパティは、任意のメディア・タイプのリソースを記述する。それは、著者、タイトル、出版社と主題、使用法への制約、参考文献の情報、PICS格づけ、その他を含む可能性がある。これらのプロパティは多くの使用法、たとえば、プロパティ値の検索、著作権の作成、電子形式で利用できない、あるいは、後で利用できるオブジェクトのためのplaceholdersとしてのカタログ・エントリの作成などを有する。 5.2. リンク 5.2.1. 機能の要求 任意のメディア・タイプのリソースの間でタイプされたリンクを作成、修正、読み出し、削除することが可能でなければならない。 5.2.2. 正当性 あるタイプのリソース間のリンクは、ハイパーテキスト・リンクであリ、それは閲覧可能なハイパーテキスト・スタイル・ポイント＆クリックのユーザ・インタフェースを使う。リンクは、閲覧可能なハイパーテキスト・リンクまたはリソース間の関係をキャプチャすることを単に意味し、多くの目的を持っている。リンクは、定められた順序で多くのリソース文書の印刷、リソースのためにアクセス制御ページへのジャンプ、そして、目次、インデックス、用語集、文献目録の記録、ヘルプ・ページ、その他のような、速く、関連した情報を閲覧しているプッシュボタンをサポートすることができる。リンク・サポートがHTMLの「LINK」要素によって提供される間、これはHTMLリソース[HTML]だけに限られる。類似したサポートは、ビットマップ・イメージ・タイプと他の非HTMLメディア・タイプのために必要とされる。 5.3. ロック 5.3.1. 一般的な原則 5.3.1.1. ロックの独立 リソースに対する追加の検索を実行することなく、かつ、編集中のリソースへのコミットなしにリソースをロックすることが可能でなければならない。 5.3.1.2. マルチ・リソースロック 同じサーバー内にある複数のリソースを単一操作で外すことと、このロック操作がリソースに渡って原子的であることが可能でなければならない。 5.3.2. 機能の要求 5.3.2.1. ライトロック 特定の人にリソースの修正を制限することが可能でなければならない。 5.3.2.2. ロック問い合わせ 与えられたリソースが、任意のアクティブなロックを持っているかどうか見つけられなければならず、もしそうならば、そのロックを保持することが可能でなければならない。 5.3.2.3. アンロック ロックを削除することが可能でなければならない。 5.3.3. 正当性 今のところ、Webは、与えられたURIに、2人以上がセーブする時、お互いの変更の上書きを防止するための限られたサポートを提供する。さらに、他の誰かがリソースに現在修正をしているかことをどうか発見する手段はない。これは、「失われたアップデート問題」または「上書き問題」として知られている。失われた変更を発見して、修理することに関連する重大なコストがありえるので、この問題を防ぐことは、分散オーサリングをサポートするために重大である。書き込みロックは1人の人だけがリソースを修正できることを確実にし、上書きを防止する。さらに、ロックのサポートは、多くのバージョン管理スキーム(分散されたオーサリングのための望ましい機能)の重要な構成要素である。 たとえ、他のリソースが変更されないようにするために、たった一つのリソースを編集しているとしても、著者は全てのウェブのリソースをロックしたいかもしれない。このように、著者はローカル・ハイパーテキスト・ウェブが彼の分散オーサリング・ツールと一貫しているならば、彼がサーバーにそれを書くとき、それが一貫していることを確実にすることができる。この理由により、リソースの内容の転送を引き起こすことなくロックを確保することは可能であるべきである。 しばしば、ロック、アンロック操作が複数のリソース間で同時に引き起こることを許可することは必要であリ、複数のリソースロック要求をサポートすることに必要となる。これは、ロックしているマルチ・リソースで2人の人々のうちの1人がロックを得るので、リソースの同じセットに関してロックを確立しようとしている2人の間の衝突を防ぐことに役立つ。この同じ複数のリソースロックシナリオが、リソース渡って繰り返し原子的なロック操作を使うならば、リソース順序と競争状況に基づく二人の間のロックを分割する結果になる。 5.4. 予約 5.4.1. 機能の要求 5.4.1.1. 保存 他の誰がリソースを編集するつもりかについて発見できるように、与えられたリソースを編集する意志をサーバに登録できることが可能でなければならない。 5.4.1.2. 予約問い合わせ 与えられたリソースが任意のアクティブな予約を持っているかどうかを見つけることが可能でなければならず、そうならば、だれが現在予約を保っているかが見つけられなければならない。 5.4.1.3. 予約解放 予約を解放することが可能でなければならない。 5.4.2. 正当性 コンフィギュレーション・マネージメント・システムからの経験は、人々がいつパラレルの編集状態をに入ったか知る必要があることを示した。一旦通知されると、他の著者とパラレル編集しないことに決めたり、あるいは、結果をマージすることの難しさを最小にするために、編集をコーディネートするためにバンド外のコミュニケーション(対面、電話、その他)を使う。予約は、ロックと別であり、書き込みロックが必ずしも必要とするというわけではしなく、そして、予約はそれとともに任意のアクセス制限を伝搬しない。この機能は、チェックアウトが一般的に書き込みロックを外すことを含むので、予約の作成と、編集されるリソースを得ることとバージョン管理をサポートする。 5.5. 編集対象の未処理のソースの検索 5.5.1. 機能の要求 任意の与えられたリソースのソースは、任意の主体がリソースを編集するために、認証付きで検索可能でなければならない。 5.5.2. 正当性 サーバーに保存されているソースがHTTP GETに答えて送られる実際のエンティティに、対応しない多くのケースが存在する。現在の既知のケースは、SSIディレクティブと、動的にハイパーテキスト・マークアップ・ランゲージ（HTML）[HTML]出力エンティティに変換されるStandard Generalized Markup Language(SGML)ソースである。多くの可能なケース、例えば異なるいくつかのビットマップ・メディア・タイプ(例えばGIF、JPEG)へのビットマップ・イメージの自動転換とHTMLへのアプリケーションのネイティブ・メディア・タイプの自動転換がある。この最後のケースの例として、ワープロは、そのネイティブ・メディア・タイプを自動的にそれをHTMLに変換するサーバーに保存することができた。このリソースのGETは、HTMLを検索しようとする。ソースを検索することは、ワープロ・ネイティブ・フォーマットを検索しようとする。 5.6. 部分書き込み 5.6.1. 機能の要求 リソースを編集した後に、全リソースを再送信することなくリソースの変化だけを書くことが可能でなければならない。 5.6.2. 正当性 地理的に広く分離しているところでの分散編集を通じてか、または、低いバンド幅での接続において、マイナーな変化(例えば1キャラクタの綴り修正)の後、大きいリソースを書き直すことは、とても能率が悪くていらいらさせる。"insert"(例えば、文書の中央にこの文を加える)、"delete"(例えば文書の中間からこのパラグラフを削除する)スタイルの更新の転送にサポートが必要とされる。部分的なリソース・アップデートのサポートは、小規模の編集をより効率化し、分散オーサリング・ツールを大きい文書を編集するために拡大させる。 5.7. 名前スペース操作 5.7.1. コピー 5.7.1.1. 機能の要求 クライアント・ロードなしでリソースを複製することは可能でなければならず、そしてリソースを再セーブできねばならない。コピー操作の後、どちらのリソースへの修正は、もう一方に修正を引き起こしてはならない。 5.7.1.2. 正当性 リソースが複製ねばならないかの多くの理由があリ、それは、例えば所有権を変えるとか、大きな修正に備えるとか、バックアップをする場合などである。リソースをロードして、セーブすることと関連するネットワーク・コストのために、サーバーが、リソースのコピーを実行することは、クライアントが行なうことよりもはるかに好ましい。 5.7.2. 移動/名前の変更 5.7.2.1. 機能の要求 クライアント・ロードなしでリソースのロケーションを変えることは可能でなければならず、その後、異なる名前でリソースを再セーブできねばならない。移動操作の後、その本来のロケーションでリソースにアクセスすることが可能であってはならない。 5.7.2.2. 正当性 例えば新しい命名規則の採用や、あるいは、元々入力した名前のタイプエラーなどで、名前の変更はしばしば必要である。ネットワーク・コストのために、ロード後古いリソースの削除を伴ってリソースを再セーブすることよってこの操作を実行することは望ましくない。同じように、単一の名前変更操作は、削除操作を伴うコピーより効率的である。リソースを移動することはリソースの名前を変えることと同じ機能とみなされる点に注意しなさい。 5.8. コレクション コレクションは、他のコレクションを含む他のリソースのためのコンテナであるリソースである。リソースは、参照か直接かのどちらかのコレクションに属していてもよい。リソースが直接コレクションに属しているならば、コレクションにも適用されるコピー、移動とデリートのような名前空間操作はリソースにあてはまる。リソースが参照によってコレクションに属しているならば、コレクションに適用される名前空間操作は参照(リソースでない)だけに影響を及ぼす。 5.8.1. 機能の要求 5.8.1.1. コレクションのリスト 特定のコレクションの中の全てのリソースのリストは、アクセスできなければならない。 5.8.1.2. コレクションの作成 新しいコレクションを作成することが可能でなければならない。 5.8.1.3. コレクションへの追加 コレクションに直接または参照によってリソースを加えることが可能でなければならない。 5.8.1.4. コレクションからの移動 コレクションからリソースを取り外すことが可能でなければならない。 5.8.2. 正当性 [URL]中で、"若干のURLスキーム(例えばftp、httpとファイル・スキーム)は、階層的であるとみなされることができる名前を含む"ことを指定している。特にHTTPサーバに、URL名前空間の全部または一部をマップするために、特定の階層レベルにある全てのリソースのリストを得ることは、非常に役に立つ。この機能は「新規保存...」ダイアログボックスをサポートし、現在の階層レベルのエンティティのリストを提供して、階層構造を通してのナビゲーションを提供する。さらに、階層構造レベルでのエンティティまたはレベルのセットの中で、ハイパーテキスト構造のグラフィック視覚化(一般的にネットワークとして)の作成をサポートする。さらに、エンティティとの階層構造レベルの木構造での視覚化をサポートする。 それに加えて、文書管理システムは、文書をウェブを通してアクセスできるようにすることを望んでもよい。それは、一般的にコレクションへの文書の組織を認め、かつ、ユーザーがWebを通してコレクションの階層構造を見ることを可能にすることを望んでもよい。 URL階層構造レベルとコレクションの概念間の強い相互関係がない所で、多くのインスタンスがある。1つの例は、URL階層構造レベルを、いくつかの名前解決を実行する計算のプロセスにマップするサーバーである。この場合、URL階層構造レベルの内容は計算への入力によって変化することができ、計算を通してアクセスできるリソースの数は非常に大きくありえる。そのような名前空間のためにディレクトリ機能をインプリメントすることは、意味をなさない。しかし、全てのケースにおいて意味があるというわけではないことにもかかわらず、例えば名前空間をファイルシステムにマップするたくさんの数のHTTPサーバのような、コレクション関連させるURL階層構造レベルの内容をリストするユーティリティは、この機能の包含に賛成する。URL階層構造レベルの内容をリストすることが特定のURLのために意味をなさないならば、"405 Method Not Allowed"状態コードを出すことができる。 関連したリソースを保持するためにコレクションを作成する能力は、小規模の、関連したクラスタにそのメンバーをパッケージすることによって名前空間の管理をサポートする。この機能のユーティリティは、最近のオペレーティング・システムにおいて、ディレクトリの大まかなインプリメンテーションによって示される。コレクションも作成する能力は、「新しいLevel/フォルダ/Directory」機能を伴う「新規保存...」ダイアログボックスの作成を、共通の多くのアプリケーションにサポートする。 5.9. バージョン管理 5.9.1. 背景と一般的な原則 5.9.1.1. バージョンの安定性 大部分のバージョン管理システムは、文書の発展のヒストリの正確な記録を提供させるつもりである。この精度は、バージョンが最終的には「凍結し」、不変になるという事実によって確実にされる。一旦バージョンが凍結されるならば、更なる変化はオリジナルを修正することよりむしろ新しいバージョンを作成する。キャッシュすることと絶え間ない参照が正しく維持されるために、クライアントはバージョンが凍結したと決定できなければならない。リソースの凍結されたバージョンを検索する任意の成功した試みは常に正確に同じ内容を検索し、そのバージョン(またはリソース)がもはや利用できないならば、エラーを返す。 5.9.1.2. 新しいバージョンを作成するための操作 バージョン管理システムは、それが要求する操作、操作の順序とそれが原子的な機能に結合される方法において大いに変化する。最も完全なケースに含まれる論理演算は以下のとおりである。 o 既存のバージョンの予約 o 既存のバージョンのロック o 既存のバージョンの検索 o 新しいバージョンのための識別子の要求または示唆 o 新しいバージョンの書き込み o ロックの解放 o 予約の解放 新しいバージョン識別子を要求することを除いて、すべての操作は、バージョン管理の外でアプリケーションを持つか、HTTPの部分にすでになっているか、あるいは、これらの要求に付いて、以前のセクションで論議されている。一般的に、バージョン管理システムは、ロック、予約、そして、検索と - またはこれらの若干のサブセットと - 原子的なチェックアウト機能で結合する。それは、原子的なチェックイン機能へ、書き込み、ロックの解放、予約の解放 - またはこれらの若干のサブセット - を結合する。新しいバージョン識別子は、チェックアウトあるいはチェックインで割り当てられてもよい。 WebDAV拡張は、バージョン管理サーバーがこれらの操作に関して望むどんなポリシーでも採用することを認めることと、クライアント・インプリメンテーションをシンプルにしておくのに十分な一様性を実施することの間の若干のバランスを見いださなければならない。 5.9.1.3. バージョン管理モデル 各バージョンは、一般的にその先祖たちとの「由来された」関係に立っている。単一のバージョン(ブランチ)と、異なるいくつかのバージョンを引き出して、いくつかのバージョン(マージ)から、単一のバージョンを引き出すことは、可能である。従って、関連したバージョンのコレクションは、指示された非周期的なグラフを作り上げる。以下の議論において、このグラフは、「バージョン・グラフ」と呼ばれている。このグラフの各ノードは、「バージョン」または「バージョン・グラフのメンバー」である。グラフの弧は、「由来された」関係を捕らえる。 単一のリソースが複数のバージョン・グラフに参加することは、また、可能である。 特定のサーバーがいろいろな手段においてそれを制限してもよいけれども、WebDAV拡張は、このバージョン管理モデルをサポートするべきである。 5.9.1.4. バージョン管理ポリシー Feiler [CM]とHaakeとHicks [VSE]を含む、多くの著者は、バージョン管理システムが実行する異なるポリシーについて考えるために、1つの手段としてバージョン管理スタイル(クライアント/サーバー相互作用の性質を反映するために、バージョン管理ポリシーとしてここに言及した)の概念を論議した。バージョン管理ポリシーは、履歴の形の決定(リニアであるか分岐か)、変化履歴の単位、サーバーでのロック要求、その他を含む。プロトコルは、それが指図するポリシーを、バージョニング・システム・インプリメンタの残っているのか、管理者に残っているのかを明らかに識別するべきである。 5.9.1.5. 任意のメディアのリソースタイプにバージョン管理は可能である。 5.9.2. 機能の要求 5.9.2.1. バージョン・グラフを参照すること。 全体としてバージョン・グラフを参照する手段がなければならない。 いくつかの問い合わせと操作が、バージョン・グラフの任意の1人のメンバーにでなく、バージョン・グラフにとって全体として適用できる。たとえば、全てのグラフの移動やバージョンの履歴をクライアントが要求してもよい。このケースは、全部のバージョン・グラフへの参照が要求される。 5.9.2.2. バージョン・グラフの特定のメンバーを参照すること バージョン・グラフの各々のメンバーを参照する手段がなければならない。これは、グラフの各々のメンバーがそれ自身でリソースであることを意味する。 ページの特定のバージョンを参照するハイパーテキスト・リンクのために、また、クライアントが文書の特定のバージョンを要求することが可能であるために、バージョン・グラフの各々のメンバーはリソースでなければならない。 5.9.2.3. クライアントは、リソースがバージョン・グラフであるかどうか、あるいは、リソースがそれ自身でバージョン・グラフのメンバーであるかどうか決定しえなければならない。 リソースはシンプルな、バージョン管理されていないリソースであっても、あるいは、バージョン・グラフであっても、あるいは、バージョン・グラフのメンバーであってもよい。クライアントは、それがどの種類のリソースにアクセスしているかについてわかる必要がある。 5.9.2.4. バージョン・グラフのサーバで定義された既定値のメンバーを参照する手段がなければならない。 サーバーは、既定値のバージョンを尋ねる要求に、特定のバージョン情報がない要求と同じように、リソースの既定値のバージョンを返すべきである。これは、非バージョン管理クライアントとの互換性を保証する最もシンプルな手段のうちの1つである。賢明な既定値が存在しないとき、エラーを返しているサーバーの可能性を除外しない。 バージョン・グラフのもう一方特別なメンバーを参照しうることは、また、望ましくてもよい。例えば、既定値のバージョンから異なる、編集のための現在のバージョンがあってもよい。いくつかの枝を持つグラフのために、任意の枝のチップ・バージョンを要求しうることは、役に立つ。 5.9.2.5. そのリソースがどのバージョングラフに属しているか見つけるために、バージョン・グラフのメンバーの参照を与えられることが可能でなければならない。 これは、リソースのバージョニング前後関係を理解することを可能にする。それは、今までのグラフの履歴の検索と、バージョン・グラフを閲覧することを可能にする。また、いくらかの比較操作をサポートする。それは、2つの参照が同じバージョン・グラフのメンバーを指定するかどうかについて決定することを可能にする。 5.9.2.6. バージョン・グラフのナビゲーション バージョン・グラフのメンバーの参照を与えられた場合、バージョン・グラフの関連しているメンバを探し、アクセスするのが可能でなければならない。 oグラフのルートメンバー o先祖メンバー o後継者メンバー oグラフの既定値メンバー バージョン管理クライアントが、現在調べられているリソースと関係するアクセス・バージョンに、若干の手段でアクセス可能でなければならない。 5.9.2.7. バージョン・トポロジー バージョン・グラフの全てのメンバーに関する情報を含むバージョン・グラフのために、完全なバージョン・トポロジーを検索する手段がなければならない。基本的情報が全てのクライアントによって使われることができるように、この情報のためのフォーマットは標準化されなければならない。標準のトポロジーに入れられることができない情報を要求するサーバーとクライアントのために、もう一方の特殊フォーマットは適応するべきである。 5.9.2.8. クライアントは、バージョン・グラフの新しいメンバーのために使われるバージョン識別子を提案しえなければならない。サーバーは、クライアントの提案されたバージョン識別子を使うことを拒否してもよい。サーバーは、それが持っているバージョン識別子が何をバージョン・グラフの新しいメンバーに割り当てたかについて、クライアントに示すべきである。 5.9.2.9. バージョン識別子は、バージョン・グラフ全体にわたって一意でなければならない。 5.9.2.10. クライアントは、バージョン・グラフの新しいメンバーと、関連するバージョン固有のプロパティを供給しえなければならない(前述の第5.1節「プロパティ」を参照)。最低限、コメントを新しいメンバーと関連することと、どんな変化がなされたかについて説明することが可能でなければならない。 5.9.2.11. クライアントは、どのバージョンがロックさたるか、編集のために予約されているか、誰によってか(セッション追跡)を含む、バージョン木に関しての情報をサーバーについて問い合わせできなければならない。 5.9.3. 正当性 ワールドワイド・ウェブのコンテキストでのバージョニングは、いろいろな利益を提供する： それは、大規模に展開しているウェブ・サイトの効率的で制御された管理のための基盤を提供する。現代の構成管理システムは、個々のリソースの改訂ヒストリを追跡することができ、それらのセーブされたバージョンを管理するための高水準ツールを提供することができる、いくつかの形式のリポジトリの上で構築される。基本的なバージョン管理機能は、そのようなシステムをサポートするために要求される。 それは、単一のリソースの並列の開発とアップデートを認める。バージョニング・システムが新しいオブジェクトの作成で変更を登録するので、異なるバージョンの作成を認めることによって同時に起こる書き込みアクセスを可能にする。多くは逆の操作を容易にするマージ機能を提供する。 それは、リソースの変化をコーディネートすることに対するフレームワークを提供する。変更を指定する間、大部分のシステムは協力的なリソース開発を可能にするために制御するか、アクセスを追跡する若干のメソッドを提供する。 それは、リソースの過去かつ代替バージョンを通して閲覧することを認める。しばしば、リソースの変更と出所ヒストリは、本来重大な情報である。 それは、注釈とリンク-サーバー支持のために外部に保存されたリンクをサポートすることができる安定した名前を提供する。注釈とリンク・サーバーは、しばしば直接の制御の下にないリソースの部分の安定した参照を保存する必要がある。リソースの安定した状態を提供することによって、バージョン・コントロールシステムは、リソースのそれらの状態の関係を決定するためにそれらのリソースへの安定したポインターだけでなくはっきりしたメソッドも認める。 それは、複数の状態で単一のリソースの明確な意味の表現を認める。バージョン管理システムは、直接にリソースが明確なヒストリを持っていて、それが持っているいろいろな状態を渡った絶え間ない独自性がそのヒストリのコースの間、持っていた事実を表す。 5.10. Variant リソースの表現(Variant)の詳細な要求は、別々の文書において開発される。 5.10.1. 機能の要求 サーバーにVariantを送ることとVariantと親リソースの関係を記述することは可能でなければならない。それに加えて、プロパティ・ラベルのVariant、プロパティ記述、そして、プロパティの価を書いて、検索することは可能でなければならない。 5.10.2. 正当性 HTTPワーキンググループは、コンテント・ネゴシエーションの問題とリソースのVariantの検索をアドレッシングしている。この仕事をオーサリング環境に拡張するために、Variantをサーバーに提出するとき使うために、WEBDAVは著者のためにメカニズムを標準化しなければならない。著者は、異なる使用法のためには異なるファイルまたは文書フォーマットにおいてVariantを提供しうる必要がある。それは、異なるクライアントのために、そして、異なる出力装置のために最適化されるVariantを提供する必要がある。それは、ウェブの国際化環境において、異なる言語でVariantを提供しうる必要がある。国際化要求(以下の5.12を参照)をサポートするため、variantがリソースの内容だけでなく、人間向けの用途(例えばプロパティの価、ラベルと記述)のための任意の情報のためにサポートされる必要がある。 5.11. セキュリティ 5.11.1. 認証 WebDAV仕様は、WebDAV拡張がどのように既存の認証スキームで相互操作し、それらのスキームを使うことに推薦を作るべきかについて告示するべきである。 5.11.2. アクセス制御 アクセス制御要求は、別々の[AC]で示されるアクセス制御の仕組みで指定される。 5.11.3. セキュリティ・プロトコルとのインターオペラビリティ WebDAV仕様は、任意の対応するサーバー/クライアントがサポートしなければならないセキュリティ・プロトコルの最小のリストを提供しなければならない。これらのプロトコルは、通過中にメッセージとプライバシーの確実性とメッセージの完全性を保証するべきである。 5.12. 国際化 5.12.1. 文字セットと言語 Web分散オーサリングがマルチ言語環境で使われるので、ユーザーが理解をするためのIETF Character Set Policy [CHAR]に従う情報が必要である。このポリシーは、文字セットと符号化と言語タグをアドレッシングする。 5.12.2. 正当性 インターネットの国際的な環境では、ライティングシステムで表示可能な、ユーザが理解できる情報と、クライアントとサーバーに認められる言語の情報を保証することはとても重要である。この要求に取り囲まれている情報は、リソースの内容だけでなくディスプレイ名前とプロパティの記述、プロパティの価と状態メッセージの記述のようなものも含む。 6. Acknowledgement 我々の、これらの問題の理解は、多くの人々による深い議論、電子メールと援助の結果として出てきた。そして、その人は彼らの努力のために承認に値する。 Terry Allen, tallen@sonic.net Alan Babich, FileNet, babich@filenet.com Dylan Barrell, Open Text, dbarrell@opentext.ch Barbara Bazemore, PC DOCS, barbarab@pcdocs.com Martin Cagan, Continuus Software, Marty_Cagan@continuus.com Steve Carter, Novell, srcarter@novell.com Dan Connolly, World Wide Web Consortium, connolly@w3.org Jim Cunningham, Netscape, jfc@netscape.com Ron Daniel Jr., Los Alamos National Laboratory, rdaniel@lanl.gov Mark Day, Lotus, Mark_Day@lotus.com Martin J. Duerst, mduerst@ifi.unizh.ch Asad Faizi, Netscape, asad@netscape.com Ron Fein, Microsoft, ronfe@microsoft.com David Fiander, Mortice Kern Systems, davidf@mks.com Roy Fielding, U.C. Irvine, fielding@ics.uci.edu Mark Fisher, Thomson Consumer Electronics, FisherM@indy.tce.com Yaron Y. Goland, Microsoft, yarong@microsoft.com Phill Hallam-Baker, MIT, hallam@ai.mit.edu Dennis Hamilton, Xerox PARC, hamilton@parc.xerox.com Andre van der Hoek, University of Colorado, Boulder, andre@cs.colorado.edu Del Jensen, Novell, dcjensen@novell.com Gail Kaiser, Columbia University, kaiser@cs.columbia.edu Rohit Khare, World Wide Web Consortium, khare@w3.org Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.com Ben Laurie, A.L. Digital, ben@algroup.co.uk Mike Little, Bellcore, little@bellcore.com Dave Long, America Online, dave@sb.aol.com Larry Masinter, Xerox PARC, masinter@parc.xerox.com Murray Maloney, SoftQuad, murray@sq.com Jim Miller, World Wide Web Consortium, jmiller@w3.org Howard S. Modell, Boeing, howard.s.modell@boeing.com Keith Moore, University of Tennessee, Knoxville, moore@cs.utk.edu Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org Jon Radoff, NovaLink, jradoff@novalink.com Alan Robertson, alanr@bell-labs.com Henry Sanders, Microsoft, Andrew Schulert, Microsoft, andyschu@microsoft.com Christopher Seiwald, Perforce Software, seiwald@perforce.com Einar Stefferud, stef@nma.com Richard Taylor, U.C. Irvine, taylor@ics.uci.edu Robert Thau, MIT, rst@ai.mit.edu Sankar Virdhagriswaran, sv@hunchuen.crystaliz.com Dan Whelan, FileNet, dan@FILENET.COM Gregory J. Woodhouse, gjw@wnetc.com 7. 参照 [AC] J. Radoff, "Requirements for Access Control within Distributed Authoring and Versioning Environments on the World Wide Web", unpublished manuscript, [CHAR] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, January 1998. [CM] P. Feiler, "Configuration Management Models in Commercial Environments", Software Engineering Institute Technical Report CMU/SEI-91-TR-7, [HTML] Berners-Lee, T., and D. Connolly, "HyperText Markup Language Specification - 2.0", RFC 1866, November 1995. [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [ISO 10646] ISO/IEC 10646-1:1993. "International Standard -- Information Technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane." [URL] Berners-Lee, T., Masinter, L., and M. McCahill. "Uniform Resource Locators (URL)", RFC 1738, December 1994. [VSE] A. Haake, D. Hicks, "VerSE: Towards Hypertext Versioning Styles", Proc. Hypertext'96, The Seventh ACM Conference on Hypertext, 1996, pages 224-234. 8. 著者のアドレス Judith Slein Xerox Corporation 800 Phillips Road 128-29E Webster, NY 14580 EMail: slein@wrc.xerox.com Fabio Vitali Department of Computer Science University of Bologna ITALY EMail: fabio@cs.unibo.it E. James Whitehead, Jr. Department of Information and Computer Science University of California Irvine, CA 92697-3425 Fax: 714-824-4056 EMail: ejw@ics.uci.edu David G. Durand Department of Computer Science Boston University Boston, MA EMail: dgd@cs.bu.edu 9. 完全な著作権声明 Copyright (C) The Internet Society (1998). 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.