Re: Local Discovery addendum update for mDNS

Hi Paul,

Agree. Though it's true that the DNS-SD might work in the public
Internet by definition, actual deployment for that seems quite difficult.
My assumption is Zeroconf, DNS-SD with mDNS in local network as stated
in 2.1 of the addendum. 

>  *   UPnP- home and local discovery
>  *   mDNS etc - web discovery, centrally managed by owner
>  *   intent tag (or other) - web discovery, developer experience/ease of starting

By the way, I have slghtly different view for above.
To me, UPnP and mDNS/DNS-SD are in the same scope - dynamic local
discovery.

Either may be implemented in a device supporting WebIntents.
Typically a UPnP device for example Sony TV will support the UPnP defintion
for WebIntents in the addendum and a Zeroconf device will use mDNS
definition for WebIntents. But this is implementation matter. A UPnP TV
could advertise its Web Intents by mDNS.

The intent tag definition itself is common for all scope I believe.
The addendum defines how to find the tag in local network dynamically.

Regards,
Kikkawa

On Mon, 30 Jul 2012 22:16:21 +0900
Paul Kinlan <paulkinlan@google.com> wrote:

> I quite like the idea a lot of web developers are used to managing DNS for verification of ownership of Google Apps accounts and Web Master tools (you encode a TXT record with the information).  That being said, it can be a little be daunting, problems with propegations and a nightmare to configure depending on provider.
> 
> Another point, I have spoken to several large retail companies in the past and changing DNS is a larger task from an Operations PoV than changing a template for a page (and in a lot of cases deploying a new file is pretty hard - too much work) etc.
> 
> Would the suggested Scope be:
> 
>  *   UPnP- home and local discovery
>  *   mDNS etc - web discovery, centrally managed by owner
>  *   intent tag (or other) - web discovery, developer experience/ease of starting
> 
> P
> 
> 
> 
> On Mon, Jul 30, 2012 at 4:41 AM, James Hawkins <jhawkins@google.com<mailto:jhawkins@google.com>> wrote:
> This seems like an interesting idea, especially as a supplement to the existing registration mechanism(s).  My initial thought is that this seems a bit daunting for the average web developer, but I suppose it's not geared at that crowd.
> 
> My second thought is that it may add unnecessary complexity to the API.  We should definitely attempt to figure out how open folks are to investing in the cost necessary to support this registration, as it moves outside of the realm of the abilities of Joe WebDev.
> 
> Thanks,
> James
> 
> 
> On Fri, Jul 27, 2012 at 7:32 AM, Rich Tibbett <richt@opera.com<mailto:richt@opera.com>> wrote:
> Norifumi Kikkawa wrote:
> Claes and I updated the addendum to support mDNS.
> 
> http://w3c-test.org/dap/wi-addendum-local-services/
> 
> The basic idea is same as that for UPnP. The discovery protocol is used
> to obtain the location of the WebIntents page.
> 
> I haven't gone through the proposal in detail just yet but my understanding at this point is that it essentially provides a way to bootstrap the registration of standard Web Intents Providers via common discovery protocols (mDNS/DNS-SD and SSDP).
> 
> As I mentioned at the F2F a couple of weeks ago I think that there is a big opportunity here to re-use the mDNS/DNS-SD parts of this spec to be able to bootstrap the registration of Web Intents providers from wide-area networks i.e. the web.
> 
> The UA (though probably not individual web pages) could query the root DNS record of e.g. 'google.com<http://google.com>' (by setting the mDNS search domain to '.google.com<http://google.com>') and then register any and all web intent services that are included therein automatically in the UA.
> 
> It means that as a user navigates different domains on the web the UA itself could simultaneously and orthogonally make a query for Web Intent service records included in that domain's root DNS record (according to the format defined in this spec) and register those Web Intents in the UA for future invocation by any web pages.
> 
> It would be an alternative (bootstrap) mechanism for registering web intent providers and it could be complimentary to both the programmatic and declarative way to register Web Intents that we have now. In some ways it may be even cleaner than the other registration methods since there is only ever one single authorative record of the Web Intents that any given domain provides (in the domain's root DNS record). That avoids the issue of different web pages on the same domain potentially contradicting each other wrt the Web Intent Providers available on the domain.
> 
> I'm wondering if it's worth discussing this further here, if you have had any thoughts in this general direction and if it's something we might want to cover in this specification or elsewhere.
> 
> Would be good to get input on having this type of bootstrap registration process for Web Intents.
> 
> br/ Rich
> 
> 
> 
> 
> 
> --
> Paul Kinlan
> Developer Advocate @ Google for Chrome and HTML5
> Watch my I/O talk: http://www.youtube.com/watch?v=O1YjdKh-rPg
> G+: http://plus.ly/paul.kinlan
> t: +447730517944
> tw: @Paul_Kinlan<http://twitter.com/paul_kinlan>
> LinkedIn: http://uk.linkedin.com/in/paulkinlan
> Blog: http://paul.kinlan.me
> Skype: paul.kinlan
> 

---------------------------------------------
 Norifumi Kikkawa <Norifumi.Kikkawa@jp.sony.com>
  Section 1
  Network Technology Dept.
  Information Technology Development Division
  System & Software Technology Platfotm 
  Sony Corporation
 (TEL) +81 50 3750 3953 
-----------------------------------------------

Received on Tuesday, 31 July 2012 02:34:01 UTC