Stuart submitted a update to his draft already... -Neil
-- Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-john...@uiowa.edu On 1/27/13 12:46 AM, "Stuart Cheshire" <chesh...@apple.com> wrote: >In private discussions about draft-cheshire-mdnsext-hybrid-00, it is >evident that the document is not clear about which parts of the proposal >already exist, and which are new. Accordingly, I have submitted an update >which adds this section: > ><http://www.ietf.org/id/draft-cheshire-mdnsext-hybrid-01.txt> > >4. Implementation Status > > Some aspects of the mechanism specified in this document already > exist in deployed software. Some aspects are new. This section > outlines which aspects already exist and which are new. > >4.1. Already Implemented and Deployed > > Domain enumeration discovery by the client (the "b._dns-sd._udp" > queries) is already implemented and deployed. > > Unicast queries to the indicated discovery domain is already > implemented and deployed. > > These are implemented and deployed in Mac OS X 10.4 and later > (including all versions of Apple iOS, on all iPhone and iPads) in > Bonjour for Windows, and in Android 4.1 "Jelly Bean" (API Level 16) > and later. > > Domain enumeration discovery and unicast querying have been used for > several years at IETF meetings to make Terminal Room printers > discoverable from outside the Terminal room. When you Press Cmd-P on > your Mac, or select AirPrint on your iPad or iPhone, and the Terminal > room printers appear, that is because your client is doing unicast > DNS queries to the IETF DNS servers. > >4.2. Partially Implemented > > The current APIs make multiple domains visible to client software, > but most client UI today lumps all discovered services into a single > flat list. This is largely a chicken-and-egg problem. Application > writers were naturally reluctant to spend time writing domain-aware > UI code when few customers today would benefit from it. If Hybrid > Proxy deployment becomes common, then application writers will have a > reason to provide better UI. Existing applications will work with > the Hybrid Proxy, but will show all services in a single flat list. > Applications with improved UI will group services by domain. > > The Long-Lived Query mechanism [I-D.sekar-dns-llq] referred to in > this specification exists and is deployed, but has not been > standardized by the IETF. It is possible that the IETF may choose to > standardize a different or better Long-Lived Query mechanism. In > that case, the pragmatic deployment approach would be for vendors to > produce Hybrid Proxies that implement both the deployed Long-Lived > Query mechanism [I-D.sekar-dns-llq] (for today's clients) and a new > IETF Standard Long-Lived Query mechanism (as the future long-term > direction). > >4.3. Not Yet Implemented > > The translating/filtering Hybrid Proxy specified in this document. > Once implemented, such a Hybrid Proxy will immediately make wide-area > discovery available with today's existing clients and devices. > > A mechanism to 'stitch' together multiple ".local." zones so that > they appear as one. Such a mechanism will be specified in a future > companion document. > >Stuart Cheshire > >_______________________________________________ >mdnsext mailing list >mdns...@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
