2009/dap/messaging Overview.html,1.14,1.15

Update of /sources/public/2009/dap/messaging
In directory hutz:/tmp/cvs-serv19130/messaging

Modified Files:
	Overview.html 
Log Message:
Section 7 removed and actions 140-141 addressed 

Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/messaging/Overview.html,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -d -r1.14 -r1.15
--- Overview.html	7 Apr 2010 15:10:46 -0000	1.14
+++ Overview.html	8 Apr 2010 20:49:51 -0000	1.15
@@ -43,7 +43,7 @@
     Since not all devices will have all messaging functionality (e.g. a phone may have only SMS and MMS while a PC may have only email) there is a need to indicate that conformant implementations need only expose available functionality.
     </p>
 
-	<p>Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [[!WEBIDL]], as this specification uses that specification’s terminology.</p> 
+	<p>Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [[!WEBIDL]], as this specification uses that specificationŐs terminology.</p> 
     
     
     <section id='informative'>
@@ -101,7 +101,7 @@
     	</p>
     	
     	<p class='note'>
-    	The specification does not replace RFCs for Mail or SMS URLs. The specification includes complementary functionality to these. Please see <a  href='#scheme-based-messaging-options'>Scheme based Messaging Options</a> section for a discussion on this topic.
+    	The specification does not replace RFCs for Mail or SMS URLs. The specification includes complementary functionality to these.
     	</p>
     	</section>
     
@@ -391,14 +391,14 @@
 				</dd>
 				
 				<dt>
-					attribute DOMString from
+					readonly attribute DOMString from
 				</dt>
 				<dd>
 					The sender the message. 
 				</dd>
 				
 				<dt>
-					attribute DOMString attachments[]
+					attribute File[] attachments 
 				</dt>
 				<dd>
 					The list of paths to attachments that will be sent together with message
@@ -433,56 +433,6 @@
 			</section>
     </section>
     
-   
-    
-    <section class="informative">
-      <h2>Scheme based messaging options</h2>
-      <section>
-      In addition to the messaging options described in this specification there is an option to use URL based schemes with email (mailto) RFC2368 and SMS RFC5724 for web page initiated messaging. 
-      
-      <section>
-      	<h3>SMS URI (RFC5724)</h3>
-      	<p>
-      	RFC5724 introduces a URI scheme similar to mailto to allow specifying recipients and body text for SMS messages. When a SMS URI is activated, the user agent may open an SMS messaging client to send an SMS. In similarity to mailto, this requires that the browser can handle the scheme and that an external SMS messaging program is correctly configured. There is no requirement that the SMS messaging program must be running same device as the user agent, allowing the use of e.g. external web based services to fulfill the request. The URI specification requires one or more phone numbers (a la RFC3966 Section 5.1) and an optional percent-encoded UTF-8 text body. The implementation is required to correctly translate the text body to suitable encoding.
-      	</p>
-      
-      	<p>
-      	The user agent must handle the SMS URI with similar carefulness as specified for mailto (i.e. must not pass obviously unsafe headers, must not send without user action, etc).
-      	</p>
-      
-      	<p>
-      	Examples of SMS URI usage
-     	</p>
-      	<ul>
-      		<li><code>sms:+4646000001</code> (addressing  single recipient)</li>
-      		<li><code>sms:+4646000001,+4646000002</code> (addressing two recipients)</li>
-      		<li><code>sms:+4646000001?body=Welcome%20to%20Atlantis</code> (sending message single recipient with initial message indicated)</li>
-      	</ul>
-      	<p>
-      	<i>Comments on relationship between DAP Messaging and SMS URI</i> The SMS URI approach typically hands of the details of the messaging to an external messaging application. It thus commonly leaves the control of the user agent and web application, providing no feedback to the application whether something was sent or not, or what a sent message actually contained. The SMS URI specification does not cover events resulting from arriving SMSs, nor the manipulation of the SMS message store, making the creation of a web application based SMS messaging application difficult. RFC5724 was accepted in January 2010, and implementation of the scheme is therefore limited. However, at least some platforms use a simpler form of SMS URI without the capacity to pre-populate the message body (e.g. iPhone). 
-      	</p>
-      	</section>
-      	<section>
-      	<h3>The mailto URL scheme (RFC2368)</h3>
-      	<p>
-      	RFC2368 defines the well known mailto URL scheme, for that allows presents a way to pass a request to send an email to the specfied receivers with a specified text body.  If the browser can handle the scheme and an external email program is correctly configured, then the user agent typically passes over the URL contents to a email program that handles the editing and sending of the email. There is no requirement that the email messaging program must be running same device as the user agent, allowing the use of e.g. external web based services to fulfill the request. The implementation is required to correctly translate the text body to suitable encoding.
-      	</p>
-      
-      	<p>
-      	RFC2368 prescribes a number of security measures that the UA must take when handling mailto URLs(i.e. must not pass obviously unsafe headers, must not send without user action, etc).
-      	</p>
-      	
-      	<p>
-      	<i>Comments on relationship between DAP Messaging and mailto</i> The mailto approach typically hands of the details of the messaging to an external messaging application. It thus commonly leaves the control of the user agent and web application, providing no feedback to the application whether something was sent or not, or what a sent message actually contained. RFC2368 specification does not cover events resulting from arriving emails, nor the manipulation of the email message store, making the creation of a web application based email messaging application difficult. The mailto scheme is commonly supported in many/most platforms. 
-      	</p>
-      	</section>
-      </section>
-
-
-     </section>
-    
-   
-    
     <section class='appendix'>
       <h2>Features for Future Consideration</h2>
       <p>

Received on Thursday, 8 April 2010 20:49:55 UTC