1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-22 23:58:51 -05:00

Merge remote-tracking branch 'upstream/master'

This commit is contained in:
Peter Saint-Andre 2015-07-14 09:24:30 -06:00
commit f91812620d
71 changed files with 157 additions and 15 deletions

0
all.shtml Executable file → Normal file
View File

0
editor.shtml Executable file → Normal file
View File

2
gen.py
View File

@ -325,7 +325,7 @@ def buildPDF( file, nr ):
def buildXEP( filename ):
nr = re.match("xep-(\d\d\d\d).xml", filename).group(1)
xepfilepath = getLatestXEPFilename("../", nr);
xepfilepath = getLatestXEPFilename("./", nr);
if not xepfilepath:
print "getLatestXEPContent (ERROR)"
return

0
inbox/calendaring.xml Executable file → Normal file
View File

0
inbox/decloak.xml Executable file → Normal file
View File

0
inbox/distributedmuc.xml Executable file → Normal file
View File

0
inbox/dna.xml Executable file → Normal file
View File

0
inbox/dsig-design.xml Executable file → Normal file
View File

0
inbox/forwarding-delivery.xml Executable file → Normal file
View File

0
inbox/incident-reporting.xml Executable file → Normal file
View File

0
inbox/instant-gaming.xml Executable file → Normal file
View File

0
inbox/jingle-ibb.xml Executable file → Normal file
View File

0
inbox/jingle-nodes.xml Executable file → Normal file
View File

0
inbox/jingle-rtp-codecs.xml Executable file → Normal file
View File

0
inbox/jingle-rtp-mti.xml Executable file → Normal file
View File

0
inbox/jingle-s5b.xml Executable file → Normal file
View File

0
inbox/jingle-xtls.xml Executable file → Normal file
View File

0
inbox/jingle-zrtp.xml Executable file → Normal file
View File

0
inbox/lop.xml Executable file → Normal file
View File

0
inbox/muji.xml Executable file → Normal file
View File

0
inbox/multi-user_gaming.xml Executable file → Normal file
View File

123
inbox/optimized-s2s.xml Normal file
View File

@ -0,0 +1,123 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Zero Handshake Server to Server Protocol</title>
<abstract>
This specification defines an approach for a pair of servers to eliminate initial handshakes and associated
data transfer when using the XMPP S2S Protocol. This approach may only be used with a priori agreement and configuration
of the two servers involved. This is of significant benefit in high latency environments.
</abstract>
<legal>
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2015 by the XMPP Standards Foundation (XSF).</copyright>
<permissions>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the &quot;Specification&quot;), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.</permissions>
<warranty>## NOTE WELL: This Specification is provided on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##</warranty>
<liability>In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.</liability>
<conformance>This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at &lt;<link url='http://xmpp.org/extensions/ipr-policy.shtml'>http://xmpp.org/extensions/ipr-policy.shtml</link>&gt; or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).</conformance>
</legal>
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Informational</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>RFC 6120</spec>
<spec>RCC 6121</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>X2X</shortname>
<author>
<firstname>Steve</firstname>
<surname>Kille</surname>
<email>steve.kille@isode.com</email>
<jid>steve.kille@isode.com</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2015-06-22</date>
<initials>sek</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>
This specification arose from work on deploying XMPP in high latency environments, with round trips of several second. Even with data transfer rates as low as 2400 bit per second, XMPP works well once connections are established as compressed messages are small and the protocols are fully asynchronous. However the combination of low data rate and high latency led to connection establishment times of several minutes. This was unworkable, particularly when connections were prone to failure.
</p>
<p>
The solution set out here is to eliminate all the initial handshaking and to start the S2S communication as if the handshaking had been correctly completed. This cannot be used for communication between an arbitrary pair of servers, as in general the negotiation associated with the handshaking is vital for correctly determining a variety of parameters for use in the connection. However, a pair of servers may operate by locally configuring information that would have been negotiated. This enables the pair of servers to eliminate initial handshaking and data exchange.
</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>
This specification can be considered as a profile for server to server XMPP communication, to enable XMPP deployment over high latency links. This profile MUST only be used where its use has been pre-agreed and configured for both participating servers.
</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<p>OPTIONAL.
</p>
<p> Sections without text to be removed prior to sending doc for XSF review.</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<p>STRONGLY RECOMMENDED.</p>
</section1>
<section1 topic='Business Rules' anchor='rules'>
<p>Typically a pair of XMPP servers connecting using this protocol will communicate with multiple domains (e.g., a base domain and a MUC domain). It is generally desirable to configure things so that all communications will share the same link, rather than establishing separate links for each domain. Two or more connections MAY be initiated from one server to the other but this is NOT RECOMMENDED. </p>
<p>
An XMPP server receiving messages over such a link should appropriately validate to and from elements of inbound messages. The rules for this SHOULD be controlled by an priori agreement. An inbound connection will generally be associated with several peer domains. A RECOMMENDED approach is to consider each of these peers in turn and validate in the manner of a peer XMPP server connected using RFC 6120 for that domain. In the event that an inbound message is not considered to be valid, it should be handled in a manner that this invalid message would be handled if it arrived over standard S2S.
</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic="General">
<p>
In simple terms, this can be considered as operation of RFC 6121 communication between a pair of XMPP servers without the preliminary negotiation done in RFC 6120. It might be considered that the start point is the
DONE box in Figure 3 of RFC 6120. The TCP connection is opened and messages start to flow. All configuration information, including choice of port is handled by a the a priori configuration.</p>
</section2>
<section2 topic="Connection Direction">
<p>
Connections may be opened by one server only or by either server. The choice is part of the a priori configured agreement. It is generally recommended to allow connections to be opened by either server. However policy or network constraints may require that the connection is initiated by one server only. When a server initiates a connection it MUST use this connection to send messages to the other server. The server opening a connection is responsible for closing it at the end of its use.
</p>
<p>
When a connection is opened by the peer server, the local server MAY use this connection to send messages or MAY open a connection. It is recommended that only a single connection is used in this scenario and so in many cases this protocol will proceed with a single TCP connection and messages flowing in both directions. In the event of both servers opening connections at the same time, both TCP connections SHOULD be used with messages sent on the connection opened by the message sender only.
</p>
</section2>
<section2 topic="Use of TLS">
<p>
This protocol MAY be deployed directly over TCP. This will often be appropriate for environments where network security is handled at IP or lower layers or where the system is operated in closed network environment.
</p>
<p>
This protocol may be deployed over TLS operating over TCP. If this is done, TLS client and or server X.509 based authentication may be used, with certificate validation achieved by PKI or simply pinning (configuring) a trusted certificate. This configuration and authentication is a part of the a priori configuration.
</p>
</section2>
</section1>
<section1 topic='Accessibility Considerations' anchor='access'>
<p>OPTIONAL.</p>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>OPTIONAL.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>
This protocol operates without the standard XMPP security negotiation. It is imperative that consideration is given to link security whenever this protocol is set up. In particular it is important to validate the source IP address and source IP port of inbound connections against the a priori configuration. This can be done directly by match of IP address or by use of reverse DNS lookup to identify the connecting server.
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>None.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>None.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>n/a.</p>
</section1>
<section1 topic="Acknowledgement">
<p>
Dave Cridland, Curtis King, Kevin Smith and Kurt Zeilenga worked out and validated the approach documented in this XEP.
</p>
</section1>
</xep>

0
inbox/outofband.xml Executable file → Normal file
View File

0
inbox/problem-reporting.xml Executable file → Normal file
View File

0
inbox/reputation.xml Executable file → Normal file
View File

0
inbox/server-rosters.xml Executable file → Normal file
View File

0
inbox/shared-bosh.xml Executable file → Normal file
View File

0
inbox/sic.xml Executable file → Normal file
View File

0
inbox/sift.xml Executable file → Normal file
View File

0
inbox/sox.xml Executable file → Normal file
View File

0
inbox/sxe.xml Executable file → Normal file
View File

0
inbox/thumbs.xml Executable file → Normal file
View File

0
inbox/tictactoe-mug.xml Executable file → Normal file
View File

0
inbox/tictactoe.xml Executable file → Normal file
View File

0
inbox/xtls.xml Executable file → Normal file
View File

0
index.shtml Executable file → Normal file
View File

0
ipr-policy.shtml Executable file → Normal file
View File

0
submit.shtml Executable file → Normal file
View File

0
xep-0016.xml Executable file → Normal file
View File

0
xep-0065.xml Executable file → Normal file
View File

0
xep-0068.xml Executable file → Normal file
View File

View File

@ -273,7 +273,7 @@
<p>Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of &rfc4790;.</p>
<ol start='1'>
<li>Initialize an empty string S.</li>
<li>Sort the service discovery identities <note>A registry of service discovery identities is located at &DISCOCATEGORIES;.</note> by category and then by type and then by xml:lang (if it exists), formatted as CATEGORY '/' [TYPE] '/' [LANG] '/' [NAME]. <note>The combination of category, type, and xml:lang forms a unique combination, so it is not necessary to also sort by name (the name merely provides some human-readable text associated with a category/type/lang).</note> Note that each slash is included even if the LANG or NAME is not included (in accordance with <cite>XEP-0030</cite>, the category and type MUST be included.</li>
<li>Sort the service discovery identities <note>A registry of service discovery identities is located at &DISCOCATEGORIES;.</note> by category and then by type and then by xml:lang (if it exists), formatted as CATEGORY '/' [TYPE] '/' [LANG] '/' [NAME]. <note>The combination of category, type, and xml:lang forms a unique combination, so it is not necessary to also sort by name (the name merely provides some human-readable text associated with a category/type/lang).</note> Note that each slash is included even if the LANG or NAME is not included (in accordance with <cite>XEP-0030</cite>, the category and type MUST be included).</li>
<li>For each identity, append the 'category/type/lang/name' to S, followed by the '&lt;' character.</li>
<li>Sort the supported service discovery features. <note>A registry of service discovery features is located at &DISCOFEATURES;.</note></li>
<li>For each feature, append the feature to S, followed by the '&lt;' character.</li>

0
xep-0138.xml Executable file → Normal file
View File

View File

@ -509,8 +509,8 @@
</ol>
<p>If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of <cite>XEP-0060</cite>).</p>
</section2>
<section2 topic='One Node Per Namespace' anchor='impl-onenode'>
<p>An earlier version of this document specified that there there could be only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there could be only one pubsub node for geolocation events, one node for tune events, and one node for mood events, etc.). However, this rule is now considered overly restrictive because some data formats can be used to encapsulate many different kinds of information; the usual example is Atom as defined in &rfc4287;, for which many extensions exist. Therefore, this document now does not specify that there is a one-to-one relationship between NodeIDs and payload namespaces.</p>
<section2 topic='One Node Per Namespace' anchor='approach-onenode'>
<p>An earlier version of this document specified that there could be only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there could be only one pubsub node for geolocation events, one node for tune events, and one node for mood events, etc.). However, this rule is now considered overly restrictive because some data formats can be used to encapsulate many different kinds of information; the usual example is Atom as defined in &rfc4287;, for which many extensions exist. Therefore, this document now does not specify that there is a one-to-one relationship between NodeIDs and payload namespaces.</p>
<p>A specification that defines a given payload format for use in PEP MUST specify whether there shall be only one node per namespace, or whether multiple NodeIDs for the same namespace are allowable.</p>
</section2>
</section1>

0
xep-0172.xml Executable file → Normal file
View File

2
xep-0176.xml Executable file → Normal file
View File

@ -364,7 +364,7 @@ INITIATOR RESPONDER
</tr>
<tr>
<td>generation</td>
<td>An index, starting at 0, that enables the parties to keep track of updates to the candidate throughout the life of the session. For details, see the <link url='#protocol-restart'>ICE Restarts</link> section of this document.</td>
<td>An index, starting at 0, that enables the parties to keep track of updates to the candidate throughout the life of the session. For details, see the <link url='#protocol-restarts'>ICE Restarts</link> section of this document.</td>
<td>extended name/value pair in a=candidate line</td>
<td>0</td>
</tr>

0
xep-0186.xml Executable file → Normal file
View File

0
xep-0198.xml Executable file → Normal file
View File

0
xep-0238.xml Executable file → Normal file
View File

0
xep-0239.xml Executable file → Normal file
View File

View File

@ -24,8 +24,13 @@
<spec>XEP-0115</spec>
<spec>XEP-0191</spec>
</dependencies>
<supersedes/>
<supersededby/>
<supersedes>
<spec>XEP-0211</spec>
<spec>XEP-0213</spec>
</supersedes>
<supersededby>
<spec>XEP-0270</spec>
</supersededby>
<shortname>N/A</shortname>
&stpeter;
<revision>

View File

@ -21,13 +21,17 @@
<spec>XEP-0045</spec>
<spec>XEP-0054</spec>
<spec>XEP-0124</spec>
<spec>XEP-0138</spec>
<spec>XEP-0163</spec>
<spec>XEP-0191</spec>
<spec>XEP-0206</spec>
</dependencies>
<supersedes/>
<supersededby/>
<supersedes>
<spec>XEP-0212</spec>
<spec>XEP-0216</spec>
</supersedes>
<supersededby>
<spec>XEP-0270</spec>
</supersededby>
<shortname>N/A</shortname>
&stpeter;
<revision>

0
xep-0262.xml Executable file → Normal file
View File

0
xep-0267.xml Executable file → Normal file
View File

View File

@ -21,8 +21,10 @@
<spec>XEP-0045</spec>
<spec>XEP-0054</spec>
<spec>XEP-0114</spec>
<spec>XEP-0115</spec>
<spec>XEP-0124</spec>
<spec>XEP-0163</spec>
<spec>XEP-0178</spec>
<spec>XEP-0191</spec>
<spec>XEP-0206</spec>
</dependencies>

0
xep-0271.xml Executable file → Normal file
View File

0
xep-0272.xml Executable file → Normal file
View File

0
xep-0277.xml Executable file → Normal file
View File

0
xep-0278.xml Executable file → Normal file
View File

0
xep-0279.xml Executable file → Normal file
View File

0
xep-0284.xml Executable file → Normal file
View File

0
xep-0285.xml Executable file → Normal file
View File

0
xep-0286.xml Executable file → Normal file
View File

0
xep-0288.xml Executable file → Normal file
View File

0
xep-0300.xml Executable file → Normal file
View File

0
xep-0309.xml Executable file → Normal file
View File

0
xep-0312.xml Executable file → Normal file
View File

View File

@ -9,8 +9,8 @@
<title>Publishing Available Jingle Sessions</title>
<abstract>This specification defines an XMPP protocol extension that enables an XMPP entity to advertise the fact that it is willing accept a particular Jingle session request. The protocol is used mainly to inform other entities that a particular file is available for transfer via the Jingle File Transfer protocol defined in XEP-0234.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<number>0358</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
@ -25,6 +25,12 @@
&fippo;
&lance;
&stpeter;
<revision>
<version>0.1</version>
<date>2015-06-29</date>
<initials>XEP Editor (psa)</initials>
<remark><p>Initial published version approved by the XMPP Council.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2014-08-12</date>

View File

@ -1336,4 +1336,6 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates</link></span> <note>
<!ENTITY xep0353 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0353.html'>Jingle Message Initiation (XEP-0353)</link></span> <note>XEP-0353: Jingle Message Initiation &lt;<link url='http://xmpp.org/extensions/xep-0353.html'>http://xmpp.org/extensions/xep-0353.html</link>&gt;.</note>" >
<!ENTITY xep0354 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0354.html'>Customizable Message Routing (XEP-0354)</link></span> <note>XEP-0354: Customizable Message Routing &lt;<link url='http://xmpp.org/extensions/xep-0354.html'>http://xmpp.org/extensions/xep-0354.html</link>&gt;.</note>" >
<!ENTITY xep0355 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0355.html'>Namespace Delegation (XEP-0355)</link></span> <note>XEP-0355: Namespace Delegation &lt;<link url='http://xmpp.org/extensions/xep-0355.html'>http://xmpp.org/extensions/xep-0355.html</link>&gt;.</note>" >
<!ENTITY xep0356 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0355.html'>Privileged Entity (XEP-0356)</link></span> <note>XEP-0356: Privileged Entity &lt;<link url='http://xmpp.org/extensions/xep-0356.html'>http://xmpp.org/extensions/xep-0356.html</link>&gt;.</note>" >
<!ENTITY xep0356 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0356.html'>Privileged Entity (XEP-0356)</link></span> <note>XEP-0356: Privileged Entity &lt;<link url='http://xmpp.org/extensions/xep-0356.html'>http://xmpp.org/extensions/xep-0356.html</link>&gt;.</note>" >
<!ENTITY xep0357 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0357.html'>Push (XEP-0357)</link></span> <note>XEP-0357: Push &lt;<link url='http://xmpp.org/extensions/xep-0357.html'>http://xmpp.org/extensions/xep-0357.html</link>&gt;.</note>" >
<!ENTITY xep0358 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0358.html'>Publishing Available Jingle Sessions (XEP-0358)</link></span> <note>XEP-0358: Publishing Available Jingle Sessions &lt;<link url='http://xmpp.org/extensions/xep-0358.html'>http://xmpp.org/extensions/xep-0358.html</link>&gt;.</note>" >

0
xep2texml.xsl Executable file → Normal file
View File

View File

@ -50,7 +50,7 @@ class XEP:
def revisions(self):
repo = hg.repository(ui.ui(), self.BASEDIR)
fctx = repo.filectx('extensions/' + "xep-" + self.nr + ".xml", 'tip')
fctx = repo.filectx("xep-" + self.nr + ".xml", 'tip')
revs = []
for rev in fctx.filelog():
revs.append(fctx.filectx(rev).rev())
@ -59,7 +59,7 @@ class XEP:
def contentOfRevision(self, revision):
repo = hg.repository(ui.ui(), self.BASEDIR)
fctx = repo.filectx('extensions/' + "xep-" + self.nr + ".xml", revision)
fctx = repo.filectx("xep-" + self.nr + ".xml", revision)
# load content for that revision
file_text = fctx.data()