mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-23 17:52:15 -05:00
ProtoXEP: Content Rating Labels
This commit is contained in:
Jonas Schäfer
parent
c5f8044bec
commit
7775f11d09
193
inbox/content-ratings.xml
Normal file
193
inbox/content-ratings.xml
Normal file
@ -0,0 +1,193 @@
|
||||
<?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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user