Community
Participate
Working Groups
Expires 8th September 2010 Cheshire & Krochmal [Page 23] Internet Draft DNS-Based Service Discovery 8th March 2010 "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, http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt Expires 8th September 2010 Cheshire & Krochmal [Page 24] Internet Draft DNS-Based Service Discovery 8th March 2010 it is not desirable, in the common case, to have two different printers both called "Sales Department", just because those printers implement 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, 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 other entity implementing at least one of the protocols from the fleet, 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 protocol fleet will detect a conflict when they try to use it. Note: When used with Multicast DNS [mDNS], the target host field of the placeholder SRV record MUST NOT be the empty root label. The SRV record needs to contain a real target host name in order for the Multicast DNS 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. "
