Merge branch 'beta6' into develop

# Conflicts:
#	docs/4_Authentifizierung_und_Autorisierung.md

docs/1_Getting_Started.md

@@ -3,19 +3,18 @@
 <!-- theme: info -->
 
 > ## ① Account registrieren
-> Registrieren Sie sich für einen Account, um einen Zugriff auf eine API zu bekommen. Im Rahmen der Registrierung bekommen Sie durch das System eine eindeutige ID (Beispiel-ID) mitgeteilt. Aus dieser Account-ID leiten sich mit einem entsprechenden Präfix die Sender-ID (Senderpräfix_Beispiel-ID) und Subscriber-ID (Subscriberpräfix_Beispiel-ID) ab. ➡ [Anwender Registrierung](./4_Authentifizierung_und_Autorisierung.md)
+> Registrieren Sie sich für ein Zugriff, um mit Ihren Client auf die API zuzugreifen. Im Rahmen der Registrierung bekommen Sie für die gewünschte API die Client-ID und Zugriffdaten mitgeteilt. Da zum aktuellen Zeitpunkt keine Sandbox Umgebung bereitstellt, wird empfohlen, sich für beide Seiten zu registieren, um für komplexere Tests mit einem REST Client die API der Gegenseite anzusprechen (Siehe Postman Nutzung in Schritt 2). ➡ [Registrierung zur API Nutzung](./4_Authentifizierung_und_Autorisierung.md)
 
-> ## ② Client anlegen
-> Für den Zugriff auf die API fügen Sie dem Account einen Client hinzu und vergeben Sie dem Client die entsprechenden Scopes. ➡ [Client registrieren](./4_Authentifizierung_und_Autorisierung.md#client-registrierung)
+> ## ② API ausprobieren
+> In der Navigation auf linken Seite finden Sie die jeweiligen API Referenzen für die Nutzung der APIs unter den Reitern `Application Sender API` und `Application Subscriber API` 
+Für einen einfachen Einstieg zum Test der API können Sie die bereitgestellte Postman Collection nutzen und mit dem Postman REST Client die Anfragen an die API durchführen. Hiermit können Sie auch die Gegenseite (Sender oder Empfänger von Anträgen simulieren) (➡ [Testen mit Postman](./Detailinformationen/Postman.md). Nähere Informationen zu Postman siehe https://www.postman.com/) 
+Alternativ können Sie die Anfragen auch mittels eigener Anwendungen oder alternativer REST Clients durchführen.
 
-> ## ③ API ausprobieren
-> Für einen einfachen Einstieg zum Test der API können Sie folgende Postman Collection (Link auf die Collection) nutzen und mittels des Postman REST Clients die Anfragen an die API durchführen. (Für nähere Informationen zu Postman siehe https://www.postman.com/) Alternativ können Sie die Anfragen auch mittels eigener Anwendungen oder alternative REST Client durchführen. Falls Sie nur für die Sender oder Subscriber Seite entwickeln, nutzen sie den folgenden Vorschlag auf Basis Postman ➡ [Testen mit Postman](./Detailinformationen/Postman.md)
-
-> ## ④ OAuth Token abrufen
+> ## ③ OAuth Token vor der API Nutzung abrufen
 > Für jede Anfrage an die API Endpunkte ist ein gültiger JWT-Token mit der Anfrage mitzusenden. Für nähere Informationen zum Abruf eines JWT-Token siehe ➡ [OAuth Details](./Detailinformationen/OAuth.md)
 
-> ## ⑤ API nutzen
-> Sofern Sie Zugriff auf die Quellen der Spezifikation im OpenAPI Format benötigen, finden Sie diese hier: ➡[FIT-Connect-PoC-v0.6.zip](https://github.com/fiep-poc/assets/raw/master/spec/FIT-Connect-PoC-v0.6.zip)
+> ## ④ Spezifikation lokal nutzen
+> Sofern Sie einen lokalen Zugriff auf die Quellen der Spezifikation im OpenAPI Format (bspw. für Code Generatoren) benötigen, finden Sie diese hier: ➡[FIT-Connect-PoC-v0.6.zip](https://github.com/fiep-poc/assets/raw/master/spec/FIT-Connect-PoC-v0.6.zip)
 <!-- Abschließendes Beispiel eines API Abrufs mit Token Abruf und einem Beispiel unter Nutzung des Tokens. -->
 
 ## Wie geht es weiter?

docs/3_Use_Cases_der_API.md

-# Durch die XFall API unterstützte Anwendungsfälle
+# Anwendungsfälle der API
 
 ## Gesamtüberblick der Anwendungsfälle und beteiligten Fachsysteme
 
@@ -12,9 +12,9 @@
 
 **Ziel:** Alle Bestandteile des Antrags werden in den Abholbereich des addressierten Zustellpunkts übergeben und liegen dort zur Abholung durch den Subscriber bereit.
 
-**Beschreibung:** Der Sender überträgt mittels eines POST die Metadaten des Antrags an die Sender API und legt damit den Antrag (`application`) als Ressource sowie die Fachdaten und die in den Metadaten angegebenen Anlagen als Subressourcen an. Für den Antrag bekommt der Sender eine eindeutige `application-id`in der Response mitgeteilt. Der Sender kann anschließend alle Bestandteile des Antrags an die jeweiligen Endpunkte per PUT übermitteln und die Übergabe an in den Abholbereich des Subscribers über einen abschließenden Commit initialisieren.
+**Beschreibung:** Falls die Parameter des Zustellpunkts (bspw. das zu nutzendes Fachdatenschema des Antrags) nicht bekannt sind, können diese Information über die Angabe der Destination-ID abgerufen werden. Zur Initierung der Übertragung, überträgt der Sender mittels eines POST die Metadaten des Antrags an die Sender API und legt damit den Antrag (`application`) als Ressource und die Fachdaten sowie die in den Metadaten angegebenen Anlagen als Subressourcen an. Für den Antrag bekommt der Sender eine eindeutige `application-id`in der Response mitgeteilt. Der Sender kann anschließend alle Bestandteile des Antrags an die jeweiligen Endpunkte per PUT übermitteln und die Übergabe an in den Abholbereich des Subscribers über einen abschließenden Commit initialisieren.
 
-![Application_Transfer](https://raw.githubusercontent.com/fiep-poc/assets/master/images/use_case_documentation/application_transfer.png "Ablaufbeschreibung zur Uebertragung eines Antrags")
+![Application_Transfer](https://raw.githubusercontent.com/fiep-poc/assets/master/images/use_case_documentation/application_transfer_API_V6.png "Ablaufbeschreibung zur Uebertragung eines Antrags")
 
 ### Zustellstatus des abgegebenen Antrags abrufen
 
@@ -50,7 +50,7 @@
 
 **Beschreibung:** Der Subscriber kann die Metadaten aller vorliegenden Anträge mit einem Request abrufen oder die Metadaten eines spezifischen Antrags abrufen, falls die `application-id` durch eine Callback Benachtigung bereits mitgeteilt wurde. Nach dem Abruf der Metadaten besteht die Möglichkeit, die Fachdaten (`data`) sowie die  Anlagen (`document`) abzurufen. Nach dem Abruf aller gewünschten Bestandteile des Antrags, muss der vollständige Abruf durch den Subscriber bestätigt werden. Diese Bestätigung hat zur Folge, dass innerhalb einer definierten Frist der Antrag unwiederruflich gelöscht wird. 
 
-![Application_Retrieval](https://raw.githubusercontent.com/fiep-poc/assets/master/images/use_case_documentation/application_retrieval.png "Ablaufbeschreibung zum Abruf eines Antrags")
+![Application_Retrieval](https://raw.githubusercontent.com/fiep-poc/assets/master/images/use_case_documentation/application_retrieval_API_V6.png "Ablaufbeschreibung zum Abruf eines Antrags")
 
 ### Legende der verwendeten BPMN Symbole
 

docs/4_Authentifizierung_und_Autorisierung.md

@@ -78,4 +78,6 @@ Wurden alle Prüfschritte erfolgreich absolviert, wird die Anfrage an den Zustel
 
 Nach Bearbeitung der Anfrage im Zustelldienst wird die Antwort des Zustelldienstes an den Client zurückgesendet.
 
+FÜr nähere Details und Beispiele siehe:
+➡ [OAuth](./Detailinformationen/OAuth.md)
 

docs/Detailinformationen/Clients.md

-# Clients verwalten

reference/callback.json → reference/3_callback.json

@@ -11,7 +11,7 @@
       "name": "Creative Commons Attribution Share Alike 4.0 (CC BY-SA 4.0)",
       "url": "https://creativecommons.org/licenses/by-sa/4.0/"
     },
-    "description": "Pseudo API um den Callback zu modellieren."
+    "description": "API Beschreibung der Callback API, die von Subscriber Clients zu implementieren ist, um Benachrichtigungen für vorliegende Antäge aktiv im Pushverfahren zu empfangen."
   },
   "servers": [
     {