Corrected editorial errors.
authorClaes Nilsson <claes1.nilsson@sonymobile.com>
Wed, 27 Jun 2012 17:59:03 +0200
changeset 128 fced17cf40f8
parent 127 ad3c7910aba6
child 129 f73be2915d48
Corrected editorial errors.
wi-addendum-local-services/Example device and service description pages/Slide1.PNG
wi-addendum-local-services/Example device and service description pages/Slide2.PNG
wi-addendum-local-services/Example scenario 1/Slide1.PNG
wi-addendum-local-services/Example scenario 1/Slide2.PNG
wi-addendum-local-services/Example scenario 1/Slide3.PNG
wi-addendum-local-services/Example scenario 2/Slide1.PNG
wi-addendum-local-services/Example scenario 2/Slide2.PNG
wi-addendum-local-services/Example scenario 2/Slide3.PNG
wi-addendum-local-services/Example scenario 2/Slide4.PNG
wi-addendum-local-services/Example1 registration page.png
wi-addendum-local-services/Example1_registration_page/Slide1.png
wi-addendum-local-services/Example_device_and_service_description_pages/Slide1.png
wi-addendum-local-services/Example_device_and_service_description_pages/Slide2.png
wi-addendum-local-services/Example_scenario_1/Slide1.png
wi-addendum-local-services/Example_scenario_1/Slide2.png
wi-addendum-local-services/Example_scenario_1/Slide3.png
wi-addendum-local-services/Example_scenario_2/Slide1.png
wi-addendum-local-services/Example_scenario_2/Slide2.png
wi-addendum-local-services/Example_scenario_2/Slide3.png
wi-addendum-local-services/Example_scenario_2/Slide4.png
wi-addendum-local-services/Overview.HTML
Binary file wi-addendum-local-services/Example device and service description pages/Slide1.PNG has changed
Binary file wi-addendum-local-services/Example device and service description pages/Slide2.PNG has changed
Binary file wi-addendum-local-services/Example scenario 1/Slide1.PNG has changed
Binary file wi-addendum-local-services/Example scenario 1/Slide2.PNG has changed
Binary file wi-addendum-local-services/Example scenario 1/Slide3.PNG has changed
Binary file wi-addendum-local-services/Example scenario 2/Slide1.PNG has changed
Binary file wi-addendum-local-services/Example scenario 2/Slide2.PNG has changed
Binary file wi-addendum-local-services/Example scenario 2/Slide3.PNG has changed
Binary file wi-addendum-local-services/Example scenario 2/Slide4.PNG has changed
Binary file wi-addendum-local-services/Example1 registration page.png has changed
Binary file wi-addendum-local-services/Example1_registration_page/Slide1.png has changed
Binary file wi-addendum-local-services/Example_device_and_service_description_pages/Slide1.png has changed
Binary file wi-addendum-local-services/Example_device_and_service_description_pages/Slide2.png has changed
Binary file wi-addendum-local-services/Example_scenario_1/Slide1.png has changed
Binary file wi-addendum-local-services/Example_scenario_1/Slide2.png has changed
Binary file wi-addendum-local-services/Example_scenario_1/Slide3.png has changed
Binary file wi-addendum-local-services/Example_scenario_2/Slide1.png has changed
Binary file wi-addendum-local-services/Example_scenario_2/Slide2.png has changed
Binary file wi-addendum-local-services/Example_scenario_2/Slide3.png has changed
Binary file wi-addendum-local-services/Example_scenario_2/Slide4.png has changed
--- a/wi-addendum-local-services/Overview.HTML	Wed Jun 27 11:09:40 2012 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,565 +0,0 @@
-<!DOCTYPE html>
-<html>
-  <head>
-    <title>Web Intents Addendum - Local Services</title>
-    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
-    <!-- 
-      === NOTA BENE ===
-      For the three scripts below, if your spec resides on dev.w3 you can check them
-      out in the same tree and use relative links so that they'll work offline,
-     -->
-    <script src='http://www.w3.org/Tools/respec/respec-w3c-common' class='remove'></script>
-    <script class='remove'>
-      var respecConfig = {
-          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
-          specStatus:           "ED",
-          
-          // the specification's short name, as in http://www.w3.org/TR/short-name/
-          shortName:            "Web Intents-UPnP addendum",
-
-          // if your specification has a subtitle that goes below the main
-          // formal title, define it here
-          // subtitle   :  "an excellent document",
-
-          // if you wish the publication date to be other than today, set this
-          // publishDate:  "2009-08-06",
-
-          // if the specification's copyright date is a range of years, specify
-          // the start date here:
-          // copyrightStart: "2005"
-
-          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
-          // and its maturity status
-          // previousPublishDate:  "1977-03-15",
-          // previousMaturity:  "WD",
-
-          // if there a publicly available Editor's Draft, this is the link
-          // edDraftURI:           "http://dev.w3.org/2009/dap/ReSpec.js/documentation.html",
-
-          // if this is a LCWD, uncomment and set the end of its review period
-          // lcEnd: "2009-08-05",
-
-          // if you want to have extra CSS, append them to this list
-          // it is recommended that the respec.css stylesheet be kept
-          extraCSS:             ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
-
-          // editors, add as many as you like
-          // only "name" is required
-          editors:  [
-              { name: "Claes Nilsson",
-                company: "Sony Mobile", companyURL: "http://www.sonymobile.com/se/" },
-          ],
-
-          // authors, add as many as you like. 
-          // This is optional, uncomment if you have authors as well as editors.
-          // only "name" is required. Same format as editors.
-
-          //authors:  [
-          //    { name: "Your Name", url: "http://example.org/",
-          //      company: "Your Company", companyURL: "http://example.com/" },
-          //],
-          
-          // name of the WG
-          wg:           "DAP/Web Apps Web Intents task force",
-          
-          // URI of the public WG page
-          wgURI:        "http://www.w3.org/2009/dap/",
-          
-          // name (without the @w3c.org) of the public mailing to which comments are due
-          wgPublicList: "public-web-intents",
-          
-          // URI of the patent status for this WG, for Rec-track documents
-          // !!!! IMPORTANT !!!!
-          // This is important for Rec-track documents, do not copy a patent URI from a random
-          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
-          // Team Contact.
-          wgPatentURI:  "",
-      };
-    </script>
-  </head>
-  <body>
-    <section id='abstract'>
-      This specification is an addendum to Web Intents, [[!WEBINTENTS]], that defines how Web Intents enabled User Agents can discover and communicate 
-      with local Web Intents Services.
-    </section>
-    
-    <section class='informative'>
-      <h2>Introduction</h2>
-      <p>
-        Web Intents,[[!WEBINTENTS]], is a service discovery and light-weight RPC mechanism for web applications. The concept enables rich integration between web applications. 
-        A typical Web Intents scenario is:
-      </p>
-      <ol>
-         <li>Web Intents Services register their intention to handle an action for the user </li>
-         <li>A web application requests to start an action (share, edit, pick, view, ...)</li>
-         <li>The user selects which service to handle the action</li>
-      </ol>
-      <p>
-        A Web Intents Service is represented by a web page that declaratively marks itself as providing handling functionality for particular intents. Users register Web Intents Services 
-        by visiting web pages that contain registration markup.
-        However, the strength of Web Intents is the ability to provide web applications with access to Services residing not only in the cloud but also in local environments.
-      </p>
-      <p>
-        This specification defines optional extensions to Web Intents enabled User Agents to discover and dynamically register local Web Intents 
-        Services. Note that all details of the specific low level protocols used to discover and communicate with the local services are hidden to
-        the Client Web Applications.          
-      </p>   
-      <p>
-        The following code illustrates how a web application containing links to videos, can initiate video playback by creating and invoking a "video intent" as defined in [[!WEBINTENTS]].
-        This code is the same irrespective of whether the Service executing the intent action is a cloud based Service or a local Service.
-      </p>
-      <pre class="example sh_javascript_dom">
-      
-        // Create a new intent
-				var intent = new Intent(
-				"http://webintents.org/view",
-				"video/mp4",
-				{ "src":videoCanvas.src, "img": videoCanvas.poster});
-					
-				// Start intents picker 
-				navigator.startActivity(intent,
-					// On Result
-					function(intentData) { 
-						console.log("player.html: On Result" + intentData);
-					}, 
-					// On Failure
-					function(intentData) { 
-						console.log("player.html: On Failure" + intentData);
-					}
-				);
-      </pre>
-      <p>
-        The example below briefly describes the steps taken when a Service on a local network, e.g. UPnP or mDNS, device is discovered and selected by 
-        the user.
-      </p>      
-      
-      <ol>
-         <li>Triggered by navigator.startActivity the User Agent will start local network discovery of Web Intents Services.</li>
-         <li>Replies from Web Intents enabled devices contain a URL to a Web Intents document, containing Web Intents Service registration 
-             markup, in the device. </li>
-         <li>The Web Intents documents are retrieved by the User Agent and the dynamically registered Services are visible in the Web Intents Service picker. </li>
-         <li>User selects Service.</li>
-         <li>User Agent retrieves the Service page from the the Web Intents local network device and invokes it. </li>
-         <li>The Service page handles the intent. </li>  
-         <li>When handling the intent is finished, the Service page issues window.intent.postResult and closes itself. </li>               
-      </ol>
-      
-    </section>
-    
-    <section id="conformance">     
-      <p>        
-        This specification defines conformance criteria that apply to <dfn>user agents</dfn> and to <dfn>local Web Intents enabled devices</dfn>.
-      </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 and terminology.
-      </p>
-      <section>
-        <h2>Dependencies</h2>
-        <p>
-          This specification relies on the following specifications:
-          
-          <dl>
-            <dt>Web Intents</dt>
-            <dd>This addendum specification is dependent on and defines optional extensions to the basic Web Intents specification, [[!WEBINTENTS]]. </dd>
-            <dt>UPnP Device Architecture 1.0</dt>
-            <dd>This addendum specification is dependent on and defines vendor specific extensions to the UPnP Device Architecture 1.0 specification, [[!UPNP-DEVICEARCH]] </dd>
-          </dl>
-          
-        </p>      
-      </section>
-    </section>
-    
-    <section>
-      <h2>Terminology</h2>
-      <p>
-        Web Intents related terms are used according to section "Terminology" in [[!WEBINTENTS]].
-      </p>
-     
-      <section> 
-        <h3>UPnP related terms</h3>
-        <p>
-          UPnP related terms are used according to [[!UPNP-DEVICEARCH]]. 
-        </p>
-        <p>
-          The User Agent has the role of a <dfn id="dfn-registration">control point</dfn>  according to UPnP terminology. 
-        </p>     
-        <p>
-          The UPnP/Web Intents device discovered by the User Agent has the roles of <dfn id="dfn-registration">device</dfn> according to UPnP terminology. 
-        </p>        
-      </section>
-      
-      <section> 
-        <h3>mDNS related terms</h3>
-        <p>
-          TBD...
-        </p>
-      </section>     
-      
-
-    </section>
-    
-    <section>
-    
-      <h2>UPnP adaptation</h2> 
-      
-      <section>   
-      
-        <h3>Web Intents enabled UPnP devices</h3> 
-        
-        <p>
-          The Web Intents enabled UPnP device <em class="rfc2119" title="must">must</em> support this section.
-        </p>
-        
-        <section>    
-        
-          <h4>UPnP Web Intents serviceType</h4>     
-          
-          <p>
-            The Web Intents enabled UPnP device <em class="rfc2119" title="must">must</em> support the UPnP service which serviceType is the <code>urn:schemas-webintents-org:service:WebIntents:1</code> 
-            as a vendor specific serviceType according to [[!UPNP-DEVICEARCH]]. It is vendor dependent how the Web Intents enabled 
-            UPnP device implements the serviceType. i.e. a device description of any deviceType could include this serviceType.
-          </p>  
-          
-          <p>          
-            The Web Intents serviceType <em class="rfc2119" title="must">must</em> have a dummy state variable, <code>X_State</code> of <code>ui4</code> data type to comform to [[!UPNP-DEVICEARCH]]
-            which requires one or more state variables in a serviceType. The <code>X_State</code> state variable is not used with a value and is never evented. 
-          </p>  
-          <p>
-            The Web Intents  serviceType has no standard action.          
-          </p>          
-
-          <p>
-            See below for the UPnP Service description document of the Web Intents serviceType.
-          </p>           
-          
-          <p align="left"><img src="Example device and service description pages/Slide2.png" alt="Service description pages" width="600" height="600" ><br>
-           (<a href="Example device and service description pages/Slide2.png">View as PNG</a>)
-          </p>   
-             
-        
-        </section>   
-        
-        <section>    
-        
-          <h4>Web Intents specific SSDP headers</h4>           
-
-          <p>
-            The UPnP Web Intents enabled device <em class="rfc2119" title="must">must</em> support SSDP discovery process based on standard UPnP Discovery extended with 2 additional 
-            SSDP headers for M-SEARCH response and NOTIFY when ST/NT headers are:<code>urn:schemas-webintents-org:service:WebIntents:1</code>
-          </p>
-        
-          <ul>
-            <li>
-              <code>location.webintents.org</code>: <em class="rfc2119" title="required">required</em>. States the location to the Web Intents document in the UPnP device. 
-              If the value of this header is a relative URL the base URL is the base URL of the <code>LOCATION</code> header.  
-            </li>
-            <li>
-              <code>action.webintents.org</code>: <em class="rfc2119" title="optional">optional</em>. If supported, states the Web Intents 
-              <code>action</code> of the supported Web Intents Services and <em class="rfc2119" title="must">must</em>
-              match the <code>action</code> attributes of the Service registration markup in the Web Intents document. To support more than 
-              one Web Intents <code>action</code> the action strings <em class="rfc2119" title="must">must</em> be separated with 
-              one or more commas. Commas included in action strings <em class="rfc2119" title="must">must</em> be percent-encoded as 
-              defined in [[!RFC3986]], section-2.1.
-              <br />  <br />
-              This header allows the User Agent to filter received SSDP messages so that User Agents only have to retrieve Web Intents documents 
-              for matching Web Intents Actions.        
-            </li>
-          </ul>         
-
-        </section>   
-        
-        <section>    
-        
-          <h4>Web Intents document</h4>   
-
-          <p>
-            The UPnP device <em class="rfc2119" title="must">must</em> store Web Intents documents for the Web Intents Services the device supports. 
-            Web Intents documents are html pages that contain Web Intents Service registration markup according to the rules for Web Intents Service registration defined 
-            by [[!WEBINTENTS]]. They may also contain Service handler code for Services registered within the same document. 
-          </p>              
-        
-        </section>   
-        
-        <section>    
-        
-          <h4>Web Intents Service pages</h4>    
-          
-          <p>
-            The Web Intents enabled UPnP device <em class="rfc2119" title="must">must</em> store a Web Intents Service page for each Service that is 
-            referred in Web Intents documents through <code>href</code> attributes in the registration markup. 
-          </p>
-          <p>
-            Service pages contain Service handler code and fulfills the rules for Web Intents Services as defined by [[!WEBINTENTS]]. 
-          </p>   
-        
-        </section>          
-        
-      </section>   
-      
-      <section>
-      
-        <h3>User Agent behavior</h3> 
-        
-        <p>
-          Web Intents/UPnP enabled User Agents <em class="rfc2119" title="must">must</em> support discovery of Web Intents enabled UPnP devices through SSDP Discovery or through Advertisement 
-          or through both methods according to [[!UPNP-DEVICEARCH]] and according to the Web Intents serviceType and Web Intents specific SSDP headers 
-          defined in this specification, section 4.1. 
-        </p>
-  
-        <p>
-          The sections below describe typical steps using these methods.
-        </p>            
-          <section class='informative'>
-            <h4>Dynamic Service registration based on M-SEARCH</h4>     
-            <p>
-              The section describes the discovery process based on standard UPnP M-SEARCH multicast request.
-            </p>
-            
-            <p>
-              When the navigator.startActivity method [[!WEBINTENTS]] is called, the User Agent runs the following steps:
-            </p>
-              
-            <ol class="rule">          
-              <li>
-                 Send a multicast request with the method M-SEARCH in the format specified by [[!UPNP-DEVICEARCH]].
-                 <br />
-                 The <code>ST</code> header is set to: <code>urn:schemas-webintents-org:service:WebIntents:1</code>
-              </li>
-              <br />
-              <li>
-                 For each matching M-SEARCH response, i.e. the response ST header is <code>urn:schemas-webintents-org:service:WebIntents:1</code> and the <code>action.webintents.org</code> 
-                 header, if present, matches the Action of the invoked intent, 
-                 the User Agent attempts to retrieve the Web Intents document from the discovered device.              
-                 The value of the <code>location.webintents.org</code> header is the location for the Web Intents document. 
-                 If this value is a relative URL the User Agent uses the base URL of the <code>LOCATION</code> header as base URL for the location of the 
-                 Web Intents document.  
-                 <br />  <br />
-                 If the User Agent fails to retrieve the Web Intents document it silently disregards the discovered Service.
-                 <br />  <br />
-                 If the <code>action.webintents.org</code> header is present and does not match the <code>action</code> attributes of the Services registered in the retrieved Web Intents 
-                 document the User Agent silently disregards the discovered Service.
-              </li>
-              <br />         
-              <li>
-                 It is expected that the Web Intents document contains registration markup and the User Agent interprets this
-                 registration markup according to the rules for registration defined by [[!WEBINTENTS]] and register the Services accordingly.           
-              </li>
-              <br />          
-              <li>
-                 The User Agent makes each dynamically registered Service available for selection 
-                 by the user, typically by making them visible and selectable in a Web Intents Service picker.                          
-              </li>
-              <br />          
-              <li>
-                 Based on user selection of a dynamically registered Service the User Agent loads the 
-                 Service handler code as defined by the <code>href</code> attribute in the registration markup for this Service according to the rules for 
-                 loading Service pages defined in [[!WEBINTENTS]].                        
-              </li>
-      
-            </ol> 
-     
-          </section>
-          
-          <section class='informative'>
-            <h4>Dynamic Service registration based on NOTIFY</h4>
-            <p>
-              This section describes the discovery process based on standard UPnP Advertisement with NOTIFY message.            
-            </p> 
-           
-            <p>
-             The User Agent <em class="rfc2119" title="may">may</em> continously listen and act on advertisments according to the following steps:
-            </p>   
-            <ol class="rule">   
-          
-              <li>
-                The User Agent maintains a list of announced services based on received SSDP NOTIFY messages
-                with <code>NT</code> header equal to <code>urn:schemas-webintents-org:service:WebIntents:1</code>.
-              </li>
-              <br /> 
-              <li>
-                When the navigator.startActivity method [[!WEBINTENTS]] is called the User Agent checks the list
-                of of announced services for a service with an <code>action.webintents.org</code> header that matches the Action of the invoked intent.
-              </li> 
-              <br />
-              <li>
-                 For each match the User Agent attempts to retrieve the Web Intents document document from the discovered device. The User Agent
-                 may also attempt to retrieve the Web Intents document for announced services without an <code>action.webintents.org</code> header.             
-                 The location of the Web Intents document is the value of the <code>location.webintents.org</code> header. If this value is a relative URL the
-                 base URL is the base URL of the <code>LOCATION</code> header.  
-                 <br />  <br />
-                 If the User Agent fails to retrieve the Web Intents document it silently disregards the discovered Service.
-                 <br />  <br />
-                 If the <code>action.webintents.org</code> header does not match the <code>action</code> attribute in the retrieved Web Intents document 
-                 the User Agent silently disregards the discovered Service.
-              </li>
-              <br />         
-              <li>
-                 It is expected that the Web Intents document contains registration markup and the User Agent interprets the
-                 Web Intents document according to the rules for registration defined by [[!WEBINTENTS]] and register the Services accordingly.                         
-              </li>
-              <br />          
-              <li>
-                 The User Agent makes each dynamically registered Service available for selection 
-                 by the user, typically by making them visible and selectable in a Web Intents Service picker.                          
-              </li>
-              <br />          
-              <li>
-                 Based on user selection of a dynamically registered Service the User Agent loads the 
-                 Service handler code as defined by the <code>href</code> attribute in the registration markup for this Service according to the rules for 
-                 loading Service pages defined in [[!WEBINTENTS]].                          
-              </li>
-            </ol> 
-             
-            <p class="note">
-              Power consumption in battery powered devices should be considered. If power consumption is severe continuously listening to SSDP advertisement in the background 
-              should not be used..          
-            </p> 
-          
-          </section>  
-          
-          
-          <section class='informative'>
-      
-            <h4>Service availability management</h4>
-
-            <p>
-             The User Agent must manage the availability of UPnP services. For example detect when contact with a UPnP device is lost through standard
-             UPnP life cycle management and remove a previously discovered and registered Service from the Service picker. However, for battery powered devices
-             power consumption must be considered and long lasting "keep alive" sessions" should be avoided.           
-            </p>        
-        
-          </section>
-
-      </section>        
-      
-   
-      
-    </section>   
-    
-    <section>
-    
-      <h2>mDNS adaptation</h2> 
-      
-      <p>
-      
-        This section describes how the User Agent handles Web Intents provided by local devices supporting mDNS.          
-      </p>
-      
-      <p>
-        TBD....
-      </p>
-      
-      
-    </section>         
-    
-        
-    <section class='informative'>
-      <h2>APIs / protocols Client - Service </h2>
-      <p>
-        The APIs / protocols for interaction between Client and Service pages are not defined by this specification. It is assumed that Web Intents 
-        based APIs and protocols will be standardized by W3C and that these will be applicable for Client and Service applications running on User Agents that
-        comply to this specification. Different use cases will require different ways of interaction patterns between Client and Service. 
-      </p>
-      
-      <p>
-        Examples:
-      </p>  
-      <ul>
-        <li>
-          A Client application invoking a "View" intent provides, as intent payload data, a link to a video to be displayed at the remote UPnP device.
-          The Service application takes full control of the video playback by providing control buttons and sends UPnP commands to the remote device.
-          So in this case there the simple "API" just gives the link to the video to play. 
-        </li>
-        <li>
-          Some use cases require a longer lasting relation between the Client and Service applications. By using the MessagePort[] attribute of the intent object 
-          a message channel can be established between the Client and Service page. This message channel can be used to run Service specific protocols, 
-          for example a protocol that allows the Client application to send simple video playback control commands to a Service application. 
-        </li>
-      </ul>          
-      
-    </section>  
-           
-    <section class='informative appendix'>
-    <h2>Examples and scenarios</h2>
-      <section>
-        <h3>View and control video on remote device through Service page control buttons</h3>
-        <p>
-          The following scenario describes how a Client page uses Web Intents to discover a remote video view service. The Service page 
-          contains the UI for controlling the video playback.
-        </p>
-        
-        <p align="left"><img src="Example scenario 1/Slide1.png" alt="Example scenario 1/Slide1" width="700" height="700" ><br>
-         (<a href="Example scenario 1/Slide1.png">View as PNG</a>)
-        </p>      
-        
-        <p align="left"><img src="Example scenario 1/Slide2.png" alt="Example scenario 1/Slide2" width="700" height="700" ><br>
-         (<a href="Example scenario 1/Slide2.png">View as PNG</a>)
-        </p> 
-        
-        <p align="left"><img src="Example scenario 1/Slide3.png" alt="Example scenario 1/Slide3" width="700" height="700" ><br>
-         (<a href="Example scenario 1/Slide3.png">View as PNG</a>)
-        </p>                 
-      </section>  
-      
-      <section>
-        <h3>View and control video on remote device through Client page control buttons</h3>
-        <p>
-          The following scenario describes how a Client page uses Web Intents to discover a remote video view service. The UI stays in the Client page, 
-          which contains the UI controls for the video playback.
-        </p>
-        
-        <p class="issue">
-          This scenario assumes the possibility to have hidden/background Service pages or Service pages that are visible inline the Client page.
-          Currently [[!WEBINTENTS]] does not allow this but W3C DAP Action http://www.w3.org/2009/dap/track/actions/519 should add a proposal for a hidden disposition. 
-        </p>   
-        
-        <p align="left"><img src="Example scenario 2/Slide1.png" alt="Example scenario 2/Slide1" width="700" height="700" ><br>
-         (<a href="Example scenario 2/Slide1.png">View as PNG</a>)
-        </p>      
-        
-        <p align="left"><img src="Example scenario 2/Slide2.png" alt="Example scenario 2/Slide2" width="700" height="700" ><br>
-         (<a href="Example scenario 2/Slide2.png">View as PNG</a>)
-        </p> 
-        
-        <p align="left"><img src="Example scenario 2/Slide3.png" alt="Example scenario 2/Slide3" width="700" height="700" ><br>
-         (<a href="Example scenario 2/Slide3.png">View as PNG</a>)
-        </p>    
-        
-        <p align="left"><img src="Example scenario 2/Slide4.png" alt="Example scenario 2/Slide4" width="700" height="700" ><br>
-         (<a href="Example scenario 2/Slide4.png">View as PNG</a>)
-        </p>                       
-      </section>  
-            
-      
-    
-      <section>
-        <h3>Example of Web Intents document</h3>
-      
-        <p align="left"><img src="Example1 registration page.png" alt="Example1 registration page" width="280" height="280" ><br>
-         (<a href="Example1 registration page.png">View as PNG</a>)
-        </p>      
-      </section>      
-    
-      <section>
-        <h3>Example of UPnP Device description document</h3>
-        <p align="left"><img src="Example device and service description pages/Slide1.png" alt="Example device and service description pages/Slide1" width="600" height="600" ><br>
-         (<a href="Example device and service description pages/Slide1.png">View as PNG</a>)
-        </p>   
-      </section>
-            
-    </section>           
-    
-    <section class='appendix'>
-      <h3>Acknowledgements</h3>
-        <p>         
-          Many thanks to Sony Mobile colleagues Anders Isberg, Anders Edenbrandt and Björn Ekberg
-          for all support.
-          <br />  <br />
-          Many thanks to Robin Berjon for making our lives so much easier with his cool specification editing tool.
-        </p>
-    </section>
-  </body>
-</html>
\ No newline at end of file