Re: Local Discovery addendum update for mDNS

Ack, I have never seen /.well-known/ used by anything.  It always seemed a
lot easier to just drop a file of web.intents at the root.  Which was
something that we actively tried to stay away from in the first set of
drafts, especially when deploying files for some organisations is very very
hard.

I suppose the point about DNS is that the service on the other end doesn't
have to be a service that supports the HTTP interface discovery.  Not sure
of the types of services that would be suited for DNS discovery but it
makes sense to document it on the wiki.

P


On Mon, Jul 30, 2012 at 4:24 PM, Greg Billock <gbillock@google.com> wrote:

> A solution for this that wouldn't require DNS chops is to use a
> resource within /.well-known/ [1]
>
>
> [1] http://tools.ietf.org/html/rfc5785
>
> On Mon, Jul 30, 2012 at 6:16 AM, 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>
> 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> 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' (by setting the mDNS search domain to
> >>> '.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
> > LinkedIn: http://uk.linkedin.com/in/paulkinlan
> > Blog: http://paul.kinlan.me
> > Skype: paul.kinlan
> >
>



-- 
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