xeps/inbox/content-ratings.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>Content Rating Labels</title>
<abstract>This specification provides a wire format in the form of a Service Discovery extension to allow services of various kinds to publish information about the kind of content they allow and/or endorse on their platform.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies/>
<supersedes/>
<supersededby/>
<shortname>crl</shortname>
<author>
<firstname>Jonas</firstname>
<surname>Schäfer</surname>
<email>jonas@zombofant.net</email>
<jid>jonas@zombofant.net</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2021-03-03</date>
<initials>jsc</initials>
<remark>
<p>First draft.</p>
</remark>
</revision>
</header>
<section1 anchor="intro" topic="Introduction">

<p>The more a communication system grows and increases its diversity, the more
likely it is that conflicts arise over which content is acceptable and which
is not. In addition, some content may be psychologically triggering or harmful
to different people or age groups, while the same content may be desirable to
share and talk about in other groups.</p>

<p>This specification intends to provide a machine-readable and extensible way of
conveying the kinds and classes of content which are acceptable, and hence to
be expected, on a service. Such a service can be an instant messaging account
server, a &xep0045; service or room, a &xep0369; service or channel or any
other entity which is able to publish extensions as per &xep0128;.</p>

<p>The content ratings are provided as a set of free-form strings, scoped by a
type URI.</p>

<section2 anchor="prior-art" topic="Prior Art">

<p>This idea is not new. The W3C for instance has had two initiatives revolving
around labelling content for the web. The
<link url='https://www.w3.org/PICS/'>Platform for Internet Content Selection (PICS)</link>
has been superseded by the
<link url='https://www.w3.org/2007/powder/'>Protocol for Web Description Resources (POWDER)</link>.</p>

<p>While the PICS approach is roughly similar to what this document intends to
achieve, the POWDER standard goes way beyond that and provides much more
extension points, at the cost of higher complexity.</p>

<p>&xep0258; provides a way to embed security labels in contexts where clearance
to view specific content is required. While the rating of content is roughly
similar, the XEP-0258 standard goes beyond that by placing restrictions
on entities which carry such labels in a way which is not desirable for this
standard.</p>

<p>Specifically, the document states that supporting implementations MUST NOT
allow the <tt>&lt;securitylabel/&gt;</tt> element outside of contexts of specifications
known to them, which could pose interoperability issues if that element was
reused for <em>this</em> specification.</p>

</section2></section1><section1 anchor="reqs" topic="Requirements">

<ul>
<li><strong>Extensibility:</strong> The protocol must allow for custom labels in both
federated and non-federated contexts.</li>
<li><strong>Flexibility:</strong> The protocol must allow for use in different contexts. It
must not be tied to &xep0045; services only, nor must it be restricted to
be applied to messages.</li>
<li><strong>Machine readability:</strong> All labels need to have a definition which can be
used in filtering or selection algorithms in order to remove/provide
specific kinds of content.</li>
<li><strong>Interoperability</strong>: Applications should be able to make an approximate
choice even if the label set contains labels which are not known to it.</li>
</ul>

</section1><section1 anchor="glossary" topic="Glossary">

<p>Content Label:
A free-form string qualified by a <tt>type</tt> URI.</p>

<p>Content Rating:
A set of Content Labels which describe the describes the classes of
content which may be encountered at the entity to which the rating
applies.</p>

</section1><section1 anchor="model" topic="Data Format">

<p>The Content Rating is conveyed using a set of free-form strings qualified
by a <tt>type</tt> attribute, the Content Labels.</p>

<p>A Content Label is represented by a single XML <tt>&lt;simple-label/&gt;</tt> element
qualified by the <tt>urn:xmpp:crl:0</tt> namespace:</p>

<example><![CDATA[<simple-label xmlns="urn:xmpp:crl:0" type="http://example.com/content-ratings">type-defined string format</simple-label>]]></example>

<p>The <tt>type</tt> attribute MUST be a URI. It defines the format of the CDATA
contained in the <tt>&lt;simple-label/&gt;</tt> element. The character data of the
<tt>&lt;simple-label/&gt;</tt> element MUST NOT contain control codes (including newline
and horizontal tab).</p>

<p>The <tt>type</tt> URI must be URL-encoded, escaping all whitespace.</p>

<p>A Content Rating is represented by a <tt>&lt;content-rating/&gt;</tt> XML element qualified
by the <tt>urn:xmpp:crl:0</tt> namespace. It carries zero or more <tt>&lt;simple-label/&gt;</tt>
child elements as described above.</p>

<p>Future extensions MAY specify other child elements for <tt>&lt;content-rating/&gt;</tt> in
separate namespaces. See the business rules for an approach for handling those
unexpected elements.</p>

<section2 anchor="plain-text" topic="Plain-text compatibility">

<p>If the format needs to be conveyed in plain text form, for example to carry
the list of labels in &xep0128; or a &xep0004; configuration form, the
following algorithm is to be applied:</p>

</section2></section1><section1 anchor="usecases" topic="Use Cases">

<section2 anchor="publish" topic="Publishing a Content Self-Rating in Service Discovery information">

<p>An entity may publish a content self-rating using &xep0128;. For this, a
&xep0004; form with the <tt>urn:xmpp:crl:0</tt> <tt>FORM_TYPE</tt> is defined.
All labels are mapped to a single <tt>text-multi</tt>.</p>

<example><![CDATA[<x type='result' xmlns='jabber:x:data'>
    <field var='FORM_TYPE'>
        <value>urn:xmpp:crl:0</value>
    </field>
    <field var='urn:xmpp:crl:0#simple-labels' type='text-multi'>
        <value>http://example.com/content-ratings type-defined string format</value>
    </field>
</x>]]></example>

<p>Each line in the <tt>text-multi</tt> field is prefixed with the <tt>key</tt> of the
corresponding <tt>&lt;simple-label/&gt;</tt> element. The <tt>key</tt> is followed by a single
space character (U+0020), followed by the character data of the
<tt>&lt;simple-label/&gt;</tt> element.</p>

</section2><section2 anchor="muc-config" topic="Offering configuration of the Self-Rating of a XEP-0045 Multi-User-Chat">

<p>Entities with sufficient permissions to modify &xep0045; room configuration
SHOULD be offered a text-multi form field of the format described above. If
offered this field MUST be mapped to the format described above in the
&xep0030; response of the room.</p>

</section2></section1><section1 anchor="rules" topic="Business Rules">

<ul>
<li>Implementations need to decide how to handle unknown child elements in
<tt>&lt;content-rating/&gt;</tt>. Depending on the level of certainty required in
interpreting a <tt>&lt;content-rating/&gt;</tt> element, implementations for example
choose to either silently ignore unknown elements or treat them as the worst
possible rating.</li>
</ul>

</section1><section1 anchor="i18n" topic="Internationalization Considerations">

<p>Implementations which convert the labels to human-readable strings need to
translate those strings. For now, no provision is made to provide
pre-translated texts.</p>

</section1><section1 anchor="security" topic="Security Considerations">

<p>REQUIRED.</p>

</section1><section1 anchor="iana" topic="IANA Considerations">

<p>REQUIRED.</p>

</section1><section1 anchor="registrar" topic="XMPP Registrar Considerations">

<p>REQUIRED.</p>

</section1><section1 anchor="schema" topic="XML Schema">

<p>REQUIRED for protocol specifications.</p>
</section1>
</xep>