mirror of https://github.com/moparisthebest/xeps
Jonas Schäfer
2 years ago
1 changed files with 193 additions and 0 deletions
@ -0,0 +1,193 @@
@@ -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