search

gematik / api-kim

API specification for gematik's KIM - a secure Email standard, which enables the exchange of information and payload in the German healthcare sector.
Other
33 stars 12 forks source link

[Kommentierung 1.5.3] AccountLimit.kasMailSizeThreshhold #53

Open stophane opened 1 year ago

stophane commented 1 year ago

Es fehlt ggf. notwendige Spezifikation bzgl. des neuen AccountLimits-Parameter „kasMailSizeThreshold“.

Siehe ursprüngliche PR: https://github.com/gematik/api-kim/pull/22

=> Entsprechend muss der Umgang mit diesem Parameter definiert:

gem-cp commented 1 year ago

AccountLimits-Parameter [„kasMailSizeThreshold“] wird wie vorgeschlagen ergänzt.

Vorausgesetzt alle Empfänger der Nachricht können 1.5.x, dann wäre es sinnvoll alle Mails über den KAS zu versenden. Wenn ein Empfänger KIM 1.0 hat, dann bekommen alle Empfänger die Mail als KIM 1.0 Nachricht.

Die Einstellung des Parameters sollte durch den Fachdienst erfolgen (aus unserer Sicht sinnvoll, um dem Nutzer nicht zusätzliche Entscheidungen zu überlassen). Welcher Minimalwert soll möglich sein? Vorschlag: 0Byte Zu "dataTimeToLive" auf dem KAS: Wenn alle KIM-Nachrichten über den KAS transportiert werden, dann kann der Nutzer nur über "dataTimeToLive" die Dauer der Speicherung steuern. Das kann dazu führen, dass sein Account mehr Daten speichert als notwendig wäre. Daher muss der Fachdienst Betreiber einen sinnvollen Wert für "kasMailSizeThreshold" wählen.

Zur Frage "Was passiert, wenn nicht oder invalid gesetzt?": Der Fachdienst sollte aus unserer Sicht immer einen korrekten Default Wert vorgeben und falsche Eingaben (außerhalb min/max) ablehnen, sodass der Fall "nicht gesetzt oder invalid" nicht eintreten kann. Wenn der Fachdienst diesen Wert vorgibt wäre eine Regelung im CM nicht erforderlich.

stophane commented 1 year ago

Achtung: Es gilt Kontext KIM 1.5+ bzw. zukünftig dem "+" zu beachten. Das "+" sagt aus, dass ein Empfänger große Nachrichten > 15 - 700 MiB verarbeiten kann.

Mit Einführung von „kasMailSizeThreshold“ und dem Heruntersetzen dieser Schwelle, folgt automatsich, dass die Empfänger Ihre KIM-Version mit "+" versehen haben müssen, da ein KIM Clientmodul sonst beim Nachrichtenabruf einen Fehlerfall produziert (siehe A_23512 - Auswertung der KOM-LE-Version bei Nachrichten mit KAS-Content). Denn mit „kasMailSizeThreshold“ würden auch dann KAS-Nachrichten versendet werden, welche < 15 MiB sind, sodass potenziell ohne "+" keine Nachrichten versendet oder empfangen werden können. Dies steht auch im direkten Konflikt zur eigentlichen Nutzung des "+" - Verhinderung, dass "über"-große Datenmenge unkontrolliert in das Empfängersystem gelangen.

Vorschlag: Ohne Einführung einer technisch verlässlichen Informationsquelle, welche die tatsächliche Datenmenge, die durch "getAttachment" in das System gelangt, bereitstellt, darf diese Änderung nicht, oder nicht mit zu "kleinem" Minimal-Wert eingeführt werden.

Als sinnvolle und nicht "never trust the client"-problem-behaftete Quelle der Information zur Datenmenge, welche durch getAttachment abgerufen wird, kann HTTP HEAD bzgl. getAttachment genutzt werden. Das setzt jedoch voraus, dass für getAttachment entsprechende Definition für das Interface geschaffen wird und alle KAS dies unterstützen.

kurtkoe commented 1 year ago

Die Argumentation mit A_23512 würde ich grundsätzlich unterstützen, hierzu gibt es aber in der aktuellen gemSpec_CM_KOMLE_V1.16.0 einen spannenden Hinweis im nicht normativen Teil:

grafik

Wäre spannend zu wissen, welche Hersteller das tatsächlich so umgesetzt haben.

stophane commented 1 year ago

Die Argumentation mit A_23512 würde ich grundsätzlich unterstützen, hierzu gibt es aber in der aktuellen gemSpec_CM_KOMLE_V1.16.0 einen spannenden Hinweis im nicht normativen Teil:

grafik

Wäre spannend zu wissen, welche Hersteller das tatsächlich so umgesetzt haben.

Dieser Hinweis ist bekannt, auch dass "size" in der KIM-AttachmentDatenStruktur eine entsprechende Wertangabe liefert.

Jedoch gilt hier "never trust the client", da diese Angaben durch den versendenden Client gesetzt werden und fälschlicher-/boshafterweise von der tatsächlichen, technischen Datenmenge abweichen können.

Dabei dient die Einführung des "+" genau dazu, zu verhindern, dass große Datenmenge unkontrolliert in Systeme gelangen, die potenziell damit nicht umgehen können. Demzufolge der o.s. Konmentar.

X-KIM-KAS-Size wurde nicht primär für diesen Fall eingeführt, sondern bspw. für dispatching Mechanismen im Kontext POP3 TOP, um vor dem eigentlichen Nachrichtenabruf "grob" zu erkennen, ob bestimmte Nachrichten bspw. außerhalb von Spitzenlasten abgerufen werden sollten.

Viele Grüße