mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-23 16:18:51 -05:00
194 lines
7.9 KiB
XML
194 lines
7.9 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>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><securitylabel/></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><simple-label/></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><simple-label/></tt> element. The character data of the
|
|
<tt><simple-label/></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><content-rating/></tt> XML element qualified
|
|
by the <tt>urn:xmpp:crl:0</tt> namespace. It carries zero or more <tt><simple-label/></tt>
|
|
child elements as described above.</p>
|
|
|
|
<p>Future extensions MAY specify other child elements for <tt><content-rating/></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><simple-label/></tt> element. The <tt>key</tt> is followed by a single
|
|
space character (U+0020), followed by the character data of the
|
|
<tt><simple-label/></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><content-rating/></tt>. Depending on the level of certainty required in
|
|
interpreting a <tt><content-rating/></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>
|
|
|