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

1.2pre1

Browse Source
This commit is contained in:
stpeter 2011-10-18 15:49:30 -06:00
parent 2a6bb9ba16
commit 24e446d0dd
1 changed files with 22 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
xep-0068.xml
View File

@ -23,6 +23,12 @@
<registry/>
&hildjj;
&stpeter;
<revision>
<version>1.2pre1</version>
<date>2011-10-18</date>
<initials>psa</initials>
<remark>Removed mandates about x- prefix.</remark>
</revision>
<revision>
<version>1.1</version>
<date>2004-07-07</date>
@ -83,23 +89,24 @@
<li>If the FORM_TYPE is used in the context of a custom protocol, it MAY be registered.</li>
</ol>
</section2>
<section2 topic='Naming Convention' anchor='approach-naming'>
<section2 topic='FORM_TYPE Names' anchor='approach-formtypes'>
<p>While the value of the FORM_TYPE attribute SHOULD be considered an opaque string from the application perspective, the following rules apply:</p>
<ol>
<li>For custom protocols, the name SHOULD be an HTTP URI that is managed by the namespace "owner".</li>
<li>For all new protocols approved by the XSF, the name MUST be an HTTP URI or IETF-style URN.</li>
<li>For custom protocols, the name SHOULD be an HTTP URI that is managed by the namespace owner (e.g., "http://example.com/foo").</li>
<li>For all new protocols approved by the XSF, the name MUST be a "urn:xmpp:*" URN in accordance with Section 4 of &xep0053;.</li>
<li>For "legacy" protocols managed by the XSF, the name SHOULD use the old-style "jabber:*:*" format.</li>
</ol>
</section2>
<section2 topic='Field Names' anchor='approach-fieldnames'>
<p>For FORM_TYPEs that are registered with the XMPP Registrar, the field names MUST conform to one of the following two conditions:</p>
<p>For FORM_TYPEs that are registered with the XMPP Registrar, the following rules apply:</p>
<ol>
<li>If the field name is defined by the relevant XEP or by registration, the field name MUST be registered with the XMPP Registrar and MAY have any name (except a name that begins with "x-"), subject to approval by the XMPP Registrar.</li>
<li>If the field name is unregistered, the field name MUST begin with "x-".</li>
<li>If the field name is defined by the XSF (i.e., in a XEP), the field name MUST be registered with the XMPP Registrar.</li>
<li>If the field name is defined outside the XSF, the field name MAY be registered with the XMPP Registrar.</li>
</ol>
<p>If the FORM_TYPE is not registered, the field name MAY have any name (presumably managed by the namespace "owner").</p>
<p>If the FORM_TYPE is not registered, the field MAY have any name (managed by the namespace owner).</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.</p>
</section2>
<section2 topic='Field Values' anchor='approach-values'>
<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>
</section2>
</section1>
@ -132,7 +139,7 @@
]]></example>
</section2>
<section2 topic='Correctly Specified FORM_TYPE' anchor='usecases-correct'>
<p>In the following example, the FORM_TYPE is 'http://jabber.org/protocol/pubsub', and all of the fields whose var names start with "pubsub#" would be registered with the XMPP Registrar, associated with that namespace.</p>
<p>In the following example, the FORM_TYPE is 'http://jabber.org/protocol/pubsub', all of the fields whose names start with "pubsub#" are registered with the XMPP Registrar (see &xep0060;), and the custom "time_restrictions" field defined by the organization at example.com uses &clark; in the field name.</p>
<example caption='Message with FORM_TYPE'><![CDATA[
<message to="node-owner" from="pubsub.jabber.org">
@ -151,7 +158,7 @@
label="Jabber ID of Subscriber">
<value>sub1@foo.com</value>
</field>
<field var="x-time_restrictions" type="text-multi"
<field var="{http://example.com/pubsub}time_restrictions" type="text-multi"
label="Limit to these time ranges">
<value>09:00-12:00</value>
<value>13:00-17:00</value>
@ -161,15 +168,15 @@
]]></example>
</section2>
<section2 topic='Incorrectly Specified FORM_TYPE' anchor='usecases-incorrect'>
<p>If the FORM_TYPE field is not hidden, it MUST be ignored as a
context indicator.</p>
<p>If the FORM_TYPE field is not hidden, it MUST be ignored as a context indicator.</p>
<example caption='Message with bad FORM_TYPE'><![CDATA[
<message to="juliet@capulet.com" from="romeo@montague.net/garden">
<x xmlns="jabber:x:data" type="form">
<title>Balcony Scene (Act 2, Scene 2)</title>
<instructions>But soft! What light through yonder window breaks?</instructions>
<!-- Not hidden. Treated as any other text-single field: -->
<!-- Not hidden. Treated as any other text-single field. -->
<field var="FORM_TYPE" type="text-single">
<value>http://jabber.org/protocol/shakespeare</value>
</field>
@ -179,34 +186,6 @@
<option label="Eyes">Stars</option>
</field>
</x>
</message>
]]></example>
</section2>
<section2 topic='Message with Bad Field' anchor='usecases-badfield'>
<p>When a FORM_TYPE is specified correctly, and an unknown field is found whose name does not start with "x-", a receiver MAY respond with an "Not Acceptable" error.</p>
<example caption='Message with bad field'><![CDATA[
<message to="juliet@capulet.com" from="romeo@montague.net/garden">
<x xmlns="jabber:x:data" type="form">
<title>Balcony Scene (Act 2, Scene 2)</title>
<instructions>But soft! What light through yonder window breaks?</instructions>
<field var="FORM_TYPE" type="hidden">
<value>http://jabber.org/protocol/shakespeare</value>
</field>
<field var="light" type="list-multi">
<option label="Juliet">Sun</option>
<option lable="Maid">Moon</option>
<option label="Eyes">Stars</option>
</field>
</x>
</message>
<message from="juliet@capulet.com" to="romeo@montague.net/garden" type="error">
<error code="406" type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
The field "light" is not acceptable.
</text>
</error>
</message>
]]></example>
</section2>
@ -317,16 +296,12 @@
<p>If the form is used in an IQ, the namespace of the &lt;query/&gt; element SHOULD match the base namespace of the FORM_TYPE. (One possible way of solving this problem would have been to reuse the &lt;query/&gt; tag from the IQ form of jabber:x:data within messages, but that would have meant that existing clients would not have been able to participate in these exchanges.)</p>
</section1>
<section1 topic='Error Codes' anchor='errors'>
<p>If the receiving entity believes that a specified field is invalid for the given FORM_TYPE, the receiver MAY respond to the sender with a "Not Acceptable" error; alternatively, the receiver MAY choose to ignore unknown fields.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Security-conscious programs that are using this approach should be careful to process only agreed-upon fields, with agreed-upon types, or "x-" fields that are understood by a particular implementation and a user of that implementation.</p>
<p>Security-conscious programs that are using this approach should be careful to process only agreed-upon fields with agreed-upon types.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA; for now. However, if this document is submitted to the IETF later, IANA should be used to standardize the field names rather than the XMPP Registrar.</p>
<p>This document requires no interaction with &IANA; for now.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>