Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
nikzen opened this issue Jan 29, 2025 · 3 comments
Open

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

nikzen opened this issue Jan 29, 2025 · 3 comments

Comments

@nikzen
Copy link

nikzen commented Jan 29, 2025

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants