implement DBUS protocol

git-svn-id: file:///home/lennart/svn/public/avahi/trunk@171 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe

1 files changed, 1798 insertions, 0 deletions

diff --git a/specs/draft-cheshire-dnsext-dns-sd-02.txt b/specs/draft-cheshire-dnsext-dns-sd-02.txt
new file mode 100644
index 0000000..bebc28d
--- /dev/null
+++ b/specs/draft-cheshire-dnsext-dns-sd-02.txt
@@ -0,0 +1,1798 @@
+Document: draft-cheshire-dnsext-dns-sd-02.txt            Stuart Cheshire
+Category: Standards Track                           Apple Computer, Inc.
+Expires 14th August 2004                                   Marc Krochmal
+                                                    Apple Computer, Inc.
+                                                      14th February 2004
+
+                      DNS-Based Service Discovery
+
+                 <draft-cheshire-dnsext-dns-sd-02.txt>
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.  Internet-Drafts are
+   working documents of the Internet Engineering Task Force (IETF),
+   its areas, and its working groups.  Note that other groups may
+   also distribute working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six
+   months and may be updated, replaced, or obsoleted by other documents
+   at any time.  It is inappropriate to use Internet-Drafts as
+   reference material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+   Distribution of this memo is unlimited.
+
+
+Abstract
+
+   This document describes a convention for naming and structuring DNS
+   resource records. Given a type of service that a client is looking
+   for, and a domain in which the client is looking for that service,
+   this convention allows clients to discover a list of named instances
+   of that desired service, using only standard DNS queries. In short,
+   this is referred to as DNS-based Service Discovery, or DNS-SD.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal          [Page 1]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+Table of Contents
+
+   1.  Introduction....................................................3
+   2.  Conventions and Terminology Used in this Document...............3
+   3.  Design Goals....................................................4
+   4.  Service Instance Enumeration....................................5
+   4.1 Structured Instance Names.......................................5
+   4.2 User Interface Presentation.....................................7
+   4.3 Internal Handling of Names......................................7
+   4.4 What You See Is What You Get....................................7
+   4.5 Ordering of Service Instance Name Components....................9
+   5.  Service Name Resolution........................................11
+   6.  Data Syntax for DNS-SD TXT Records.............................12
+   6.1 General Format Rules for DNS TXT Records.......................12
+   6.2 DNS TXT Record Format Rules for use in DNS-SD..................12
+   6.3 DNS-SD TXT Record Size.........................................14
+   6.4 Rules for Names in DNS-SD Name/Value Pairs.....................14
+   6.5 Rules for Values in DNS-SD Name/Value Pairs....................16
+   6.6 Example TXT Record.............................................16
+   6.7 Version Tag....................................................17
+   7.  Application Protocol Names.....................................18
+   8.  Selective Instance Enumeration.................................19
+   9.  Flagship Naming................................................10
+   10. Service Type Enumeration.......................................21
+   11. Populating the DNS with Information............................22
+   12. Relationship to Multicast DNS..................................22
+   13. Discovery of Browsing and Registration Domains.................23
+   14. DNS Additional Record Generation...............................24
+   15. Comparison with Alternative Service Discovery Protocols........25
+   16. Real Example...................................................27
+   17. IPv6 Considerations............................................28
+   18. Security Considerations........................................28
+   19. IANA Considerations............................................28
+   20. Acknowledgements...............................................29
+   21. Copyright......................................................29
+   22. Normative References...........................................30
+   23. Informative References.........................................30
+   24. Author's Addresses.............................................31
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal          [Page 2]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+1. Introduction
+
+   This document describes a convention for naming and structuring DNS
+   resource records. Given a type of service that a client is looking
+   for, and a domain in which the client is looking for that service,
+   this convention allows clients to discover a list of named instances
+   of a that desired service, using only standard DNS queries. In short,
+   this is referred to as DNS-based Service Discovery, or DNS-SD.
+
+   This document proposes no change to the structure of DNS messages,
+   and no new operation codes, response codes, resource record types,
+   or any other new DNS protocol values. This document simply proposes
+   a convention for how existing resource record types can be named and
+   structured to facilitate service discovery.
+
+   This proposal is entirely compatible with today's existing unicast
+   DNS server and client software.
+
+   Note that the DNS-SD service does NOT have to be provided by the same
+   DNS server hardware that is currently providing an organization's
+   conventional host name lookup service (the service we traditionally
+   think of when we say "DNS"). By delegating the "_tcp" subdomain, all
+   the workload related to DNS-SD can be offloaded to a different
+   machine. This flexibility, to handle DNS-SD on the main DNS server,
+   or not, at the network administrator's discretion, is one of the
+   things that makes DNS-SD so compelling.
+
+   Even when the DNS-SD functions are delegated to a different machine,
+   the benefits of using DNS remain: It is mature technology, well
+   understood, with multiple independent implementations from different
+   vendors, a wide selection of books published on the subject, and an
+   established workforce experienced in its operation. In contrast,
+   adopting some other service discovery technology would require every
+   site in the world to install, learn, configure, operate and maintain
+   some entirely new and unfamiliar server software. Faced with these
+   obstacles, it seems unlikely that any other service discovery
+   technology could hope to compete with the ubiquitous deployment
+   that DNS already enjoys.
+
+   This proposal is also compatible with (but not dependent on) the
+   proposal outlined in "Multicast DNS" [mDNS].
+
+
+2. Conventions and Terminology Used in this Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in "Key words for use in
+   RFCs to Indicate Requirement Levels" [RFC 2119].
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal          [Page 3]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+3. Design Goals
+
+   A good service discovery protocol needs to have many properties,
+   three of which are mentioned below:
+
+   (i) The ability to query for services of a certain type in a certain
+   logical domain and receive in response a list of named instances
+   (network browsing, or "Service Instance Enumeration").
+
+   (ii) Given a particular named instance, the ability to efficiently
+   resolve that instance name to the required information a client needs
+   to actually use the service, i.e. IP address and port number, at the
+   very least (Service Name Resolution).
+
+   (iii) Instance names should be relatively persistent. If a user
+   selects their default printer from a list of available choices today,
+   then tomorrow they should still be able to print on that printer --
+   even if the IP address and/or port number where the service resides
+   have changed -- without the user (or their software) having to repeat
+   the network browsing step a second time.
+
+   In addition, if it is to become successful, a service discovery
+   protocol should be so simple to implement that virtually any
+   device capable of implementing IP should not have any trouble
+   implementing the service discovery software as well.
+
+   These goals are discussed in more detail in the remainder of this
+   document. A more thorough treatment of service discovery requirements
+   may be found in "Requirements for a Protocol to Replace AppleTalk
+   NBP" [NBP]. That document draws upon examples from two decades of
+   operational experience with AppleTalk Name Binding Protocol to
+   develop a list of universal requirements which are broadly applicable
+   to any potential service discovery protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal          [Page 4]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+4. Service Instance Enumeration
+
+   DNS SRV records [RFC 2782] are useful for locating instances of a
+   particular type of service when all the instances are effectively
+   indistinguishable and provide the same service to the client.
+
+   For example, SRV records with the (hypothetical) name
+   "_http._tcp.example.com." would allow a client to discover a list of
+   all servers implementing the "_http._tcp" service (i.e. Web servers)
+   for the "example.com." domain. The unstated assumption is that all
+   these servers offer an identical set of Web pages, and it doesn't
+   matter to the client which of the servers it uses, as long as it
+   selects one at random according to the weight and priority rules laid
+   out in RFC 2782.
+
+   Instances of other kinds of service are less easily interchangeable.
+   If a word processing application were to look up the (hypothetical)
+   SRV record "_ipp._tcp.example.com." to find the list of IPP printers
+   at Example Co., then picking one at random and printing on it would
+   probably not be what the user wanted.
+
+   The remainder of this section describes how SRV records may be used
+   in a slightly different way to allow a user to discover the names
+   of all available instances of a given type of service, in order to
+   select the particular instance the user desires.
+
+
+4.1 Structured Instance Names
+
+   This document borrows the logical service naming syntax and semantics
+   from DNS SRV records, but adds one level of indirection. Instead of
+   requesting records of type "SRV" with name "_ipp._tcp.example.com.",
+   the client requests records of type "PTR" (pointer from one name to
+   another in the DNS namespace).
+
+   In effect, if one thinks of the domain name "_ipp._tcp.example.com."
+   as being analogous to an absolute path to a directory in a file
+   system then the PTR lookup is akin to performing a listing of that
+   directory to find all the files it contains. (Remember that domain
+   names are expressed in reverse order compared to path names: An
+   absolute path name is read from left to right, beginning with a
+   leading slash on the left, and then the top level directory, then the
+   next level directory, and so on. A fully-qualified domain name is
+   read from right to left, beginning with the dot on the right -- the
+   root label -- and then the top level domain to the left of that, and
+   the second level domain to the left of that, and so on. If the fully-
+   qualified domain name "_ipp._tcp.example.com." were expressed as a
+   file system path name, it would be "/com/example/_tcp/_ipp".)
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal          [Page 5]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+   The result of this PTR lookup for the name "<Service>.<Domain>" is a
+   list of zero or more PTR records giving Service Instance Names of the
+   form:
+
+      Service Instance Name = <Instance> . <Service> . <Domain>
+
+   The <Instance> portion of the Service Instance Name is a single DNS
+   label, containing arbitrary UTF-8-encoded text [RFC 2279]. It is a
+   user-friendly name, meaning that it is allowed to contain any
+   characters, without restriction, including spaces, upper case, lower
+   case, punctuation -- including dots -- accented characters, non-roman
+   text, and anything else that may be represented using UTF-8.
+   DNS recommends guidelines for allowable characters for host names
+   [RFC 1033][RFC 1034][RFC 1035], but Service Instance Names are not
+   host names. Service Instance Names are not intended to ever be typed
+   in by a normal user; the user selects a Service Instance Name by
+   selecting it from a list of choices presented on the screen.
+
+   Note that just because this protocol supports arbitrary UTF-8-encoded
+   names doesn't mean that any particular user or administrator is
+   obliged to make use of that capability. Any user is free, if they
+   wish, to continue naming their services using only letters, digits
+   and hyphens, with no spaces, capital letters, or other punctuation.
+
+   DNS labels are currently limited to 63 octets in length. UTF-8
+   encoding can require up to four octets per Unicode character, which
+   means that in the worst case, the <Instance> portion of a name could
+   be limited to fifteen Unicode characters. However, the Unicode
+   characters with longer UTF-8 encodings tend to be the more obscure
+   ones, and tend to be the ones that convey greater meaning per
+   character.
+
+   Note that any character in the commonly-used 16-bit Unicode space can
+   be encoded with no more than three octets of UTF-8 encoding. This
+   means that an Instance name can contain up to 21 Kanji characters,
+   which is a sufficiently expressive name for most purposes.
+
+   The <Service> portion of the Service Instance Name consists of a pair
+   of DNS labels, following the established convention for SRV records
+   [RFC 2782], namely: the first label of the service pair is the
+   application protocol name, as recorded in the IANA list of assigned
+   application protocol names and port numbers [ports]. The second label
+   of the service pair is either "_tcp" or "_udp", depending on the
+   transport protocol used by the application.
+
+   The <Domain> portion of the Service Instance Name is a conventional
+   DNS domain name, consisting of as many labels as appropriate. For
+   example, "apple.com.", "cs.stanford.edu.", and "eng.us.ibm.com." are
+   all valid domain names for the <Domain> portion of the Service
+   Instance Name.
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal          [Page 6]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+4.2 User Interface Presentation
+
+   The names resulting from the PTR lookup are presented to the user in
+   a list for the user to select one (or more). Typically only the first
+   label is shown (the user-friendly <Instance> portion of the name). In
+   the common case, the <Service> and <Domain> are already known to the
+   user, these having been provided by the user in the first place, by
+   the act of indicating the service being sought, and the domain in
+   which to look for it. Note: The software handling the response
+   should be careful not to make invalid assumptions though, since it
+   *is* possible, though rare, for a service enumeration in one domain
+   to return the names of services in a different domain. Similarly,
+   when using subtypes (see "Selective Instance Enumeration") the
+   <Service> of the discovered instance my not be exactly the same as
+   the <Service> that was requested.
+
+   Having chosen the desired named instance, the Service Instance Name
+   may then be used immediately, or saved away in some persistent
+   user-preference data structure for future use, depending on what is
+   appropriate for the application in question.
+
+
+4.3 Internal Handling of Names
+
+   If the <Instance>, <Service> and <Domain> portions are internally
+   concatenated together into a single string, then care must be taken
+   with the <Instance> portion, since it is allowed to contain any
+   characters, including dots.
+
+   Any dots in the <Instance> portion should be escaped by preceeding
+   them with a backslash ("." becomes "\."). Likewise, any backslashes
+   in the <Instance> portion should also be escaped by preceeding them
+   with a backslash ("\" becomes "\\"). Having done this, the three
+   components of the name may be safely concatenated. The
+   backslash-escaping allows literal dots in the name (escaped) to be
+   distinguished from label-separator dots (not escaped).
+
+   The resulting concatenated string may be safely passed to standard
+   DNS APIs like res_query(), which will interpret the string correctly
+   provided it has been escaped correctly, as described here.
+
+
+4.4 What You See Is What You Get
+
+   Some service discovery protocols decouple the true service identifier
+   from the name presented to the user. The true service identifier used
+   by the protocol is an opaque unique id, often represented using a
+   long string of hexadecimal digits, and should never be seen by the
+   typical user. The name presented to the user is merely one of the
+   ephemeral attributes attached to this opaque identifier.
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal          [Page 7]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+   The problem with this approach is that it decouples user perception
+   from reality:
+
+   * What happens if there are two service instances, with different
+     unique ids, but they have inadvertently been given the same
+     user-visible name? If two instances appear in an on-screen list
+     with the same name, how does the user know which is which?
+
+   * Suppose a printer breaks down, and the user replaces it with
+     another printer of the same make and model, and configures the new
+     printer with the exact same name as the one being replaced:
+     "Stuart's Printer". Now, when the user tries to print, the
+     on-screen print dialog tells them that their selected default
+     printer is "Stuart's Printer". When they browse the network to see
+     what is there, they see a printer called "Stuart's Printer", yet
+     when the user tries to print, they are told that the printer
+     "Stuart's Printer" can't be found. The hidden internal unique id
+     that the software is trying to find on the network doesn't match
+     the hidden internal unique id of the new printer, even though its
+     apparent "name" and its logical purpose for being there are the
+     same. To remedy this, the user typically has to delete the print
+     queue they have created, and then create a new (apparently
+     identical) queue for the new printer, so that the new queue will
+     contain the right hidden internal unique id. Having all this hidden
+     information that the user can't see makes for a confusing and
+     frustrating user experience, and exposing long ugly hexadecimal
+     strings to the user and forcing them to understand what they mean
+     is even worse.
+
+   * Suppose an existing printer is moved to a new department, and given
+     a new name and a new function. Changing the user-visible name of
+     that piece of hardware doesn't change its hidden internal unique
+     id. Users who had previously created print queues for that printer
+     will still be accessing the same hardware by its unique id, even
+     though the logical service that used to be offered by that hardware
+     has ceased to exist.
+
+   To solve these problems requires the user or administrator to be
+   aware of the supposedly hidden unique id, and to set its value
+   correctly as hardware is moved around, repurposed, or replaced,
+   thereby contradicting the notion that it is a hidden identifier that
+   human users never need to deal with. Requiring the user to unserstand
+   this expert behind-the-scenes knowledge of what is *really* going on
+   is just one more burden placed on the user when they are trying to
+   diagnose why their computers and network devices are not working as
+   expected.
+
+   These anomalies and counter-intuitive behaviours can be eliminated by
+   maintaining a tight bidirectional one-to-one mapping between what the
+   user sees on the screen and what is really happening "behind the
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal          [Page 8]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+   curtain". If something is configured incorrectly, then that is
+   apparent in the familiar day-to-day user interface that everyone
+   understands, not in some little-known rarely-used "expert" interface.
+
+   In summary: The user-visible name is the primary identifier for a
+   service. If the user-visible name is changed, then conceptually the
+   service being offered is a different logical service -- even though
+   the hardware offering the service stayed the same. If the
+   user-visible name doesn't change, then conceptually the service being
+   offered is the same logical service -- even if the hardware offering
+   the service is new hardware brought in to replace some old equipment.
+
+   There are certainly arguments on both sides of this debate.
+   Nonetheless, the designers of any service discovery protocol have
+   to make a choice between between having the primary identifiers be
+   hidden, or having them be visible, and these are the reasons that we
+   chose to make them visible. We're not claiming that there are no
+   disadvantages of having primary identifiers be visible. We considered
+   both alternatives, and we believe that the few disadvantages
+   of visible identifiers are far outweighed by the many problems
+   caused by use of hidden identifiers.
+
+
+4.5 Ordering of Service Instance Name Components
+
+   There have been questions about why services are named using DNS
+   Service Instance Names of the form:
+
+      Service Instance Name = <Instance> . <Service> . <Domain>
+
+   instead of:
+
+      Service Instance Name = <Service> . <Instance> . <Domain>
+
+   There are three reasons why it is beneficial to name service
+   instances with the parent domain as the most-significant (rightmost)
+   part of the name, then the abstract service type as the nextmost
+   significant, and then the specific instance name as the
+   least-significant (leftmost) part of the name:
+
+
+4.5.1. Semantic Structure
+
+   The facility being provided by browsing ("Service Instance
+   Enumeration") is effectively enumerating the leaves of a tree
+   structure. A given domain offers zero or more services. For each of
+   those service types, there may be zero or more instances of that
+   service.
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal          [Page 9]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+   The user knows what type of service they are seeking. (If they are
+   running an FTP client, they are looking for FTP servers. If they have
+   a document to print, they are looking for entities that speak some
+   known printing protocol.) The user knows in which organizational or
+   geographical domain they wish to search. (The user does not want a
+   single flat list of every single printer on the planet, even if such
+   a thing were possible.) What the user does not know in advance is
+   whether the service they seek is offered in the given domain, or if
+   so, how many instances are offered, and the names of those instances.
+   Hence having the instance names be the leaves of the tree is
+   consistent with this semantic model.
+
+   Having the service types be the terminal leaves of the tree would
+   imply that the user knows the domain name, and already knows the
+   name of the service instance, but doesn't have any idea what the
+   service does. We would argue that this is a less useful model.
+
+
+4.5.2. Network Efficiency
+
+   When a DNS response contains multiple answers, name compression works
+   more effectively if all the names contain a common suffix. If many
+   answers in the packet have the same <Service> and <Domain>, then each
+   occurrence of a Service Instance Name can be expressed using only the
+   <Instance> part followed by a two-byte compression pointer
+   referencing a previous appearance of "<Service>.<Domain>". This
+   efficiency would not be possible if the <Service> component appeared
+   first in each name.
+
+
+4.5.3. Operational Flexibility
+
+   This name structure allows subdomains to be delegated along logical
+   service boundaries. For example, the network administrator at Example
+   Co. could choose to delegate the "_tcp.example.com." subdomain to a
+   different machine, so that the machine handling service discovery
+   doesn't have to be the same as the machine handling other day-to-day
+   DNS operations. (It *can* be the same machine if the administrator so
+   chooses, but the point is that the administrator is free to make that
+   choice.) Furthermore, if the network administrator wishes to delegate
+   all information related to IPP printers to a machine dedicated to
+   that specific task, this is easily done by delegating the
+   "_ipp._tcp.example.com." subdomain to the desired machine. It is also
+   convenient to set security policies on a per-zone/per-subdomain
+   basis. For example, the administrator may choose to enable DNS
+   Dynamic Update [RFC 2136] [RFC 3007] for printers registering in the
+   "_ipp._tcp.example.com." subdomain, but not for other
+   zones/subdomains. This easy flexibility would not exist if the
+   <Service> component appeared first in each name.
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 10]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+5. Service Name Resolution
+
+   Given a particular Service Instance Name, when a client needs to
+   contact that service, it sends a DNS query for the SRV record of
+   that name.
+
+   The result of the DNS query is a SRV record giving the port number
+   and target host where the service may be found.
+
+   The use of SRV records is very important. There are only 65535 TCP
+   port numbers available. These port numbers are being allocated
+   one-per-application-protocol at an alarming rate. Some protocols like
+   the X Window System have a block of 64 TCP ports allocated
+   (6000-6063). If we start allocating blocks of 64 TCP ports at a time,
+   we will run out even faster. Using a different TCP port for each
+   different instance of a given service on a given machine is entirely
+   sensible, but allocating large static ranges, as was done for X, is a
+   very inefficient way to manage a limited resource. On any given host,
+   most TCP ports are reserved for services that will never run on that
+   particular host. This is very poor utilization of the limited port
+   space. Using SRV records allows each host to allocate its available
+   port numbers dynamically to those services running on that host that
+   need them, and then advertise the allocated port numbers via SRV
+   records. Allocating the available listening port numbers locally
+   on a per-host basis as needed allows much better utilization of the
+   available port space than today's centralized global allocation.
+
+   In some environments there may be no compelling reason to assign
+   managed names to every host, since every available service is
+   accessible by name anyway, as a first-class entity in its own right.
+   However, the DNS packet format and record format still require a host
+   name to link the target host referenced in the SRV record to the
+   address records giving the IPv4 and/or IPv6 addresses for that
+   hardware. In the case where no natural host name is available, the
+   SRV record may give its own name as the name of the target host, and
+   then the requisite address records may be attached to that same name.
+   It is perfectly permissible for a single name in the DNS hierarchy to
+   have multiple records of different type attached. (The only
+   restriction being that a given name may not have both a CNAME record
+   and other records at the same time.)
+
+   In the event that more than one SRV is returned, clients MUST
+   correctly interpret the priority and weight fields -- i.e. Lower
+   numbered priority servers should be used in preference to higher
+   numbered priority servers, and servers with equal priority should be
+   selected randomly in proportion to their relative weights.
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 11]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+6. Data Syntax for DNS-SD TXT Records
+
+   Some services discovered via Service Instance Enumeration may need
+   more than just an IP address and port number to properly identify the
+   service. For example, printing via the LPR protocol often specifies a
+   queue name. This queue name is typically short and cryptic, and need
+   not be shown to the user. It should be regarded the same way as the
+   IP address and port number -- it is one component of the addressing
+   information required to identify a specific instance of a service
+   being offered by some piece of hardware. Similarly, a file server may
+   have multiple volumes, each identified by its own volume name. A Web
+   server typically has multiple pages, each identified by its own URL.
+   In these cases, the necessary additional data is stored in a TXT
+   record with the same name as the SRV record. The specific nature of
+   that additional data, and how it is to be used, is service-dependent,
+   but the overall syntax of the data in the TXT record is standardized,
+   as described below.
+
+
+6.1 General Format Rules for DNS TXT Records
+
+   A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total
+   length is indicated by the length given in the resource record header
+   in the DNS message. There is no way to tell directly from the data
+   alone how long it is (e.g. there is no length count at the start, or
+   terminating NULL byte at the end). (Note that when using Multicast
+   DNS [mDNS] the maximum packet size is 9000 bytes, which imposes an
+   upper limit on the size of TXT records of about 8800 bytes.)
+
+   The format of the data within a DNS TXT record is zero or more
+   strings, packed together in memory without any intervening gaps or
+   padding bytes for word alignment.
+
+   The format of each constituent string within the DNS TXT record is a
+   single length byte, followed by 0-255 bytes of text data.
+
+   These format rules are defined in Section 3.3.14 of RFC 1035, and are
+   not specific to DNS-SD. DNS-SD simply specifies a usage convention
+   for what data should be stored in those constituent strings.
+
+
+6.2 DNS TXT Record Format Rules for use in DNS-SD
+
+   DNS-SD uses DNS TXT records to store arbitrary name/value pairs
+   conveying additional information about the named service. Each
+   name/value pair is encoded as its own constituent string within the
+   DNS TXT record, in the form "name=value". Everything up to the first
+   '=' character is the name. Everything after the first '=' character
+   to the end of the string (including subsequent '=' characters, if
+   any) is the value. Specific rules governing names and values are
+   given below. Each author defining a DNS-SD profile for discovering
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 12]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+   instances of a particular type of service should define the base set
+   of name/value attributes that are valid for that type of service.
+
+   Using this standardized name/value syntax within the TXT record makes
+   it easier for these base definitions to be expanded later by defining
+   additional named attributes. If an implementation sees unknown
+   attribute names in a service TXT record, it MUST silently ignore them.
+
+   The TCP (or UDP) port number of the service, and target host name,
+   are given in the SRV record. This information -- target host name and
+   port number -- MUST NOT be duplicated using name/value attributes in
+   the TXT record.
+
+   The intention of DNS-SD TXT records is to convey a small amount of
+   useful additional information about a service. Ideally it SHOULD NOT
+   be necessary for a client to retrieve this additional information
+   before it can usefully establish a connection to the service. For a
+   well-designed TCP-based application protocol, it should be possible,
+   knowing only the host name and port number, to open a connection to
+   that listening process, and then perform version- or feature-
+   negotiation to determine the capabilities of the service instance.
+   For example, when connecting to an AppleShare server over TCP, the
+   client enters into a protocol exchange with the server to determine
+   which version of the AppleShare protocol the server implements, and
+   which optional features or capabilities (if any) are available. For a
+   well-designed application protocol, clients should be able to connect
+   and use the service even if there is no information at all in the TXT
+   record. In this case, the information in the TXT record should be
+   viewed as a performance optimization -- when a client discovers many
+   instances of a service, the TXT record allows the client to know some
+   rudimentary information about each instance without having to open a
+   TCP connection to each one and interrogate every service instance
+   separately. Extreme care should be taken when doing this to ensure
+   that the information in the TXT record is in agreement with the
+   information retrieved by a client connecting over TCP.
+
+   There are legacy protocols which provide no feature negotiation
+   capability, and in these cases it may be useful to convey necessary
+   information in the TXT record. For example, when printing using the
+   old Unix LPR (port 515) protocol, the LPR service provides no way for
+   the client to determine whether a particular printer accepts
+   PostScript, or what version of PostScript, etc. In this case it is
+   appropriate to embed this information in the TXT record, because the
+   alternative is worse -- passing around written instructions to the
+   users, arcane manual configuration of "/etc/printcap" files, etc.
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 13]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+6.3 DNS-SD TXT Record Size
+
+   The total size of a typical DNS-SD TXT record is intended to be small
+   -- 200 bytes or less.
+
+   In cases where more data is justified (e.g. LPR printing), keeping
+   the total size under 400 bytes should allow it to fit in a single
+   standard 512-byte DNS message. (This standard DNS message size is
+   defined in RFC 1035.)
+
+   In extreme cases where even this is not enough, keeping the size of
+   the TXT record under 1300 bytes should allow it to fit in a single
+   1500-byte Ethernet packet.
+
+   Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this
+   time.
+
+
+6.4 Rules for Names in DNS-SD Name/Value Pairs
+
+   The "Name" MUST be at least one character. Strings beginning with an
+   '=' character (i.e. the name is missing) SHOULD be silently ignored.
+
+   The characters of "Name" MUST be printable US-ASCII values
+   (0x20-0x7E), excluding '=' (0x3D).
+
+   Spaces in the name are significant, whether leading, trailing, or in
+   the middle -- so don't include any spaces unless you really intend
+   that!
+
+   Case is ignored when interpreting a name, so "papersize=A4",
+   "PAPERSIZE=A4" and "Papersize=A4" are all identical.
+
+   If there is no '=', then it is a boolean attribute, and is simply
+   identified as being present, with no value.
+
+   Unless specified otherwise by a particular DNS-SD profile, a given
+   attribute name may appear at most once in a TXT record. If a client
+   receives a TXT record containing the same attribute name more than
+   once, then the client SHOULD silently ignore all but the first
+   occurrence of that attribute. For client implementations that process
+   a DNS-SD TXT record from start to end, placing name/value pairs into
+   a hash table, using the name as the hash table key, this means that
+   if the implementation attempts to add a new name/value pair into the
+   table and finds an entry with the same name already present, then the
+   new entry being added should be silently discarded instead. For
+   client implementations that retrieve name/value pairs by searching
+   the TXT record for the requested name, they should search the TXT
+   record from the start, and simply return the first matching name they
+   find.
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 14]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+   When examining a TXT record for a given named attribute, there are
+   therefore four broad categories of results which may be returned:
+
+   * Attribute not present (Absent)
+
+   * Attribute present, with no value
+     (e.g. "Anon Allowed" -- server allows anonymous connections)
+
+   * Attribute present, with empty value (e.g. "Installed PlugIns=" --
+     server supports plugins, but none are presently installed)
+
+   * Attribute present, with non-empty value
+     (e.g. "Installed PlugIns=JPEG,MPEG2,MPEG4")
+
+   Each author defining a DNS-SD profile for discovering instances of a
+   particular type of service should define the interpretation of these
+   different kinds of result. For example, for some keys, there may be
+   a natural true/false boolean interpretation:
+
+   * Present implies 'true'
+   * Absent implies 'false'
+
+   For other keys it may be sensible to define other semantics, such as
+   value/no-value/unknown:
+
+   * Present with value implies that value.
+     E.g. "Color=4" for a four-color ink-jet printer,
+     or "Color=6" for a six-color ink-jet printer.
+
+   * Present with empty value implies 'false'. E.g. Not a color printer.
+    
+   * Absent implies 'Unknown'. E.g. A print server connected to some
+     unknown printer where the print server doesn't actually know if the
+     printer does color or not -- which gives a very bad user experience
+     and should be avoided wherever possible.
+
+   (Note that this is a hypothetical example, not an example of actual
+   name/value keys used by DNS-SD network printers.)
+
+   As a general rule, attribute names that contain no dots are defined
+   as part of the open-standard definition written by the person or
+   group defining the DNS-SD profile for discovering that particular
+   service type. Vendor-specific extensions should be given names of the
+   form "keyname.company.com=value", using a domain name legitimately
+   registered to the person or organization creating the vendor-specific
+   key. This reduces the risk of accidental conflict if different
+   organizations each define their own vendor-specific keys.
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 15]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+6.5 Rules for Values in DNS-SD Name/Value Pairs
+
+   If there is an '=', then everything after the first '=' to the end of
+   the string is the value. The value can contain any eight-bit values
+   including '='. Leading or trailing spaces are part of the value, so
+   don't put them there unless you intend them to be there. Any
+   quotation marks around the value are part of the value, so don't put
+   them there unless you intend them to be part of the value.
+
+   The value is opaque binary data. Often the value for a particular
+   attribute will be US-ASCII (or UTF-8) text, but it is legal for a
+   value to be any binary data. For example, if the value of a key is an
+   IPv4 address, that address should simply be stored as four bytes of
+   binary data, not as a variable-length 7-15 byte ASCII string giving
+   the address represented in textual dotted decimal notation.
+
+   Generic debugging tools should generally display all attribute values
+   as a hex dump, with accompanying text alongside displaying the UTF-8
+   interpretation of those bytes, except for attributes where the
+   debugging tool has embedded knowledge that the value is some other
+   kind of data.
+
+   Authors defining DNS-SD profiles SHOULD NOT convert binary attribute
+   data types into printable text (e.g. using hexadecimal, Base64 or UU
+   encoding) merely for the sake of making the data be printable text
+   when seen in a generic debugging tool. Doing this simply bloats the
+   size of the TXT record, without atually making the data any more
+   understandable to someone looking at it in a generic debugging tool.
+
+
+6.6 Example TXT Record
+
+   The TXT record below contains three syntactically valid name/value
+   pairs. (The meaning of these name/value pairs, if any, would depend
+   on the definitions pertaining to the service in question that is
+   using them.)
+
+   ---------------------------------------------------------------
+   | 0x0A | name=value | 0x08 | paper=A4 | 0x0E | DNS-SD Is Cool |
+   ---------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 16]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+6.7 Version Tag
+
+   It is recommended that authors defining DNS-SD profiles include an
+   attribute of the form "txtvers=xxx" in their definition, and require
+   it to be the first name/value pair in the TXT record. This
+   information in the TXT record can be useful to help clients maintain
+   backwards compatibility with older implementations if it becomes
+   necessary to change or update the specification over time. Even if
+   the profile author doesn't anticipate the need for any future
+   incompatible changes, having a version number in the specification
+   provides useful insurance should incompatible changes become
+   unavoidable. Clients SHOULD ignore TXT records with a txtvers number
+   higher (or lower) than the version(s) they know how to interpret.
+
+   Note that the version number in the txtvers tag describes the version
+   of the TXT record specification being used to create this TXT record,
+   not the version of the application protocol that will be used if the
+   client subsequently decides to contact that service. Ideally, every
+   DNS-SD TXT record specification starts at txtvers=1 and stays that
+   way forever. Improvements can be made by defining new keys that older
+   clients silently ignore. The only reason to increment the version
+   number is if the old specification is subsequently found to be so
+   horribly broken that there's no way to do a compatible forward
+   revision, so the txtvers number has to be incremented to tell all the
+   old clients they should just not even try to understand this new TXT
+   record.
+
+   If there is a need to indicate which version number(s) of the
+   application protocol the service implements, the recommended key
+   name for this is "protovers".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 17]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+7. Application Protocol Names
+
+   The <Service> portion of a Service Instance Name consists of a pair
+   of DNS labels, following the established convention for SRV records
+   [RFC 2782], namely: the first label of the pair is the Application
+   Protocol Name, and the second label is either "_tcp" or "_udp".
+
+   Wise selection of the Application Protocol Name is very important,
+   and the choice is not always as obvious as it may appear.
+
+   In some cases, the Application Protocol Name merely names and refers
+   to the on-the-wire message format and semantics being used. FTP is
+   "ftp", IPP printing is "ipp", and so on.
+
+   However, it is common to "borrow" an existing protocol and repurpose
+   it for a new task. This is entirely sensible and sound engineering
+   practice, but that doesn't mean that the new protocol is providing
+   the same semantic service as the old one, even if it borrows the same
+   message formats. For example, the local network music playing
+   protocol implemented by iTunes on Macintosh and Windows is little
+   more than "HTTP GET" commands. However, that does *not* mean that it
+   is sensible or useful to try to access one of these music servers by
+   connecting to it with a standard web browser. Consequently, the
+   DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp"
+   (Digital Audio Access Procol), not "_http._tcp". Advertising
+   "_http._tcp" service would cause iTunes servers to show up in
+   conventional Web browsers (Safari, Camino, OmniWeb, Opera, Netscape,
+   Internet Explorer, etc.) which is little use since it offers no pages
+   containing human-readable content. Similarly, browsing for
+   "_http._tcp" service would cause iTunes to find generic web servers,
+   such as the embedded web servers in devices like printers, which is
+   little use since printers generally don't have much music to offer.
+
+   Similarly, NFS is built on top of SUN RPC, but that doesn't mean it
+   makes sense for an NFS server to advertise that it provides "SUN RPC"
+   service. Likewise, Microsoft SMB file service is built on top of
+   Netbios running over IP, but that doesn't mean it makes sense for an
+   SMB file server to advertise that it provides "Netbios-over-IP"
+   service. The DNS-SD name of a service needs to encapsulate both the
+   "what" (semantics) and the "how" (protocol implementation) of the
+   service, since knowledge of both is necessary for a client to
+   usefully use the service. Merely advertising that a service was built
+   on top of SUN RPC is no use if the client has no idea what the
+   service actually does.
+
+   Another common mistake is to assume that the service type advertised
+   by iTunes should be "_daap._http._tcp." This is also incorrect. Part
+   of the confusion here is that the presence of "_tcp" or "_udp" in the
+   <Service> portion of a Service Instance Name has led people to assume
+   that the structure of a service name has to reflect the internal
+   structure of how the protocol was implemented. This is not correct.
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 18]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+   The "_tcp" or "_udp" should be regarded as little more than
+   boilerplate text, and care should be taken not to attach too much
+   importance to it. Some might argue that the "_tcp" or "_udp" should
+   not be there at all, but this format is defined by RFC 2782, and
+   that's not going to change. In addition, the presence of "_tcp" has
+   the useful side-effect that it provides a convenient delegation point
+   to hand off control to a different DNS server, if so desired.
+
+
+8. Selective Instance Enumeration
+
+   This document does not attempt to define an arbitrary query language
+   for service discovery, nor do we believe one is necessary.
+
+   However, there are some circumstances where narrowing the list of
+   results may be useful. A Web browser client that is able to retrieve
+   HTML documents via HTTP and display them may also be able to retrieve
+   HTML documents via FTP and display them, but only in the case of FTP
+   servers that allow anonymous login. For that Web browser, discovering
+   all FTP servers on the network is not useful. The Web browser only
+   wants to discover FTP servers that it is able to talk to. In this
+   case, a subtype of "_ftp._tcp" could be defined. Instead of issuing a
+   query for "_ftp._tcp.<Domain>", the Web browser issues a query for
+   "_anon._ftp._tcp.<Domain>", where "_anon" is a defined subtype of
+   "_ftp._tcp". The response to this query only includes the names of
+   SRV records for FTP servers that are willing to allow anonymous
+   login.
+
+   Note that the FTP server's Service Instance Name is unchanged -- it
+   is still something of the form "The Server._ftp._tcp.example.com."
+   The subdomain in which FTP server SRV records are registered defines
+   the namespace within which FTP server names are unique. Additional
+   subtypes (e.g. "_anon") of the basic service type (e.g. "_ftp._tcp")
+   serve to narrow the list of results, not to create more namespace.
+
+   As with the TXT record name/value pairs, the list of possible
+   subtypes, if any, are defined and specified separately for each basic
+   service type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 19]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+9. Flagship Naming
+
+   In some cases, there may be several network protocols available which
+   all perform roughly the same logical function. For example, the
+   printing world has the LPR protocol, and the Internet Printing
+   Protocol (IPP), both of which cause printed sheets to be emitted from
+   printers in much the same way. In addition, many printer vendors send
+   their own proprietary page description language (PDL) data over a TCP
+   connection to TCP port 9100, herein referred to as the
+   "pdl-datastream" protocol. In an ideal world we would have only one
+   network printing protocol, and it would be sufficiently good that no
+   one felt a compelling need to invent a different one. However, in
+   practice, multiple legacy protocols do exist, and a service discovery
+   protocol has to accommodate that.
+
+   Many printers implement all three printing protocols: LPR, IPP, and
+   pdl-datastream. For the benefit of clients that may speak only one of
+   those protocols, all three are advertised.
+
+   However, some clients may implement two, or all three of those
+   printing protocols. When a client looks for all three service types
+   on the network, it will find three distinct services -- an LPR
+   service, an IPP service, and a pdl-datastream service -- all of which
+   cause printed sheets to be emitted from the same physical printer.
+
+   In the case of multiple protocols like this that all perform
+   effectively the same function, the client should suppress duplicate
+   names and display each name only once. When the user prints to a
+   given named printer, the printing client is responsible for choosing
+   the protocol which will best achieve the desired effect, without, for
+   example, requiring the user to make a manual choice between LPR and
+   IPP.
+
+   As described so far, this all works very well. However, consider some
+   future printer that only supports IPP printing, and some other future
+   printer that only supports pdl-datastream printing. The name spaces
+   for different service types are intentionally disjoint -- it is
+   acceptable and desirable to be able to have both a file server called
+   "Sales Department" and a printer called "Sales Department". However,
+   it is not desirable, in the common case, to have two different
+   printers both called "Sales Department", just because those printers
+   are implementing different protocols.
+
+   To help guard against this, when there are two or more network
+   protocols which perform roughly the same logical function, one of the
+   protocols is declared the "flagship" of the fleet of related
+   protocols. Typically the flagship protocol is the oldest and/or
+   best-known protocol of the set.
+
+   If a device does not implement the flagship protocol, then it instead
+   creates a placeholder SRV record (priority=0, weight=0, port=0,
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 20]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+   target host = hostname of device) with that name. If, when it
+   attempts to create this SRV record, it finds that a record with the
+   same name already exists, then it knows that this name is already
+   taken by some entity implementing at least one of the protocols from
+   the class, and it must choose another. If no SRV record already
+   exists, then the act of creating it stakes a claim to that name so
+   that future devices in the same class will detect a conflict when
+   they try to use it. The SRV record needs to contain the target host
+   name in order for the conflict detection rules to operate. If two
+   different devices were to create placeholder SRV records both using a
+   null target host name (just the root label), then the two SRV records
+   would be seen to be in agreement so no conflict would be registered.
+
+   By defining a common well-known flagship protocol for the class,
+   future devices that may not even know about each other's protocols
+   establish a common ground where they can coordinate to verify
+   uniqueness of names.
+
+   No PTR record is created advertising the presence of empty flagship
+   SRV records, since they do not represent a real service being
+   advertised.
+
+
+10. Service Type Enumeration
+
+   In general, clients are not interested in finding *every* service on
+   the network, just the services that the client knows how to talk to.
+   (Software designers may *think* there's some value to finding *every*
+   service on the network, but that's just wooly thinking.)
+
+   However, for problem diagnosis and network management tools, it may
+   be useful for network administrators to find the list of advertised
+   service types on the network, even if those service names are just
+   opaque identifiers and not particularly informative in isolation.
+
+   For this reason, a special meta-query is defined. A DNS query for
+   PTR records with the name "_services._dns-sd._udp.<Domain>" yields
+   a list of PTR records, where the rdata of each PTR record is the
+   name of a service type. A subsequent query for PTR records with
+   one of those names yields a list of instances of that service type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 21]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+11. Populating the DNS with Information
+
+   How the SRV and PTR records that describe services and allow them to
+   be enumerated make their way into the DNS is outside the scope of
+   this document. However, it can happen easily in any of 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 Apple LaserWriters 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.
+
+   Future IP printers could use Dynamic DNS Update [RFC 2136] to
+   automatically register their own SRV and PTR 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 and SRV names ending with ".local." [mDNS]
+
+
+12. Relationship to Multicast DNS
+
+   DNS-Based Service Discovery is only peripherally related to Multicast
+   DNS, in that the standard unicast DNS queries used by DNS-SD may also
+   be performed using multicast when appropriate, which is particularly
+   beneficial in Zeroconf environments [ZC].
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 22]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+13. Discovery of Browsing and Registration Domains (Domain Enumeration)
+
+   One of the main reasons for DNS-Based Service Discovery is so that
+   when a visiting client (e.g. a laptop computer) arrives at a new
+   network, it can discover what services are available on that network
+   without manual configuration. This logic that applies to discovering
+   services without manual configuration also applies to discovering the
+   domains in which services are registered without requiring manual
+   configuration.
+
+   This discovery is performed recursively, using Unicast or Multicast
+   DNS. Four special RR names are reserved for this purpose:
+
+                 _browse._dns-sd._udp.<domain>
+        _default._browse._dns-sd._udp.<domain>
+               _register._dns-sd._udp.<domain>
+      _default._register._dns-sd._udp.<domain>
+
+   By performing PTR queries for these names, a client can learn,
+   respectively:
+
+   o A list of domains recommended for browsing
+
+   o A single recommended default domain for browsing
+
+   o A list of domains recommended for registering services using
+     Dynamic Update
+
+   o A single recommended default domain for registering services.
+
+   These domains are purely advisory. The client or user is free to
+   browse and/or register services in any domains. The purpose of these
+   special queries is to allow software to create a user-interface that
+   displays a useful list of suggested choices to the user, from which
+   they may make a suitable selection, or ignore the offered suggestions
+   and manually enter their own choice.
+
+   The <domain> part of the name may be ".local." (meaning "perform the
+   query using link-local multicast) or it may be learned through some
+   other mechanism, such as the DHCP "Domain" option (option code 15)
+   [RFC 2132] or the DHCP "Domain Search" option (option code 119)
+   [RFC 3397]. Sophisticated clients may perform these queries both in
+   ".local." and in one or more unicast domains, and then present the
+   user with an aggregate result, combining the information received
+   from all sources.
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 23]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+14. DNS Additional Record Generation
+
+   DNS has an efficiency feature whereby a DNS server may place
+   additional records in the Additional Section of the DNS Message.
+   These additional records are typically records that the client did
+   not explicitly request, but the server has reasonable grounds to
+   expect that the client might request them shortly.
+
+   This section recommends which additional records should be generated
+   to improve network efficiency for both unicast and multicast DNS-SD
+   responses.
+
+
+14.1 PTR Records
+
+   When including a PTR record in a response packet, the
+   server/responder SHOULD include the following additional records:
+
+   o The SRV record(s) named in the PTR rdata.
+   o The TXT record(s) named in the PTR rdata.
+   o All address records (type "A" and "AAAA") named in the SRV rdata.
+
+
+14.2 SRV Records
+
+   When including an SVR record in a response packet, the
+   server/responder SHOULD include the following additional records:
+
+   o All address records (type "A" and "AAAA") named in the SRV rdata.
+
+
+14.3 TXT Records
+
+   When including a TXT record in a response packet, no additional
+   records are required.
+
+
+14.4 Other Record Types
+
+   In response to address queries, or other record types, no additional
+   records are required by this document.
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 24]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+15. Comparison with Alternative Service Discovery Protocols
+
+   Over the years there have been many proposed ways to do network
+   service discovery with IP, but none achieved ubiquity in the
+   marketplace. Certainly none has achieved anything close to the
+   ubiquity of today's deployment of DNS servers, clients, and other
+   infrastructure.
+
+   The advantage of using DNS as the basis for service discovery is that
+   it makes use of those existing servers, clients, protocols,
+   infrastructure, and expertise. Existing network analyser tools
+   already know how to decode and display DNS packets for network
+   debugging.
+
+   For ad-hoc networks such as Zeroconf environments, peer-to-peer
+   multicast protocols are appropriate. The Zeroconf host profile [ZCHP]
+   requires the use of a DNS-like protocol over IP Multicast for host
+   name resolution in the absence of DNS servers. Given that Zeroconf
+   hosts will have to implement this Multicast-based DNS-like protocol
+   anyway, it makes sense for them to also perform service discovery
+   using that same Multicast-based DNS-like software, instead of also
+   having to implement an entirely different service discovery protocol.
+
+   In larger networks, a high volume of enterprise-wide IP multicast
+   traffic may not be desirable, so any credible service discovery
+   protocol intended for larger networks has to provide some facility to
+   aggregate registrations and lookups at a central server (or servers)
+   instead of working exclusively using multicast. This requires some
+   service discovery aggregation server software to be written,
+   debugged, deployed, and maintained. This also requires some service
+   discovery registration protocol to be implemented and deployed for
+   clients to register with the central aggregation server. Virtually
+   every company with an IP network already runs a DNS server, and DNS
+   already has a dynamic registration protocol [RFC 2136]. Given that
+   virtually every company already has to operate and maintain a DNS
+   server anyway, it makes sense to take advantage of this instead of
+   also having to learn, operate and maintain a different service
+   registration server. It should be stressed again that using the same
+   software and protocols doesn't necessarily mean using the same
+   physical piece of hardware. The DNS-SD service discovery functions
+   do not have to be provided by the same piece of hardware that
+   is currently providing the company's DNS name service. The
+   "_tcp.<Domain>" subdomain may be delegated to a different piece of
+   hardware. However, even when the DNS-SD service is being provided by
+   a different piece of hardware, it is still the same familiar DNS
+   server software that is running, with the same configuration file
+   syntax, the same log file format, and so forth.
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 25]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+   Service discovery needs to be able to provide appropriate security.
+   DNS already has existing mechanisms for security [RFC 2535].
+
+   In summary:
+
+      Service discovery requires a central aggregation server.
+      DNS already has one: It's called a DNS server.
+
+      Service discovery requires a service registration protocol.
+      DNS already has one: It's called DNS Dynamic Update.
+
+      Service discovery requires a query protocol
+      DNS already has one: It's called DNS.
+
+      Service discovery requires security mechanisms.
+      DNS already has security mechanisms: DNSSEC.
+
+      Service discovery requires a multicast mode for ad-hoc networks.
+      Zeroconf environments already require a multicast-based DNS-like
+      name lookup protocol for mapping host names to addresses, so it
+      makes sense to let one multicast-based protocol do both jobs.
+
+   It makes more sense to use the existing software that every network
+   needs already, instead of deploying an entire parallel system just
+   for service discovery.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 26]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+16. Real Example
+
+   The following examples were prepared using standard unmodified
+   nslookup and standard unmodified BIND running on GNU/Linux.
+
+   Note: In real products, this information is obtained and presented to
+   the user using graphical network browser software, not command-line
+   tools, but if you wish you can try these examples for yourself as you
+   read along, using the command-line tools already available on your
+   own Unix machine.
+
+
+16.1 Question: What FTP servers are being advertised from dns-sd.org?
+
+   nslookup -q=ptr _ftp._tcp.dns-sd.org.
+   _ftp._tcp.dns-sd.org name=Apple\032QuickTime\032Files.dns-sd.org
+   _ftp._tcp.dns-sd.org name=Microsoft\032Developer\032Files.dns-sd.org
+   _ftp._tcp.dns-sd.org name=Registered\032Users'\032Only.dns-sd.org
+
+   Answer: There are three, called "Apple QuickTime Files",
+   "Microsoft Developer Files" and "Registered Users' Only".
+
+   Note that nslookup escapes spaces as "\032" for display purposes,
+   but a graphical DNS-SD browser does not.
+
+
+16.2 Question: What FTP servers allow anonymous access?
+
+   nslookup -q=ptr _anon._ftp._tcp.dns-sd.org
+   _anon._ftp._tcp.dns-sd.org
+                        name=Apple\032QuickTime\032Files.dns-sd.org
+   _anon._ftp._tcp.dns-sd.org
+                        name=Microsoft\032Developer\032Files.dns-sd.org
+
+   Answer: Only "Apple QuickTime Files" and "Microsoft Developer Files"
+   allow anonymous access.
+
+
+16.3 Question: How do I access "Apple QuickTime Files"?
+
+   nslookup -q=any "Apple\032QuickTime\032Files.dns-sd.org."
+   Apple\032QuickTime\032Files.dns-sd.org  text = "path=/quicktime"
+   Apple\032QuickTime\032Files.dns-sd.org
+        priority = 0, weight = 0, port= 21 host = ftp.apple.com
+   ftp.apple.com   internet address = 17.254.0.27
+   ftp.apple.com   internet address = 17.254.0.31
+   ftp.apple.com   internet address = 17.254.0.26
+
+   Answer: You need to connect to ftp.apple.com, port 21, path
+   "/quicktime". The addresses for ftp.apple.com are also given.
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 27]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+17. IPv6 Considerations
+
+   IPv6 has no significant differences, except that the address of the
+   SRV record's target host is given by the appropriate IPv6 address
+   records instead of the IPv4 "A" record.
+
+
+18. Security Considerations
+
+   DNSSEC [RFC 2535] should be used where the authenticity of
+   information is important. Since DNS-SD is just a naming and usage
+   convention for records in the existing DNS system, it has no specific
+   additional security requirements over and above those that already
+   apply to DNS queries and DNS updates.
+
+
+19. IANA Considerations
+
+   This protocol builds on DNS SRV records [RFC 2782], and similarly
+   requires IANA to assign unique application protocol names.
+   Unfortunately, the "IANA Considerations" section of RFC 2782 says
+   simply, "The IANA has assigned RR type value 33 to the SRV RR.
+   No other IANA services are required by this document."
+   Due to this oversight, IANA is currently prevented from carrying
+   out the necessary function of assigning these unique identifiers.
+
+   This document proposes the following IANA allocation policy for
+   unique application protocol names:
+
+   Allowable names:
+     * Must be no more than fourteen characters long
+     * Must consist only of:
+       - lower-case letters 'a' - 'z'
+       - digits '0' - '9'
+       - the hyphen character '-'
+     * Must begin and end with a lower-case letter or digit.
+     * Must not already be assigned to some other protocol in the
+       existing IANA "list of assigned application protocol names
+       and port numbers" [ports].
+
+   These identifiers are allocated on a First Come First Served basis.
+   In the event of abuse (e.g. automatated mass registrations, etc.),
+   the policy may be changed without notice to Expert Review [RFC 2434].
+
+   The textual nature of service/protocol names means that there are
+   almost infinitely many more of them available than the finite set of
+   65535 possible port numbers. This means that developers can produce
+   experimental implementations using unregistered service names with
+   little chance of accidental collision, providing service names are
+   chosen with appropriate care. However, this document strongly
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 28]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+   advocates that on or before the date a product ships, developers
+   should properly register their service names.
+
+   Some developers have expressed concern that publicly registering
+   their service names (and port numbers today) with IANA before a
+   product ships may give away clues about that product to competitors.
+   For this reason, IANA should consider allowing service name
+   applications to remain secret for some period of time, much as US
+   patent applications remain secret for two years after the date of
+   filing.
+
+   This proposed IANA allocation policy is not in force until this
+   document is published as an RFC. In the meantime, unique application
+   protocol names may be registered according to the instructions at
+   <http://www.dns-sd.org/ServiceNames.html>. As of January 2004, there
+   are roughly 100 application protocols in currently shipping products
+   that have been so registered as using DNS-SD for service discovery.
+
+
+20. Acknowledgements
+
+   We would like to thank (in alphabetical order) Richard Brown, Josh
+   Graessley, Erik Guttman, Paul Vixie, and Bill Woodcock, for their
+   contributions.
+
+
+21. Copyright
+
+   Copyright (C) The Internet Society 2004.
+   All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works. However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 29]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+22. Normative References
+
+   [ports]    IANA list of assigned application protocol names and port
+              numbers <http://www.iana.org/assignments/port-numbers>
+
+   [RFC 1033] Lottor, M., "Domain Administrators Operations Guide",
+              RFC 1033, November 1987.
+
+   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
+              Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+              Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, March 1997.
+
+   [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", RFC 2279, January 1998.
+
+   [RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the
+              location of services (DNS SRV)", RFC 2782, February 2000.
+
+
+23. Informative References
+
+   [mDNS]     Cheshire, S., and M. Krochmal, "Multicast DNS",
+              Internet-Draft (work in progress),
+              draft-cheshire-dnsext-multicastdns-04.txt, February 2004.
+
+   [NBP]      Cheshire, S., and M. Krochmal,
+              "Requirements for a Protocol to Replace AppleTalk NBP",
+              Internet-Draft (work in progress),
+              draft-cheshire-dnsext-nbp-03.txt, February 2004.
+
+   [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP
+              Vendor Extensions", RFC 2132, March 1997.
+
+   [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
+              System (DNS UPDATE)", RFC 2136, April 1997.
+
+   [RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing
+              an IANA Considerations Section in RFCs", RFC 2434,
+              October 1998.
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 30]
+
+Internet Draft       DNS-Based Service Discovery      14th February 2004
+
+
+   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC 3007] Wellington, B., et al., "Secure Domain Name System (DNS)
+              Dynamic Update", RFC 3007, November 2000.
+
+   [RFC 3397] Aboba, B., and Cheshire, S., "Dynamic Host Configuration
+              Protocol (DHCP) Domain Search Option", RFC 3397, November
+              2002.
+
+   [ZC]       Williams, A., "Requirements for Automatic Configuration
+              of IP Hosts", Internet-Draft (work in progress),
+              draft-ietf-zeroconf-reqts-12.txt, September 2002.
+
+   [ZCHP]     Guttman, E., "Zeroconf Host Profile Applicability
+              Statement", Internet-Draft (work in progress),
+              draft-ietf-zeroconf-host-prof-01.txt, July 2001.
+
+
+24. Author's Addresses
+
+   Stuart Cheshire
+   Apple Computer, Inc.
+   1 Infinite Loop
+   Cupertino
+   California 95014
+   USA
+
+   Phone: +1 408 974 3207
+   EMail: rfc@stuartcheshire.org
+
+
+   Marc Krochmal
+   Apple Computer, Inc.
+   1 Infinite Loop
+   Cupertino
+   California 95014
+   USA
+
+   Phone: +1 408 974 4368
+   EMail: marc@apple.com
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004           Cheshire & Krochmal         [Page 31]