W3C home > Mailing lists > Public > public-dap-commits@w3.org > September 2012

dap commit: Web Intents addendum: Added fleder FPWD with static version FPWD.html +

From: Mercurial notifier <cvsmail@w3.org>
Date: Tue, 25 Sep 2012 09:21:15 +0000
Message-Id: <E1TGRKN-0001wq-CS@mcbain.w3.org>
To: public-dap-commits@w3.org
changeset:   229:2c38f7223615
tag:         tip
user:        Claes Nilsson <claes1.nilsson@sonymobile.com>
date:        Tue Sep 25 11:20:35 2012 +0200
files:       wi-addendum-local-services/FPWD.html wi-addendum-local-services/FPWD/Example1_registration_page/Slide1.png wi-addendum-local-services/FPWD/Example_device_and_service_description_pages/Slide1.png wi-addendum-local-services/FPWD/Example_device_and_service_description_pages/Slide2.png wi-addendum-local-services/FPWD/Example_scenario_1/Slide1.png wi-addendum-local-services/FPWD/Example_scenario_1/Slide2.png wi-addendum-local-services/FPWD/Example_scenario_1/Slide3.png wi-addendum-local-services/FPWD/Example_scenario_2/Slide1.png wi-addendum-local-services/FPWD/Example_scenario_2/Slide2.png wi-addendum-local-services/FPWD/Example_scenario_2/Slide3.png wi-addendum-local-services/FPWD/Example_scenario_2/Slide4.png wi-addendum-local-services/FPWD/FPWD.html wi-addendum-local-services/FPWD/FPWD_src.html
description:
Web Intents addendum: Added fleder FPWD with static version FPWD.html +
folders with images.


diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD.html
--- a/wi-addendum-local-services/FPWD.html	Mon Sep 24 15:42:20 2012 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,746 +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:           "FPWD",
-          
-          // the specification's short name, as in http://www.w3.org/TR/short-name/
-          shortName:            "Web Intents-LD 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:  "2012-09-27",
-
-          // 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://w3c-test.org/dap/wi-addendum-local-services/",
-
-          // 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/" },
-              { name: "Norifumi Kikkawa",
-                company: "Sony Corporation", companyURL: "http://www.sony.net/"},
-          ],
-
-          // 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>
-
-    <style type="text/css">
-
-      /* Add addition spacing to <ol> and <ul> for rule definition */
-      ol.rule li, ul.rule li { padding:0.6em; }
-
-    </style>
-
-
-  </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 class="rule">
-         <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>
-         <li>The selected service executes 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 class="rule">
-         <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:
-      </p>   
-      <ul class="rule">
-        <li><dfn>UPnP enabled User Agent</dfn>: A <a>UPnP enabled User Agent</a> MUST support Web Intents [[!WEBINTENTS]] and the conformance criteria 
-        stated in this specification. </li>
-        <li><dfn>Web Intents enabled UPnP device</dfn>: A <a>Web Intents enabled UPnP device</a> MUST support [[!UPNP-DEVICEARCH]] and the conformance criteria 
-        stated in this specification. </li>
-        <li><dfn>mDNS enabled User Agent</dfn>: An <a>mDNS enabled User Agent</a> MUST support Web Intents [[!WEBINTENTS]] and the conformance criteria 
-        stated in this specification. </li>
-        <li><dfn>Web Intents enabled mDNS device</dfn>: A <a>Web Intents enabled mDNS device</a> MUST support [[!DNS-SD]], [[!MDNS]] and the conformance criteria 
-        stated in this specification. </li>
-      </ul>
-     
-      <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:
-        </p>
-          
-        <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>
-          <dt>IANA Service Name and Transport Protocol Port Number Registry</dt>
-          <dd>This addendum specification adds new entry on it, [[!IANA-SRVPORT-REG]]. </dd>
-          <dt>DNS-SD</dt>
-          <dd>This addendum specification is dependent on it, [[!DNS-SD]]. </dd>
-          <dt>mDNS</dt>
-          <dd>This addendum specification is dependent on it, [[!MDNS]]. </dd>
-        </dl>
-          
-           
-      </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 <a>UPnP enabled User Agent</a> has the role of a <dfn id="dfn-control-point">control point</dfn>  according to UPnP terminology. 
-        </p>     
-        <p>
-          The <a>Web Intents enabled UPnP device</a> discovered by the <a>UPnP enabled User Agent</a> has the roles of <dfn id="dfn-device">device</dfn> according to UPnP terminology. 
-        </p>        
-      </section>
-      
-      <section> 
-        <h3>mDNS related terms</h3>
-        <p>
-          The <a>mDNS enabled User Agent</a> has the role of a <dfn id="dfn-DNS-client">DNS client</dfn> with capability of [[!DNS-SD]]. 
-        </p>
-        <p>
-          The <a>Web Intents enabled mDNS device</a> discovered by the <a>mDNS enabled User Agent</a> has the roles of <dfn id="dfn-service">service</dfn> according to [[!MDNS]] and [[!DNS-SD]]. 
-        </p>        
-      </section>     
-      
-
-    </section>
-    
-    <section>
-    
-      <h2>UPnP adaptation</h2> 
-      
-      <section>   
-      
-        <h3><a>Web Intents enabled UPnP device</a></h3> 
-        
-        <p>
-          The <a>Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> support this section.
-        </p>
-        
-        <section>    
-        
-          <h4>UPnP Web Intents serviceType</h4>
-          
-          <p>
-            The <a>Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> support one 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 <a>Web Intents enabled UPnP device</a> 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>boolean</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><img src="Example_device_and_service_description_pages/Slide2.png" alt="Service description page" 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 <a>Web Intents enabled UPnP device</a> <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 class="rule">
-            <li>
-              <code>location.webintents.org</code>: <em class="rfc2119" title="required">required</em>. States the location to the Web Intents document in the <a>Web Intents enabled UPnP device</a>. 
-              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 
-              comma. Commas included in action strings <em class="rfc2119" title="must">must</em> be percent-encoded as 
-              defined in [[!RFC3986]], section-2.1.
-              <br />
-              This header allows the <a>UPnP enabled User Agent</a> to filter received SSDP messages so that the <a>UPnP enabled User Agent</a> only has to 
-              retrieve Web Intents documents for matching Web Intents Actions.        
-            </li>
-          </ul>         
-
-        </section>   
-        
-        <section>    
-        
-          <h4>Web Intents document</h4>   
-
-          <p>
-            The <a>Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> host Web Intents documents for the Web Intents Services the <a>Web Intents enabled UPnP device</a> 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 <a>Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> host 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><a>UPnP enabled User Agent</a></h3> 
-        
-        <p>
-          The <a>UPnP enabled User Agent</a> <em class="rfc2119" title="must">must</em> support discovery of <a>Web Intents enabled UPnP device</a>s 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 <a>UPnP enabled User Agent</a> 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>
-              
-              <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 <a>UPnP enabled User Agent</a> attempts to retrieve the Web Intents document from the discovered <a>Web Intents enabled UPnP device</a>.              
-                 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 <a>UPnP enabled User Agent</a> 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 <a>UPnP enabled User Agent</a> fails to retrieve the Web Intents document it silently disregards the received M-SEARCH response.
-                 <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 <a>UPnP enabled User Agent</a> silently disregards the the received M-SEARCH response.
-              </li>
-       
-              <li>
-                 It is expected that the Web Intents document contains registration markup and the <a>UPnP enabled User Agent</a> interprets this
-                 registration markup according to the rules for registration defined by [[!WEBINTENTS]] and register the Services accordingly.           
-              </li>
-         
-              <li>
-                 The <a>UPnP enabled User Agent</a> makes each dynamically registered Service, that matches the Action of the invoked intent, available for selection 
-                 by the user, typically by making them visible and selectable in a Web Intents Service picker.                          
-              </li>
-         
-              <li>
-                 Based on user selection of a dynamically registered Service the <a>UPnP enabled User Agent</a> 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 <a>UPnP enabled User Agent</a> <em class="rfc2119" title="may">may</em> continuously listen to and act on advertisments according to the following steps:
-            </p>   
-            <ol class="rule">   
-          
-              <li>
-                The <a>UPnP enabled User Agent</a> maintains a list of announced UPnP services based on received SSDP NOTIFY messages
-                with <code>NT</code> header equal to <code>urn:schemas-webintents-org:service:WebIntents:1</code>.
-              </li>
-              
-              <li>
-                When the navigator.startActivity method [[!WEBINTENTS]] is called the <a>UPnP enabled User Agent</a> checks the list
-                of of announced services and attempts to retrieve the Web Intents document from the discovered <a>Web Intents enabled UPnP device</a> in the following cases:                
-                <ul>
-                  <li>
-                    The received NOTIFY message contains an <code>action.webintents.org</code> header and this header matches the Action of the invoked intent.
-                  </li>
-                  <li>
-                    The received NOTIFY message does not contain an <code>action.webintents.org</code> header.
-                  </li>                
-                </ul>
-                <br />     
-                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 <a>UPnP enabled User Agent</a> fails to retrieve the Web Intents document it silently disregards the received NOTIFY message.
-                <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 <a>UPnP enabled User Agent</a> silently disregards the received NOTIFY message.
-              </li>
-                       
-              <li>
-                 It is expected that the Web Intents document contains registration markup and the <a>UPnP enabled User Agent</a> interprets the
-                 Web Intents document according to the rules for registration defined by [[!WEBINTENTS]] and register the Services accordingly.                         
-              </li>
-                        
-              <li>
-                 The <a>UPnP enabled User Agent</a> makes each dynamically registered Service, that matches the Action of the invoked intent, available for selection 
-                 by the user, typically by making them visible and selectable in a Web Intents Service picker.                          
-              </li>
-                       
-              <li>
-                 Based on user selection of a dynamically registered Service the <a>UPnP enabled User Agent</a> 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>Support for Web Intents and UPnP</h4>
-            <p>
-              In addition to the normative statements defined in this specification a <a>UPnP enabled User Agent</a> that complies to this specification 
-              supports Web Intents according to [[!WEBINTENTS]] and UPnP Discovery, Description and Control according to [[!UPNP-DEVICEARCH]]. 
-              However, it is implementation dependent whether this is supported natively in the User Agent or supported through some external component, 
-              e.g. an in-device web server. 
-            </p>         
-          </section>           
-          
-          <section class='informative'>
-      
-            <h4>Service availability management</h4>
-
-            <p>
-             The <a>UPnP enabled User Agent</a> should manage the availability of UPnP services. For example detect when contact with a <a>Web Intents enabled UPnP device</a> 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 should be considered and long lasting "keep alive" sessions" should be avoided.           
-            </p>        
-        
-          </section>
-
-      </section>        
-      
-   
-      
-    </section>   
-    
-    <section>
-    
-      <h2>mDNS (DNS-SD) adaptation</h2> 
-      
-      <p>
-        This section describes how the User Agent handles Web Intents Services provided by local devices supporting mDNS and DNS-SD.          
-      </p>
-
-      <section>   
-      
-        <h3>Web Intents enabled mDNS device</h3> 
-        
-        <p>
-          The <a>Web Intents enabled mDNS device</a> <em class="rfc2119" title="must">must</em> support this section.
-        </p>
-        
-        <section>    
-        
-          <h4>Web Intents service type for DNS-SD</h4>     
-          
-          <p>
-            The <a>Web Intents enabled mDNS device</a> <em class="rfc2119" title="must">must</em> support [[!DNS-SD]] with a SRV record of the <code>webintents</code> service type. 
-          </p>  
-          
-            <p class="note">
-              A service type <code>webintents</code> should be registered in [[!IANA-SRVPORT-REG]].
-            </p>
-
-          <p>          
-            The TXT record for the <code>webintents</code> service must have following parameters:           
-          </p>          
-          <ul class="rule">
-            <li>
-              <code>location</code>: <em class="rfc2119" title="required">required</em>. States the location to the Web Intents document in the <a>Web Intents enabled mDNS device</a>. 
-              The value of this header is path to be concatenated with a host of the <a>Web Intents enabled mDNS device</a> to determine the location. The definition of the Web Intents document is the same as for UPnP.
-            </li>
-            <li>
-              <code>action</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 
-              comma. Commas included in action strings <em class="rfc2119" title="must">must</em> be percent-encoded as 
-              defined in [[!RFC3986]], section-2.1.
-              <br>
-              This allows the <a>mDNS enabled User Agent</a> to filter received mDNS messages so that the <a>mDNS enabled User Agent</a> only has to 
-              retrieve Web Intents documents for matching Web Intents Actions.        
-            </li>
-          </ul>         
-
-        </section>   
-        
-      </section>   
-      <section>    
-        <h3>mDNS enabled User Agent</h3> 
-
-        <p>
-          The <a>mDNS enabled User Agent</a> <em class="rfc2119" title="must">must</em> support discovery of <a>Web Intents enabled mDNS device</a>s through mDNS and DNS-SD 
-          according to [[!MDNS]], [[!DNS-SD]] and according to the Web Intents specific DNS records defined in this specification, section 5.1. 
-        </p>
-        
-        <section class='informative'>
-          <h4>Dynamic Service registration</h4>   
-          <p>
-            When the navigator.startActivity method [[!WEBINTENTS]] is called, the <a>mDNS enabled User Agent</a> typically runs the following steps:
-          </p>
-            
-          <ol class="rule">          
-            <li>
-               Send a multicast PTR query of the <code>_webintents._tcp.local</code> in the format specified by [[!MDNS]] and [[!DNS-SD]].
-               <br />
-            </li>
-
-            <li>
-               For each response, send a unicast TXT query of the webintents service instance in the PTR answer.
-               <br />
-               <p>This step can be omitted in case that the <a>Web Intents enabled mDNS device</a> attaches a TXT answer with the previous answer.
-            </li>
-
-            <li>
-               For each matching response, i.e. the response TXT record does not have an action parameter or does have an <code>action</code> parameter matching the Action of the invoked intent,
-               send a unicast request with a SRV query of the webintens service instance.
-               <br />
-               <p>This step can be omitted in case that the <a>Web Intents enabled mDNS device</a> attaches a SRV answer with the previous answer.
-            </li>
-
-            <li>
-               For each response, send a unicast A and/or AAAA query of the host name in the SRV answer.
-               <br />
-               <p>This step can be omitted in case that the <a>Web Intents enabled mDNS device</a> attaches an A and/or AAAA answer with the previous answer.
-            </li>
-
-            <li>
-               The <a>mDNS enabled User Agent</a> attempts to retrieve the Web Intents document from the discovered <a>Web Intents enabled mDNS device</a>.
-               The destination URL consists of an IP address in the A or AAAA answer, a port number in the SRV record and an absolute path in the <code>location</code> parameter of the TXT record.  
-               <br />  <br />
-               If the <a>mDNS enabled User Agent</a> fails to retrieve the Web Intents document it silently disregards the received response.
-               <br />  <br />
-               If the <code>action</code> parameter is present and does not match the <code>action</code> attributes of the Services registered in the retrieved Web Intents 
-               document the <a>mDNS enabled User Agent</a> silently disregards the the received response.
-               <br />  <br />
-               Note that following steps are identical to those of UPnP described in 4.2.
-            </li>
-          
-            <li>
-               It is expected that the Web Intents document contains registration markup and the <a>mDNS enabled User Agent</a> interprets this
-               registration markup according to the rules for registration defined by [[!WEBINTENTS]] and register the Services accordingly.           
-            </li>
-          
-            <li>
-               The <a>mDNS enabled User Agent</a> makes each dynamically registered Service, that matches the Action of the invoked intent, available for selection 
-               by the user, typically by making them visible and selectable in a Web Intents Service picker.                          
-            </li>
-          
-            <li>
-               Based on user selection of a dynamically registered Service the <a>mDNS enabled User Agent</a> 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>    
-      <section class="informative">
-        <h3>Sample Records</h3> 
-        
-        <p>
-          See below for the example records for Web Intents. An <a>mDNS enabled User Agent</a> looking for devices supporting http://webintents.org/view Web Intents can understand that 
-          it is possible to get a Web Intents document for "LivingRoomTV" at http://192.168.1.47:3619/webintents.html.
-        </p>
-
-        <ul class="rule">
-          <li>
-            <code>_webintents._tcp.local. 120 IN PTR LivingRoomTV._webintents._tcp.local.</code>: A LivingRoomTV instance serves webintents service.
-          </li>
-          <li>
-            <code>LivingRoomTV._webintents._tcp.local. 120 IN SRV 0 0 3619 TV40EX-W2000.local.</code>: A host "TV40EX-W2000" in the link local network offers the LivingRoomTV webintents service instance in its port 3619.
-          </li>
-          <li>
-            <code>LivingRoomTV._webintents._tcp.local. 120 IN TXT location=/webintents.html action=http://webintents.org/view</code>: It offers http://webintents.org/view type of Web Intents. The absolute path for its Web Intents document is "/webintents.html". Note that the actual binary format of the TXT record value is concatinating key-value pairs each of which is a single byte length followed by 0-255 length key=value character string as defined in [DNS-SD].
-          </li>
-          <li>
-            <code>TV40EX-W2000 120 IN A 192.168.1.47</code>: A host "TV40EX-W2000" is on 192.168.1.47.
-          </li>
-        </ul>
-
-      </section>   
-                 
-    </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 class="rule">
-        <li>
-          A Client application invoking a "View" intent provides, as intent payload data, a link to a video to be displayed at the remote <a>Web Intents enabled UPnP device</a>.
-          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><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><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><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. This means that there is a need for continuous communication between the Client page and the Service page,
-          which is "hidden", i.e. it has no UI. The Client page creates a messaging channel and sends the messaging channel port to the Service page trhrough the intent invocation.
-          A high level "TV control" protocol, supporting commands such as "play", "pause" and "stop, runs on top of the messaging channel. 
-        </p>
-        <p>
-          In this example the assumption is that he Client invokes an intent to discover a Service that supports a specified protocol running on top of the message channel So the 
-          "discover" intent Action is used and Type is set to the specific protocol used to communicate with the Service.
-        </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><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><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><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><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><img src="Example1_registration_page/Slide1.png" alt="Example1 registration page" width="280" height="280" ><br>
-         (<a href="Example1_registration_page/Slide1.png">View as PNG</a>)
-        </p>      
-      </section>      
-    
-      <section>
-        <h3>Example of UPnP Device description document</h3>
-        <p><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 colleagues Anders Isberg, Naoyuki Sato, Tatsuya Igarashi, 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
diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD/Example1_registration_page/Slide1.png
Binary file wi-addendum-local-services/FPWD/Example1_registration_page/Slide1.png has changed
diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD/Example_device_and_service_description_pages/Slide1.png
Binary file wi-addendum-local-services/FPWD/Example_device_and_service_description_pages/Slide1.png has changed
diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD/Example_device_and_service_description_pages/Slide2.png
Binary file wi-addendum-local-services/FPWD/Example_device_and_service_description_pages/Slide2.png has changed
diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD/Example_scenario_1/Slide1.png
Binary file wi-addendum-local-services/FPWD/Example_scenario_1/Slide1.png has changed
diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD/Example_scenario_1/Slide2.png
Binary file wi-addendum-local-services/FPWD/Example_scenario_1/Slide2.png has changed
diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD/Example_scenario_1/Slide3.png
Binary file wi-addendum-local-services/FPWD/Example_scenario_1/Slide3.png has changed
diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD/Example_scenario_2/Slide1.png
Binary file wi-addendum-local-services/FPWD/Example_scenario_2/Slide1.png has changed
diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD/Example_scenario_2/Slide2.png
Binary file wi-addendum-local-services/FPWD/Example_scenario_2/Slide2.png has changed
diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD/Example_scenario_2/Slide3.png
Binary file wi-addendum-local-services/FPWD/Example_scenario_2/Slide3.png has changed
diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD/Example_scenario_2/Slide4.png
Binary file wi-addendum-local-services/FPWD/Example_scenario_2/Slide4.png has changed
diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD/FPWD.html
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/wi-addendum-local-services/FPWD/FPWD.html	Tue Sep 25 11:20:35 2012 +0200
@@ -0,0 +1,990 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr">
+<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,
+     -->
+    
+    
+
+    <style type="text/css">
+
+      /* Add addition spacing to <ol> and <ul> for rule definition */
+      ol.rule li, ul.rule li { padding:0.6em; }
+
+    </style>
+
+
+  <style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon - http://berjon.com/
+ *****************************************************************/
+
+/* --- INLINES --- */
+em.rfc2119 { 
+    text-transform:     lowercase;
+    font-variant:       small-caps;
+    font-style:         normal;
+    color:              #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+    border: none;
+}
+
+dfn {
+    font-weight:    bold;
+}
+
+a.internalDFN {
+    color:  inherit;
+    border-bottom:  1px solid #99c;
+    text-decoration:    none;
+}
+
+a.externalDFN {
+    color:  inherit;
+    border-bottom:  1px dotted #ccc;
+    text-decoration:    none;
+}
+
+a.bibref {
+    text-decoration:    none;
+}
+
+cite .bibref {
+    font-style: normal;
+}
+
+code {
+    color:  #ff4500;
+}
+
+
+/* --- --- */
+ol.algorithm { counter-reset:numsection; list-style-type: none; }
+ol.algorithm li { margin: 0.5em 0; }
+ol.algorithm li:before { font-weight: bold; counter-increment: numsection; content: counters(numsection, ".") ") "; }
+
+/* --- TOC --- */
+.toc a, .tof a {
+    text-decoration:    none;
+}
+
+a .secno, a .figno {
+    color:  #000;
+}
+
+ul.tof, ol.tof {
+    list-style: none outside none;
+}
+
+.caption {
+    margin-top: 0.5em;
+    font-style:   italic;
+}
+
+/* --- TABLE --- */
+table.simple {
+    border-spacing: 0;
+    border-collapse:    collapse;
+    border-bottom:  3px solid #005a9c;
+}
+
+.simple th {
+    background: #005a9c;
+    color:  #fff;
+    padding:    3px 5px;
+    text-align: left;
+}
+
+.simple th[scope="row"] {
+    background: inherit;
+    color:  inherit;
+    border-top: 1px solid #ddd;
+}
+
+.simple td {
+    padding:    3px 10px;
+    border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+    background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+    margin-top: 0;
+}
+
+.section dd > p:last-child {
+    margin-bottom: 0;
+}
+
+.section dd {
+    margin-bottom:  1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+    margin-bottom:  0;
+}
+</style><style>/* --- EXAMPLES --- */
+div.example-title {
+    min-width: 7.5em;
+    color: #b9ab2d;
+}
+div.example-title span {
+    text-transform: uppercase;   
+}
+aside.example, div.example, div.illegal-example {
+    padding: 0.5em;
+    margin: 1em 0;
+    position: relative;
+    clear: both;
+}
+div.illegal-example { color: red }
+div.illegal-example p { color: black }
+aside.example, div.example {
+    padding: .5em;
+    border-left-width: .5em;
+    border-left-style: solid;
+    border-color: #e0cb52;
+    background: #fcfaee;    
+}
+
+aside.example div.example {
+    border-left-width: .1em;
+    border-color: #999;
+    background: #fff;
+}
+aside.example div.example div.example-title {
+    color: #999;
+}
+</style><style>/* --- ISSUES/NOTES --- */
+div.issue-title, div.note-title {
+    padding-right:  1em;
+    min-width: 7.5em;
+    color: #b9ab2d;
+}
+div.issue-title { color: #e05252; }
+div.note-title { color: #52e052; }
+div.issue-title span, div.note-title span {
+    text-transform: uppercase;
+}
+div.note, div.issue {
+    margin-top: 1em;
+    margin-bottom: 1em;
+}
+.note > p:first-child, .issue > p:first-child { margin-top: 0 }
+.issue, .note {
+    padding: .5em;
+    border-left-width: .5em;
+    border-left-style: solid;
+}
+div.issue, div.note {
+    padding: 0.5em;
+    margin: 1em 0;
+    position: relative;
+    clear: both;
+}
+span.note, span.issue { padding: .1em .5em .15em; }
+
+.issue {
+    border-color: #e05252;
+    background: #fbe9e9;
+}
+.note {
+    border-color: #52e052;
+    background: #e9fbe9;
+}
+
+
+</style><style>/* HIGHLIGHTS */
+code.prettyprint {
+    color:  inherit;
+}
+
+/* this from google-code-prettify */
+.pln{color:#000}@media screen{.str{color:#080}.kwd{color:#008}.com{color:#800}.typ{color:#606}.lit{color:#066}.pun,.opn,.clo{color:#660}.tag{color:#008}.atn{color:#606}.atv{color:#080}.dec,.var{color:#606}.fun{color:red}}@media print,projection{.str{color:#060}.kwd{color:#006;font-weight:bold}.com{color:#600;font-style:italic}.typ{color:#404;font-weight:bold}.lit{color:#044}.pun,.opn,.clo{color:#440}.tag{color:#006;font-weight:bold}.atn{color:#404}.atv{color:#060}}ol.linenums{margin-top:0;margin-bottom:0}li.L0,li.L1,li.L2,li.L3,li.L5,li.L6,li.L7,li.L8{list-style-type:none}li.L1,li.L3,li.L5,li.L7,li.L9{background:#eee}
+</style><link rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD"><!--[if lt IE 9]><script src='undefined://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+  <body><div class="head">
+  <p>
+    
+      <a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a>
+    
+  </p>
+  <h1 class="title" id="title">Web Intents Addendum - Local Services</h1>
+  
+  <h2 id="w3c-working-draft-27-september-2012"><abbr title="World Wide Web Consortium">W3C</abbr> Working Draft 27 September 2012</h2>
+  <dl>
+    
+      <dt>This version:</dt>
+      <dd><a href="http://www.w3.org/TR/2012/WD-Web Intents-LD addendum-20120927/">http://www.w3.org/TR/2012/WD-Web Intents-LD addendum-20120927/</a></dd>
+      <dt>Latest published version:</dt>
+      <dd><a href="http://www.w3.org/TR/Web Intents-LD addendum/">http://www.w3.org/TR/Web Intents-LD addendum/</a></dd>
+    
+    
+      <dt>Latest editor's draft:</dt>
+      <dd><a href="http://w3c-test.org/dap/wi-addendum-local-services/">http://w3c-test.org/dap/wi-addendum-local-services/</a></dd>
+    
+    
+    
+    
+    
+    
+    <dt>Editors:</dt>
+    <dd><span>Claes Nilsson</span>, <a href="http://www.sonymobile.com/se/">Sony Mobile</a></dd>
+<dd><span>Norifumi Kikkawa</span>, <a href="http://www.sony.net/">Sony Corporation</a></dd>
+
+    
+  </dl>
+  
+  
+  
+  
+    
+      <p class="copyright">
+        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>  
+        2012
+        
+        <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup></sup> 
+        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
+        <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
+        <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved.
+        <abbr title="World Wide Web Consortium">W3C</abbr> <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>
+    <section id="abstract" class="introductory"><h2>Abstract</h2><p>
+      This specification is an addendum to Web Intents, [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>], that defines how Web Intents enabled User Agents can discover and communicate 
+      with local Web Intents Services.
+    </p></section><section id="sotd" class="introductory"><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 <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision
+          of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> 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/">DAP/Web Apps Web Intents task force</a> as a First Public Working Draft.
+          
+            This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.
+          
+          If you wish to make comments regarding this document, please send them to 
+          <a href="mailto:public-web-intents@w3.org">public-web-intents@w3.org</a> 
+          (<a href="mailto:public-web-intents-request@w3.org?subject=subscribe">subscribe</a>,
+          <a href="http://lists.w3.org/Archives/Public/public-web-intents/">archives</a>).
+          
+          
+          All feedback is welcome.
+        </p>
+        
+          <p>
+            Publication as a Working Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> 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 <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+          
+          
+          
+            
+              <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="" 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 believes 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 <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+          
+          
+        </p>
+        
+      
+    
+  
+</section><section id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a href="#conformance" class="tocxref"><span class="secno">2. </span>Conformance</a><ul class="toc"><li class="tocline"><a href="#dependencies" class="tocxref"><span class="secno">2.1 </span>Dependencies</a></li></ul></li><li class="tocline"><a href="#terminology" class="tocxref"><span class="secno">3. </span>Terminology</a><ul class="toc"><li class="tocline"><a href="#upnp-related-terms" class="tocxref"><span class="secno">3.1 </span>UPnP related terms</a></li><li class="tocline"><a href="#mdns-related-terms" class="tocxref"><span class="secno">3.2 </span>mDNS related terms</a></li></ul></li><li class="tocline"><a href="#upnp-adaptation" class="tocxref"><span class="secno">4. </span>UPnP adaptation</a><ul class="toc"><li class="tocline"><a href="#web-intents-enabled-upnp-device" class="tocxref"><span class="secno">4.1 </span><span class="formerLink">Web Intents enabled UPnP device</span></a><ul class="toc"><li class="tocline"><a href="#upnp-web-intents-servicetype" class="tocxref"><span class="secno">4.1.1 </span>UPnP Web Intents serviceType</a></li><li class="tocline"><a href="#web-intents-specific-ssdp-headers" class="tocxref"><span class="secno">4.1.2 </span>Web Intents specific SSDP headers</a></li><li class="tocline"><a href="#web-intents-document" class="tocxref"><span class="secno">4.1.3 </span>Web Intents document</a></li><li class="tocline"><a href="#web-intents-service-pages" class="tocxref"><span class="secno">4.1.4 </span>Web Intents Service pages</a></li></ul></li><li class="tocline"><a href="#upnp-enabled-user-agent" class="tocxref"><span class="secno">4.2 </span><span class="formerLink">UPnP enabled User Agent</span></a><ul class="toc"><li class="tocline"><a href="#dynamic-service-registration-based-on-m-search" class="tocxref"><span class="secno">4.2.1 </span>Dynamic Service registration based on M-SEARCH</a></li><li class="tocline"><a href="#dynamic-service-registration-based-on-notify" class="tocxref"><span class="secno">4.2.2 </span>Dynamic Service registration based on NOTIFY</a></li><li class="tocline"><a href="#support-for-web-intents-and-upnp" class="tocxref"><span class="secno">4.2.3 </span>Support for Web Intents and UPnP</a></li><li class="tocline"><a href="#service-availability-management" class="tocxref"><span class="secno">4.2.4 </span>Service availability management</a></li></ul></li></ul></li><li class="tocline"><a href="#mdns-dns-sd-adaptation" class="tocxref"><span class="secno">5. </span>mDNS (DNS-SD) adaptation</a><ul class="toc"><li class="tocline"><a href="#web-intents-enabled-mdns-device" class="tocxref"><span class="secno">5.1 </span>Web Intents enabled mDNS device</a><ul class="toc"><li class="tocline"><a href="#web-intents-service-type-for-dns-sd" class="tocxref"><span class="secno">5.1.1 </span>Web Intents service type for DNS-SD</a></li></ul></li><li class="tocline"><a href="#mdns-enabled-user-agent" class="tocxref"><span class="secno">5.2 </span>mDNS enabled User Agent</a><ul class="toc"><li class="tocline"><a href="#dynamic-service-registration" class="tocxref"><span class="secno">5.2.1 </span>Dynamic Service registration</a></li></ul></li><li class="tocline"><a href="#sample-records" class="tocxref"><span class="secno">5.3 </span>Sample Records</a></li></ul></li><li class="tocline"><a href="#apis-protocols-client---service" class="tocxref"><span class="secno">6. </span>APIs / protocols Client - Service </a></li><li class="tocline"><a href="#examples-and-scenarios" class="tocxref"><span class="secno">A. </span>Examples and scenarios</a><ul class="toc"><li class="tocline"><a href="#view-and-control-video-on-remote-device-through-service-page-control-buttons" class="tocxref"><span class="secno">A.1 </span>View and control video on remote device through Service page control buttons</a></li><li class="tocline"><a href="#view-and-control-video-on-remote-device-through-client-page-control-buttons" class="tocxref"><span class="secno">A.2 </span>View and control video on remote device through Client page control buttons</a></li><li class="tocline"><a href="#example-of-web-intents-document" class="tocxref"><span class="secno">A.3 </span>Example of Web Intents document</a></li><li class="tocline"><a href="#example-of-upnp-device-description-document" class="tocxref"><span class="secno">A.4 </span>Example of UPnP Device description document</a></li></ul></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">B. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">C.1 </span>Normative references</a></li></ul></li></ul></section>
+    
+    <section class="informative" id="introduction">
+      <!--OddPage--><h2><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
+      <p>
+        Web Intents,[<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>], 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 class="rule">
+         <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>
+         <li>The selected service executes 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 [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>].
+        This code is the same irrespective of whether the Service executing the intent action is a cloud based Service or a local Service.
+      </p>
+      <div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example highlight prettyprint"><span class="com">// Create a new intent</span><span class="pln">
+</span><span class="kwd">var</span><span class="pln"> intent </span><span class="pun">=</span><span class="pln"> </span><span class="kwd">new</span><span class="pln"> </span><span class="typ">Intent</span><span class="pun">(</span><span class="pln"> </span><span class="str">"http://webintents.org/view"</span><span class="pun">,</span><span class="str">"video/mp4"</span><span class="pun">,{</span><span class="pln"> </span><span class="str">"src"</span><span class="pun">:</span><span class="pln">videoCanvas</span><span class="pun">.</span><span class="pln">src</span><span class="pun">,</span><span class="pln"> </span><span class="str">"img"</span><span class="pun">:</span><span class="pln"> videoCanvas</span><span class="pun">.</span><span class="pln">poster</span><span class="pun">});</span><span class="pln">
+					
+</span><span class="com">// Start intents picker </span><span class="pln">
+navigator</span><span class="pun">.</span><span class="pln">startActivity</span><span class="pun">(</span><span class="pln">intent</span><span class="pun">,</span><span class="pln">
+  </span><span class="com">// On Result</span><span class="pln">
+  </span><span class="kwd">function</span><span class="pun">(</span><span class="pln">intentData</span><span class="pun">)</span><span class="pln"> </span><span class="pun">{</span><span class="pln">console</span><span class="pun">.</span><span class="pln">log</span><span class="pun">(</span><span class="str">"player.html: On Result"</span><span class="pln"> </span><span class="pun">+</span><span class="pln"> intentData</span><span class="pun">);},</span><span class="pln"> 
+  </span><span class="com">// On Failure</span><span class="pln">
+  </span><span class="kwd">function</span><span class="pun">(</span><span class="pln">intentData</span><span class="pun">)</span><span class="pln"> </span><span class="pun">{</span><span class="pln">console</span><span class="pun">.</span><span class="pln">log</span><span class="pun">(</span><span class="str">"player.html: On Failure"</span><span class="pln"> </span><span class="pun">+</span><span class="pln"> intentData</span><span class="pun">);});</span></pre></div>
+      <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 class="rule">
+         <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"><!--OddPage--><h2><span class="secno">2. </span>Conformance</h2>
+<p>
+  As well as sections marked as non-normative, all authoring guidelines, diagrams, examples,
+  and notes in this specification are non-normative. Everything else in this specification is
+  normative.
+</p>
+<p>
+  The key words <em class="rfc2119" title="must">must</em>, <em class="rfc2119" title="must not">must not</em>, <em class="rfc2119" title="required">required</em>, <em class="rfc2119" title="should">should</em>, <em class="rfc2119" title="should not">should not</em>, <em class="rfc2119" title="recommended">recommended</em>, <em class="rfc2119" title="may">may</em>,
+  and <em class="rfc2119" title="optional">optional</em> in this specification are to be interpreted as described in [<cite><a class="bibref" href="#bib-RFC2119">RFC2119</a></cite>].
+</p>
+     
+      <p>        
+        This specification defines conformance criteria that apply to:
+      </p>   
+      <ul class="rule">
+        <li><dfn id="dfn-upnp-enabled-user-agent">UPnP enabled User Agent</dfn>: A <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> <em class="rfc2119" title="must">must</em> support Web Intents [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>] and the conformance criteria 
+        stated in this specification. </li>
+        <li><dfn id="dfn-web-intents-enabled-upnp-device">Web Intents enabled UPnP device</dfn>: A <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> support [<cite><a class="bibref" href="#bib-UPNP-DEVICEARCH">UPNP-DEVICEARCH</a></cite>] and the conformance criteria 
+        stated in this specification. </li>
+        <li><dfn id="dfn-mdns-enabled-user-agent">mDNS enabled User Agent</dfn>: An <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> <em class="rfc2119" title="must">must</em> support Web Intents [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>] and the conformance criteria 
+        stated in this specification. </li>
+        <li><dfn id="dfn-web-intents-enabled-mdns-device">Web Intents enabled mDNS device</dfn>: A <a href="#dfn-web-intents-enabled-mdns-device" class="internalDFN">Web Intents enabled mDNS device</a> <em class="rfc2119" title="must">must</em> support [<cite><a class="bibref" href="#bib-DNS-SD">DNS-SD</a></cite>], [<cite><a class="bibref" href="#bib-MDNS">MDNS</a></cite>] and the conformance criteria 
+        stated in this specification. </li>
+      </ul>
+     
+      <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 [<cite><a class="bibref" href="#bib-WEBIDL">WEBIDL</a></cite>],
+        as this specification uses that specification and terminology.
+      </p>
+      <section id="dependencies">
+        <h3><span class="secno">2.1 </span>Dependencies</h3>
+        <p>
+          This specification relies on the following specifications:
+        </p>
+          
+        <dl>
+          <dt>Web Intents</dt>
+          <dd>This addendum specification is dependent on and defines optional extensions to the basic Web Intents specification, [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>]. </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, [<cite><a class="bibref" href="#bib-UPNP-DEVICEARCH">UPNP-DEVICEARCH</a></cite>]. </dd>
+          <dt>IANA Service Name and Transport Protocol Port Number Registry</dt>
+          <dd>This addendum specification adds new entry on it, [<cite><a class="bibref" href="#bib-IANA-SRVPORT-REG">IANA-SRVPORT-REG</a></cite>]. </dd>
+          <dt>DNS-SD</dt>
+          <dd>This addendum specification is dependent on it, [<cite><a class="bibref" href="#bib-DNS-SD">DNS-SD</a></cite>]. </dd>
+          <dt>mDNS</dt>
+          <dd>This addendum specification is dependent on it, [<cite><a class="bibref" href="#bib-MDNS">MDNS</a></cite>]. </dd>
+        </dl>
+          
+           
+      </section>
+    </section>
+    
+    <section id="terminology">
+      <!--OddPage--><h2><span class="secno">3. </span>Terminology</h2>
+      <p>
+        Web Intents related terms are used according to section "Terminology" in [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>].
+      </p>
+     
+      <section id="upnp-related-terms"> 
+        <h3><span class="secno">3.1 </span>UPnP related terms</h3>
+        <p>
+          UPnP related terms are used according to [<cite><a class="bibref" href="#bib-UPNP-DEVICEARCH">UPNP-DEVICEARCH</a></cite>]. 
+        </p>
+        <p>
+          The <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> has the role of a <dfn id="dfn-control-point">control point</dfn>  according to UPnP terminology. 
+        </p>     
+        <p>
+          The <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a> discovered by the <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> has the roles of <dfn id="dfn-device">device</dfn> according to UPnP terminology. 
+        </p>        
+      </section>
+      
+      <section id="mdns-related-terms"> 
+        <h3><span class="secno">3.2 </span>mDNS related terms</h3>
+        <p>
+          The <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> has the role of a <dfn id="dfn-DNS-client">DNS client</dfn> with capability of [<cite><a class="bibref" href="#bib-DNS-SD">DNS-SD</a></cite>]. 
+        </p>
+        <p>
+          The <a href="#dfn-web-intents-enabled-mdns-device" class="internalDFN">Web Intents enabled mDNS device</a> discovered by the <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> has the roles of <dfn id="dfn-service">service</dfn> according to [<cite><a class="bibref" href="#bib-MDNS">MDNS</a></cite>] and [<cite><a class="bibref" href="#bib-DNS-SD">DNS-SD</a></cite>]. 
+        </p>        
+      </section>     
+      
+
+    </section>
+    
+    <section id="upnp-adaptation">
+    
+      <!--OddPage--><h2><span class="secno">4. </span>UPnP adaptation</h2> 
+      
+      <section id="web-intents-enabled-upnp-device">   
+      
+        <h3><span class="secno">4.1 </span><a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a></h3> 
+        
+        <p>
+          The <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> support this section.
+        </p>
+        
+        <section id="upnp-web-intents-servicetype">    
+        
+          <h4><span class="secno">4.1.1 </span>UPnP Web Intents serviceType</h4>
+          
+          <p>
+            The <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> support one UPnP service which serviceType is the <code>urn:schemas-webintents-org:service:WebIntents:1</code> 
+            as a vendor specific serviceType according to [<cite><a class="bibref" href="#bib-UPNP-DEVICEARCH">UPNP-DEVICEARCH</a></cite>]. It is vendor dependent how the <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a> 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>boolean</code> data type to comform to [<cite><a class="bibref" href="#bib-UPNP-DEVICEARCH">UPNP-DEVICEARCH</a></cite>]
+            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><img src="Example_device_and_service_description_pages/Slide2.png" alt="Service description page" width="600" height="600"><br>
+           (<a href="Example_device_and_service_description_pages/Slide2.png">View as PNG</a>)
+          </p>   
+             
+        
+        </section>   
+        
+        <section id="web-intents-specific-ssdp-headers">    
+        
+          <h4><span class="secno">4.1.2 </span>Web Intents specific SSDP headers</h4>           
+
+          <p>
+            The <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a> <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 class="rule">
+            <li>
+              <code>location.webintents.org</code>: <em class="rfc2119" title="required">required</em>. States the location to the Web Intents document in the <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a>. 
+              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 
+              comma. Commas included in action strings <em class="rfc2119" title="must">must</em> be percent-encoded as 
+              defined in [<cite><a class="bibref" href="#bib-RFC3986">RFC3986</a></cite>], section-2.1.
+              <br>
+              This header allows the <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> to filter received SSDP messages so that the <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> only has to 
+              retrieve Web Intents documents for matching Web Intents Actions.        
+            </li>
+          </ul>         
+
+        </section>   
+        
+        <section id="web-intents-document">    
+        
+          <h4><span class="secno">4.1.3 </span>Web Intents document</h4>   
+
+          <p>
+            The <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> host Web Intents documents for the Web Intents Services the <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a> 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 [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>]. They may also contain Service handler code for Services registered within the same document. 
+          </p>              
+        
+        </section>   
+        
+        <section id="web-intents-service-pages">    
+        
+          <h4><span class="secno">4.1.4 </span>Web Intents Service pages</h4>    
+          
+          <p>
+            The <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> host 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 [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>]. 
+          </p>   
+        
+        </section>          
+        
+      </section>   
+      
+      <section id="upnp-enabled-user-agent">
+      
+        <h3><span class="secno">4.2 </span><a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a></h3> 
+        
+        <p>
+          The <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> <em class="rfc2119" title="must">must</em> support discovery of <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a>s through SSDP Discovery or through Advertisement 
+          or through both methods according to [<cite><a class="bibref" href="#bib-UPNP-DEVICEARCH">UPNP-DEVICEARCH</a></cite>] 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" id="dynamic-service-registration-based-on-m-search">
+            <h4><span class="secno">4.2.1 </span>Dynamic Service registration based on M-SEARCH</h4><p><em>This section is non-normative.</em></p>
+
+            <p>
+              The section describes the discovery process based on standard UPnP M-SEARCH multicast request.
+            </p>
+            
+            <p>
+              When the navigator.startActivity method [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>] is called, the <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> runs the following steps:
+            </p>
+              
+            <ol class="rule">          
+              <li>
+                 Send a multicast request with the method M-SEARCH in the format specified by [<cite><a class="bibref" href="#bib-UPNP-DEVICEARCH">UPNP-DEVICEARCH</a></cite>].
+                 <br>
+                 The <code>ST</code> header is set to: <code>urn:schemas-webintents-org:service:WebIntents:1</code>
+              </li>
+              
+              <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 <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> attempts to retrieve the Web Intents document from the discovered <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a>.              
+                 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 <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> 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 <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> fails to retrieve the Web Intents document it silently disregards the received M-SEARCH response.
+                 <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 <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> silently disregards the the received M-SEARCH response.
+              </li>
+       
+              <li>
+                 It is expected that the Web Intents document contains registration markup and the <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> interprets this
+                 registration markup according to the rules for registration defined by [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>] and register the Services accordingly.           
+              </li>
+         
+              <li>
+                 The <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> makes each dynamically registered Service, that matches the Action of the invoked intent, available for selection 
+                 by the user, typically by making them visible and selectable in a Web Intents Service picker.                          
+              </li>
+         
+              <li>
+                 Based on user selection of a dynamically registered Service the <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> 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 [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>].                        
+              </li>
+      
+            </ol> 
+     
+          </section>
+          
+          <section class="informative" id="dynamic-service-registration-based-on-notify">
+            <h4><span class="secno">4.2.2 </span>Dynamic Service registration based on NOTIFY</h4><p><em>This section is non-normative.</em></p>
+            <p>
+              This section describes the discovery process based on standard UPnP Advertisement with NOTIFY message.            
+            </p> 
+           
+            <p>
+             The <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> <em class="rfc2119" title="may">may</em> continuously listen to and act on advertisments according to the following steps:
+            </p>   
+            <ol class="rule">   
+          
+              <li>
+                The <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> maintains a list of announced UPnP services based on received SSDP NOTIFY messages
+                with <code>NT</code> header equal to <code>urn:schemas-webintents-org:service:WebIntents:1</code>.
+              </li>
+              
+              <li>
+                When the navigator.startActivity method [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>] is called the <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> checks the list
+                of of announced services and attempts to retrieve the Web Intents document from the discovered <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a> in the following cases:                
+                <ul>
+                  <li>
+                    The received NOTIFY message contains an <code>action.webintents.org</code> header and this header matches the Action of the invoked intent.
+                  </li>
+                  <li>
+                    The received NOTIFY message does not contain an <code>action.webintents.org</code> header.
+                  </li>                
+                </ul>
+                <br>     
+                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 <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> fails to retrieve the Web Intents document it silently disregards the received NOTIFY message.
+                <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 <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> silently disregards the received NOTIFY message.
+              </li>
+                       
+              <li>
+                 It is expected that the Web Intents document contains registration markup and the <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> interprets the
+                 Web Intents document according to the rules for registration defined by [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>] and register the Services accordingly.                         
+              </li>
+                        
+              <li>
+                 The <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> makes each dynamically registered Service, that matches the Action of the invoked intent, available for selection 
+                 by the user, typically by making them visible and selectable in a Web Intents Service picker.                          
+              </li>
+                       
+              <li>
+                 Based on user selection of a dynamically registered Service the <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> 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 [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>].                          
+              </li>
+            </ol> 
+             
+            <div class="note"><div class="note-title"><span>Note</span></div><p class="">
+              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></div> 
+          
+          </section>  
+          
+          <section class="informative" id="support-for-web-intents-and-upnp">  
+            <h4><span class="secno">4.2.3 </span>Support for Web Intents and UPnP</h4><p><em>This section is non-normative.</em></p>
+            <p>
+              In addition to the normative statements defined in this specification a <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> that complies to this specification 
+              supports Web Intents according to [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>] and UPnP Discovery, Description and Control according to [<cite><a class="bibref" href="#bib-UPNP-DEVICEARCH">UPNP-DEVICEARCH</a></cite>]. 
+              However, it is implementation dependent whether this is supported natively in the User Agent or supported through some external component, 
+              e.g. an in-device web server. 
+            </p>         
+          </section>           
+          
+          <section class="informative" id="service-availability-management">
+      
+            <h4><span class="secno">4.2.4 </span>Service availability management</h4><p><em>This section is non-normative.</em></p>
+
+            <p>
+             The <a href="#dfn-upnp-enabled-user-agent" class="internalDFN">UPnP enabled User Agent</a> should manage the availability of UPnP services. For example detect when contact with a <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a> 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 should be considered and long lasting "keep alive" sessions" should be avoided.           
+            </p>        
+        
+          </section>
+
+      </section>        
+      
+   
+      
+    </section>   
+    
+    <section id="mdns-dns-sd-adaptation">
+    
+      <!--OddPage--><h2><span class="secno">5. </span>mDNS (DNS-SD) adaptation</h2> 
+      
+      <p>
+        This section describes how the User Agent handles Web Intents Services provided by local devices supporting mDNS and DNS-SD.          
+      </p>
+
+      <section id="web-intents-enabled-mdns-device">   
+      
+        <h3><span class="secno">5.1 </span>Web Intents enabled mDNS device</h3> 
+        
+        <p>
+          The <a href="#dfn-web-intents-enabled-mdns-device" class="internalDFN">Web Intents enabled mDNS device</a> <em class="rfc2119" title="must">must</em> support this section.
+        </p>
+        
+        <section id="web-intents-service-type-for-dns-sd">    
+        
+          <h4><span class="secno">5.1.1 </span>Web Intents service type for DNS-SD</h4>     
+          
+          <p>
+            The <a href="#dfn-web-intents-enabled-mdns-device" class="internalDFN">Web Intents enabled mDNS device</a> <em class="rfc2119" title="must">must</em> support [<cite><a class="bibref" href="#bib-DNS-SD">DNS-SD</a></cite>] with a SRV record of the <code>webintents</code> service type. 
+          </p>  
+          
+            <div class="note"><div class="note-title"><span>Note</span></div><p class="">
+              A service type <code>webintents</code> should be registered in [<cite><a class="bibref" href="#bib-IANA-SRVPORT-REG">IANA-SRVPORT-REG</a></cite>].
+            </p></div>
+
+          <p>          
+            The TXT record for the <code>webintents</code> service must have following parameters:           
+          </p>          
+          <ul class="rule">
+            <li>
+              <code>location</code>: <em class="rfc2119" title="required">required</em>. States the location to the Web Intents document in the <a href="#dfn-web-intents-enabled-mdns-device" class="internalDFN">Web Intents enabled mDNS device</a>. 
+              The value of this header is path to be concatenated with a host of the <a href="#dfn-web-intents-enabled-mdns-device" class="internalDFN">Web Intents enabled mDNS device</a> to determine the location. The definition of the Web Intents document is the same as for UPnP.
+            </li>
+            <li>
+              <code>action</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 
+              comma. Commas included in action strings <em class="rfc2119" title="must">must</em> be percent-encoded as 
+              defined in [<cite><a class="bibref" href="#bib-RFC3986">RFC3986</a></cite>], section-2.1.
+              <br>
+              This allows the <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> to filter received mDNS messages so that the <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> only has to 
+              retrieve Web Intents documents for matching Web Intents Actions.        
+            </li>
+          </ul>         
+
+        </section>   
+        
+      </section>   
+      <section id="mdns-enabled-user-agent">    
+        <h3><span class="secno">5.2 </span>mDNS enabled User Agent</h3> 
+
+        <p>
+          The <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> <em class="rfc2119" title="must">must</em> support discovery of <a href="#dfn-web-intents-enabled-mdns-device" class="internalDFN">Web Intents enabled mDNS device</a>s through mDNS and DNS-SD 
+          according to [<cite><a class="bibref" href="#bib-MDNS">MDNS</a></cite>], [<cite><a class="bibref" href="#bib-DNS-SD">DNS-SD</a></cite>] and according to the Web Intents specific DNS records defined in this specification, section 5.1. 
+        </p>
+        
+        <section class="informative" id="dynamic-service-registration">
+          <h4><span class="secno">5.2.1 </span>Dynamic Service registration</h4><p><em>This section is non-normative.</em></p>   
+          <p>
+            When the navigator.startActivity method [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>] is called, the <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> typically runs the following steps:
+          </p>
+            
+          <ol class="rule">          
+            <li>
+               Send a multicast PTR query of the <code>_webintents._tcp.local</code> in the format specified by [<cite><a class="bibref" href="#bib-MDNS">MDNS</a></cite>] and [<cite><a class="bibref" href="#bib-DNS-SD">DNS-SD</a></cite>].
+               <br>
+            </li>
+
+            <li>
+               For each response, send a unicast TXT query of the webintents service instance in the PTR answer.
+               <br>
+               <p>This step can be omitted in case that the <a href="#dfn-web-intents-enabled-mdns-device" class="internalDFN">Web Intents enabled mDNS device</a> attaches a TXT answer with the previous answer.
+            </p></li>
+
+            <li>
+               For each matching response, i.e. the response TXT record does not have an action parameter or does have an <code>action</code> parameter matching the Action of the invoked intent,
+               send a unicast request with a SRV query of the webintens service instance.
+               <br>
+               <p>This step can be omitted in case that the <a href="#dfn-web-intents-enabled-mdns-device" class="internalDFN">Web Intents enabled mDNS device</a> attaches a SRV answer with the previous answer.
+            </p></li>
+
+            <li>
+               For each response, send a unicast A and/or AAAA query of the host name in the SRV answer.
+               <br>
+               <p>This step can be omitted in case that the <a href="#dfn-web-intents-enabled-mdns-device" class="internalDFN">Web Intents enabled mDNS device</a> attaches an A and/or AAAA answer with the previous answer.
+            </p></li>
+
+            <li>
+               The <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> attempts to retrieve the Web Intents document from the discovered <a href="#dfn-web-intents-enabled-mdns-device" class="internalDFN">Web Intents enabled mDNS device</a>.
+               The destination URL consists of an IP address in the A or AAAA answer, a port number in the SRV record and an absolute path in the <code>location</code> parameter of the TXT record.  
+               <br>  <br>
+               If the <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> fails to retrieve the Web Intents document it silently disregards the received response.
+               <br>  <br>
+               If the <code>action</code> parameter is present and does not match the <code>action</code> attributes of the Services registered in the retrieved Web Intents 
+               document the <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> silently disregards the the received response.
+               <br>  <br>
+               Note that following steps are identical to those of UPnP described in 4.2.
+            </li>
+          
+            <li>
+               It is expected that the Web Intents document contains registration markup and the <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> interprets this
+               registration markup according to the rules for registration defined by [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>] and register the Services accordingly.           
+            </li>
+          
+            <li>
+               The <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> makes each dynamically registered Service, that matches the Action of the invoked intent, available for selection 
+               by the user, typically by making them visible and selectable in a Web Intents Service picker.                          
+            </li>
+          
+            <li>
+               Based on user selection of a dynamically registered Service the <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> 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 [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>].                        
+            </li>
+    
+          </ol> 
+                 
+        </section>          
+
+      </section>    
+      <section class="informative" id="sample-records">
+        <h3><span class="secno">5.3 </span>Sample Records</h3><p><em>This section is non-normative.</em></p> 
+        
+        <p>
+          See below for the example records for Web Intents. An <a href="#dfn-mdns-enabled-user-agent" class="internalDFN">mDNS enabled User Agent</a> looking for devices supporting http://webintents.org/view Web Intents can understand that 
+          it is possible to get a Web Intents document for "LivingRoomTV" at http://192.168.1.47:3619/webintents.html.
+        </p>
+
+        <ul class="rule">
+          <li>
+            <code>_webintents._tcp.local. 120 IN PTR LivingRoomTV._webintents._tcp.local.</code>: A LivingRoomTV instance serves webintents service.
+          </li>
+          <li>
+            <code>LivingRoomTV._webintents._tcp.local. 120 IN SRV 0 0 3619 TV40EX-W2000.local.</code>: A host "TV40EX-W2000" in the link local network offers the LivingRoomTV webintents service instance in its port 3619.
+          </li>
+          <li>
+            <code>LivingRoomTV._webintents._tcp.local. 120 IN TXT location=/webintents.html action=http://webintents.org/view</code>: It offers http://webintents.org/view type of Web Intents. The absolute path for its Web Intents document is "/webintents.html". Note that the actual binary format of the TXT record value is concatinating key-value pairs each of which is a single byte length followed by 0-255 length key=value character string as defined in [DNS-SD].
+          </li>
+          <li>
+            <code>TV40EX-W2000 120 IN A 192.168.1.47</code>: A host "TV40EX-W2000" is on 192.168.1.47.
+          </li>
+        </ul>
+
+      </section>   
+                 
+    </section>         
+    
+        
+    <section class="informative" id="apis-protocols-client---service">
+      <!--OddPage--><h2><span class="secno">6. </span>APIs / protocols Client - Service </h2><p><em>This section is non-normative.</em></p>
+      <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 <abbr title="World Wide Web Consortium">W3C</abbr> 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 class="rule">
+        <li>
+          A Client application invoking a "View" intent provides, as intent payload data, a link to a video to be displayed at the remote <a href="#dfn-web-intents-enabled-upnp-device" class="internalDFN">Web Intents enabled UPnP device</a>.
+          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" id="examples-and-scenarios">
+    <!--OddPage--><h2><span class="secno">A. </span>Examples and scenarios</h2><p><em>This section is non-normative.</em></p>
+      <section id="view-and-control-video-on-remote-device-through-service-page-control-buttons">
+        <h3><span class="secno">A.1 </span>View and control video on remote device through Service page control buttons</h3><p><em>This section is non-normative.</em></p>
+        <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><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><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><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 id="view-and-control-video-on-remote-device-through-client-page-control-buttons">
+        <h3><span class="secno">A.2 </span>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. This means that there is a need for continuous communication between the Client page and the Service page,
+          which is "hidden", i.e. it has no UI. The Client page creates a messaging channel and sends the messaging channel port to the Service page trhrough the intent invocation.
+          A high level "TV control" protocol, supporting commands such as "play", "pause" and "stop, runs on top of the messaging channel. 
+        </p>
+        <p>
+          In this example the assumption is that he Client invokes an intent to discover a Service that supports a specified protocol running on top of the message channel So the 
+          "discover" intent Action is used and Type is set to the specific protocol used to communicate with the Service.
+        </p>
+        
+        <div class="issue"><div class="issue-title"><span>Issue 1</span></div><p class="">
+          This scenario assumes the possibility to have hidden/background Service pages or Service pages that are visible inline the Client page.
+          Currently [<cite><a class="bibref" href="#bib-WEBINTENTS">WEBINTENTS</a></cite>] does not allow this but <abbr title="World Wide Web Consortium">W3C</abbr> DAP Action http://www.w3.org/2009/dap/track/actions/519 should add a proposal for a hidden disposition. 
+        </p></div>   
+        
+        <p><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><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><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><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 id="example-of-web-intents-document">
+        <h3><span class="secno">A.3 </span>Example of Web Intents document</h3>
+      
+        <p><img src="Example1_registration_page/Slide1.png" alt="Example1 registration page" width="280" height="280"><br>
+         (<a href="Example1_registration_page/Slide1.png">View as PNG</a>)
+        </p>      
+      </section>      
+    
+      <section id="example-of-upnp-device-description-document">
+        <h3><span class="secno">A.4 </span>Example of UPnP Device description document</h3>
+        <p><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" id="acknowledgements">
+      <!--OddPage--><h2><span class="secno">B. </span>Acknowledgements</h2>
+        <p>         
+          Many thanks to Sony colleagues Anders Isberg, Naoyuki Sato, Tatsuya Igarashi, Anders Edenbrandt and Bjrn 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>
+  
+<section id="references" class="appendix"><!--OddPage--><h2><span class="secno">C. </span>References</h2><section id="normative-references"><h3><span class="secno">C.1 </span>Normative references</h3><dl class="bibliography"><dt id="bib-DNS-SD">[DNS-SD]</dt><dd>S. Cheshire; M. Krochmal. <a href="http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt"><cite>DNS-Based Service Discovery.</cite></a> 27 February 2011. IETF Draft. URL: <a href="http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt">http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt</a>
+</dd><dt id="bib-IANA-SRVPORT-REG">[IANA-SRVPORT-REG]</dt><dd><a href="http://www.iana.org/form/ports-services">IANA Service Name and Transport Protocol Port Number Registry</a>. URL: <a href="http://www.iana.org/form/ports-services">http://www.iana.org/form/ports-services</a>
+</dd><dt id="bib-MDNS">[MDNS]</dt><dd>S. Cheshire; M. Krochmal. <a href="http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt"><cite>Multicast DNS.</cite></a> 14 February 2011. IETF Draft. URL: <a href="http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt">http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt</a>
+</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels.</cite></a> March 1997. Internet RFC 2119.  URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a> 
+</dd><dt id="bib-RFC3986">[RFC3986]</dt><dd>T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifier (URI): Generic Syntax.</cite></a> January 2005. Internet RFC 3986. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a> 
+</dd><dt id="bib-UPNP-DEVICEARCH">[UPNP-DEVICEARCH]</dt><dd><a href="http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20081015.pdf"><cite>UPnP Device Architecture 1.0</cite></a>. 15 October 2008. UPnP Forum. For UPnP Version 1.0. PDF document. URL: <a href="http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20081015.pdf">http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20081015.pdf</a>
+</dd><dt id="bib-WEBIDL">[WEBIDL]</dt><dd>Cameron McCormack. <a href="http://www.w3.org/TR/2011/WD-WebIDL-20110927/"><cite>Web IDL.</cite></a> 27 September 2011. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/2011/WD-WebIDL-20110927/">http://www.w3.org/TR/2011/WD-WebIDL-20110927/</a> 
+</dd><dt id="bib-WEBINTENTS">[WEBINTENTS]</dt><dd>Greg Billock; James Hawkins; Paul Kinlan. <a href="http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html"><cite>Web Intents.</cite></a> Editors' Draft. (Work in progress.) URL: <a href="http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html">http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html</a> 
+</dd></dl></section></section></body></html>
\ No newline at end of file
diff -r ffd0af37ad4e -r 2c38f7223615 wi-addendum-local-services/FPWD/FPWD_src.html
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/wi-addendum-local-services/FPWD/FPWD_src.html	Tue Sep 25 11:20:35 2012 +0200
@@ -0,0 +1,746 @@
+<!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:           "FPWD",
+          
+          // the specification's short name, as in http://www.w3.org/TR/short-name/
+          shortName:            "Web Intents-LD 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:  "2012-09-27",
+
+          // 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://w3c-test.org/dap/wi-addendum-local-services/",
+
+          // 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/" },
+              { name: "Norifumi Kikkawa",
+                company: "Sony Corporation", companyURL: "http://www.sony.net/"},
+          ],
+
+          // 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>
+
+    <style type="text/css">
+
+      /* Add addition spacing to <ol> and <ul> for rule definition */
+      ol.rule li, ul.rule li { padding:0.6em; }
+
+    </style>
+
+
+  </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 class="rule">
+         <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>
+         <li>The selected service executes 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 class="rule">
+         <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:
+      </p>   
+      <ul class="rule">
+        <li><dfn>UPnP enabled User Agent</dfn>: A <a>UPnP enabled User Agent</a> MUST support Web Intents [[!WEBINTENTS]] and the conformance criteria 
+        stated in this specification. </li>
+        <li><dfn>Web Intents enabled UPnP device</dfn>: A <a>Web Intents enabled UPnP device</a> MUST support [[!UPNP-DEVICEARCH]] and the conformance criteria 
+        stated in this specification. </li>
+        <li><dfn>mDNS enabled User Agent</dfn>: An <a>mDNS enabled User Agent</a> MUST support Web Intents [[!WEBINTENTS]] and the conformance criteria 
+        stated in this specification. </li>
+        <li><dfn>Web Intents enabled mDNS device</dfn>: A <a>Web Intents enabled mDNS device</a> MUST support [[!DNS-SD]], [[!MDNS]] and the conformance criteria 
+        stated in this specification. </li>
+      </ul>
+     
+      <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:
+        </p>
+          
+        <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>
+          <dt>IANA Service Name and Transport Protocol Port Number Registry</dt>
+          <dd>This addendum specification adds new entry on it, [[!IANA-SRVPORT-REG]]. </dd>
+          <dt>DNS-SD</dt>
+          <dd>This addendum specification is dependent on it, [[!DNS-SD]]. </dd>
+          <dt>mDNS</dt>
+          <dd>This addendum specification is dependent on it, [[!MDNS]]. </dd>
+        </dl>
+          
+           
+      </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 <a>UPnP enabled User Agent</a> has the role of a <dfn id="dfn-control-point">control point</dfn>  according to UPnP terminology. 
+        </p>     
+        <p>
+          The <a>Web Intents enabled UPnP device</a> discovered by the <a>UPnP enabled User Agent</a> has the roles of <dfn id="dfn-device">device</dfn> according to UPnP terminology. 
+        </p>        
+      </section>
+      
+      <section> 
+        <h3>mDNS related terms</h3>
+        <p>
+          The <a>mDNS enabled User Agent</a> has the role of a <dfn id="dfn-DNS-client">DNS client</dfn> with capability of [[!DNS-SD]]. 
+        </p>
+        <p>
+          The <a>Web Intents enabled mDNS device</a> discovered by the <a>mDNS enabled User Agent</a> has the roles of <dfn id="dfn-service">service</dfn> according to [[!MDNS]] and [[!DNS-SD]]. 
+        </p>        
+      </section>     
+      
+
+    </section>
+    
+    <section>
+    
+      <h2>UPnP adaptation</h2> 
+      
+      <section>   
+      
+        <h3><a>Web Intents enabled UPnP device</a></h3> 
+        
+        <p>
+          The <a>Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> support this section.
+        </p>
+        
+        <section>    
+        
+          <h4>UPnP Web Intents serviceType</h4>
+          
+          <p>
+            The <a>Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> support one 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 <a>Web Intents enabled UPnP device</a> 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>boolean</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><img src="Example_device_and_service_description_pages/Slide2.png" alt="Service description page" 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 <a>Web Intents enabled UPnP device</a> <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 class="rule">
+            <li>
+              <code>location.webintents.org</code>: <em class="rfc2119" title="required">required</em>. States the location to the Web Intents document in the <a>Web Intents enabled UPnP device</a>. 
+              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 
+              comma. Commas included in action strings <em class="rfc2119" title="must">must</em> be percent-encoded as 
+              defined in [[!RFC3986]], section-2.1.
+              <br />
+              This header allows the <a>UPnP enabled User Agent</a> to filter received SSDP messages so that the <a>UPnP enabled User Agent</a> only has to 
+              retrieve Web Intents documents for matching Web Intents Actions.        
+            </li>
+          </ul>         
+
+        </section>   
+        
+        <section>    
+        
+          <h4>Web Intents document</h4>   
+
+          <p>
+            The <a>Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> host Web Intents documents for the Web Intents Services the <a>Web Intents enabled UPnP device</a> 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 <a>Web Intents enabled UPnP device</a> <em class="rfc2119" title="must">must</em> host 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><a>UPnP enabled User Agent</a></h3> 
+        
+        <p>
+          The <a>UPnP enabled User Agent</a> <em class="rfc2119" title="must">must</em> support discovery of <a>Web Intents enabled UPnP device</a>s 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 <a>UPnP enabled User Agent</a> 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>
+              
+              <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 <a>UPnP enabled User Agent</a> attempts to retrieve the Web Intents document from the discovered <a>Web Intents enabled UPnP device</a>.              
+                 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 <a>UPnP enabled User Agent</a> 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 <a>UPnP enabled User Agent</a> fails to retrieve the Web Intents document it silently disregards the received M-SEARCH response.
+                 <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 <a>UPnP enabled User Agent</a> silently disregards the the received M-SEARCH response.
+              </li>
+       
+              <li>
+                 It is expected that the Web Intents document contains registration markup and the <a>UPnP enabled User Agent</a> interprets this
+                 registration markup according to the rules for registration defined by [[!WEBINTENTS]] and register the Services accordingly.           
+              </li>
+         
+              <li>
+                 The <a>UPnP enabled User Agent</a> makes each dynamically registered Service, that matches the Action of the invoked intent, available for selection 
+                 by the user, typically by making them visible and selectable in a Web Intents Service picker.                          
+              </li>
+         
+              <li>
+                 Based on user selection of a dynamically registered Service the <a>UPnP enabled User Agent</a> 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 <a>UPnP enabled User Agent</a> <em class="rfc2119" title="may">may</em> continuously listen to and act on advertisments according to the following steps:
+            </p>   
+            <ol class="rule">   
+          
+              <li>
+                The <a>UPnP enabled User Agent</a> maintains a list of announced UPnP services based on received SSDP NOTIFY messages
+                with <code>NT</code> header equal to <code>urn:schemas-webintents-org:service:WebIntents:1</code>.
+              </li>
+              
+              <li>
+                When the navigator.startActivity method [[!WEBINTENTS]] is called the <a>UPnP enabled User Agent</a> checks the list
+                of of announced services and attempts to retrieve the Web Intents document from the discovered <a>Web Intents enabled UPnP device</a> in the following cases:                
+                <ul>
+                  <li>
+                    The received NOTIFY message contains an <code>action.webintents.org</code> header and this header matches the Action of the invoked intent.
+                  </li>
+                  <li>
+                    The received NOTIFY message does not contain an <code>action.webintents.org</code> header.
+                  </li>                
+                </ul>
+                <br />     
+                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 <a>UPnP enabled User Agent</a> fails to retrieve the Web Intents document it silently disregards the received NOTIFY message.
+                <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 <a>UPnP enabled User Agent</a> silently disregards the received NOTIFY message.
+              </li>
+                       
+              <li>
+                 It is expected that the Web Intents document contains registration markup and the <a>UPnP enabled User Agent</a> interprets the
+                 Web Intents document according to the rules for registration defined by [[!WEBINTENTS]] and register the Services accordingly.                         
+              </li>
+                        
+              <li>
+                 The <a>UPnP enabled User Agent</a> makes each dynamically registered Service, that matches the Action of the invoked intent, available for selection 
+                 by the user, typically by making them visible and selectable in a Web Intents Service picker.                          
+              </li>
+                       
+              <li>
+                 Based on user selection of a dynamically registered Service the <a>UPnP enabled User Agent</a> 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>Support for Web Intents and UPnP</h4>
+            <p>
+              In addition to the normative statements defined in this specification a <a>UPnP enabled User Agent</a> that complies to this specification 
+              supports Web Intents according to [[!WEBINTENTS]] and UPnP Discovery, Description and Control according to [[!UPNP-DEVICEARCH]]. 
+              However, it is implementation dependent whether this is supported natively in the User Agent or supported through some external component, 
+              e.g. an in-device web server. 
+            </p>         
+          </section>           
+          
+          <section class='informative'>
+      
+            <h4>Service availability management</h4>
+
+            <p>
+             The <a>UPnP enabled User Agent</a> should manage the availability of UPnP services. For example detect when contact with a <a>Web Intents enabled UPnP device</a> 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 should be considered and long lasting "keep alive" sessions" should be avoided.           
+            </p>        
+        
+          </section>
+
+      </section>        
+      
+   
+      
+    </section>   
+    
+    <section>
+    
+      <h2>mDNS (DNS-SD) adaptation</h2> 
+      
+      <p>
+        This section describes how the User Agent handles Web Intents Services provided by local devices supporting mDNS and DNS-SD.          
+      </p>
+
+      <section>   
+      
+        <h3>Web Intents enabled mDNS device</h3> 
+        
+        <p>
+          The <a>Web Intents enabled mDNS device</a> <em class="rfc2119" title="must">must</em> support this section.
+        </p>
+        
+        <section>    
+        
+          <h4>Web Intents service type for DNS-SD</h4>     
+          
+          <p>
+            The <a>Web Intents enabled mDNS device</a> <em class="rfc2119" title="must">must</em> support [[!DNS-SD]] with a SRV record of the <code>webintents</code> service type. 
+          </p>  
+          
+            <p class="note">
+              A service type <code>webintents</code> should be registered in [[!IANA-SRVPORT-REG]].
+            </p>
+
+          <p>          
+            The TXT record for the <code>webintents</code> service must have following parameters:           
+          </p>          
+          <ul class="rule">
+            <li>
+              <code>location</code>: <em class="rfc2119" title="required">required</em>. States the location to the Web Intents document in the <a>Web Intents enabled mDNS device</a>. 
+              The value of this header is path to be concatenated with a host of the <a>Web Intents enabled mDNS device</a> to determine the location. The definition of the Web Intents document is the same as for UPnP.
+            </li>
+            <li>
+              <code>action</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 
+              comma. Commas included in action strings <em class="rfc2119" title="must">must</em> be percent-encoded as 
+              defined in [[!RFC3986]], section-2.1.
+              <br>
+              This allows the <a>mDNS enabled User Agent</a> to filter received mDNS messages so that the <a>mDNS enabled User Agent</a> only has to 
+              retrieve Web Intents documents for matching Web Intents Actions.        
+            </li>
+          </ul>         
+
+        </section>   
+        
+      </section>   
+      <section>    
+        <h3>mDNS enabled User Agent</h3> 
+
+        <p>
+          The <a>mDNS enabled User Agent</a> <em class="rfc2119" title="must">must</em> support discovery of <a>Web Intents enabled mDNS device</a>s through mDNS and DNS-SD 
+          according to [[!MDNS]], [[!DNS-SD]] and according to the Web Intents specific DNS records defined in this specification, section 5.1. 
+        </p>
+        
+        <section class='informative'>
+          <h4>Dynamic Service registration</h4>   
+          <p>
+            When the navigator.startActivity method [[!WEBINTENTS]] is called, the <a>mDNS enabled User Agent</a> typically runs the following steps:
+          </p>
+            
+          <ol class="rule">          
+            <li>
+               Send a multicast PTR query of the <code>_webintents._tcp.local</code> in the format specified by [[!MDNS]] and [[!DNS-SD]].
+               <br />
+            </li>
+
+            <li>
+               For each response, send a unicast TXT query of the webintents service instance in the PTR answer.
+               <br />
+               <p>This step can be omitted in case that the <a>Web Intents enabled mDNS device</a> attaches a TXT answer with the previous answer.
+            </li>
+
+            <li>
+               For each matching response, i.e. the response TXT record does not have an action parameter or does have an <code>action</code> parameter matching the Action of the invoked intent,
+               send a unicast request with a SRV query of the webintens service instance.
+               <br />
+               <p>This step can be omitted in case that the <a>Web Intents enabled mDNS device</a> attaches a SRV answer with the previous answer.
+            </li>
+
+            <li>
+               For each response, send a unicast A and/or AAAA query of the host name in the SRV answer.
+               <br />
+               <p>This step can be omitted in case that the <a>Web Intents enabled mDNS device</a> attaches an A and/or AAAA answer with the previous answer.
+            </li>
+
+            <li>
+               The <a>mDNS enabled User Agent</a> attempts to retrieve the Web Intents document from the discovered <a>Web Intents enabled mDNS device</a>.
+               The destination URL consists of an IP address in the A or AAAA answer, a port number in the SRV record and an absolute path in the <code>location</code> parameter of the TXT record.  
+               <br />  <br />
+               If the <a>mDNS enabled User Agent</a> fails to retrieve the Web Intents document it silently disregards the received response.
+               <br />  <br />
+               If the <code>action</code> parameter is present and does not match the <code>action</code> attributes of the Services registered in the retrieved Web Intents 
+               document the <a>mDNS enabled User Agent</a> silently disregards the the received response.
+               <br />  <br />
+               Note that following steps are identical to those of UPnP described in 4.2.
+            </li>
+          
+            <li>
+               It is expected that the Web Intents document contains registration markup and the <a>mDNS enabled User Agent</a> interprets this
+               registration markup according to the rules for registration defined by [[!WEBINTENTS]] and register the Services accordingly.           
+            </li>
+          
+            <li>
+               The <a>mDNS enabled User Agent</a> makes each dynamically registered Service, that matches the Action of the invoked intent, available for selection 
+               by the user, typically by making them visible and selectable in a Web Intents Service picker.                          
+            </li>
+          
+            <li>
+               Based on user selection of a dynamically registered Service the <a>mDNS enabled User Agent</a> 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>    
+      <section class="informative">
+        <h3>Sample Records</h3> 
+        
+        <p>
+          See below for the example records for Web Intents. An <a>mDNS enabled User Agent</a> looking for devices supporting http://webintents.org/view Web Intents can understand that 
+          it is possible to get a Web Intents document for "LivingRoomTV" at http://192.168.1.47:3619/webintents.html.
+        </p>
+
+        <ul class="rule">
+          <li>
+            <code>_webintents._tcp.local. 120 IN PTR LivingRoomTV._webintents._tcp.local.</code>: A LivingRoomTV instance serves webintents service.
+          </li>
+          <li>
+            <code>LivingRoomTV._webintents._tcp.local. 120 IN SRV 0 0 3619 TV40EX-W2000.local.</code>: A host "TV40EX-W2000" in the link local network offers the LivingRoomTV webintents service instance in its port 3619.
+          </li>
+          <li>
+            <code>LivingRoomTV._webintents._tcp.local. 120 IN TXT location=/webintents.html action=http://webintents.org/view</code>: It offers http://webintents.org/view type of Web Intents. The absolute path for its Web Intents document is "/webintents.html". Note that the actual binary format of the TXT record value is concatinating key-value pairs each of which is a single byte length followed by 0-255 length key=value character string as defined in [DNS-SD].
+          </li>
+          <li>
+            <code>TV40EX-W2000 120 IN A 192.168.1.47</code>: A host "TV40EX-W2000" is on 192.168.1.47.
+          </li>
+        </ul>
+
+      </section>   
+                 
+    </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 class="rule">
+        <li>
+          A Client application invoking a "View" intent provides, as intent payload data, a link to a video to be displayed at the remote <a>Web Intents enabled UPnP device</a>.
+          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><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><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><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. This means that there is a need for continuous communication between the Client page and the Service page,
+          which is "hidden", i.e. it has no UI. The Client page creates a messaging channel and sends the messaging channel port to the Service page trhrough the intent invocation.
+          A high level "TV control" protocol, supporting commands such as "play", "pause" and "stop, runs on top of the messaging channel. 
+        </p>
+        <p>
+          In this example the assumption is that he Client invokes an intent to discover a Service that supports a specified protocol running on top of the message channel So the 
+          "discover" intent Action is used and Type is set to the specific protocol used to communicate with the Service.
+        </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><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><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><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><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><img src="Example1_registration_page/Slide1.png" alt="Example1 registration page" width="280" height="280" ><br>
+         (<a href="Example1_registration_page/Slide1.png">View as PNG</a>)
+        </p>      
+      </section>      
+    
+      <section>
+        <h3>Example of UPnP Device description document</h3>
+        <p><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 colleagues Anders Isberg, Naoyuki Sato, Tatsuya Igarashi, 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
Received on Tuesday, 25 September 2012 09:23:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 25 September 2012 09:23:16 GMT