Other people at the hotspot can also advertise similar DNS records for use on the local link. Essentially, the mDNS daemons running on all of the machines at the hotspot collectively manage the ".local." domain, which has meaning only at the hotspot (not across the broader Internet). Queries and responses for services on the local link occur via multicast DNS over UDP port 5353 instead of via normal DNS unicast over UDP port 53. When a new machine joins the local link, it can send out queries for any number of service types, to which the other machines will reply. For the purpose of serverless messaging we are interested only in the "presence" service, but many other services could exist on the local link (see dns-sd.org for a complete list).
@@ -321,19 +321,19 @@ pronto.local. A 10.2.1.187 juliet@pronto._presence._tcp.local. IN TXT " 0x09txtvers=1 - 0x101st=Juliet - 0x1Eemail=juliet@capulet.lit - 0x10hash=sha-1 - 0x1Cjid=juliet@capulet.lit - 0x12last=Capulet - 0x12msg=Hanging out downtown - 0x10nick=JuliC - 0x26node=http://www.adiumx.com - 0x45phsh=a3839614e1a382bcfebbcf20464f519e81770813 - 0x14port.p2pj=5562 - 0x12status=avail + 0x0A1st=Juliet + 0x18email=juliet@capulet.lit + 0x0Ahash=sha-1 + 0x16jid=juliet@capulet.lit + 0x0Clast=Capulet + 0x18msg=Hanging out downtown + 0x0Anick=JuliC + 0x1Anode=http://www.adiumx.com + 0x2Dphsh=a3839614e1a382bcfebbcf20464f519e81770813 + 0x0Eport.p2pj=5562 + 0x0Cstatus=avail 0x06vc=CA! - 0x33ver=QgayPKawpkPSDYmwT/WM94uAlu0= + 0x20ver=QgayPKawpkPSDYmwT/WM94uAlu0= " ]]>The IPv4 and IPv6 addresses associated with a machine might vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be "192.168.0.100" but when the machine is connected to a wireless network the physical address might change to "10.10.1.187". See RFC 3927 for details.
@@ -344,7 +344,7 @@ juliet@pronto._presence._tcp.local. IN TXT "For detailed information about the format of the TXT record value, refer to the DNS-SD specification. The following truncated example illustrates the format.
In the context of serverless messaging, the following rules apply:
@@ -353,7 +353,7 @@ juliet@pronto._presence._tcp.local. IN TXT "The ®ISTRAR; maintains a registry of the parameters that can be used in the TXT record value for the _presence._tcp service type, as specified in the XMPP Registrar Considerations section of this document. Those parameters are not listed here. It is OPTIONAL to include any of these TXT record parameters, and an implementation MUST NOT fail (i.e., MUST enable serverless messaging) even if none of the parameters are provided by another entity. However, as mentioned the TXT reocrd MUST be published (although its value MAY be a single zero byte).
+The ®ISTRAR; maintains a registry of the parameters that can be used in the TXT record value for the _presence._tcp service type, as specified in the XMPP Registrar Considerations section of this document. Those parameters are not listed here. It is OPTIONAL to include any of these TXT record parameters, and an implementation MUST NOT fail (i.e., MUST enable serverless messaging) even if none of the parameters are provided by another entity. However, as mentioned the TXT record MUST be published (although its value MAY be a single zero byte).
Most of the registered TXT record parameters relate to human users, in which context certain parameters are of greater interest than others, e.g. "msg", "nick", and "status"; however, serverless messaging can be used by non-human entities (e.g., devices).
Note: See the Security Considerations section of this document regarding the inclusion of information that can have an impact on personal privacy (e.g., the "1st", "last", "nick", "email", and "jid" parameters).