- From: Robin Berjon via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 19 Jan 2010 17:23:15 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/contacts
In directory hutz:/tmp/cvs-serv22284
Modified Files:
FPWD.html
Log Message:
update the generated draft
Index: FPWD.html
===================================================================
RCS file: /sources/public/2009/dap/contacts/FPWD.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- FPWD.html 19 Jan 2010 17:17:40 -0000 1.2
+++ FPWD.html 19 Jan 2010 17:23:12 -0000 1.3
@@ -439,7 +439,7 @@
pre.sh_sourceCode .sh_paren { color: red; }
pre.sh_sourceCode .sh_attribute { color: #006400; }
-</style><link charset="utf-8" type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD"></head><body style="display: inherit;"><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a></p><h1>The Contacts API</h1><h2><acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 19 January 2010</h2><dl><dt>This Version:</dt><dd><a href="http://www.w3.org/TR/2010/WD-contacts-api-20100119/">http://www.w3.org/TR/2010/WD-contacts-api-20100119/</a></dd><dt>Latest Published Version:</dt><dd><a href="http://www.w3.org/TR/contacts-api/">http://www.w3.org/TR/contacts-api/</a></dd><dt>Latest Editor's Draft:</dt><dd><a href="http://dev.w3.org/2009/dap/contacts/">http://dev.w3.org/2009/dap/contacts/</a></dd><dt>Editor:</dt><dd>Richard Tibbett, France Telecom</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2010 <a href="http://www.w3.org/"><acronym titl="World Wide Web Consortium"><acronym title="World Wide Web Consortium">W3C</acronym></acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology"><acronym title="Massachusetts Institute of Technology">MIT</acronym></acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
+</style><link charset="utf-8" type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD"></head><body style="display: inherit;"><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a></p><h1>The Contacts API</h1><h2><acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 21 January 2010</h2><dl><dt>This Version:</dt><dd><a href="http://www.w3.org/TR/2010/WD-contacts-api-20100121/">http://www.w3.org/TR/2010/WD-contacts-api-20100121/</a></dd><dt>Latest Published Version:</dt><dd><a href="http://www.w3.org/TR/contacts-api/">http://www.w3.org/TR/contacts-api/</a></dd><dt>Latest Editor's Draft:</dt><dd><a href="http://dev.w3.org/2009/dap/contacts/">http://dev.w3.org/2009/dap/contacts/</a></dd><dt>Editor:</dt><dd>Richard Tibbett, France Telecom</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2010 <a href="http://www.w3.org/"><acronym titl="World Wide Web Consortium"><acronym title="World Wide Web Consortium">W3C</acronym></acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology"><acronym title="Massachusetts Institute of Technology">MIT</acronym></acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
<div class="introductory section" id="abstract"><h2>Abstract</h2>
<p>This specification defines an API that provides access to a user's unified address book.</p>
</div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p><p>This document was published by the <a href="http://www.w3.org/2009/dap/">Device APIs and Policy Working Group</a> as a First Public Working Draft. This document is intended to become a <acronym title="World Wide Web Consortium">W3C</acronym> Recommendation. If you wish to make comments regarding this document, please send them to <a href="mailto:public-device-apis@w3.org">public-device-apis@w3.org</a> (<a href="mailto:public-device-apis-request@w3.org?subject=subscribe">subscribe<a>, <a href="http://lists.w3.org/Archives/Public/public-device-apis/">archives</a>). All feedback is welcome.</p><p>Publication as a Working Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a href="http://www.w3.org/2004/01/pp-impl/43696/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believs contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div><div class="section" id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li><a href="#conformance"><span class="secno">1. </span>Conformance</a></li><li><a href="#introduction"><span class="secno">2. </span>Introduction</a></li><li><ul class="toc"><li><a href="#usage-examples"><span class="secno">2.1 </span>Usage Examples</a></li></ul></li><li><a href="#security-and-privacy-considerations"><span class="secno">3. </span>Security and Privacy Considerations</a></li><li><ul class="toc"><li><a href="#privacy-considerations-for-implementors-of-the-contacts-api"><span class="secno">3.1 </span>Privacy considerations for implementors of the Contacts API</a></li>li><a href="#privacy-considerations-for-recipients-of-contact-information"><span class="secno">3.2 </span>Privacy considerations for recipients of contact information</a></li><li><a href="#additional-implementation-considerations"><span class="secno">3.3 </span>Additional implementation considerations</a></li></ul></li><li><a href="#api-description"><span class="secno">4. </span>API Description</a></li><li><ul class="toc"><li><a href="#servicecontacts-interface"><span class="secno">4.1 </span><span class="idlType formerLink idlType"><code>ServiceContacts</code></span> interface</a></li><li><ul class="toc"><li><a href="#attributes"><span class="secno">4.1.1 </span>Attributes</a></li></ul></li><li><a href="#contacts-interface"><span class="secno">4.2 </span><span class="idlType formerLink idlType"><code>Contacts</code></span> interface</a></li><li><ul class="toc"><li><a href="#methods"><span class="secno">4.2.1 </span>Methods</a></li></ul></li><li><a href="#contact-interface"><span class="secno">4.3 </span><san class="idlType formerLink idlType"><code>Contact</code></span> interface</a></li><li><ul class="toc"><li><a href="#attributes-1"><span class="secno">4.3.1 </span>Attributes</a></li><li><a href="#methods-1"><span class="secno">4.3.2 </span>Methods</a></li></ul></li><li><a href="#contactproperties-interface"><span class="secno">4.4 </span><span class="idlType formerLink idlType"><code>ContactProperties</code></span> interface</a></li><li><ul class="toc"><li><a href="#attributes-2"><span class="secno">4.4.1 </span>Attributes</a></li></ul></li><li><a href="#contactfield-interface"><span class="secno">4.5 </span><span class="idlType formerLink idlType"><code>ContactField</code></span> interface</a></li><li><ul class="toc"><li><a href="#attributes-3"><span class="secno">4.5.1 </span>Attributes</a></li></ul></li><li><a href="#contactaddress-interface"><span class="secno">4.6 </span><span class="idlType formerLink idlType"><code>ContactAddress</code></span> interface</a></li><li><ul class="toc"><li><a href="#attibutes-4"><span class="secno">4.6.1 </span>Attributes</a></li></ul></li><li><a href="#contactoptions-interface"><span class="secno">4.7 </span><span class="idlType formerLink idlType"><code>ContactOptions</code></span> interface</a></li><li><ul class="toc"><li><a href="#attributes-5"><span class="secno">4.7.1 </span>Attributes</a></li></ul></li><li><a href="#contactfindsuccesscb-interface"><span class="secno">4.8 </span><span class="idlType formerLink idlType"><code>ContactFindSuccessCB</code></span> interface</a></li><li><ul class="toc"><li><a href="#methods-2"><span class="secno">4.8.1 </span>Methods</a></li></ul></li><li><a href="#contactsuccesscb-interface"><span class="secno">4.9 </span><span class="idlType formerLink idlType"><code>ContactSuccessCB</code></span> interface</a></li><li><ul class="toc"><li><a href="#methods-3"><span class="secno">4.9.1 </span>Methods</a></li></ul></li><li><a href="#contacterrorcb-interface"><span class="secno">4.10 </span><span class="idlType formerLink idlType"><code>CotactErrorCB</code></span> interface</a></li><li><ul class="toc"><li><a href="#methods-4"><span class="secno">4.10.1 </span>Methods</a></li></ul></li><li><a href="#contacterror-interface"><span class="secno">4.11 </span><span class="idlType formerLink idlType"><code>ContactError</code></span> interface</a></li><li><ul class="toc"><li><a href="#constants"><span class="secno">4.11.1 </span>Constants</a></li></ul></li></ul></li><li><a href="#general-api-support"><span class="secno">5. </span>General API Support</a></li><li><ul class="toc"><li><a href="#genericerror-interface"><span class="secno">5.1 </span><span class="idlType formerLink idlType"><code>GenericError</code></span> interface</a></li><li><ul class="toc"><li><a href="#attributes-6"><span class="secno">5.1.1 </span>Attributes</a></li><li><a href="#constants-1"><span class="secno">5.1.2 </span>Constants</a></li></ul></li></ul></li><li><a href="#contact-search-processing-rules"><span class="secno">6. </span><span class="formerLink">Contact Search Procesing Rules</span></a></li><li><a href="#use-cases-and-requirements"><span class="secno">7. </span>Use Cases and Requirements</a></li><li><ul class="toc"><li><a href="#use-cases"><span class="secno">7.1 </span>Use Cases</a></li><li><a href="#requirements"><span class="secno">7.2 </span>Requirements</a></li></ul></li><li><a href="#features-for-future-consideration"><span class="secno">A. </span>Features for Future Consideration</a></li><li><a href="#acknowledgements"><span class="secno">B. </span>Acknowledgements</a></li><li><a href="#references"><span class="secno">C. </span>References</a></li><li><ul class="toc"><li><a href="#normative-references"><span class="secno">C.1 </span>Normative references</a></li><li><a href="#informative-references"><span class="secno">C.2 </span>Informative references</a></li></ul></li></ul></div>
@@ -746,12 +746,12 @@
};</span>
</pre><div class="section" id="attributes-1"><h4><span class="secno">4.3.1 </span>Attributes</h4><dl class="attributes"><dt id="widl-Contact-id"><code>id</code> of type <span class="idlAttrType"><a>DOMString</a></span>, readonly</dt><dd>
<p class="note">
- Perhaps we don't want to recommend the use of UUID URN here. Saying that id must be globally unique could suffice, and there may be good reasons why someone would want to use something else (e.g. a SHA mailbox as in FOAF).
+ Perhaps we don't want to recommend the use of <abbr title="Universally Unique IDentifier">UUID</abbr> URN here. Saying that id must be globally unique could suffice, and there may be good reasons why someone would want to use something else (e.g. a SHA mailbox as in FOAF).
</p>
<p>A globally unique identifier for the given <code>Contact</code> object. Each <code>Contact</code> referenced from <code>Contacts</code> <em title="must" class="rfc2119">must</em> include a non-empty <code>id</code> value.</p>
<p>An implementation <em title="must" class="rfc2119">must</em> maintain this globally unique resource identifier when a Contact is added to, or present within, an Address Book.</p>
<p>An implementation <em title="may" class="rfc2119">may</em> use an IANA registered identifier format. The value can also be a non-standard format.</p>
- <p>It is <em title="recommended" class="rfc2119">recommended</em> that an implementation assign the id attribute as a <abbr name="Universally Unique IDentifier">UUID</abbr> URN as defined in [<a href="#bib-RFC4122" rel="biblioentry" class="bibref">RFC4122</a>].</p>
+ <p>It is <em title="recommended" class="rfc2119">recommended</em> that an implementation assign the id attribute as a <abbr title="Universally Unique IDentifier"><abbr title="Universally Unique IDentifier">UUID</abbr></abbr> URN as defined in [<a href="#bib-RFC4122" rel="biblioentry" class="bibref">RFC4122</a>].</p>
<pre class="example sh_javascript sh_sourceCode"><span class="sh_cbracket">{</span>id<span class="sh_symbol">:</span> <span class="sh_string">'urn:uuid:d13d4fd0-4ce9-1cef-b1f2-10a9c1446bf0'</span><span class="sh_cbracket">}</span></pre>
<div><em>No exceptions.</em></div></dd></dl></div><div class="section" id="methods-1"><h4><span class="secno">4.3.2 </span>Methods</h4><dl class="methods"><dt id="widl-Contact-clone"><code>clone</code></dt><dd>
@@ -1246,28 +1246,28 @@
<h3><span class="secno">7.1 </span>Use Cases</h3>
<p>
- </p><h4>Use Case 1: Upload a set of contact details to a user's social network</h4>
+ </p><h4 id="uc1">Use Case 1: Upload a set of contact details to a user's social network</h4>
A user is registered on a number of different social networking sites and would like to upload some or all of their
address book contacts to the service. Using the Contacts API, the Web application has access to the user's address book,
subject to user opt-in, and it is therefore able to import the user's selected contacts in to their service.
<p>
- </p><h4>Use Case 2: Download a set of contact details from a user's social network</h4>
+ </p><h4 id="uc2">Use Case 2: Download a set of contact details from a user's social network</h4>
A social networking user would like to download some or all of their social network contacts to their native address book, in to their native
phone dialling application or in to another application for offline / non-web use. Using the Contacts API, the Web application provides the user with an export
function and, subject to user opt-in, the selected contacts can be downloaded and imported in to the user's address book.
<p>
- </p><h4>Use Case 3: A user would like to keep their work address book and personal address book seperate</h4>
+ </p><h4 id="uc3">Use Case 3: A user would like to keep their work address book and personal address book seperate</h4>
The Contacts API will provide all address book contacts in a unified way but the user would like to associate individual contacts
to individual address books - keeping their work and social address books seperated. The Contacts API must allow Web Applications to
distinguish between multiple address book stores and allow the user to manage different address books according to their needs.
<p>
- </p><h4>Use Case 4: A user maintains a single unified address book but would like to maintain groups of contacts within that address book</h4>
+ </p><h4 id="uc4">Use Case 4: A user maintains a single unified address book but would like to maintain groups of contacts within that address book</h4>
A user has a number of friends, family, colleagues and other contacts in their address book. They would like to create groups and assign
existing contacts to these groups. The user can create, update or remove as many groups as they like and equally they would like to be able to
add, remove and update the members assigned to those groups whenever they need to. The user's contacts can belong to multiple groups at the
@@ -1275,14 +1275,14 @@
<p>
- </p><h4>Use Case 5: Use a web interface to manage contact details on both the user's device and the web</h4>
+ </p><h4 id="uc5">Use Case 5: Use a web interface to manage contact details on both the user's device and the web</h4>
A Web Application is built that allows users to add, update and remove friend's contact details stored in their native address book.
The Web Application can add, remove and update contact details, subject to user opt-in, and these details are automatically propagated
from the web interface to the user's address book.
<p>
- </p><h4>Use Case 6: A user would like to export contacts from the one address book store and import them to another address book store</h4>
+ </p><h4 id="uc6">Use Case 6: A user would like to export contacts from the one address book store and import them to another address book store</h4>
The user maintains multiple address books that are stored on both the web and on their device(s). The user would like to move some or all of
their contacts from one address book store to another. Using the Contacts API, the user can assign contact details to different address book
stores. The underlying implementation will action the import/export process when the user changes to which address book store a contact is
@@ -1290,7 +1290,7 @@
<p>
- </p><h4>Use Case 7: A user would like to be notified when friends have a birthday coming up</h4>
+ </p><h4 id="uc7">Use Case 7: A user would like to be notified when friends have a birthday coming up</h4>
A user would like their favorite Web Application to inform them when all their friend's birthdays are coming up. The user imports some or all
of their address book contacts to the Web Application. The web application can read in the contacts' birthdays as well as other useful identifying
information (e.g. the contacts' names). The Web Application can then email, SMS or otherwise notify the user when a contact's birthday is coming
@@ -1298,7 +1298,7 @@
<p>
- </p><h4>Use Case 8: A user would like his/her contacts to update their own contact details via a mediating Web Application and sync any changes to their
+ </p><h4 id="uc8">Use Case 8: A user would like his/her contacts to update their own contact details via a mediating Web Application and sync any changes to their
current address book</h4>
User's contact details are constantly changing and being updated. A user has uploaded their address book to a Web Application which has then allowed
the user's contacts to update the details contained therein in a collaborative way. The user can then synchronise any changes made by his/her contacts
Received on Tuesday, 19 January 2010 17:23:16 UTC