Service Discovery Road Map
draft-cheshire-dnssd-roadmap-00

Document Type Active Internet-Draft (individual)
Last updated 2017-07-03
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                              S. Cheshire
Internet-Draft                                                Apple Inc.
Intended status: Informational                              July 2, 2017
Expires: January 3, 2018

                       Service Discovery Road Map
                    draft-cheshire-dnssd-roadmap-00

Abstract

   Over the course of several years, a rich collection of technologies
   has developed around DNS-Based Service Discovery, described across
   multiple documents.  This "Road Map" document gives an overview of
   how these separate but related technologies (and their documents) fit
   together, to facilitate Service Discovery in various environments.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 3, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Cheshire                 Expires January 3, 2018                [Page 1]
Internet-Draft         Service Discovery Road Map              July 2017

1.  Road Map

   DNS-Based Service Discovery [RFC6763] is a component of Zero
   Configuration Networking [RFC6760] [ZC] [Roadmap].

   Over the course of several years, a rich collection of technologies
   has developed around DNS-Based Service Discovery.  These various
   separate but related technologies are described across multiple
   documents.  This "Road Map" document gives an overview of how these
   technologies (and their documents) fit together to facilitate Service
   Discovery across a broad range of operating environments, from small
   scale zero-configuration networks to large scale administered
   networks, from local area to wide area, and from low-speed wireless
   links in the kb/s range to high-speed wired links operating at
   multiple Gb/s.

   Not all of the available components are necessary or appropriate in
   all scenarios.  One goal of this "Road Map" document is to provide
   guidance about which components to use depending on the problem being
   solved.

Cheshire                 Expires January 3, 2018                [Page 2]
Internet-Draft         Service Discovery Road Map              July 2017

2.  Service Type Namespace

   The single most important concept in Service Discovery is the
   namespace specifying how different service types are identified.
   This is how a client communicates what it needs, and how a server
   communicates what it offers.  For a client to discover a server,
   client and server need to use the same namespace of service types,
   otherwise they may actually speak the same application protocol over
   the air or on the wire, and may in fact be completely compatible, and
   yet may be unable to detect this because they are using different
   names to refer to the same actual service.  Hence, having a
   consistent namespace for referring to service types is vital.

   IANA manages the registry of Service Types [RFC6335][SN].  This
   registry of Service Types can (and should) be used in any Service
   Discovery protocol as the vocabulary for describing *all* IP-based
   services, not only DNS-Based Service Discovery [RFC6763].

   In this document we focus on the use of the IANA Service Type
   Registry [SN] in conjunction with DNS-Based Service Discovery, though
   that should not be taken in any way to imply any criticism of other
   Service Discovery protocols sharing the same namespace of service
   types.  In different circumstances different Service Discovery
   protocols are appropriate.

   For example, for Service Discovery of services potentially available
   via a Wi-Fi access point, prior to association with that Wi-Fi access
   point, when no IP link has yet been established, a Service Discovery
Show full document text