- From: Dominique Hazael-Massieux via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 04 Jul 2011 12:59:46 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/messaging
In directory hutz:/tmp/cvs-serv26243
Modified Files:
Overview.html
Log Message:
*** empty log message ***
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/messaging/Overview.html,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -d -r1.47 -r1.48
--- Overview.html 4 Jul 2011 12:57:44 -0000 1.47
+++ Overview.html 4 Jul 2011 12:59:44 -0000 1.48
@@ -101,7 +101,7 @@
<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 and pre-defined attachments.</p>
- <p>In general, user’s consent is expected to be confirmed for each invocation of the <code>sendMessage</code> methods. Typically, the user agent would bring forward the application responsible for editing/sending the type of message with pre-filled entries, and the ability for the user to send the message through the said application.</p>
+ <p>In general, user’s consent is expected to be confirmed for each invocation of the <code>sendMessage</code> methods. Typically, the user agent would bring forward the application responsible for editing/sending the type of message with pre-filled entries, allowing the user to send the message through the said application (after edits if she wants so).</p>
</section>
Received on Monday, 4 July 2011 12:59:50 UTC