mirror of https://github.com/moparisthebest/xeps
1.3rc1: corrected TXT record format per draft-cheshire-dnsext-dns-sd
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2419 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
0f649efde0
commit
ce6a886ff7
226
xep-0174.xml
226
xep-0174.xml
|
|
@ -26,6 +26,12 @@
|
|||
<shortname>linklocal</shortname>
|
||||
<registry/>
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>1.3rc1</version>
|
||||
<date>in progress, last updated 2008-10-21</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Corrected TXT record format in conformance with draft-cheshire-dnsext-dns-sd.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.2</version>
|
||||
<date>2008-09-03</date>
|
||||
|
|
@ -171,25 +177,27 @@ _presence._tcp.local. PTR juliet@pronto._presence._tcp.local.
|
|||
<li>The SRV record (see &rfc2782;) maps the presence service instance "juliet@pronto" to the machine "pronto.local." on port 5562.</li>
|
||||
<li>The PTR ("pointer") record (see &rfc2317; and &rfc1886;) says that there is a service of type "presence" on the local subnet (".local.") called "juliet@pronto" and that the service communicates over TCP.</li>
|
||||
</ul>
|
||||
<p>Your chat client also wants to advertise some information about you (subject to your control so that you don't divulge private information). Therefore it invokes the mDNS daemon to also store some DNS TXT records (see &rfc1464;):</p>
|
||||
<p>Your chat client also wants to advertise some information about you (subject to your control so that you don't divulge private information). Therefore it invokes the mDNS daemon to also store a single DNS TXT record (see &rfc1464;) that encapsulates some strings of information, where the record name is the same as the SRV record and the record value follows the format defined in <cite>draft-cheshire-dnsext-dns-sd</cite> (note: the line breaks are provided only for the sake of readability).</p>
|
||||
<code><![CDATA[
|
||||
juliet IN TXT "txtvers=1"
|
||||
juliet IN TXT "1st=Juliet"
|
||||
juliet IN TXT "email=juliet@capulet.lit"
|
||||
juliet IN TXT "hash=sha-1"
|
||||
juliet IN TXT "jid=juliet@capulet.lit"
|
||||
juliet IN TXT "last=Capulet"
|
||||
juliet IN TXT "msg=Hanging out downtown"
|
||||
juliet IN TXT "nick=JuliC"
|
||||
juliet IN TXT "node=http://www.adiumx.com"
|
||||
juliet IN TXT "phsh=a3839614e1a382bcfebbcf20464f519e81770813"
|
||||
juliet IN TXT "port.p2pj=5562"
|
||||
juliet IN TXT "status=avail"
|
||||
juliet IN TXT "vc=CA!"
|
||||
juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI="
|
||||
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
|
||||
0x06vc=CA!
|
||||
0x33ver=66/0NaeaBKkwk85efJTGmU47vXI\=
|
||||
"
|
||||
]]></code>
|
||||
<p>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 <link url='http://www.dns-sd.org/'>dns-sd.org</link> for a complete list).</p>
|
||||
<p>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.</p>
|
||||
<p>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 record parameters). 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 record parameters) 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.</p>
|
||||
<code><![CDATA[
|
||||
<stream:stream
|
||||
xmlns='jabber:client'
|
||||
|
|
@ -274,30 +282,31 @@ machine-name.local. A ip-address
|
|||
<li>
|
||||
<p>An SRV record of the following form:</p>
|
||||
<code><![CDATA[
|
||||
_presence._tcp <ttl> SRV <priority> <weight> port-number machine-name.local.
|
||||
username@machine-name._presence._tcp.local <ttl> SRV <priority> <weight> port-number machine-name.local.
|
||||
]]></code>
|
||||
</li>
|
||||
<li>
|
||||
<p>Optionally, various TXT records of the following form, as further described in the <link url='#txt'>TXT Records</link> section of this document:</p>
|
||||
<p>Optionally, a TXT record whose name is the same as the SRV record and whose value follows the format defined in <cite>draft-cheshire-dnsext-dns-sd</cite>, as further described in the <link url='#txt'>TXT Record</link> section of this document (note: the line breaks are provided only for the sake of readability):</p>
|
||||
<code><![CDATA[
|
||||
<owner> IN <ttl> TXT "txtvers=1"
|
||||
<owner> IN <ttl> TXT "1st=user-first-name"
|
||||
<owner> IN <ttl> TXT "email=user-email-address"
|
||||
<owner> IN <ttl> TXT "hash=entity-capabilities-algorithm"
|
||||
<owner> IN <ttl> TXT "jid=user-jabber-id"
|
||||
<owner> IN <ttl> TXT "last=user-last-name"
|
||||
<owner> IN <ttl> TXT "msg=freeform-availability-status"
|
||||
<owner> IN <ttl> TXT "n=entity-capabilities-application-name"
|
||||
<owner> IN <ttl> TXT "nick=user-nickname"
|
||||
<owner> IN <ttl> TXT "node=application-identifier"
|
||||
<owner> IN <ttl> TXT "n=entity-capabilities-operating-system"
|
||||
<owner> IN <ttl> TXT "phsh=sha1-hash-of-avatar"
|
||||
<owner> IN <ttl> TXT "port.p2pj=5562"
|
||||
<owner> IN <ttl> TXT "status=avail-away-or-dnd"
|
||||
<owner> IN <ttl> TXT "vc=capabilities-string"
|
||||
<owner> IN <ttl> TXT "ver=entity-capabilities-identity"
|
||||
username@machine-name._presence._tcp.local. IN TXT "
|
||||
0x##txtvers=1
|
||||
0x##1st=user-first-name"
|
||||
0x##email=user-email-address"
|
||||
0x##hash=entity-capabilities-algorithm"
|
||||
0x##jid=user-jabber-id"
|
||||
0x##last=user-last-name"
|
||||
0x##msg=freeform-availability-status"
|
||||
0x##n=entity-capabilities-application-name"
|
||||
0x##nick=user-nickname"
|
||||
0x##node=application-identifier"
|
||||
0x##n=entity-capabilities-operating-system"
|
||||
0x##phsh=sha1-hash-of-avatar"
|
||||
0x##port.p2pj=5562"
|
||||
0x##status=avail-away-or-dnd"
|
||||
0x##vc=capabilities-string"
|
||||
0x##ver=entity-capabilities-identity"
|
||||
"
|
||||
]]></code>
|
||||
<p>Note: In accordance with Section 6.7 of <cite>draft-cheshire-dnsext-dns-sd</cite>, the "txtvers" record SHOULD be the first record specified.</p>
|
||||
</li>
|
||||
</ol>
|
||||
<p>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" can be any unassigned port number, and the "ip-address" is the physical address of the computer on the local network.</p>
|
||||
|
|
@ -309,43 +318,52 @@ juliet@pronto._presence._tcp.local. SRV 5562 pronto.local.
|
|||
|
||||
pronto.local. A 10.2.1.187
|
||||
|
||||
juliet IN TXT "txtvers=1"
|
||||
juliet IN TXT "1st=Juliet"
|
||||
juliet IN TXT "email=juliet@capulet.lit"
|
||||
juliet IN TXT "hash=sha-1"
|
||||
juliet IN TXT "jid=juliet@capulet.lit"
|
||||
juliet IN TXT "last=Capulet"
|
||||
juliet IN TXT "msg=Hanging out downtown"
|
||||
juliet IN TXT "nick=JuliC"
|
||||
juliet IN TXT "node=http://www.adiumx.com"
|
||||
juliet IN TXT "phsh=a3839614e1a382bcfebbcf20464f519e81770813"
|
||||
juliet IN TXT "port.p2pj=5562"
|
||||
juliet IN TXT "status=avail"
|
||||
juliet IN TXT "vc=CA!"
|
||||
juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI="
|
||||
|
||||
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
|
||||
0x06vc=CA!
|
||||
0x33ver=66/0NaeaBKkwk85efJTGmU47vXI\=
|
||||
"
|
||||
]]></code>
|
||||
<p>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 <cite>RFC 3927</cite> for details.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<section2 topic='TXT Records' anchor='txt'>
|
||||
<p>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 <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
|
||||
<p>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.</p>
|
||||
<p>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).</p>
|
||||
<p>Note: See the <link url='#security'>Security Considerations</link> 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" records).</p>
|
||||
<section2 topic='TXT Record' anchor='txt'>
|
||||
<p>DNS-SD enables service definitions to include a TXT record that specifies parameters to be used in the context of the relevant service type. The name of the TXT record is the same as that of the SRV record (i.e., "username@machine-name._presence._tcp.local."). The value of the TXT record is a binary object that contains one or more strings, where (1) each string is a parameter that usually takes the form of a key-value pair and (2) the parameters are separated by a single-length byte ("0x##") that specifies the length of the parameter itself.</p>
|
||||
<p>For detailed information about the format of the TXT record value, refer to the DNS-SD specification. The following truncated example illustrates the format.</p>
|
||||
<code><![CDATA[
|
||||
--------------------------------------------------------------------------
|
||||
| 0x09 | txtvers=1 | 0x10 | 1st=Juliet | 0x1E | email=juliet@capulet.lit |
|
||||
--------------------------------------------------------------------------
|
||||
]]></code>
|
||||
<p>Note: In accordance with Section 6.7 of <cite>draft-cheshire-dnsext-dns-sd</cite>, the first parameter in the TXT record value SHOULD be "txtvers".</p>
|
||||
<p>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 <link url='#registrar'>XMPP Registrar Considerations</link> section of this document. Those parameters are not listed here.</p>
|
||||
<p>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.</p>
|
||||
<p>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).</p>
|
||||
<p>Note: See the <link url='#security'>Security Considerations</link> 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).</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Discovering Other Users' anchor='disco'>
|
||||
<p>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. <note>The replies will include a record corresponding the client itself; the client MUST filter out this result.</note> 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 communication 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.</p>
|
||||
<p>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. <note>The replies will include a record corresponding the client itself; the client MUST filter out this result.</note> The client MAY then find out detailed information about each machine by sending SRV and TXT queries to "username@machine-name.local." for each machine (however, to preserve bandwidth, the client SHOULD NOT send these queries unless it is about to initiate communication 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 record if available.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Exchanging Presence' anchor='presence'>
|
||||
<p>When the _presence._tcp service is used, presence is exchanged via the format described in the <link url='#txt'>TXT Records</link> 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 <cite>Multicast DNS</cite>.</p>
|
||||
<p>When the _presence._tcp service is used, presence is exchanged via the format described in the <link url='#txt'>TXT Record</link> 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 <cite>Multicast DNS</cite>.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Discovering Capabilities' anchor='caps'>
|
||||
<p>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 TXT record). The values of these records MUST be the same as the values for the 'node', 'hash', 'ver', and 'ext' attributes that are advertised for the application in normal XMPP presence (if any) via the Entity Capabilities protocol as described in <cite>XEP-0115</cite>.</p>
|
||||
<p>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 record parameters (and OPTIONAL to include the ext parameter). The values of these parameters MUST be the same as the values for the 'node', 'hash', 'ver', and 'ext' attributes that are advertised for the application in normal XMPP presence (if any) via the Entity Capabilities protocol as described in <cite>XEP-0115</cite>.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Initiating a Messaging Session' anchor='initiate'>
|
||||
|
|
@ -449,11 +467,11 @@ _presence._tcp.local. IN NULL raw-binary-data-here
|
|||
<section2 topic='Stanza Injection' anchor='security-inject'>
|
||||
<p>Because of fundamental differences between a true XMPP network and a serverless client "mesh", entities communicating via serverless messaging 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 <cite>RFC 3920</cite>. 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).</p>
|
||||
</section2>
|
||||
<section2 topic='TXT Record Data' anchor='security-txt'>
|
||||
<section2 topic='TXT Record Parameters' anchor='security-txt'>
|
||||
<p>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).</p>
|
||||
</section2>
|
||||
<section2 topic='Private Information' anchor='security-priv'>
|
||||
<p>The TXT records optionally advertised as part of this protocol MAY result in exposure of privacy-sensitive information about a human user (such as full name, email address, and Jabber ID). A client MUST allow a user to disable publication of this personal information (e.g., via client configuration).</p>
|
||||
<p>The TXT record parameters optionally advertised as part of this protocol MAY result in exposure of privacy-sensitive information about a human user (such as full name, email address, and Jabber ID). A client MUST allow a user to disable publication of this personal information (e.g., via client configuration).</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
|
|
@ -482,14 +500,14 @@ _presence._tcp.local. IN NULL raw-binary-data-here
|
|||
</section1>
|
||||
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Link-Local Messaging TXT Records Registry' anchor='registrar-linklocal'>
|
||||
<p>The ®ISTRAR; maintains a registry of TXT records advertised in the context of serverless messaging (see &LINKLOCAL;).</p>
|
||||
<section2 topic='Link-Local Messaging TXT Record Parameters Registry' anchor='registrar-linklocal'>
|
||||
<p>The ®ISTRAR; maintains a registry of parameter strings contained in the TXT record advertised for serverless messaging (see &LINKLOCAL;).</p>
|
||||
<section3 topic='Registration Process' anchor='registrar-linklocal-process'>
|
||||
®PROCESS;
|
||||
<code><![CDATA[
|
||||
<record>
|
||||
<name>The attribute name of the TXT record.</name>
|
||||
<desc>A natural-language description of the record.</desc>
|
||||
<param>
|
||||
<name>The name of the parameter as used a key-value pair.</name>
|
||||
<desc>A natural-language description of the parameter.</desc>
|
||||
<status>
|
||||
The requirements status of the record. Should be one of:
|
||||
- required
|
||||
|
|
@ -498,30 +516,30 @@ _presence._tcp.local. IN NULL raw-binary-data-here
|
|||
- deprecated
|
||||
- obsolete
|
||||
</status>
|
||||
</record>
|
||||
</param>
|
||||
]]></code>
|
||||
<p>The registrant can register more than one TXT record at a time, each contained in a separate <record/> element.</p>
|
||||
<p>The registrant can register more than one parameter at a time, each contained in a separate <record/> element.</p>
|
||||
</section3>
|
||||
<section3 topic='Initial Registration' anchor='registrar-linklocal-reg'>
|
||||
<p>The following submission registers TXT records in use as of June 2007. Refer to the registry itself for a complete and current list of TXT records (this specification might or might not be revised when new TXT records are registered).</p>
|
||||
<p>The following submission registers parameters in use as of June 2007. Refer to the registry itself for a complete and current list of parameters (this specification might or might not be revised when new parameters are registered).</p>
|
||||
<code><![CDATA[
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>1st</name>
|
||||
<desc>The given or first name of the user.</desc>
|
||||
<status>optional</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>email</name>
|
||||
<desc>
|
||||
The email address of the user; can contain a space-separated list
|
||||
of more than one email address.
|
||||
</desc>
|
||||
<status>optional</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>ext</name>
|
||||
<desc>
|
||||
A space-separated list of extensions; the value of this record MUST
|
||||
|
|
@ -529,49 +547,49 @@ _presence._tcp.local. IN NULL raw-binary-data-here
|
|||
in the 'ext' attribute specified in Entity Capabilities (XEP-0115).
|
||||
</desc>
|
||||
<status>optional</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>hash</name>
|
||||
<desc>
|
||||
The hashing algorithm used to generated the 'ver' attribute in
|
||||
Entity Capabilities (XEP-0115) and therefore the ver TXT record
|
||||
Entity Capabilities (XEP-0115) and therefore the ver parameter
|
||||
in Link-Local Messaging.
|
||||
</desc>
|
||||
<status>recommended</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>jid</name>
|
||||
<desc>
|
||||
The Jabber ID of the user; can contain a space-separated list of
|
||||
more than one JID.
|
||||
</desc>
|
||||
<status>recommended</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>last</name>
|
||||
<desc>The family or last name of the user.</desc>
|
||||
<status>optional</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>msg</name>
|
||||
<desc>
|
||||
Natural-language text describing the user's state. This is
|
||||
equivalent to the XMPP <status/>; element.
|
||||
</desc>
|
||||
<status>optional</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>nick</name>
|
||||
<desc>A friendly or informal name for the user.</desc>
|
||||
<status>recommended</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>node</name>
|
||||
<desc>
|
||||
A unique identifier for the application; the value of this record MUST
|
||||
|
|
@ -579,9 +597,9 @@ _presence._tcp.local. IN NULL raw-binary-data-here
|
|||
in the 'node' attribute specified in Entity Capabilities (XEP-0115).
|
||||
</desc>
|
||||
<status>recommended</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>phsh</name>
|
||||
<desc>
|
||||
The SHA-1 hash of the user's avatar icon or photo. This SHOULD be
|
||||
|
|
@ -593,22 +611,22 @@ _presence._tcp.local. IN NULL raw-binary-data-here
|
|||
expiring avatar icons.
|
||||
</desc>
|
||||
<status>optional</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>port.p2pj</name>
|
||||
<desc>
|
||||
The port for serverless communication. 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
|
||||
via SRV lookups and MUST ignore the value of this parameter. However,
|
||||
clients SHOULD advertise this parameter if it is important to ensure
|
||||
backwards-compatibility with some existing implementations. (Note: In
|
||||
some existing implementations this value was hardcoded to "5298".)
|
||||
</desc>
|
||||
<status>deprecated</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>status</name>
|
||||
<desc>
|
||||
The presence availability of the user. Allowable values are "avail",
|
||||
|
|
@ -618,19 +636,19 @@ _presence._tcp.local. IN NULL raw-binary-data-here
|
|||
be assumed to be "avail".
|
||||
</desc>
|
||||
<status>recommended</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>txtvers</name>
|
||||
<desc>
|
||||
The version of the TXT records supported by the client. For backwards
|
||||
compatibility this is hardcoded at "1". This TXT record SHOULD be the
|
||||
The version of the TXT record supported by the client. For backwards
|
||||
compatibility this is hardcoded at "1". This parameter SHOULD be the
|
||||
first one provided, in accordance with the DNS-SD specification.
|
||||
</desc>
|
||||
<status>deprecated</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>vc</name>
|
||||
<desc>
|
||||
A flag advertising the user's ability to engage in audio or video
|
||||
|
|
@ -643,13 +661,13 @@ _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 records for more robust capabilities discovery as described
|
||||
and ext parameters for more robust capabilities discovery as described
|
||||
in the Discovering Capabilities section of XEP-0174.
|
||||
</desc>
|
||||
<status>optional</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
<record>
|
||||
<param>
|
||||
<name>ver</name>
|
||||
<desc>
|
||||
A hashed string that defines the XMPP service discovery (XEP-0030)
|
||||
|
|
@ -659,7 +677,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
|
|||
the 'ver' attribute specified in Entity Capabilities (XEP-0115).
|
||||
</desc>
|
||||
<status>recommended</status>
|
||||
</record>
|
||||
</param>
|
||||
|
||||
]]></code>
|
||||
</section3>
|
||||
|
|
|
|||
Loading…
Reference in New Issue