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

Fixed two typos (#505)

Browse Source 
I assume this doesn't warrant a new revision section, correct?

* Add new version number (for the previous change).

* Remove whitespace.

* Update xep-0001.xml
This commit is contained in:
JC Brand 2017-09-04 10:53:02 +02:00 committed by GitHub
parent 895f59cc7e
commit 40afc22f0c
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
xep-0001.xml
View File

@ -219,7 +219,7 @@
</section1>
<section1 topic='XEP Types' anchor='types'>
<p>The five XEP types are described in the following sections.</p>
<p>The approving body for all Standards Track, Informational, and Historical XEPs is the XMPP Council; the approving body for Humorous XEPs in the XMPP Extensions Editor; and the approving body for Procedural XEPs may be either the &BOARD; or the XMPP Council.</p>
<p>The approving body for all Standards Track, Informational, and Historical XEPs is the XMPP Council; the approving body for Humorous XEPs is the XMPP Extensions Editor; and the approving body for Procedural XEPs may be either the &BOARD; or the XMPP Council.</p>
<p>This document focuses primarily on Standards Track XEPs since they are the vehicle for defining new protocols, but also discusses the other XEP types.</p>
<section2 topic='Standards Track' anchor='types-Standards-Track'>
<p>A <span class='ref'>Standards Track XEP</span> defines one of the following:</p>
@ -406,7 +406,7 @@ Experimental ----> Proposed ----> Active
<p>Every XMPP Extension Protocol specification must contain a section entitled "Security Considerations", detailing security concerns or features related to the proposal; in particular, a Standards Track XEP should list the security threats that the protocol addresses and does not address, as well as security issues related to implementation of the protocol and deployment of such implementations. XEP authors should refer to &rfc3552; for helpful information about documenting security considerations and should also confer with the XMPP Extensions Editor and/or XMPP Council regarding this important task.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>Some XMPP Extension Protocols may require interaction with &IANA;. The IANA acts as a clearinghouse to assign and coordinate the use of numerous Internet protocol parameters, such as MIME types and port numbers (e.g., the TCP ports 5222, 5269, and 5280 used by the XMPP developer community are registered with the IANA). Whether or not a XEP requires registration of parameters with the IANA, that fact must be noted and explained in a distinct section of the XEP entitled "IANA Considerations". Registration with the IANA must not occur until the registration has been approbved by the XMPP Council (e.g., by advancement of a XEP to a status of Draft or Active), and must be initiated by the XMPP Registrar in consultation with the XEP author, not by the XEP author directly with the IANA.</p>
<p>Some XMPP Extension Protocols may require interaction with &IANA;. The IANA acts as a clearinghouse to assign and coordinate the use of numerous Internet protocol parameters, such as MIME types and port numbers (e.g., the TCP ports 5222, 5269, and 5280 used by the XMPP developer community are registered with the IANA). Whether or not a XEP requires registration of parameters with the IANA, that fact must be noted and explained in a distinct section of the XEP entitled "IANA Considerations". Registration with the IANA must not occur until the registration has been approved by the XMPP Council (e.g., by advancement of a XEP to a status of Draft or Active), and must be initiated by the XMPP Registrar in consultation with the XEP author, not by the XEP author directly with the IANA.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; performs a function similar to the IANA, although limited to the XMPP developer community. It does so by reserving protocol namespaces and by uniquely assigning parameters for use in the context of XMPP protocols (for example, the categories and types used in &xep0030;).</p>