Clarified handling of stream version.
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.
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; shall maintain 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 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", "nick", and "status" keys.
-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" keys).
+It is OPTIONAL to include any of these TXT records, since link-local messaging can be used by non-human entities (e.g., devices) and these records relate to human users. However, for use by humans, certain records are of greater interest than others, e.g. the "msg", "nick", and "status" records.
+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).
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 records (and OPTIONAL to include the ext TXT record). The values of these records 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:
+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:
Note: If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in RFC 3920, then it SHOULD include the version='1.0' flag as shown in the previous example.
The recipient then responds with a stream header as well:
The recipient SHOULD also send stream features as specified in RFC 3920:
+If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in RFC 3920:
The p2pj port number 5298 is not included in the &ianaports; maintained by &IANA;. The author will investigate whether that port number (or some other port number) needs to be registered.
+The p2pj port number 5298 is not included in the &ianaports; maintained by &IANA;. As far as is known, the port number does not need to be registered with the IANA.
- the attribute name of the TXT record
- a natural-language description of the record
- the requirements status of the record; should be one of:
- required, recommended, optional, deprecated, obsolete
+ The attribute name of the TXT record.
+ A natural-language description of the record.
+
+ The requirements status of the record. Should be one of:
+ - required
+ - recommended
+ - optional
+ - deprecated
+ - obsolete
]]>
@@ -437,8 +451,8 @@ _presence._tcp.local. IN NULL raw-binary-data-here
the string MUST include the "!" character. The order of characters
in the string is immaterial. NOTE: This flag is included only for
backwards-compatibility; implementations SHOULD use the node, ver,
- and ext keys for more robust capabilities discovery as described in
- the Capabilities Discovery section of XEP-0174.
+ and ext records for more robust capabilities discovery as described
+ in the Capabilities Discovery section of XEP-0174.