[要約] RFC 2291は、World Wide Webのための分散型著作およびバージョン管理プロトコルの要件を定義しています。その目的は、Web上での共同作業とバージョン管理を容易にすることです。
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
Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web
World Wide Webの分散オーサリングおよびバージョン管理プロトコルの要件
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
Current World Wide Web (WWW or Web) standards provide simple support for applications which allow remote editing of typed data. In practice, the existing capabilities of the WWW have proven inadequate to support efficient, scalable remote editing free of overwriting conflicts. This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW.
現在のWorld Wide Web（WWWまたはWeb）標準は、型付きデータのリモート編集を可能にするアプリケーションを簡単にサポートします。実際には、WWWの既存の機能は、上書きの競合がない、効率的でスケーラブルなリモート編集をサポートするには不十分であることが判明しています。このドキュメントでは、Web分散オーサリングとバージョン管理プロトコルの要件の形式で機能のリストを示します。実装すると、一般的なリモート編集操作の効率が向上し、ロックのメカニズムが提供され、上書きの競合が防止され、非リンク間のリンク管理サポートが向上します-HTMLデータ型は、単純な属性値メタデータ機能を提供し、コンテナーデータ型の作成と読み取りを提供し、バージョン管理をWWWに統合します。
This document describes functionality which, if incorporated in an extension to the existing HTTP proposed standard [HTTP], would allow tools for remote loading, editing and saving (publishing) of various media types on the WWW to interoperate with any compliant Web server. As much as possible, this functionality is described without suggesting a proposed implementation, since there are many ways to perform the functionality within the WWW framework. It is also possible that a single mechanism could simultaneously satisfy several requirements.
このドキュメントでは、既存のHTTP提案標準[HTTP]の拡張機能に組み込むと、WWW上のさまざまなメディアタイプをリモートでロード、編集、保存（公開）するためのツールが、準拠するWebサーバーと相互運用できるようになる機能について説明します。 WWWフレームワーク内で機能を実行する多くの方法があるため、可能な限り、この機能は提案された実装を提案することなく説明されます。また、単一のメカニズムで複数の要件を同時に満たすこともできます。
This document reflects the consensus of the WWW Distributed Authoring and Versioning working group (WebDAV) as to the functionality that should be standardized to support distributed authoring and versioning on the Web. As with any set of requirements, practical considerations may make it impossible to satisfy them all. It is the intention of the WebDAV working group to come as close as possible to satisfying them in the specifications that make up the WebDAV protocol.
このドキュメントは、Webでの分散オーサリングとバージョン管理をサポートするために標準化する必要がある機能に関するWWW分散オーサリングおよびバージョン管理作業グループ（WebDAV）の合意を反映しています。一連の要件と同様に、実際の考慮事項により、すべての要件を満たすことが不可能になる場合があります。 WebDAVプロトコルを構成する仕様でできる限りそれらに近づくことがWebDAVワーキンググループの意図です。
Current Web standards contain functionality which enables the editing of Web content at a remote location, without direct access to the storage media via an operating system. This capability is exploited by several existing HTML distributed authoring tools, and by a growing number of mainstream applications (e.g., word processors) which allow users to write (publish) their work to an HTTP server. To date, experience from the HTML authoring tools has shown they are unable to meet their users' needs using the facilities of Web standards. The consequence of this is either postponed introduction of distributed authoring capability, or the addition of nonstandard extensions to the HTTP protocol or other Web standards. These extensions, developed in isolation, are not interoperable.
現在のWeb標準には、オペレーティングシステムを介してストレージメディアに直接アクセスすることなく、離れた場所でWebコンテンツを編集できる機能が含まれています。この機能は、いくつかの既存のHTML分散オーサリングツールと、ユーザーが自分の作業をHTTPサーバーに書き込む（公開する）ことを可能にする主流のアプリケーション（ワードプロセッサなど）の増加によって利用されています。これまでに、HTMLオーサリングツールの経験から、Web標準の機能を使用してユーザーのニーズを満たすことができないことがわかりました。この結果、分散オーサリング機能の導入が延期されるか、HTTPプロトコルまたはその他のWeb標準に非標準の拡張機能が追加されます。分離して開発されたこれらの拡張機能は相互運用できません。
Other authoring applications have wanted to access document repositories or version control systems through Web gateways, and have been similarly frustrated. Where this access is available at all, it is through nonstandard extensions to HTTP or other standards that force clients to use a different interface for each vendor's service.
他のオーサリングアプリケーションは、Webゲートウェイを介してドキュメントリポジトリまたはバージョン管理システムにアクセスすることを望んでおり、同様に不満を感じています。このアクセスがまったく利用できる場合、HTTPや他の標準への非標準の拡張を介して、クライアントに各ベンダーのサービスに異なるインターフェースを使用するよう強制します。
This document describes requirements for a set of standard extensions to HTTP that would allow distributed Web authoring tools to provide the functionality their users need by means of the same standard syntax across all compliant servers. The broad categories of functionality that need to be standardized are:
このドキュメントでは、すべての準拠サーバー全体で同じ標準構文を使用してユーザーが必要とする機能を分散Webオーサリングツールが提供できるようにする、HTTPの標準拡張セットの要件について説明します。標準化する必要がある機能の幅広いカテゴリは次のとおりです。
Properties Links Locking Reservations Retrieval of Unprocessed Source Partial Write Name Space Manipulation Collections Versioning Variants Security Internationalization
プロパティリンク未処理ソースの予約の取得のロック部分的な名前空間書き込み操作コレクションバージョン管理バリアントセキュリティの国際化
Where there is overlap, usage is intended to be consistent with that in the HTTP 1.1 specification [HTTP].
重複がある場合、使用法はHTTP 1.1仕様[HTTP]の使用法と一致するように意図されています。
Client A program which issues HTTP requests and accepts responses.
クライアントHTTP要求を発行し、応答を受け入れるプログラム。
Collection A collection is a resource that contains other resources, either directly or by reference.
コレクションコレクションは、直接または参照により、他のリソースを含むリソースです。
Distributed Authoring Tool A program which can retrieve a source entity via HTTP, allow editing of this entity, and then save/publish this entity to a server using HTTP.
分散オーサリングツールHTTP経由でソースエンティティを取得し、このエンティティの編集を許可し、HTTPを使用してこのエンティティをサーバーに保存/公開できるプログラム。
Entity The information transferred in a request or response.
エンティティリクエストまたはレスポンスで転送される情報。
Hierarchical Collection A hierarchical organization of resources. A hierarchical collection is a resource that contains other resources, including collections, either directly or by reference.
階層コレクションリソースの階層構造。階層コレクションは、コレクションを含む他のリソースを直接または参照して含むリソースです。
Link A typed connection between two or more resources.
リンク2つ以上のリソース間の型付き接続。
Lock A mechanism for preventing anyone other than the owner of the lock from accessing a resource.
ロックロックの所有者以外の誰かがリソースにアクセスできないようにするメカニズム。
Member of Version Graph A resource that is a node in a version graph, and so is derived from the resources that precede it in the graph, and is the basis of those that succeed it.
バージョングラフのメンバーバージョングラフ内のノードであるリソース。したがって、グラフ内でそれより前にあるリソースから派生し、その後に続くリソースの基礎となります。
Property Named descriptive information about a resource.
プロパティリソースに関する名前付きの説明情報。
Reservation A declaration that one intends to edit a resource.
予約リソースを編集することを意図した宣言。
Resource A network data object or service that can be identified by a URI.
リソースURIで識別できるネットワークデータオブジェクトまたはサービス。
Server A program which receives and responds to HTTP requests.
サーバーHTTP要求を受信して応答するプログラム。
User Agent The client that initiates a request.
ユーザーエージェントリクエストを開始するクライアント。
Variant A representation of a resource. A resource may have one or more representations associated with it at any given time.
バリアントリソースの表現。リソースには、常に1つ以上の表現が関連付けられている場合があります。
Version Graph A directed acyclic graph with resources as its nodes, where each node is derived from its predecessor(s).
バージョングラフノードとしてリソースを持つ有向非循環グラフ。各ノードはその先行ノードから派生します。
Write Lock A lock that prevents anyone except its owner from modifying the resource it applies to.
書き込みロック所有者以外の誰もが適用するリソースを変更できないようにするロック。
This section describes a set of general principles that the WebDAV extensions should follow. These principles cut across categories of functionality.
このセクションでは、WebDAV拡張が従うべき一連の一般原則について説明します。これらの原則は、機能のカテゴリにまたがっています。
All WebDAV clients should be able to work with any WebDAV-compliant HTTP server. It is acceptable for some client/server combinations to provide special features that are not universally available, but the protocol should be sufficient that a basic level of functionality will be universal.
すべてのWebDAVクライアントは、任意のWebDAV準拠のHTTPサーバーと連携できる必要があります。一部のクライアント/サーバーの組み合わせでは、普遍的に利用できない特別な機能を提供することは許容されますが、プロトコルは、基本的なレベルの機能が普遍的になるのに十分でなければなりません。
The WebDAV extensions should be designed to allow client implementations to be simple.
WebDAV拡張は、クライアントの実装が単純になるように設計する必要があります。
It should be possible to implement a WebDAV-compliant server in such a way that it can interoperate with non-WebDAV clients. Such a server would be able to understand any valid HTTP 1.1 request from an ordinary Web client without WebDAV extensions, and to provide a valid HTTP 1.1 response that does not require the client to understand the extensions.
非WebDAVクライアントと相互運用できるように、WebDAV準拠のサーバーを実装できる必要があります。このようなサーバーは、WebDAV拡張機能のない通常のWebクライアントからの有効なHTTP 1.1要求を理解し、クライアントが拡張機能を理解する必要がない有効なHTTP 1.1応答を提供できます。
WebDAV-compliant servers should be able to work with existing resources and URIs [URL]. Special additional information should not become a mandatory part of document formats.
WebDAV準拠のサーバーは、既存のリソースとURI [URL]を処理できる必要があります。特別な追加情報は、ドキュメント形式の必須部分にはなりません。
Distribution and replication are at the heart of the Internet. All WebDAV extensions should be designed to allow for distribution and replication. Version trees should be able to be split across multiple servers. Collections may have members on different servers. Any resource may be cached or replicated for mobile computing or other reasons. Consequently, the WebDAV extensions must be able to operate in a distributed, replicated environment.
配布と複製はインターネットの中心です。すべてのWebDAV拡張機能は、配布と複製を可能にするように設計する必要があります。バージョンツリーは、複数のサーバーに分割できる必要があります。コレクションには、異なるサーバー上のメンバーが含まれる場合があります。リソースは、モバイルコンピューティングまたはその他の理由でキャッシュまたは複製される場合があります。したがって、WebDAV拡張機能は、分散複製環境で動作できる必要があります。
The WebDAV extensions should keep to a minimum the number of interactions between the client and the server needed to perform common functions. For example, publishing a document to the Web will often mean publishing content together with related properties. A client may often need to find out what version graph a particular resource belongs to, or to find out which resource in a version graph is the published one. The extensions should make it possible to do these things efficiently.
WebDAV拡張は、一般的な機能を実行するために必要なクライアントとサーバー間の対話の数を最小限に抑える必要があります。たとえば、ドキュメントをWebに発行するとは、多くの場合、関連するプロパティと共にコンテンツを発行することを意味します。クライアントは、特定のリソースがどのバージョングラフに属しているかを調べたり、バージョングラフのどのリソースが公開されているかを調べたりする必要がある場合があります。拡張機能により、これらのことを効率的に行うことができるはずです。
WebDAV adds a number of new types of objects to the Web: properties, collections, version graphs, etc. Existing HTTP methods such as DELETE and PUT will have to operate in well-defined ways in this expanded environment. WebDAV should explicitly address not only new methods, headers, and MIME types, but also any required changes to the existing HTTP methods and headers.
WebDAVは、プロパティ、コレクション、バージョングラフなど、多くの新しいタイプのオブジェクトをWebに追加します。DELETEやPUTなどの既存のHTTPメソッドは、この拡張された環境で明確に定義された方法で動作する必要があります。 WebDAVは、新しいメソッド、ヘッダー、MIMEタイプだけでなく、既存のHTTPメソッドおよびヘッダーに必要な変更も明示的に対処する必要があります。
It may be desirable to transport WebDAV requests and responses by other mechanisms, particularly EMail, in addition to HTTP. The WebDAV protocol specification should not preclude a future body from developing an interoperability specification for disconnected operation via EMail.
HTTPに加えて、他のメカニズム、特にEMailによってWebDAV要求と応答を転送することが望ましい場合があります。 WebDAVプロトコル仕様は、将来の団体がEMailを介した切断された操作の相互運用性仕様を開発することを妨げるべきではありません。
In the requirement descriptions below, the requirement will be stated, followed by its rationale.
以下の要件の説明では、要件が説明され、その根拠が続きます。
It must be possible to create, modify, read and delete arbitrary properties on resources of any media type.
任意のメディアタイプのリソースの任意のプロパティを作成、変更、読み取り、削除できる必要があります。
Properties describe resources of any media type. They may include bibliographic information such as author, title, publisher, and subject, constraints on usage, PICS ratings, etc. These properties have many uses, such as supporting searches on property values, enforcing copyrights, and the creation of catalog entries as placeholders for objects which are not available in electronic form, or which will be available later.
プロパティは、あらゆるメディアタイプのリソースを記述します。これらには、著者、タイトル、発行者、主題などの書誌情報、使用上の制約、PICS評価などが含まれます。これらのプロパティには、プロパティ値の検索のサポート、著作権の適用、プレースホルダーとしてのカタログエントリの作成など、多くの用途があります。電子形式で入手できないオブジェクト、または後で入手できるオブジェクトの場合。
It must be possible to create, modify, read and delete typed links between resources of any media type.
メディアタイプのリソース間の型付きリンクを作成、変更、読み取り、および削除できる必要があります。
One type of link between resources is the hypertext link, which is browsable using a hypertext style point-and-click user interface. Links, whether they are browsable hypertext links, or simply a means of capturing a relationship between resources, have many purposes. Links can support pushbutton printing of a multi-resource document in a prescribed order, jumping to the access control page for a resource, and quick browsing of related information, such as a table of contents, an index, a glossary, a bibliographic record, help pages, etc. While link support is provided by the HTML "LINK" element, this is limited only to HTML resources [HTML]. Similar support is needed for bitmap image types, and other non-HTML media types.
リソース間のリンクの1つのタイプは、ハイパーテキストリンクです。これは、ハイパーテキストスタイルのポイントアンドクリックユーザーインターフェイスを使用して参照できます。リンクは、ブラウズ可能なハイパーテキストリンクであるか、単にリソース間の関係を取得する手段であるかにかかわらず、多くの目的があります。リンクは、所定の順序でのマルチリソースドキュメントの押しボタン印刷、リソースのアクセス制御ページへのジャンプ、目次、索引、用語集、書誌レコードなどの関連情報の迅速な参照をサポートできます。ヘルプページなど。リンクのサポートはHTMLの「LINK」要素によって提供されますが、これはHTMLリソース[HTML]にのみ限定されます。ビットマップ画像タイプやその他の非HTMLメディアタイプについても、同様のサポートが必要です。
5.3.1.1. Independence of locks. It must be possible to lock a resource without performing an additional retrieval of the resource, and without committing to editing the resource.
5.3.1.1. ロックの独立性。リソースの追加取得を実行したり、リソースの編集をコミットしたりせずに、リソースをロックできる必要があります。
5.3.1.2. Multi-Resource Locking. It must be possible to take out a lock on multiple resources residing on the same server in a single action, and this locking operation must be atomic across these resources.
5.3.1.2. マルチリソースロック。同じサーバー上にある複数のリソースのロックを1回のアクションで解除できる必要があり、このロック操作はこれらのリソース全体でアトミックである必要があります。
5.3.2.1. Write Locks. It must be possible to restrict modification of a resource to a specific person.
5.3.2.1. ロックの書き込み。リソースの変更を特定の人に制限することが可能でなければなりません。
5.3.2.2. Lock Query. It must be possible to find out whether a given resource has any active locks, and if so, who holds those locks.
5.3.2.2. クエリをロックします。特定のリソースにアクティブなロックがあるかどうか、ある場合はそれらのロックを保持しているユーザーを見つけることが可能でなければなりません。
5.3.2.3. Unlock. It must be possible to remove a lock.
5.3.2.3. ロックを解除します。ロックを解除できる必要があります。
At present, the Web provides limited support for preventing two or more people from overwriting each other's modifications when they save to a given URI. Furthermore, there is no way to discover whether someone else is currently making modifications to a resource. This is known as the "lost update problem," or the "overwrite problem." Since there can be significant cost associated with discovering and repairing lost modifications, preventing this problem is crucial for supporting distributed authoring. A write lock ensures that only one person may modify a resource, preventing overwrites. Furthermore, locking support is a key component of many versioning schemes, a desirable capability for distributed authoring.
現在、Webは、2人以上のユーザーが特定のURIに保存するときに互いの変更を上書きできないようにするための限定的なサポートを提供しています。さらに、誰かが現在リソースに変更を加えているかどうかを発見する方法はありません。これは「失われた更新の問題」または「上書きの問題」として知られています。失われた変更の検出と修復にはかなりのコストがかかる可能性があるため、この問題を防ぐことは、分散オーサリングをサポートするために重要です。書き込みロックにより、1人のユーザーのみがリソースを変更できるようになり、上書きが防止されます。さらに、ロックのサポートは、多くのバージョン管理スキームの主要コンポーネントであり、分散オーサリングに望ましい機能です。
An author may wish to lock an entire web of resources even though he is editing just a single resource, to keep the other resources from changing. In this way, an author can ensure that if a local hypertext web is consistent in his distributed authoring tool, it will then be consistent when he writes it to the server. Because of this, it should be possible to take out a lock without also causing transmission of the contents of a resource.
著者は、他のリソースが変更されないようにするために、1つのリソースのみを編集している場合でも、リソースのWeb全体をロックしたい場合があります。このようにして、作成者は、ローカルハイパーテキストWebが分散オーサリングツールで一貫している場合、サーバーに書き込んだときに一貫していることを確認できます。このため、リソースの内容を送信することなくロックを外すことができるはずです。
It is often necessary to guarantee that a lock or unlock operation occurs at the same time across multiple resources, a feature which is supported by the multiple-resource locking requirement. This is useful for preventing a collision between two people trying to establish locks on the same set of resources, since with multi-resource locking, one of the two people will get a lock. If this same multiple-resource locking scenario was repeated by using atomic lock operations iterated across the resources, the result would be a splitting of the locks between the two people, based on resource ordering and race conditions.
多くの場合、複数のリソース間でロックまたはロック解除操作が同時に発生することを保証する必要があります。これは、複数リソースのロック要件でサポートされている機能です。これは、同じリソースのセットでロックを確立しようとする2人の衝突を防ぐのに役立ちます。マルチリソースロックでは、2人のうち1人がロックを取得するためです。リソース間で反復されるアトミックロック操作を使用してこの同じ複数リソースロックのシナリオを繰り返した場合、リソースの順序と競合状態に基づいて、2人のユーザー間でロックが分割されます。
5.4.1.1. Reserve. It must be possible for a principal to register with the server an intent to edit a given resource, so that other principals can discover who intends to edit the resource.
5.4.1.1. 予約。プリンシパルは、特定のリソースを編集する意図でサーバーに登録できる必要があります。これにより、他のプリンシパルは、リソースを編集する意図を発見できます。
5.4.1.2. Reservation Query. It must be possible to find out whether a given resource has any active reservations, and if so, who currently holds reservations.
5.4.1.2. 予約クエリ。特定のリソースにアクティブな予約があるかどうか、またある場合、現在予約を保持している人を見つけることが可能でなければなりません。
5.4.1.3. Release Reservation. It must be possible to release the reservation.
5.4.1.3. 予約を解除します。予約を解除できる必要があります。
Experience from configuration management systems has shown that people need to know when they are about to enter a parallel editing situation. Once notified, they either decide not to edit in parallel with the other authors, or they use out-of-band communication (face-to-face, telephone, etc.) to coordinate their editing to minimize the difficulty of merging their results. Reservations are separate from locking, since a write lock does not necessarily imply a resource will be edited, and a reservation does not carry with it any access restrictions. This capability supports versioning, since a check-out typically involves taking out a write lock, making a reservation, and getting the resource to be edited.
構成管理システムの経験から、並行編集の状況に入るタイミングを知る必要があることがわかっています。通知を受けると、他の作成者と並行して編集しないことを決定するか、アウトオブバンド通信（対面、電話など）を使用して編集を調整し、結果をマージする難しさを最小限に抑えます。書き込みロックは必ずしもリソースが編集されることを意味するわけではないため、予約はロックとは別であり、予約はアクセス制限を伴いません。チェックアウトは通常、書き込みロックの解除、予約の作成、リソースの編集を行うため、この機能はバージョン管理をサポートします。
The source of any given resource must be retrievable by any principal with authorization to edit the resource.
特定のリソースのソースは、リソースを編集する権限を持つプリンシパルによって取得可能である必要があります。
There are many cases where the source stored on a server does not correspond to the actual entity transmitted in response to an HTTP GET. Current known cases are server side include directives, and Standard Generalized Markup Language (SGML) source which is converted on the fly to HyperText Markup Language (HTML) [HTML] output entities. There are many possible cases, such as automatic conversion of bitmap images into several variant bitmap media types (e.g. GIF, JPEG), and automatic conversion of an application's native media type into HTML. As an example of this last case, a word processor could store its native media type on a server which automatically converts it to HTML. A GET of this resource would retrieve the HTML. Retrieving the source would retrieve the word processor native format.
サーバーに格納されているソースが、HTTP GETに応答して送信された実際のエンティティに対応していない場合が多くあります。現在の既知のケースは、サーバー側のincludeディレクティブ、およびその場でハイパーテキストマークアップ言語（HTML）[HTML]出力エンティティに変換される標準の汎用マークアップ言語（SGML）ソースです。ビットマップ画像のいくつかのバリアントビットマップメディアタイプ（GIF、JPEGなど）への自動変換、アプリケーションのネイティブメディアタイプのHTMLへの自動変換など、多くの可能なケースがあります。この最後のケースの例として、ワープロはネイティブメディアタイプをサーバーに保存し、それを自動的にHTMLに変換します。このリソースのGETはHTMLを取得します。ソースを取得すると、ワードプロセッサのネイティブ形式が取得されます。
5.6. Partial Write.
5.6. 部分書き込み。
After editing a resource, it must be possible to write only the changes to the resource, rather than retransmitting the entire resource.
リソースを編集した後、リソース全体を再送信するのではなく、リソースへの変更のみを書き込むことが可能でなければなりません。
During distributed editing which occurs over wide geographic separations and/or over low bandwidth connections, it is extremely inefficient and frustrating to rewrite a large resource after minor changes, such as a one-character spelling correction. Support is needed for transmitting "insert" (e.g., add this sentence in the middle of a document) and "delete" (e.g. remove this paragraph from the middle of a document) style updates. Support for partial resource updates will make small edits more efficient, and allow distributed authoring tools to scale up for editing large documents.
地理的に離れた場所や低帯域幅の接続で発生する分散編集中に、1文字のスペル修正などの小さな変更を加えた後で大きなリソースを書き換えることは非常に非効率的でイライラします。 「挿入」（例：ドキュメントの途中でこの文を追加）および「削除」（例：ドキュメントの途中からこの段落を削除）スタイルの更新を送信するには、サポートが必要です。部分的なリソース更新のサポートにより、小さな編集がより効率的になり、分散したオーサリングツールが大きなドキュメントを編集するためにスケールアップできるようになります。
It must be possible to duplicate a resource without a client loading, then resaving the resource. After the copy operation, a modification to either resource must not cause a modification to the other.
クライアントをロードせずにリソースを複製してから、リソースを再保存できる必要があります。コピー操作後、いずれかのリソースを変更しても、もう一方のリソースが変更されてはなりません。
There are many reasons why a resource might need to be duplicated, such as changing ownership, preparing for major modifications, or making a backup. Due to network costs associated with loading and saving a resource, it is far preferable to have a server perform a resource copy than a client.
所有権の変更、大きな変更の準備、バックアップの作成など、リソースを複製する必要がある理由はたくさんあります。リソースのロードと保存に関連するネットワークコストのため、クライアントよりもサーバーにリソースのコピーを実行させる方がはるかに望ましいです。
It must be possible to change the location of a resource without a client loading, then resaving the resource under a different name. After the move operation, it must no longer be possible to access the resource at its original location.
クライアントをロードせずにリソースの場所を変更し、リソースを別の名前で再保存できる必要があります。移動操作後は、元の場所にあるリソースにアクセスできなくなります。
It is often necessary to change the name of a resource, for example due to adoption of a new naming convention, or if a typing error was made entering the name originally. Due to network costs, it is undesirable to perform this operation by loading, then resaving the resource, followed by a delete of the old resource. Similarly, a single rename operation is more efficient than a copy followed by a delete operation. Note that moving a resource is considered the same function as renaming a resource.
たとえば、新しい命名規則が採用されたため、または名前を最初に入力するときに入力エラーが発生した場合など、リソースの名前を変更する必要があることがよくあります。ネットワークコストのため、この操作をロードしてリソースを再保存し、その後古いリソースを削除することは望ましくありません。同様に、単一の名前変更操作は、コピーとそれに続く削除操作よりも効率的です。リソースを移動することは、リソースの名前を変更することと同じ機能と見なされることに注意してください。
A collection is a resource that is a container for other resources, including other collections. A resource may belong to a collection either directly or by reference. If a resource belongs to a collection directly, name space operations like copy, move, and delete applied to the collection also apply to the resource. If a resource belongs to a collection by reference, name space operations applied to the collection affect only the reference, not the resource itself.
コレクションは、他のコレクションを含む他のリソースのコンテナであるリソースです。リソースは、直接または参照によってコレクションに属します。リソースがコレクションに直接属している場合、コレクションに適用されるコピー、移動、削除などの名前空間操作もリソースに適用されます。リソースが参照によってコレクションに属している場合、コレクションに適用される名前空間操作は、リソース自体ではなく参照にのみ影響します。
5.8.1.1. List Collection. A listing of all resources in a specific collection must be accessible.
5.8.1.1. リストコレクション。特定のコレクション内のすべてのリソースのリストにアクセスできる必要があります。
5.8.1.2. Make Collection. It must be possible to create a new collection.
5.8.1.2. コレクションを作る。新しいコレクションを作成できる必要があります。
5.8.1.3. Add to Collection. It must be possible to add a resource to a collection directly or by reference.
5.8.1.3. コレクションに追加。リソースを直接または参照によりコレクションに追加できる必要があります。
5.8.1.4. Remove from Collection. It must be possible to remove a resource from a collection.
5.8.1.4. コレクションから削除します。コレクションからリソースを削除できる必要があります。
In [URL] it states that, "some URL schemes (such as the ftp, http, and file schemes) contain names that can be considered hierarchical." Especially for HTTP servers which directly map all or part of their URL name space into a filesystem, it is very useful to get a listing of all resources located at a particular hierarchy level. This functionality supports "Save As..." dialog boxes, which provide a listing of the entities at a current hierarchy level, and allow navigation through the hierarchy. It also supports the creation of graphical visualizations (typically as a network) of the hypertext structure among the entities at a hierarchy level, or set of levels. It also supports a tree visualization of the entities and their hierarchy levels.
[URL]には、「一部のURLスキーム（ftp、http、ファイルスキームなど）には階層と見なすことができる名前が含まれている」と記載されています。特に、URL名前空間のすべてまたは一部をファイルシステムに直接マップするHTTPサーバーの場合、特定の階層レベルにあるすべてのリソースのリストを取得すると非常に便利です。この機能は、[名前を付けて保存...]ダイアログボックスをサポートしています。このダイアログボックスでは、現在の階層レベルでのエンティティのリストが提供され、階層内を移動できます。また、階層レベルまたはレベルセットのエンティティ間のハイパーテキスト構造のグラフィカルな視覚化（通常はネットワーク）の作成もサポートします。また、エンティティとその階層レベルのツリー視覚化もサポートしています。
In addition, document management systems may want to make their documents accessible through the Web. They typically allow the organization of documents into collections, and so also want their users to be able to view the collection hierarchy through the Web.
さらに、ドキュメント管理システムでは、Web経由でドキュメントにアクセスできるようにする必要がある場合があります。通常、ドキュメントをコレクションに編成できるため、ユーザーがWebを介してコレクションの階層を表示できるようにします。
There are many instances where there is not a strong correlation between a URL hierarchy level and the notion of a collection. One example is a server in which the URL hierarchy level maps to a computational process which performs some resolution on the name. In this case, the contents of the URL hierarchy level can vary depending on the input to the computation, and the number of resources accessible via the computation can be very large. It does not make sense to implement a directory feature for such a name space. However, the utility of listing the contents of those URL hierarchy levels which do correspond to collections, such as the large number of HTTP servers which map their name space to a filesystem, argue for the inclusion of this capability, despite not being meaningful in all cases. If listing the contents of a URL hierarchy level does not makes sense for a particular URL, then a "405 Method Not Allowed" status code could be issued.
URL階層レベルとコレクションの概念との間に強い相関がない多くの場合があります。 1つの例は、URL階層レベルが名前の解決を実行する計算プロセスにマップするサーバーです。この場合、URL階層レベルの内容は、計算への入力に応じて変化する可能性があり、計算を介してアクセスできるリソースの数は非常に多くなる可能性があります。このような名前空間のディレクトリ機能を実装することは意味がありません。ただし、コレクションに対応するURL階層レベルのコンテンツを一覧表示するユーティリティ（ファイルシステムに名前空間をマップする多数のHTTPサーバーなど）は、すべてで意味があるわけではないにもかかわらず、この機能を含めることを主張しています。ケース。 URL階層レベルのコンテンツをリストすることが特定のURLにとって意味をなさない場合、「405メソッドは許可されていません」というステータスコードが発行される可能性があります。
The ability to create collections to hold related resources supports management of a name space by packaging its members into small, related clusters. The utility of this capability is demonstrated by the broad implementation of directories in recent operating systems. The ability to create a collection also supports the creation of "Save As..." dialog boxes with "New Level/Folder/Directory" capability, common in many applications.
関連リソースを保持するためのコレクションを作成する機能は、そのメンバーを小さな関連クラスターにパッケージ化することにより、名前空間の管理をサポートします。この機能の有用性は、最近のオペレーティングシステムでのディレクトリの広範な実装によって実証されています。コレクションを作成する機能は、多くのアプリケーションで一般的な「新しいレベル/フォルダ/ディレクトリ」機能を備えた「名前を付けて保存」ダイアログボックスの作成もサポートします。
5.9.1.1. Stability of versions. Most versioning systems are intended to provide an accurate record of the history of evolution of a document. This accuracy is ensured by the fact that a version eventually becomes "frozen" and immutable. Once a version is frozen, further changes will create new versions rather than modifying the original. In order for caching and persistent references to be properly maintained, a client must be able to determine that a version has been frozen. Any successful attempt to retrieve a frozen version of a resource will always retrieve exactly the same content, or return an error if that version (or the resource itself) is no longer available.
5.9.1.1. バージョンの安定性。ほとんどのバージョン管理システムは、ドキュメントの進化の履歴を正確に記録することを目的としています。この精度は、バージョンが最終的に「凍結」されて不変になるという事実によって保証されます。バージョンが凍結されると、さらに変更を加えると、元のバージョンが変更されるのではなく、新しいバージョンが作成されます。キャッシュと永続的な参照が適切に維持されるためには、クライアントがバージョンが凍結されていると判断できる必要があります。リソースのフリーズバージョンを取得しようとすると、常にまったく同じコンテンツが取得されます。または、そのバージョン（またはリソース自体）が利用できなくなった場合はエラーが返されます。
5.9.1.2. Operations for Creating New Versions. Version management systems vary greatly in the operations they require, the order of the operations, and how they are combined into atomic functions. In the most complete cases, the logical operations involved are:
5.9.1.2. 新しいバージョンを作成するための操作。バージョン管理システムは、必要な操作、操作の順序、およびそれらをアトミック関数に組み合わせる方法が大きく異なります。最も完全なケースでは、関連する論理演算は次のとおりです。
o Reserve existing version o Lock existing version o Retrieve existing version o Request or suggest identifier for new version o Write new version o Release lock o Release reservation
o 既存バージョンの予約o既存バージョンのロックo既存バージョンの取得o新しいバージョンの識別子の要求または提案o新しいバージョンの書き込みoロックの解除o予約の解除
With the exception of requesting a new version identifier, all of these operations have applications outside of versioning and are either already part of HTTP or are discussed in earlier sections of these requirements. Typically, versioning systems combine reservation, locking, and retrieval -- or some subset of these -- into an atomic checkout function. They combine writing, releasing the lock, and releasing the reservation -- or some subset of these -- into an atomic checkin function. The new version identifier may be assigned either at checkout or at checkin.
新しいバージョン識別子を要求することを除いて、これらの操作はすべてバージョン管理外のアプリケーションを持ち、すでにHTTPの一部であるか、これらの要件の前のセクションで説明されています。通常、バージョン管理システムは、予約、ロック、および取得（またはこれらの一部）をアトミックチェックアウト関数に組み合わせます。これらは、書き込み、ロックの解放、予約の解放（またはこれらのサブセット）を組み合わせて、アトミックチェックイン関数にします。新しいバージョン識別子は、チェックアウト時またはチェックイン時に割り当てられます。
The WebDAV extensions must find some balance between allowing versioning servers to adopt whatever policies they wish with regard to these operations and enforcing enough uniformity to keep client implementations simple.
WebDAV拡張機能は、バージョン管理サーバーがこれらの操作に関して希望するポリシーを採用できるようにすることと、クライアントの実装を単純に保つのに十分な均一性を適用することのバランスを見つける必要があります。
5.9.1.3. The Versioning Model. Each version typically stands in a "derived from" relationship to its predecessor(s). It is possible to derive several different versions from a single version (branching), and to derive a single version from several versions (merging). Consequently, the collection of related versions forms a directed acyclic graph. In the following discussion, this graph will be called a "version graph". Each node of this graph is a "version" or "member of the version graph". The arcs of the graph capture the "derived from" relationships.
5.9.1.3. バージョン管理モデル。各バージョンは通常、その先行バージョンとの「派生元」関係にあります。単一のバージョンから複数の異なるバージョンを派生させ（分岐）、複数のバージョンから単一のバージョンを派生させること（マージ）が可能です。その結果、関連バージョンのコレクションは有向非循環グラフを形成します。以下の説明では、このグラフを「バージョングラフ」と呼びます。このグラフの各ノードは、「バージョン」または「バージョングラフのメンバー」です。グラフの弧は、「派生元」の関係をキャプチャします。
It is also possible for a single resource to participate in multiple version graphs.
単一のリソースが複数のバージョングラフに参加することも可能です。
The WebDAV extensions should support this versioning model, though particular servers may restrict it in various ways.
WebDAV拡張機能は、このバージョン管理モデルをサポートする必要がありますが、特定のサーバーがさまざまな方法で制限する場合があります。
5.9.1.4. Versioning Policies. Many writers, including Feiler [CM] and Haake and Hicks [VSE], have discussed the notion of versioning styles (referred to here as versioning policies, to reflect the nature of client/server interaction) as one way to think about the different policies that versioning systems implement. Versioning policies include decisions on the shape of version histories (linear or branched), the granularity of change tracking, locking requirements made by a server, etc. The protocol should clearly identify the policies that it dictates and the policies that are left up to versioning system implementors or administrators.
5.9.1.4. バージョン管理ポリシー。 Feiler [CM]やHaake and Hicks [VSE]を含む多くのライターは、異なるポリシーについて考える1つの方法として、バージョニングスタイル（ここではクライアント/サーバーの相互作用の性質を反映するためにバージョン管理ポリシーと呼ばれます）の概念について説明しています。そのバージョン管理システムが実装します。バージョン管理ポリシーには、バージョン履歴の形状（線形または分岐）、変更追跡の細分性、サーバーによって行われたロック要件などの決定が含まれます。プロトコルは、それが指示するポリシーとバージョン管理に委ねられているポリシーを明確に識別する必要がありますシステムの実装者または管理者。
5.9.1.5. It is possible to version resources of any media type.
5.9.1.5. 任意のメディアタイプのリソースをバージョン管理することが可能です。
5.9.2.1. Referring to a version graph. There must be a way to refer to a version graph as a whole.
5.9.2.1. バージョングラフを参照する。バージョングラフ全体を参照する方法が必要です。
Some queries and operations apply, not to any one member of a version graph, but to the version graph as a whole. For example, a client may request that an entire graph be moved, or may ask for a version history. In these cases, a way to refer to the whole version graph is required.
一部のクエリと操作は、バージョングラフの1つのメンバーではなく、バージョングラフ全体に適用されます。たとえば、クライアントはグラフ全体の移動を要求したり、バージョン履歴を要求したりできます。これらの場合、バージョングラフ全体を参照する方法が必要です。
5.9.2.2. Referring to a specific member of a version graph. There must be a way to refer to each member of a version graph. This means that each member of the graph is itself a resource.
5.9.2.2. バージョングラフの特定のメンバーを参照します。バージョングラフの各メンバーを参照する方法が必要です。これは、グラフの各メンバー自体がリソースであることを意味します。
Each member of a version graph must be a resource if it is to be possible for a hypertext link to refer to specific version of a page, or for a client to request a specific version of a document for editing.
ハイパーテキストリンクがページの特定のバージョンを参照すること、またはクライアントが編集のためにドキュメントの特定のバージョンを要求することが可能である場合、バージョングラフの各メンバーはリソースである必要があります。
5.9.2.3. A client must be able to determine whether a resource is a version graph, or whether a resource is itself a member of a version graph.
5.9.2.3. クライアントは、リソースがバージョングラフであるかどうか、またはリソース自体がバージョングラフのメンバーであるかどうかを判別できる必要があります。
A resource may be a simple, non-versioned resource, or it may be a version graph, or it may be a member of a version graph. A client needs to be able to tell which sort of resource it is accessing.
リソースは、バージョン管理されていない単純なリソースの場合もあれば、バージョングラフの場合もあれば、バージョングラフのメンバーの場合もあります。クライアントは、アクセスするリソースの種類を認識できる必要があります。
5.9.2.4. There must be a way to refer to a server-defined default member of a version graph.
5.9.2.4. バージョングラフのサーバー定義のデフォルトメンバーを参照する方法が必要です。
The server should return a default version of a resource for requests that ask for the default version, as well as for requests where no specific version information is provided. This is one of the simplest ways to guarantee non-versioning client compatibility. This does not rule out the possibility of a server returning an error when no sensible default exists.
サーバーは、デフォルトバージョンを要求するリクエストや、特定のバージョン情報が提供されていないリクエストに対して、リソースのデフォルトバージョンを返す必要があります。これは、バージョン非対応のクライアント互換性を保証する最も簡単な方法の1つです。これは、適切なデフォルトが存在しないときにサーバーがエラーを返す可能性を排除するものではありません。
It may also be desirable to be able to refer to other special members of a version graph. For example, there may be a current version for editing that is different from the default version. For a graph with several branches, it may be useful to be able to request the tip version of any branch.
バージョングラフの他の特別なメンバーを参照できることが望ましい場合もあります。たとえば、編集用の現在のバージョンがデフォルトのバージョンと異なる場合があります。複数のブランチを持つグラフの場合、任意のブランチのチップバージョンをリクエストできると便利な場合があります。
5.9.2.5. It must be possible, given a reference to a member of a version graph, to find out which version graph(s) that resource belongs to.
5.9.2.5. バージョングラフのメンバーへの参照を指定すると、リソースが属するバージョングラフを見つけることが可能でなければなりません。
This makes it possible to understand the versioning context of the resource. It makes it possible to retrieve a version history for the graphs to which it belongs, and to browse the version graph. It also supports some comparison operations: It makes it possible to determine whether two references designate members of the same version graph.
これにより、リソースのバージョン管理コンテキストを理解することができます。それが属するグラフのバージョン履歴を取得し、バージョングラフを閲覧することができます。また、いくつかの比較操作もサポートします。2つの参照が同じバージョングラフのメンバーを指定しているかどうかを判断できるようにします。
5.9.2.6. Navigation of a version graph. Given a reference to a member of a version graph, it must be possible to discover and access the following related members of the version graph.
5.9.2.6. バージョングラフのナビゲーション。バージョングラフのメンバーへの参照を指定すると、バージョングラフの次の関連するメンバーを検出してアクセスできる必要があります。
o root member of the graph o predecessor member(s) o successor member(s) o default member of the graph
o グラフのルートメンバーo先行メンバーo後続メンバーoグラフのデフォルトメンバー
It must be possible in some way for a versioning client to access versions related to a resource currently being examined.
バージョニングクライアントが、現在調査中のリソースに関連するバージョンにアクセスできるようにする必要があります。
5.9.2.7. Version Topology. There must be a way to retrieve the complete version topology for a version graph, including information about all members of the version graph. The format for this information must be standardized so that the basic information can be used by all clients. Other specialized formats should be accommodated, for servers and clients that require information that cannot be included in the standard topology.
5.9.2.7. バージョントポロジ。バージョングラフのすべてのメンバーに関する情報を含む、バージョングラフの完全なバージョントポロジを取得する方法が必要です。この情報の形式は、すべてのクライアントが基本情報を使用できるように標準化する必要があります。標準トポロジーに含めることができない情報を必要とするサーバーおよびクライアントには、他の特殊なフォーマットに対応する必要があります。
5.9.2.8. A client must be able to propose a version identifier to be used for a new member of a version graph. The server may refuse to use the client's suggested version identifier. The server should tell the client what version identifier it has assigned to the new member of the version graph.
5.9.2.8. クライアントは、バージョングラフの新しいメンバーに使用するバージョン識別子を提案できる必要があります。サーバーは、クライアントが推奨するバージョン識別子の使用を拒否する場合があります。サーバーは、バージョングラフの新しいメンバーに割り当てたバージョン識別子をクライアントに通知する必要があります。
5.9.2.9. A version identifier must be unique across a version graph.
5.9.2.9. バージョン識別子は、バージョングラフ全体で一意である必要があります。
5.9.2.10. A client must be able to supply version-specific properties to be associated with a new member of a version graph. (See Section 5.1 "Properties" above.) At a minimum, it must be possible to associate comments with the new member, explaining what changes were made.
5.9.2.10. クライアントは、バージョングラフの新しいメンバーに関連付けるバージョン固有のプロパティを提供できる必要があります。 （上記のセクション5.1「プロパティ」を参照してください。）少なくとも、変更が加えられた内容を説明するコメントを新しいメンバーに関連付けることが可能でなければなりません。
5.9.2.11. A client must be able to query the server for information about a version tree, including which versions are locked, which are reserved for editing, and by whom (Session Tracking).
5.9.2.11. クライアントは、ロックされているバージョン、編集用に予約されているバージョン、およびだれが誰が管理したかなど、バージョンツリーに関する情報をサーバーに照会できる必要があります（セッショントラッキング）。
Versioning in the context of the world-wide web offers a variety of benefits:
ワールドワイドウェブのコンテキストでのバージョン管理には、さまざまな利点があります。
It provides infrastructure for efficient and controlled management of large evolving web sites. Modern configuration management systems are built on some form of repository that can track the revision history of individual resources, and provide the higher-level tools to manage those saved versions. Basic versioning capabilities are required to support such systems.
大規模な進化するWebサイトの効率的で管理された管理のためのインフラストラクチャを提供します。最新の構成管理システムは、個々のリソースの変更履歴を追跡し、それらの保存されたバージョンを管理するためのより高レベルのツールを提供できる何らかの形のリポジトリーに基づいて構築されています。このようなシステムをサポートするには、基本的なバージョン管理機能が必要です。
It allows parallel development and update of single resources. Since versioning systems register change by creating new objects, they enable simultaneous write access by allowing the creation of variant versions. Many also provide merge support to ease the reverse operation.
単一のリソースを並行して開発および更新できます。バージョン管理システムは、新しいオブジェクトを作成することによって変更を登録するため、バリアントバージョンの作成を許可することにより、同時書き込みアクセスが可能になります。多くは、逆の操作を容易にするためのマージサポートも提供しています。
It provides a framework for coordinating changes to resources. While specifics vary, most systems provide some method of controlling or tracking access to enable collaborative resource development.
リソースへの変更を調整するためのフレームワークを提供します。詳細は異なりますが、ほとんどのシステムは、共同リソース開発を可能にするためにアクセスを制御または追跡する何らかの方法を提供します。
It allows browsing through past and alternative versions of a resource. Frequently the modification and authorship history of a resource is critical information in itself.
リソースの過去のバージョンと代替バージョンを閲覧できます。多くの場合、リソースの変更と作成者の履歴は、それ自体が重要な情報です。
It provides stable names that can support externally stored links for annotation and link-server support. Both annotation and link servers frequently need to store stable references to portions of resources that are not under their direct control. By providing stable states of resources, version control systems allow not only stable pointers into those resources, but also well-defined methods to determine the relationships of those states of a resource.
注釈とリンクサーバーのサポートのために外部に保存されたリンクをサポートできる安定した名前を提供します。注釈サーバーとリンクサーバーの両方が、直接制御されていないリソースの部分への安定した参照を保存する必要があることがよくあります。リソースの安定した状態を提供することにより、バージョン管理システムは、それらのリソースへの安定したポインターだけでなく、リソースのそれらの状態の関係を決定するための明確に定義されたメソッドも許可します。
It allows explicit semantic representation of single resources with multiple states. A versioning system directly represents the fact that a resource has an explicit history, and a persistent identity across the various states it has had during the course of that history.
複数の状態を持つ単一のリソースを明示的に意味的に表現できます。バージョン管理システムは、リソースに明示的な履歴があり、その履歴の過程でリソースが持っていたさまざまな状態にわたって永続的なIDを持っているという事実を直接表します。
Detailed requirements for variants will be developed in a separate document.
バリアントの詳細な要件は、別のドキュメントで作成されます。
It must be possible to send variants to the server, describing the relationships between the variants and their parent resource. In addition, it must be possible to write and retrieve variants of property labels, property descriptions, and property values.
バリアントとその親リソースの関係を記述したバリアントをサーバーに送信できる必要があります。さらに、プロパティラベル、プロパティの説明、プロパティ値のバリアントを記述および取得できる必要があります。
The HTTP working group is addressing problems of content negotiation and retrieval of variants of a resource. To extend this work to an authoring environment, WEBDAV must standardize mechanisms for authors to use when submitting variants to a server. Authors need to be able to provide variants in different file or document formats, for different uses. They need to provide variants optimized for different clients and for different output devices. They need to be able to provide variants in different languages in the international environment of the Web. In support of internationalization requirements (See 5.12 below), variants need to be supported not just for the content of resources, but for any information intended for human use, such as property values, labels, and descriptions.
HTTPワーキンググループは、コンテンツのネゴシエーションとリソースのバリアントの取得の問題に取り組んでいます。この作業をオーサリング環境に拡張するには、WEBDAVは、バリアントをサーバーに送信するときに作成者が使用するメカニズムを標準化する必要があります。著者は、さまざまな用途のために、さまざまなファイルまたはドキュメント形式でバリアントを提供できる必要があります。彼らは、さまざまなクライアントやさまざまな出力デバイスに最適化されたバリアントを提供する必要があります。彼らは、Webの国際環境でさまざまな言語のバリアントを提供できる必要があります。国際化の要件（5.12を参照）をサポートするには、リソースのコンテンツだけでなく、プロパティ値、ラベル、説明など、人間が使用することを目的とした情報についてもバリアントをサポートする必要があります。
5.11.1. Authentication. The WebDAV specification should state how the WebDAV extensions interoperate with existing authentication schemes, and should make recommendations for using those schemes.
5.11.1. 認証。 WebDAV仕様では、WebDAV拡張が既存の認証スキームとどのように相互運用するかを記述し、それらのスキームの使用に関する推奨事項を作成する必要があります。
5.11.2. Access Control. Access control requirements are specified in a separate access control work in progress [AC].
5.11.2. アクセス制御。アクセス制御要件は、別の進行中のアクセス制御作業[AC]で指定されています。
5.11.3. Interoperability with Security Protocols. The WebDAV specification must provide a minimal list of security protocols which any compliant server / client must support. These protocols should insure the authenticity of messages and the privacy and integrity of messages in transit.
5.11.3. セキュリティプロトコルとの相互運用性。 WebDAV仕様は、準拠するサーバー/クライアントがサポートする必要があるセキュリティプロトコルの最小限のリストを提供する必要があります。これらのプロトコルは、メッセージの信頼性と、転送中のメッセージのプライバシーと整合性を保証する必要があります。
Since Web distributed authoring occurs in a multi-lingual environment, information intended for user comprehension must conform to the IETF Character Set Policy [CHAR]. This policy addresses character sets and encodings, and language tagging.
Web分散オーサリングは多言語環境で行われるため、ユーザーの理解を目的とした情報は、IETF文字セットポリシー[CHAR]に準拠する必要があります。このポリシーは、文字セットとエンコーディング、および言語のタグ付けを扱います。
In the international environment of the Internet, it is important to insure that any information intended for user comprehension can be displayed in a writing system and language agreeable to both the client and the server. The information encompassed by this requirement includes not only the content of resources, but also such things as display names and descriptions of properties, property values, and status messages.
インターネットの国際的な環境では、ユーザーの理解を目的とした情報を、クライアントとサーバーの両方が同意できる書記体系と言語で表示できるようにすることが重要です。この要件に含まれる情報には、リソースのコンテンツだけでなく、プロパティの表示名と説明、プロパティ値、ステータスメッセージなども含まれます。
Our understanding of these issues has emerged as the result of much thoughtful discussion, email, and assistance by many people, who deserve recognition for their effort.
これらの問題に対する私たちの理解は、多くの人々が彼らの努力に認められるに値する多くの人々による多くの思慮深い議論、電子メール、および支援の結果として浮上しています。
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
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.、ロスアラモス国立研究所、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、UC Irvine、fielding @ ics.uci.edu Mark Fisher、Thomson Consumer Electronics、FisherM @ indy.tce.com Yaron Y. Goland、マイクロソフト、yarong @ microsoft.com Phill Hallam-Baker、MIT、hallam @ ai.mit.edu Dennisハミルトン、ゼロックスPARC、hamilton @ parc.xerox.comアンドレファンデルホーク、コロラド大学ボルダー校、andre @ cs.colorado.eduデルイェンセン、ノベル、dcjensen @ novell.comゲイルカイザー、コロンビア大学、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、AL 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ハワードSモデル、ボーイング、howard.s.modell @ boeing.comキースムーア、テネシー大学、ノックスビル、moore @ cs.utk.edu Henrik Frystyk Nielsen、World Wide Web Consortium、frystyk @ w3.orgジョン・ラドフf、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、UC 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
[AC] J. Radoff, "Requirements for Access Control within Distributed
Authoring and Versioning Environments on the World Wide Web",
unpublished manuscript, <http://lists.w3.org/Archives/Public/w3c-
dist-auth/1997AprJun/0183.html>
[CHAR] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, January 1998.
[CHAR] Alvestrand、H。、「IETF Policy on Character Sets and Languages」、RFC 2277、1998年1月。
[CM] P. Feiler, "Configuration Management Models in Commercial
Environments", Software Engineering Institute Technical Report
CMU/SEI-91-TR-7,
<http://www.sei.cmu.edu/products/publications/91.reports/91.tr.007.html>
[HTML] Berners-Lee, T., and D. Connolly, "HyperText Markup Language Specification - 2.0", RFC 1866, November 1995.
[HTML] Berners-Lee、T。、およびD. Connolly、「HyperText Markup Language Specification-2.0」、RFC 1866、1995年11月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[HTTP] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」、RFC 2068、1997年1月。
[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.
[URL] Berners-Lee、T.、Masinter、L。、およびM. McCahill。 「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[VSE] A. Haake, D. Hicks, "VerSE: Towards Hypertext Versioning Styles", Proc. Hypertext'96, The Seventh ACM Conference on Hypertext, 1996, pages 224-234.
[VSE] A. Haake、D。Hicks、「VerSE：Towards Hypertext Versioning Styles」、Proc。 Hypertext'96、Hypertextに関する第7回ACM会議、1996年、224〜234ページ。
Judith Slein Xerox Corporation 800 Phillips Road 128-29E Webster, NY 14580
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
E.ジェームズホワイトヘッド、カリフォルニア州立大学情報およびコンピュータサイエンス学部アーバイン、カリフォルニア州92697-3425
Fax: 714-824-4056 EMail: ejw@ics.uci.edu
ファックス：714-824-4056メール：ejw@ics.uci.edu
David G. Durand Department of Computer Science Boston University Boston, MA
デビッドG.デュランボストン大学ボストン校
EMail: dgd@cs.bu.edu
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。