moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

0.12

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@699 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-03-26 21:17:25 +00:00
parent 719ae788a6
commit a760236d3f
1 changed files with 156 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

223
xep-0174.xml
View File

@ -25,11 +25,17 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>0.12</version>
<date>2007-03-26</date>
<initials>psa</initials>
<remark><p>Specified creation of registry for TXT records.</p></remark>
</revision>
<revision>
<version>0.11</version>
<date>2007-03-14</date>
<initials>psa</initials>
<remark><p>Added section on capabilities discovery; added TXT fields corresponding to the node, ver, and ext attributes from XEP-0115; changed textvers value to 2.</p></remark>
<remark><p>Added section on capabilities discovery; added TXT records corresponding to the node, ver, and ext attributes from XEP-0115; changed textvers value to 2.</p></remark>
</revision>
<revision>
<version>0.10</version>
@ -200,70 +206,9 @@ psa IN TXT "ver=524"
<p>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".</p>
<p>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.</p>
<section2 topic='TXT Records' anchor='txt'>
<p>DNS-SD enables service definitions to include various TXT keys that specify parameters to be used in the context of the service type. The TXT keys defined for the _presence._tcp service are as follows:</p>
<table caption='TXT Records'>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
<tr>
<td>1st</td>
<td>The given or first name of the user.</td>
</tr>
<tr>
<td>email</td>
<td>The email address of the user.</td>
</tr>
<tr>
<td>ext</td>
<td>A space-separated list of extensions; the value of this field MUST be the same as that provided via normal XMPP presence (if applicable) in the 'ext' attribute specified in <cite>XEP-0115</cite>; for details, refer to the <link url='#disco'>Capabilities Discovery</link> section of this document.</td>
</tr>
<tr>
<td>jid</td>
<td>The Jabber ID of the user.</td>
</tr>
<tr>
<td>last</td>
<td>The family or last name of the user.</td>
</tr>
<tr>
<td>msg</td>
<td>Natural-language text describing the user's state. This is equivalent to the XMPP &STATUS; element.</td>
</tr>
<tr>
<td>nick</td>
<td>A friendly or informal name for the user.</td>
</tr>
<tr>
<td>node</td>
<td>A unique identifier for the application; the value of this field MUST be the same as that provided via normal XMPP presence (if applicable) in the 'node' attribute specified in <cite>XEP-0115</cite>; for details, refer to the <link url='#disco'>Capabilities Discovery</link> section of this document.</td>
</tr>
<tr>
<td>phsh</td>
<td>The SHA-1 hash of the user's avatar icon or photo. <note>The client should keep a local cache of icons keyed by hash. If the phsh value is not in the cache, the client should fetch the unknown icon and then cache it. Implementations should also include logic for expiring avatar icons.</note> This SHOULD be requested using mDNS in unicast mode by sending a DNS query to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent FF02::FB).</td>
</tr>
<tr>
<td>port.p2pj</td>
<td>The (hardcoded) port for link-local communications. Clients MUST use the port discovered via SRV lookups and MUST ignore the value of this TXT field, which is included only for backwards-compatibility with some older, existing implementations.</td>
</tr>
<tr>
<td>status</td>
<td>The presence availability of the user. Allowable values are "avail", "away", and "dnd", which map to mere XMPP presence (the user is available) and the XMPP &SHOW; values of "away" and "dnd", respectively.</td>
</tr>
<tr>
<td>txtvers</td>
<td>The version of the TXT fields supported by the client. This document describes txtvers "2". <note>Version 1 did not include the ext, nick, node, and ver TXT fields.</note></td>
</tr>
<tr>
<td>vc</td>
<td>A flag advertising the user's ability to engage in audio or video conferencing. If the user is able to engage in audio conferencing, the string MUST include the "A" character. If the user is able to engage in video conferencing, the string MUST include the "V" character. If the user is able to engage in conferencing with more than one participant, the string MUST include the "C" character. If the user is not currently engaged in an audio or video conference, the string MUST include the "!" character. The order of characters in the string is immaterial. NOTE: This flag is included for backwards-compatibility only; implementations SHOULD use the node, ver, and ext keys for more robust capabilities discovery as described in the <link url='#disco'>Capabilities Discovery</link> section of this document.</td>
</tr>
<tr>
<td>ver</td>
<td>The application version; the value of this field MUST be the same as that provided via normal XMPP presence (if applicable) in the 'ver' attribute specified in <cite>XEP-0115</cite>; for details, refer to the <link url='#disco'>Capabilities Discovery</link> section of this document.</td>
</tr>
</table>
<p>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 <link url='#security'>Security Considerations</link> 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).</p>
<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 &REGISTRAR; shall maintain 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 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.</p>
<p>Note: See the <link url='#security'>Security Considerations</link> 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).</p>
</section2>
</section1>
<section1 topic='Discovering Other Users' anchor='disco'>
@ -273,7 +218,7 @@ psa IN TXT "ver=524"
<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 local entities. Recommended rates for sending updates can be found in <cite>Multicast DNS</cite>.</p>
</section1>
<section1 topic='Capabilities Discovery' anchor='disco'>
<p>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 <cite>XEP-0115</cite>.</p>
<p>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 <cite>XEP-0115</cite>.</p>
</section1>
<section1 topic='Establishing XML Streams' anchor='streams'>
<p>In order to exchange link-local messages, the sender and recipient MUST first establish XML streams between themselves, as is familiar from <cite>RFC 3920</cite>.</p>
@ -366,7 +311,151 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<p>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.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
<section2 topic='Link-Local TXT Records Registry' anchor='registrar-linklocal'>
<p>The XMPP Registrar shall maintain a registry of TXT records advertised in the context of link-local messaging.</p>
<section3 topic='Registration Process' anchor='registrar-linklocal-process'>
&REGPROCESS;
<code><![CDATA[
<record>
<name>the attribute name of the TXT record</name>
<desc>a natural-language description of the record</desc>
<status>the requirements status of the record; should be one of:
required, recommended, optional, deprecated, obsolete
</status>
</record>
]]></code>
<p>The registrant may register more than one TXT record at a time, each contained in a separate &lt;record/&gt; element.</p>
</section3>
<section3 topic='Initial Registration' anchor='registrar-linklocal-reg'>
<p>The following submission registers TXT records in use as of March 2007. Refer to the registry itself for a complete and current list of TXT records.</p>
<code><![CDATA[
<record>
<name>1st</name>
<desc>The given or first name of the user.</desc>
<status>optional</status>
</record>
<record>
<name>email</name>
<desc>The email address of the user.</desc>
<status>optional</status>
</record>
<record>
<name>ext</name>
<desc>
A space-separated list of extensions; the value of this record MUST
be the same as that provided via normal XMPP presence (if applicable)
in the 'ext' attribute specified in XEP-0115; for details, refer to
the Capabilities Discovery section of XEP-0174.
</desc>
<status>recommended</status>
</record>
<record>
<name>jid</name>
<desc>The Jabber ID of the user.</desc>
<status>recommended</status>
</record>
<record>
<name>last</name>
<desc>The family or last name of the user.</desc>
<status>optional</status>
</record>
<record>
<name>msg</name>
<desc>
Natural-language text describing the user's state. This is
equivalent to the XMPP &lt;status/&gt;; element.
</desc>
<status>optional</status>
</record>
<record>
<name>nick</name>
<desc>A friendly or informal name for the user.</desc>
<status>recommended</status>
</record>
<record>
<name>node</name>
<desc>
A unique identifier for the application; the value of this record MUST
be the same as that provided via normal XMPP presence (if applicable)
in the 'node' attribute specified in XEP-0115; for details, refer to
the Capabilities Discovery section of XEP-0174.
</desc>
<status>recommended</status>
</record>
<record>
<name>phsh</name>
<desc>
The SHA-1 hash of the user's avatar icon or photo. This SHOULD be
requested using mDNS in unicast mode by sending a DNS query to the
mDNS multicast address (224.0.0.251 or its IPv6 equivalent FF02::FB).
The client should keep a local cache of icons keyed by hash. If the
phsh value is not in the cache, the client should fetch the unknown
icon and then cache it. Implementations should also include logic for
expiring avatar icons.
</desc>
<status>optional</status>
</record>
<record>
<name>port.p2pj</name>
<desc>
The (hardcoded) port for link-local communications. Clients MUST use the
port discovered via SRV lookups and MUST ignore the value of this TXT
record, which is included only for backwards-compatibility with some
older, existing implementations.
</desc>
<status>deprecated</status>
</record>
<record>
<name>status</name>
<desc>
The presence availability of the user. Allowable values are "avail", "away",
and "dnd", which map to mere XMPP presence (the user is available) and the
XMPP &lt;show/&gt; values of "away" and "dnd", respectively; if the status
record is not included, the status should be assumed to be "avail".
</desc>
<status>recommended</status>
</record>
<record>
<name>txtvers</name>
<desc>
The version of the TXT records supported by the client. For backwards
compatibility this is hardcoded at "1".
</desc>
<status>deprecated</status>
</record>
<record>
<name>vc</name>
<desc>
A flag advertising the user's ability to engage in audio or video
conferencing. If the user is able to engage in audio conferencing,
the string MUST include the "A" character. If the user is able to
engage in video conferencing, the string MUST include the "V"
character. If the user is able to engage in conferencing with more
than one participant, the string MUST include the "C" character. If
the user is not currently engaged in an audio or video conference,
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.
</desc>
<status>optional</status>
</record>
<record>
<name>ver</name>
<desc>
The application version; the value of this record MUST be the same as that
provided via normal XMPP presence (if applicable) in the 'ver' attribute
specified in XEP-0115; for details, refer to the Capabilities Discovery
section of XEP-0174.
</desc>
<status>recommended</status>
</record>
]]></code>
</section3>
</section2>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Jens Alfke, Justin Karneges, Marc Krochmal, and Sjoerd Simons for their input.</p>