mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 08:45:04 -05:00
ede401924d
Preparation not Preperation (not "e" but "a")
265 lines
8.7 KiB
XML
265 lines
8.7 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||
%ents;
|
||
]>
|
||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||
<xep>
|
||
<header>
|
||
<title>JID Preparation and Validation Service</title>
|
||
<abstract>This specification defines a way for an XMPP entity to request another entity to prepare and validate a given JID.</abstract>
|
||
&LEGALNOTICE;
|
||
<number>0328</number>
|
||
<status>Experimental</status>
|
||
<type>Standards Track</type>
|
||
<sig>Standards</sig>
|
||
<dependencies>
|
||
<spec>XMPP Core</spec>
|
||
<spec>XMPP IM</spec>
|
||
<spec>XEP-0030</spec>
|
||
</dependencies>
|
||
<supersedes/>
|
||
<supersededby/>
|
||
<shortname>jid-prep</shortname>
|
||
<author>
|
||
<firstname>Lance</firstname>
|
||
<surname>Stout</surname>
|
||
<email>lance@lance.im</email>
|
||
<jid>lance@lance.im</jid>
|
||
</author>
|
||
&flow;
|
||
<revision>
|
||
<version>0.2</version>
|
||
<date>2019-09-09</date>
|
||
<initials>fs</initials>
|
||
<remark>
|
||
<ul>
|
||
<li>Do not return error IQ result if the string to validate is
|
||
not a valid JID. It is indistinguishable if the error is
|
||
caused by the string to check, or if some other involved JID,
|
||
like the one in the 'to' attribute, is malformed.</li>
|
||
<li>Return the normalized JID in its parts, to make it clear
|
||
which parts constitute the JID</li>
|
||
<li>Do not use text as child of an IQ child element. Using
|
||
text makes it impossible to inject further child elements as
|
||
XMPP disallows mixed content.</li>
|
||
<li>Add support for base64 encoding.</li>
|
||
<li>Always announce the jidprep identity.</li>
|
||
</ul>
|
||
</remark>
|
||
</revision>
|
||
<revision>
|
||
<version>0.1</version>
|
||
<date>2013-05-28</date>
|
||
<initials>psa</initials>
|
||
<remark><p>Initial published version approved by the XMPP Council.</p></remark>
|
||
</revision>
|
||
<revision>
|
||
<version>0.0.2</version>
|
||
<date>2013-05-21</date>
|
||
<initials>lance</initials>
|
||
<remark><p>Incorporated feedback.</p></remark>
|
||
</revision>
|
||
<revision>
|
||
<version>0.0.1</version>
|
||
<date>2013-05-08</date>
|
||
<initials>lance</initials>
|
||
<remark><p>Initial version.</p></remark>
|
||
</revision>
|
||
</header>
|
||
|
||
<section1 topic='Introduction' anchor='intro'>
|
||
|
||
<p>To accurately compare and match JIDs, a normalization step is
|
||
required by &rfc7622;. This normalization is split into two steps
|
||
called 'Preparation' and 'Enforcement' by &rfc8264; and maybe
|
||
resource-intensive. The protocol defined herein, called "JID Prep"
|
||
can be used to ask XMPP entities to perform such a
|
||
normalization. Amongst other use-cases, this protocol can be used
|
||
for testing purposes, where a test suite checks the conformance of
|
||
an normalization implementation of, e.g., an XMPP server
|
||
implementation.</p>
|
||
|
||
<p>Furthermore, in some environments, especially ones like IoT where
|
||
devices with constraint resources are used, a client may not have
|
||
access to the various Unicode and internationalization libraries
|
||
necessary to properly normalize a JID. For those situations, this
|
||
protocol can be used by a client to ask a server to normalize a JID
|
||
on its behalf.</p>
|
||
|
||
</section1>
|
||
|
||
<section1 topic='Discovering support' anchor='disco'>
|
||
|
||
<p>If a server supports JID Prep queries, it MUST specify the
|
||
'urn:xmpp:jidprep:1' feature in its service discovery information
|
||
features as specified in &xep0030;.</p>
|
||
|
||
<example caption='Server advertises support for JID prep queries'><![CDATA[
|
||
<iq type="result"
|
||
to="juliet@capulet.lit/balcony"
|
||
from="capulet.lit"
|
||
id="info1">
|
||
<query xmlns="http://jabber.org/protocol/disco#info">
|
||
<identity category="component" type="jidprep" />
|
||
...
|
||
<feature var="urn:xmpp:jidprep:1" />
|
||
</query>
|
||
</iq>]]></example>
|
||
|
||
</section1>
|
||
|
||
<section1 topic='Use Cases' anchor='usecases'>
|
||
|
||
<p>To request preparation and enforcement, and thus normalization
|
||
and validation, of a string to a JID, the client sends a JID Prep
|
||
request to the service. This request is an &IQ; of type 'get',
|
||
containing a <jid-validate-request/> element qualified by the
|
||
'urn:xmpp:jidprep:1' namespace. This element contains a
|
||
<maybe-jid/> child element whose textual content is the string
|
||
to normalize to and validate as JID.</p>
|
||
|
||
<example caption='JID prep request (valid JID)'><![CDATA[
|
||
<iq type='get'
|
||
from='user@example.org/resource'
|
||
to='example.org'
|
||
id='request1'>
|
||
<jid-validate-request xmlns='urn:xmpp:jidprep:1'>
|
||
<maybe-jid>Σ@example.com/resource</maybe-jid>
|
||
</jid-validate-request>
|
||
</iq>]]></example>
|
||
|
||
<p>If the given string can be enforced to a valid JID, then a
|
||
<jid-validate-result/> with a <valid-jid/> child
|
||
element is returned. This child element contains the normalized
|
||
JID parts. The valid-jid element MUST contain <domainpart/>
|
||
and may contain <localpart/> and/or <resourcepart/>
|
||
elements. If the JID does not contain a local- or resourcepart,
|
||
then the corresponding element is omitted. Those elements contain the
|
||
normalized, i.e., PRECIS enforced, strings of the own JID
|
||
parts.</p>
|
||
|
||
<example caption='Valid JID result'><![CDATA[
|
||
<iq type='result'
|
||
from='example.org'
|
||
to='user@example.org/resource'
|
||
id='request1'>
|
||
<jid-validate-result xmlns='urn:xmpp:jidprep:1'>
|
||
<valid-jid>
|
||
<localpart>σ</localpart>
|
||
<domainpart>example.com</domainpart>
|
||
<resourcepart>resource</resourcepart>
|
||
<valid-jid>
|
||
</jid-validate-result>
|
||
</iq>]]></example>
|
||
|
||
<p>If the service is given an invalid JID, a
|
||
<jid-validate-result/> IQ result response with an
|
||
<invalid-jid/> elmeent is returned.</p>
|
||
|
||
<example caption='JID Prep request (invalid JID)'><![CDATA[
|
||
<iq type='get'
|
||
from='user@example.org/resource'
|
||
to='example.org'
|
||
id='request2'>
|
||
<jid-validate-request xmlns='urn:xmpp:jidprep:1'>
|
||
<maybe-jid>henryⅣ@example.com</maybe-jid>
|
||
</jid-validate-request>
|
||
</iq>]]></example>
|
||
|
||
<example caption='Invalid JID result'><![CDATA[
|
||
<iq type='result'
|
||
from='example.org'
|
||
to='user@example.org/resource'
|
||
id='request2'>
|
||
<jid-validate-result xmlns='urn:xmpp:jidprep:1'>
|
||
<invalid-jid>
|
||
<reason>Invalid codepoint 'Ⅳ' in localpart.</reason>
|
||
</invalid-jid>
|
||
</jid-validate-result>
|
||
</iq>]]></example>
|
||
|
||
</section1>
|
||
|
||
<section1 topic='Optional Base64 Encoding' anchor='base64'>
|
||
|
||
<p>To be able to feed arbitrary strings into the validator, not
|
||
being limited by XML 1.0, the protocol supports an optional Base64
|
||
encoding of the string to validate. The requestor first encodes the
|
||
string to UTF-8, then encodes the UTF-8 byte-sequence using Base64
|
||
(&rfc4648; <link
|
||
url='https://tools.ietf.org/html/rfc4648#section-4'>§ 4</link>) and
|
||
places the result into an <base64-maybe-jid/> element. This
|
||
element is a put under the <jid-validate-base64-request/> IQ
|
||
child element qualified by the 'urn:xmpp:jidprep:1' namespace.</p>
|
||
|
||
<p>The IQ respones of the service are identical to the ones of the
|
||
non-Base64 case.</p>
|
||
|
||
<p>If supported, service announces 'urn:xmpp:jidprep:base64:1'
|
||
feature.</p>
|
||
|
||
<example caption='JID Prep request using Base64'><![CDATA[
|
||
<iq type='get'
|
||
from='user@example.org/resource'
|
||
to='example.org'
|
||
id='request1'>
|
||
<jid-validate-base64-request xmlns='urn:xmpp:jidprep:1'>
|
||
<base64-maybe-jid>zqNAZXhhbXBsZS5jb20vcmVzb3VyY2U=</base64-maybe-jid>
|
||
</jid-validate-base64-request>
|
||
</iq>]]></example>
|
||
|
||
</section1>
|
||
|
||
<section1 topic="Implementation Notes" anchor='impl'>
|
||
|
||
<p>If a client has the ability to perform the normalization process
|
||
itself, it SHOULD NOT make use of the protocol defined herein.</p>
|
||
|
||
<p>Upon a successful response, it is RECOMMENDED that the client
|
||
caches the result, mapping the original JID to the normalized
|
||
version.</p>
|
||
|
||
</section1>
|
||
|
||
<section1 topic='Security Considerations' anchor='security'>
|
||
|
||
<p>As the process for normalizing and validating a JID can be
|
||
resource intensive, there is a possibility for denial of service
|
||
attacks. A server MAY rate limit the number of requests to prevent
|
||
such attacks. Likewise, the server MAY restrict access to the
|
||
service torequests from users that are local to the server or
|
||
otherwhise trusted.</p>
|
||
|
||
</section1>
|
||
|
||
<section1 topic='IANA Considerations' anchor='iana'>
|
||
<p>This document requires no interaction with &IANA;.</p>
|
||
</section1>
|
||
|
||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||
|
||
<section2 topic='Protocol Namespaces' anchor='ns'>
|
||
|
||
<p>The ®ISTRAR; includes 'urn:xmpp:jidprep:1' in its registry of protocol namespaces (see &NAMESPACES;).</p>
|
||
|
||
<ul>
|
||
<li>urn:xmpp:jidprep:1</li>
|
||
</ul>
|
||
|
||
</section2>
|
||
|
||
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
|
||
&NSVER;
|
||
</section2>
|
||
|
||
</section1>
|
||
|
||
<section1 topic='XML Schema' anchor='schema'>
|
||
|
||
<p>TODO: Add once the XEP leaves the experimental state.</p>
|
||
|
||
</section1>
|
||
|
||
</xep>
|