DAV Frequently Asked Questions

あー、私は、これは誰に対して話をするかによると思います。 オフィシャルにはWebDAVですが、私はより短く"DAV"と表記するのが好きです。 これは、私がMSで働いていたときに使ってた造語なのかもしれませんが。 MSでは、DAVという言葉は WebDAV よりも排他的に使われてました。

（憲章によると）WebDAVワーキンググループの掲げている目標は、「ユーザが必要とする限りにおいて、分散Web制作ツールが広い相互接続性を獲得するのに必要なHTTPの拡張を定義すること」です。 この点において、DAV は Webを書き込みや協調作業が可能なメディアとして補完します。

しかし、DAVに従事する人は、WebページのオーサリングにDAVを供する以上の目標を持っています。ある人はDAVはインターネットにおいてネットワークファイルシステムを実現するのに適していると見ていますし、またある人は、ネットワークの遅延が大きい環境においてよいパフォーマンスで全てのファイルを一度に扱えると見ています。またある人は、DAVをWeb経由のドキュメント管理システムにおいてコンテンツを操作するためのものと見ています。DAVの重要な目標は、バーチャルなエンタプライズをサポートし、広い範囲でのコラボレーション向けアプリケーションのためのプライマリなプロトコルにすることです。 重要なことに、メジャーなゴールは分散したソフトウェア開発チームのサポートです。DAVの最終的な目標は、HTTPを広範囲なストレージリポジトリのためのアクセスレイヤの標準（手段）とすることです。HTTPは読み取りアクセス機能を提供しますが、その一方でDAVは書き込みアクセスを提供します。

これら全ての目標は、それぞれが補完的な意味を持ちます。そしてそれは全て同じネットワークプロトコルの上で実現されます。

WebDAVは相互接続性を持った協調作業アプリケーションのためのプロトコルを提供します。このプロトコルの大きな特徴は、以下のようなものです。

• ロック（コンカレンシーコントロール）:長期間にわたる排他的な共有書き込みロックは上書きの問題を回避します。例えば、2人以上の協調作業者が、その前の変更を反映しない状態で同じリソースに書き込むような自体を回避します。ネットワーク接続が任意に分離されるかもしれず、かつスケーラビリティについてそれぞれのコネクション開設時にサーバ資源を消費するような状況において、ロバストなインターネット規模の協調作業を行うために、DAVロックの継続はネットワークコネクションに依存しません。
• プロパティ: XMLプロパティは、例えばとあるWebリソースについての編集者リストのような任意のメタデータを保持するために使用される。これらのプロパティは、DAVプロトコルを使用することで、効率的に設定／削除／取得することが可能です。DASL(DAV Searching and Locating)プロトコルは、Webリソースのありかを特定するために、プロパティの値に基づいた検索機能を提供します。
• 名前空間の操作: リソースは、Webサイトの改良／改善のために、リソースはコピーもしくは異動されることがあるので、DAVはコピーおよび異動の操作をサポートします。ファイルシステムにおけるディレクトリと似ていますが、コレクションが作成／リストされます。

機能についての更なる詳細は、WebDAV:IETF Standard for Collaborative Authoring on the Webを参照してください。これは、1998年9/10月ににIEEE Internet Computing に出ています。

HTTP Extensions for Distributed Authoring -- WEBDAV(text)が、RFC2518としてIETFからリリースされています。これがベースとなるDAVプロトコルです。その中には、以下のようなことが記述されています。

• ロック
• プロパティ
• 名前空間の管理

最終的に、これらの機能は完全です。そして安定していることを期待しています。

ベースとなるDAVプロトコルのうちいくつかのいくつかの拡張については、現在IETFにて開発中です。それらは以下の通り。

• 高機能なコレクション: この機能は、要求のあったコレクションに対し、コレクション内の（複数の）URLに対する単一の持続した要求を維持するための機能を提供します。これは、指定されたリソースについても適用されます。ファイルシステム上において、シンボリックリンクのように機能するリソースに対するクライアントアクセスを、他の（指示された）リソースに対するアクセスとしてリダイレクトします。この機能は2000年の中盤には完成することを期待しています。
• バージョン管理とコンフィグレーション管理: バージョン管理のサポートは、RCSやSCCSが提供する機能と似ていますが、機能性のエントリレベルを提供します。バージョン管理のレベルは、例えばcheck-outやcheck-inのような操作をサポートし、履歴一覧を取得します。とあるリソースの前のバージョンを直接取得する機能（前のリビジョンへの直接のリンクを許可する）も、サポートされる予定です。バージョン管理を行う層の上に構築されるものは、コンフィグレーションを管理する層であり、これはワークスペースとコンフィグレーションのサポートを提供します。そして、これは作業対象であるバージョン管理対象のリソースを格納するコレクションをさらにバージョン管理することを許可しています。どちらのレイヤも、並行した開発をサポートします。この作業は、IETF DELTA-V working groupにて実施されており、2000年の後半には完成することを期待しています。
• アクセスコントロール: アクセスコントロールリストを設定したりクリアしたりするための機能です。この機能は、協調作業を実施する人の間で単一のリソースを扱うにあたり、作業者リストから操作できる人を追加したり取り除いたりすることをリモートでできるようにするということを考えると重要なものです。最も一般的なレベルでは、この作業はDAVのためのアクセスコントロールというだけではなく、全てのWebアクセスのためのものになります。

DAVはプロトコルです。もう少し述べるならば、これはHTTP/1.1プロトコルの拡張になります。DAV は HTTP に対して新しいメソッドとヘッダを追加します。加えて、DAV は新しい拡張を使用する方法、リクエストおよびレスポンスボディの形式、既存のHTTPの動作がどのように変わるか、などについて規定します。

一般的には、APIはプログラマがその機能をどのように使うかという部分に関連してきます。プロトコルは、クライアントとサーバを繋ぐ「通信路」の上での挙動を規定します。基本的にAPIは、クライアントおよびサーバが共同で作業することができるように、それらはデータ形式およびアルゴリズムを指定します。

規格を採択するにあたり、プロトコルはAPIよりもやりやすいです。というのも、APIは組み込まれた制御とアーキテクチャについて、常にあらゆる利用ケースにおいて使用に適さないという仮定の元、採択に達するものだからです。よく定義されたプロトコルがあると、多くの異なる言語におけるAPIは、そのプロトコルがよく見える形で記述可能です。これは HTTP についていえることであり、このような形で記述された HTTP の API が現在多く存在しています。さらに、プロトコルがよく定義された文法やセマンティクスを持っている場合、APIを開発する作業は通常面倒にはなりません。WebDAV向けのAPIは、すでにいくつかが開発されており、それらの開発の上で特に問題となる個所(gotchas)はありませんでした。

最も新しいドラフトは、常にDeltaV Working Group pagesで見つけられます。これを書いている時点で、適切なドラフトは以下のとおりです。

バージョン管理とコンフィグレーション管理プロトコルの目標は、以下のURLにて見れます。

http://www.webdav.org/deltav/goals/draft-ietf-webdav-version-goals-01.txt

バージョン管理とコンフィグレーション管理の概要について、UML形式のモデルが以下のURLにて見れます。

http://www.webdav.org/deltav/model/model990209/

最新のプロトコルドラフトは、以下のURLで見れます。

http://www.webdav.org/deltav/protocol/draft-ietf-deltav-versioning-10.htm

以下のURLで処理の流れが見れます。

http://www.webdav.org/deltav/scenarios/scenarios-00-1.htm

Webサイトは、典型的には遠隔地で作業する人々から、さまざまな出所の情報を集めます。DAVサーバを用いて、Webページに含まれるHTMLページや画像、そしてその他の情報を直接編集することが可能になります。また、公開プロセスを採用しているWebサイトでも、情報が公開承認のプロセスに最初に入力される場合のことを考えると、DAVは大きな長所を持っています。DAVはさらに、承認ワークフローに沿ってサーバーからサーバーへとページのデータを移すツールによって使用することもできます。

物理的に分散したソフトウェア開発チームを支援するキーチャレンジの1つは、ソフトウェアをインターネット経由で遠隔アクセス可能にすることです。DAVは、これらを実施するための標準的なインフラを提供します。というのも、例えばソースコードや設計書など、ソフトウエアの開発成果物などは、リモートの協調制作に適しており、DAVは仮想的な開発チームをサポートするのに利用可能だからです。DAVは現時点ですでにリモートのソフトウェア開発をサポートするだけの機能は持ってはいますが、バージョン管理プロトコルが完成した時、DAVはソフトウェア開発用の重要な共同作業技術としてバージョン管理およびコンフィグレーション管理について利用されるようになるでしょう。

もちろん。ひとたびDAVを用いてWeb上の場所をドキュメント編集可能としたら、分断されたローカルディスク上のデータや、ローカルのイントラネット上のデータはなくなっていくでしょう。というのも、Webアクセス可能な場所で（一元的に格納された）データの価値が、個々のディスクにおかれたそれよりも利用価値が高いからです。このことは、業務上の試行から、ローカルのイントラネット周辺を整理するためのインセンティブを与えます。DAVを使用して、ますます多くのドキュメントが編集されるとともに、共同作業のにかかる経費は劇的に縮小されます。もしあなたがDAVを用いて一人でドキュメントを作成しはじめた場合、他の作業者を追加するのは容易です。ドキュメントへのアクセスを許可するようドキュメントの権限を変更を要求します。それから、ドキュメントのURLを追加した作業者に対してメールや電話で通知します。組織内もしくは組織を超えた協調作業は、DAVを用いることで劇的に単純化されます。

そんなことはありません。DAVはHTTPベースであり、8ビットクリーンなプロトコルです。DAVは、あらゆるメディアタイプのWebリソースについて制作をサポートします。例えば HTML , GIF, JPEG, その他いろんなフォーマットのデータが扱えます。バージョン管理の拡張もまた、テキストベースでないあらゆるメディアタイプのデータを扱えることが目標です。

このことを目指した結果、diff と merge の操作は現在プロトコルの一部としては規定されていません。これら（の実装）については、メディアタイプについての責任があるクライアントプログラム側での実装になります。

いいえ。DAVはベースのプロトコルです。DAVは、拡張プロパティを備えたリモートファイルシステムであると思ってください。ドキュメント管理システムはその上位に実装されるものです。ドキュメント管理はアプリケーションであり、DAVはプロトコルです。

さて、DAVのACL、検索、バージョン管理が完成した際にはこれはいえるでしょう。これらのシステムのいずれかを作成するために、誰かが基本機能を提供するでしょう。

はい、とってもオープンです。DAVはIETFが提唱した標準（RFC2518）です。このことは、DAVは完全にオープンに公開された標準であることを意味します。IETFのプロセスもまた、標準の開発のためにオープンで透過的なプロセスであることを保証しようとしています。誰もが議論用のメイリングリストに参加することが出来ます。（WebDAVのコアもしくは DELTA-V バージョン管理＆コンフィグレーション管理議論用の list への参加方法については、Working Group Home Pageを見るとわかります）

公開された標準なので、（それを見たり使ったりする）人がその標準にこだわるかどうかを決定することが出来ます。別にマイクロソフトがその標準に沿わないことを決定する自由もあります。しかしその標準をあとで変更することは出来ません。

しかしながら、私はマイクロソフトが mod_dav と自分たちのプロダクトとの相互接続性を保証することに対し、非常に自発的でかつ協調性を発揮してくれたということを個人的に言っておきます。実際、それらはすばらしく有用であり、彼らの支援の結果見つかった多くのバグをフィックスすることが出来ました。

いまや、ここまで言ってきたように、企業がDAVプロトコルへの準拠をうたうのは可能になりました。プロトコルの上位、いわゆるアプリケーションのレベルにおいて、彼らはクライアントサーバ間で特別な処理を実装することが出来ます。ここは、アプリケーションベンダが付加価値をつける部分であり、ビジネスを行う上でごく普通のことです。もしサーバがよりよいアプリケーションレベルのサポートを提供するならば、もし望む機能があればそれを特定のサーバに実装出来るかもしれません。あなたはDAVサーバを自由に選べますが、選んだ結果としてDAVの持ち得る機能性を失うこともあるということは認識してください。

IETF WebDAVワーキンググループがその役目を負っています。このグループは、Jim Whiteheadがチェアを努めており、自らのWebページを持っています。DAVスペックの作成について、大半の実作業は、DAV discussion lists 上のワーキンググループで行われています。

あなたが必要なことは、discussion list に参加することです。list に参加している誰もがワーキンググループのメンバであると認識しています。discussion list に参加するための情報は、Working Group Home Pageに記述されています。

W3Cは、IETFに全て任せてプロトコルからは手を引こうとしています。というのも、DAVはプロトコルであり、IETFスタンダードとして制御されるからです。DAVはXML（プロトコルというよりはコンテンツ形式の標準です）を使いますが、こちらはW3Cの標準です。何かヘンですかね？

DAVの主な特徴は、全てのファイルを操作する協調作業向けでないアプリケーションからの（協調作業向けの）移行パスを提供することもあります。WebDAVは、既存のアプリケーションに対して容易にWebDAVサポート（全てのリソースに適用可能なロックや名前空間の操作など）を追加できるようにデザインされています。DAVクライアントAPIは軽量に作られています。これにより、大きな開発向けの負担を負うことがありません。Office 2000 は、DAV機能を有効にした最初の非協調作業向けアプリケーションです。そして他の製品も確実に後を追っています。

アプリケーションがDAVをサポートするように遷移するようになった場合、既存のアプリケーションはローカルファイルシステムを用いて、更にsitecopyのようなDAVサーバへの変更を書き込むためのプログラムを併用することでDAVへの対応を行うことが可能です。マイクロソフトも「Webフォルダ」と呼ばれる機能を提供しており、これを使うことでDAVサーバ上のコレクションを Windows 上のディレクトリの1つで「あるかのように」扱うことが可能になります。非DAVアプリケーションはこれらのディレクトリを直接扱うことは出来ません。というのもあくまで「そう見える」だけだからです。---それらのWebフォルダは、ローカルファイルシステムにはマッピングされてません。Windows の「リダイレクタ」は、それらの Webフォルダがローカルファイルシステムであるかのように見せることが出来ます。しかし、そんなものを使うよりは、さっさとアプリケーションが DAVサーバを直接使うことが出来るよう変更すべきでしょう。

IETF は全ての参加者が個々のコントリビュータであることを期待する一方、多くの人は、キーとなる参加者が企業に加入するのを見てわかることがあるでしょう。結局、DAVを開発する時間を費やすことが出来る人は、所属してる組織の全面的なサポートを得ています。

マイクロソフト、ネットスケープ、ノベル、そしてゼロックスは、その大事な時間をベースのDAVプロトコル開発に費やしています。そしてFilenet、DocumentumおよびPC Docsのようなドキュメント管理ベンダからの参加者は大きな興味を持っています。カリフォルニア大学Irvine校のJim Whiteheadは、チェアを勤めましたが、彼のオフィスメイトであるRoy FieldingがApache Groupの創設者であることを考えると、これは重要です。さらに、これらの組織には、クライアントおよびサーバサイドの両面において、マーケットシェアのコントロールと組み合わせつつDAVをデファクトスタンダードにするだけの力があります。

世界一流のバージョン管理およびCMに関する専門知識を持ったチームは、現在バージョン管理についての標準を開発するために動いてます。設計チームの参加者は、Rational(ClearCase)、Microsoft(Visual SourceSafe)、Intersolv(PVCS)、Novell (GroupWise)、そしてIBM(Envy)から来ています。学術サイドの参加者は、カリフォルニア大学Irvine校およびボストン大学から来ています。これらの人々は、良い標準を開発した経験を持っており、十分なシェアを持つ組織からこの技術をデファクトスタンダードとするために来ています。これらの組織は、ソフトウェア開発において重要な経験と市場シェアを持っています。しかしながら、IETFのプロセスが会員についての概念を持たず、また企業が介在していないことを知ることは重要です。これは、個人としてのコントリビュータのみ存在することを意味していますが、彼らは往々にして企業や何らかの団体からのバックアップを受けています。策定プロセスの中には投票はなく、ML 上でのおおまかなコンセンサスがあるのみです。その結果、個々のコントリビュータは（その考え方に）大きな相違を持っていますが、これがIETFの基準が典型的に高水準の技術品質を持つ理由の1つです。

Projects and Software pageには、DAVサポートをしている商用製品が掲載されています。

まだいくつかのプロジェクトしか進んでません。ここには4つのプロジェクトを挙げておきます。

1. mod_dav: Apache用のDAVモジュール
2. sitecopy:Webサイトのコンテンツを、ローカルシステムからWebサーバへとコピーするためのツール
3. cadaver:コマンドラインのFTPツールと似ています。このツールはDAVサーバとの間で簡単で直接的なインタラクションを実現します。
4. Goliath: MacOS のためのDAVクライアントアプリケーションおよびライブラリです。

とっても簡単。mod_dav page に行ってみてください。そして、dav-dev mailing listに参加してみてください。

versioning group ができる限り早くプロトコルの詳細を書いています。しかしプロトコルは変更されつづけています。もしあなたが面倒でなければ、自由にプロジェクトを開始してください（その時は、Gregに教えて下さい。彼はその時助けになるか、助けになるほかの人を見つけてくれるでしょう）。また、mod_dav extensions for Apacheについて、バージョニングサポートについて開発を助けることも可能です。もちろん、プロトコル詳細に関して助けてくれてもOKですDeltaV Working Group Home Pageに詳細が含まれています）。

DAVはHTTPの上で動くため、FTPは享受できないHTTPの利点を全て受け継ぎます。例えば、強力な認証、暗号化、プロキシサポート、そしてキャッシングなどがあります。これらの利点のうちいくつかは、SSH経由でも享受できるのは確かですが、HTTPインフラはSSHよりも広く展開されています。さらに、SSH はHTTPで実現されているような広範囲のツールサポートや開発ライブラリ、そしてアプリケーションはありません。

DAV転送（要はHTTP転送）は、FTPより効果的です。80番ポートへの単一のTCPコネクションを用いて複数の転送を実現できます。が、FTPはファイル転送ごとに新しいコネクションを必要とします（これに加え、FTP ではコントロールコネクションが常に張られています）。（訳注：DAV による転送は、80番ポートだけが使えれば済みますが、FTPではコントロールコネクション（21番）に加え、データコネクション（1回のデータ転送ごとにポート番号を決定。コネクション方向もパッシブかそうでないかで異なります）が必要です。）

これから始める人のために、DAVとCVSの統合をどのようにするかという興味深いアイディアがcvshome.org上のページに記述されています。

見込みとしては、DAVサポートを行いつつ、CVSがさまざまなCMリポジトリを使い、相互乗り入れをしつつ共同作業を行えて、プロジェクト管理のためにさらに魅力的なプラットフォームを提供するだろうということです。具体的には、プロジェクトが大きくなり、より大きなリポジトリを使うようになったとしても、CVSで使っているツールは放棄する必要はありません。さらに、CVSが複数のリポジトリが混在しているところで使われていたとしても、WebDAV はそれら複数のリポジトリに対してCVSとの相互運用を実現するためのさまざまなデータ統合層を提供します。

将来的に、いくつかの点において置き換えるのに使われるでしょう。私は、CVSフロントエンドは残るだろうと信じています。そしてその結果、慣れ親しんだツールを使いつづけることができます。しかしながら、バックエンドは（DAVのものに）変わり、回線上のプロトコルがHTTPになり（その恩恵を享受する）、CVSデーモンはDAVサーバとかわってその姿を消すでしょう。

必ずしもそうではありません。バージョン管理の詳細は、今もなお活動中です。しかしこのプロトコルは、複数のチェックアウトとマージはサポートしています。今現在とこれからしばらくの間、DAVのバージョン管理機能がCVSのそれと等価になるまでの間は、CVSが最も良い環境でありつづけるでしょう。

これは興味深い質問ですね。DAVは確かにそういうことをしてしまう可能性を持ったプロトコルです。FTP はすでに HTTP にとってかわられてしまってます。POP3はどうでしょう？新しいメッセージのリストを得るDAVのPROPFINDメソッドの組み合わせ(それらを取り除くために多くのDELETEを後に続けて、それらを取って来る一連のGET)を使うことでありえます。IMAPフォルダ管理はどうでしょう？メッセージをコピーしたり動かしたりする COPY や MOVE メソッド、そして新しいフォルダを作成する MKCOL メソッドを単に使用するだけです。

しかしながら、これらのいずれもクライアントがない状態では起こり得ません。そして、もしクライアントが出てくるとしてもまだ長い時間かかるでしょう。また、実際には利用する人が HTTP 単一プロトコルを使いたいか、それとも FTP / POP3 / IMAP / NNTP その他の個々のプロトコルを使いたいかに依存します。単一のプロトコルのためのライブラリを作成し、その上にいろんなものを実装する方が確実に有利ではあります。DAV は HTTP を使っているため、他のプロトコルが持っていない多くのものをすでに持っています。例えば認証や暗号化、プロキシ、キャッシュ等がそれにあたります。

ここに挙げた全てを試すよりも、まずはシンプルにWebDAV Resourcesのページにアクセスしてみることをお薦めします。

mod_encoding を使いましょう。置き場所は、（補完予定）です。

クライアントのエンコーディングを SJIS と指定しているか、古い mod_encoding を使っていますね。新しい mod_encoding を入手して、その設定の中で、Webフォルダのエンコーディングを MSSJIS として下さい。

それは、MacOS X の採用している Unicode バージョンが新しいために発生している問題です。現在、mod_encoding の改修を検討しています。

それは、ファイルシステム上に出来ているファイルの名前について、エンコーディングが UTF-8 になっています。これを解決するためには、UTF-8 対応の端末エミュレータを用いるか、mod_encoding の設定でサーバ上のエンコーディングを UTF-8 以外のものにする必要があります。

現在、びぎねっとさんの方で、WebDAVユーザ向けのメーリングリストを開設しています。詳細は、WebDAV-jp メーリングリストのページをご覧下さい。

あります。最近は、UNIX USER をはじめとする雑誌で特集が組まれていますので、そちらをごらんになるか、もしくはアットマーク・アイティさんに掲載されている記事の方でも取り上げられています。今後はもっと増えてくるでしょう。