Subject: [mdnsext] draft-cheshire-mdnsext-hybrid-01

From: Stuart Cheshire <[email-masked]>
Date: Sat, 26 Jan 2013 22:46:23 -0800

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