Added section on capabilities discovery; added TXT fields corresponding to the node, ver, and ext attributes from XEP-0115; changed textvers value to 2.
IN TXT "1st=user-first-name"
IN TXT "email=user-email-address"
+ IN TXT "ext=optional-list-of-extensions"
IN TXT "jid=user-jabber-id"
IN TXT "last=user-last-name"
IN TXT "msg=freeform-availability-status"
IN TXT "nick=user-nickname"
+ IN TXT "node=application-identifier"
IN TXT "phsh=sha1-hash-of-avatar"
IN TXT "port.p2pj=5298"
IN TXT "status=avail-away-or-dnd"
- IN TXT "txtvers=1"
+ IN TXT "txtvers=2"
IN TXT "vc=capabilities-string"
+ IN TXT "ver=application-version"
]]>
@@ -174,15 +183,19 @@ _presence._tcp.local. 5526 IN PTR stpeter@roundabout._presence._tcp.local.
psa IN TXT "1st=Peter"
psa IN TXT "email=stpeter@jabber.org"
+psa IN TXT "ext=rcd sgc auxvideo sgs mvideo avavail avcap maudio"
psa IN TXT "jid=stpeter@jabber.org"
psa IN TXT "last=Saint-Andre"
psa IN TXT "msg=IETF 66 Montreal"
psa IN TXT "nick=stpeter"
+psa IN TXT "node=http://www.apple.com/ichat/caps"
psa IN TXT "phsh=a3839614e1a382bcfebbcf20464f519e81770813"
psa IN TXT "port.p2pj=5298"
psa IN TXT "status=avail"
-psa IN TXT "txtvers=1"
+psa IN TXT "txtvers=2"
psa IN TXT "vc=CA!"
+psa IN TXT "ver=524"
+
]]>
The IPv4 and IPv6 addresses associated with a machine may vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be "10.2.1.187" but when the machine is connected to a wireless network, its physical address might change to "10.10.1.179".
In the unlikely event that the "presence name" (username@machine-name) asserted by a client is already taken by another entity on the network, the client MUST choose a different presence name, which SHOULD be formed by adding the digit "1" to the end of the username string, adding the digit "2" if the resulting presence name is already taken, and incrementing the digit until a unique presence name is constructed.
@@ -201,6 +214,10 @@ psa IN TXT "vc=CA!"It is OPTIONAL to include any of these TXT keys, since link-local messaging can be used by non-human entities (e.g., devices) and these keys relate to human users. However, for use by humans, certain keys are of greater interest than others, e.g. the "msg" and "status" keys. See also the Security Considerations section of this document regarding the inclusion of information that may have an impact on personal privacy (e.g., the "1st", "last", "nick", "email", and "jid" keys).
@@ -247,6 +272,9 @@ psa IN TXT "vc=CA!"When the _presence._tcp service is used, presence is exchanged via the format described in the TXT Records section of this document. In particular, presence information is not pushed as in XMPP (see &rfc3921;). Instead, clients listen for presence announcements from other local entities. Recommended rates for sending updates can be found in Multicast DNS.
Because link-local communication does not involve the exchange of XMPP presence, it is not possible to use &xep0115; for capabilities discovery. Therefore, it is REQUIRED to instead include the node and ver TXT fields (and OPTIONAL to include the ext TXT field). The values of these fields MUST be the same as the values for the 'node', 'ver', and 'ext' attributes that are advertised for the application in XMPP presence (if any) via the Entity Capabilities protocol as described in XEP-0115.
+In order to exchange link-local messages, the sender and recipient MUST first establish XML streams between themselves, as is familiar from RFC 3920.
First, the initating party opens a TCP connection at the IP address and port discovered via the DNS lookup for a local entity and opens an XML stream to the recipient, which SHOULD include 'to' and 'from' address: