Liguster

Privet ist eine lokale Cloud Discovery API, die von Cloud-Diensten verwendet wird. Dieses Dokument ist in folgende Abschnitte unterteilt:

  1. Einführung: Einführung in Privet
  2. Discovery: lokale Erkennungsmechanismen
  3. Mitteilungen: Ankündigungen für lokale Entdeckungen
  4. API: Privet APIs für allgemeine Cloud-Geräte
  5. Drucker-API: Privet APIs, die von Druckern verwendet werden
  6. Anhang: ergänzende Diagramme

1. Einführung

Verbundene Geräte in der Cloud haben viele Vorteile. Sie können Online-Conversion-Dienste verwenden, Jobwarteschlangen hosten, während das Gerät offline ist, und von überall auf der Welt aus darauf zugreifen. Bei vielen Cloud-Geräten, auf die ein bestimmter Nutzer zugreifen kann, müssen wir jedoch eine Methode zur Verfügung stellen, mit der sich das nächstgelegene Gerät anhand des Standorts ermitteln lässt. Der Zweck des Privet-Protokolls besteht darin, die Flexibilität von Cloud-Geräten mit einem geeigneten lokalen Erkennungsmechanismus zu binden, sodass Geräte in neuen Umgebungen einfach gefunden werden können.

Dieses Protokoll hat folgende Ziele:
  • Cloud-Geräte lokal sichtbar machen
  • Cloud-Geräte bei einem Cloud-Dienst registrieren
  • Registrierte Geräte mit ihrer Cloud-Darstellung verknüpfen
  • Offlinefunktion aktivieren
  • Die Implementierung wird vereinfacht, damit auch kleine Geräte sie nutzen können.

Das Privet-Protokoll besteht aus zwei Hauptteilen: Discovery und API. Mit der Erkennung wird das Gerät im lokalen Netzwerk gefunden. Über die API werden Informationen zum Gerät abgerufen und einige Aktionen ausgeführt. In diesem Dokument bezieht sich das Gerät auf ein mit der Cloud verbundenes Gerät, auf dem das Privet-Protokoll implementiert ist.

2. Auffindbarkeit

Discovery ist ein Zero-conf-basiertes Protokoll (mDNS + DNS-SD). Auf dem Gerät MUSS die IPv4-Link-Local-Adressierung implementiert sein. Das Gerät MUSS den mDNS- und DNS-SD-Spezifikationen entsprechen.

Die Gerätekonflikte müssen gemäß den oben genannten Spezifikationen auf dem Gerät behoben werden.

2.1. Dienstleistungstyp

DNS Service Discovery verwendet das folgende Format für Diensttypen: _applicationprotokolle._transportprotokolle. Für das Privet-Protokoll sollte der Diensttyp für DNS-SD so aussehen: _privet._tcp

Auf dem Gerät können auch andere Diensttypen implementiert werden. Es wird empfohlen, für alle vom Gerät implementierten Diensttypen denselben Dienstinstanznamen zu verwenden. Beispiel: Ein Drucker kann die Dienste „Drucker XYZ._privet._tcp&quot“ und „"Drucker XYZ._printer._tcp&quot“ implementieren. Die Einrichtung wird für den Nutzer vereinfacht. Privet-Kunden suchen jedoch nur nach "_privet._tcp".

Zusätzlich zum Hauptdiensttyp muss das Gerät die PTR-Einträge für die entsprechenden Untertypen bewerben (siehe DNS-SD-Spezifikation: "7.1. Selektive Instanzaufzählung (Untertypen)" Verwenden Sie folgendes Format: _<subtype>._sub._privet._tcp

Derzeit wird nur der Gerätedrucker unterstützt. Daher MÜSSEN alle Drucker zwei PTR-Einträge bewerben:

  • _privet._tcp.local.
  • _printer._sub._privet._tcp.local.

2.2. TXT-Eintrag

In DNS Service Discovery sind Felder definiert, mit denen optionale Informationen zu einem Dienst in die TXT-Einträge aufgenommen werden. Ein TXT-Eintrag besteht aus Schlüssel/Wert-Paaren. Jedes Schlüssel/Wert-Paar beginnt mit dem Byte der Länge gefolgt von bis zu 255 Byte Text. Der Schlüssel ist der Text vor dem ersten „=“-Zeichen und der Wert ist der Text nach dem ersten „=“-Zeichen bis zum Ende. Die Spezifikation lässt keinen Wert im Datensatz zu. In diesem Fall ist das Zeichen „=“ ODER kein Text nach dem Zeichen „=“. (Siehe DNS-SD-Spezifikation: "6.1. Allgemeine Formatregeln für DNS-TXT-Einträge&6; DNS-SD-TXT-Eintragsgröße für die empfohlene Länge.

Für Privet muss das Gerät die folgenden Schlüssel/Wert-Paare im TXT-Eintrag senden. Bei Schlüssel/Wert-Strings wird die Groß- und Kleinschreibung nicht beachtet. So sind beispielsweise "CS=online" und "cs=ONLINE" identisch. Die Informationen im TXT-Eintrag müssen mit denen übereinstimmen, auf die über das /info-API zugegriffen werden kann (siehe Abschnitt 4.1). API-Bereich).

Es wird empfohlen, die Größe des TXT-Eintrags unter 512 Byte zu halten.

2.2.1. TXTvers

Version der TXT-Struktur. txtvers muss der erste Datensatz der TXT-Struktur sein. Derzeit wird nur Version 1 unterstützt.

txtvers=1

2.2.2.

Gibt einen für den Nutzer lesbaren Namen des Geräts an. Beispiel:

ty=Google Cloud Ready Printer Model XYZ

2.2.3. Notiz (optional)

Gibt einen für den Nutzer lesbaren Namen des Geräts an. Beispiel:

note=1st floor lobby printer

Hinweis: Dies ist ein optionaler Schlüssel, der übersprungen werden kann. Falls vorhanden, kann der Nutzer diesen Wert jedoch ändern. Die gleiche Beschreibung MUSS bei der Registrierung des Geräts verwendet werden.

2.2.4. URL

Server-URL, mit der dieses Gerät verbunden ist (einschließlich Protokoll). Beispiel:

url=https://www.google.com/cloudprint

2.2.5 Typ

Durch Kommas getrennte Liste der Geräteuntertypen, die von diesem Gerät unterstützt werden. Format: "type=_subtype1,_subtype2" Derzeit ist Drucker der einzige unterstützte Untertyp des Geräts.

type=printer

Jeder aufgeführte Untertyp sollte mit einem entsprechenden PTR-Eintrag beworben werden. Für jeden unterstützten Dienstuntertyp sollte es ein entsprechendes Element geben. Der Name des Dienstuntertyps (<subtype>._sub._privet._tcp) sollte hier dem Gerätetyp entsprechen.

2.2.6.-ID

Geräte-ID. Wenn das Gerät noch nicht registriert wurde, sollte dieser Schlüssel vorhanden sein, aber der Wert muss leer sein. Beispiel:

  id=11111111-2222-3333-4444-555555555555
  id=

2.2.7. cs

Zeigt den aktuellen Verbindungsstatus des Geräts an. In dieser Spezifikation sind vier mögliche Werte definiert.

  • &online zeigt an, dass das Gerät derzeit mit der Cloud verbunden ist.
  • "offline" gibt an, dass das Gerät im lokalen Netzwerk verfügbar ist, aber nicht mit dem Server kommunizieren kann.
  • "&connect"" gibt an, dass das Gerät die Startsequenz ausführt und noch nicht vollständig online ist.
  • "nicht konfiguriert" gibt an, dass der Internetzugriff des Geräts noch nicht konfiguriert wurde. Dieser Wert wird derzeit nicht verwendet, kann aber in zukünftigen Versionen der Spezifikation nützlich sein.
Beispiel:
  • cs=online
  • cs=offline
  • cs=verbinden

Wenn das Gerät in der Cloud registriert wurde, sollte es beim Start die Verbindung mit einem Server prüfen, um den Verbindungsstatus zu erkennen (z. B. die Cloud API aufrufen, um die Geräteeinstellungen abzurufen). Das Gerät kann seinen Verbindungsstatus über den Benachrichtigungskanal (z.B. XMPP) verwenden, um diesen Wert zu melden. Nicht registrierte Geräte können beim Start eine Domain kontaktieren, um den Verbindungsstatus zu erkennen, z. B. www.google.com für Cloud Print-Geräte.

3. Ankündigungen

Beim Starten, Herunterfahren oder Statuswechsel des Geräts MUSS das Gerät den Ankündigungsschritt wie in der mDNS-Spezifikation beschrieben ausführen. Die entsprechende Mitteilung sollte mindestens zweimal mit einem Intervall von einer Sekunde gesendet werden.

3.1. Starten

Beim Start des Geräts MUSS er die in der mDNS-Spezifikation beschriebenen Prüfungen und Ankündigungen ausführen. In diesem Fall sollten die SRV-, PTR- und TXT-Einträge gesendet werden. Sie sollten nach Möglichkeit alle Datensätze in einer DNS-Antwort gruppieren. Falls nicht, wird die folgende Reihenfolge empfohlen: SRV, PTR, TXT-Einträge.

3.2. Heruntergefahren

Nach dem Herunterfahren des Geräts sollten alle betroffenen Parteien benachrichtigt werden, indem ein „Goodbye-Paket“ mit TTL=0 gesendet wird (wie in der mDNS-Dokumentation beschrieben).

3.3. Aktualisieren

Falls sich die in TXT beschriebenen Informationen geändert haben, MUSS das Gerät eine Update-Mitteilung senden. In diesem Fall reicht es aus, nur den neuen TXT-Eintrag zu senden. Nachdem ein Gerät registriert wurde, MUSS er beispielsweise eine Update-Ankündigung mit der neuen Geräte-ID senden.

4. API

Nachdem ein Cloud-Gerät erkannt wurde, wird die Clientkommunikation mit dem Gerät direkt über das lokale Netzwerk aktiviert. Alle APIs basieren auf HTTP 1.1. Datenformate sind JSON-basiert. API-Anfragen können GET- oder POST-Anfragen sein.

Jede Anfrage MUSS einen gültigen X-Privet-Token-Header enthalten. Die NUR Anfrage darf einen leeren Header X enthalten. Dies ist eine Anfrage von /privet/info. Der Header MUSS noch vorhanden sein. Wenn der Header „X-Privet-Token“ fehlt, MUSS das Gerät mit dem folgenden HTTP 400-Fehler antworten:

HTTP/1.1 400 Missing X-Privet-Token header.

Wenn der Header "X-Privet-Token" leer oder ungültig ist, MUSS das Gerät "X-Privet-Token-Fehler" zurückgeben. Weitere Informationen erhalten Sie im Abschnitt "Fehler". Die einzige Ausnahme ist die /info API. Weitere Informationen darüber, warum dies ausgeführt wird und wie Tokens generiert werden sollten, finden Sie in Anhang A: XSSI- und XSRF-Angriffe sowie deren Vorbeugung.

Wenn eine angeforderte API nicht vorhanden ist oder nicht unterstützt wird, MUSS das Gerät einen HTTP-404-Fehler zurückgeben.

4.1. API-Verfügbarkeit

Bevor eine API (einschließlich der /info API) verfügbar gemacht wird, MUSS das Gerät den Server kontaktieren, um die lokalen Einstellungen zu überprüfen. Lokale Einstellungen MÜSSEN vor Neustarts beibehalten werden. Wenn der Server nicht verfügbar ist, sollten die letzten bekannten lokalen Einstellungen verwendet werden. Wenn das Gerät noch nicht registriert wurde, sollte es den Standardeinstellungen entsprechen.

Cloud Print-Geräte MÜSSEN die folgenden Schritte ausführen, um lokale Einstellungen zu registrieren, zu empfangen und zu aktualisieren.

4.1.1 Anmeldung

Bei der Registrierung MUSS der Parameter "local_settings" angegeben werden:

{
       "current": {
                "local_discovery": true,
                "access_token_enabled": true,
                "printer/local_printing_enabled": true,
                "printer/conversion_printing_enabled": true,
                "xmpp_timeout_value": 300
        }
}
Sie können die folgenden Einstellungen festlegen:
WertnameWerttypBeschreibung
lokale_ErkennungbooleanGibt an, ob lokale Erkennungsfunktionen zulässig sind. Wenn „false“ ist, müssen alle lokalen APIs (einschließlich /info) und die DNS-SD-Erkennung deaktiviert werden. Standardmäßig sollten neu registrierte Geräte "true" übergeben.
Zugriffstoken_aktiviertBoolesch (optional)Gibt an, ob die /accesstoken API im lokalen Netzwerk verfügbar gemacht werden soll. Der Standardwert ist "true".
drucker/lokal_drucken_aktiviertBoolesch (optional)Gibt an, ob die lokale Druckfunktion (/printer/createjob, /printer/submitdoc, /printer/jobstate) im lokalen Netzwerk verfügbar gemacht werden soll. Der Standardwert ist "true".
drucker/conversion_printing_aktiviertBoolesch (optional)Gibt an, ob der lokale Druck den Job zur Konvertierung an den Server senden kann. Dies ist nur sinnvoll, wenn das lokale Drucken aktiviert ist.
xmpp_timeout_valueGanzzahl (optional)Gibt die Anzahl der Sekunden zwischen den Pings des XMPP-Kanals an. Der Wert muss 300 (5 Minuten) oder länger sein.

Wichtig: Das Fehlen eines optionalen Werts weist darauf hin, dass die entsprechende Funktionalität vom Gerät vollständig nicht unterstützt wird.

4.1.2 Starten

Beim Gerätestart sollte es den Server kontaktieren, um zu prüfen, welche APIs im lokalen Netzwerk verfügbar sind. Für Drucker, die mit Cloud Print verbunden sind, sollten sie folgendes aufrufen:

/cloudprint/printer?printerid=<printer_id>
oder
/cloudprint/list

/CHROME/Drucker wird gegenüber /CHROME/Liste bevorzugt, aber beide funktionieren.

Diese API gibt aktuelle Geräteparameter zurück, einschließlich der Einstellungen für die lokale API. Die Antwort des Servers hat das folgende Format:

"local_settings": {
        "current": {
                "local_discovery": true,
                "access_token_enabled": true,
                "printer/local_printing_enabled": true,
                "printer/conversion_printing_enabled": true,
                "xmpp_timeout_value": 300
         },
         "pending": {
                "local_discovery": true,
                "access_token_enabled": true,
                "printer/local_printing_enabled": false,
                "printer/conversion_printing_enabled": false,
                "xmpp_timeout_value": 500
         }
}

Objekt steht für Einstellungen, die derzeit wirksam sind.

Objekt mit ausstehender Einstellung gibt die Einstellungen an, die auf das Gerät angewendet werden sollen (dieses Objekt fehlt möglicherweise).

Sobald auf dem Gerät Einstellungen angezeigt werden, MUSS der Status aktualisiert werden (siehe unten).

4.1.3 Aktualisieren

Wenn ein Update der Einstellungen erforderlich ist, wird eine XMPP-Benachrichtigung an das Gerät gesendet. Die Benachrichtigung hat das folgende Format:

<device_id>/update_settings

Bei Erhalt einer solchen Benachrichtigung MÜSSEN die Geräte vom Server abgefragt werden, um die neuesten Einstellungen abzurufen. Cloud Print-Geräte MÜSSEN Folgendes verwenden:

/cloudprint/printer?printerid=<printer_id>

Sobald auf dem Gerät der Abschnitt „ausstehend“ als Ergebnis der /CHROME/Drucker-API angezeigt wird (beim Start oder aufgrund der Benachrichtigung), MUSS der interne Status aktualisiert werden, damit die neuen Einstellungen gespeichert werden. Es MUSS die Server-API aufrufen, um die neuen Einstellungen zu bestätigen. Bei Cloud Printern MUSS das Gerät die /CHROME/update API aufrufen und den Parameter &locale settings" wie bei der Registrierung verwenden.

Wenn Sie wieder eine Verbindung zum XMPP-Kanal herstellen, MUSS das Gerät die /CHROME/Drucker-API aufrufen, um zu prüfen, ob die lokalen Einstellungen seit dem letzten Mal geändert wurden.

4.1.3.1 Lokale Einstellungen ausstehend

Parameter „local_settings"“, den das Gerät zum Aufrufen der Server-API verwendet, DARF KEINEN Abschnitt „Ausstehend“ enthalten.

4.1.3.2 Aktuelle lokale Einstellungen

NUR das Gerät kann den Abschnitt „aktuell“ in den lokalen Einstellungen ändern. Alle anderen Nutzer ändern den Abschnitt „Ausstehend“ und warten, bis die Änderungen vom Gerät auf den Abschnitt „Aktuell“ übertragen wurden.

4.1.4 Offline

Wenn der Server beim Start nicht kontaktiert werden kann, MUSS das Gerät nach der Benachrichtigung die letzten bekannten lokalen Einstellungen verwenden.

4.1.5 Gerät wird aus dem Dienst gelöscht

Wenn das Gerät aus dem Dienst gelöscht wurde (z. B. die GCP), wird eine XMPP-Benachrichtigung an das Gerät gesendet. Die Benachrichtigung hat folgendes Format:

<device_id>/delete

Nach Erhalt einer solchen Benachrichtigung MUSS das Gerät an den Server gesendet werden, um seinen Status zu überprüfen. Cloud Print-Geräte MÜSSEN Folgendes verwenden:

/cloudprint/printer?printerid=<printer_id>

Das Gerät MUSS eine erfolgreiche HTTP-Antwort mit „success=false“ und keine Geräte-/Druckerbeschreibung erhalten. Es bedeutet, dass das Gerät vom Server entfernt wurde und dass die Anmeldedaten des Geräts gelöscht werden müssen. Außerdem muss der Modus auf die standardmäßigen Werkseinstellungen zurückgesetzt werden.

Jedes Mal, wenn das Gerät eine Antwort erhält, die darauf hinweist, dass es aufgrund der /CHROME/Drucker-API (Starten, Benachrichtigung über Update-Einstellungen, täglicher Ping) gelöscht wurde, MUSS er die Anmeldedaten löschen und in den Standardmodus wechseln.

4.2. /privet/info-API

Die Info API ist obligatorisch und MUSS von jedem Gerät implementiert werden. Dies ist eine HTTP GET-Anfrage für "/privet/info" url: GET /privet/info HTTP/1.1

Die Info API gibt grundlegende Informationen zu einem Gerät und den unterstützten Funktionen zurück. Diese API MUSS nie den Gerätestatus ändern oder eine Aktion ausführen, da sie anfällig für XSRF-Angriffe ist. Dies ist die NUR API, die einen leeren X-Privet-Token-Header haben darf. Clients sollten die /privet/info API mit dem Header „X-Privet-Token“ auf X-Privet-Token aufrufen: ""

Die Info API MUSS Daten zurückgeben, die den im TXT-Eintrag während der Erkennung verfügbaren Daten entsprechen.

4.2.1. Eingabe

Die /privet/info API hat keine Eingabeparameter.

4.2.2. Zurücksenden

Die /privet/info API gibt grundlegende Informationen zum Gerät und zu unterstützten Funktionen zurück.

In der Spalte „TXT“ ist das entsprechende Feld im DNS-SD-TXT-Eintrag angegeben.

WertnameWerttypBeschreibungTXT
VersionstringHöchste API-Version (Hauptversion) wird derzeit von 1.0 unterstützt
namestringFür Menschen lesbarer Name des Geräts.ty
TextzeilestringOptional: Gerätebeschreibung. SOLLTE vom Nutzer geändert werden.note
urlstringURL des Servers, mit dem dieses Gerät kommuniziert. Die URL MUSS die Protokollspezifikation enthalten, z. B. https://www.google.com/CHROME.url
TypListe von StringsListe der unterstützten Gerätetypen.Typ
idstringGeräte-ID: leer, wenn das Gerät noch nicht registriert wurde id
GerätestatusstringStatus des Geräts.
idle bedeutet, dass das Gerät bereit ist
Verarbeitung bedeutet, dass das Gerät ausgelastet und die Funktionalität für einige Zeit eingeschränkt ist
angehalten bedeutet, dass das Gerät nicht funktioniert und ein Eingreifen des Nutzers erforderlich ist
VerbindungsstatusstringStatus der Serververbindung (base_url)
online – Verbindung verfügbar
offline – keine Verbindung
Verbindung – Startschritte werden ausgeführt
nicht konfiguriert – Verbindung wurde noch nicht konfiguriert
Ein registriertes Gerät meldet möglicherweise seinen Verbindungsstatus basierend auf dem Status des Benachrichtigungskanals (z.B. XMPP-Verbindungsstatus).
cs
HerstellerstringName des Geräteherstellers
ModellstringModell des Geräts
SeriennummerstringEindeutige Gerätekennung. In dieser Spezifikation muss dies eine UUID sein. (GCP 1.1-Spezifikation)
(optional) Wir empfehlen dringend, überall dieselbe Seriennummer-ID zu verwenden, damit verschiedene Clients dasselbe Gerät identifizieren können. Beispielsweise kann Drucker, die IPP implementieren, diese Seriennummer-ID im Feld „Drucker-ID“ verwenden.
FirmwarestringFirmwareversion des Geräts
uptimeintAnzahl der Sekunden ab dem Gerätestart.
Setup-URLstringOptional: URL (einschließlich Protokoll) der Seite mit Einrichtungsanleitung
Support-URLstringOptional: URL (einschließlich Protokoll) der Seite mit dem Support, FAQs
URL_aktualisierenstringOptional: URL (einschließlich Protokoll) der Seite mit Anweisungen zur Aktualisierung der Firmware
x-privet-TokenstringWert des X-Privet-Token-Headers, der an alle APIs übergeben werden muss, um XSSI- und XSRF-Angriffe zu verhindern. Weitere Informationen findest du unter 6.1.
APIBeschreibung der APIsListe der unterstützten APIs (siehe unten)
SemantikstatusJSON(Optional) Semantischer Status des Geräts im CloudDeviceState-Format.

api – eine JSON-Liste mit der Liste der über das lokale Netzwerk verfügbaren APIs. Möglicherweise sind nicht alle APIs gleichzeitig über das lokale Netzwerk verfügbar. Beispielsweise sollte ein neu verbundenes Gerät nur die /register API unterstützen:

"api": [
        "/privet/register",
]
Sobald die Geräteregistrierung abgeschlossen ist, sollte das Gerät die /register API nicht mehr unterstützen. Außerdem sollte sich das Gerät beim Dienst erkundigen, welche APIs über das lokale Netzwerk bereitgestellt werden können. Beispiel:
"api": [
        "/privet/accesstoken",
        "/privet/capabilities",
        "/privet/printer/submitdoc",
]

Folgende APIs sind derzeit verfügbar:

  • /privet/register – API für die Geräteregistrierung über das lokale Netzwerk. Weitere Informationen findest du unter /privet/register API. Diese API MUSS ausgeblendet werden, nachdem das Gerät erfolgreich in der Cloud registriert wurde.
  • /privet/accesstoken – API zum Anfordern des Zugriffstokens vom Gerät (weitere Informationen finden Sie unter /privet/accesstoken API).
  • /privet/abilities – API zum Abrufen von Gerätefunktionen (weitere Informationen findest du unter /privet/abilities API)
  • /privet/printer/* – spezifische API für den Gerätetyp „Drucker“. Weitere Informationen finden Sie unter „druckerspezifische APIs“.
Hier ist ein Beispiel für die Antwort „/privet/info“. (Hinweis: Es fehlt die /privet/register API, da dies bereits ein Gerät ist):
{
        "version": "1.0",
        "name": "Gene’s printer",
        "description": "Printer connected through Chrome connector",
        "url": "https://www.google.com/cloudprint",
        "type": [
                "printer"
        ],
        "id": "11111111-2222-3333-4444-555555555555",
        "device_state": "idle",
        "connection_state": "online",
        "manufacturer": "Google",
        "model": "Google Chrome",
        "serial_number": "1111-22222-33333-4444",
        "firmware": "24.0.1312.52",
        "uptime": 600,
        "setup_url": "http://support.google.com/cloudprint/answer/1686197/?hl=en",
        "support_url": "http://support.google.com/cloudprint/?hl=en",
        "update_url": "http://support.google.com/cloudprint/?hl=en",
        "x-privet-token": "AIp06DjQd80yMoGYuGmT_VDAApuBZbInsQ:1358377509659",
        "api": [
                "/privet/accesstoken",
                "/privet/capabilities",
                "/privet/printer/submitdoc",
        ]
}
Hier siehst du ein Beispiel einer /privet/info-Antwort für einen Drucker, der die Tinte nicht mehr verwendet hat (Feld „semantik_status“):
{
        "version": "1.0",
        "name": "Gene’s printer",
        "description": "Printer connected through Chrome connector",
        "url": "https://www.google.com/cloudprint",
        "type": [
                "printer"
        ],
        "id": "11111111-2222-3333-4444-555555555555",
        "device_state": "stopped",
        "connection_state": "online",
        "manufacturer": "Google",
        "model": "Google Chrome",
        "serial_number": "1111-22222-33333-4444",
        "firmware": "24.0.1312.52",
        "uptime": 600,
        "setup_url": "http://support.google.com/cloudprint/answer/1686197/?hl=en",
        "support_url": "http://support.google.com/cloudprint/?hl=en",
        "update_url": "http://support.google.com/cloudprint/?hl=en",
        "x-privet-token": "AIp06DjQd80yMoGYuGmT_VDAApuBZbInsQ:1358377509659",
        "api": [
                "/privet/accesstoken",
                "/privet/capabilities",
                "/privet/printer/submitdoc",
        ],
        "semantic_state": {
                "version": "1.0",
                "printer": {
                        "state": "STOPPED",
                        "marker_state": {
                                "item": [
                                        {
                                                "vendor_id": "ink",
                                                "state": "EXHAUSTED",
                                                "level_percent": 0
                                        }
                                ]
                        }
                }
        }
}

4.2.3. Fehler

Die /privet/info API sollte nur einen Fehler zurückgeben, wenn der Header X-Privet-Token fehlt. Es muss ein HTTP 400-Fehler sein:

HTTP/1.1 400 Missing X-Privet-Token header.

4.3. /privet/register API

Die /privet/register API ist OPTIONAL. Es handelt sich um eine HTTP-POST-Anfrage. /privet/register API MUSS auf einen gültigen X-Privet-Token-Header achten. Das Gerät MUSS diese API unter der URL &pritt/register" implementieren:

POST /privet/register?action=start&user=user@domain.com HTTP/1.1
POST /privet/register?action=complete&user=user@domain.com HTTP/1.1

Das Gerät sollte die /privet/register API NUR bereitstellen, wenn die anonyme Registrierung derzeit zulässig ist. Beispiel:

  • Wenn das Gerät eingeschaltet ist (oder nach einem Klick auf eine spezielle Schaltfläche auf dem Gerät) und noch nicht registriert wurde, sollte die /privet/register API verfügbar gemacht werden, damit ein Nutzer aus dem lokalen Netzwerk den Drucker anfordern kann.
  • Nach Abschluss der Registrierung sollte das Gerät die /privet/register API nicht mehr verfügbar machen, um zu verhindern, dass ein anderer Nutzer im lokalen Netzwerk das Gerät zurückfordert.
  • Einige Geräte können auf unterschiedliche Weise registriert werden und sollten die /privet/register API nicht enthalten, z. B. den Chrome Cloud Print Connector.

Die Registrierung umfasst drei Schritte (siehe anonyme Registrierung für Cloud Print).

  1. Anonymen Registrierungsprozess einleiten
  2. Ein Client initiiert diesen Vorgang durch Aufrufen der /privet/register API. Das Gerät wartet dann möglicherweise auf die Nutzerbestätigung.
  3. Anforderungstoken abrufen.

Der Client fragt, ob das Gerät bereit zum Fortfahren ist. Sobald das Gerät bereit ist, sendet es eine Anfrage zum Abrufen des Registrierungstokens und der Registrierungs-URL an den Server. Das empfangene Token und die URL sollten an den Client zurückgegeben werden. Wenn das Gerät in diesem Schritt einen weiteren Aufruf zum Initialisieren der Registrierung empfängt, sollte es so aussehen:

  • Wenn derselbe Nutzer mit der Registrierung begonnen hat, löschen Sie alle bisherigen Daten (falls vorhanden) und starten Sie einen neuen Registrierungsprozess.
  • Wenn dies ein anderer Nutzer ist, geben Sie den Fehler „device_beschäftigt“ und ein Zeitlimit von 30 Sekunden zurück.

Schließen Sie die Registrierung ab.

Nachdem der Client das Gerät beansprucht hat, sollte der Client das Gerät benachrichtigen, um die Registrierung abzuschließen. Nach Abschluss der Registrierung sollte das Gerät eine Update-Benachrichtigung mit der neu erworbenen Geräte-ID senden.

Hinweis: Wenn das Gerät einen /privet/register API-Aufruf verarbeitet, dürfen keine anderen /privet/register API-Aufrufe gleichzeitig verarbeitet werden. Das Gerät MUSS den Fehler „device_beschäftigt“ und ein Zeitlimit von 30 Sekunden zurückgeben.

Eine Nutzerbestätigung für die Registrierung auf dem Gerät wird dringend empfohlen. Nach der Implementierung MUSS das Gerät auf die Nutzerbestätigung warten, NACH der es einen /privet/register?action=start API-Aufruf erhalten hat. Der Client ruft die /privet/register?action=getClaimToken API auf, um herauszufinden, wann die Nutzerbestätigung abgeschlossen ist und das Token verfügbar ist. Wenn der Nutzer die Registrierung auf dem Gerät storniert (z.B. die Schaltfläche „Abbrechen“), muss der Fehler „user_cancel“ zurückgegeben werden. Wenn der Nutzer die Registrierung innerhalb eines bestimmten Zeitraums nicht bestätigt hat, MUSS der Fehler „confirm_timeout“ zurückgegeben werden. Weitere Informationen finden Sie im Abschnitt „Standardeinstellungen“.

4.3.1 Eingabe

Die /privet/register API hat die folgenden Eingabeparameter:
NameWert
AktionEs kann sich um einen der folgenden Typen handeln:
start – um den Registrierungsprozess zu starten
getClaimToken – Anspruchstoken für das Gerät abrufen
cancel – Registrierungsvorgang abbrechen
complete – Registrierungsvorgang abschließen
NutzerE-Mail-Adresse des Nutzers, der Anspruch auf dieses Gerät erhebt.

Das Gerät MUSS überprüfen, ob die E-Mail-Adresse aller Aktionen (start, getClaimToken, abbrechen, abgeschlossen) übereinstimmt.

4.3.2 Zurücksenden

Die /privet/register API gibt die folgenden Daten zurück:
WertnameWerttypBeschreibung
AktionstringDie Aktion entspricht der im Eingabeparameter.
NutzerString (optional)Derselbe Nutzer wie im Eingabeparameter (möglicherweise fehlt, wenn er in der Eingabe weggelassen wird).
TokenString (optional)Registrierungstoken (erforderlich für "getClaimToken" Antwort, weggelassen für "start", "complete", "cancel").
Anspruchs-URLString (optional)Registrierungs-URL (erforderlich für "getClaimToken" Antwort, weggelassen für "start", "complete", "cancel"). Für Cloud Printer muss dies der vom Server erhaltene Parameter sein.
Automatische Anspruchs-URLString (optional)Registrierungs-URL (erforderlich für "getClaimToken" Antwort, weggelassen für "start", "complete", "cancel"). Für Cloud Printer muss dies vom Server automatisch festgelegt werden.
Geräte-IDString (optional)Neue Geräte-ID (ausgelassen für &Antwort; obligatorisch für"abschließen&").

Das Gerät MUSS die Geräte-ID NUR nach Abschluss der Registrierung in der /privet/info API-Antwort zurückgeben.

Beispiel 1:

{
        "action": "start",
        "user": "user@domain.com",
}

Beispiel 2:

{
        "action": "getClaimToken",
        "user": "user@domain.com",
        "token": "AAA111222333444555666777",
        "claim_url": "https://domain.com/SoMeUrL",
}

Beispiel 3:

{
        "action": "complete",
        "user": "user@domain.com",
        "device_id": "11111111-2222-3333-4444-555555555555",
}

4.3.3 Fehler

Die /privet/register API kann folgende Fehler zurückgeben (weitere Informationen findest du im Abschnitt "Fehler"):
FehlerBeschreibung
Gerät_beschäftigtDas Gerät ist ausgelastet und die gewünschte Aktion kann nicht ausgeführt werden. Nach Ablauf des Zeitlimits noch einmal versuchen.
Ausstehende NutzeraktionAls Antwort auf &gettTokenToken geben Sie an, dass dieser Fehler anzeigt, dass die Bestätigung des Nutzers noch aussteht, und die Anforderung nach Timeout noch einmal auszuführen.
Nutzer_AbbrechenDer Nutzer hat den Registrierungsvorgang vom Gerät explizit abgebrochen.
Zeitüberschreitung bei BestätigungZeitüberschreitung bei der Nutzerbestätigung.
ungültige_AktionEine ungültige Aktion wird aufgerufen. Beispiel: Der Client hat action=complete vor dem Aufruf von action=start und action=getClaimToken aufgerufen.
ungültige ParameterDie Anfrage enthält ungültige Parameter. (Unbekannte Parameter sollten aus Gründen der zukünftigen Kompatibilität sicher ignoriert werden.) Geben Sie beispielsweise Folgendes zurück, wenn der Client „action=unknown“ oder „user=“ heißt.
GerätekonfigurationsfehlerDatum/Uhrzeit (oder andere Einstellungen) sind auf dem Gerät falsch. Der Nutzer muss die interne Website des Geräts aufrufen und die Geräteeinstellungen konfigurieren.
OfflinegerätDas Gerät ist derzeit offline und kann nicht mit dem Server kommunizieren.
ServerfehlerServerfehler während der Registrierung
ungültig_x_privet_tokenDas X-Privet-Token in der Anfrage ist ungültig oder leer.

Das Gerät MUSS die Freigabe der /privet/register API nach erfolgreicher Registrierung beenden. Wenn das Gerät die /privet/register API nicht verfügbar macht, MUSS der HTTP-Fehler 404 zurückgegeben werden. Wenn ein Gerät bereits registriert ist, muss beim Aufruf dieser API 404-Fehler zurückgegeben werden. Wenn der X-Privet-Token-Header fehlt, muss das Gerät den HTTP-Fehler 400 zurückgeben.

4.4. /privet/accesstoken-API

Die /privet/accesstoken API ist OPTIONAL. Es ist eine HTTP GET-Anfrage. /privet/accesstoken API MUSS auf einen gültigen Header zugreifen. Das Gerät MUSS diese API unter der URL &pritt/accesstoken" implementieren:
GET /privet/accesstoken HTTP/1.1

Wenn das Gerät den /accesstoken API-Aufruf empfängt, sollte er den Server aufrufen, um das Zugriffstoken für den jeweiligen Nutzer abzurufen und das Token an den Client zurückzugeben. Der Client verwendet dann das Zugriffstoken, um über die Cloud auf dieses Gerät zuzugreifen.

Cloud Print-Geräte MUSS die folgende API aufrufen:

/cloudprint/proximitytoken
und übergeben Sie den Parameter "printerid=<printer_id>" und "user" aus der lokalen API. Wenn der Vorgang erfolgreich war, enthält die Serverantwort das folgende Objekt:
"proximity_token": {
        "user": "user@domain.com",
        "token": "AAA111222333444555666777",
        "expires_in": 600
}
Cloud Print-Geräte MÜSSEN den Wert des Objekts „"sustainability_token"“ in der Antwort an lokale /privet/accesstoken API-Aufrufe übergeben. Es ist vorteilhafter (zukunftssicher), wenn das Gerät ALLE Parameter übergeben kann (einschließlich der, die in dieser Spezifikation nicht beschrieben werden).

4.4.1. Eingabe

Die /privet/accesstoken API hat die folgenden Eingabeparameter:
NameWert
NutzerE-Mail-Adresse des Nutzers, der dieses Zugriffstoken verwenden wollte. Kann in der Anfrage leer sein.

4.4.2. Zurücksenden

Die /privet/accesstoken API gibt folgende Daten zurück:
WertnameWerttypBeschreibung
tokenstringVom Server zurückgegebenes Zugriffstoken
NutzerstringDerselbe Nutzer wie im Eingabeparameter
expires_inintAnzahl der Sekunden, bis das Token abläuft. Vom Server empfangen und in dieser Antwort übergeben.

Beispiel:

{
        "token": "AAA111222333444555666777",
        "user": "user@domain.com",
        "expires_in": 600
}

4.4.3 Fehler

Die /privet/accesstoken-API kann die folgenden Fehler zurückgeben (Details siehe Fehler):
FehlerBeschreibung
OfflinegerätDas Gerät ist derzeit offline und kann nicht mit dem Server kommunizieren.
Zugriff_abgelehntUnzureichende Rechte. Zugriff verweigert Das Gerät sollte diesen Fehler zurückgeben, wenn die Anfrage vom Server explizit abgelehnt wurde.
ungültige ParameterDie Anfrage enthält ungültige Parameter. (Unbekannte Parameter sollten aus Gründen der zukünftigen Kompatibilität sicher ignoriert werden.) Beispiel: Der Client hat /accesstoken?user= oder /accesstoken aufgerufen.
ServerfehlerServerfehler
ungültig_x_privet_tokenDas X-Privet-Token in der Anfrage ist ungültig oder leer.

Wenn das Gerät die /privet/accesstoken API nicht verfügbar macht, MUSS der HTTP-Fehler 404 zurückgegeben werden. Wenn der X-Privet-Token-Header fehlt, muss das Gerät den HTTP-Fehler 400 zurückgeben.

4.5. /privet/features-API

Die /privet/abilities API ist OPTIONAL. Es ist eine HTTP GET-Anfrage. /privet/abilities API MUSS auf einen gültigen &X-Privet-Token-Header prüfen. Das Gerät MUSS diese API auf der folgenden URL implementieren:
GET /privet/capabilities HTTP/1.1
Wenn das Gerät den API-Aufruf /abilities erhält, sollte er sich an den Server wenden, um aktualisierte Funktionen zu erhalten. Wenn ein Drucker beispielsweise die Veröffentlichung eines Druckauftrags (lokal empfangen) über den Cloud Print-Dienst unterstützt, sollte er die Funktionen zurückgeben, die der Cloud Print-Dienst zurückgeben würde. Cloud Print kann in diesem Fall die ursprünglichen Druckerfunktionen ändern, indem neue Funktionen hinzugefügt werden, die vor dem Senden des Auftrags an den Drucker ausgeführt werden können. Am häufigsten wird eine Liste der unterstützten Dokumenttypen verwendet. Wenn der Drucker offline ist, sollte er die unterstützten Dokumenttypen zurückgeben. Wenn der Drucker jedoch online ist und bei Cloud Print registriert ist, muss er als einen der unterstützten Typen „*/*"“ zurückgeben. In diesem Fall führt der Cloud Print-Dienst die erforderliche Konvertierung aus. Für den Offlinedruck muss der Drucker mindestens das Format &image/pwg-raster" unterstützen.

4.5.1. Eingabe

Die /privet/abilities API hat die folgenden Eingabeparameter:
NameWert
OfflinegerätOptional: Nur ""offline=1"" möglich. In diesem Fall sollte das Gerät die Funktionen für die Offlinenutzung zurückgeben, wenn sie sich von den Onlinefunktionen unterscheiden.

4.5.2. Zurücksenden

Die /privet/abilities API gibt Gerätefunktionen im JSON-Format (Cloud Device Description, CDD) zurück. Weitere Informationen finden Sie im CDD-Dokument. Drucker müssen mindestens eine Liste der unterstützten Typen hier zurückgeben. Ein Cloud-fähiger Drucker, der gerade online ist, kann beispielsweise Folgendes zurückgeben (mindestens):
{
        "version": "1.0",
        "printer": {
                "supported_content_type": [
                        {
                                "content_type": "application/pdf",
                                "min_version": "1.4"
                        },
                        { "content_type": "image/pwg-raster" },
                        { "content_type": "image/jpeg" },
                        { "content_type": "*/*" }
                ]
        }
}
Wenn er vom Server getrennt ist, kann er Folgendes zurückgeben:
{
        "version": "1.0",
        "printer": {
                "supported_content_type": [
                        {
                                "content_type": "application/pdf",
                                "min_version": "1.4"
                        },
                        { "content_type": "image/pwg-raster" },
                        { "content_type": "image/jpeg" }
                ]
        }
}

Hinweis: Bei Druckern wird die Priorität der unterstützten Inhaltstypen anhand der Reihenfolge angegeben. In den Beispielen oben gibt der Drucker beispielsweise an, dass er Daten vor und nach „image/pwg-raster“ und „image/jpeg“ bevorzugt. Clients sollten nach Möglichkeit die Priorisierung des Druckers berücksichtigen. Weitere Informationen finden Sie im CDD-Dokument.

4.5.3. Fehler

Die /privet/abilities API kann folgende Fehler zurückgeben (Details findest du im Abschnitt „Fehler“):
FehlerBeschreibung
ungültig_x_privet_tokenDas X-Privet-Token in der Anfrage ist ungültig oder leer.

Wenn das Gerät die /privet/features API nicht verfügbar macht, MUSS der HTTP-Fehler 404 zurückgegeben werden. Wenn der X-Privet-Token-Header fehlt, muss das Gerät den HTTP-Fehler 400 zurückgeben.

4.6. Fehler

Von den oben genannten APIs werden Fehler im folgenden Format zurückgegeben:
WertnameWerttypBeschreibung
FehlerstringFehlertyp (definiert pro API)
TextzeileString (optional)Eine für Menschen lesbare Beschreibung des Fehlers.
server_apiString (optional)Bei einem Serverfehler enthält dieses Feld die fehlgeschlagene Server-API.
ServercodeGanzzahl (optional)Bei einem Serverfehler enthält dieses Feld diesen Fehlercode, den der Server zurückgegeben hat.
server_http_codeGanzzahl (optional)Bei einem Server-HTTP-Fehler enthält dieses Feld einen HTTP-Fehlercode-Server.
timeoutGanzzahl (optional)Anzahl der Sekunden, die der Client vor einem erneuten Versuch warten soll (nur bei wiederholbaren Fehlern). Der Client muss das tatsächliche Zeitlimit von diesem Wert auf einen Wert von + 20 % nach dem Zufallsprinzip ändern.

Alle APIs MÜSSEN den HTTP-Fehler 400 zurückgeben, wenn der X-Privet-Token-Header fehlt.

HTTP/1.1 400 Fehlender X-Privet-Token-Header.

Beispiel 1:

{
        "error": "server_error",
        "description": "Service unavailable",
        "server_api": "/submit",
        "server_http_code": 503
}

Beispiel 2:

{
        "error": "printer_busy",
        "description": "Printer is currently printing other job",
        "timeout": 15
}

5. Drucker-API

Einer der von diesem Protokoll unterstützten Gerätetypen ist „Drucker“. Geräte, die diesen Typ unterstützen, MÖCHTEN einige Funktionen speziell für Drucker implementieren. Im Idealfall erfolgt das Drucken auf cloudfähigen Druckern über einen Cloud Print-Server:

Manchmal muss ein Client ein Dokument lokal senden. Es kann erforderlich sein, wenn der Client keine Google-ID hat oder nicht mit dem Cloud Print-Server kommunizieren kann. In diesem Fall wird der Druckauftrag lokal an den Drucker gesendet. Der Drucker wiederum verwendet den Cloud Print-Dienst, um Jobs in die Warteschlange zu stellen und zu konvertieren. Der Drucker sendet den Job noch einmal lokal an den Cloud Print-Dienst und fordert ihn an, da er über die Cloud gesendet wurde. Dieser Prozess ermöglicht eine flexible Nutzererfahrung (Conversion) sowie Verwaltung/Tracking von Druckaufträgen.

Da der Cloud Print-Dienst die Konvertierung implementiert, DARF der Drucker für alle Eingabeformate ("*/*") in der Liste der unterstützten Inhaltstypen werben:

{
        "version": "1.0",
        "printer": {
                "supported_content_type": [
                        { "content_type": "image/pwg-raster" },
                        { "content_type": "*/*" }
                ]
        }
}

In einigen Fällen ist eine vollständig Offlinelösung erwünscht. Da Drucker eine begrenzte Anzahl von Eingabeformaten unterstützen, muss ein Client Dokumente in einige nativ unterstützte Druckerformate konvertieren.

Diese Spezifikation erfordert, dass alle Drucker mindestens das PWG-Raster-Format ("image/pwg-raster") für den Offline-Druckmodus haben. Ein Drucker unterstützt möglicherweise auch andere Formate, z. B. JPEG. Wenn ein Client dies unterstützt, kann er Dokumente in diesem Format senden. Der Drucker MUSS unterstützte Typen über die /abilities API verfügbar machen. Beispiel:

{
        "version": "1.0",
        "printer": {
                "supported_content_type": [
                        { "content_type": "image/pwg-raster" },
                        { "content_type": "image/jpeg" }
                ]
        }
}
Ein Client kann das Drucken über das lokale Netzwerk starten.

Einfaches Drucken: Der Client sendet das Dokument über das lokale Netzwerk an die /submitdoc API, ohne den Parameter „job_id“ anzugeben. Das eingereichte Dokument wird in den Standardeinstellungen für Drucktickets gedruckt. Ein Druckauftragsstatus ist nicht erforderlich. Wenn der Drucker NUR diese Druckart unterstützt, MUSS NUR in der /privet /info API-Antwort die/submitdoc API beworben werden.

"api": [
        "/privet/accesstoken",
        "/privet/capabilities",
        "/privet/printer/submitdoc",
]

Erweitertes Drucken: Der Kunde sollte zuerst einen Druckauftrag auf dem Drucker erstellen. Dazu ruft er in der Anfrage die API /privet/printer/createjob mit einem gültigen CJT-Jobticket auf. Der Drucker MUSS das Druckticket im Speicher ablegen und eine job_id an den Client zurückgeben. Anschließend ruft der Client die /printer/submitdoc API auf und gibt die zuvor erhaltene job_id an. Dann beginnt der Drucker. Der Client fragt den Drucker nach dem Status des Druckauftrags ab, indem er die /privet/printer/jobstate API aufruft.

In einer Mehrfachkundenumgebung gibt es keine Garantie dafür, wie diese API aufgerufen wird. Ein Client kann /createjob zwischen den /createjob->/submitdoc-Aufrufen eines anderen Clients aufrufen. Um mögliche Deadlocks zu vermeiden und die Nutzerfreundlichkeit zu verbessern, empfehlen wir, eine kleine Warteschlange mit ausstehenden Druckaufträgen auf dem Drucker zu haben (mindestens 3–5):

  • /createjob belegt den ersten verfügbaren Platz in der Warteschlange.
  • Die Lebensdauer des Jobs (in der Warteschlange) beträgt mindestens 5 Minuten.
  • Wenn alle Plätze in der Warteschlange vergeben sind, wird der älteste nicht druckbare Job entfernt und ein neuer wird dort platziert.
  • Wenn auf dem Gerät gerade ein Druckauftrag gedruckt wird (einfacher oder erweiterter Druck), sollte /submitdoc den Status „Belegt“ zurückgeben und eine Zeitüberschreitung vorschlagen, um diesen Druckauftrag noch einmal auszuführen.
  • Wenn sich /submitdoc auf einen Job bezieht, der aufgrund eines Austauschs oder einer Zeitüberschreitung aus der Warteschlange entfernt wurde, sollte der Drucker den Fehler invalid_print_job zurückgeben und der Client wiederholt den Vorgang im Schritt /createjob. Der Client MUSS bis zu fünf Sekunden lang auf ein zufälliges Zeitlimit warten, bevor er es noch einmal versuchen kann.

Wenn aufgrund von Speicherbeschränkungen nicht mehrere ausstehende Aufträge auf dem Gerät gespeichert werden können, ist eine Warteschlange mit einem längeren Druckauftrag möglich. Es sollte immer noch dasselbe Protokoll wie oben verwendet werden. Nachdem ein Job abgeschlossen oder mit einem Fehler fehlgeschlagen ist, sollte der Drucker mindestens 5 Minuten lang Informationen zum Jobstatus speichern. Die Warteschlangengröße zum Speichern abgeschlossener Jobstatus sollte mindestens 10 betragen. Wenn weitere Jobstatus gespeichert werden müssen, kann der älteste vor dem Zeitlimit von 5 Minuten aus der Warteschlange entfernt werden.

Hinweis: Derzeit werden Clients den Auftragsstatus abfragen. In Zukunft kann es erforderlich sein, dass der Drucker eine TXT-DNS-Benachrichtigung sendet, wenn sich der Status von Druckaufträgen geändert hat.

5.1. /privet/printer/createjob-API

/privet/printer/createjob API ist optional (siehe „Einfaches Drucken“ oben). Es handelt sich um eine HTTP-POST-Anfrage. /privet/printer/createjob API MUSS auf einen gültigen X-Privet-Token-Header achten. Das Gerät MUSS diese API unter der URL "&pritt/printer/createjob"" implementieren:

POST /privet/printer/createjob HTTP/1.1
Beim Empfangen des /privet/printer/createjob API-Aufrufs muss der Drucker eine neue Druckauftrags-ID erstellen, das erhaltene Druckticket im CJT-Format speichern und die Druckauftrags-ID an den Client zurückgeben.

5.1.1. Eingabe

Die /privet/printer/createjob API hat in der URL keine Eingabeparameter. Der Text der Anfrage sollte die Ticketdaten des Druckauftrags im CJT-Format enthalten.

5.1.2. Zurücksenden

Die /privet/printer/createjob API gibt die folgenden Daten zurück:
WertnameWerttypBeschreibung
Job-IDstringID des neu erstellten Druckauftrags.
expires_inintAnzahl der Sekunden, für die dieser Druckauftrag gültig ist.

Beispiel:

{
        "job_id": "123",
        "expires_in": 600
}

5.1.3 Fehler

Die /privet/printer/createjob API kann folgende Fehler zurückgeben (weitere Informationen findest du im Abschnitt "Fehler"):
FehlerBeschreibung
ungültig_ticketDas eingereichte Druckticket ist ungültig.
Drucker_beschäftigtDer Drucker ist ausgelastet und kann /createjob derzeit nicht verarbeiten. Nach Ablauf des Zeitlimits noch einmal versuchen.
DruckerfehlerDrucker hat einen Fehlerstatus und erfordert eine Nutzerinteraktion, um das Problem zu beheben. Die Beschreibung sollte eine ausführlichere Erläuterung enthalten (z.B. &„Paper jam“ in Fach 1").
ungültig_x_privet_tokenDas X-Privet-Token in der Anfrage ist ungültig oder leer.

Wenn für das Gerät /privet/printer/createjob nicht verfügbar gemacht wird, MUSS der HTTP-Fehler 404 zurückgegeben werden. Wenn der X-Privet-Token-Header fehlt, muss das Gerät den HTTP-Fehler 400 zurückgeben.

5.2. /privet/printer/submitdoc API

Die /privet/printer/submitdoc API ist erforderlich, um das Drucken über ein lokales Netzwerk (offline oder in Cloud Print) zu implementieren. Es handelt sich um eine HTTP-POST-Anfrage. /privet/printer/submitdoc API MUSS auf einen gültigen X-Privet-Token-Header achten. Das Gerät MUSS diese API unter /privet/printer/submitdoc" url implementieren:
POST /privet/printer/submitdoc HTTP/1.1
Wenn der API-Aufruf „/privet/printer/submitdoc“ empfangen wird, sollte der Drucker beginnen. Wenn das Drucken nicht gestartet werden kann, MUSS der Fehler „printer_beschäftigt“ und eine empfohlene Zeitüberschreitung zurückgegeben werden, damit der Client warten kann, bevor er es noch einmal versuchen kann.

Wenn der Drucker nicht alle Daten in seinem internen Zwischenspeicher enthalten kann, MUSS er die Datenübertragung mithilfe von TCP-Mechanismen verlangsamen, bis ein Teil des Dokuments ausgedruckt wird, sodass ein Teil des Zwischenspeichers wieder verfügbar ist. (Der Drucker kann z. B. windowsize=0 auf TCP-Ebenen festlegen. Dadurch muss der Client warten.)

Das Senden eines Dokuments an den Drucker kann einige Zeit dauern. Der Client sollte den Status des Druckers und des Auftrags (erweitertes Drucken) prüfen können, während er ausgeführt wird. Dazu muss der Drucker dem Client erlauben, die API-Aufrufe „/privet/info“ und „/privet/printer/jobstate“ während der Verarbeitung der API-Aufrufe „/privet/printer/submitdoc“ aufzurufen. Es wird allen Clients empfohlen, einen neuen Thread zu starten, um den /privet/printer/submitdoc API-Aufruf auszuführen, damit der Hauptthread die /privet/info und /privet/printer/jobstate APIs zum Prüfen von Drucker- und Jobstatus verwenden kann.

Hinweis: Nach Abschluss oder dem Abbruch des lokalen Druckauftrags wird dringend empfohlen (und ist in einer zukünftigen Version dieser Spezifikation erforderlich), den endgültigen Status des Auftrags zu Buchhaltungs- und Nutzererfahrungszwecken an die /CHROME/submit-Schnittstelle zu senden. Die Parameter "printerid", "title", "contentType" und "final_mic_state" (im PrintJobState-Format) sind erforderlich, ebenso wie die Parameter "tag" (wiederholter Parameter) und "ticket" (das Ticket des Jobs). Der angegebene PrintJobState-Wert muss tatsächlich endgültig sein, d. h., der Typ muss DONE oder ABORTED sein. Für den Fall, dass er ABORTED ist, muss ein Grund angegeben werden. Weitere Informationen finden Sie unter JobState. Beachten Sie auch, dass diese Verwendung der Schnittstelle /CHROME/submit zum Melden lokaler Druckaufträge nicht in seiner Spezifikation erwähnt wird, da dieser Abschnitt die primäre Verwendung der Schnittstelle beschreiben soll: das Senden eines Druckauftrags mit dem zu druckenden Dokument im Parameter &content.

5.2.1. Eingabe

Das /privet/printer/submitdoc API hat die folgenden Eingabeparameter:
NameWert
Job-ID(Optional) Druckauftrags-ID. Kann für einfaches Druck-Case weggelassen werden (siehe oben). Muss mit dem vom Drucker zurückgegebenen übereinstimmen.
nutzernameOptional: für Menschen lesbarer Nutzername Dies ist nicht endgültig und sollte nur für Anmerkungen von Druckaufträgen verwendet werden. Wenn der Job noch einmal an den Cloud Print-Dienst gesendet wird, sollte dieser String an den Cloud Print-Job angehängt werden.
KundennameOptional: Name der Clientanwendung, die diese Anfrage stellt. Nur zu Anzeigezwecken. Wenn der Job noch einmal an den Cloud Print-Dienst gesendet wird, sollte dieser String an den Cloud Print-Job angehängt werden.
JobnameOptional: Name des Druckauftrags, der aufgezeichnet werden soll. Wenn der Job noch einmal an den Cloud Print-Dienst gesendet wird, sollte er an den Cloud Print-Job angehängt werden.
OfflinegerätOptional: Nur ""offline=1"" möglich. In diesem Fall sollte der Drucker nur offline drucken, also nicht noch einmal auf dem Cloud Print-Server posten.

Der Text der Anfrage muss ein gültiges Dokument zum Drucken enthalten. &content-Length" muss die korrekte Länge der Anfrage enthalten. Der Header „&-Type“ sollte auf „Dokument-MIME-Typ“ festgelegt werden und mit einem der Typen in der CDD übereinstimmen, es sei denn, CDD gibt „*/*"“ an.

Clients wird dringend empfohlen, bei dieser Anfrage einen gültigen Nutzernamen (oder eine E-Mail-Adresse), einen Clientnamen und einen Jobnamen anzugeben. Diese Felder werden nur in Benutzeroberflächen verwendet, um die Nutzererfahrung zu verbessern.

5.2.2. Zurücksenden

Die /privet/printer/submitdoc API gibt folgende Daten zurück:
WertnameWerttypBeschreibung
Job-IDstringID des neu erstellten Druckauftrags (einfaches Drucken) oder die Job-ID, die in der Anfrage angegeben ist (erweitertes Drucken).
expires_inintAnzahl der Sekunden, für die dieser Druckauftrag gültig ist.
JobtypstringInhaltstyp des eingereichten Dokuments
JobgrößeGanzzahl 64-BitGröße der Druckdaten in Byte.
JobnamestringOptional: Gleicher Jobname wie eingegeben (falls vorhanden).

Beispiel:

{
        "job_id": "123",
        "expires_in": 500,
        "job_type": "application/pdf",
        "job_size": 123456,
        "job_name": "My PDF document"
}

5.2.3. Fehler

Die /privet/printer/submitdoc API kann folgende Fehler zurückgeben (weitere Informationen findest du im Abschnitt "Fehler"):
FehlerBeschreibung
Ungültiger_DruckauftragIn der Anfrage ist eine ungültige/abgelaufene Job-ID angegeben. Nach Ablauf des Zeitlimits noch einmal versuchen.
Ungültiger DokumenttypDer MIME-Typ des Dokuments wird vom Drucker nicht unterstützt.
ungültiges DokumentDas eingereichte Dokument ist ungültig.
Dokument_zu_großDas Dokument überschreitet die maximal zulässige Größe.
Drucker_beschäftigtDer Drucker ist ausgelastet und kann das Dokument momentan nicht verarbeiten. Nach Ablauf des Zeitlimits noch einmal versuchen.
DruckerfehlerDrucker hat einen Fehlerstatus und erfordert eine Nutzerinteraktion, um das Problem zu beheben. Die Beschreibung sollte eine ausführlichere Erläuterung enthalten (z.B. &„Paper jam“ in Fach 1").
ungültige ParameterDie Anfrage enthält ungültige Parameter. (Unbekannte Parameter sollten aus Gründen der zukünftigen Kompatibilität sicher ignoriert werden.)
Nutzer_AbbrechenDer Nutzer hat das Drucken über das Gerät explizit abgebrochen.
ServerfehlerFehler beim Posten des Dokuments in Cloud Print.
ungültig_x_privet_tokenDas X-Privet-Token in der Anfrage ist ungültig oder leer.

Wenn für das Gerät /privet/printer/submitdoc nicht verfügbar gemacht wird, MUSS der HTTP-Fehler 404 zurückgegeben werden. Wenn der X-Privet-Token-Header fehlt, muss das Gerät den HTTP-Fehler 400 zurückgeben.

Hinweis: Die /privet/printer/submitdoc API erfordert aufgrund der großen Nutzlast im Anhang möglicherweise eine besondere Handhabung auf Druckerseite. Je nach HTTP-Serverimplementierung und -Plattform kann der Drucker den Socket schließen, BEVOR der HTTP-Fehler zurückgegeben wird. Möglicherweise gibt der Drucker jedoch einen 503-Fehler zurück (anstatt einen „Livet-Fehler“). Drucker SOLLTEn versuchen, Livre zurückzugeben. Allerdings sollte jeder Client, der die Privet-Spezifikation implementiert, Socket Close (keine HTTP-Fehler) und 503-HTTP-Fehlerfälle für die /privet/printer/submitdoc API verarbeiten können. In diesem Fall muss der Client ihn als Privet-Fehler behandeln und der Fehler 15 Sekunden betragen. Um unendliche Wiederholungsversuche zu vermeiden, kann es vorkommen, dass der Client nach einer angemessenen Anzahl von Versuchen (z. B. 3) den Vorgang wiederholt.

5.3. /privet/printer/jobstate API

/privet/printer/jobstate API ist optional (siehe „Einfaches Drucken“ oben). Es ist eine HTTP GET-Anfrage. /privet/printer/jobstate API MUSS auf einen gültigen &Header-Header prüfen. Das Gerät MUSS diese API unter der URL &pritt/printer/jobstate" implementieren:
GET /privet/printer/jobstate HTTP/1.1
Wenn du einen /privet/printer/jobstate API-Aufruf erhältst, sollte ein Drucker den Status des angeforderten Druckauftrags oder den Fehler „invalid_print_job“ zurückgeben.

5.3.1. Eingabe

Die /privet/printer/jobstate API hat folgende Eingabeparameter:
NameWert
Job-IDID des Druckauftrags, für den der Status zurückgegeben werden soll.

5.3.2. Zurücksenden

Die /privet/printer/jobstate API gibt die folgenden Daten zurück:
WertnameWerttypBeschreibung
Job-IDstringID des Druckauftrags, für den der Status angegeben ist.
BundeslandstringEntwurf: Der Druckauftrag wurde auf dem Gerät erstellt. Es wurden noch keine /privet/printer/submitdoc-Anrufe empfangen.
Warteschlange: Druckauftrag wurde empfangen und in Warteschlange gestellt, der Druckvorgang wurde jedoch noch nicht gestartet.
in_progress – Der Druckauftrag wird ausgeführt.
angehalten: Druckauftrag wurde angehalten, kann aber manuell oder automatisch neu gestartet werden.
Fertig: Der Druckauftrag ist abgeschlossen.
abgebrochen: Der Druckauftrag ist fehlgeschlagen.
Textzeilestring(Optional) Für Menschen lesbare Beschreibung des Status des Druckauftrags. Sollte zusätzliche Informationen enthalten, wenn der Status angehalten oder abgebrochen wird. Das Feld semantische_Zustand bietet in der Regel eine bessere und aussagekräftigere Beschreibung für den Client.
expires_inintAnzahl der Sekunden, für die dieser Druckauftrag gültig ist.
JobtypstringOptional: Der Inhaltstyp des eingereichten Dokuments.
JobgrößeGanzzahl 64-Bit(Optional) Größe der Druckdaten in Byte.
JobnamestringOptional: Gleicher Jobname wie eingegeben (falls vorhanden).
Server-Job-IDstring(Optional) ID des vom Server zurückgegebenen Jobs (wenn der Job an den Cloud Print-Dienst gesendet wurde). Ausgelassen für Offlinedruck.
SemantikstatusJSON(Optional) Semantischer Status des Jobs im Format PrintJobState.

Beispiel (Drucken über die Berichterstellung über Cloud Print):

{
        "job_id": "123",
        "state": "in_progress",
        "expires_in": 100,
        "job_type": "application/pdf",
        "job_size": 123456,
        "job_name": "My PDF document",
        "server_job_id": "1111-2222-3333-4444"
}

Beispiel (Fehler beim Offlinedruck):

{
        "job_id": "123",
        "state": "stopped",
        "description": "Out of paper",
        "expires_in": 100,
        "job_type": "application/pdf",
        "job_size": 123456,
        "job_name": "My PDF document"
}

Beispiel (Druckauftrag vom Nutzer abgebrochen):

{
        "job_id": "123",
        "state": "aborted",
        "description": "User action",
        "expires_in": 100,
        "job_type": "application/pdf",
        "job_size": 123456,
        "job_name": "My PDF document",
        "semantic_state": {
                "version": "1.0",
                "state": {
                        "type": "ABORTED",
                        "user_action_cause": {"action_code": "CANCELLED"}
                },
                "pages_printed": 7
        }
}

Beispiel (Druckauftrag wurde wegen Papiermangel beendet). Beachten Sie den Verweis auf den Gerätestatus. Der Client muss die /privet/info API aufrufen, um weitere Details zum Gerätestatus abzurufen:

{
        "job_id": "123",
        "state": "stopped",
        "description": "Out of paper",
        "expires_in": 100,
        "job_type": "application/pdf",
        "job_size": "123456",
        "job_name": "My PDF document",
        "semantic_state": {
                "version": "1.0",
                "state": {
                        "type": "STOPPED",
                        "device_state_cause": {"error_code": "INPUT_TRAY"}
                },
                "pages_printed": 7
        }
}

5.3.3. Fehler

Die /privet/printer/jobstate API kann folgende Fehler zurückgeben (weitere Informationen findest du im Abschnitt "Fehler"):
FehlerBeschreibung
Ungültiger_DruckauftragIn der Anfrage ist eine ungültige/abgelaufene Job-ID angegeben.
ServerfehlerDer Status des Druckauftrags (für in Cloud Print veröffentlichte Druckaufträge) konnte nicht abgerufen werden.
ungültig_x_privet_tokenDas X-Privet-Token in der Anfrage ist ungültig oder leer.

Wenn für das Gerät /privet/printer/jobstate nicht verfügbar gemacht wird, MUSS der HTTP-Fehler 404 zurückgegeben werden. Wenn der X-Privet-Token-Header fehlt, muss das Gerät den HTTP-Fehler 400 zurückgeben.

6. Appendix

6.1. Standardverhalten und -einstellungen

In diesem Abschnitt wird das Standardverhalten erläutert, das wir von ALLEN mit Privet kompatiblen Geräten erwarten.
  • Sofort einsatzbereite Geräte sollten nur die APIs /privet/info und /privet/register unterstützen. Alle anderen APIs (z.B. /privet/accesstoken, lokales Drucken) sollten deaktiviert sein.
  • Die Registrierung erfordert eine physische Interaktion mit einem Gerät.
    • Der Nutzer MUSS auf dem Gerät eine Aktion ausführen (z.B. eine Taste drücken), um den Zugriff auf das Gerät zu bestätigen.
    • Nachdem der Nutzer die oben genannte Aktion ausgeführt hat, sollte der Drucker die Anfrage „/CHROME/register“ senden. Sie sollte diese Anfrage erst senden, nachdem die Aktion ausgeführt wurde (siehe Sequenzdiagramm 1).
    • Wenn das Gerät eine /privet/register-Anfrage verarbeitet (z. B. auf die obige Aktion wartet), müssen alle anderen /privet/register-Anfragen abgelehnt werden. Das Gerät MUSS in diesem Fall den Fehler „device_beschäftigt“ zurückgeben.
    • Das Gerät sollte jede /register-Anfrage, die die oben genannte physische Aktion nicht empfängt, innerhalb von 60 Sekunden mit einer Zeitüberschreitung versehen. Das Gerät MUSS in diesem Fall den „confirm_timeout“-Fehler zurückgeben.
    • Optional: Empfohlen, aber nicht erforderlich. Mit den folgenden Elementen lässt sich die Nutzererfahrung verbessern:
      • Möglicherweise blinkt der Lichtring oder der Bildschirm, um anzugeben, dass der Nutzer etwas tun muss, um die Registrierung zu bestätigen.
      • Der Drucker kann auf seinem Bildschirm angeben, dass er bei Google Cloud Print für den Nutzer abc@def.com registriert wird. Klicken Sie auf „OK“, um fortzufahren. Dabei ist abc@def.com der Nutzerparameter des API-Aufrufs /register. Dadurch wird für Nutzer deutlicher, dass
        • die Registrierungsanfrage bestätigt,
        • was passiert, wenn er die Anfrage nicht ausgelöst hat.
      • Zusätzlich zu einer Aktion durch den Drucker (z.B. „Drücke die Taste auf ‚OK‘“, kann ein Drucker dem Nutzer auch eine Schaltfläche zum Abbrechen der Anfrage anbieten (z.B. „Abbrechen“. So können Nutzer, die die Registrierungsanfrage nicht vor Ablauf der 60 Sekunden abgebrochen haben, abbrechen. Das Gerät MUSS in diesem Fall den Fehler „user_cancel“ zurückgeben.
  • Übertragungen von Eigentumsrechten:
    • Das Gerät kann explizit aus dem Cloud-Dienst gelöscht werden.
      • Wenn das Gerät Erfolg hat, aber aufgrund eines /CHROME/printer (für GCP)-Aufrufs keine Gerätebeschreibung angezeigt wird, MUSS es auf den Standardmodus (Standard-Standardeinstellung) zurückgesetzt werden.
      • Wenn die Anmeldedaten des Geräts nicht mehr funktionieren (ausdrücklich aufgrund von ungültigen Anmeldedaten), muss das Gerät auf den Standardmodus (Standardkonfiguration) zurückgesetzt werden.
    • Beim Zurücksetzen auf die Werkseinstellungen MÜSSEN die Anmeldedaten des Geräts gelöscht und der Standardstatus festgelegt werden.
    • Optional: Möglicherweise gibt es ein Menüelement, mit dem Anmeldedaten gelöscht und der Standardmodus aktiviert wird.
  • Geräte, die XMPP-Benachrichtigungen unterstützen, MÜSSEN auch die Möglichkeit haben, den Server anzupingen. Das Ping-Zeitlimit MUSS vom Server über "local_settings" gesteuert werden.
  • Das Gerät kann (zusätzlich zu XMPP-Pings) nicht häufiger als einmal täglich (24 Stunden) an den Server (/CHROME/Drucker-API für die GCP) pingen, um sicherzustellen, dass beide synchronisiert sind. Es wird empfohlen, das Prüffenster innerhalb von 24 bis 32 Stunden zufällig auszuwählen.
  • Optional: Für Cloud Print-Geräte wird empfohlen, dass es keine manuelle Methode (Schaltfläche) gibt, damit der Nutzer auf neuen Geräten Druckaufträge ausführen kann. Einige Drucker haben das bereits.
  • Optional. Unternehmensdrucker haben möglicherweise die Möglichkeit, die lokale Erkennung vollständig zu deaktivieren. In diesem Fall MUSS das Gerät diese lokalen Einstellungen auf dem Server aktualisieren. Neue lokale Einstellungen MÜSSEN leer sein. Wenn Sie "local_discovery" auf "false" setzen, kann sie über den GCP-Dienst wieder aktiviert werden.

6.1.2 Diagramm zur Standardregistrierung

6.2. Angriffe und Prävention von XSSI und XSRF

In diesem Abschnitt wird erläutert, ob XSSI- und XSRF-Angriffe auf das Gerät möglich sind und wie man sich davor schützt (einschließlich Verfahren zur Tokengenerierung).
Weitere Informationen finden Sie hier: http://www.security.blogspot.com/2011/05/website-sicherheits-for-webmasters.html
Normalerweise sind XSSI- und XSRF-Angriffe möglich, wenn eine Website Cookie-Authentifizierungsmechanismen verwendet. Obwohl Google keine Cookies mit dem Cloud Print-Dienst verwendet, sind solche Angriffe dennoch möglich. Der lokale Netzwerkzugriff vertraut Anfragen implizit.

6.2.1. Logo: XSSI

Es ist möglich, dass eine schädliche Website die IP-Adresse und Portnummer eines Privet-kompatiblen Geräts erraten und die Privet API mithilfe von <script>-Tag aufrufen kann:
<script type="text/javascript" src="http://192.168.1.42:8080/privet/info"></script>
Schade Websites könnten ohne das API API-Aufrufe ausführen und auf Ergebnisse zugreifen.
Um diese Art von Angriff zu verhindern, MÜSSEN ALLE Privet API-Aufrufe in der Anfrage den Header „X-Privet-Token“ anfordern. Mit Skript-Tags können keine Header hinzugefügt werden, um Sie vor solchen Angriffen zu schützen.

6.2.2. Logo: XSRF

http://en.wikipedia.org/wiki/Cross-site_request_forgery
Es ist möglich, dass eine schädliche Website die IP-Adresse und Portnummer eines Privet-kompatiblen Geräts erraten und versucht, die Privet API mithilfe eines <iframe>-Formulars oder eines anderen websiteübergreifenden Lademechanismus aufzurufen. Angreifer könnten nicht auf die Ergebnisse der Anfrage zugreifen. Wenn die Anfrage jedoch eine Aktion ausführen würde (z. B. Drucken), könnte sie die Aktion auslösen.

Um diesen Angriff zu verhindern, benötigen wir den folgenden Schutz:

  • /privet/info API für XSRF geöffnet lassen
  • /privet/info API DARF KEINE Aktionen auf dem Gerät ausführen
  • Verwenden Sie das /privet/info-API, um ein x-privet-Token zu erhalten.
  • Alle anderen APIs MÜSSEN auf ein gültiges x-Prvet-Token im Header achten.
  • Das x-privet-Token DARF nur 24 Stunden lang gültig sein.

Selbst wenn ein Angreifer die /privet/info-API ausführen kann, kann er kein x-privet-Token aus der Antwort lesen und damit auch keine andere API aufrufen.

Es wird dringend empfohlen, das XSRF-Token mit dem folgenden Algorithmus zu generieren:

XSRF_token = base64( SHA1(device_secret + DELIMITER + issue_timecounter) + DELIMITER + issue_timecounter )

Elemente der XSRF-Tokengenerierung:

  • DELIMITER ist ein Sonderzeichen, in der Regel „:“
  • issue_timecounter ist die Anzahl an Sekunden, die seit einem Ereignis (Epoche für Zeitstempel) oder dem Gerätestart (bei CPU-Zählern) vergangen ist. issue_timecounter erhöht sich kontinuierlich, wenn das Gerät betriebsbereit ist (siehe Token-Bestätigung unten).
  • SHA1: Hash-Funktion des SHA1-Algorithmus
  • base64 – base64-Codierung
  • device_secret – spezifisch für das Gerät Das Geräteschlüssel muss bei jedem Neustart aktualisiert werden.

Empfohlene Möglichkeiten zum Generieren des Geräteschlüssels:

  • Bei jedem Neustart eine neue UUID generieren
  • Bei jedem Neustart eine 64-Bit-Zufallsnummer generieren

Das Gerät muss nicht alle von ihm ausgestellten XSRF-Tokens speichern. Wenn das Gerät ein XSRF-Token auf Gültigkeit prüfen muss, sollte es das base64-Token decodieren. Rufen Sie den issue_timecounter aus der zweiten Hälfte (Klartext) ab und erstellen Sie den SHA1-Hash-Wert device_secret + + issue_timecounter, wobei issue_timecounter aus dem Token stammt. Wenn der neu generierte SHA1 mit dem im Token übereinstimmt, muss das Gerät jetzt prüfen, ob der issue_timecounter innerhalb des Gültigkeitszeitraums (24 Stunden) des aktuellen Zeitzählers liegt. Dazu zieht das Gerät den aktuellen Zeitzähler (z. B. CPU-Zähler) von issue_timecounter ab. Das Ergebnis MUSS die Anzahl der Sekunden seit dem Tokenproblem sein.

Wichtig:Dies ist die empfohlene Methode zum Implementieren des XSRF-Schutzes. Clients der Privet-Spezifikation versuchen nicht, das XSRF-Token zu verstehen, sondern werden als Blackbox behandelt. Abbildung 6.2.3 zeigt eine empfohlene Methode zur Implementierung des X-Privet-Tokens und die Bestätigung einer typischen Anfrage.

Diagramm: 6.2.3 X-Privet-Tokenerstellung und Überprüfungssequenz

6.3 Workflowdiagramme

In diesem Abschnitt wird ein Workflow in verschiedenen Fällen veranschaulicht.

6.3.1 Sofort einsatzbereiter Drucker

6.3.2 Registrierter Drucker wird gestartet

6.3.3 Umgang mit XMPP-Benachrichtigungen

6.3.4 Workflow der Druckereinstellungen prüfen