Content Rating Labels

%ents; ]>

Content Rating Labels 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. &LEGALNOTICE; 0456 Experimental Standards Track Standards Council crl Jonas Schäfer jonas@zombofant.net jonas@zombofant.net 0.2.0 2021-03-28 jsc Describe the conversion algorithm. 0.1.0 2021-03-28 XEP Editor (jsc) Accepted by vote of Council on 2021-03-10. 0.0.1 2021-03-03 jsc

First draft.

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.

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;.

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

This idea is not new. The W3C for instance has had two initiatives revolving around labelling content for the web. The Platform for Internet Content Selection (PICS) has been superseded by the Protocol for Web Description Resources (POWDER).

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.

&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.

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

Extensibility: The protocol must allow for custom labels in both federated and non-federated contexts.
Flexibility: 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.
Machine readability: 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.
Interoperability: Applications should be able to make an approximate choice even if the label set contains labels which are not known to it.

Content Label: A free-form string qualified by a type URI.

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.

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

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

type-defined string format]]>

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

The type URI must be URL-encoded, escaping all whitespace.

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

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

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 structure described above is converted to a simple text-based form.

Each <simple-label/> element is converted to a line of text. The line is composed of the value of the type attribute of the element, followed by a single space character (U+0020), followed by the character data of the element.

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

urn:xmpp:crl:0 http://example.com/content-ratings type-defined string format ]]>

Each line in the text-multi field corresponds to a converted <simple-label/> element as described above.

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.

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

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.

REQUIRED.

REQUIRED for protocol specifications.