stophane

Guter Hinweis. Ohne den aktuellen Zustand der Spezifikation/dieses Repos validiert zu haben, ist die Anwendung des o.g. eigentlich nur in versionierter Abbildung der interfaces möglich (bspw. /v2 -> /v3), sodass...

Hallo zusammen, diesen Scope erweiternd, folgende Anmerkungen zum Umgang mit appTags KIM CM - KIM FD - VZD. Scope: A_23728 - VZD, I_Directory_Application_Maintenance, Aktualisierung zulässiger Anwendungskennzeichen A_23729 - VZD, I_Directory_Application_Maintenance,...

### Ergänzung Wenn der VZD als zentrale Quelle der appTags eingesetzt wird, bietet das ebenfalls die Möglichkeit, dass der VZD als anti-corruption layer agieren kann (vgl.: [anti-corruption layer](https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer)). So kann...

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

> 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: > >  > > Wäre...

Hallo zusammen, Ergänzende Hinweise im Kontext der nachfolgenden Spec: A_23819 - VZD, I_Directory_Application_Maintenance, Behandlung komLeData & kimData REST Tabelle 15: Tab_VZD_Datenbeschreibung ### Delimiter in kimData beachten/überdenken - "|" (pipe) ggf....

Als möglicher Ansatz: [siehe Auszug aus "altem" Ticket](https://github.com/gematik/api-kim/issues/32)

> Ergänzung: Der Fachdienst muss neben der vom CM angegebenen SIZE auch die tatsächliche Größe der Mail auswerten (DATA) und ablehnen, falls größer 15MiB oder ungleich SIZE (https://www.rfc-editor.org/rfc/rfc1870.html#section-6) Hallo, das...