From 40afc22f0c0aab26c4b3f52febaf0166f29266ff Mon Sep 17 00:00:00 2001 From: JC Brand Date: Mon, 4 Sep 2017 10:53:02 +0200 Subject: [PATCH] Fixed two typos (#505) 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 --- xep-0001.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0001.xml b/xep-0001.xml index 4b83834f..8679a331 100644 --- a/xep-0001.xml +++ b/xep-0001.xml @@ -219,7 +219,7 @@

The five XEP types are described in the following sections.

-

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.

+

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.

This document focuses primarily on Standards Track XEPs since they are the vehicle for defining new protocols, but also discusses the other XEP types.

A Standards Track XEP defines one of the following:

@@ -406,7 +406,7 @@ Experimental ----> Proposed ----> Active

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.

 -

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.

+

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.

The ®ISTRAR; 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;).