[Kommentierung 1.5.3] A_23541 - Servicelokalisierung durch das Clientmodul

[CLAM01]

A_23541 - Servicelokalisierung durch das Clientmodul
Das Clientmodul MUSS den FQDN des Fachdienstes sowie den zu nutzenden Port per DNS Service Discovery bestimmen, wenn diese nicht durch das Clientsystem im jeweiligen Benutzernamen bereitgestellt wurden.[<=]

In der Beschreibung steht, dass das CM den FQDN und den Port des Fachdiensten per DNS SD ermitteln muss wenn der Teilstring fehlt.
Soweit OK.

Jedoch müssen diese Afo nochmal geprüft werden durch gematik, da diese nachfolgende Afo besagt, dass der Vorgang abgebrochen werden muss wenn der Benutzername nicht passt im Aufbau:
Bevor ich feststellen kann das was fehlt, muss ja zuerst die Prüfung der Benutzernamen stattfinden und das CM käme nie bis zur A_23541.

A_21519-02 - Überprüfung des SMTP-Benutzernames
Das Clientmodul MUSS die übergebene SMTP-Benutzername-Zeichenkette auf Vollständigkeit überprüfen. Werden optionale Bestandteile des SMTP-Benutzernamens nicht genutzt, MUSS sichergestellt werden, dass später folgende optionale Bestandteile in ihrer vorgegebenen Position platziert werden. Als Platzhalter ist in so einem Fall "*" zu verwenden. Wenn die SMTP-Benutzername-Zeichenkette nicht vollständig ist, MUSS das Clientmodul den SMTP Fehlercode gemäß Tabelle "Tab_SMTP_Verbindung SMTP-Antwortcodes für MTA-Verbindungsaufbau" an das Clientsystem senden und den Vorgang abbrechen.

A_21518-02 - Überprüfung des POP3-Benutzernames
Das Clientmodul MUSS die übergebene POP3-Benutzername-Zeichenkette auf Vollständigkeit überprüfen. Werden optionale Bestandteile des POP3-Benutzernamens nicht genutzt, MUSS sichergestellt werden das später folgende optionale Bestandteile in ihrer vorgegebenen Position platziert werden. Als Platzhalter ist in so einem Fall "*" zu verwenden. Wenn die POP3-Benutzername-Zeichenkette nicht vollständig ist, MUSS das Clientmodul den POP3 Fehlercode gemäß Tabelle "Tab_POP3_Verbindung Antwortcodes für POP3-Server-Verbindungsaufbau" an das Clientsystem senden und den Vorgang abbrechen. [<=]

[dhufnagel]

Was ist der Sinn hinter der Ergänzung des SMTP und POP3 Nutzernamen um die Platzhalter „*“? Warum sollte man das machen, wenn das einzige System, welches diese Teile auswertet das Clientmodul selbst ist? Der Nutzername wird so nie an den Fachdienst übermittelt oder anderweitig verwendet. Daher erschließt sich mir der Sinn des Teils der jeweiligen AFO nicht.

[CLAM01]

Die "*" sind notwendig, da z.B. bei POP3 und der Nutzung einer HBA eine "User-ID" im Benutzernamen benötigt wird.
Bei SMTP hingegen gibt es die "User-ID" nicht, da nicht auf das Schlüsselmaterial des HBA zugegriffen werden muss.
Um auf das Schlüsselmaterial des HBA zugreifen zu können, muss diese ja in eine erhöhte Sicherheitsstufe gelegt werden.

Zudem befindet sich im Benutzernamen ja auch noch die KonnektorID, mit der man steuern kann, welcher Konnektor für Signatur und Verschlüsselung der KIM-Nachricht genutzt werden soll.

Würde man jetzt bei POP3 nicht das "*" bei UserId setzten, dann würde das CM die KonektorId als UserId ansehen und der Konnektor könnte nicht explizit angesteuert werden.

[dhufnagel]

Das CM muss doch auch die "*" an der gegebenen Stelle als "nicht gesetzt" interpretieren, was kein Unterschied dazu ist, ob der Teilstring einfach nicht existiert. Technisch würde ich im CM in einer Zeile den Benutzername so anpassen, dass "*" drin steht, 2 Zeilen weiter unten würde ich den Benutzername auseinandernehmen und müsste das "*" wieder interpretieren. Dann kann ich mir die Ergänzung sparen und einfach die Abfrage, ob eine User-ID angegeben ist oder nicht, anhand des Originalstrings machen und auswerten, dass ein Teil fehlt.
Daher verstehe ich nicht, warum das Ergänzen des Benutzernamens eine AFO ist. Die AFO müsste eher fachlicher Natur sein und jedem ist es dann überlassen, wie er das implementiert.

[CLAM01]

Das CM bekommt den Benutzernamen doch vom Clientsystem.
Wenn das CM die Kombination aus hrst_domain.kim.telematik:Port nicht finden, dann muss es DNS SD machen um den FQDN zu bekommen.

Zu den optionalen Parametern.
Laut Spezifikation muss das * nur inmitten des Benutzernamens gesetzt werden.
Wenn ein optionaler Parameter am Ende weggelassen wird, dann muss kein * hin.

Bei SMTP kein Problem, da gibt es nur den optionalen Parameter KonektorId am Ende.

Bei POP3 muss das CM genau wissen wenn die UserId nicht benötigt wird.
Ok, auch wenn das * weggelassen wird, interpretiert das CM den POP3 Benutzernamen als OK, aber es kann dann zu Problemen kommen wenn eine HBA ins Spiel kommt.

Ich sehe an dieser Stelle noch etwas anders kritisch im Bezug auf die A_23541:

Es werden andere Delimiter erlaubt, jedoch nicht gesagt welche.
Wenn jetzt aber der Delimiter dazu genutzt wird, den Part gemäß A_23541 zu prüfen, muss man auch wissen welcher Delimiter vorhanden sein kann. Oder?

[dhufnagel]

Ja, genau, der Benutzername kommt vom Clientsystem und nicht vom Clientmodul. Daher müsste das Clientsystem ein "*" einfügen, nicht aber das Clientmodul, da dieses den Benutzerstring ja direkt wieder verarbeitet. Wenn die Daten vom Clientsystem fehlen, nutzt es nichts, wenn das Clientmodul vor Verarbeitung ein "*" einfügt.

[CLAM01]

Werden optionale Bestandteile des SMTP-Benutzernamens nicht genutzt, MUSS sichergestellt werden, dass später folgende optionale Bestandteile in ihrer vorgegebenen Position platziert werden. Als Platzhalter ist in so einem Fall "*" zu verwenden. Wenn die SMTP-Benutzername-Zeichenkette nicht vollständig ist, MUSS das Clientmodul den SMTP Fehlercode gemäß Tabelle "Tab_SMTP_Verbindung SMTP-Antwortcodes für MTA-Verbindungsaufbau" an das Clientsystem senden und den Vorgang abbrechen.

Diese beiden Sätze stehen im Widerspruch wenn beides durch das CM gemacht werden soll.
Meine Interpretation ist, dass durch das Clientsystem sichergestellt werden muss das alle Parameter korrekt gesetzt sind.

ABer nochmal zum Anfang:
Die Afos zur Prüfung müssen dahingehend angepasst werden, dass der FQDN:Port fehlen kann, und dies nicht als unvollständiger Benutzername angesehen werden darf gemäß der beiden Afos.

[dhufnagel]

Auf das Clientsystem hat die Spezifikation keinen Einfluss, da dies außerhalb des Regelungsbereichs der Spezifikation liegt. Die AFO beginnt mit "Das Clientmodul MUSS", daher interpretiere ich das Ergänzen als AFO für das Clientmodul.

In den anderen Punkten stimme ich voll zu.

Die Handhabung mit dem Part FQDN:Port müsste auf jeden Fall in der AFO nochmal überdacht werden. Aktuell werden alle Clientsysteme den Benutzernamen mit einem FQDN:Port Part versehen haben. Somit würde die DNS SD für bestehende, eingerichtete Clientsysteme nie ausgeführt werden, auch wenn das CM aktualisiert wird.

Auch der Part mit dem Delimiter müsste genauer spezifiziert werden, denn hier müssten alle CM die gleichen Delimiter unterstützen, um Interoperabel zu agieren.

[gem-cp]

OK. Schauen wir uns an.

[stophane]

Hallo zusammen,

(bewusst umfassendere Inhalte, um diese Afo. im Gesamtkontext zu kommentieren)

Vorab-Referenz zu Benutzernamen gemäß gemSpec_CM_KOMLE_V1.16.0

SMTP-Benutzername

[0] Benutzername
[1] :
[2] MandantId
[3] ClientsystemId
[4] WorkplaceId
— —
[5] KonnektorId [...]

POP3-Benutzername

[0] Benutzername
[1] :
[2] MandantId
[3] ClientsystemId
[4] WorkplaceId
— —
[5] UserId
[6] KonnektorId [...]

Aktuelle Situation

In den Mail-Clients, welche KIM nutzen sind die KIM credentials statisch, gemäß KIM 1.0 abgebildet, und nicht durch KIM beeinflussbar/änderbar.

Folglich gilt:

• Bestehende Benutzernamen müssen weiterhin verwendet werden können
• Aufgrund der UserId müssen SMTP- und POP3-Benutzernamen weiterhin getrennt voneinander betrachtet werden können.
• Jede semantische oder syntaktische Veränderung bisher geltender Inhalte des Benutzernamens können zum Funktionsverlust führen und würde ggf. Anpassungen der Mail-Clients oder darin befindlicher Konfigurationen notwendig machen
  • Beachte: Es existieren auf KIM bzw. TI spezialisierte Mail-Clients, welche den KIM-Benutzernamen „dynmaisch“ bzgl. des Konnektor-Aufrufkontextes zusammensetzen, da der Konnektor-Aufrufkontext unabhängig von KIM in den Systemen genutzt und verändert werden kann.

Neue Möglichkeiten KIM 1.5 – Einführung DNS-SD

Durch die Einführung von DSN-SD für alle KIM-Services kann „[1] <fqdn/domain>:“ als optional gelten und durch „*“ substituiert werden. Endpunkte Mailserver (SMTP, POP3), KAS, Account-Manager müssen generell per DNS-SD, anhand der KIM-Domain des KIM-Accounts, auflösbar sein.

Beachte - technische Notwendigkeit von [1] als absolute Endpunktangabe:
Es existieren Betriebsumgebungen (bspw. Klinik-Infrastrukturen), welche Aufgrund der Verwendung von proxy appliances, speziellen routing-settings oder übergreifender Anbindungssetups zwingend die dedizierte Angabe des Endpunktes benötigen, um KIM-Nachrichten versenden/abrufen zu können.
(Es ist klar, dass dies für Account-Manager und KAS nicht ohne weiteres analog abbildbar ist, da es für diese Endpunkte keine spezifizierte, dedizierte Konfigurationsmöglichkeit gibt).

Möglicher, geeigneter Umgang mit Endpunktinformationen im Benutzernamen (fallback-strategy)

1. Wenn „[1] <fqdn/domain>:“ angegeben, dann gilt dieser absolut und ist als dieser zu verwenden, da dedizierte Konfiguration durch Betreiber (aktuelle Situation durch KIM 1.0)
2. Ist [1] positionsgetreu nicht bzw. durch „*“ angegeben, dann sind die Endpunktinformationen per DNS-SD absolut, anhand der KIM-Maildomain zu ermitteln.
3. Schlägt (2 – DNS-SD) fehl oder liefert keine geeigneten Endpunkt-Informationen zurück, kann weiterführend DNS-MX aufgelöst werden, unter der Annahme, dass gemäß Spezifikation die Ports 465, 995 nutzbar sind.

Teilweise auch in „3.3.2.2 Verbindungsaufbau mit dem MTA“ beschrieben.

Delimiter in „[1] <fqdn/domain>:“

In der Vergangenheit kam es dazu, dass verschiedene Bestands-Mailsysteme (Mailclients) „:“ im Benutzernamen nicht nutzen konnten. Folglich ist es notwendig, „:“ durch einen anderen delimiter ersetzen zu können, damit diese Systeme an KIM angebunden werden können.
Der Text verweist nachfolgend korrekt auf die RFC´s zur Abbildung von internet hostnames, in diesem Fall (ip:port oder fqdn:port), sodass verhindert wird, dass bspw. „.“ als delimiter verwendet wird, was bspw. bei 127.0.0.1.465 ein Problem wäre.

Da dieses Problemfeld i.d.R. individuell je Mail-Clientsystem bestehen würde, kann hier keine Festlegung zu den unterstützen, die hostname RFC-nicht-verletztenden delimitern, zw. , getroffen werden und ist im spezifischen Problemlösungsszenario zw. Mail-Clientsystem und Clientmodul zu betrachten. Wird eine Festlegung getroffen, und es passt im spezifischen Problemfall nicht = wieder Problem.
Dieser Teil der Anforderung ist aus meiner Sicht eher als optionale Erweiterung zu sehen, um geeignet auf Bestandssysteme reagieren zu können, ohne dabei übergeordnete Festlegung zu verletzen.

Grobe Beispiel regex für parsing „[1] <fqdn/domain>:“:
https://regex101.com/r/StTEQL/1

Zu "*" als Platzhalter

Es ist korrekt, dass es keine Platzhalter bräuchter, denn "##" kann auch als "##" angesehen werden = keine Wertangabe.
Da jedoch Teile des KIM-Benutzernamens (Konnektor-Aurufkontext) außerhalb der KIM-Anwendungsdomäne liegen, meiner Erinnerung nach Leer-Strings dort erlaubt schienen, macht die klare und eindeutige Definition eines Platzhalter = kein auszuwertender Value m.E. Sinn. So existiert ein absoluter Wert mit dieser Semantik und erzeugt "lesbare" Struktur (ggf. hilft es bei ohnehin notwendiger string.empty, null Betrachtung weiter).

=> Durch die aktuelle Spezifikation mit "*" ist es ohnehin und aus Konsistenz- und IOP-Gründen zu hinterfragen, ob eine Abwandlung zielführend bzw. problemverursachend ist.

Viele Grüße

[dhufnagel]

Zu "*" als Platzhalter

Aus meiner Sicht macht es auch Sinn, Platzhalter für die Clientsysteme zu definieren, die referenzierten AFOs interpretiere ich jedoch so, dass das Clientmodul den Benutzerstring im Clientmodul selbst mit Platzhaltern erweitern muss. Das macht aus meiner Sicht keinen Sinn. Dass das Clientmodul mit Platzhaltern umgehen können muss, macht hingegen Sinn.

[stophane]

Zu "*" als Platzhalter

Aus meiner Sicht macht es auch Sinn, Platzhalter für die Clientsysteme zu definieren, die referenzierten AFOs interpretiere ich jedoch so, dass das Clientmodul den Benutzerstring im Clientmodul selbst mit Platzhaltern erweitern muss. Das macht aus meiner Sicht keinen Sinn. Dass das Clientmodul mit Platzhaltern umgehen können muss, macht hingegen Sinn.

Ah sry, wenn man es so liest ist diese Interpretation möglich )-:
Bin da voll bei Ihnen, die Afo. dreht sich meiner Interpretation nach ausschließlich um die Angabe des Benutzernamens im Clientsystem, das Clientmodul wiederum hat nur die Aufgabe den Benutzernamen korrekt zu parsen und nicht zu manipulieren oder zu erweitern - spielt keine Rolle, wie auch von Ihnen weiter oben beschrieben!

[gem-cp]

OK, Wir werden die Formulierung in A_21518_XX und A_21519_XX so ändern, dass klar ist, dass das CM keine "*" Platzhalter einfügen muss. Das war nie beabsichtigt.