Internet Engineering Task Force (IETF) C. Daboo
Request for Comments: 6352 Apple
Category: Standards Track August 2011
ISSN: 2070-1721
CardDAV: vCard Extensions to
Web Distributed Authoring and Versioning (WebDAV)
Abstract
抽象
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format.
この文書では、vCard形式に基づいて連絡先情報を、アクセス管理、および共有するための標準的な方法を指定するには、Web分散オーサリングとバージョン管理（WebDAV）プロトコルの拡張機能を定義します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6352.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6352で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements Overview . . . . . . . . . . . . . . . . . . . . 6
4. Address Book Data Model . . . . . . . . . . . . . . . . . . . 7
4.1. Address Book Server . . . . . . . . . . . . . . . . . . . 7
5. Address Book Resources . . . . . . . . . . . . . . . . . . . . 7
5.1. Address Object Resources . . . . . . . . . . . . . . . . . 7
5.1.1. Data Type Conversion . . . . . . . . . . . . . . . . . 8
5.1.1.1. Additional Precondition for GET . . . . . . . . . 8
5.2. Address Book Collections . . . . . . . . . . . . . . . . . 9
6. Address Book Feature . . . . . . . . . . . . . . . . . . . . . 10
6.1. Address Book Support . . . . . . . . . . . . . . . . . . . 10
6.1.1. Example: Using OPTIONS for the Discovery of
Support for CardDAV . . . . . . . . . . . . . . . . . 10
6.2. Address Book Properties . . . . . . . . . . . . . . . . . 10
6.2.1. CARDDAV:addressbook-description Property . . . . . . . 10
6.2.2. CARDDAV:supported-address-data Property . . . . . . . 11
6.2.3. CARDDAV:max-resource-size Property . . . . . . . . . . 12
6.3. Creating Resources . . . . . . . . . . . . . . . . . . . . 13
6.3.1. Extended MKCOL Method . . . . . . . . . . . . . . . . 13
6.3.1.1. Example - Successful MKCOL Request . . . . . . . . 14
6.3.2. Creating Address Object Resources . . . . . . . . . . 15
6.3.2.1. Additional Preconditions for PUT, COPY, and
MOVE . . . . . . . . . . . . . . . . . . . . . . . 16
6.3.2.2. Non-Standard vCard Properties and Parameters . . . 17
6.3.2.3. Address Object Resource Entity Tag . . . . . . . . 18
7. Address Book Access Control . . . . . . . . . . . . . . . . . 18
7.1. Additional Principal Properties . . . . . . . . . . . . . 18
7.1.1. CARDDAV:addressbook-home-set Property . . . . . . . . 19
7.1.2. CARDDAV:principal-address Property . . . . . . . . . . 19
8. Address Book Reports . . . . . . . . . . . . . . . . . . . . . 20
8.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Ordinary Collections . . . . . . . . . . . . . . . . . . . 21
8.3. Searching Text: Collations . . . . . . . . . . . . . . . . 21
8.3.1. CARDDAV:supported-collation-set Property . . . . . . . 22
8.4. Partial Retrieval . . . . . . . . . . . . . . . . . . . . 23
8.5. Non-Standard Properties and Parameters . . . . . . . . . . 23
8.6. CARDDAV:addressbook-query Report . . . . . . . . . . . . . 23
8.6.1. Limiting Results . . . . . . . . . . . . . . . . . . . 25
8.6.2. Truncation of Results . . . . . . . . . . . . . . . . 25
8.6.3. Example: Partial Retrieval of vCards Matching
NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 26
8.6.4. Example: Partial Retrieval of vCards Matching a
Full Name or Email Address . . . . . . . . . . . . . . 27
8.6.5. Example: Truncated Results . . . . . . . . . . . . . . 29
8.7. CARDDAV:addressbook-multiget Report . . . . . . . . . . . 31
8.7.1. Example: CARDDAV:addressbook-multiget Report . . . . . 32
8.7.2. Example: CARDDAV:addressbook-multiget Report . . . . . 33
9. Client Guidelines . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Restrict the Properties Returned . . . . . . . . . . . . . 34
9.2. Avoiding Lost Updates . . . . . . . . . . . . . . . . . . 35
9.3. Client Configuration . . . . . . . . . . . . . . . . . . . 35
9.4. Finding Other Users' Address Books . . . . . . . . . . . . 35
10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 36
10.1. CARDDAV:addressbook XML Element . . . . . . . . . . . . . 36
10.2. CARDDAV:supported-collation XML Element . . . . . . . . . 36
10.3. CARDDAV:addressbook-query XML Element . . . . . . . . . . 37
10.4. CARDDAV:address-data XML Element . . . . . . . . . . . . . 37
10.4.1. CARDDAV:allprop XML Element . . . . . . . . . . . . . 39
10.4.2. CARDDAV:prop XML Element . . . . . . . . . . . . . . . 39
10.5. CARDDAV:filter XML Element . . . . . . . . . . . . . . . . 40
10.5.1. CARDDAV:prop-filter XML Element . . . . . . . . . . . 40
10.5.2. CARDDAV:param-filter XML Element . . . . . . . . . . . 41
10.5.3. CARDDAV:is-not-defined XML Element . . . . . . . . . . 42
10.5.4. CARDDAV:text-match XML Element . . . . . . . . . . . . 42
10.6. CARDDAV:limit XML Element . . . . . . . . . . . . . . . . 43
10.6.1. CARDDAV:nresults XML Element . . . . . . . . . . . . . 44
10.7. CARDDAV:addressbook-multiget XML Element . . . . . . . . . 44
11. Service Discovery via SRV Records . . . . . . . . . . . . . . 45
12. Internationalization Considerations . . . . . . . . . . . . . 45
13. Security Considerations . . . . . . . . . . . . . . . . . . . 45
14. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 46
14.1. Namespace Registration . . . . . . . . . . . . . . . . . . 46
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
16.1. Normative References . . . . . . . . . . . . . . . . . . . 47
16.2. Informative References . . . . . . . . . . . . . . . . . . 48
Address books containing contact information are a key component of personal information management tools, such as email, calendaring and scheduling, and instant messaging clients. To date several protocols have been used for remote access to contact data, including the Lightweight Directory Access Protocol (LDAP) [RFC4510], Internet Message Support Protocol [IMSP], and Application Configuration Access Protocol (ACAP) [RFC2244], together with SyncML used for synchronization of such data.
連絡先情報を含むアドレス帳は、電子メール、カレンダーおよびスケジューリング、およびインスタントメッセージングクライアントなどの個人情報管理ツールの重要なコンポーネントです。これまでにいくつかのプロトコルは、SyncMLのと一緒に、ライトウェイトディレクトリアクセスプロトコル（LDAP）[RFC4510]、インターネットメッセージのサポートプロトコル[IMSP]、およびアプリケーション設定アクセスプロトコル（ACAP）[RFC2244]を含む、データを連絡するリモートアクセスのために使用されていますそのようなデータの同期のために使用。
WebDAV [RFC4918] offers a number of advantages as a framework or basis for address book access and management. Most of these advantages boil down to a significant reduction in the costs of design, implementation, interoperability testing, and deployment.
WebDAVの[RFC4918]は、アドレス帳へのアクセスと管理のためのフレームワークや基礎として多くの利点を提供しています。これらの利点のほとんどは、設計、実装、相互運用性テスト、および展開のコストの大幅な削減に煮詰めます。
The key features of address book support with WebDAV are:
WebDAVを持つアドレス帳のサポートの主な機能は以下のとおりです。
2. Ability to control access to individual address books and address entries as per WebDAV Access Control List (ACL) [RFC3744].
WebDAVのアクセス制御リスト（ACL）[RFC3744]あたりのように、個々のアドレス帳やアドレスエントリへのアクセスを制御する2.能力。
3. Principal collections can be used to enumerate and query other users on the system as per WebDAV ACL [RFC3744].
3.主なコレクションは、WebDAV ACL [RFC3744]に従って、システム上の他のユーザを列挙し、クエリするために使用することができます。
4. Server-side searching of address data, avoiding the need for clients to download an entire address book in order to do a quick address 'expansion' operation.
迅速なアドレス「拡大」操作を行うために全体のアドレス帳をダウンロードするには、クライアントの必要性を回避するアドレスデータの4サーバー側の検索、。
5. Well-defined internationalization support through WebDAV's use of XML.
XMLのWebDAVを使用しての5明確に定義された国際化サポート。
6. Use of vCards [RFC2426] for well-defined address schema to enhance client interoperability.
クライアントの相互運用性を高めるために、明確に定義されたアドレススキーマのためのvCardの6. [RFC2426]。
7. Many limited clients (e.g., mobile devices) contain an HTTP stack that makes implementing WebDAV much easier than other protocols.
7.多くの限られたクライアント（例えば、モバイル・デバイス）他のプロトコルよりもはるかに簡単にWebDAVを実装しますHTTPスタックが含まれています。
The key disadvantage of address book support in WebDAV is:
WebDAVのアドレス帳のサポートの重要な欠点は、次のとおりです。
1. Lack of change notification. Many of the alternative protocols also lack this ability. However, an extension for push notifications could easily be developed.
変更通知の1欠如。代替のプロトコルの多くは、この能力を欠いています。ただし、プッシュ通知のための拡張が容易に開発することができます。
vCard is a MIME directory profile aimed at encapsulating personal addressing and contact information about people. The specification of vCard was originally done by the Versit consortium, with a subsequent 3.0 version standardized by the IETF [RFC2426]. vCard is in widespread use in email clients and mobile devices as a means of encapsulating address information for transport via email or for import/export and synchronization operations.
vCardのは、人々について取り組む個人や連絡先情報をカプセル化を目的としたMIMEディレクトリプロファイルです。 vCardの仕様は、もともとIETF [RFC2426]によって標準化され、その後の3.0バージョンと、Versitコンソーシアムによって行いました。 vCardのは、電子メールを介して、またはインポート/エクスポートと同期の操作のために輸送するためのアドレス情報をカプセル化する手段として、電子メールクライアントやモバイルデバイスで広く使用されています。
An update to vCard -- vCard v4 -- is currently being developed [RFC6350] and is compatible with this specification.
vCardのにアップデート - vCardのV4は - 現在[RFC6350]を開発し、この仕様と互換性のあるされています。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The term "protected" is used in the Conformance field of property definitions as defined in Section 15 of [RFC4918].
[RFC4918]のセクション15で定義されるように「保護」という用語は、プロパティ定義の適合フィールドで使用されています。
This document uses XML DTD fragments ([W3C.REC-xml-20081126], Section 3.2) as a purely notational convention. WebDAV request and response bodies cannot be validated by a DTD due to the specific extensibility rules defined in Section 17 of [RFC4918] and due to the fact that all XML elements defined by that specification use the XML namespace name "DAV:". In particular:
この文書では、純粋な表記規則としてXML DTDフラグメント（[W3C.REC-XML-20081126]、3.2節）を使用しています。 WebDAVの要求と応答体が原因[RFC4918]のセクション17で定義された特定の拡張ルールに起因している仕様で定義されたすべてのXML要素は、XML名前空間名「DAV：」を使用しているという事実にDTDで検証することはできません。特に：
3. Extension elements (elements not already defined as valid child elements) may be added anywhere, except when explicitly stated otherwise.
3.拡張要素（すでに有効な子要素として定義されていない要素が）特に明記する場合を除いて、どこにでも追加することができます。
4. Extension attributes (attributes not already defined as valid for this element) may be added anywhere, except when explicitly stated otherwise.
4.拡張属性が（すでにこの要素に対して有効と定義されていない属性）特に明記する場合を除いて、どこにでも追加することができます。
The namespace "urn:ietf:params:xml:ns:carddav" is reserved for the XML elements defined in this specification, its revisions, and related CardDAV specifications. XML elements defined by individual implementations MUST NOT use the "urn:ietf:params:xml:ns:carddav" namespace, and instead should use a namespace that they control.
名前空間「URN：IETF：のparams：XML：NS：CardDAVのは、」XMLのこの仕様で定義された要素、その改訂版、および関連CardDAVの仕様のために予約されています。名前空間、そして代わりに、彼らはコントロールの名前空間を使用する必要があり、個々の実装によって定義されたXML要素は「：IETF：のparams：XML：：NS CardDAVの壷」を使用してはなりません。
When XML element types in the namespaces "DAV:" and "urn:ietf:params:xml:ns:carddav" are referenced in this document outside of the context of an XML fragment, the strings "DAV:" and "CARDDAV:" will be prefixed to the element types, respectively.
XML要素の名前空間のタイプ「DAV：」および「URN：IETF：paramsは：XML：NS：CardDAVの」はXMLフラグメントのコンテキストの外で、この文書で参照され、文字列「DAV：」および「CardDAVの：」それぞれ、要素タイプに付けられます。
This document inherits, and sometimes extends, DTD productions from Section 14 of [RFC4918].
この文書は、継承、及び時々延び、[RFC4918]のセクション14からDTD制作。
Also, note that some CardDAV XML element names are identical to WebDAV XML element names, though their namespace differs. Care must be taken not to confuse the two sets of names.
また、彼らの名前空間が異なるが、いくつかのCardDAVのXML要素名は、WebDAVのXML要素名と同一であることに注意してください。ケアは、名前の2セットを混同しないように注意しなければなりません。
This section lists what functionality is required of a CardDAV server. To advertise support for CardDAV, a server:
このセクションでは、CardDAVのサーバーで必要とされるものの機能一覧表示されます。 CardDAVの、サーバーのサポートを宣伝するには：
o MUST support vCard v3 [RFC2426] as a media type for the address object resource format;
Oは、アドレスオブジェクトリソース形式のメディアタイプとしてのvCard V3 [RFC2426]をサポートしなければなりません。
o MUST support WebDAV Class 3 [RFC4918];
Oは、WebDAVクラス3 [RFC4918]をサポートしなければなりません。
o MUST support WebDAV ACL [RFC3744];
Oは、WebDAV ACL [RFC3744]をサポートしなければなりません。
o MUST support secure transport as defined in [RFC2818] using Transport Layer Security (TLS) [RFC5246] and using the certificate validation procedures described in [RFC5280];
[RFC2818]で定義されるようにOがトランスポート層セキュリティ（TLS）[RFC5246]を用いて、[RFC5280]に記載の証明書検証の手順を使用してセキュアな転送をサポートしなければなりません。
o MUST support ETags [RFC2616] with additional requirements specified in Section 6.3.2.3 of this document;
Oは、このドキュメントのセクション6.3.2.3で指定された追加要件てETag [RFC2616]をサポートしなければなりません。
o MUST support all address book reports defined in Section 8 of this document; and
oはこのドキュメントのセクション8で定義されているすべてのアドレス帳のレポートをサポートしなければなりません。そして
o MUST advertise support on all address book collections and address object resources for the address book reports in the DAV:supported-report-set property, as defined in Versioning Extensions to WebDAV [RFC3253].
oはDAVでのアドレス帳のレポートのためのすべてのアドレス帳コレクションとアドレスオブジェクトリソースのサポートを公示しなければならない：サポート・レポート・プロパティセットを、WebDAVの[RFC3253]にバージョン管理の拡張機能で定義されています。
In addition, a server:
また、サーバー：
o SHOULD support vCard v4 [RFC6350] as a media type for the address object resource format;
Oは、アドレスオブジェクトリソース形式のメディアタイプとしてのvCard V4 [RFC6350]を支持します。
o SHOULD support the extended MKCOL method [RFC5689] to create address book collections as defined in Section 6.3.1 of this document.
oはこのドキュメントのセクション6.3.1で定義されているアドレス帳のコレクションを作成するには、拡張MKCOLメソッド[RFC5689]をサポートすべきです。
o SHOULD support the DAV:current-user-principal-URL property as defined in [RFC5397] to give clients a fast way to locate user principals.
O DAVをサポートする必要があります。現在のユーザー-元本-URLプロパティをクライアントにユーザープリンシパルを迅速に検索する方法を提供するために、[RFC5397]で定義されています。
As a brief overview, a CardDAV address book is modeled as a WebDAV collection with a well-defined structure; each of these address book collections contains a number of resources representing address objects as their direct child resources. Each resource representing an address object is called an "address object resource". Each address object resource and each address book collection can be individually locked and have individual WebDAV properties. Requirements derived from this model are provided in Sections 5.1 and 5.2.
簡単な概要として、CardDAVのアドレス帳は、明確に定義された構造を持つWebDAVコレクションとしてモデル化されます。これらのアドレス帳のコレクションのそれぞれは、その直接の子リソースとしてアドレスオブジェクトを表すリソースの数が含まれています。アドレスオブジェクトを表す各リソースは、「アドレスオブジェクトリソース」と呼ばれています。各アドレスオブジェクトリソースとそれぞれのアドレス帳のコレクションは、個別にロックされ、個々のWebDAVプロパティを持つことができます。このモデルから派生要件は、セクション5.1と5.2で提供されています。
A CardDAV server is an address-aware engine combined with a WebDAV server. The server may include address data in some parts of its URL namespace and non-address data in other parts.
CardDAVのサーバーは、WebDAVサーバーと組み合わせたアドレス認識エンジンです。サーバーは、他の部分でそのURL名前空間と非アドレスデータの一部のアドレスデータを含むことができます。
A WebDAV server can advertise itself as a CardDAV server if it supports the functionality defined in this specification at any point within the root of its repository. That might mean that address data is spread throughout the repository and mixed with non-address data in nearby collections (e.g., address data may be found in /lisa/ addressbook/ as well as in /bernard/addressbook/, and non-address data in /lisa/calendars/). Or, it might mean that address data can be found only in certain sections of the repository (e.g., /addressbooks/user/). Address book features are only required in the repository sections that are or contain address objects. So, a repository confining address data to the /carddav/ collection would only need to support the CardDAV required features within that collection.
それはそのリポジトリのルート内の任意の点で、この仕様で定義された機能をサポートしている場合、WebDAVサーバーには、CardDAVのサーバとしての地位を宣伝することができます。それは例えば、アドレスデータが/リサに/アドレス帳/など/バーナード/アドレス帳/、および非アドレスデータで見ることができる（そのアドレスのデータは近くのコレクションに非アドレスデータとリポジトリと混合全体に広がっている意味するかもしれません中/リサ/カレンダー/）。または、それは（例えば、/アドレス帳/ユーザ/）アドレスデータのみリポジトリの特定のセクションに見出すことができることを意味するかもしれません。アドレス帳機能だけであるかのアドレスオブジェクトが含まれているリポジトリのセクションで必要とされています。だから、/ CardDAVの/コレクションにアドレスデータを閉じ込めるリポジトリにのみ、そのコレクション内CardDAVのに必要な機能をサポートする必要があります。
The CardDAV server is the canonical location for address data and state information. Clients may submit requests to change data or download data. Clients may store address objects offline and attempt to synchronize at a later time. Address data on the server can change between the time of last synchronization and when attempting an update, as address book collections may be shared and accessible via multiple clients. Entity tags and locking help this work.
CardDAVのサーバは、アドレス、データ及び状態情報の正規の位置です。クライアントは、データを変更したり、データをダウンロードする要求を提出することができます。クライアントは、オフラインアドレスオブジェクトを格納し、後で同期しようとすることができます。アドレス帳のコレクションを共有し、複数のクライアントを介してアクセスすることができるように、サーバー上のアドレスデータは、更新をしようと最後の同期の時間とするときの間で変更することができます。エンティティタグとロックのヘルプこの作品。
This specification uses vCard as the default format for address or contact information being stored on the server. However, this specification does allow other formats for address data provided that the server advertises support for those additional formats as described below. The requirements in this section pertain to vCard address data or formats that follow the semantics of vCard data.
この仕様は、サーバー上に保存されているアドレスや連絡先情報のデフォルトの形式としてのvCardを使用しています。しかしながら、この仕様は、以下に説明するように、サーバはそれらの追加のフォーマットのサポートをアドバタイズすることを提供されたアドレスデータの他のフォーマットを許可し。このセクションの要件は、vCardデータの意味をたどるvCardのアドレスデータやフォーマットに関係します。
Address object resources contained in address book collections MUST contain a single vCard component only.
アドレス帳のコレクションに含まれるAddressオブジェクトのリソースは、単一のvCardの構成要素を含まなければなりません。
vCard components in an address book collection MUST have a UID property value that MUST be unique in the scope of the address book collection in which it is contained.
アドレス帳コレクション内のvCardのコンポーネントは、それが含まれるアドレス帳コレクションの範囲内で一意である必要がありUIDプロパティの値を持つ必要があります。
Servers might support more than one primary media type for address object resources, for example, vCard v3.0 and vCard v4.0. In such cases, servers have to accept all media types that they advertise via the CARDDAV:supported-address-data WebDAV property (see Section 6.2.2).
サーバは、例えば、vCardのバージョン3.0とのvCard V4.0をアドレスオブジェクトリソースの複数のプライマリメディアタイプをサポートする場合があります。サポートされるアドレスデータのWebDAVプロパティ（6.2.2項を参照してください）：このような場合には、サーバーは、CardDAVの経由宣伝すべてのメディアタイプを受け入れなければなりません。
However, clients can use standard HTTP content negotiation behavior (the Accept request header defined in Section 14.1 of [RFC2616]) to request that an address object resource's data be returned in a specific media type format. For example, a client merely capable of handling vCard v3.0 would only want to have address object resources returned in v3.0 format.
しかし、クライアントは、アドレスオブジェクトリソースのデータが特定のメディアタイプのフォーマットで戻されることを要求するために、標準的なHTTPコンテンツネゴシエーション動作（[RFC2616]のセクション14.1で定義された受け入れ要求ヘッダ）を使用することができます。たとえば、vCardのバージョン3.0を処理するだけでできるクライアントは、V3.0形式で返されたアドレスオブジェクトのリソースを持っているしたいと思います。
Additionally, REPORT requests, defined later in this specification, allow for the return of address object resource data within an XML response body. Again, the client can use content negotiation to request that data be returned in a specific media type by specifying appropriate attributes on the CARDDAV:address-data XML element used in the request body (see Section 10.4).
また、この仕様で定義された後のREPORT要求は、XMLレスポンスボディ内のアドレスオブジェクトリソースデータの復帰を可能にします。ここでも、クライアントは、データがCardDAVのに適切な属性を指定することで、特定のメディアタイプに返されることを要求するコンテンツネゴシエーションを使用することができますリクエストボディに使用されるアドレス・データXML要素（項10.4を参照してください）。
In some cases, it might not be possible for a server to convert from one media type to another. When that happens, the server MUST return the CARDDAV:supported-address-data-conversion precondition (see below) in the response body (when the failure to convert applies to the entire response) or use that same precondition code in the DAV:response XML element in the response for the targeted address object resource when one of the REPORTs defined below is used. See Section 8.7.2 for an example of this.
サーバーを別のメディアタイプから変換することのためにいくつかのケースでは、それができない場合があります。そのような場合、サーバは、CardDAVの返さなければならない：応答体に支持されたアドレスデータ変換前提条件（下記参照）（変換の失敗が全体の応答に適用される場合）、またはDAVで同じ前提条件コード使用：応答以下に定義されたレポートのいずれかが使用されているターゲットアドレスオブジェクトリソースの応答のXML要素。この例については、セクション8.7.2を参照してください。
This specification creates additional preconditions for the GET method.
この仕様は、GETメソッドの追加の前提条件を作成します。
The new precondition is:
新しい前提条件は次のとおりです。
(CARDDAV:supported-address-data-conversion): The resource targeted by the GET request can be converted to the media type specified in the Accept request header included with the request.
（CardDAVの：サポートされているアドレスデータ変換）：GET要求によって標的リソースが要求に含まれて受け入れ要求ヘッダーで指定されたメディア・タイプに変換することができます。
Address book collections appear to clients as a WebDAV collection resource, identified by a URL. An address book collection MUST report the DAV:collection and CARDDAV:addressbook XML elements in the value of the DAV:resourcetype property. The element type declaration for CARDDAV:addressbook is:
アドレス帳のコレクションは、URLで識別されるWebDAVコレクションのリソースとしてクライアントに表示されます。アドレス帳のコレクションは、DAVを報告しなければなりません：コレクションとCardDAVの：アドレス帳XML要素をDAVの値に：resourcetypeのプロパティを。 CardDAVのための要素型宣言：アドレス帳は、次のとおりです。
<!ELEMENT addressbook EMPTY>
<！ELEMENTのアドレス帳EMPTY>
An address book collection can be created through provisioning (e.g., automatically created when a user's account is provisioned), or it can be created with the extended MKCOL method (see Section 6.3.1). This can be used by a user to create additional address books (e.g., "soccer team members") or for users to share an address book (e.g., "sales team contacts"). However, note that this document doesn't define what extra address book collections are for. Users must rely on non-standard cues to find out what an address book collection is for, or use the CARDDAV:addressbook-description property defined in Section 6.2.1 to provide such a cue.
アドレス帳のコレクションは、（ユーザーのアカウントがプロビジョニングされるとき、例えば、自動的に作成）プロビジョニングによって作成することができ、またはそれは、拡張MKCOLメソッドを使用して作成することができます（6.3.1項を参照してください）。これは、追加のアドレス帳を作成するためにユーザが使用することができます（例えば、「サッカーチームのメンバー」）ユーザーがアドレス帳を共有するか（例えば、「営業チームの連絡先」）。しかし、この文書は、余分なアドレス帳のコレクションはのためにあるものを定義していないことに注意してください。ユーザーは、アドレス帳のコレクションが何のためにあるのかを調べるために、非標準的手がかりに依存している、またはCardDAVのを使用する必要があります。セクション6.2.1で定義されているアドレス帳-descriptionプロパティには、このような手がかりを提供します。
The following restrictions are applied to the resources within an address book collection:
次のような制限は、アドレス帳のコレクション内のリソースに適用されます。
a. Address book collections MUST only contain address object resources and collections that are not address book collections. That is, the only "top-level" non-collection resources allowed in an address book collection are address object resources. This ensures that address book clients do not have to deal with non-address data in an address book collection, though they do have to distinguish between address object resources and collections when using standard WebDAV techniques to examine the contents of a collection.
A。アドレス帳のコレクションは蔵書に対処されていないアドレスオブジェクトのリソースやコレクションを含まなければなりません。これは、アドレス帳コレクションに許される唯一の「トップレベル」は、非コレクションリソースはアドレスオブジェクトの資源である、です。これは、彼らがコレクションの内容を検討するために、標準のWebDAV技術を使用したときにアドレスオブジェクトのリソースやコレクションを区別する必要がないにもかかわらず、アドレス帳クライアントは、アドレス帳コレクションに非アドレスデータに対処する必要がないことを保証します。
b. Collections contained in address book collections MUST NOT contain address book collections at any depth. That is, "nesting" of address book collections within other address book collections at any depth is not allowed. This specification does not define how collections contained in an address book collection are used or how they relate to any address object resources contained in the address book collection.
B。アドレス帳のコレクションに含まれているコレクションは、任意の深さでのアドレス帳のコレクションを含めることはできません。それは許可されていない任意の深さで他のアドレス帳コレクション内のアドレス帳コレクションの「ネスト」、です。この仕様は、アドレス帳コレクションに含まれているコレクションが使用されている方法を定義していないか、彼らは、アドレス帳コレクションに含まれる任意のアドレスオブジェクトのリソースにどのように関係しますか。
Multiple address book collections MAY be children of the same collection.
複数のアドレス帳のコレクションは、同じコレクションの子かもしれ。
A server supporting the features described in this document MUST include "addressbook" as a field in the DAV response header from an OPTIONS request on any resource that supports any address book properties, reports, or methods. A value of "addressbook" in the DAV response header MUST indicate that the server supports all MUST level requirements and REQUIRED features specified in this document.
この文書で説明する機能をサポートしているサーバーは、任意のアドレス帳のプロパティ、レポート、またはメソッドをサポートしているすべてのリソース上のOPTIONS要求からのDAV応答ヘッダ内のフィールドとして「アドレス帳」を含まなければなりません。 DAVレスポンスヘッダ内の「アドレス帳」の値は、サーバがすべてのMUSTレベルの要件と、この文書で指定された必要な機能をサポートしていることを示す必要があります。
>> Request <<
>>リクエスト<<
OPTIONS /addressbooks/users/ HTTP/1.1 Host: addressbook.example.com
OPTIONS /アドレス帳/ユーザー/ HTTP / 1.1ホスト：addressbook.example.com
>> Response <<
>>回答<<
HTTP/1.1 200 OK Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL DAV: 1, 2, 3, access-control, addressbook DAV: extended-mkcol Date: Sat, 11 Nov 2006 09:32:12 GMT Content-Length: 0
HTTP / 1.1 200 OKを許可：OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、COPY、MOVEを許可：MKCOL、PROPFIND、PROPPATCH、LOCKを、UNLOCK、REPORT、ACL DAV：1、2、3、アクセス制御を、アドレス帳のDAV：拡張MKCOL日：土、2006年11月11日九時32分12秒GMTのコンテンツの長さ：0
In this example, the OPTIONS response indicates that the server supports CardDAV in this namespace; therefore, the '/addressbooks/ users/' collection may be used as a parent for address book collections as the extended MKCOL method is available and as a possible target for REPORT requests for address book reports.
この例では、OPTIONS応答は、サーバがこの名前空間にCardDAVのをサポートしていることを示します。そのため、「/アドレス帳/ユーザー/」コレクションは、拡張MKCOLメソッドが利用可能であるように、アドレス帳のコレクションの親として使用することができ、アドレス帳のレポートのレポート要求のための可能なターゲットとして。
Name: addressbook-description
名前：アドレス帳-説明
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Provides a human-readable description of the address book collection.
目的：アドレス帳コレクションの人間が読める記述を提供します。
Value: Any text.
値：任意のテキスト。
Protected: SHOULD NOT be protected so that users can specify a description.
保護：ユーザーが説明を指定することができるように保護されるべきではありません。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
COPY / MOVEの振舞い：このプロパティの値は、COPYとMOVE操作で保存されるべき。
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop request.
allprop動作は：allprop要求：PROPFINDのDAVによって返されるべきではありません。
Description: This property contains a description of the address book collection that is suitable for presentation to a user. The xml:lang attribute can be used to add a language tag for the value of this property.
説明：このプロパティは、ユーザーへの表示に適しているアドレス帳のコレクションの記述が含まれています。 XML：lang属性は、このプロパティの値の言語タグを追加するために使用することができます。
Definition:
定義：
<!ELEMENT addressbook-description (#PCDATA)>
<!-- PCDATA value: string -->
Example:
例：
<C:addressbook-description xml:lang="fr-CA"
xmlns:C="urn:ietf:params:xml:ns:carddav"
>Adresses de Oliver Daboo</C:addressbook-description>
Name: supported-address-data
名前：サポートされているアドレスデータ
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Specifies what media types are allowed for address object resources in an address book collection.
目的：メディアの種類は、アドレス帳コレクションにアドレスオブジェクトのリソースに対して許可されているものを指定します。
Protected: MUST be protected as it indicates the level of support provided by the server.
保護された：それは、サーバによって提供されるサポートのレベルを示すように保護しなければなりません。
COPY/MOVE behavior: This property value MUST be preserved in COPY and MOVE operations.
COPY / MOVE動作：このプロパティの値は、COPYとMOVE操作で保存されなければなりません。
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop request.
allprop動作は：allprop要求：PROPFINDのDAVによって返されるべきではありません。
Description: The CARDDAV:supported-address-data property is used to specify the media type supported for the address object resources contained in a given address book collection (e.g., vCard version
説明：CardDAVの：サポートされているアドレスデータプロパティが指定されたアドレス帳コレクションに含まれるアドレス・オブジェクト・リソースに対してサポートされるメディアタイプを指定するために使用されている（例えば、vCardのバージョン
3.0). Any attempt by the client to store address object resources with a media type not listed in this property MUST result in an error, with the CARDDAV:supported-address-data precondition (Section 6.3.2.1) being violated. In the absence of this property, the server MUST only accept data with the media type "text/vcard" and vCard version 3.0, and clients can assume that is all the server will accept.
3.0）。 CardDAVのではなく、エラーをもたらさなければなりません。このプロパティに記載されているメディアの種類とアドレスオブジェクトのリソースを格納するためのクライアントによるどんな試み：サポートされているアドレスデータの前提条件（6.3.2.1項）が侵害さ。このプロパティが存在しない場合には、サーバが唯一の「テキスト/ vCardの」メディアタイプを使用してデータを受け入れ、vCardのバージョン3.0、およびクライアントは、それがすべてのサーバーが受け入れるであると仮定することができなければなりません。
Definition:
定義：
<!ELEMENT supported-address-data (address-data-type+)>
<！ELEMENTサポートアドレスデータ（アドレス・データ・タイプ）>
<!ELEMENT address-data-type EMPTY> <!ATTLIST address-data-type content-type CDATA "text/vcard" version CDATA "3.0"> <!-- content-type value: a MIME media type --> <!-- version value: a version string -->
<！ELEMENTアドレス・データ型EMPTY> <！ATTLISTアドレス・データ型コンテンツ型CDATA「テキスト/ vCardの」バージョンCDATA「3.0」> <！ - コンテンツ・タイプ値：MIMEメディアタイプ - > < ！ - バージョン値：バージョン文字列 - >
Example:
例：
<C:supported-address-data
xmlns:C="urn:ietf:params:xml:ns:carddav">
<C:address-data-type content-type="text/vcard" version="3.0"/>
</C:supported-address-data>
Name: max-resource-size
名前：MAX-リソースサイズ
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Provides a numeric value indicating the maximum size in octets of a resource that the server is willing to accept when an address object resource is stored in an address book collection.
目的：アドレスオブジェクトのリソースがアドレス帳コレクションに格納されている場合、サーバーが受け入れて喜んでリソースのオクテットの最大サイズを示す数値を提供します。
Value: Any text representing a numeric value.
値：数値を表す任意のテキスト。
Protected: MUST be protected as it indicates limits provided by the server.
保護された：それは、サーバが提供する限界を示して保護しなければなりません。
COPY/MOVE behavior: This property value MUST be preserved in COPY and MOVE operations.
COPY / MOVE動作：このプロパティの値は、COPYとMOVE操作で保存されなければなりません。
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop request.
allprop動作は：allprop要求：PROPFINDのDAVによって返されるべきではありません。
Description: The CARDDAV:max-resource-size is used to specify a numeric value that represents the maximum size in octets that the server is willing to accept when an address object resource is stored in an address book collection. Any attempt to store an address book object resource exceeding this size MUST result in an error, with the CARDDAV:max-resource-size precondition (Section 6.3.2.1) being violated. In the absence of this property, the client can assume that the server will allow storing a resource of any reasonable size.
説明：CardDAVの：MAX-リソースサイズは、アドレスオブジェクトのリソースがアドレス帳コレクションに格納されている場合、サーバが受け入れる意志があるオクテットの最大サイズを表す数値を指定するために使用されます。このサイズを超えるアドレス帳オブジェクトのリソースを保存しようとすると、CardDAVので、エラーをもたらさなければなりません：MAX-リソースサイズの前提条件（6.3.2.1項）が侵害さ。このプロパティがない場合には、クライアントは、サーバが合理的なサイズのリソースを格納できるようになると仮定することができます。
Definition:
定義：
<!ELEMENT max-resource-size (#PCDATA)>
<!-- PCDATA value: a numeric value (positive decimal integer) -->
Example:
例：
<C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:carddav"
>102400</C:max-resource-size>
Address book collections and address object resources may be created by either a CardDAV client or the CardDAV server. This specification defines restrictions and a data model that both clients and servers MUST adhere to when manipulating such address data.
アドレス帳コレクションとアドレスオブジェクトのリソースは、CardDAVのクライアントまたはCardDAVのサーバーのいずれかによって作成することができます。この仕様は、制限やクライアントとサーバの両方が、このようなアドレスデータを操作する際に順守しなければならないデータモデルを定義します。
An HTTP request using the extended MKCOL method [RFC5689] can be used to create a new address book collection resource. A server MAY restrict address book collection creation to particular collections.
拡張MKCOLメソッド[RFC5689]を使用してHTTPリクエストは、新しいアドレス帳コレクションリソースを作成するために使用することができます。サーバーは、特定のコレクションにアドレス帳のコレクションの作成を制限することができます。
To create an address book, the client sends an extended MKCOL request to the server and in the body of the request sets the DAV:resourcetype property to the resource type for an address book collection as defined in Section 5.2.
アドレス帳を作成するには、クライアントがサーバーに拡張MKCOL要求を送信し、要求の本体にDAV設定：5.2節で定義されているアドレス帳の収集のためのリソースタイプにresourcetypeのプロパティを。
Support for creating address books on the server is only RECOMMENDED and not REQUIRED because some address book stores only support one address book per user (or principal), and those are typically pre-created for each account. However, servers and clients are strongly encouraged to support address book creation whenever possible to allow users to create multiple address book collections to help organize their data better.
サーバー上のアドレス帳を作成するためのサポートは唯一の推奨や、一部のアドレス帳ストアはユーザーのみ（またはプリンシパル）ごとに1つのアドレス帳をサポートしているため必須ではありません、そして、それらは、典型的には、各アカウントに対して事前に作成されています。ただし、サーバーとクライアントは強く、可能な限り、ユーザーはより自分のデータを整理するために、複数のアドレス帳のコレクションを作成できるようにするために、アドレス帳の作成をサポートすることをお勧めします。
The DAV:displayname property can be used for a human-readable name of the address book. Clients can either specify the value of the DAV:displayname property in the request body of the extended MKCOL request or, alternatively, issue a PROPPATCH request to change the DAV:displayname property to the appropriate value immediately after using the extended MKCOL request. When displaying address book collections to users, clients SHOULD check the DAV:displayname property and use that value as the name of the address book. In the event that the DAV:displayname property is not set, the client MAY use the last part of the address book collection URI as the name; however, that path segment may be "opaque" and not represent any meaningful human-readable text.
DAV：displaynameはプロパティは、アドレス帳の人間可読な名前のために使用することができます。問題DAV変更するPROPPATCH要求、あるいは、拡張MKCOLリクエストのリクエストボディでのDisplayNameプロパティまたは：すぐに拡張MKCOL要求を使用した後、適切な値にDisplayNameにプロパティをクライアントは、DAVの値を指定することができます。 DisplayNameプロパティをし、アドレス帳の名前としてその値を使用：ユーザーにアドレス帳のコレクションを表示する場合、クライアントは、DAVをチェックする必要があります。 DAVた場合に：DisplayNameにプロパティが設定されていない、クライアントは名前とアドレス帳コレクションURIの最後の部分を使用することができます。しかし、そのパスセグメントは、「不透明」であると意味のある人間可読テキストを表していてもよいです。
This example creates an address book collection called /home/lisa/ addressbook/ on the server addressbook.example.com with specific values for the properties DAV:resourcetype, DAV:displayname, and CARDDAV:addressbook-description.
resourcetypeの、DAV：表示名、およびCardDAVの：アドレス帳-説明この例では、プロパティDAVのための具体的な値でアドレス帳/ホームと呼ばれるコレクション/リサ/アドレス帳/サーバー上のaddressbook.example.comを作成します。
>> Request <<
>>リクエスト<<
MKCOL /home/lisa/addressbook/ HTTP/1.1 Host: addressbook.example.com Content-Type: text/xml; charset="utf-8" Content-Length: xxx
MKCOL /ホーム/リサ/アドレス帳/ HTTP / 1.1ホスト：addressbook.example.comのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX
<?xml version="1.0" encoding="utf-8" ?> <D:mkcol xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"> <D:set> <D:prop> <D:resourcetype> <D:collection/> <C:addressbook/> </D:resourcetype> <D:displayname>Lisa's Contacts</D:displayname> <C:addressbook-description xml:lang="en" >My primary address book.</C:addressbook-description> </D:prop> </D:set> </D:mkcol>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：MKCOL用のxmlns：D = "DAV：" のxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの"> <D：設定> <D：小道具> <D：resourcetypeの> <D：コレクション/> <C：アドレス帳/> </ D：resourcetypeの> <D：のDisplayName>リサの連絡先</ D：表示名> <C：アドレス帳-説明XML ：LANG = "EN">マイプライマリアドレス帳</ C：アドレス帳-記述> </ D：小道具> </ D：セット> </ D：MKCOL>
>> Response <<
>>回答<<
HTTP/1.1 201 Created Cache-Control: no-cache Date: Sat, 11 Nov 2006 09:32:12 GMT Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 201作成されたのCache-Control：キャッシュなし日付：土、2006年11月11日午前9時32分12秒GMTのコンテンツタイプ：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:mkcol-response xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"> <D:propstat> <D:prop> <D:resourcetype/> <D:displayname/> <C:addressbook-description/> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:mkcol-response>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：MKCOL応答のxmlns：D = "DAV：" のxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの"> < D：propstat> <D：プロペラ> <D：resourcetypeの/> <D：表示名/> <C：アドレス帳記述/> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：MKCOL応答>
Clients populate address book collections with address object resources. The URL for each address object resource is entirely arbitrary and does not need to bear a specific relationship (but might) to the address object resource's vCard properties or other metadata. New address object resources MUST be created with a PUT request targeted at an unmapped URI. A PUT request targeted at a mapped URI updates an existing address object resource.
クライアントはアドレスオブジェクトリソースとアドレス帳のコレクションを移入します。各アドレスオブジェクトリソースのURLは、アドレスオブジェクトリソースのvCardのプロパティまたは他のメタデータに完全に任意であり、特定の関係を負担する必要はありません（ただし、可能性があります）。新しいアドレスオブジェクトリソースがマップされていないURIをターゲットにPUTリクエストを作成する必要があります。マッピングされたURIを対象とPUTリクエストは既存のアドレスオブジェクトのリソースを更新します。
When servers create new resources, it's not hard for the server to choose a unique URL. It's slightly tougher for clients, because a client might not want to examine all resources in the collection and might not want to lock the entire collection to ensure that a new one isn't created with a name collision. However, there is an HTTP feature to mitigate this. If the client intends to create a new address resource, the client SHOULD use the HTTP header "If-None-Match: *" on the PUT request. The Request-URI on the PUT request MUST include the target collection, where the resource is to be created, plus the name of the resource in the last path segment. The "If-None-Match" header ensures that the client will not inadvertently overwrite an existing resource even if the last path segment turned out to already be used.
サーバーは、新しいリソースを作成すると、サーバがユニークなURLを選択するために、それは難しいことではありません。クライアントは、コレクション内のすべてのリソースを検討したくない場合がありますし、新しいものが名前の衝突を使用して作成されていないことを確認するために、コレクション全体をロックしたくない場合がありますので、それは、クライアントのために少し厳しいです。しかし、これを緩和するためにHTTPの機能があります。クライアントが新しいアドレスリソースを作成しようとする場合、「場合 - なし - マッチ：*」、クライアントは、HTTPヘッダーを使用すべきであるPUT要求に。 PUTリクエストのRequest-URIがリソースが作成されるターゲット・コレクション、プラス最後のパスセグメント内のリソースの名前を含まなければなりません。 「もし-なしマッチ」ヘッダは、クライアントが誤って最後のパスセグメントが既に使用されることが判明した場合でも、既存のリソースを上書きしないことが保証されます。
>> Request <<
>>リクエスト<<
PUT /lisa/addressbook/newvcard.vcf HTTP/1.1 If-None-Match: * Host: addressbook.example.com Content-Type: text/vcard Content-Length: xxx
PUT /lisa/addressbook/newvcard.vcf HTTP / 1.1の場合 - なし - マッチ：*ホスト：addressbook.example.comのContent-Type：テキスト/のvCardのContent-Length：XXX
BEGIN:VCARD VERSION:3.0 FN:Cyrus Daboo N:Daboo;Cyrus ADR;TYPE=POSTAL:;2822 Email HQ;Suite 2821;RFCVille;PA;15213;USA EMAIL;TYPE=INTERNET,PREF:cyrus@example.com NICKNAME:me NOTE:Example VCard. ORG:Self Employed TEL;TYPE=WORK,VOICE:412 605 0499 TEL;TYPE=FAX:412 605 0705 URL:http://www.example.com UID:1234-5678-9000-1 END:VCARD
BEGIN：VCARDバージョン：3.0 FN：サイラスDaboo N：Daboo;サイラスADR; TYPE = POSTAL：; 2822メールHQ;スイート2821; RFCVille; PA; 15213;米国EMAIL; TYPE = INTERNET、PREF：cyrus@example.com NICKNAME ：私注：例電子名刺を。 ORG：自営業TEL; TYPE = WORK、VOICE：412 605 0499 TEL; TYPE = FAX：412 605 0705 URL：のhttp：//www.example.com UID：1234-5678-9000-1 END：VCARD
>> Response <<
>>回答<<
HTTP/1.1 201 Created Date: Thu, 02 Sep 2004 16:53:32 GMT Content-Length: 0 ETag: "123456789-000-111"
HTTP / 1.1 201作成日：木、2004年9月2日16時53分32秒GMTのコンテンツ長：0のETag： "123456789-000-111"
The request to change an existing address object resource without overwriting a change made on the server uses a specific ETag in an "If-Match" header, rather than the "If-None-Match" header.
サーバー上で行われた変更を上書きすることなく、既存のアドレスオブジェクトのリソースを変更する要求は、むしろ、「もし-なしマッチ」ヘッダよりも、「もしマッチ」ヘッダに特定のETagを使用しています。
File names for vCards are commonly suffixed by ".vcf", and clients may choose to use the same convention for URLs.
vCardのためのファイル名は、一般に、「の.vcf」サフィックスされ、そしてクライアントがURLの同じ規則を使用することもできます。
This specification creates additional preconditions for the PUT, COPY, and MOVE methods. These preconditions apply:
この仕様は、PUT、COPY、MOVEおよびメソッドの追加の前提条件を作成します。これらの前提条件が適用されます。
o When a PUT operation of an address object resource into an address book collection occurs.
Oアドレス帳コレクションにアドレスオブジェクトリソースのPUT操作が発生した場合。
o When a COPY or MOVE operation of an address object resource into an address book collection occurs.
Oアドレス帳コレクションにアドレスオブジェクトリソースのコピーまたは移動操作が発生した場合。
The new preconditions are:
新しい前提条件は以下のとおりです。
(CARDDAV:supported-address-data): The resource submitted in the PUT request, or targeted by a COPY or MOVE request, MUST be a supported media type (i.e., vCard) for address object resources.
（CardDAVの：サポートされているアドレスデータ）：PUT要求で提出リソース、またはコピーまたは移動要求によって標的は、アドレスオブジェクトリソースのサポートされるメディアタイプ（すなわち、vCardの）でなければなりません。
(CARDDAV:valid-address-data): The resource submitted in the PUT request, or targeted by a COPY or MOVE request, MUST be valid data for the media type being specified (i.e., MUST contain valid vCard data).
（CardDAVの：有効アドレスデータ）：コピーまたは移動要求によってPUT要求で提出、またはターゲットリソースは、指定されたメディアタイプのための有効なデータ（すなわち、有効なvCardデータを含まなければなりません）でなければなりません。
(CARDDAV:no-uid-conflict): The resource submitted in the PUT request, or targeted by a COPY or MOVE request, MUST NOT specify a vCard UID property value already in use in the targeted address book collection or overwrite an existing address object resource with one that has a different UID property value. Servers SHOULD report the URL of the resource that is already making use of the same UID property value in the DAV:href element.
（CardDAVの：無UID-紛争）：PUT要求で提出、リソース、またはCOPYまたはMOVE要求の対象となるには、対象アドレス帳のコレクションですでに使用vCardのUIDプロパティの値を指定するか、既存のアドレスオブジェクトを上書きしてはなりません異なるUIDのプロパティ値を持つものとリソース。 HREF要素：サーバはすでにDAVで同じUIDプロパティの値を利用しているリソースのURLを報告する必要があります。
<!ELEMENT no-uid-conflict (DAV:href)>
<！ELEMENT無UID-紛争（DAV：HREF）>
(CARDDAV:addressbook-collection-location-ok): In a COPY or MOVE request, when the Request-URI is an address book collection, the URI targeted by the Destination HTTP Request header MUST identify a location where an address book collection can be created.
（CardDAVの：アドレス帳捕集場所-OK）のRequest-URIは、アドレス帳のコレクションである場合コピーまたは移動要求で、宛先HTTPリクエストヘッダによってターゲットURIは、アドレス帳コレクションができる場所を識別しなければなりません作成した。
(CARDDAV:max-resource-size): The resource submitted in the PUT request, or targeted by a COPY or MOVE request, MUST have a size in octets less than or equal to the value of the CARDDAV:max-resource-size property value (Section 6.2.3) on the address book collection where the resource will be stored.
（CardDAVの：MAX-リソースサイズ）：MAX-リソースサイズプロパティ：コピーまたは移動要求によってPUT要求で提出、またはターゲットリソースは、以下のCardDAVの値に等しいオクテットのサイズを有するMUST値リソースが格納されるアドレス帳コレクション上（6.2.3項）。
vCard provides a "standard mechanism for doing non-standard things". This extension support allows implementers to make use of non-standard vCard properties and parameters whose names are prefixed with the text "X-".
vCardのは「非標準的な物事を行うための標準的なメカニズム」を提供します。この拡張サポートは、実装者は、非標準のvCardのプロパティと名前テキスト「X-」で始まるされているパラメータを利用することができます。
Servers MUST support the use of non-standard properties and parameters in address object resources stored via the PUT method.
サーバーは、PUTメソッドを介して格納されている非標準プロパティおよびアドレスオブジェクトリソースのパラメータの使用をサポートしなければなりません。
Servers may need to enforce rules for their own "private" properties or parameters, so servers MAY reject any attempt by the client to change those or use values for those outside of any restrictions the server may have. A server SHOULD ensure that any "private" properties or parameters it uses follow the convention of including a vendor ID in the "X-" name, as described in Section 3.8 of [RFC2426], e.g., "X-ABC-PRIVATE".
サーバはこれらを変更したり、サーバーが持つかもしれない制限のものを外の値を使用するようにクライアントによるいかなる試みを拒否するかもしれないので、サーバーは、自分自身の「プライベート」の特性やパラメータのための規則を施行する必要があるかもしれません。サーバは、セクション3.8で説明したように、使用する任意の「プライベート」特性またはパラメータは、「X-」名でベンダーIDなどの慣例に従うことを保証しなければならない[RFC2426]、例えば、「X-ABC-PRIVATE」。
The DAV:getetag property MUST be defined and set to a strong entity tag on all address object resources.
DAV：getetagプロパティが定義され、すべてのアドレスオブジェクトのリソースに強いエンティティタグを設定しなければなりません。
A response to a GET request targeted at an address object resource MUST contain an ETag response header field indicating the current value of the strong entity tag of the address object resource.
アドレス・オブジェクト・リソースをターゲットGET要求に対する応答は、アドレスオブジェクトリソースの強いエンティティタグの現在の値を示すのETagレスポンスヘッダフィールドを含まなければなりません。
Servers SHOULD return a strong entity tag (ETag header) in a PUT response when the stored address object resource is equivalent by octet equality to the address object resource submitted in the body of the PUT request. This allows clients to reliably use the returned strong entity tag for data synchronization purposes. For instance, the client can do a PROPFIND request on the stored address object resource, have the DAV:getetag property returned, compare that value with the strong entity tag it received on the PUT response, and know that if they are equal, then the address object resource on the server has not been changed.
格納されたアドレスオブジェクトリソースがPUTリクエストのボディで送信アドレスオブジェクトリソースへオクテット等式によって同等である場合、サーバは、PUT応答に強いエンティティタグ（ETagヘッダ）を返すべきです。これは、クライアントが確実にデータ同期目的のために返さ強いエンティティタグを使用することができます。その後、getetagプロパティが返され、それがPUT応答で受信した強いエンティティタグとその値を比較し、それらが等しい場合ことを知っている：例えば、クライアントは、保存されたアドレスオブジェクトリソースのPROPFIND要求を行うことができますDAVを持っていますサーバー上のアドレスオブジェクトリソースが変更されていません。
In the case where the data stored by a server as a result of a PUT request is not equivalent by octet equality to the submitted address object resource, the behavior of the ETag response header is not specified here, with the exception that a strong entity tag MUST NOT be returned in the response. As a result, a client may need to retrieve the modified address object resource (and ETag) as a basis for further changes, rather than use the address object resource it had sent with the PUT request.
PUT要求の結果として、サーバによって記憶されるデータが送信アドレスオブジェクトリソースへオクテット平等によって等価ではない場合には、ETagをレスポンスヘッダの挙動を除いて、ここで指定されていないという強いエンティティタグ応答で返されてはなりません。その結果、クライアントは、さらに変更のための基礎として変更されたアドレスオブジェクトのリソース（とのETag）を取得する必要がある、というよりも、それはPUTリクエストを送信したアドレスオブジェクトのリソースを使用することができます。
CardDAV servers MUST support and adhere to the requirements of WebDAV ACL [RFC3744]. WebDAV ACL provides a framework for an extensible set of privileges that can be applied to WebDAV collections and ordinary resources.
CardDAVのサーバは、サポートおよびWebDAV ACL [RFC3744]の要件を遵守しなければなりません。 WebDAVのACLは、WebDAVコレクションと通常リソースに適用することができる権限の拡張可能なセットのためのフレームワークを提供します。
This section defines additional properties for WebDAV principal resources as defined in [RFC3744].
[RFC3744]で定義されるように、このセクションでは、WebDAVの主要リソースの追加のプロパティを定義します。
Name: addressbook-home-set
名前：アドレス帳-家セット
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Identifies the URL of any WebDAV collections that contain address book collections owned by the associated principal resource.
目的：関連する主要なリソースが所有しているアドレス帳のコレクションを含むすべてのWebDAVコレクションのURLを指定します。
Protected: MAY be protected if the server has fixed locations in which address books are created.
保護：サーバーはアドレス帳が作成された場所を固定した場合に保護されていてもよいです。
COPY/MOVE behavior: This property value MUST be preserved in COPY and MOVE operations.
COPY / MOVE動作：このプロパティの値は、COPYとMOVE操作で保存されなければなりません。
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop request.
allprop動作は：allprop要求：PROPFINDのDAVによって返されるべきではありません。
Description: The CARDDAV:addressbook-home-set property is meant to allow users to easily find the address book collections owned by the principal. Typically, users will group all the address book collections that they own under a common collection. This property specifies the URL of collections that are either address book collections or ordinary collections that have child or descendant address book collections owned by the principal.
説明：CardDAVの：アドレス帳-ホーム設定プロパティは、ユーザーが簡単に校長が所有しているアドレス帳のコレクションを見つけることができるようにするためのものです。一般的に、ユーザーは、共通のコレクションの下に所有するグループのすべてのアドレス帳のコレクションをでしょう。このプロパティは、アドレス帳のコレクションや校長が所有する子や子孫のアドレス帳のコレクションを持っている通常のコレクションのどちらかであるコレクションのURLを指定します。
Definition:
定義：
<!ELEMENT addressbook-home-set (DAV:href*)>
<！ELEMENTのアドレス帳-ホームセット（DAV：hrefのの*）>
Example:
例：
<C:addressbook-home-set xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:carddav">
<D:href>/bernard/addresses/</D:href>
</C:addressbook-home-set>
Name: principal-address
名前：校長アドレス
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Identifies the URL of an address object resource that corresponds to the user represented by the principal.
目的：主要で表されるユーザに対応するアドレスオブジェクトリソースのURLを指定します。
Protected: MAY be protected if the server provides a fixed location for principal addresses.
保護：サーバーは元本のアドレスの固定された場所を提供した場合に保護されていてもよいです。
COPY/MOVE behavior: This property value MUST be preserved in COPY and MOVE operations.
COPY / MOVE動作：このプロパティの値は、COPYとMOVE操作で保存されなければなりません。
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop request.
allprop動作は：allprop要求：PROPFINDのDAVによって返されるべきではありません。
Description: The CARDDAV:principal-address property is meant to allow users to easily find contact information for users represented by principals on the system. This property specifies the URL of the resource containing the corresponding contact information. The resource could be an address object resource in an address book collection, or it could be a resource in a "regular" collection.
説明：CardDAVの：元本アドレスプロパティは、ユーザーが簡単にシステム上のプリンシパルで表さユーザーの連絡先情報を見つけることができるようにするためのものです。このプロパティには、対応するコンタクト情報を含むリソースのURLを指定します。リソースは、アドレス帳のコレクション内のアドレスオブジェクトのリソース可能性があり、またはそれは「通常の」コレクション内のリソースである可能性があります。
Definition:
定義：
<!ELEMENT principal-address (DAV:href)>
<！ELEMENTプリンシパル・アドレス（DAV：HREF）>
Example:
例：
<C:principal-address xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:carddav">
<D:href>/system/cyrus.vcf</D:href>
</C:principal-address>
This section defines the reports that CardDAV servers MUST support on address book collections and address object resources.
このセクションでは、CardDAVのサーバがアドレス帳コレクションとアドレスオブジェクトのリソースにサポートしなければならないとの報告を定義します。
CardDAV servers MUST advertise support for these reports on all address book collections and address object resources with the DAV:supported-report-set property defined in Section 3.1.5 of [RFC3253]. CardDAV servers MAY also advertise support for these reports on ordinary collections.
[RFC3253]のセクション3.1.5で定義されたサポート・レポート - 設定されたプロパティ：CardDAVのサーバはDAVを持つすべてのアドレス帳コレクションとアドレスオブジェクトのリソースにこれらのレポートをサポートすることを通知しなければなりません。 CardDAVのサーバは、通常のコレクションにこれらのレポートをサポートすることを通知してもよい（MAY）。
Some of these reports allow address data (from possibly multiple resources) to be returned.
これらのレポートの一部は（おそらく複数のリソースからの）アドレスデータが返されることを可能にします。
The REPORT method (defined in Section 3.6 of [RFC3253]) provides an extensible mechanism for obtaining information about a resource. Unlike the PROPFIND method, which returns the value of one or more named properties, the REPORT method can involve more complex processing. REPORT is valuable in cases where the server has access to all of the information needed to perform the complex request (such as a query), and where it would require multiple requests for the client to retrieve the information needed to perform the same request.
（[RFC3253]のセクション3.6で定義された）報告方法は、リソースに関する情報を取得するための拡張可能なメカニズムを提供します。一つ以上の名前付きプロパティの値を返すPROPFIND法とは異なり、REPORTの方法は、より複雑な処理を含むことができます。 REPORTは、サーバは（例えばクエリとして）複雑な要求を実行するために必要なすべての情報へのアクセスを持っている場合に貴重であり、それは同じ要求を実行するために必要な情報を取得するためのクライアントのために複数の要求を必要とするところ。
A server that supports this specification MUST support the DAV:expand-property report (defined in Section 3.8 of [RFC3253]).
この仕様をサポートするサーバはDAVをサポートしなければならない：（[RFC3253]の3.8節で定義される）を展開-プロパティをレポート。
Servers MAY support the reports defined in this document on ordinary collections (collections that are not address book collections) in addition to address book collections or address object resources. In computing responses to the reports on ordinary collections, servers MUST only consider address object resources contained in address book collections that are targeted by the REPORT based on the value of the Depth request header.
サーバーは、通常のコレクションブックコレクションやアドレスオブジェクトのリソースに対処するために加えて、（蔵書に対処されていないコレクション）に、この文書で定義されたレポートをサポートするかもしれません。通常のコレクションに関するレポートへの応答を計算するには、サーバーのみ深リクエストヘッダの値に基づいて、REPORTによりターゲットとしているアドレス帳のコレクションに含まれているアドレスオブジェクトのリソースを考慮する必要があります。
Some of the reports defined in this section do text matches of character strings provided by the client and compared to stored address data. Since vCard data is by default encoded in the UTF-8 charset and may include characters outside of the US-ASCII charset range in some property and parameter values, there is a need to ensure that text matching follows well-defined rules.
このセクションで定義されたレポートの一部の文字列のテキストマッチがクライアントによって提供され、保存されたアドレスデータと比べてください。 vCardデータは、UTF-8文字セットでエンコードされたデフォルトであり、いくつかのプロパティとパラメータ値のUS-ASCII文字セットの範囲外の文字を含むことができるので、そのテキストマッチングは、明確に定義されたルールに従う確保する必要があります。
To deal with this, this specification makes use of the IANA Collation Registry defined in [RFC4790] to specify collations that may be used to carry out the text comparison operations with a well-defined rule.
これに対処するために、本明細書では、明確に定義されたルールにテキスト比較動作を実行するために使用することができる照合順序を指定するために[RFC4790]で定義されたIANA照合レジストリを利用します。
Collations supported by the server MUST support "equality" and "substring" match operations as per [RFC4790], Section 4.2, including the "prefix" and "suffix" options for "substring" matching. CardDAV uses these match options for "equals", "contains", "starts-with", and "ends-with" match operations.
サーバーでサポートされている照合順序は、「接頭辞」および「サブ」のマッチングのための「接尾辞」オプションを含む[RFC4790]あたりとして「平等」と「サブ」のマッチ操作、4.2節を、サポートしなければなりません。 「等しい」、「含まれている」、「始まり-で」、および「終了-で」一致操作にCardDAVのは、これらの一致オプションを使用しています。
CardDAV servers are REQUIRED to support the "i;ascii-casemap" [RFC4790] and "i;unicode-casemap" [RFC5051] collations and MAY support other collations.
[RFC4790]と "I;ユニコード-CASEMAP" [RFC5051]照合やその他の照合をサポートするかもしれ; CardDAVのサーバは "ASCII-CASEMAP I" をサポートする必要があります。
Servers MUST advertise the set of collations that they support via the CARDDAV:supported-collation-set property defined on any resource that supports reports that use collations.
照合順序を使用するレポートをサポートしているすべてのリソースに定義されているサポート・照合-setプロパティ：サーバーは、彼らがCardDAVのを経由してサポートして照合順序のセットをアドバタイズする必要があります。
In the absence of a collation explicitly specified by the client, or if the client specifies the "default" collation identifier (as defined in [RFC4790], Section 3.1), the server MUST default to using "i;unicode-casemap" as the collation.
「;ユニコードCASEMAP I」として明示的にクライアントによって指定された、またはクライアントが「デフォルト」の照合識別子（[RFC4790]で定義されるように、セクション3.1）を指定した場合、サーバが使用するデフォルトとしなければなりません照合の非存在下で照合。
Wildcards (as defined in [RFC4790], Section 3.2) MUST NOT be used in the collation identifier.
（セクション3.2、[RFC4790]で定義されるように）のワイルドカードは、照合識別子に使用してはいけません。
If the client chooses a collation not supported by the server, the server MUST respond with a CARDDAV:supported-collation precondition error response.
サポート・照合前提条件エラーレスポンス：クライアントがサーバーでサポートされていない照合を選択した場合、サーバはCardDAVので応じなければなりません。
Name: supported-collation-set
名前：サポート-照合セット
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Identifies the set of collations supported by the server for text matching operations.
目的：テキストマッチング操作用のサーバーによってサポートされている照合のセットを識別します。
Protected: MUST be protected as it indicates support provided by the server.
保護された：それは、サーバによって提供されるサポートを示して保護しなければなりません。
COPY/MOVE behavior: This property value MUST be preserved in COPY and MOVE operations.
COPY / MOVE動作：このプロパティの値は、COPYとMOVE操作で保存されなければなりません。
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop request.
allprop動作は：allprop要求：PROPFINDのDAVによって返されるべきではありません。
Description: The CARDDAV:supported-collation-set property contains two or more CARDDAV:supported-collation elements that specify the identifiers of the collations supported by the server.
説明：CardDAVの：サーバでサポートされている照合の識別子を指定して支持された照合要素：サポート-照合設定プロパティは、2つ以上のCardDAVのを含んでいます。
Definition:
定義：
<!ELEMENT supported-collation-set (
supported-collation
supported-collation
supported-collation*)>
<!-- Both "i;ascii-casemap" and "i;unicode-casemap"
will be present -->
<!ELEMENT supported-collation (#PCDATA)>
<！ELEMENTサポート-照合（#PCDATA）>
Example:
例：
<C:supported-collation-set xmlns:C="urn:ietf:params:xml:ns:carddav"> <C:supported-collation>i;ascii-casemap</C:supported-collation> <C:supported-collation>i;octet</C:supported-collation> <C:supported-collation>i;unicode-casemap</C:supported-collation> </C:supported-collation-set>
<C：サポート-照合セットのxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの"> <C：サポート-照合> I; ASCII-CASEMAP </ C：サポート-照合> <C：サポート-collation> I;オクテット</ C：サポート-照合> <C：サポート-照合> I;ユニコードCASEMAP </ C：サポート-照合> </ C：サポート-照合設定>
Some address book reports defined in this document allow partial retrieval of address object resources. A CardDAV client can specify what information to return in the body of an address book REPORT request.
この文書で定義されたいくつかのアドレス帳のレポートは、アドレスオブジェクトリソースの部分的検索を可能にします。 CardDAVのクライアントは、アドレス帳REPORT要求のボディに戻すためにどのような情報を指定することができます。
A CardDAV client can request particular WebDAV property values, all WebDAV property values, or a list of the names of the resource's WebDAV properties. A CardDAV client can also request address data to be returned and whether all vCard properties should be returned or only particular ones. See CARDDAV:address-data in Section 10.4.
CardDAVのクライアントは、特定のWebDAVプロパティの値は、すべてのWebDAVプロパティ値、またはリソースのWebDAVのプロパティの名前のリストを要求することができます。また、アドレスデータを要求することができCardDAVのクライアントが返されると、すべてのvCardのプロパティが返されたり、特定のものをすべきかどうか。セクション10.4内のアドレス・データ：CardDAVのを参照してください。
Servers MUST support the use of non-standard vCard property or parameter names in the CARDDAV:address-data XML element in address book REPORT requests to allow clients to request that non-standard properties and parameters be returned in the address data provided in the response.
サーバーはCardDAVのに非標準のvCardプロパティまたはパラメータ名の使用をサポートしなければならない：アドレス帳のREPORT要求内のアドレス・データのXML要素は、クライアントが非標準のプロパティとパラメータが応答で提供されたアドレスデータに返されることを要求できるようにするために。
Servers MAY support the use of non-standard vCard property or parameter names in the CARDDAV:prop-filter and CARDDAV:param-filter XML elements specified in the CARDDAV:filter XML element of address book REPORT requests.
プロパフィルタおよびCardDAVの：：CardDAVのに指定のparam-フィルタのXML要素：アドレス帳のREPORT要求のフィルターXML要素サーバは、CardDAVの非標準のvCardプロパティまたはパラメータ名の使用をサポートするかもしれません。
Servers MUST fail with the CARDDAV:supported-filter precondition if an address book REPORT request uses a CARDDAV:prop-filter or CARDDAV:param-filter XML element that makes reference to a non-standard vCard property or parameter name on which the server does not support queries.
プロパフィルタまたはCardDAVの：PARAM-フィルタXML要素サーバはありませんれている非標準のvCardプロパティまたはパラメータ名を参照し、アドレス帳REPORT要求はCardDAVのを使用している場合は、サポート・フィルター前提条件：サーバーはCardDAVのに失敗しなければなりませんクエリをサポートしていません。
The CARDDAV:addressbook-query REPORT performs a search for all address object resources that match a specified filter. The response of this report will contain all the WebDAV properties and address object resource data specified in the request. In the case of the
CardDAVの：アドレス帳問合せレポートは、指定したフィルタに一致するすべてのアドレスオブジェクトのリソースの検索を実行します。この報告書の応答は、要求で指定されたすべてのWebDAVのプロパティとアドレスオブジェクトのリソースデータが含まれています。の場合
CARDDAV:address-data XML element, one can explicitly specify the vCard properties that should be returned in the address object resource data that matches the filter.
CardDAVの：アドレスデータのXML要素は、一つは、明示的にフィルタに一致するアドレスオブジェクトリソースデータで返されるべきvCardのプロパティを指定することができます。
The format of this report is modeled on the PROPFIND method. The request and response bodies of the CARDDAV:addressbook-query report use XML elements that are also used by PROPFIND. In particular, the request can include XML elements to request WebDAV properties to be returned. When that occurs, the response should follow the same behavior as PROPFIND with respect to the DAV:multistatus response elements used to return specific WebDAV property results. For instance, a request to retrieve the value of a WebDAV property that does not exist is an error and MUST be noted with a response XML element that contains a 404 (Not Found) status value.
このレポートの形式は、PROPFINDメソッドをモデルにしています。また、PROPFINDで使用されているアドレス帳、クエリ報告用XML要素：CardDAVののリクエストとレスポンスのボディ。具体的には、要求が返されるのWebDAVプロパティを要求するXML要素を含むことができます。特定のWebDAVプロパティ結果を返すために使用multistatus応答エレメント：それが発生すると、応答がDAVに対してPROPFINDと同じ挙動に従わなければなりません。例えば、存在しないWebDAVのプロパティの値を取得するための要求がエラーであり、404（見つかりません）ステータス値を含む応答XML要素に留意しなければなりません。
Support for the CARDDAV:addressbook-query REPORT is REQUIRED.
CardDAVのためのサポート：アドレス帳、クエリレポートが必要です。
Marshalling:
マーシャリング：
The request body MUST be a CARDDAV:addressbook-query XML element as defined in Section 10.3.
セクション10.3で定義されているアドレス帳クエリのXML要素：リクエストボディはCardDAVのでなければなりません。
The request MUST include a Depth header. The scope of the query is determined by the value of the Depth header. For example, to query all address object resources in an address book collection, the REPORT would use the address book collection as the Request-URI and specify a Depth of 1 or infinity.
要求は、深ヘッダを含まなければなりません。クエリの範囲は、奥行きヘッダの値によって決定されます。たとえば、アドレス帳のコレクション内のすべてのアドレスオブジェクトのリソースを照会するために、REPORTは、Request-URIとしてアドレス帳コレクションを使用し、1または無限の深さを指定します。
The response body for a successful request MUST be a DAV:multistatus XML element (i.e., the response uses the same format as the response for PROPFIND). In the case where there are no response elements, the returned DAV:multistatus XML element is empty.
multistatus XML要素（すなわち、応答がPROPFINDに対するレスポンスと同じフォーマットを使用）：成功した要求に対する応答の本体は、DAVでなければなりません。応答要素が存在しない場合、返さDAV：multistatus XML要素は空です。
The response body for a successful CARDDAV:addressbook-query REPORT request MUST contain a DAV:response element for each address object that matched the search filter. Address data is returned in the CARDDAV:address-data XML element inside the DAV:propstat XML element.
成功のためのCardDAVのレスポンスボディ：検索フィルタに一致した各アドレスオブジェクトのための応答要素：アドレス帳問合せレポート要求は、DAVを含まなければなりません。アドレスデータは、CardDAVのに返されます。DAV内部アドレス・データのXML要素：propstat XML要素。
Preconditions:
前提条件：
(CARDDAV:supported-address-data): The attributes "content-type" and "version" of the CARDDAV:address-data XML element (see Section 10.4) specify a media type supported by the server for address object resources.
（CardDAVの：サポートされているアドレスデータ）：属性「コンテンツタイプ」とCardDAVのの「バージョン」：アドレスデータのXML要素（項10.4を参照してください）アドレスオブジェクトリソースのサーバーでサポートされているメディアタイプを指定します。
(CARDDAV:supported-filter): The CARDDAV:prop-filter (see Section 10.5.1) and CARDDAV:param-filter (see Section 10.5.2) XML elements used in the CARDDAV:filter XML element (see Section 10.5) in the REPORT request only make reference to vCard properties and parameters for which queries are supported by the server. That is, if the CARDDAV:filter element attempts to reference an unsupported vCard property or parameter, this precondition is violated. A server SHOULD report the CARDDAV:prop-filter or CARDDAV:param-filter for which it does not provide support.
（CardDAVの：サポートされているフィルタ）：プロパフィルタ（10.5.1項を参照）、CardDAVの：CardDAVのPARAMフィルタCardDAVのに使用されるXML要素（10.5.2項を参照）：フィルタXML要素（セクション10.5を参照） REPORT要求は、クエリのみがサーバによってサポートされているvCardのプロパティとパラメータを参照すること。フィルタエレメントこの前提条件に違反している、サポートされていないvCardのプロパティまたはパラメータを参照しよう：CardDAVのがあれば、です。サーバーは、CardDAVのを報告する必要があります：PROP-フィルタまたはCardDAVの：それはサポートを提供しないためのparam-フィルタを。
<!ELEMENT supported-filter (prop-filter*,
param-filter*)>
(CARDDAV:supported-collation): Any XML attribute specifying a collation MUST specify a collation supported by the server as described in Section 8.3.
（CardDAVの：サポート-照合）：照合順序を指定する任意のXML属性は、8.3節で説明したように、サーバーでサポートされている照合順序を指定しなければなりません。
Postconditions:
事後条件：
(DAV:number-of-matches-within-limits): The number of matching address object resources must fall within server-specific, predefined limits. For example, this condition might be triggered if a search specification would cause the return of an extremely large number of responses.
（DAV：数のマッチ-内-限界）：アドレスオブジェクトのリソースを一致の数は、サーバ固有の、事前に定義された限界内に入らなければなりません。検索仕様は応答の非常に多くのリターンを引き起こす場合たとえば、この条件がトリガされる可能性があります。
A client can limit the number of results returned by the server through use of the CARDDAV:limit element in the request body. This is useful when clients are only interested in a few matches or only have limited space to display results to users and thus don't need the overhead of receiving more than that. When the results are truncated by the server, the server MUST follow the rules below for indicating a result set truncation to the client.
リクエストボディには限界要素：クライアントは、CardDAVのを使用して、サーバから返される結果の数を制限することができます。クライアントは、いくつかの試合にのみ関心があるかユーザーのみに結果を表示するので、それ以上のものを受け取るのオーバーヘッドを必要としないスペースが限られている場合に便利です。結果がサーバーによって切り捨てられた場合、サーバはクライアントに結果セットの切り捨てを示すため、以下の規則に従わなければなりません。
A server MAY limit the number of resources in a response, for example, to limit the amount of work expended in processing a query, or as the result of an explicit limit set by the client. If the result set is truncated because of such a limit, the response MUST use status code 207 (Multi-Status), return a DAV:multistatus response body, and indicate a status of 507 (Insufficient Storage) for the Request-URI. That DAV:response element SHOULD include a DAV:error element with the DAV:number-of-matches-within-limits precondition, as defined in [RFC3744], Section 9.2.
サーバは、例えば、応答内のリソースの数を制限することができるクエリの処理に費やされる作業の量を制限するために、又はクライアントによって設定された明示的な制限の結果として。このような限界の、レスポンスステータスコード207（マルチステータス）を使用しなければならないため、結果セットが切り捨てられる場合、DAVを返す：multistatus応答本体を、そしてリクエストURIのための507（ストレージ不足）の状態を示します。そのDAV：[RFC3744]で定義されている数のマッチ-内-制限前提条件、セクション9.2：DAVとエラー要素：応答エレメントは、DAVを含むべきです。
The server SHOULD also include the partial results in additional DAV:response elements. If a client-requested limit is being applied, the 507 response for the Request-URI MUST NOT be included in calculating the limit (e.g., if the client requests that only a single result be returned, and multiple matches are present, then the DAV:multistatus response will include one DAV:response for the matching resource and one DAV:response for the 507 status on the Request-URI).
応答要素：サーバーは、追加のDAVでの部分的な結果をも含むべきです。クライアントが要求した制限が適用されている場合は、要求URIのための507応答は（例えば、クライアントのみ単一の結果が返されることを要求し、複数の一致が存在する場合、DAVを限度の計算に含んではいけません：マッチングリソースの応答一のDAV：のRequest-URIに507のステータス応答）multistatus応答は、一のDAVを含むであろう。
In this example, the client requests that the server search for address object resources that contain a NICKNAME property whose value equals some specific text and return specific vCard properties for those vCards found. In addition, the DAV:getetag property is also requested and returned as part of the response.
この例では、クライアントが値ニックネームプロパティが含まれているアドレスオブジェクトリソースのサーバーの検索は、いくつかの特定のテキストに等しいと見られるものvCardのための特定のvCardプロパティを返すことを要求します。また、DAV：getetag性も要求され、応答の一部として返さ。
>> Request <<
>>リクエスト<<
REPORT /home/bernard/addressbook/ HTTP/1.1 Host: addressbook.example.com Depth: 1 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
REPORT /ホーム/バーナード/アドレス帳/ HTTP / 1.1ホスト：addressbook.example.com奥行：1のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <C:addressbook-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"> <D:prop> <D:getetag/> <C:address-data> <C:prop name="VERSION"/> <C:prop name="UID"/> <C:prop name="NICKNAME"/> <C:prop name="EMAIL"/> <C:prop name="FN"/> </C:address-data> </D:prop> <C:filter> <C:prop-filter name="NICKNAME"> <C:text-match collation="i;unicode-casemap" match-type="equals" >me</C:text-match> </C:prop-filter> </C:filter> </C:addressbook-query>
<？xml version = "1.0" エンコード= "UTF-8"？> <C：アドレス帳-クエリのxmlns：D = "DAV：" のxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの"> < D：プロペラ> <D：getetag /> <C：アドレスデータ> <C：名小道具= "VERSION" /> <C：小道具名= "UID" /> <C：名小道具= "ニックネーム" /> <C：名= "EMAIL" /小道具> <C：小道具名= "FN" /> </ C：アドレスデータ> </ D：プロペラ> <C：フィルタ> <C：プロパフィルタ名=」 NICKNAME "> <C：テキストマッチ照合=" I;ユニコード-CASEMAP」マッチタイプは= "" に等しい>私</ C：テキストマッチ> </ C：プロパフィルタ> </ C：フィルタ> < / C：アドレス帳クエリ>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Date: Sat, 11 Nov 2006 09:32:12 GMT Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスの日付：土、2006年11月11日午前9時32分12秒GMTのコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"> <D:response> <D:href>/home/bernard/addressbook/v102.vcf</D:href> <D:propstat> <D:prop> <D:getetag>"23ba4d-ff11fb"</D:getetag> <C:address-data>BEGIN:VCARD VERSION:3.0 NICKNAME:me UID:34222-232@example.com FN:Cyrus Daboo EMAIL:daboo@example.com END:VCARD </C:address-data> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV：" のxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの"> <D：レスポンス> <D：HREF> /home/bernard/addressbook/v102.vcf </ D：HREF> <D：propstat> <D：プロペラ> <D：getetag> "23ba4d-ff11fb" </ D：getetag> < C：アドレスデータ> BEGIN：VCARDバージョン：3.0ニックネーム：私UID：34222-232@example.com FN：サイラスDabooのEMAIL：daboo@example.com END：VCARD </ C：アドレスデータ> </ D：支柱> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ D：multistatus>
8.6.4. Example: Partial Retrieval of vCards Matching a Full Name or Email Address
8.6.4. 例：フルネームやメールアドレスのマッチングのvCardの一部を検索
In this example, the client requests that the server search for address object resources that contain a FN property whose value contains some specific text or that contain an EMAIL property whose value contains other text and return specific vCard properties for those vCards found. In addition, the DAV:getetag property is also requested and returned as part of the response.
この例では、クライアントは、値いくつかの特定のテキストまたはその値が他のテキストが含まれていると見られるもののvCardのための特定のvCardプロパティを返すEMAILプロパティが含まれているが含まれているFNプロパティが含まれているアドレスオブジェクトリソースのサーバ検索することを要求します。また、DAV：getetag性も要求され、応答の一部として返さ。
>> Request <<
>>リクエスト<<
REPORT /home/bernard/addressbook/ HTTP/1.1 Host: addressbook.example.com Depth: 1 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
REPORT /ホーム/バーナード/アドレス帳/ HTTP / 1.1ホスト：addressbook.example.com奥行：1のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <C:addressbook-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"> <D:prop> <D:getetag/> <C:address-data> <C:prop name="VERSION"/> <C:prop name="UID"/> <C:prop name="NICKNAME"/> <C:prop name="EMAIL"/> <C:prop name="FN"/> </C:address-data> </D:prop> <C:filter test="anyof"> <C:prop-filter name="FN"> <C:text-match collation="i;unicode-casemap" match-type="contains" >daboo</C:text-match> </C:prop-filter> <C:prop-filter name="EMAIL"> <C:text-match collation="i;unicode-casemap" match-type="contains" >daboo</C:text-match> </C:prop-filter> </C:filter> </C:addressbook-query>
<？xml version = "1.0" エンコード= "UTF-8"？> <C：アドレス帳-クエリのxmlns：D = "DAV：" のxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの"> < D：プロペラ> <D：getetag /> <C：アドレスデータ> <C：名小道具= "VERSION" /> <C：小道具名= "UID" /> <C：名小道具= "ニックネーム" /> <C：名= "EMAIL" 小道具/> <C：NAME = "FN" /小道具>：</ D：プロペラ> <C：フィルタテスト= "anyof"> <C <アドレスデータ/ C>小道具名前-filter = "FN"> <C：テキスト一致照合が= "I;ユニコードCASEMAP" マッチタイプ= "含有"> daboo </ C：テキストマッチ> </ C：プロプフィルタ> <C ：プロパフィルタ名= "EMAIL" は> <C：テキストマッチ照合= "I;ユニコードCASEMAP" マッチタイプ= "含有"> daboo </ C：テキストマッチ> </ C：プロプフィルタ> </ C：フィルタ> </ C：アドレス帳クエリ>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Date: Sat, 11 Nov 2006 09:32:12 GMT Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスの日付：土、2006年11月11日午前9時32分12秒GMTのコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"> <D:response> <D:href>/home/bernard/addressbook/v102.vcf</D:href> <D:propstat> <D:prop> <D:getetag>"23ba4d-ff11fb"</D:getetag> <C:address-data>BEGIN:VCARD VERSION:3.0 NICKNAME:me UID:34222-232@example.com FN:David Boo EMAIL:daboo@example.com
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV：" のxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの"> <D：レスポンス> <D：HREF> /home/bernard/addressbook/v102.vcf </ D：HREF> <D：propstat> <D：プロペラ> <D：getetag> "23ba4d-ff11fb" </ D：getetag> < C：アドレスデータ> BEGIN：VCARDバージョン：3.0ニックネーム：私UID：34222-232@example.com FN：デヴィッド・ブーのEMAIL：daboo@example.com
END:VCARD </C:address-data> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/home/bernard/addressbook/v104.vcf</D:href> <D:propstat> <D:prop> <D:getetag>"23ba4d-ff11fc"</D:getetag> <C:address-data>BEGIN:VCARD VERSION:3.0 NICKNAME:oliver UID:34222-23222@example.com FN:Oliver Daboo EMAIL:oliver@example.com END:VCARD </C:address-data> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
END：VCARD </ C：アドレスデータ> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> <D：応答> <D：HREF> /home/bernard/addressbook/v104.vcf </ D：HREF> <D：propstat> <D：プロペラ> <D：getetag> "23ba4d-ff11fc" </ D：getetag> <C：アドレスデータ> BEGIN：VCARDバージョン：3.0ニックネーム：オリバーUIDを：34222-23222@example.com FN：オリバーDaboo EMAIL：oliver@example.com END：VCARD </ C：アドレスデータ> </ D：小道具> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ D：multistatus>
In this example, the client requests that the server search for address object resources that contain a FN property whose value contains some specific text and return the DAV:getetag property for two results only. The server response includes a 507 status for the Request-URI indicating that there were more than two resources that matched the query, but that the server truncated the result set as requested by the client.
2つのだけの結果を得るためにgetetagプロパティ：この例では、クライアントが値FNプロパティが含まれているアドレスオブジェクトリソースのサーバーの検索は、いくつかの特定のテキストが含まれており、DAVを返すことを要求します。サーバーの応答は、サーバがクライアントからの要求に応じて、結果セットを切り捨てることのRequest-URIがクエリにマッチした二つ以上のリソースがあったことを示すための507個のステータスが含まれていますが、。
>> Request <<
>>リクエスト<<
REPORT /home/bernard/addressbook/ HTTP/1.1 Host: addressbook.example.com Depth: 1 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
REPORT /ホーム/バーナード/アドレス帳/ HTTP / 1.1ホスト：addressbook.example.com奥行：1のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <C:addressbook-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav">
<？xml version = "1.0" エンコード= "UTF-8"？> <C：アドレス帳-クエリのxmlns：D = "DAV：" のxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの">
<D:prop> <D:getetag/> </D:prop> <C:filter test="anyof"> <C:prop-filter name="FN"> <C:text-match collation="i;unicode-casemap" match-type="contains" >daboo</C:text-match> </C:prop-filter> </C:filter> <C:limit> <C:nresults>2</C:nresults> </C:limit> </C:addressbook-query>
<D：プロペラ> <D：getetag /> </ D：プロペラ> <C：フィルタテスト= "anyof"> <C：プロパフィルタ名= "FN"> <C：テキストマッチ照合= "I。ユニコードCASEMAP」マッチ型= "" が含ま> daboo </ C：テキストマッチ> </ C：プロプフィルタ> </ C：フィルタ> <C：リミット> <C：nresults> 2 </ C： nresults> </ C：リミット> </ C：アドレス帳クエリ>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Date: Sat, 11 Nov 2006 09:32:12 GMT Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスの日付：土、2006年11月11日午前9時32分12秒GMTのコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"> <D:response> <D:href>/home/bernard/addressbook/</D:href> <D:status>HTTP/1.1 507 Insufficient Storage</D:status> <D:error><D:number-of-matches-within-limits/></D:error> <D:responsedescription xml:lang="en"> Only two matching records were returned </D:responsedescription> </D:response> <D:response> <D:href>/home/bernard/addressbook/v102.vcf</D:href> <D:propstat> <D:prop> <D:getetag>"23ba4d-ff11fb"</D:getetag> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/home/bernard/addressbook/v104.vcf</D:href> <D:propstat> <D:prop> <D:getetag>"23ba4d-ff11fc"</D:getetag> </D:prop>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV：" のxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの"> <D：応答> <D：HREF> /ホーム/バーナード/アドレス帳/ </ D：のhref> <D：状態> HTTP / 1.1 507ストレージ不足</ D：状態> <D：エラー> <D：数のマッチ-within-制限/> </ D：エラー> <D：responsedescriptionのXML：LANG = "EN"> 2つだけ一致するレコードが返された</ D：responsedescription> </ D：レスポンス> <D：レスポンス> <D： HREF> /home/bernard/addressbook/v102.vcf </ D：HREF> <D：propstat> <D：プロペラ> <D：getetag> "23ba4d-ff11fb" </ D：getetag> </ D：小道具> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> <D：レスポンス> <D：HREF> /home/bernard/addressbook/v104.vcf </ D：HREF> <D：propstat> <D：プロペラ> <D：getetag> "23ba4d-ff11fc" </ D：getetag> </ D：小道具>
<D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
<D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ D：multistatus>
The CARDDAV:addressbook-multiget REPORT is used to retrieve specific address object resources from within a collection, if the Request-URI is a collection, or to retrieve a specific address object resource, if the Request-URI is an address object resource. This report is similar to the CARDDAV:addressbook-query REPORT (see Section 8.6), except that it takes a list of DAV:href elements instead of a CARDDAV:filter element to determine which address object resources to return.
CardDAVの：アドレス帳-multiget REPORTを要求URIた場合、コレクションの中から特定のアドレスオブジェクトのリソースを取得するために使用されるのRequest-URIは、アドレスオブジェクトのリソースである場合は、コレクションである、または特定のアドレスオブジェクトのリソースを取得します。このレポートは、CardDAVのに似ています：アドレス帳問合せレポート（8.6節を参照）、それはDAVのリストを取ることを除い：代わりにCardDAVののhref要素：フィルタ要素をオブジェクトのリソースを返すためにどのアドレスを決定します。
Support for the addressbook-multiget REPORT is REQUIRED.
アドレス帳-multiget REPORTのためのサポートが必要です。
Marshalling:
マーシャリング：
The request body MUST be a CARDDAV:addressbook-multiget XML element (see Section 10.7), which MUST contain at least one DAV:href XML element and one optional CARDDAV:address-data element as defined in Section 10.4. If DAV:href elements are present, the scope of the request is the set of resources identified by these elements, which all need to be members (not necessarily internal members) of the resource identified by the Request-URI. Otherwise, the scope is the resource identified by the Request-URI itself.
アドレス帳-multiget XML要素（セクション10.7を参照）、少なくとも一つのDAV含める必要があります：10.4節で定義されたアドレスデータエレメント：hrefのXML要素と1つのオプションをCardDAVのリクエストボディはCardDAVのでなければなりません。 DAV場合：hrefの要素が存在している、請求の範囲は、すべてのRequest-URIによって識別されるリソースのメンバー（必ずしも内部部材）である必要があり、これらの要素によって識別されたリソースのセットです。それ以外の場合は、スコープは、Request-URI自体で識別されるリソースです。
The request MUST include a Depth: 0 header; however, the actual scope of the REPORT is determined as described above.
要求は、深含まなければならない：0ヘッダと、ただし、レポートの実際の範囲は、上記のように決定されます。
The response body for a successful request MUST be a DAV:multistatus XML element.
multistatus XML要素：成功したリクエストのレスポンスボディは、DAVでなければなりません。
The response body for a successful CARDDAV:addressbook-multiget REPORT request MUST contain a DAV:response element for each address object resource referenced by the provided set of DAV:href elements. Address data is returned in the CARDDAV:address-data element inside the DAV:prop element.
HREF要素：DAVの提供組によって参照される各アドレスオブジェクトリソースの応答エレメント：アドレス帳-multiget REPORT要求がDAVを含まなければなりません：成功CardDAVのためのレスポンスボディ。アドレスデータは、CardDAVのに返されます。DAV内部アドレス・データ要素：支柱要素。
In the case of an error accessing any of the provided DAV:href resources, the server MUST return the appropriate error status code in the DAV:status element of the corresponding DAV:response element.
提供DAVのいずれかのアクセスエラーの場合：HREFリソースを、サーバがDAVに適切なエラーステータスコードを返さなければならない：対応DAVのステータス要素：応答エレメント。
Preconditions:
前提条件：
(CARDDAV:supported-address-data): The attributes "content-type" and "version" of the CARDDAV:address-data XML elements (see Section 10.4) specify a media type supported by the server for address object resources.
（CardDAVの：サポートされているアドレスデータ）：属性「コンテンツタイプ」とCardDAVのの「バージョン」：アドレスデータのXML要素（項10.4を参照してください）アドレスオブジェクトリソースのサーバーでサポートされているメディアタイプを指定します。
Postconditions:
事後条件：
None.
無し。
In this example, the client requests the server to return specific vCard properties of the address components referenced by specific URIs. In addition, the DAV:getetag property is also requested and returned as part of the response. Note that, in this example, the resource at http://addressbook.example.com/home/bernard/addressbook/vcf1.vcf does not exist, resulting in an error status response.
この例では、クライアントが特定のURIで参照されるアドレス構成要素の特定のvCardプロパティを返すようにサーバに要求します。また、DAV：getetag性も要求され、応答の一部として返さ。なお、この例では、http://addressbook.example.com/home/bernard/addressbook/vcf1.vcfにおけるリソースは、エラーステータス応答をもたらす、存在しません。
>> Request <<
>>リクエスト<<
REPORT /home/bernard/addressbook/ HTTP/1.1 Host: addressbook.example.com Depth: 1 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
REPORT /ホーム/バーナード/アドレス帳/ HTTP / 1.1ホスト：addressbook.example.com奥行：1のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <C:addressbook-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"> <D:prop> <D:getetag/> <C:address-data> <C:prop name="VERSION"/> <C:prop name="UID"/> <C:prop name="NICKNAME"/> <C:prop name="EMAIL"/> <C:prop name="FN"/> </C:address-data> </D:prop> <D:href>/home/bernard/addressbook/vcf102.vcf</D:href> <D:href>/home/bernard/addressbook/vcf1.vcf</D:href> </C:addressbook-multiget>
<？xml version = "1.0" エンコード= "UTF-8"？> <C：帳-multigetのxmlns：D = "DAV：" のxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの"> < D：プロペラ> <D：getetag /> <C：アドレスデータ> <C：名小道具= "VERSION" /> <C：小道具名= "UID" /> <C：名小道具= "ニックネーム" /> <C：名= "EMAIL" 小道具/> <C：名= "FN" 小道具/> </ C：アドレスデータ> </ D：小道具> <D：HREF> /ホーム/バーナード/アドレス帳/ vcf102。 VCF </ D：HREF> <D：HREF> /home/bernard/addressbook/vcf1.vcf </ D：HREF> </ C：アドレス帳-multiget>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Date: Sat, 11 Nov 2006 09:32:12 GMT Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスの日付：土、2006年11月11日午前9時32分12秒GMTのコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"> <D:response> <D:href>/home/bernard/addressbook/vcf102.vcf</D:href> <D:propstat> <D:prop> <D:getetag>"23ba4d-ff11fb"</D:getetag> <C:address-data>BEGIN:VCARD VERSION:3.0 NICKNAME:me UID:34222-232@example.com FN:Cyrus Daboo EMAIL:daboo@example.com END:VCARD </C:address-data> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/home/bernard/addressbook/vcf1.vcf</D:href> <D:status>HTTP/1.1 404 Resource not found</D:status> </D:response> </D:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV：" のxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの"> <D：レスポンス> <D：HREF> /home/bernard/addressbook/vcf102.vcf </ D：HREF> <D：propstat> <D：プロペラ> <D：getetag> "23ba4d-ff11fb" </ D：getetag> < C：アドレスデータ> BEGIN：VCARDバージョン：3.0ニックネーム：私UID：34222-232@example.com FN：サイラスDabooのEMAIL：daboo@example.com END：VCARD </ C：アドレスデータ> </ D：支柱> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> <D：レスポンス> <D：HREF> /home/bernard/addressbook/vcf1.vcf </ D：HREF> <D：ステータス> HTTP / 1.1 404リソースが見つかりません</ D：状態> </ D：レスポンス> </ D：multistatus>
In this example, the client requests the server to return vCard v4.0 data of the address components referenced by specific URIs. In addition, the DAV:getetag property is also requested and returned as part of the response. Note that, in this example, the resource at http://addressbook.example.com/home/bernard/addressbook/vcf3.vcf exists but in a media type format that the server is unable to convert, resulting in an error status response.
この例では、クライアントが特定のURIで参照されるアドレス構成要素のvCardのv4.0のデータを返すようにサーバに要求します。また、DAV：getetag性も要求され、応答の一部として返さ。この例では、http://addressbook.example.com/home/bernard/addressbook/vcf3.vcfでリソースが存在するが、サーバーは、エラーステータス応答を生じる、変換することができないメディアタイプのフォーマットで、なお。
>> Request <<
>>リクエスト<<
REPORT /home/bernard/addressbook/ HTTP/1.1 Host: addressbook.example.com Depth: 1 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
REPORT /ホーム/バーナード/アドレス帳/ HTTP / 1.1ホスト：addressbook.example.com奥行：1のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <C:addressbook-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"> <D:prop> <D:getetag/> <C:address-data content-type='text/vcard' version='4.0'/> </D:prop> <D:href>/home/bernard/addressbook/vcf3.vcf</D:href> </C:addressbook-multiget>
<？xml version = "1.0" エンコード= "UTF-8"？> <C：帳-multigetのxmlns：D = "DAV：" のxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの"> < D：小道具> <D：getetag /> <C：アドレス・データ・コンテンツ・タイプ= 'テキスト/ vCardの' バージョン= '4.0' /> </ D：小道具> <D：HREF> /ホーム/バーナード/アドレス帳/ vcf3.vcf </ D：HREF> </ C：アドレス帳-multiget>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Date: Sat, 11 Nov 2006 09:32:12 GMT Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスの日付：土、2006年11月11日午前9時32分12秒GMTのコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"> <D:response> <D:href>/home/bernard/addressbook/vcf3.vcf</D:href> <D:status>HTTP/1.1 415 Unsupported Media Type</D:status> <D:error><C:supported-address-data-conversion/></D:error> <D:responsedescription>Unable to convert from vCard v3.0 to vCard v4.0</D:responsedescription> </D:response> </D:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV：" のxmlns：C = "URN：IETF：paramsは：XML：NS：CardDAVの"> <D：レスポンス> <D：HREF> /home/bernard/addressbook/vcf3.vcf </ D：HREF> <D：ステータス> HTTP / 1.1 415サポートされていないメディアタイプ</ D：状態> <D：エラー> <C：サポート-addressデータ変換/> </ D：エラー> <D：responsedescription>のvCard V4.0へのvCard V3.0へ変換することができません</ D：responsedescription> </ D：レスポンス> </ D：multistatus>
Clients may not need all the properties in a vCard object when presenting information to the user, or looking up specific items for their email address, for example. Since some property data can be large (e.g., PHOTO or SOUND with in-line content) clients can choose to ignore those by only requesting the specific items it knows it will use, through use of the CARDDAV:address-data XML element in the relevant reports.
例えば、ユーザに情報を提示する、またはメールアドレスの特定の項目を検索するとき、クライアントはvCardのオブジェクトのすべてのプロパティを必要としないかもしれません。内のアドレス・データのXML要素：いくつかのプロパティデータが大きい（インラインコンテンツを持つ例えば、PHOTOまたはSOUND）をすることができますので、クライアントは、それはそれはCardDAVのを使用して、使用する知っている特定の項目を要求することにより、それらを無視することを選択することができます関連するレポート。
However, if a client needs to make a change to a vCard, it can only change the entire vCard data via a PUT request. There is no way to incrementally make a change to a set of properties within a vCard object resource. As a result, the client will have to cache the entire set of properties on a resource that is being changed.
クライアントは、vCardのに変更を加える必要がある場合は、それが唯一のPUTリクエストを経由して、全体vCardデータを変更することができます。インクリメンタルvCardのオブジェクトリソース内のプロパティセットへの変更を行う方法はありません。その結果、クライアントが変更されているリソースのプロパティのセット全体をキャッシュする必要があります。
When resources are accessed by multiple clients, the possibility of clients overwriting each other's changes exists. To alleviate this, clients SHOULD use the If-Match request header on PUT requests with the ETag of the previously retrieved resource data to check whether the resource was modified since it was previously retrieved. If a precondition failure occurs, clients need to reload the resource and go through their own merge or conflict resolution process before writing back the data (again using the If-Match check).
リソースが複数のクライアントからアクセスされた場合、お互いの変更を上書きするクライアントの可能性が存在します。これを軽減するために、クライアントは、それが以前に検索してからリソースが変更されたかどうかを確認するために以前に取得したリソースデータのETagを用いてPUT要求の場合、対戦要求ヘッダーを使用すべきです。前提条件に障害が発生した場合、クライアントはリソースをリロードし、（再びもしマッチのチェックを使用して）データを書き戻す前に、自分のマージや紛争解決のプロセスを通過する必要があります。
When CardDAV clients need to be configured, the key piece of information that they require is the principal-URL of the user whose address book information is desired. Servers SHOULD support the DAV:current-user-principal-URL property as defined in [RFC5397] to give clients a fast way to locate user principals.
CardDAVのクライアントを構成する必要がある場合には、彼らが必要とする情報の重要な部分は、アドレス帳の情報希望する利用者の要URLです。サーバはDAVをサポートする必要があります。現在のユーザー-元本-URLプロパティをクライアントにユーザープリンシパルを迅速に検索する方法を提供するために、[RFC5397]で定義されています。
Given support for SRV records (Section 11) and DAV:current-user-principal-URL [RFC5397], users only need enter a user identifier, host name, and password to configure their client. The client would take the host name and do an SRV lookup to locate the CardDAV server, then execute an authenticated PROPFIND on the root/resource looking for the DAV:current-user-principal-URL property. The value returned gives the client direct access to the user's principal-URL and from there all the related CardDAV properties needed to locate address books.
与えられたSRVレコードのサポート（第11節）とDAV：現在のユーザー-元本-URL [RFC5397]は、ユーザーが唯一の彼らのクライアントを設定するには、ユーザ識別子、ホスト名、およびパスワードを入力する必要があります。現在のユーザー-元本-URLプロパティ：クライアントは、DAVを探してルート/リソースに認証されたPROPFINDを実行し、ホスト名を取り、CardDAVのサーバーを見つけるためにSRVルックアップを行うだろう。値は、アドレス帳を検索するために必要な関連CardDAVのプロパティユーザーの元本-URLへ、そこからすべてのクライアントの直接アクセスを提供します返さ。
For use cases of address book sharing, one might wish to find the address book belonging to another user. To find other users' address books on the same server, the DAV:principal-property-search REPORT [RFC3744] can be used to search principals for matching properties and return specified properties for the matching principal resources. To search for an address book owned by a user named "Laurie", the REPORT request body would look like this:
アドレス帳の共有の使用例については、一つは他のユーザーに属しているアドレス帳を検索したい場合があります。同じサーバー上の他のユーザーのアドレス帳を検索するには、DAV：元本プロパティ検索REPORT [RFC3744]は一致するプロパティのためのプリンシパルを検索し、一致する主要リソースに対して指定されたプロパティを返すために使用することができます。 「ローリー」という名前のユーザーが所有しているアドレス帳を検索するには、REPORTリクエストボディは次のようになります。
<?xml version="1.0" encoding="utf-8" ?> <D:principal-property-search xmlns:D="DAV:"> <D:property-search> <D:prop> <D:displayname/> </D:prop> <D:match>Laurie</D:match> </D:property-search> <D:prop> <C:addressbook-home-set xmlns:C="urn:ietf:params:xml:ns:carddav"/> <D:displayname/> </D:prop> </D:principal-property-search>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：主-プロパティ検索のxmlns：D = "DAV："> <D：プロパティ検索> <D：プロペラ> <D：のDisplayName /> </ D：小道具> <D：試合>ローリー</ D：試合> </ D：プロパティ検索> <D：小道具> <C：アドレス帳-ホームセットのxmlns：C = "壷：IETF： params：XML：NS：CardDAVの "/> <D：DisplayNameに/> </ D：小道具> </ D：元本-プロパティ検索>
The server performs a case-sensitive or caseless search for a matching string subset of "Laurie" within the DAV:displayname property. Thus, the server might return "Laurie Dusseault", "Laurier Desruisseaux", or "Wilfrid Laurier" all as matching DAV:displayname values, and the address books for each of these.
表示名プロパティ：サーバがDAV内の「ローリー」の一致文字列のサブセットのための大文字と小文字を区別またはケースレス検索を行います。これらのそれぞれに対してのDisplayName値、およびアドレス帳：このように、サーバがDAVに一致するよう「ローリー・Dusseault」、「ロリエDesruisseaux」、または「ウィルフリッドローリエ」すべてを返すことがあります。
Name: addressbook
名前：アドレス帳
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Specifies the resource type of an address book collection.
目的：アドレス帳のコレクションのリソースタイプを指定します。
Description: See Section 5.2.
説明：5.2節を参照してください。
Definition:
定義：
<!ELEMENT addressbook EMPTY>
<！ELEMENTのアドレス帳EMPTY>
Name: supported-collation
名前：サポートされ、照合
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Identifies a single collation via its collation identifier as defined by [RFC4790].
目的：[RFC4790]で定義されるように、その照合識別子を介して、単一の照合を識別します。
Description: The CARDDAV:supported-collation contains the text of a collation identifier as described in Section 8.3.1.
説明：CardDAVの：8.3.1項に記載されるように支持された照合は、照合識別子のテキストを含みます。
Definition:
定義：
<!ELEMENT supported-collation (#PCDATA)>
<!-- PCDATA value: collation identifier -->
Name: addressbook-query
名前：アドレス帳クエリ
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Defines a report for querying address book data
目的：アドレス帳データを照会するためのレポートを定義します
Description: See Section 8.6.
説明：8.6節を参照してください。
Definition:
定義：
<!ELEMENT addressbook-query ((DAV:allprop |
DAV:propname |
DAV:prop)?, filter, limit?)>
Name: address-data
名前：住所データ
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Specifies one of the following:
目的：以下のいずれかを指定します。
1. The parts of an address object resource that should be returned by a given address book REPORT request, and the media type and version for the returned data; or
1.指定されたアドレス帳REPORT要求によって返されるべきアドレスオブジェクトリソース、および返されたデータのメディアタイプとバージョンの部品。または
2. The content of an address object resource in a response to an address book REPORT request.
2.アドレス帳REPORT要求に応じて、アドレスオブジェクトのリソースの内容。
Description: When used in an address book REPORT request, the CARDDAV:address-data XML element specifies which parts of address object resources need to be returned in the response. If the CARDDAV:address-data XML element doesn't contain any CARDDAV:prop elements, address object resources will be returned in their entirety. Additionally, a media type and version can be specified to request that the server return the data in that format if possible.
説明：アドレス帳REPORT要求で使用される場合には、CardDAVの：アドレスデータのXML要素は、アドレスオブジェクトのリソースの一部が応答で返される必要があるかを指定します。 CardDAVの場合：アドレスデータのXML要素は、任意のCardDAVのが含まれていません：要素PROP、アドレスオブジェクトのリソースは、その全体が返されます。また、メディアの種類とバージョンは、可能な場合、サーバーはその形式でデータを返すことを要求するように指定することができます。
Finally, when used in an address book REPORT response, the CARDDAV:address-data XML element specifies the content of an address object resource. Given that XML parsers normalize the two-character sequence CRLF (US-ASCII decimal 13 and US-ASCII decimal 10) to a single LF character (US-ASCII decimal 10), the CR character (US-ASCII decimal 13) MAY be omitted in address object resources specified in the CARDDAV:address-data XML element. Furthermore, address object resources specified in the CARDDAV:address-data XML element MAY be invalid per their media type specification if the CARDDAV:address-data XML element part of the address book REPORT request did not specify required vCard properties (e.g., UID, etc.) or specified a CARDDAV:prop XML element with the "novalue" attribute set to "yes".
アドレス帳REPORT応答に使用された場合最後に、CardDAVの：アドレスデータのXML要素は、アドレスオブジェクトリソースの内容を指定します。 XMLパーサは、2文字のシーケンスCRLF正常化することを考えると（小数点以下13 US-ASCIIをとUS-ASCII十進10）単一のLF文字（US-ASCII十進10）に、CR文字（US-ASCII十進13）省略されるかもしれませんアドレスデータのXML要素：CardDAVのに指定されたアドレスオブジェクト資源インチさらに、CardDAVのに指定されたアドレスオブジェクトの資源：CardDAVの場合は、アドレスデータのXML要素は、そのメディアタイプの仕様ごとに無効である可能性があります：アドレス帳REPORT要求のアドレス・データのXML要素の一部が必要なvCardの特性（例えば、UIDを指定していません、など）、またはCardDAVの指定：「はい」に設定された「NOVALUE」属性を持つXML要素小道具を。
Note: The CARDDAV:address-data XML element is specified in requests and responses inside the DAV:prop XML element as if it were a WebDAV property. However, the CARDDAV:address-data XML element is not a WebDAV property and as such it is not returned in PROPFIND responses nor used in PROPPATCH requests.
注意：CardDAVの：アドレスデータのXML要素は、DAV内部の要求と応答で指定されている：XML要素プロップそれはWebDAVのプロパティであるかのように。しかし、CardDAVの：アドレスデータのXML要素は、WebDAVプロパティではなく、そのようにはPROPFIND応答で返されていないにもPROPPATCH要求で使用されます。
Note: The address data embedded within the CARDDAV:address-data XML element MUST follow the standard XML character data encoding rules, including use of <, >, & etc., entity encoding or the use of a <![CDATA[ ... ]]> construct. In the latter case, the vCard data cannot contain the character sequence "]]>", which is the end delimiter for the CDATA section.
注：CardDAVの内に埋め込まれたアドレスデータ：アドレスデータのXML要素が＆LT ;,＆gt;で、＆＃038の使用を含む、標準的なXML文字データ符号化規則に従わなければなりません。など、エンティティのエンコーディングまたは<！[CDATA [...]]>構文を使用します。後者の場合には、vCardデータは、CDATAセクションの終了区切り文字である文字列「]]>」を含めることはできません。
Definition:
定義：
<!ELEMENT address-data (allprop | prop*)>
<！ELEMENTアドレスデータ（allprop |小道具*）>
when nested in the DAV:prop XML element in an address book REPORT request to specify which parts of address object resources should be returned in the response;
DAVにネストされたとき：アドレス帳REPORT要求でXML要素プロップアドレスオブジェクトのリソースの一部が応答で返されるべきかを指定します。
<!ELEMENT address-data (#PCDATA)> <!-- PCDATA value: address data -->
<！ELEMENTアドレス・データ（#PCDATA）> <！ - PCDATA値：アドレスデータ - >
when nested in the DAV:prop XML element in an address book REPORT response to specify the content of a returned address object resource.
DAVにするときにネスト：アドレス帳REPORT応答のXML要素プロップ返されたアドレスオブジェクトリソースの内容を指定します。
<!ATTLIST address-data content-type CDATA "text/vcard" version CDATA "3.0"> <!-- content-type value: a MIME media type --> <!-- version value: a version string -->
<！ATTLISTアドレス・データ・コンテンツ・タイプCDATA "テキスト/ vCardの" バージョンCDATA "3.0に"> <！ - コンテンツ・タイプ値：MIMEメディアタイプ - > <！ - バージョン値：バージョン文字列 - >
attributes can be used on each variant of the CALDAV:address-data XML element.
アドレスデータのXML要素：属性は、CalDAVに、各バリアントに使用することができます。
Name: allprop
名前：allprop
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Specifies that all vCard properties shall be returned.
目的：すべてのvCardのプロパティが返されなければならないことを指定します。
Description: This element can be used when the client wants all vCard properties of components returned by a report.
説明：この要素は、クライアントがレポートで返されるすべてのコンポーネントのvCardプロパティを希望する場合に使用することができます。
Definition:
定義：
<!ELEMENT allprop EMPTY>
<EMPTY allprop！ELEMENT>
Note: The CARDDAV:allprop element defined here has the same name as the DAV:allprop element defined in WebDAV. However, the CARDDAV:allprop element defined here uses the "urn:ietf:params:xml:ns:carddav" namespace, as opposed to the "DAV:" namespace used for the DAV:allprop element defined in WebDAV.
注：CardDAVの：WebDAVの中で定義されてallprop要素：ここで定義されallprop要素はDAVと同じ名前を持っています。しかし、CardDAVのは：名前空間とは対照的に、 "DAV："：WebDAVの中で定義されてallprop要素DAVのために使用される名前空間ここで定義されallprop要素は "：IETF：のparams：XML：：NS CardDAVの壷" を使用しています。
Name: prop
名前：小道具
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Defines which vCard properties to return in the response.
目的：vCardのプロパティが応答で返すように定義します。
Description: The "name" attribute specifies the name of the vCard property to return (e.g., "NICKNAME"). The "novalue" attribute can be used by clients to request that the actual value of the property not be returned (if the "novalue" attribute is set to "yes"). In that case, the server will return just the vCard property name and any vCard parameters and a trailing ":" without the subsequent value data.
説明：「名前」属性が（例えば、「ニックネーム」）を返すようにvCardのプロパティの名前を指定します。 「NOVALUE」属性は、（「NOVALUE」属性が「はい」に設定されている場合）、プロパティの実際の値が返されないことを要求するためにクライアントで使用することができます。その場合、サーバは単にvCardのプロパティ名と任意のvCardのパラメータと末尾を返します「：」以降の値データなし。
vCard allows a "group" prefix to appear before a property name in the vCard data. When the "name" attribute does not specify a group prefix, it MUST match properties in the vCard data without a group prefix or with any group prefix. When the "name" attribute includes a group prefix, it MUST match properties that have exactly the same group prefix and name. For example, a "name" set to "TEL" will match "TEL", "X-ABC.TEL", and "X-ABC-1.TEL" vCard properties. A "name" set to "X-ABC.TEL" will match an "X-ABC.TEL" vCard property only; it will not match "TEL" or "X-ABC-1.TEL".
vCardのは、「グループ」プレフィックスはvCardデータ内のプロパティ名の前に現れることができます。 「name」属性は、グループの接頭辞を指定しない場合は、グループの接頭辞なしまたは任意のグループの接頭辞でvCardデータのプロパティと一致しなければなりません。 「name」属性は、グループの接頭辞が含まれている場合、それはまったく同じグループプレフィックスと名前を持つプロパティと一致しなければなりません。たとえば、「名前」を「TEL」は「TEL」、「X-ABC.TEL」、および「X-ABC-1.TEL」vCardのプロパティと一致しますように設定します。 「名前」は「X-ABC.TEL」のみ「X-ABC.TEL」vCardのプロパティと一致しますように設定します。それは「TEL」または「X-ABC-1.TEL」と一致しません。
Definition:
定義：
<!ELEMENT prop EMPTY>
<！ELEMENT EMPTY小道具>
<!ATTLIST prop name CDATA #REQUIRED novalue (yes | no) "no"> <!-- name value: a vCard property name --> <!-- novalue value: "yes" or "no" -->
<！ATTLIST小道具名CDATA #REQUIREDのNOVALUE（はい|いいえ） "いいえ"> < - 名前値：！vCardのプロパティ名 - > <！ - NOVALUE値： "yes" または "no" - >
Note: The CARDDAV:prop element defined here has the same name as the DAV:prop element defined in WebDAV. However, the CARDDAV:prop element defined here uses the "urn:ietf:params:xml:ns:carddav" namespace, as opposed to the "DAV:" namespace used for the DAV:prop element defined in WebDAV.
注意：CardDAVのを：ここで定義された要素は、DAVと同じ名前を持つPROP：WebDAVの中で定義された要素PROP。しかし、CardDAVの：名前空間、「DAV：」とは対照的に、DAVのために使用される名前空間：WebDAVの中で定義された要素小道具ここで定義された要素小道具は「：IETF：のparams：XML：：NS CardDAVの壷」を使用しています。
Name: filter
名前：フィルタ
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Determines which matching objects are returned.
目的：一致するオブジェクトが返されるかを決定します。
Description: The "filter" element specifies the search filter used to match address objects that should be returned by a report. The "test" attribute specifies whether any (logical OR) or all (logical AND) of the prop-filter tests need to match in order for the overall filter to match.
説明：「フィルタ」要素は、レポートで返されるべきアドレスオブジェクトを一致させるために使用する検索フィルタを指定します。 「テスト」属性がプロパフィルタのテストのいずれか（論理和）または全て（論理AND）が一致するように、全体的なフィルタのために一致させる必要があるかどうかを指定します。
Definition:
定義：
<!ELEMENT filter (prop-filter*)>
<！ELEMENTフィルタ（プロップフィルター*）>
<!ATTLIST filter test (anyof | allof) "anyof"> <!-- test value: anyof logical OR for prop-filter matches allof logical AND for prop-filter matches -->
<！ATTLISTフィルタテスト（anyof | ALLOF） "anyof"> < - テスト値：！anyof論理和プロップフィルタにはALLOF論理ANDプロパフィルタ一致のために一致します - >
Name: prop-filter
名前：プロパフィルタ
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Limits the search to specific vCard properties.
目的：特定のvCardプロパティに検索を制限します。
Description: The CARDDAV:prop-filter XML element specifies search criteria on a specific vCard property (e.g., "NICKNAME"). An address object is said to match a CARDDAV:prop-filter if:
説明：CardDAVの：プロパフィルタXML要素が特定vCardのプロパティ（例えば、「ニックネーム」）で検索条件を指定します。プロパフィルタの場合：アドレスオブジェクトは、CardDAVのに一致するように言われています。
* A vCard property of the type specified by the "name" attribute exists, and the CARDDAV:prop-filter is empty, or it matches any specified CARDDAV:text-match or CARDDAV:param-filter conditions. The "test" attribute specifies whether any (logical OR) or all (logical AND) of the text-filter and param-filter tests need to match in order for the overall filter to match.
*「名前」属性が存在し、CardDAVので指定されたタイプのvCardのプロパティ：プロップフィルタが空である、またはそれが指定した任意のCardDAVの一致する：テキストマッチやCardDAVの：PARAM-フィルタ条件を。 「テスト」属性は、テキストフィルタとのparam-フィルタ試験のいずれか（論理和）または全て（論理AND）が一致するように、全体的なフィルタのために一致させる必要があるかどうかを指定します。
or:
または：
* A vCard property of the type specified by the "name" attribute does not exist, and the CARDDAV:is-not-defined element is specified.
*「名前」属性が存在しない、とCardDAVので指定されたタイプのvCardのプロパティ：-定義されていない要素が指定されています。
vCard allows a "group" prefix to appear before a property name in the vCard data. When the "name" attribute does not specify a group prefix, it MUST match properties in the vCard data without a group prefix or with any group prefix. When the "name" attribute includes a group prefix, it MUST match properties that have exactly the same group prefix and name. For example, a "name" set to "TEL" will match "TEL", "X-ABC.TEL", "X-ABC-1.TEL" vCard properties. A "name" set to "X-ABC.TEL" will match an "X-ABC.TEL" vCard property only, it will not match "TEL" or "X-ABC-1.TEL".
vCardのは、「グループ」プレフィックスはvCardデータ内のプロパティ名の前に現れることができます。 「name」属性は、グループの接頭辞を指定しない場合は、グループの接頭辞なしまたは任意のグループの接頭辞でvCardデータのプロパティと一致しなければなりません。 「name」属性は、グループの接頭辞が含まれている場合、それはまったく同じグループプレフィックスと名前を持つプロパティと一致しなければなりません。たとえば、「名前」を「TEL」は「TEL」、「X-ABC.TEL」、「X-ABC-1.TEL」vCardのプロパティと一致しますように設定します。 「名前は」それは「TEL」または「X-ABC-1.TEL」と一致しないであろう、「X-ABC.TEL」のみ「X-ABC.TEL」vCardのプロパティと一致しますように設定します。
Definition:
定義：
<!ELEMENT prop-filter (is-not-defined |
(text-match*, param-filter*))>
<!ATTLIST prop-filter name CDATA #REQUIRED test (anyof | allof) "anyof"> <!-- name value: a vCard property name (e.g., "NICKNAME") test value: anyof logical OR for text-match/param-filter matches allof logical AND for text-match/param-filter matches -->
<！ATTLISTプロパフィルタ名CDATA #REQUIREDテスト（anyof | ALLOF） "anyof"> < - 名前値：vCardのプロパティ名（例えば、 "ニックネーム"）テスト値：anyof論理和テキストマッチ/ PARAMのための！ -filterはALLOF論理ANDテキストマッチ/ PARAM-フィルタ一致のために一致します - >
Name: param-filter
名前：PARAM-フィルタ
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Limits the search to specific parameter values.
目的：特定のパラメータの値に検索を制限します。
Description: The CARDDAV:param-filter XML element specifies search criteria on a specific vCard property parameter (e.g., TYPE) in the scope of a given CARDDAV:prop-filter. A vCard property is said to match a CARDDAV:param-filter if:
説明：CardDAVの：プロパフィルタ：PARAMフィルタXML要素は、所与のCardDAVの範囲の特定のvCardのプロパティ・パラメータ（例えば、TYPE）に検索条件を指定します。場合のparam-フィルタ：vCardのプロパティはCardDAVのに一致するように言われています。
* A parameter of the type specified by the "name" attribute exists, and the CARDDAV:param-filter is empty, or it matches the CARDDAV:text-match conditions if specified.
*「名前」属性が存在し、CardDAVので指定された型のパラメータ：PARAM-フィルタが空である、またはそれはCardDAVの一致した：指定された場合は、テキストマッチ条件を。
or:
または：
* A parameter of the type specified by the "name" attribute does not exist, and the CARDDAV:is-not-defined element is specified.
*「名前」属性が存在しない、とCardDAVので指定された型のパラメータ：-定義されていない要素が指定されています。
Definition:
定義：
<!ELEMENT param-filter (is-not-defined | text-match)?>
<！ELEMENT PARAM-フィルター（ - - 定義されていない|テキストマッチ）？>
<!ATTLIST param-filter name CDATA #REQUIRED> <!-- name value: a property parameter name (e.g., "TYPE") -->
<！ATTLISTのparam-フィルタ名CDATA #REQUIRED> <！ - 名前値：プロパティのパラメータ名（例えば、 "TYPE"） - >
Name: is-not-defined
名前：-定義されていません
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Specifies that a match should occur if the enclosing vCard property or parameter does not exist.
目的：囲むvCardのプロパティまたはパラメータが存在しない場合、一致が発生するように指定します。
Description: The CARDDAV:is-not-defined XML element specifies that a match occurs if the enclosing vCard property or parameter value specified in an address book REPORT request does not exist in the address data being tested.
説明：CardDAVの： - 定義されていないXML要素は、アドレス帳レポート要求で指定された囲みvCardのプロパティまたはパラメータ値がテストされたアドレスデータに存在しない場合、一致が発生したことを指定します。
Definition:
定義：
<!ELEMENT is-not-defined EMPTY>
<！ELEMENTはEMPTY-定義されていません>
Name: text-match
名前：テキストマッチ
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Specifies a substring match on a vCard property or parameter value.
目的：vCardのプロパティまたはパラメータの値にサブストリングの一致を指定します。
Description: The CARDDAV:text-match XML element specifies text used for a substring match against the vCard property or parameter value specified in an address book REPORT request.
説明：CardDAVの：テキストマッチXML要素は、アドレス帳REPORT要求で指定されたvCardのプロパティまたはパラメータ値に対する部分文字列の一致のために使用されるテキストを指定します。
The "collation" attribute is used to select the collation that the server MUST use for character string matching. In the absence of this attribute, the server MUST use the "i;unicode-casemap" collation.
「照合」属性は、サーバーが文字列マッチングに使用しなければならない照合を選択するために使用されます。照合;この属性がない場合には、サーバーは、「ユニコード・CASEMAP I」を使用しなければなりません。
The "negate-condition" attribute is used to indicate that this test returns a match if the text matches, when the attribute value is set to "no", or return a match if the text does not match, if the attribute value is set to "yes". For example, this can be used to match components with a CATEGORIES property not set to PERSON.
属性値が設定されている場合、テキストは、属性値が「なし」に設定されている場合、一致する、またはテキストが一致しない場合、一致を返す場合は、「否定条件を」属性はこのテストが試合を返すことを示すために使用されます"yes" に。例えば、これは人に設定されていないカテゴリプロパティを持つコンポーネントを一致させるために使用することができます。
The "match-type" attribute is used to indicate the type of match operation to use. Possible choices are:
「マッチタイプ」属性が使用するマッチ操作の種類を示すために使用されます。可能な選択肢は次のとおりです。
"equals" - an exact match to the target string
「等しい」 - ターゲット文字列に正確に一致します
"contains" - a substring match, matching anywhere within the target string
「を含む」 - サブストリングの一致を、対象文字列内のどこにでもマッチします
"starts-with" - a substring match, matching only at the start of the target string
「始まり-で」 - サブストリングの一致、ターゲット文字列の先頭でのみ一致
"ends-with" - a substring match, matching only at the end of the target string
「終了-と」 - サブストリングの一致、ターゲット文字列の末尾にのみ一致します
Definition:
定義：
<!ELEMENT text-match (#PCDATA)>
<!-- PCDATA value: string -->
<!ATTLIST text-match collation CDATA "i;unicode-casemap" negate-condition (yes | no) "no" match-type (equals|contains|starts-with|ends-with) "contains">
<！ATTLISTテキストマッチ照合は、CDATAは "私、ユニコード-CASEMAP" 否定しない条件（YES | NO）、 "ノー" のマッチタイプ（等しい|が含まれている| - で始まる|-で終わる） "が含まれて">
Name: limit
名前：制限
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Specifies different types of limits that can be applied to the results returned by the server.
目的：サーバから返された結果に適用することもできる限界の種類を指定します。
Description: The CARDDAV:limit XML element can be used to specify different types of limits that the client can request the server to apply to the results returned by the server. Currently, only the CARDDAV:nresults limit can be used; other types of limit could be defined in the future.
説明：CardDAVの：制限XML要素は、クライアントがサーバから返された結果に適用するサーバーを要求することができる限界の異なるタイプを指定するために使用することができます。現在、唯一のCardDAVの：nresultsリミットは使用することができます。制限の他のタイプは、将来的に定義することができます。
Definition:
定義：
<!ELEMENT limit (nresults)>
<！ELEMENTリミット（結果）>
Name: nresults
名前：結果
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: Specifies a limit on the number of results returned by the server.
目的：サーバーから返される結果の数の制限を指定します。
Description: The CARDDAV:nresults XML element contains a requested maximum number of DAV:response elements to be returned in the response body of a query. The server MAY disregard this limit. The value of this element is an unsigned integer.
説明：CardDAVの：nresults XML要素は、DAVの要求の最大数が含まれています応答要素は、クエリの応答ボディに返されます。サーバーは、この制限を無視することがあります。この要素の値は、符号なし整数です。
Definition:
定義：
<!ELEMENT nresults (#PCDATA)>
<!-- nresults value: unsigned integer, must be digits -->
Name: addressbook-multiget
名前：アドレス帳、multiget
Namespace: urn:ietf:params:xml:ns:carddav
名前空間：URN：IETF：のparams：XML：NS：CardDAVの
Purpose: CardDAV report used to retrieve specific address objects via their URIs.
目的：自分のURIを経由して特定のアドレスオブジェクトを取得するために使用CardDAVのレポート。
Description: See Section 8.7.
説明：8.7項を参照してください。
Definition:
定義：
<!ELEMENT addressbook-multiget ((DAV:allprop |
DAV:propname |
DAV:prop)?,
DAV:href+)>
[RFC2782] defines a DNS-based service discovery protocol that has been widely adopted as a means of locating particular services within a local area network and beyond, using SRV RRs.
[RFC2782]は広範囲のSRV RRを使用して、ローカルエリアネットワーク以降内の特定のサービスの位置を特定する手段として採用されているDNSベースのサービス発見プロトコルを定義します。
This specification adds two service types for use with SRV records:
この仕様は、SRVレコードで使用するための2つのサービスタイプを追加します。
carddav: Identifies a CardDAV server that uses HTTP without TLS [RFC2818].
CardDAVの：TLS [RFC2818]なしHTTPを使用してCardDAVのサーバを識別します。
carddavs: Identifies a CardDAV server that uses HTTP with TLS [RFC2818].
carddavsは：TLS [RFC2818]でHTTPを使用してCardDAVのサーバを識別します。
Example: non-TLS service record
例：非TLSサービスレコード
_carddav._tcp SRV 0 1 80 addressbook.example.com.
_carddav._tcpのSRV 0 1 80 addressbook.example.com。
Example: TLS service
例：TLSサービス
_carddavs._tcp SRV 0 1 443 addressbook.example.com.
_carddavs._tcpのSRV 0 1 443 addressbook.example.com。
CardDAV allows internationalized strings to be stored and retrieved for the description of address book collections (see Section 6.2.1).
CardDAVのは、国際化された文字列が格納されているアドレス帳のコレクション（6.2.1項を参照）の説明については、検索することができます。
The CARDDAV:addressbook-query REPORT (Section 8.6) includes a text searching option controlled by the CARDDAV:text-match element and details of character handling are covered in the description of that element (see Section 10.5.4).
CardDAVの：アドレス帳問合せレポート（8.6節）はCardDAVのによって制御されるテキスト検索オプションが含まれます。テキストマッチ要素を、文字の取り扱いの詳細については、（10.5.4項を参照）、その要素の説明で覆われています。
HTTP protocol transactions are sent in the clear over the network unless protection from snooping is negotiated. This can be accomplished by use of TLS as defined in [RFC2818]. In particular, if HTTP Basic authentication [RFC2617] is available, the server MUST allow TLS to be used at the same time, and it SHOULD prevent use of Basic authentication when TLS is not in use. Clients SHOULD use TLS whenever possible.
スヌーピングからの保護が交渉されない限り、HTTPプロトコルのトランザクションは、ネットワークを介して平文で送信されます。 [RFC2818]で定義されるように、これは、TLSを使用することによって達成することができます。具体的には、HTTP基本認証[RFC2617]が利用可能である場合、サーバはTLSを同時に使用することを許容しなければなりません、及びTLSが使用されていないときには、基本認証の使用を防止するはずです。可能な限り、クライアントはTLSを使用すべきです。
With the ACL extension [RFC3744] present, WebDAV allows control over who can access (read or write) any resource on the WebDAV server. In addition, WebDAV ACL provides for an "inheritance" mechanism, whereby resources may inherit access privileges from other resources. Often, the "other" resource is a parent collection of the resource itself. Servers are able to support address books that are "private" (accessible only to the "owner"), "shared" (accessible to the owner and other specified authenticated users), and "public" (accessible to any authenticated or unauthenticated users). When provisioning address books of a particular type, servers MUST ensure that the correct privileges are applied on creation. In particular, private and shared address books MUST NOT be accessible by unauthenticated users (to prevent data from being automatically searched or indexed by web "crawlers").
ACL拡張[RFC3744]現在では、WebDAVは、WebDAVサーバー上（読み取りまたは書き込み）任意のリソースにアクセスできるユーザーを制御できます。また、WebDAVのACLは、リソースが他のリソースからのアクセス権限を継承することができることにより、「継承」機構を提供します。多くの場合、「その他」のリソースは、リソース自体の親コレクションです。サーバは、（任意の認証済みまたは認証されていないユーザーがアクセス可能）「プライベート」（唯一の「所有者」へのアクセス）されているアドレス帳をサポートすることができ、（所有者およびその他の指定された認証されたユーザがアクセス可能）「共有」、および「パブリック」 。特定の種類のアドレス帳をプロビジョニングする場合、サーバは、適切な権限が作成時に適用されていることを確認しなければなりません。特に、プライベートと共有アドレス帳で（自動的に検索やウェブ「クローラ」でインデックス化されてからデータを防ぐために）認証されていないユーザーによってアクセス可能であってはなりません。
Clients SHOULD warn users in an appropriate fashion when they copy or move address data from a private address book to a shared address book or public address book. Clients SHOULD provide a clear indication as to which address books are private, shared, or public. Clients SHOULD provide an appropriate warning when changing access privileges for a private or shared address book with data so as to allow unauthenticated users access.
クライアントは、コピーしたときに、適切な方法でユーザーに警告するか、共有アドレス帳またはパブリックアドレス帳にプライベートアドレス帳からアドレスデータを移動する必要があります。クライアントは、そのアドレス帳は、プライベート共有、または公開されてするように明確な指標を提供する必要があります。認証されていないユーザーのアクセスを許可するようにデータをプライベートまたは共有アドレス帳のアクセス権限を変更する場合、クライアントは適切な警告を提供する必要があります。
This specification currently relies on standard HTTP authentication mechanisms for identifying users. These comprise Basic and Digest authentication [RFC2617] as well as TLS [RFC2818] using client-side certificates.
この仕様は、現在のユーザを識別するための標準的なHTTP認証メカニズムに依存しています。これらは、クライアント側の証明書を使用して基本とダイジェスト認証[RFC2617]と同様にTLS [RFC2818]を含みます。
This document uses a URN to describe a new XML namespace conforming to the registry mechanism described in [RFC3688].
この文書では、[RFC3688]で説明登録メカニズムに準拠した新しいXML名前空間を記述するためにURNを使用しています。
Registration request for the carddav namespace:
CardDAVの名前空間の登録要求：
URI: urn:ietf:params:xml:ns:carddav
URI：URN：IETF：のparams：XML：NS：CardDAVの
Registrant Contact: The IESG <iesg@ietf.org>
登録者連絡先：IESG <iesg@ietf.org>
XML: None - not applicable for namespace registrations.
XML：なし - 名前空間の登録には適用されません。
Thanks go to Lisa Dusseault and Bernard Desruisseaux for their work on CalDAV, on which CardDAV is heavily based. The following individuals contributed their ideas and support for writing this specification: Mike Douglass, Stefan Eissing, Helge Hess, Arnaud Quillaud, Julian Reschke, Elias Sinderson, Greg Stein, Wilfredo Sanchez, and Simon Vaillancourt.
おかげでCardDAVのが頻繁に基づいているのCalDAVに自分の仕事のためにリサDusseaultとバーナードDesruisseauxに行きます。マイク・ダグラス、ステファンEissing、ヘルゲ・ヘス、アルノーQuillaud、ジュリアンReschke、エリアスSinderson、グレッグ・スタイン、ウィルフレド・サンチェス、そしてサイモンVaillancourt：以下の個人はこの仕様書を書くためのアイデアやサポートに貢献しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[RFC2426]ドーソン、F.とT.ハウズ、 "vCardのMIMEディレクトリプロフィール"、RFC 2426、1998年9月。
[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.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、2000年5月。
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002.
[RFC3253] Clemm、G.、Amsden、J.、エリソン、T.、Kaler、C.、およびJ.ホワイトヘッド "のWebDAV（Web分散オーサリングとバージョン）のバージョンの拡張"、RFC 3253、2002年3月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004.
[RFC3744] Clemm、G.、Reschke、J.、Sedlar、E.、およびJ.ホワイトヘッド、 "Web分散オーサリングとバージョン管理（WebDAV）アクセス制御プロトコル"、RFC 3744、2004年5月。
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[RFC4790]ニューマン、C.、Duerst、M.、およびA. Gulbrandsenの、 "インターネットアプリケーションプロトコル照合レジストリ"、RFC 4790、2007年3月。
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918] Dusseault、L.、RFC 4918、2007年6月 "Web分散オーサリングとバージョン管理（WebDAV）のためのHTTP拡張機能"。
[RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, October 2007.
[RFC5051]のCrispin、M.、 "I;ユニコード-CASEMAP - シンプルなUnicode照合アルゴリズム"、RFC 5051、2007年10月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC5397] Sanchez, W. and C. Daboo, "WebDAV Current Principal Extension", RFC 5397, December 2008.
[RFC5397]サンチェス、W.とC. Daboo、 "WebDAVの現在のプリンシパル拡張"、RFC 5397、2008年12月。
[RFC5689] Daboo, C., "Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)", RFC 5689, September 2009.
[RFC5689] Daboo、C.、RFC 5689、2009年9月 "Web分散オーサリングとバージョン管理（WebDAV）の拡張MKCOL"。
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011.
[RFC6350]ペロー、S.、 "vCardのフォーマット仕様"、RFC 6350、2011年8月。
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-XML-20081126]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.、MALER、E.、およびF. Yergeau、 "拡張マークアップ言語（XML）1.0（第5版）"、 World Wide Web Consortium（W3C）の勧告REC-XML-20081126、2008年11月、<http://www.w3.org/TR/2008/REC-xml-20081126>。
[IMSP] Myers, J., "IMSP - Internet Message Support Protocol", Work in Progress, June 1995.
[IMSP]マイヤーズ、J.、 "IMSP - インターネットメッセージのサポートプロトコル"、進歩、1995年6月での作業。
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"、RFC 4510、2006年6月。
Author's Address
著者のアドレス
Cyrus Daboo Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 USA
サイラスDabooアップル社1無限ループクパチーノ、CA 95014 USA
EMail: cyrus@daboo.name URI: http://www.apple.com/
電子メール：cyrus@daboo.name URI：http://www.apple.com/