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

RFC 6648

Browse Source
This commit is contained in:
Peter Saint-Andre 2012-06-25 11:46:07 -06:00
parent 5a9b58ee2b
commit eec77489c7
2 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0068.xml
View File

@ -103,7 +103,7 @@
<p>For FORM_TYPEs that are not registered with the XMPP Registrar, the field name SHALL follow the extension rules described below and the field typically will not be registered with the XMPP Registrar.</p>
<p>The "namespace" of a field is assumed to be inherited from the FORM_TYPE. When an organization or project defines a field that is used in the context of a FORM_TYPE it does not manage (e.g., a non-XSF field contained in a form whose FORM_TYPE is managed by the XSF, or a third-party field contained in a form whose FORM_TYPE is managed by some other organization), the name of the field MUST be namespaced using &clark;, where the universal name portion SHOULD be a URI controlled by the extending organization or project, e.g., a field name of "{http://example.com/pubsub}time_restrictions".</p>
<p>For reasons that are lost in the mists of time, some XMPP extension protocols produced by the XSF, such as &xep0045; and &xep0060;, prefix their field names with strings like "muc#" and "pubsub#". There is no good reason to apply that convention to new XSF extensions. Indeed, there is even no good reason to apply that convention to the names of new fields defined by the XSF for those existing XSF extensions; however, the practice is harmless for those existing extensions (since a string such as "{http://jabber.org/protocol/pubsub#subscribe_authorization}pubsub#subscriber_jid" can be considered equivalent to a string such as "pubsub#subscriber_jid"), and this document does not actively recommend deprecating the convention.</p>
<p class='box'>Note: Older versions of this specification mandated that unregistered field names had to begin with the prefix "x-". In accordance with &xdash;, that mandate has been removed. However, existing "x-" field names are acceptable and can be registered with the XMPP Registrar as described above.</p>
<p class='box'>Note: Older versions of this specification mandated that unregistered field names had to begin with the prefix "x-". In accordance with &rfc6648;, that mandate has been removed. However, existing "x-" field names are acceptable and can be registered with the XMPP Registrar as described above.</p>
</section2>
<section2 topic='Field Values' anchor='approach-fieldvalues'>
<p>Field values MAY also be registered; refer to the <link url='registrar'>XMPP Registrar</link> section of this document.</p>

2
xep.ent
View File

@ -618,6 +618,7 @@ THE SOFTWARE.
<!ENTITY rfc6350 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6350'>RFC 6350</link></span> <note>RFC 6350: vCard Format Specification &lt;<link url='http://tools.ietf.org/html/rfc6350'>http://tools.ietf.org/html/rfc6350</link>&gt;.</note>" >
<!ENTITY rfc6351 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6351'>RFC 6351</link></span> <note>RFC 6351: vCard XML Representation &lt;<link url='http://tools.ietf.org/html/rfc6351'>http://tools.ietf.org/html/rfc6351</link>&gt;.</note>" >
<!ENTITY rfc6473 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6473'>RFC 6473</link></span> <note>RFC 6473: vCard KIND:application &lt;<link url='http://tools.ietf.org/html/rfc6473'>http://tools.ietf.org/html/rfc6351</link>&gt;.</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 &lt;<link url='http://tools.ietf.org/html/rfc6648'>http://tools.ietf.org/html/rfc6351</link>&gt;.</note>" >
<!-- Internet-Drafts -->
@ -651,7 +652,6 @@ THE SOFTWARE.
<!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 &lt;<link url='http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure'>http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure</link>&gt;. 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) &lt;<link url='http://tools.ietf.org/html/draft-ietf-behave-turn'>http://tools.ietf.org/html/draft-ietf-behave-turn</link>&gt;. Work in progress.</note>" >
<!ENTITY vcardapp "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-vcarddav-kind-app'>vCard KIND:kind-app</link></span> <note>vCard KIND:application &lt;<link url='http://tools.ietf.org/html/draft-ietf-vcarddav-kind-app'>http://tools.ietf.org/html/draft-ietf-vcarddav-kind-app</link>&gt;. Work in progress.</note>" >
<!ENTITY xdash "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-appsawg-xdash'>Deprecating X-</link></span> <note>Deprecating the X- Prefix and Similar Constructs in Application Protocols &lt;<link url='http://tools.ietf.org/html/draft-ietf-appsawg-xdash'>http://tools.ietf.org/html/draft-ietf-appsawg-xdash</link>&gt;. Work in progress.</note>" >
<!-- IANA registries -->