mirror of https://github.com/moparisthebest/xeps
0.13
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@703 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
5f2609ae8a
commit
eedd5d55c9
42
xep-0174.xml
42
xep-0174.xml
|
|
@ -25,6 +25,12 @@
|
|||
<supersededby/>
|
||||
<shortname>N/A</shortname>
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>0.13</version>
|
||||
<date>2007-03-28</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Clarified handling of stream version.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.12</version>
|
||||
<date>2007-03-26</date>
|
||||
|
|
@ -207,8 +213,8 @@ psa IN TXT "ver=524"
|
|||
<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 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 <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>
|
||||
<p>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.</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" records).</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Discovering Other Users' anchor='disco'>
|
||||
|
|
@ -221,24 +227,27 @@ psa IN TXT "ver=524"
|
|||
<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>
|
||||
<p>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:</p>
|
||||
<p>In order to exchange link-local messages, the initiator and recipient MUST first establish XML streams between themselves, as is familiar from <cite>RFC 3920</cite>.</p>
|
||||
<p>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:</p>
|
||||
<example caption="Opening a Stream"><![CDATA[
|
||||
<stream:stream
|
||||
xmlns='jabber:client'
|
||||
xmlns:stream='http://etherx.jabber.org/streams'
|
||||
from='stpeter@roundabout'
|
||||
to='hildjj@wolfram'>
|
||||
to='hildjj@wolfram'
|
||||
version='1.0'>
|
||||
]]></example>
|
||||
<p>Note: If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in <cite>RFC 3920</cite>, then it SHOULD include the version='1.0' flag as shown in the previous example.</p>
|
||||
<p>The recipient then responds with a stream header as well:</p>
|
||||
<example caption="Stream Header Response"><![CDATA[
|
||||
<stream:stream
|
||||
xmlns='jabber:client'
|
||||
xmlns:stream='http://etherx.jabber.org/streams'>
|
||||
from='hildjj@wolfram'
|
||||
to='stpeter@roundabout'>
|
||||
to='stpeter@roundabout'
|
||||
version='1.0'>
|
||||
]]></example>
|
||||
<p>The recipient SHOULD also send stream features as specified in <cite>RFC 3920</cite>:</p>
|
||||
<p>If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in <cite>RFC 3920</cite>:</p>
|
||||
<example caption="Recipient Sends Stream Features"><![CDATA[
|
||||
<stream:features>
|
||||
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
|
||||
|
|
@ -308,7 +317,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
|
|||
</section2>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<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>
|
||||
<p>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.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Link-Local TXT Records Registry' anchor='registrar-linklocal'>
|
||||
|
|
@ -317,10 +326,15 @@ _presence._tcp.local. IN NULL raw-binary-data-here
|
|||
®PROCESS;
|
||||
<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
|
||||
<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>
|
||||
|
|
@ -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.
|
||||
</desc>
|
||||
<status>optional</status>
|
||||
</record>
|
||||
|
|
|
|||
Loading…
Reference in New Issue