Updated definition of port.p2pj TXT record so that it is not hardcoded to 5298 but instead tracks the port advertised via SRV.
Updated IANA Considerations to reflect proposed modification to DNS-SD registration.
Updated IANA Considerations to reflect proposed modifications to DNS-SD registration.
XMPP as defined in &rfc3920; does not support direct client-to-client interactions, since it requires authentication with a server: an XMPP client is allowed access to the network only once it has authenticated with a server, and the server must not grant access if authentication fails for any reason. If an unauthenticated client attempts to communicate directly with another client, such communication will fail because all XMPP communications are sent through one or more servers and a client cannot inject messages onto the network without first authenticating with a server.
-However, it is possible to establish an XMPP-like communications system on a local network using zero-configuration networking. In this situation, the clients obviate the XMPP requirement for authentication with a server by relying on zero-configuration networking to establish link-local communication using the _presence._tcp DNS SRV service type. Once discovery has been completed, the clients are then able to exchange messages and other structured data using the XMPP &MESSAGE; and &IQ; stanzas. Note well that such communications are restricted to the local network because of how zero-configuration networking works. It is impossible for clients that communicate via link-local addresses to insert messages into an XMPP network, which is why this kind of local "mesh" is most accurately referred to as an XMPP-like system that exists outside the context of existing XMPP networks (though see the Security Considerations regarding the ability to "forward" messages from a local mesh to an XMPP network or vice-versa).
+However, it is possible to establish an XMPP-like communications system on a local network using zero-configuration networking. In this situation, the clients obviate the XMPP requirement for authentication with a server by relying on zero-configuration networking to establish link-local communication using the _presence._tcp DNS SRV service type. Once discovery has been completed, the clients are then able to exchange messages and other structured data using the XMPP &MESSAGE; and &IQ; stanzas.
+Link-local messaging is restricted to the local network because of how zero-configuration networking works. It is impossible for clients that communicate via link-local addresses to insert messages into an XMPP network, which is why this kind of local "mesh" is most accurately referred to as an XMPP-like system that exists outside the context of existing XMPP networks (though see the Security Considerations regarding the ability to "forward" messages from a local mesh to an XMPP network or vice-versa).
Such a local "mesh" can be quite valuable in certain circumstances. For instance, participants in a trade show or conference, users of the same WiFi hotspot, or employees on the same local area network can communicate without the need for a pre-configured server. For this reason, support for link-local messaging has been a feature of Apple's iChat client when operating in Bonjour (formerly Rendezvous) mode. Because it is desirable for other Jabber clients to support such functionality, this document describes how to use zero-configuration networking as the basis for link-local communication.
The "machine-name" is the name of the computer, the "username" is the system username of the principal currently logged into the computer, the "port" may be any unassigned port number, and the "ip-address" is the physical address of the computer on the local network.
-So, for example, if the machine name is "roundabout", the username is "stpeter", the chosen port is "5526", the IP address is "10.2.1.187", and the personal information is that associated with the author of this document, the DNS records would be as follows:
+So, for example, if the machine name is "roundabout", the username is "stpeter", the chosen port is "5562", the IP address is "10.2.1.187", and the personal information is that associated with the author of this document, the DNS records would be as follows:
In order to discover other users, a client sends an mDNS request for PTR records that match "_presence_tcp.local.". The client then receives replies from all machines that advertise support for link-local messaging.
In order to discover other users, a client sends an mDNS request for PTR records that match "_presence._tcp.local.". The client then receives replies from all machines that advertise support for link-local messaging.
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.
@@ -256,7 +263,7 @@ psa IN TXT "ver=524"DNS-SD service type names are not yet managed by &IANA;. Section 19 of DNS-Based Service Discovery proposes an IANA allocation policy for unique application protocol or service type names. Until the proposal is adopted and in force, Section 19 points to <http://www.dns-sd.org/ServiceTypes.html> regarding registration of service type names for DNS-SD. The current registration is as follows:
-The XMPP Registrar has proposed to the maintainer of <http://www.dns-sd.org/ServiceTypes.html> that the registration be changed as follows:
+DNS-SD service type names are not yet managed by &IANA;. Section 19 of DNS-Based Service Discovery proposes an IANA allocation policy for unique application protocol or service type names. Until the proposal is adopted and in force, Section 19 points to <http://www.dns-sd.org/ServiceTypes.html> regarding registration of service type names for DNS-SD.
+There is an existing registration for the "presence" service type. The XMPP Registrar has proposed to the maintainer of <http://www.dns-sd.org/ServiceTypes.html> that the registration be changed as follows: