From b564a24f2b54471142e1892d43be16bab702210f Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 20 Feb 2008 18:19:39 +0000 Subject: [PATCH] 1.1pre4 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1691 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0174.xml | 77 ++++++++++++++++++++++++++-------------------------- 1 file changed, 38 insertions(+), 39 deletions(-) diff --git a/xep-0174.xml b/xep-0174.xml index 4641a23a..46853728 100644 --- a/xep-0174.xml +++ b/xep-0174.xml @@ -6,8 +6,8 @@
- Link-Local Messaging - This specification defines how to establish XMPP-like communications over local networks based on zero-configuration networking. This method uses DNS-based Service Discovery and Multicast DNS to discover entities that support the protocol, including their IP addresses and preferred ports. Any two entities can then negotiate a serverless connection using standard XML streams in order to exchange XMPP message and IQ stanzas. + Serverless Messaging + This specification defines how to communicate over local or wide-area networks using the principles of zero-configuration networking for endpoint discovery and the syntax of XML streams and XMPP messaging for real-time communication. This method uses DNS-based Service Discovery and Multicast DNS (or Wide-Area DNS-SD) to discover entities that support the protocol, including their IP addresses and preferred ports. Any two entities can then negotiate a serverless connection using standard XML streams in order to exchange XMPP message and IQ stanzas. &LEGALNOTICE; 0174 Draft @@ -27,10 +27,10 @@ &stpeter; - 1.1pre3 - in progress, last updated 2008-01-17 + 1.1pre4 + in progress, last updated 2008-02-20 psa -

Clarified order of publishing and querying DNS records; corrected several DNS errors in the text and examples; added friendly How It Works section; added implementation note about port choice; updated TXT records to reflect version 1.5 of XEP-0115; updated registry.

 +

Clarified order of publishing and querying DNS records; corrected several DNS errors in the text and examples; added friendly How It Works section; added implementation note about port choice; updated TXT records to reflect version 1.5 of XEP-0115; updated registry; generalized text to handle usage of wide-area DNS-SD.

 1.0 @@ -145,13 +145,13 @@

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.

-

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 for many years. 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.

+

However, it is possible to establish an XMPP-like communications system on a local (or even wide-area) network using the principles of 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 serverless 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.

+

Serverless messaging is restricted to a local network (or ad-hoc wide-area network) because of how zero-configuration networking works. It is impossible for clients that communicate via this serverless mode to insert messages into an XMPP network, which is why this kind of "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 serverless mesh to an XMPP network or vice-versa).

+

Such a "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 serverless messaging has been a feature of Apple's iChat client when operating in Bonjour (formerly Rendezvous) mode for many years. Because it is desirable for other Jabber/XMPP clients to support such functionality, this document describes how to use zero-configuration networking as the basis for serverless communication, mainly for use on local links (although the protocol can also be used on ad-hoc wide-area networks).

 -

This section provides a friendly introduction to link-local messaging.

-

Imagine that you are a Shakespearean character named Juliet. You are are using your laptop computer (a machine named "pronto") at a wifi hotspot in downtown Verona and you want to find other people to chat with on an ad-hoc basis (i.e., not people in your normal XMPP roster). Therefore your chat client advertises a link-local address of "juliet@pronto" so that other people can dynamically find you at the hotspot. Your client does this by invoking a daemon on your machine that supports DNS-based Service Discovery ("DNS-SD") as defined in &dnssd; and Multicast DNS ("mDNS") as defined in &mdns;. As a result, the daemon stores the following DNS records and listens for multicast DNS queries asking for them:

+

This section provides a friendly introduction to serverless messaging. The examples show usage on a local link using dynamically configured link-local addresses as described in &rfc3927; (see the Wide-Area Networks section of this document regarding non-local usage).

+

Imagine that you are a Shakespearean character named Juliet. You are are using your laptop computer (a machine named "pronto") at a wifi hotspot in downtown Verona and you want to find other people to chat with on an ad-hoc basis (i.e., not people in your normal XMPP roster). Therefore your chat client advertises a serverless address of "juliet@pronto" so that other people can dynamically find you at the hotspot. Your client does this by invoking a daemon on your machine that supports DNS-based Service Discovery ("DNS-SD") as defined in &dnssd; and Multicast DNS ("mDNS") as defined in &mdns;. As a result, the daemon stores the following DNS records and listens for multicast DNS queries asking for them:

-

Other people at the hotspot may 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 link-local multicast 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 link-local 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).

-

Now let us imagine that a fine young gentleman named Romeo joins the hotspot and that his chat client (actually his mDNS daemon) sends out link-local multicast queries for link-local services of type "presence". To do this, his client essentially reverses the order of DNS record publication (explained above) by asking for pointers to presence services (i.e., PTR records that match "_presence._tcp.local."), querying each service for its service instance and port (i.e., SRV record), mapping each service instance to an IP address (i.e., A record), and finding out additional information about the entity using the service (i.e., TXT records). As a result, Romeo's client will discover any number of local presence services, among them a service named "juliet@pronto" (with some intriguing TXT records) at IP address 10.2.1.187 and port 5562. Being a romantic fellow, he then initiates a chat with you by opening an XML stream to the advertised IP address and port.

+

Other people at the hotspot may 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).

+

Now let us imagine that a fine young gentleman named Romeo joins the hotspot and that his chat client (actually his mDNS daemon) sends out multicast DNS queries for services of type "presence". To do this, his client essentially reverses the order of DNS record publication (explained above) by asking for pointers to presence services (i.e., PTR records that match "_presence._tcp.local."), querying each service for its service instance and port (i.e., SRV record), mapping each service instance to an IP address (i.e., A record), and finding out additional information about the entity using the service (i.e., TXT records). As a result, Romeo's client will discover any number of local presence services, among them a service named "juliet@pronto" (with some intriguing TXT records) at IP address 10.2.1.187 and port 5562. Being a romantic fellow, he then initiates a chat with you by opening an XML stream to the advertised IP address and port.

DNS-SD A convention for naming and structuring DNS SRV records such that a client can dynamically discover a domain for a service using only standard DNS queries. See draft-cheshire-dnsext-dns-sd. For a full list of registered DNS-SD records, see <http://www.dns-sd.org/ServiceTypes.html>. - - Link-local address - An IPv4 or IPv6 address that is valid for communication with other devices connected to the same physical or logical link. See &rfc3927;. - Multicast DNS (mDNS) A technology that provides the ability to perform DNS-like operations on a local link in the absence of any conventional unicast DNS server. See draft-cheshire-dnsext-multicastdns. Zero-configuration networking - A set of technologies that enable the use of the Internet Protocol for local communications. See <http://www.zeroconf.org/>. + A set of technologies that enable the use of the Internet Protocol for local or wide-area communications. See <http://www.zeroconf.org/>. -

In order to advertise its availability for link-local messaging, a client MUST publish four different kinds of DNS records:

+

In order to advertise its availability for serverless messaging, a client MUST publish four different kinds of DNS records:

  1. A PTR record of the following form:

    @@ -267,7 +263,7 @@ _presence._tcp.local. PTR username@machine-name._presence._tcp.local. ]]>
  2. -

    An address ("A" or "AAAA") record of the following form: The IP address MAY be either an IPv4 address or an IPv6 address.

    +

    An address ("A" or "AAAA") record of the following form (where the IP address can be either an IPv4 address or an IPv6 address):

    @@ -330,32 +326,32 @@ juliet IN TXT "vc=CA!" juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI=" ]]> -

    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 "192.168.0.100" but when the machine is connected to a wireless network the physical address might change to "10.10.1.187".

    +

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

    If the machine name asserted by a client is already taken by another machine on the network, the client MUST assert a different machine name, which SHOULD be formed by adding the character "-" and digit "1" to the end of the machine name string (e.g., "pronto-1"), adding the character "-" and digit "2" if the resulting machine name is already taken (e.g., "pronto-2"), and similarly incrementing the digit until a unique machine name is constructed.

    If the username asserted by a client is already taken by another application on the machine, the client MUST assert a different username, which SHOULD be formed by adding the character "-" and digit "1" to the end of the username string (e.g., "juliet-1"), adding the character "-" and digit "2" if the resulting username is already taken (e.g., "juliet-2"), and similarly incrementing the digit until a unique username is constructed.

    DNS-SD enables service definitions to include various TXT records that specify parameters to be used in the context of the relevant service type. The ®ISTRAR; maintains a registry of TXT records for use with the _presence._tcp service type, as specified in the XMPP Registrar Considerations section of this document.

    -

    It is OPTIONAL to include any of these TXT records, and an implementation MUST NOT fail (i.e., MUST enable link-local messaging) even if none of the TXT records are provided by another local entity.

    -

    Most of the registered TXT records relate to human users, in which context certain records are of greater interest than others, e.g. "msg", "nick", and "status"; however, link-local messaging can be used by non-human entities (e.g., devices).

    +

    It is OPTIONAL to include any of these TXT records, and an implementation MUST NOT fail (i.e., MUST enable serverless messaging) even if none of the TXT records are provided by another entity.

    +

    Most of the registered TXT records relate to human users, in which context certain records 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 may have an impact on personal privacy (e.g., the "1st", "last", "nick", "email", and "jid" records).

     -

    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. The replies will include a record corresponding the client itself; the client MUST filter out this result. The client MAY then find out detailed information about each machine by sending SRV and TXT queries to "machine-name.local." for each machine (however, to preserve bandwidth, the client SHOULD NOT send these queries unless it is about to initiate communications with the other user, and it MUST cancel the queries after it has received a response). Note: The presence name to be used for display in a link-local "roster" SHOULD be obtained from the <Instance> portion of the received PTR record for each user; however, the client MAY instead display a name or nickname derived from the TXT records if available.

    +

    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 serverless messaging. The replies will include a record corresponding the client itself; the client MUST filter out this result. The client MAY then find out detailed information about each machine by sending SRV and TXT queries to "machine-name.local." for each machine (however, to preserve bandwidth, the client SHOULD NOT send these queries unless it is about to initiate communications with the other user, and it MUST cancel the queries after it has received a response). Note: The presence name to be used for display in a serverless "roster" SHOULD be obtained from the <Instance> portion of the received PTR record for each user; however, the client MAY instead display a name or nickname derived from the TXT records if available.

     -

    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.

    +

    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 entities on the local link or wide-area network. 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 RECOMMENDED to instead include the node, hash, and ver TXT records (and OPTIONAL to include the ext and v TXT records). The values of these records MUST be the same as the values for the 'node', 'hash', 'ver', 'ext', 'n', 'os', and 'v' attributes that are advertised for the application in normal XMPP presence (if any) via the Entity Capabilities protocol as described in XEP-0115.

    +

    Because serverless communication does not involve the exchange of XMPP presence, it is not possible to use &xep0115; for capabilities discovery. Therefore, it is RECOMMENDED to instead include the node, hash, and ver TXT records (and OPTIONAL to include the ext and v TXT records). The values of these records MUST be the same as the values for the 'node', 'hash', 'ver', 'ext', 'n', 'os', and 'v' attributes that are advertised for the application in normal XMPP presence (if any) via the Entity Capabilities protocol as described in XEP-0115.

     -

    In order to exchange link-local messages, the initiator and recipient MUST first establish XML streams between themselves, as is familiar from RFC 3920.

    -

    First, the initiator 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:

    +

    In order to exchange serverless messages, the initiator and recipient MUST first establish XML streams between themselves, as is familiar from RFC 3920.

    +

    First, the initiator opens a TCP connection at the IP address and port discovered via the DNS lookup for an entity and opens an XML stream to the recipient, which SHOULD include 'to' and 'from' address:

    -

    Once the streams are established, either entity then can send XMPP message or IQ stanzas by specifying 'to' and 'from' addresses using the logical local addresses: The to and from addresses MUST be of the form "username@machine-name" as discovered via SRV (this is the <Instance> portion of the Service Instance Name).

    +

    Once the streams are established, either entity then can send XMPP message or IQ stanzas by specifying 'to' and 'from' addresses using the logical addresses: The to and from addresses MUST be of the form "username@machine-name" as discovered via SRV (this is the <Instance> portion of the Service Instance Name).

    M'lady, I would be pleased to make your acquaintance. @@ -410,12 +406,12 @@ juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI="     -

    In order to go offline, a client MUST send a Multicast DNS "Goodbye" packet for the user's PTR record. As a result, all other entities on the local network will receive a Multicast DNS "Remove" event, at which point they MUST cancel any outstanding TXT, SRV, or NULL record queries for the offline user.

    +

    In order to go offline, a link-local entity MUST send a Multicast DNS "Goodbye" packet for the user's PTR record. As a result, all other entities on the local network will receive a Multicast DNS "Remove" event, at which point they MUST cancel any outstanding TXT, SRV, or NULL record queries for the offline user.

     -

    Devices that use link-local messaging may have multiple network interfaces. As a result, it is possible to discover the same entity multiple times. Even if a client discovers the same presence name on multiple network interfaces, it MUST show only one entity in the local roster. In addition, because local IP addresses can be dynamically re-assigned, the client SHOULD NOT store the IP address to be used for communications when it discovers that address in the initial DNS lookup phase; instead, it SHOULD delay sending the Multicast DNS query until the client is ready to communicate with the other entity.

    +

    Devices that use serverless messaging may have multiple network interfaces. As a result, it is possible to discover the same entity multiple times. Even if a client discovers the same presence name on multiple network interfaces, it MUST show only one entity in the serverless roster. In addition, because local IP addresses can be dynamically re-assigned, the client SHOULD NOT store the IP address to be used for communications when it discovers that address in the initial DNS lookup phase; instead, it SHOULD delay sending the Multicast DNS query until the client is ready to communicate with the other entity.

    If an entity has an associated icon (e.g., a user avatar or photo), its client SHOULD publish the raw binary data for that image via a DNS NULL record of the following form:

    @@ -424,31 +420,34 @@ _presence._tcp.local. IN NULL raw-binary-data-here ]]>

    Note: In accordance with &rfc1035;, the data MUST be 65535 octets or less.

    After retrieving the "phsh" value from a Buddy's TXT record, a client SHOULD search its local picture database to learn the last recorded picture hash value for an entity and then compare it to the "phsh" value in the TXT record. If the values are equal, the client SHOULD use the local copy of the icon. If the picture hash values are not equal, the client SHOULD issue a Multicast DNS NULL record query to retrieve the new icon. After retrieving the NULL record, the client SHOULD replace the old "phsh" value in the picture database with the new "phsh" value and save the icon to disk. If the client needs to send a Multicast DNS query in order to retrieve the icon, it MUST cancel the NULL record query immediately after receiving a response containing the new picture data.

    -

    If a user changes their picture, the user's client MUST update the NULL record with the contents of the new picture, calculate a new picture hash, and then update the "phsh" value in the TXT record with the new hash value. Since all users logged into local presence are monitoring for TXT record changes, they will see that the "phsh" value was changed; if they wish to view the new icon, their clients SHOULD issue a new Multicast DNS query to retrieve the updated picture.

    +

    If a user changes their picture, the user's client MUST update the NULL record with the contents of the new picture, calculate a new picture hash, and then update the "phsh" value in the TXT record with the new hash value. Since all users "logged into" serverless presence are monitoring for TXT record changes, they will see that the "phsh" value was changed; if they wish to view the new icon, their clients SHOULD issue a new Multicast DNS query to retrieve the updated picture.

     -

    The port used for link-local messaging MAY be any unassigned port number, as determined by the messaging application on the device. The chosen port MUST be specified in the SRV record and applications MUST use the port specified in the SRV record. However, the chosen port SHOULD also be specifed in the "port.p2pj" TXT record for backwards-compatibility with older implementations, and if included the port specified in the TXT record MUST be the same as the port specified in the SRV record.

    +

    The port used for serverless messaging MAY be any unassigned port number, as determined by the messaging application on the device. The chosen port MUST be specified in the SRV record and applications MUST use the port specified in the SRV record. However, the chosen port SHOULD also be specifed in the "port.p2pj" TXT record for backwards-compatibility with older implementations, and if included the port specified in the TXT record MUST be the same as the port specified in the SRV record.

    +     + +

    Serverless messaging via the _presence._tcp DNS SRV service type is not limited to local networks, since it is possible to advertise this service type via Wide-Area DNS-SD as described at <http://www.dns-sd.org/iChatWideArea.html>. Although the protocol is most commonly used on local networks, there is nothing intrinsic to the protocol that limits its use to peers on the same link, and it also works between any two peers that can discover each other via any profile of DNS-SD (whether local or wide-area). Naturally, the DNS records used in Wide-Area DNS-SD will not contain the ".local." domain, since the records are not intended for use over a local link.

         -

    RFC 1035 does not allow characters outside the &ascii; character range in DNS A records. Therefore the "machine-name" portion of an A record as used for link-local messaging MUST NOT contain characters outside the US-ASCII character range.

    -

    Although RFC 2317 and RFC 2782 do not allow characters outside the US-ASCII character range in PTR and SRV records respectively, Section 4.1 of DNS-Based Service Discovery recommends support for UTF-8-encoded Unicode characters in the <Instance> portion of Service Instance Names, which in link-local messaging is the "username@machine-name" portion of the PTR or SRV record. This document adheres to the recommendation in DNS-Based Service Discovery. However, as mentioned above, the "machine-name" portion of the <Instance> portion MUST NOT contain characters outside the US-ASCII range.

    +

    RFC 1035 does not allow characters outside the &ascii; character range in DNS A records. Therefore the "machine-name" portion of an A record as used for serverless messaging MUST NOT contain characters outside the US-ASCII character range.

    +

    Although RFC 2317 and RFC 2782 do not allow characters outside the US-ASCII character range in PTR and SRV records respectively, Section 4.1 of DNS-Based Service Discovery recommends support for UTF-8-encoded Unicode characters in the <Instance> portion of Service Instance Names, which in serverless messaging is the "username@machine-name" portion of the PTR or SRV record. This document adheres to the recommendation in DNS-Based Service Discovery. However, as mentioned above, the "machine-name" portion of the <Instance> portion MUST NOT contain characters outside the US-ASCII range.

    Although RFC 1464 does not allow characters outside the US-ASCII character range in TXT records, Section 6.5 of DNS-Based Service Discovery mentions support for UTF-8-encoded Unicode characters in text record values (e.g., values of the TXT "msg" name). This document adheres to the recommendation in DNS-Based Service Discovery.

     -

    XMPP networks use TLS (&rfc2246;) for channel encryption, SASL (&rfc4422;) for authentication, and the Domain Name System (&rfc1034;) for weak validation of server hostnames; these technologies help to ensure the identity of sending entities and to encrypt XML streams. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, link-local messaging does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between local entities.

    +

    XMPP networks use TLS (&rfc2246;) for channel encryption, SASL (&rfc4422;) for authentication, and the Domain Name System (&rfc1034;) for weak validation of server hostnames; these technologies help to ensure the identity of sending entities and to encrypt XML streams. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, serverless messaging does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between entities.

    There are two potential solutions to this problem:

    1. Negotiate the use of TLS and SASL for the XML stream as described in RFC 3920.
    2. Negotiate encryption with identity checking for the message exchange using &xep0116;.
    -

    It is RECOMMENDED to use one of these methods to secure communications between local entities. However, subject to client configuration and local service policies, two entities MAY accept an unauthenticated and unencrypted channel; but a client SHOULD warn the human user that the channel is unauthenticated and unencrypted.

    +

    It is RECOMMENDED to use one of these methods to secure communications between serverless entities. However, subject to client configuration and local service policies, two entities MAY accept an unauthenticated and unencrypted channel; but a client SHOULD warn the human user that the channel is unauthenticated and unencrypted.

     -

    Because of fundamental differences between a true XMPP network and a localized XMPP client "mesh", local entities MUST NOT attempt to inject local traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated in accordance with the rules defined in RFC 3920. However, a client on a local mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a local client mesh to a contact on an XMPP network).

    +

    Because of fundamental differences between a true XMPP network and a serverless client "mesh", entities communicating via serverless messagin MUST NOT attempt to inject serverless traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated in accordance with the rules defined in RFC 3920. However, a client on a serverless mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a serverless client mesh to a contact on an XMPP network).

    Because there is no mechanism for validating the information that is published in DNS TXT records, it is possible for clients to "poison" this information (e.g., by publishing email addresses or Jabber IDs that are controlled by or associated with other users).

    @@ -484,7 +483,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here -

    The ®ISTRAR; maintains a registry of TXT records advertised in the context of link-local messaging (see &LINKLOCAL;).

    +

    The ®ISTRAR; maintains a registry of TXT records advertised in the context of serverless messaging (see &LINKLOCAL;).

    ®PROCESS; port.p2pj - The port for link-local communications. This MUST be the same as the + The port for serverless communications. This MUST be the same as the value provided for SRV lookups. Clients MUST use the port discovered via SRV lookups and MUST ignore the value of this TXT record. However, clients SHOULD advertise this TXT record if it is important to ensure