- From: Dominique Hazael-Massieux via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 13 Jan 2011 10:10:30 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/messaging
In directory hutz:/tmp/cvs-serv24747
Modified Files:
Overview.html
Log Message:
stab at reworking messaging API per ACTION-325
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/messaging/Overview.html,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -d -r1.27 -r1.28
--- Overview.html 5 Jan 2011 11:07:57 -0000 1.27
+++ Overview.html 13 Jan 2011 10:10:28 -0000 1.28
@@ -100,23 +100,25 @@
- <section id='informative'>
+ <section class='informative' id="intro">
<h1>Introduction</h1>
<p>
- The Messaging API defines a high-level interface to Messaging functionality,
+ The Messaging API defines a high-level interface to messaging functionality,
- including SMS, MMS and e-mail. It includes APIs to create and send messages.
+ including SMS, MMS and e-mail. It includes APIs to create and send messages.
</p>
- <p>
-
- The following code extracts illustrate how to create and send messages.
+ <p>These APIs complement what <code>sms:</code>, <code>mms:</code>, and <code>mailto:</code> URI schemes with:</p>
+ <ul>
+ <li>the possibility to attach files to messages,</li>
+ <li>a callback on success / error when a message is sent.</li>
+ </ul>
- </p>
+ <p>The following code extracts illustrate how to create and send messages. </p>
<div> <p>
@@ -172,7 +174,7 @@
<p class='note'>
- The specification does not replace RFCs for Mail or SMS URLs but provides complementary functionality to these.
+ The specification does not replace RFCs for Mail or SMS URLs but provides complementary functionality to these (attachments, callbacks).
</p>
@@ -189,37 +191,17 @@
The API defined in this specification can be used to create and send messages through different technologies.
Sending messages usually has an associated cost (especially SMSs and MMSs), hence a conforming implementation of this specification
- MUST provide a mechanism that ensures that no message is sent without the user's express permission.
-
- </p>
-
- <p>
- The methods for sending messages that require user's express permission to be accessed are:
- </p>
- <p>
- SMSMessage.send(), MMSMessage.send() and EmailMessage.send().
- </p>
-
- <p>
- Unless the <a>user agent</a> has a prearranged trust relationship with the user, it MUST acquire permission through a user interface.
- The cost of sending the message may depend on the message attributes (e.g. destination address) or external conditions
- (e.g. roaming status). Due to that, the user interface MUST include the type of message to be sent and its destination
- (i.e. the "to" attribute of the message) so that the user can take an informed decision. Additionally, the user interface MUST
- include the URI of the document origin, as defined in [[!HTML5]].
- </p>
+ should provide a mechanism that ensures that no message is sent without the user's consent.
+ </p>
<p>
- Obtaining permission through the user interface for one invocation of the method MUST NOT imply consent for future invocations
- of the same method, i.e. user interface authorization must be done every time the send method is invoked.
+ The methods for sending messages that require user's express permission to be accessed are: <code>SMSMessage.send()</code>, <code>MMSMessage.send()</code> and <code>EmailMessage.send()</code>.
</p>
-
-
- <p>
- A <a>user agent</a> may have prearranged trust relationships that do not require such user interfaces. For example, while a Web
- browser will present a user interface when a Web site requests sending an SMS, a Widget Runtime MAY have a prearranged,
- delegated security relationship with the user and, as such, a suitable alternative security and privacy mechanism with which to
- authorize that operation.
- </p>
+
+ <p>Since the implications of sending a given message may depend on the message attributes (e.g. destination address) and content, the approach used to ensure user’s consent should include the relevant information, typically the type of message and its destination address.</p>
+
+ <p>A typical (but not required) way of ensuring user’s consent would be to use the same mechanism as the one used when the user click on a link using one the relevant URI schemes, for instance, bringing up the platform messaging application with pre-filled fields.</p>
+ <p>In general, user’s consent is expected to be confirmed for each invocation of the <code>send</code> methods.</p>
</section>
@@ -244,8 +226,8 @@
</p>
- <table border="1">
-
+ <table class="simple">
+ <thead>
<tr>
<th>Attribute</th>
@@ -257,112 +239,113 @@
<th>e-mail</th>
</tr>
-
+ </thead>
+ <tbody>
<tr>
- <td><code>from</code></td>
+ <th><code>from</code></th>
- <td>X</td>
+ <td title="supported">✓</td>
- <td>X</td>
+ <td title="supported">✓</td>
- <td>X</td>
+ <td title="supported">✓</td>
</tr>
<tr>
- <td><code>sentTime</code></td>
+ <th><code>sentTime</code></th>
- <td>X</td>
+ <td title="supported">✓</td>
- <td>X</td>
+ <td title="supported">✓</td>
- <td>X</td>
+ <td title="supported">✓</td>
</tr>
<tr>
- <td><code>to</code></td>
+ <th><code>to</code></th>
- <td>X</td>
+ <td title="supported">✓</td>
- <td>X</td>
+ <td title="supported">✓</td>
- <td>X</td>
+ <td title="supported">✓</td>
</tr>
<tr>
- <td><code>cc</code></td>
+ <th><code>cc</code></th>
- <td>-</td>
+ <td title="not available">N/A</td>
- <td>-</td>
+ <td title="not available">N/A</td>
- <td>X</td>
+ <td title="supported">✓</td>
</tr>
<tr>
- <td><code>bcc</code></td>
+ <th><code>bcc</code></th>
- <td>-</td>
+ <td title="not available">N/A</td>
- <td>-</td>
+ <td title="not available">N/A</td>
- <td>X</td>
+ <td title="supported">✓</td>
</tr>
<tr>
- <td><code>subject</code></td>
+ <th><code>subject</code></th>
- <td>-</td>
+ <td title="not available">N/A</td>
- <td>X</td>
+ <td title="supported">✓</td>
- <td>X</td>
+ <td title="supported">✓</td>
</tr>
<tr>
- <td><code>body</code></td>
+ <th><code>body</code></th>
- <td>X</td>
+ <td title="supported">✓</td>
- <td>X</td>
+ <td title="supported">✓</td>
- <td>X</td>
+ <td title="supported">✓</td>
</tr>
<tr>
- <td><code>attachments</code></td>
+ <th><code>attachments</code></th>
- <td>-</td>
+ <td title="not available">N/A</td>
- <td>X</td>
+ <td title="supported">✓</td>
- <td>X</td>
+ <td title="supported">✓</td>
</tr>
<tr>
- <td><code>priority</code></td>
+ <th><code>priority</code></th>
- <td>-</td>
+ <td title="not available">N/A</td>
- <td>-</td>
+ <td title="not available">N/A</td>
- <td>X</td>
+ <td title="supported">✓</td>
</tr>
@@ -416,7 +399,7 @@
<dd>
- The root node from which the messaging functionality can be accessed.
+ The object from which the messaging functionality can be accessed.
</dd>
@@ -436,6 +419,8 @@
</p>
+ <p class="issue">The Working Group plans in reworking this interface to rely more directly on URI schemes rather than having a per messaging protocol method.</p>
+
<dl title='interface MessagingManager' class='idl'>
<dt>SMSMessage createSMS (in SMSProperties smsProperties)</dt>
@@ -572,7 +557,7 @@
<dd>
- Asynchronous method to request sending an SMS. Upon a successful invocation the message is delivered to the network. The <code>pendingOp</code> returns object allows canceling the sending of the message.
+ Asynchronous method to request sending an SMS. The <code>pendingOp</code> return object allows canceling the sending of the message.
<dl class='parameters'>
@@ -644,17 +629,6 @@
- <dt>
-
- readonly attribute DOMString from
-
- </dt>
-
- <dd>
-
- The MSISDN of the MMS sender.
-
- </dd>
@@ -663,7 +637,7 @@
<dd>
- Asynchronous method to request sending an MMS. Upon a successful invocation the message is delivered to the network. The <code>pendingOp</code> returns object allows canceling the sending of the message.
+ Asynchronous method to request sending an MMS. The <code>pendingOp</code> return object allows canceling the sending of the message.
<dl class='parameters'>
@@ -734,18 +708,6 @@
</dd>
- <dt>
-
- readonly attribute EmailAddress from
-
- </dt>
-
- <dd>
-
- The address and name of the e-mail sender. In order to fill-in this attribute, different criteria MAY be used to select the e-mail account:
- e.g. use a pre-defined default account, promt the user to select the account...
-
- </dd>
@@ -756,8 +718,8 @@
<dd>
- Asynchronous method to request sending an e-mail. Upon a successful invocation the message is delivered to the network.
- The <code>pendingOp</code> returns object allows cancelling the sending of the message.
+ Asynchronous method to request sending an e-mail.
+ The <code>pendingOp</code> return object allows cancelling the sending of the message.
<dl class='parameters'>
@@ -1296,13 +1258,7 @@
<h2>Features for Future Consideration</h2>
- <p>
-
- This is a list of features that have been discussed with respect to this version of the API but for which it has been decided that if they are included it will be in a future revision.
-
- </p>
-
- <h3>ToDo</h3>
+ <p>The following messaging functionalities have been delayed to a future version of the API.</p>
<ul>
<li>Message subscription and reading.</li>
Received on Thursday, 13 January 2011 10:10:32 UTC