Bug 314999 - [Discovery][DNS-SD] Implement IDiscoveryAdvertiser
Summary: [Discovery][DNS-SD] Implement IDiscoveryAdvertiser
Status: RESOLVED FIXED
Alias: None
Product: ECF
Classification: RT
Component: ecf.providers (show other bugs)
Version: 3.3.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 3.4.0   Edit
Assignee: Markus Kuppe CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 321959 321960 321963 316106 317798 318074 320188
Blocks: 310580
  Show dependency tree
 
Reported: 2010-05-30 07:15 EDT by Markus Kuppe CLA
Modified: 2010-08-06 05:23 EDT (History)
0 users

See Also:


Attachments
First we steps of implementing the IDiscoveryAdvertiser (8.67 KB, patch)
2010-06-07 09:00 EDT, Markus Kuppe CLA
no flags Details | Diff
mylyn/context/zip (7.07 KB, application/octet-stream)
2010-06-25 10:58 EDT, Markus Kuppe CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Kuppe CLA 2010-05-30 07:15:42 EDT
IDiscoveryAdvertiser should be implemented based on DDNS [0][1]. This update mechanism is used by bind, the most commonly used DNS server.


[0] http://en.wikipedia.org/wiki/Dynamic_DNS
[1] http://tools.ietf.org/html/rfc2136
Comment 2 Markus Kuppe CLA 2010-06-07 09:00:33 EDT
Created attachment 171258 [details]
First we steps of implementing the IDiscoveryAdvertiser
Comment 3 Markus Kuppe CLA 2010-06-07 09:18:40 EDT
Expires 8th September 2010         Cheshire & Krochmal         [Page 25]
Internet Draft         DNS-Based Service Discovery        8th March 2010

"10. Populating the DNS with Information

   How a service's PTR, SRV and TXT records make their way into the DNS
   is outside the scope of this document. It can happen in a number of
   ways, for example:

   On some networks, the administrator might manually enter the records
   into the name server's configuration file.

   A network monitoring tool could output a standard zone file to be
   read into a conventional DNS server. For example, a tool that can
   find networked PostScript laser printers using AppleTalk NBP, could
   find the list of printers, communicate with each one to find its IP
   address, PostScript version, installed options, etc., and then write
   out a DNS zone file describing those printers and their capabilities
   using DNS resource records. That information would then be available
   to DNS-SD clients that don't implement AppleTalk NBP, and don't want
   to.

   IP printers could use Dynamic DNS Update [RFC 2136] to automatically
   register their own PTR, SRV and TXT records with the DNS server.

   A printer manager device which has knowledge of printers on the
   network through some other management protocol could also use Dynamic
   DNS Update [RFC 2136].

   Alternatively, a printer manager device could implement enough of
   the DNS protocol that it is able to answer DNS queries directly,
   and Example Co.'s main DNS server could delegate the
   _ipp._tcp.example.com subdomain to the printer manager device.

   Zeroconf printers answer Multicast DNS queries on the local link
   for appropriate PTR, SRV and TXT names ending with ".local." [mDNS]
"

http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt
Comment 4 Markus Kuppe CLA 2010-06-25 10:58:47 EDT
Pushed WIP to HEAD
Comment 5 Markus Kuppe CLA 2010-06-25 10:58:49 EDT
Created attachment 172763 [details]
mylyn/context/zip
Comment 6 Markus Kuppe CLA 2010-08-06 04:53:05 EDT
Umbrella bug, marking as fixed as all subtasks are done