mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 08:45:04 -05:00
2013 copyright updates
This commit is contained in:
Peter Saint-Andre
parent
e67fdd3a39
commit
170b40f1a2
62
xep-0292.xml
62
xep-0292.xml
@ -118,7 +118,7 @@
|
||||
</header>
|
||||
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>Since 1999, the Jabber/XMPP community has used an interim, unofficial XML representation of vCard data for personal contacts, called &xep0054;. Recently, the IETF has upgraded vCard from vCard3 to vCard 4(&rfc6350;), and at the same time has defined an official XML format for vCard4 (&rfc6351;). This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format. Primarily this document defines the encapsulation method itself; secondarily it also defines transport methods and a mapping to the vcard-temp format for migration by clients and servers.</p>
|
||||
<p>Since 1999, the Jabber/XMPP community has used an interim, unofficial XML representation of vCard data for personal contacts, called &xep0054;. Recently, the IETF has upgraded vCard from vCard3 to vCard 4 (&rfc6350;), and at the same time has defined an official XML format for vCard4 (&rfc6351;). This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format. Primarily this document defines the encapsulation method itself; secondarily it also defines transport methods and a mapping to the vcard-temp format for migration by clients and servers.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
@ -165,7 +165,7 @@
|
||||
<n><surname>Saint-Andre</surname><given>Peter</given><middle></middle></n>
|
||||
<nickname><text>stpeter</text></nickname>
|
||||
<nickname><text>psa</text></nickname>
|
||||
<photo><uri>http://me.stpeter.im/images/stpeter_oscon.jpg</uri></photo>
|
||||
<photo><uri>https://stpeter.im/images/stpeter_oscon.jpg</uri></photo>
|
||||
<bday><date>1966-08-06</date></bday>
|
||||
<adr>
|
||||
<parameters>
|
||||
@ -183,9 +183,9 @@
|
||||
<parameters><type><text>home</text></type></parameters>
|
||||
<ext></ext>
|
||||
<street></street>
|
||||
<locality>Denver</locality>
|
||||
<locality>Parker</locality>
|
||||
<region>CO</region>
|
||||
<code>80210</code>
|
||||
<code>80138</code>
|
||||
<country>USA</country>
|
||||
</adr>
|
||||
<tel>
|
||||
@ -255,7 +255,7 @@
|
||||
]]></example>
|
||||
</section3>
|
||||
<section3 topic='Publication' anchor='self-iq-publication'>
|
||||
<p>An XMPP entity publishes or updates its vCard by sending an IQ-set to itself, containing a <vcard/> child element qualified by the 'urn:ietf:params:xml:ns:vcard-4.0' namespace. The publication request needs to include the entire vCard, not a "diff" against the prior data (if any).</p>
|
||||
<p>An XMPP entity publishes or updates its vCard by sending an IQ-set to itself (typically its bare JID), containing a <vcard/> child element qualified by the 'urn:ietf:params:xml:ns:vcard-4.0' namespace. The publication request needs to include the entire vCard, not a "diff" against the prior data (if any).</p>
|
||||
<example caption="vCard Publication Request"><![CDATA[
|
||||
<iq from='stpeter@jabber.org/squire
|
||||
id='h3vz319m'
|
||||
@ -287,12 +287,12 @@
|
||||
<p>Let us imagine that Juliet wishes to receive the updates that Romeo publishes to his vCard. She has two options:
|
||||
<ol>
|
||||
<li>Implicitly subscribe by advertising support for "urn:xmpp:vcard4+notify" in her &xep0115; data. Romeo's PEP service then automatically sends vCard updates to her when it receives presence from her, until and unless she sends presence of type unavailable or stops advertising an interest in vCard updates. This is in accordance with XEP-0060, section 6.1.</li>
|
||||
<li>Explicitly subscribe by sending a formal subscription request to the "urn:xmpp:vcard4" node at Romeo's JabberID. Romeo's PEP service may send her all vCard updates even if she is offline at the time (depending on service policies regarding presence integration).</li>
|
||||
<li>Explicitly subscribe by sending a formal subscription request to the "urn:xmpp:vcard4" node at Romeo's JabberID. Romeo's PEP service might send her all vCard updates even if she is offline at the time (depending on service policies regarding presence integration).</li>
|
||||
</ol>
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic='Receiving a vCard Notification'>
|
||||
<p>Because Juliet has sent presence to Romeo including Entity Capabilities data that includes the "urn:xmpp:vcard4+notify" feature, Romeo's XMPP server will send a PEP notification to Juliet. The notification can include an XMPP message body for backwards-compatibility with XMPP clients that are not pubsub-capable (see Message Body). This is in accordance with XEP-0060, second 6.1.7.</p>
|
||||
<p>Because Juliet has sent presence to Romeo including Entity Capabilities data that includes the "urn:xmpp:vcard4+notify" feature, Romeo's XMPP server will send a PEP notification to Juliet. The notification can include an XMPP message body for backward-compatibility with XMPP clients that are not pubsub-capable. This is in accordance with XEP-0060, second 6.1.7.</p>
|
||||
<example caption="Receiving a vCard publication/update"><![CDATA[
|
||||
<message from='romeo@montague.lit'
|
||||
to='juliet@capulet.lit'
|
||||
@ -304,7 +304,7 @@
|
||||
</event>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>Note: There is no payload, because this is a pure notification (the receiver needs to retrieve the vCard using an IQ-get as described earlier.</p>
|
||||
<p>Note: There is no payload, because this is a pure notification (the receiver needs to retrieve the vCard using an IQ-get as described earlier).</p>
|
||||
</section3>
|
||||
</section2>
|
||||
|
||||
@ -472,7 +472,7 @@
|
||||
</section1>
|
||||
|
||||
<section1 topic='vCards of Automated Entities' anchor='apps'>
|
||||
<p>Traditionally, vCards have been used on the XMPP network for entities other than human users, e.g. by XMPP servers and chatrooms. When such automated entities use vCards, it is RECOMMENDED to specify a value of "application" for the vCard4 KIND property &vcardapp;, as illustrated in the following example:</p>
|
||||
<p>Traditionally, vCards have been used on the XMPP network for entities other than human users, e.g. by XMPP servers and chatrooms. When such automated entities use vCards, it is RECOMMENDED to specify a value of "application" for the vCard4 KIND property &rfc6473;, as illustrated in the following example:</p>
|
||||
<example caption="vCard for a Thing"><![CDATA[
|
||||
<iq from='jabber.org'
|
||||
id='yhx51c35'
|
||||
@ -506,7 +506,7 @@
|
||||
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Well-Known Service Discovery Nodes' anchor='registrar-nodes'>
|
||||
<p>The ®ISTRAR; shall include 'urn:xmpp:contact' in its registry of Nodes for Service Discovery and Publish-Subscribe at &NODES;.</p>
|
||||
<p>The ®ISTRAR; shall include 'urn:xmpp:contact' and 'urn:xmpp:vcard4' in its registry of Nodes for Service Discovery and Publish-Subscribe at &NODES;.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
@ -560,7 +560,7 @@ property-key = element key {
|
||||
(value-uri | value-text)
|
||||
}
|
||||
]]></code>
|
||||
<p>The source of the spurious <TYPE/> and <CRED/> elements is unknown. Here we map the vcard-temp <CRED/> element to the vCard4 value-text construction.</p>
|
||||
<p>The source of the spurious <TYPE/> and <CRED/> elements is unknown. The vcard-temp <CRED/> element is mapped to the vCard4 value-text construction.</p>
|
||||
</section3>
|
||||
<section3 topic='SOUND' anchor='mapping-incorrect-sound'>
|
||||
<p>The DTD in <cite>XEP-0054</cite> provided this definition for the SOUND element:</p>
|
||||
@ -571,7 +571,7 @@ property-key = element key {
|
||||
<code><![CDATA[
|
||||
<!ELEMENT sound (extref | b64bin)>
|
||||
]]></code>
|
||||
<p>The source of the spurious <PHONETIC/> element is unknown. However, it does not exist in vCard4 and therefore is simply discarded when mapping.</p>
|
||||
<p>The source of the spurious vcard-temp <PHONETIC/> element is unknown. However, it does not exist in vCard4 and therefore is simply discarded when mapping. The vcard-temp <BINVAL/> element is mapped to the vCard4 b64bin construction and the vcard-temp <EXTVAL/> element is mapped to the vCard4 extref construction.</p>
|
||||
</section3>
|
||||
<section3 topic='VERSION' anchor='mapping-incorrect-version'>
|
||||
<p>As explained in <cite>XEP-0054</cite>, the <VERSION/> element from the final Dawson draft was not used in vcard-temp; instead, the vcard-temp protocol used a 'version' attribute (in fact the Dawson drafts were inconsistent, since the DTD defined a <VERSION/> element and the body of the specification used a 'version' attribute).</p>
|
||||
@ -592,7 +592,7 @@ property-key = element key {
|
||||
<p>In vCard3 and vcard-temp, the AGENT property was allowed to contain the inline vCard of someone who could act as an agent for the primary owner of the referenced vCard. In vCard4, inline vCards are disallowed. Therefore only pointers to external vCard objects are now allowed, by means of a URI.</p>
|
||||
</section3>
|
||||
<section3 topic='ORG' anchor='mapping-different-org'>
|
||||
<p>The ORGUNIT property was removed from vCard4, with the result that the ORGNAME property becomes the only value for an ORG.</p>
|
||||
<p>The ORGUNIT property was removed from vCard4, with the result that the ORGNAME property becomes the only child of ORG.</p>
|
||||
</section3>
|
||||
<section3 topic='SORT-STRING' anchor='mapping-different-sortstring'>
|
||||
<p>The SORT-STRING property from vCard3 was renamed to SORT-AS in vCard4.</p>
|
||||
@ -610,7 +610,7 @@ property-key = element key {
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic='Properties Defined Similarly in vcard-temp, vCard3, and vCard4' anchor='mapping-similar'>
|
||||
<p>The following properties are defined similarly in vcard-temp, vCard3, and vCard4, and the mappings are fairly straightforward (a future version of this document might provide more detailed narrative descriptions of the mappings).</p>
|
||||
<p>The following properties are defined similarly in vcard-temp, vCard3, and vCard4. The mappings are fairly straightforward (a future version of this document might provide more detailed narrative descriptions of the mappings).</p>
|
||||
<ul>
|
||||
<li>BDAY</li>
|
||||
<li>CATEGORIES</li>
|
||||
@ -655,7 +655,7 @@ property-key = element key {
|
||||
|
||||
<!--
|
||||
|
||||
Copyright (c) 1999 - 2011 XMPP Standards Foundation
|
||||
Copyright (c) 1999 - 2013 XMPP Standards Foundation
|
||||
|
||||
Permission is hereby granted, free of charge, to any
|
||||
person obtaining a copy of this software and
|
||||
@ -812,21 +812,25 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
but it was removed from vCard4 -->
|
||||
|
||||
<!-- one or more TZ elements can be included -->
|
||||
|
||||
<xsl:for-each select='/vCard/TZ'>
|
||||
<tz><text><xsl:value-of select='.'/></text></tz>
|
||||
</xsl:for-each>
|
||||
|
||||
<!-- one or more GEO elements can be included -->
|
||||
|
||||
<xsl:for-each select='/vCard/GEO'>
|
||||
<geo><uri><xsl:text>geo:</xsl:text><xsl:value-of select='LAT'/><xsl:text>,</xsl:text><xsl:value-of select='LON'/></uri></geo>
|
||||
</xsl:for-each>
|
||||
|
||||
<!-- one or more TITLE elements can be included -->
|
||||
|
||||
<xsl:for-each select='/vCard/TITLE'>
|
||||
<title><text><xsl:value-of select='.'/></text></title>
|
||||
</xsl:for-each>
|
||||
|
||||
<!-- one or more ROLE elements can be included -->
|
||||
|
||||
<xsl:for-each select='/vCard/ROLE'>
|
||||
<role><text><xsl:value-of select='.'/></text></role>
|
||||
</xsl:for-each>
|
||||
@ -834,6 +838,7 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
<!-- one or more LOGO elements can be included -->
|
||||
<!-- content is either a pointer to a URL or inline binary,
|
||||
which is mapped to a data: URI in vCard4 -->
|
||||
|
||||
<xsl:for-each select='/vCard/LOGO'>
|
||||
<xsl:variable name='LOGO.ext' select='count(EXTVAL)'/>
|
||||
<xsl:variable name='LOGO.type' select='TYPE'/>
|
||||
@ -905,6 +910,7 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
|
||||
<!-- one or more SORT-STRING elements can be included -->
|
||||
<!-- this element maps to SORT-AS in vCard4 -->
|
||||
|
||||
<xsl:for-each select='/vCard/SORT-STRING'>
|
||||
<sort-as><xsl:value-of select='.'/></sort-as>
|
||||
</xsl:for-each>
|
||||
@ -994,8 +1000,10 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
<adr>
|
||||
<xsl:variable name='HOME.count' select='count(HOME)'/>
|
||||
<xsl:variable name='WORK.count' select='count(WORK)'/>
|
||||
|
||||
<!-- NOTE: vcard-temp allowed address types of POSTAL, PARCEL,
|
||||
DOM, and INTL, but they were removed from vCard4 -->
|
||||
|
||||
<xsl:variable name='PREF.count' select='count(PREF)'/>
|
||||
<xsl:variable name='POBOX.count' select='count(POBOX)'/>
|
||||
<xsl:variable name='EXTADD.count' select='count(EXTADD)'/>
|
||||
@ -1003,11 +1011,17 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
<xsl:variable name='LOCALITY.count' select='count(LOCALITY)'/>
|
||||
<xsl:variable name='REGION.count' select='count(REGION)'/>
|
||||
<xsl:variable name='PCODE.count' select='count(PCODE)'/>
|
||||
|
||||
<!-- NOTE: yes, vcard-temp has CTRY, not COUNTRY -->
|
||||
|
||||
<xsl:variable name='CTRY.count' select='count(CTRY)'/>
|
||||
|
||||
<!-- first we count the number of vCard TYPE parameters -->
|
||||
|
||||
<xsl:variable name='TYPE.count' select='$HOME.count + $WORK.count'/>
|
||||
|
||||
<!-- now we output all the parameters -->
|
||||
|
||||
<xsl:if test='$TYPE.count > 0'>
|
||||
<parameters>
|
||||
<type>
|
||||
@ -1058,8 +1072,10 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
<xsl:variable name='VIDEO.count' select='count(VIDEO)'/>
|
||||
<xsl:variable name='PAGER.count' select='count(PAGER)'/>
|
||||
<xsl:variable name='TEXTPHONE.count' select='count(TEXTPHONE)'/>
|
||||
|
||||
<!-- NOTE: vcard-temp allowed telephony types of MSG, BBS,
|
||||
MODEM, ISDN, and PCS but they were removed from vCard4 -->
|
||||
|
||||
<xsl:variable name='PREF.count' select='count(PREF)'/>
|
||||
<xsl:variable name='NUMBER.count' select='count(NUMBER)'/>
|
||||
<!-- first we count the number of vCard TYPE parameters -->
|
||||
@ -1073,7 +1089,9 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
+ $VIDEO.count
|
||||
+ $PAGER.count
|
||||
+ $TEXTPHONE.count'/>
|
||||
|
||||
<!-- now we output all the parameters -->
|
||||
|
||||
<xsl:if test='$TYPE.count > 0'>
|
||||
<parameters>
|
||||
<type>
|
||||
@ -1120,13 +1138,19 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
<email>
|
||||
<xsl:variable name='HOME.count' select='count(HOME)'/>
|
||||
<xsl:variable name='WORK.count' select='count(WORK)'/>
|
||||
|
||||
<!-- NOTE: vcard-temp allowed email types of INTERNET
|
||||
and X400, but they were never in vCard3 -->
|
||||
|
||||
<xsl:variable name='PREF.count' select='count(PREF)'/>
|
||||
<xsl:variable name='USERID.count' select='count(USERID)'/>
|
||||
|
||||
<!-- first we count the number of vCard TYPE parameters -->
|
||||
|
||||
<xsl:variable name='TYPE.count' select='$HOME.count + $WORK.count'/>
|
||||
|
||||
<!-- now we output all the parameters -->
|
||||
|
||||
<xsl:if test='$TYPE.count > 0'>
|
||||
<parameters>
|
||||
<type>
|
||||
@ -1179,9 +1203,9 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
<HOME/>
|
||||
<EXTADD/>
|
||||
<STREET/>
|
||||
<LOCALITY>Denver</LOCALITY>
|
||||
<LOCALITY>Parker</LOCALITY>
|
||||
<REGION>CO</REGION>
|
||||
<PCODE>80210</PCODE>
|
||||
<PCODE>80138</PCODE>
|
||||
<CTRY>USA</CTRY>
|
||||
</ADR>
|
||||
<TEL><PREF/><WORK/><VOICE/><NUMBER>303-308-3282</NUMBER></TEL>
|
||||
@ -1372,9 +1396,9 @@ vg1b8xiNvBYs7KmcWkZMV+KlAloAn38KQv4WdVk2ugeCDCcVe9ARI3PE
|
||||
<parameters><type><text>home</text></type></parameters>
|
||||
<ext></ext>
|
||||
<street></street>
|
||||
<locality>Denver</locality>
|
||||
<locality>Parker</locality>
|
||||
<region>CO</region>
|
||||
<code>80210</code>
|
||||
<code>80138</code>
|
||||
<country>USA</country>
|
||||
</adr>
|
||||
<tel>
|
||||
|
||||
@ -9,7 +9,7 @@
|
||||
<title>XEP Template</title>
|
||||
<abstract>This specification provides an example of the format for XMPP Extension Protocols (XEPs).</abstract>
|
||||
<legal>
|
||||
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2012 by the XMPP Standards Foundation (XSF).</copyright>
|
||||
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2013 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 "Specification"), 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 "AS IS" 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>
|
||||
|
||||
7
xep.ent
7
xep.ent
@ -17,7 +17,7 @@
|
||||
|
||||
<!--
|
||||
|
||||
Copyright (c) 1999 - 2012 XMPP Standards Foundation
|
||||
Copyright (c) 1999 - 2013 XMPP Standards Foundation
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
@ -221,7 +221,7 @@ THE SOFTWARE.
|
||||
|
||||
<!ENTITY LEGALNOTICE "
|
||||
<legal>
|
||||
<copyright>This XMPP Extension Protocol is copyright © 1999 - 2012 by the <link url='http://xmpp.org/'>XMPP Standards Foundation</link> (XSF).</copyright>
|
||||
<copyright>This XMPP Extension Protocol is copyright © 1999 - 2013 by the <link url='http://xmpp.org/'>XMPP Standards Foundation</link> (XSF).</copyright>
|
||||
<permissions>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), 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 "AS IS" 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. ##</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 from, out of, or in connection with the Specification or the implementation, deployment, or other use of 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>
|
||||
@ -563,6 +563,7 @@ THE SOFTWARE.
|
||||
<!ENTITY rfc4571 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4571'>RFC 4571</link></span> <note>RFC 4571: Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport <<link url='http://tools.ietf.org/html/rfc4571'>http://tools.ietf.org/html/rfc4571</link>>.</note>" >
|
||||
<!ENTITY rfc4575 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4575'>RFC 4575</link></span> <note>RFC 4575: A Session Initiation Protocol (SIP) Event Package for Conference State <<link url='http://tools.ietf.org/html/rfc4575'>http://tools.ietf.org/html/rfc4575</link>>.</note>" >
|
||||
<!ENTITY rfc4585 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4585'>RFC 4585</link></span> <note>RFC 4585: Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) <<link url='http://tools.ietf.org/html/rfc4585'>http://tools.ietf.org/html/rfc4585</link>>.</note>" >
|
||||
<!ENTITY rfc4616 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4616'>RFC 4616</link></span> <note>RFC 4616: The PLAIN Simple Authentication and Security Layer (SASL) Mechanism <<link url='http://tools.ietf.org/html/rfc4616'>http://tools.ietf.org/html/rfc4616</link>>.</note>" >
|
||||
<!ENTITY rfc4622 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4622'>RFC 4622</link></span> <note>RFC 4622: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) <<link url='http://tools.ietf.org/html/rfc4622'>http://tools.ietf.org/html/rfc4622</link>>.</note>" >
|
||||
<!ENTITY rfc4627 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4627'>RFC 4627</link></span> <note>RFC 4627: The application/json Media Type for JavaScript Object Notation (JSON) <<link url='http://tools.ietf.org/html/rfc4627'>http://tools.ietf.org/html/rfc4627</link>>.</note>" >
|
||||
<!ENTITY rfc4646 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4646'>RFC 4646</link></span> <note>RFC 4646: Tags for Identifying Languages <<link url='http://tools.ietf.org/html/rfc4646'>http://tools.ietf.org/html/rfc4646</link>>.</note>" >
|
||||
@ -618,6 +619,7 @@ THE SOFTWARE.
|
||||
<!ENTITY rfc6331 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6331'>RFC 6331</link></span> <note>RFC 6331: Moving DIGEST-MD5 to Historic <<link url='http://tools.ietf.org/html/rfc6331'>http://tools.ietf.org/html/rfc6331</link>>.</note>" >
|
||||
<!ENTITY rfc6350 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6350'>RFC 6350</link></span> <note>RFC 6350: vCard Format Specification <<link url='http://tools.ietf.org/html/rfc6350'>http://tools.ietf.org/html/rfc6350</link>>.</note>" >
|
||||
<!ENTITY rfc6351 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6351'>RFC 6351</link></span> <note>RFC 6351: vCard XML Representation <<link url='http://tools.ietf.org/html/rfc6351'>http://tools.ietf.org/html/rfc6351</link>>.</note>" >
|
||||
<!ENTITY rfc6455 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6455'>RFC 6455</link></span> <note>RFC 6455: The WebSocket Protocol <<link url='http://tools.ietf.org/html/rfc6455'>http://tools.ietf.org/html/rfc6455</link>>.</note>" >
|
||||
<!ENTITY rfc6473 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6473'>RFC 6473</link></span> <note>RFC 6473: vCard KIND:application <<link url='http://tools.ietf.org/html/rfc6473'>http://tools.ietf.org/html/rfc6351</link>>.</note>" >
|
||||
<!ENTITY rfc6648 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6648'>RFC 6648</link></span> <note>RFC 6648: Deprecating the X- Prefix and Similar Constructs in Application Protocols <<link url='http://tools.ietf.org/html/rfc6648'>http://tools.ietf.org/html/rfc6648</link>>.</note>" >
|
||||
<!ENTITY rfc6716 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6716'>RFC 6716</link></span> <note>RFC 6716: Definition of the Opus Audio Codec <<link url='http://tools.ietf.org/html/rfc6716'>http://tools.ietf.org/html/rfc716</link>>.</note>" >
|
||||
@ -655,6 +657,7 @@ THE SOFTWARE.
|
||||
<!ENTITY sshx509 "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-secsh-x509'>X.509 Authentication in SSH2</link></span> <note>X.509 Authentication in SSH2 <<link url='http://tools.ietf.org/html/draft-ietf-secsh-x509'>http://tools.ietf.org/html/draft-ietf-secsh-x509</link>>. Work in progress.</note>" >
|
||||
<!ENTITY tcprobust "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure'>Improving TCP's Robustness to Blind In-Window Attacks</link></span> <note>Improving TCP's Robustness to Blind In-Window Attacks <<link url='http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure'>http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure</link>>. Work in progress.</note>" >
|
||||
<!ENTITY turn "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-behave-turn'>TURN</link></span> <note>Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) <<link url='http://tools.ietf.org/html/draft-ietf-behave-turn'>http://tools.ietf.org/html/draft-ietf-behave-turn</link>>. Work in progress.</note>" >
|
||||
<!ENTITY xmppoverwebsocket "<span class='ref'><link url='https://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket/'>XMPP Over WebSocket</link></span> <note>An XMPP Sub-protocol for WebSocket <<link url='https://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket/'>https://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket/</link>>. Work in progress.</note>" >
|
||||
|
||||
<!-- IANA registries -->
|
||||
|
||||
|
||||
4
xep.xsl
4
xep.xsl
@ -2,7 +2,7 @@
|
||||
|
||||
<!--
|
||||
|
||||
Copyright (c) 1999 - 2012 XMPP Standards Foundation
|
||||
Copyright (c) 1999 - 2013 XMPP Standards Foundation
|
||||
|
||||
Permission is hereby granted, free of charge, to any
|
||||
person obtaining a copy of this software and
|
||||
@ -126,7 +126,7 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
</xsl:if>
|
||||
<tr valign='top'>
|
||||
<td><strong>Copyright:</strong></td>
|
||||
<td>© 1999 - 2012 XMPP Standards Foundation. <a href='#appendix-legal'>SEE LEGAL NOTICES</a>.</td>
|
||||
<td>© 1999 - 2013 XMPP Standards Foundation. <a href='#appendix-legal'>SEE LEGAL NOTICES</a>.</td>
|
||||
</tr>
|
||||
<tr valign='top'>
|
||||
<td><strong>Status:</strong></td>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user