A_26228, A_26228-01: Length limitation of annotations in reactions

[nikzen]

Anforderungen

A_26228 - Der TI-M FD MUSS sicherstellen, dass Events des Typs m.reaction, deren Wert des Attributes key im Event-Content in Events die Länge eines einzelnen Unicode-Characters bzw. dessen Code Point Repräsentation überschreitet, mit dem Response Code 400 und dem Error Code M_BAD_JSON abgewiesen werden.

A_26228-01 - Der TI-M FD MUSS sicherstellen, dass der Wert des Attributes key im Event-Content in Events des Typs m.reaction nur ein Emoji darstellt, sonst MUSS der Request mit dem Response Code 400 und dem Error Code M_BAD_JSON abgewiesen werden

Problem

Es gibt viele Emojis, wie "blauer Kasten", "Familie mit Kindern" etc, die durch diese Anforderung nicht mehr erlaubt werden, da diese aus mehreren Emojis bestehen. Aus unserer Sicht ist das ein unnötiger Einschnitt in die Nutzererfahrung und wir erkennen keinen Mehrwert. Wir bitten um eine erneute Überprüfung, ob diese Anforderungen wirklich notwendig sind.

[Johennes]

Gemeint ist hier anstatt "Emoji" eigentlich eher Graphem-Cluster. Ich bin mir allerdings nicht ganz sicher ob diese Cluster abhängig vom Locale sind oder nicht. Falls ja, müsste man den auch noch festlegen.

Hintergedanke dieser Afo ist ja, dass Annotations unverschlüsselt sind und darum keine sensitiven Informationen enthalten dürfen. Die Beschränkung auf ein (zusammengesetztes) Emoji schien bisher die praktikabelste Lösung dafür. Wir wären aber natürlich offen für Alternativvorschläge.

[nico-famedly]

Wie wäre es wenn wir das genau so in die Afo packen?

Der TI-M F MUSS sicherstellen, dass der Wert des Attributes key im Event-Content in Events des Typs m.reaction keine sensitiven Informationen beinhalten, z.B. durch eine Beschränkung auf einzelne Emoji oder einzelne Schriftzeichen. Andernfalls MUSS der Request mit dem Response Code 400 und dem Error Code M_BAD_JSON abgewiesen werden.

Das würde die Deutungshoheit, was ein Emoji ist, aus der Afo rausnehmen, aber wäre meiner Meinung nach immer noch ausreichend?

Wir benutzen diese Reactions zusätzlich auch als Downloadindikator indem mit dem String 'Downloaded' reagiert wird. Idealerweise wäre das auch zulässig, aber wir können auch eine andere Lösung dafür entwickeln.

[Johennes]

Wie wäre es wenn wir das genau so in die Afo packen?

Der TI-M F MUSS sicherstellen, dass der Wert des Attributes key im Event-Content in Events des Typs m.reaction keine sensitiven Informationen beinhalten, z.B. durch eine Beschränkung auf einzelne Emoji oder einzelne Schriftzeichen. Andernfalls MUSS der Request mit dem Response Code 400 und dem Error Code M_BAD_JSON abgewiesen werden.

Das würde die Deutungshoheit, was ein Emoji ist, aus der Afo rausnehmen, aber wäre meiner Meinung nach immer noch ausreichend?

Die Idee finde ich nicht schlecht. Ich kläre das mal mit unserer Zulassungsabteilung ab. In dieser Form ließe es sich nicht mehr automatisiert testen sondern bräuchte dann z. B. eine Herstellererklärung. Das könnte aber genügen.

Wir benutzen diese Reactions zusätzlich auch als Downloadindikator indem mit dem String 'Downloaded' reagiert wird. Idealerweise wäre das auch zulässig, aber wir können auch eine andere Lösung dafür entwickeln.

😲 Coole Idee!

[nikzen]

Hallo, ich wollte fragen ob es hier eine Entscheidung gibt? Wir würden ungern die UX so stark beschneiden.

[Johennes]

Ich hatte gestern schon angefangen ein knappes Proposal zu formulieren mit dem allgemein statische Strings (also kein Freitext) erlaubt werden und wollte das demnächst online stellen. Es wäre damit noch nicht entschieden aber zumindest ist das die Richtung, die ich mir momentan vorstelle.

[Johennes]

#302

[nikzen]

Ich hatte gestern schon angefangen ein knappes Proposal zu formulieren mit dem allgemein statische Strings (also kein Freitext) erlaubt werden und wollte das demnächst online stellen. Es wäre damit noch nicht entschieden aber zumindest ist das die Richtung, die ich mir momentan vorstelle.

Perfekt vielen Dank. Ich lese es mir gleich mal durch.