News

Cloud ist sexy! Sofort eingerichtet, Wartung und Pflege ist ausgelagert, Ressourcen skalieren ohne Zutun und in vielen Fällen bieten Web-Lösungen mittlerweile Funktionen, die man sich bei Desktop-Lösungen nur wünschen kann.

Seit Google vormacht, wie man online gemeinsam am gleichen Dokument arbeiten kann, merken auch hartgesottene Word-Freaks, dass es bei Textverarbeitung primär um Inhalte geht und diese entstehen nun mal schneller und unkomplizierter, wenn man mit seinen Arbeits- oder StudienkollegInnen direkt am gleichen Text arbeiten kann.

Auch bei Projekt-Management Tools merken selbst die grössten Fans von etablierten Desktop-Lösungen, dass es durchaus praktisch ist, wenn man unkompliziert via Browser den Status eines Tasks aktualisieren kann.

Die Liste solcher Anwendungsfälle liesse sich beliebig erweitern und so erstaunt es nicht, dass immer mehr Workflows ins Web wandern – doch was passiert mit den Daten?

Der Einsatz von Dropbox, Google Docs, SmartSheet und co. hat einen gewichtigen Nachteil: sämtliche Daten wandern in die Hände Dritter und jede Organisation, welche diesen Schritt vollzieht, läuft Gefahr, dass etwelche Firmengeheimnisse in die falschen Hände geraten.

Die Wahl lautet also: die Vorteile der Cloud nutzen oder Datensicherheit garantieren?

Collabora Online – Funktionalität und Datensicherheit

Die Open Source Community hat mit LibreOffice eine Office Suite geschaffen, die längst etabliert ist und in rasantem Tempo weiterentwickelt wird.

Unsere Kollegen bei Collabora zählen zu den wichtigsten Unterstützern dieses Projekts und haben früh erkannt, dass eine webbasierte Lösungen geschaffen werden muss, um auch die neuen Anforderungen an webbasierte Workflows abdecken zu können.

Statt auf Feld 1 neu zu starten und eine komplett neue Office-Lösung für den Browser zu entwickeln, haben die Collabora EntwicklerInnen auf LibreOffice aufgebaut und eine Art Web-Frontend darum gezimmert.

Die so entstandene Lösung ist heisst Collabora Online, ist komplett Open Source, lässt sich auf der eigenen Infrastruktur betreiben und wird durch kommerzielle Support-Dienstleistungen abgerundet.

Wie funktioniert Collabora Online?

Collabora Online besteht im Kern aus einer Server-Komponente, die am einfachsten als eine Art headless LibreOffice beschrieben werden kann.

Dieser Daemon rendert die Dokumente auf dem Server und verwendet dabei die gleiche Code-Basis wie die Desktop Version, nutzt als Zeichnungsfläche jedoch nicht eine GUI, sondern erstellt direkt Bitmap-Repräsentationen der Dokumente. Der Server akzeptiert externe Verbindungen über HTTP(S) und stellt Websockets zur Verfügung, über welche die Kommunikation mit dem Browser verläuft.

Im Client läuft eine HTML/JavaScript-Applikation, die im Kern auf leaflet.js aufbaut. leaflet.js ist im Umfeld von Online-Karten entstanden und man darf sich fragen, wo hier der Zusammenhang besteht. Nun, unterteilt man ein Dokument in 256×256 Pixel grosse Segmente und klatscht eine Zoom-Funktion oben drauf, stellt man schnell fest, dass eine online Repräsentationen eines Dokuments durchaus einer Karten-Darstellung gleicht.

Über dieser „Karten-Darstellung“ des Dokuments schwebt eine (transparente) Ebene, über die der Benutzer mit dem Dokument interagiert. Text markieren, Objekte herumschieben, etc. werden dabei auf diesem Layer getätigt und über den Websocket an den Server geschickt.

Der Server-Dienst rendert das Dokument neu und invalidiert die Bereiche des Dokuments, die neu gezeichnet werden müssen. Die neuen Tiles werden an den Browser geschickt und dieser tauscht die nötigen Bereiche entsprechend aus.

Die Roundtrip-Zeit (Client → Server → Client) hat dabei einen grossen Einfluss darauf, wie flüssig sich das Editieren anfühlt. Diesen Text habe ich über Wifi und eine gewöhnliche VDSL-Leitung geschrieben. Beim Tippen fällt die Latenz dabei auf. Die ping-Zeiten zu dem Host betrugen rund 20ms, doch als all zu störend habe ich diesen Lag nicht empfunden. Beim Herumschieben von Bildern fällt es hingegen eher ins Gewicht.

Funktionsumfang

Der angebotene Funktionsumfang umfasst aktuell ein Subset der Möglichkeiten der Desktop-Anwendungen. Sämtliche Basis-Funktionen stehen jedoch zur Verfügung und funktionieren soweit problemlos.

Es spielt keine Rolle, ob man ein Text-Dokument, eine Tabelle oder eine Präsentation bearbeiten will – alle diese Dateitypen werden gleichermassen unterstützt.

Das kollaborative Editieren sticht aus der Lösung natürlich hervor: ein Dokument kann gleichzeitig von mehreren BenutzerInnen editiert werden. Jeder Cursor wird dabei separat angezeit – genau so, wie man es von Lösungen wie Google Docs auch kennt.

Ausblick

Collabora arbeitet intensiv daran, weitere Funktionen von LibreOffice auch im Browser zugänglich zu machen. Bis Ende 2017 sollen in der online Version viele weitere Funktionen dazu kommen – hier profitiert die Lösung natürlich ungemein davon, dass sämtliche Features auf der Server-Seite bereits implementiert sind und „lediglich“ der Frontend Teil um entsprechende Aufrufe ergänzt werden muss.

Test Zugang

Wir führen aktuell intensive Tests durch und sammeln Erfahrungen im Betrieb der Lösung. Gerne erstellen wir dafür auch Test-Zugänge für interessierte Leserinnen und Leser dieses Blogs. Eine Mail an info@adfinis.com genügt – wir übernehmen aber aktuell noch keine Garantien für die Verfügbarkeit des Dienstes! Die Daten liegen aber auf Servern unserer Infrastruktur und wir stellen definitiv keinen Unfug damit an – versprochen! 🙂

Fazit

Collabora Online hat gehöriges Potential! Die von Collabora erstellte Lösung ist simpel und genial. Die Dokumente werden perfekt gerendert und es gibt eine 100%ige Kompatibilität zwischen der Desktop und der online Version. Schon allein dieser Vorteil ist ein USP für sich. Dass man die Lösung im eigenen Datacenter betreiben kann ist jedoch noch weitaus wichtiger als wenn das nicht schon ausreichen würde: das ganze ist Open Source und selbst kommerzielle Support Angebote mit lokalen Partnern sind schon verfügbar.

Einziger Wermutstropfen: die Round-Trip Zeiten werden bei langsamen Verbindungen ein Problem darstellen. Dies lässt sich wohl mit dem gewählten Ansatz auch zukünftig nicht lösen.

Links

• https://www.collaboraoffice.com/solutions/collabora-cloudsuite/
• https://cgit.freedesktop.org/libreoffice/online/
• http://leafletjs.com/

Wer in Python seinen Code testen möchte, sollte sich einmal Pytest als Alternative zu Unittest anschauen.

Pytest ist ein Testing-Framework für Python, welches das Testen sehr einfach und ohne viel Boilerplate ermöglicht. Seine Vorteile liegen in der Einfachheit, automatischem Test-Discovery, modularer Fixtures und intelligenter Fehlerausgabe.

Dieser Blogbeitrag soll einen Überblick und einfachen Einstieg in das Testen mit Pytest geben. Er gibt zuerst eine Übersicht über die Verwendung von Pytest, geht danach darauf ein, wie man Ressourcen für die Tests zur Verfügung stellt und schliesst mit ein paar Tipps und Tricks ab.

Einführung

Tests schreiben

Tests können mit Pytest ganz einfach geschrieben werden. Man benötigt lediglich das Python eigene Assert-Statement. Damit Pytest den Test auch findet, stellt man der Test-Funktion das Präfix `test_` voran:

def test_blog():

assert 1 > 0

Mehr ist zum Testen nicht nötig!

Tests starten

Nach der Installation via pip (`pip install pytest`) oder durch den Paketmanager seiner Wahl kann Pytest grundsätzlich auf zwei Arten gestartet werden:

• mit dem Dateinamen als Argument: `pytest foo.py`
• ohne Argument. In diesem Fall sucht Pytest alle Dateien mit dem Format *\*\_test.py* oder *test\_\*.py* und testet diese

Output

Bei erfolgreichem Test erhält man eine Übersicht über das Test-Resultat:

>======= test session starts =======

platform linux -- Python 3.5.2, pytest-3.0.5, py-1.4.31, pluggy-0.4.0

rootdir: /home/sh/pytest_blog, inifile:

plugins: factoryboy-1.1.6

collected 1 items

first.py .

>======= 1 passed in 0.00 seconds =======

Pytest entfaltet seine Stärke jedoch erst so richtig mit Tests, die nicht funktionieren, indem nach Möglichkeit eine detaillierte Ausgabe gemacht wird, was genau nicht bestanden hat. Sehr schön am Beispiel von zwei Listen, die nicht die selben Elemente enthalten:

def test_list():

>assert [1, 2] == [1, 2, 3]

Resultiert in

def test_list():

> assert [1, 2] == [1, 2, 3]

E assert [1, 2] == [1, 2, 3]

E Right contains more items, first extra item: 3

E Use -v to get the full diff

list.py:4: AssertionError

=============== 1 failed in 0.01 seconds ================

Wie man sieht, liefert Pytest gleich das Element, welches den Fehler verursacht!

Wichtige Optionen

Einige wichtige Optionen von Pytest, die wesentlich beim Gebrauch von Pytest helfen, sind die folgenden:

• `-s` Verhindert das Capturing von Input/Output. Sehr wichtig, da man den Output seiner Print-Statements im normalen Modus nicht sieht oder der Debugger ansonsten nicht gestartet werden kann
• `-k <string>` Dient zum Filtern von Tests. Startet dabei nur diejenigen Tests, die `string` als Substring enthalten
• `-x` Bricht beim ersten fehlgeschlagenen Test ab

Über die Datei pytest.ini können Standardwerte für Pytest konfiguriert werden.

Fixtures

Oftmals benötigen Tests irgendwelche Ressourcen, die zum Testen zur Verfügung stehen müssen. Beispiele hierfür sind Datenbankverbindungen, Config-Files, der Browser für UI-Tests etc. Pytest bietet dafür das Konzept von Fixtures. Man kann sich Fixtures ein wenig wie die `setUp()`- und `tearDown()`-Funktionen von bekannten Unit-Test-Frameworks vorstellen. Jedoch können Pytest-Fixtures viel dynamischer pro Test geladen werden: um eine Fixture in einem Test zu verweden, kann sie lediglich als Argument in der Funktion angegeben werden:

def test_something_fancy(browser):

browser.visit(foo) # browser ist nun eine geladene fixture für diesen test

Um eine Fixture zu erstellen, wird der Decorator `@pytest.fixture` verwendet. Der benötigte Wert wird mit `yield` zurückgegeben. So ist es möglich, dass nach dem yield-Statement die Fixture wieder abgebaut werden kann. Ein Beispiel zur Klärung:

1 import os

2 import sqlite3

3

4 import pytest

5

6 @pytest.fixture(scope='function')

7 def db(tmpdir):

8 file = os.path.join(tmpdir.strpath, "test.db")

9

10 conn = sqlite3.connect(file)

11 conn.execute("CREATE TABLE blog (id, title, text)")

12

13 yield conn

14

15 conn.close()

16

17 def test_entry_creation(db):

18 query = ("INSERT INTO blog "

19 "(id, title, text)"

20 "VALUES (?, ?, ?)")

21 values = (1,

22 "PyTest",

23 "Dies ist ein Blogeintrag")

24

25 db.execute(query, values)

Die Fixture stellt hier eine DB-Verbindung für den Test zur Verfügung und erstellt auch gleich eine Tabelle, die zum Testen nötig ist.

Interessant sind Zeilen 6 und 7: Auf Zeile 6 wird mittels Parameter `scope` festgelegt, wie häufig eine Fixture ausgeführt wird. Zur Verfügung stehen `function`, `class`, `module` und `session`. Wählt man z.B. den Scope `module`, wird die Fixture für das gesamte Modul nur einmal erstellt und anschliessend für jeden Test wiederverwendet. Dies ist sehr praktisch bei Ressourcen, die nicht unbedingt bei jedem Test neu erstellt werden müssen und somit wiederverwendet werden können.

Auf Zeile 7 wird eine weitere Fixture in unserer Fixture geladen, was ohne weiteres möglich ist. In Falle dieses Beispiels ist dies eine Fixture, die von Pytest [mitgeliefert wird](http://docs.pytest.org/en/latest/builtin.html#builtin-fixtures-function-arguments). Sie gibt ein temporäres Verzeichnis zurück das für jeden Test-Aufruf einzigartig ist.

Weitere wichtige Features

Tests parametrisieren

Mit dem Decorator `pytest.mark.parametrize` kann man Tests mit verschiedenen Parametern generieren. Für ein Beispiel erweitern wir den `test_entry_creation` Test von oben:

@pytest.mark.parametrize("id,title,text", [

(1, "House Stark", "Winter is coming"),

(2, "House Lannister", "Hear me Roar"),

(3, "House Martell", "Unbowed, Unbent, Unbroken")

])

def test_parametrized_entry_creation(id, title, text, db):

query = ("INSERT INTO blog "

"(id, title, text)"

"VALUES (?, ?, ?)")

values = (id, title, text)

db.execute(query, values)

So werden nun drei Tests generieren, jeder mit einem anderen Set von Parametern.

Skippen, failen und markieren

Tests können auf verschiedene Arten markiert werden:

• `@pytest.mark.skip(reason=”Not implemented yet”)` bringt Pytest dazu, den Test zu überspringen
• `@pytest.mark.skipif(not os.environ.get(‘CI’, False))` bringt Pytest dazu, den Test zu überpspringen, wenn die Bedingung erfüllt ist
• `@pytest.mark.xfail(reason=”Can’t work yet”)` erwartet, dass ein Test scheitert
• `@pytest.mark.abc` sonstiger Marker. Tests können so beim Aufruf gefiltert werden. Beispiel: starte alle Tests, die mit abc markiert sind: `pytest -m abc`. Um alle Tests zu starten, die *nicht* mit abc markiert sind, kann der `not` Operator benutzt werden: `pytest -m ‘not abc’`

Exceptions erwarten

Wenn Exceptions aus dem getesteten Code erwartet werden, wird dies in Pytest mit einem `ContextManager` gemacht:

def test_exception():

with pytest.raises(Exception):

raise(Exception)
Autouse von Fixtures
Zu guter Letzt, um eine Fixture automatisch in jedem Test zur Verfügung zu stellen, kann dies als Parameter im Decorator übergeben werden. Folgender Code könnte ein Beispiel dafür sein, dass bei jedem Test im Browser ein Login geschieht:

@pytest.fixture(autouse=True)

def session(login_page, browser):

login_page.login()

yield

browser.delete_all_cookies()

Zu guter Letzt…

Für Pytest existieren zum Zeitpunkt von diesem Beitrag etwas über 260 Plugins. Sie erweitern Pytest um jenste Sachen, von witzigen Erweiterungen wie das emoji Plugin, welches die Test-Ausgabe etwas spassiger macht, über erweiterte Checks wie Import-Reihenfolge (Isort) und Syntax Linting mit Flake8, zu Erweiterungen wie die Integration von Selenium oder Splinter. Wem also ein Feature in Pytest fehlt, sollte definitiv ein Blick in die Plugin-Liste werfen – es lohnt sich!

Alles in allem, Pytest macht das Testen so einfach, dass es keine Ausreden für das Vernachlässigen von Tests gibt!

In diesem Blog Post soll es darum gehen, wie ein GitLab hinter einem OpenVPN aufgebaut werden kann. Oft steckt in Daten, welche in einem Git-Repository sind, viel Arbeit und somit auch viel Energie, Zeit und Geld. Wer sich nicht nur auf das Login von GitLab verlassen sondern einen weiteren Schutz davor haben will, kann dies z.B. mit OpenVPN lösen. Die Idee ist, dass der Zugriff auf das GitLab nur noch innerhalb des VPN möglich ist.
Damit die User Administration weiterhin simpel bleibt, wird dabei der OpenVPN Server an die User Datenbank von GitLab angebunden.

Impact

Als negativer Punkt sei hier erwähnt, dass User zuerst einen Account mit Passwort haben müssen, bevor sie auf das GitLab verbinden können. Werden die User von einem Administrator verwaltet, erstellt dieser nur die Accounts, jedoch nicht die Passwörter, da GitLab einen Passwort-Reset-Link versendet. Dadurch kann sich der User aber nicht am System anmelden um sein Passwort zu setzen. Dies bedeutet, es muss in einem ersten Schritt zuerst entweder das Passwort durch den Administrator gesetzt werden (indem er die eigene E-Mail Adresse verwendet und später wechselt) oder der User kann über eine schon bestehende VPN Verbindung (z.B. mit Hilfe der Credentials eines schon vorhandenen Accounts) sein Passwort initial setzen.

Realisierung

Hier wird mit einem Debian 8 gearbeitet, jede andere aktuelle Linux Distribution sollte sich aber sehr ähnlich verhalten.
Zuerst wird ein GitLab installiert, dies ist auf der Webseite von GitLab schon dokumentiert (siehe GitLab-CE Install).
Danach wird ein OpenVPN Server mittels apt-get install openvpn installiert.

Zertifikate erstellen

Wir erstellen Keys und Zertifikate für eine CA und für den VPN Server. Dies geschieht vorzugsweise direkt im Verzeichnis, in welchem die OpenVPN Konfiguration (standardmässig /etc/openvpn) liegt.
Zuerst generieren wir den privaten Key und das Zertifikat der CA.

$ openssl req -x509 -sha256 -nodes -newkey rsa:4096 -keyout ca.key -days 3650 -out ca.pem

Danach erstellen wir einen privaten Key und ein Certificate Signing Request für den Server und signieren diesen mit der CA.

$ openssl req -new -sha256 -nodes -newkey rsa:4096 -keyout server.key -out server.csr  
$ openssl x509 -req -sha256 -CA ca.pem -CAkey ca.key -days 730 -CAcreateserial -CAserial ca.srl -in server.csr -out server.pem  

Es sollte darauf geachtet werden, dass die beiden privaten Keys (.key-Files) nur durch den benötigten User (in diesem Beispiel git) gelesen werden können.

OpenVPN Server Konfiguration

Der OpenVPN Server wird mit folgender Konfiugration erstellt:

port 1194
proto udp
dev tun
ca ca.pem
cert server.pem
key server.key
dh dh4096.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
cipher AES-256-CBC
comp-lzo
user git
group git
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn-debug.log
verb 3
auth-user-pass-verify /etc/openvpn/auth-user.rb via-env
script-security 3
client-cert-not-required

Der OpenVPN Server wird in der oben beschriebenen Konfiguration vom Client keine Zertifikate erwarten, da die User sich nur per Passwort anmelden sollen.
Der OpenVPN Client verifiziert den Server anhand dessen Zertifikat, welches jedem Client bekannt sein sollte.
Die Verifizierung der Usernamen-Passwort-Kombination wird mithilfe eines externen Scripts gelöst. Dieses Script muss bei gültiger Username-Passwort-Kombination 0, und ansonsten 1, zurückgeben. Aufgrund des gitlab-rails Runner muss das Script in der OpenVPN Konfiguration zwingend mit absolutem Pfad angegeben werden, da der Runner ansonsten das Script nicht findet.
Das Script sieht wie folgt aus:

#!/usr/bin/gitlab-rails runner

begin
    if ((User.find_by_username! ENV['username']).valid_password? ENV['password'])
        exit 0
    end
rescue
    exit 1
end

exit 1

DNS

Damit diese Konfiguration funktioniert, sollten zwei DNS Einträge vorhanden sein. Der erste Eintrag wird gebraucht, damit der VPN Client zum Server verbinden kann und der Zweite wird genutzt, um auf das GitLab zu verbinden.
Der DNS Eintrag für den VPN Server hat die Public IP Adresse des Servers hinterlegt. Der DNS Eintrag für GitLab zeigt auf die IP Adresse im VPN Tunnel, im obigen Beispiel ist dies die erste IP Adresse aus dem IP Pool 10.8.0.1.

vpn.example.com.    IN    A    <Server Public IP>
git.example.com.    IN    A    10.8.0.1

OpenVPN Benutzer Konfiguration (CLI basiert)

Der User kann mit folgender Konfiguration zum VPN Server verbinden. Er muss dafür nebst der Konfiguration auch das Zertifikat der CA ca.pem besitzen, damit er den Server verifizieren kann.

dev tun
remote vpn.example.com 1194
nobind
ca ca.pem
tls-client
persist-key
persist-tun
comp-lzo
cipher AES-256-CBC
pull
auth-user-pass
verb 3

OpenVPN Benutzer Konfiguration (NetworkManager)

Es wird ein neues OpenVPN Setup im Network Manager angelegt.
Die “Identity” Konfiguration sollte dabei wie folgt aussehen (Gateway, Username und Password müssen dabei angepasst und als CA Certificate muss das Zertifikat der CA geladen werden):

Danach wird mit dem Button “Advanced…” das Fenster für die erweiterten Optionen geöffnet.
Dort wird der Reiter “General” wie folgt eingestellt (wichtig ist Use LZO data compression):

und der Reiter “Security” folgendermassen (“Cipher” anpassen):

Danach wird das Advanced Options Fenster mit “OK” wieder geschlossen.

Die IPv4 Konfiguration sollte wie folgt aussehen (“DNS” wird hier ausgeschalten, wichtig ist vor allem, dass IPv4 mit “DHCP” eingeschalten ist und die Routes automatisch konfiguriert werden):

Und schliesslich auch noch die IPv6 Konfiguration ausschalten:

Damit sind alle Konfigurationen für VPN gemacht, nach dem Speichern, kann eine Verbindung zum OpenVPN Server aufgebaut und danach innerhalb vom VPN Kanal der GitLab Server angesurft werden.

Der RFC 2119 vom Autor Scott Bradner von der Harvard University in Cambridge, wurde von Jean-Louis Fuchs von der Adfinis SyGroup in die deutsche Sprache interpretiert. Es handelt sich dabei nicht um eine wortgetreue Übersetzung, sondern um eine Interpretation in Deutsch. Das Ziel dieser Interpretation ist es, den RFC 2119 im deutschsprachigen Raum zur Verfügung zu stellen und zu verbreiten.

Der RFC 2119 behandelt die Schlüsselwörter in Dokumenten, um die Anforderung der Spezifikation aufzuzeigen.

Die Originalversion befindet sich auch auf GitHub.

Schlüsselwörter zum Kennzeichnen von Anforderungen

Status dieses Memorandum

Basierend auf RFC 2119 definiert dieses Dokument Schlüsselwörter zum Kennzeichen von Anforderungen. Dies ist keine Übersetzung, sondern eine Interpretation für Deutschsprachige, damit dieses grossartige Werkzeug auch für Deutsche Dokumentationen eingesetzt werden kann.

Zusammenfassung

Im Standardisierungsverfahren werden in vielen Dokumenten Schlüsselwörter verwendet um Anforderungen der Spezifikation aufzuzeigen. Diese Wörter werden oft gross geschrieben. Autoren die diesen Richtlinien folgen, sollten den folgenden Satz am Anfang ihres Dokuments einfügen:

Die Schlüsselwörter "MUSS", "DARF NICHT", "ERFORDERLICH", "SOLL", "VERBOTEN", "NÖTIG", "NICHT NÖTIG", "SOLL NICHT", "EMPFOHLEN", "DARF", "KANN" und "OPTIONAL" werden nach 2119de interpretiert. https://goo.gl/6QZH4J

Beachten Sie dass die Aussagekraft dieser Wörter, durch die Anforderungen des Dokuments in welchem sie verwendet werden, relativiert werden können.

1. MUSS
oder die Schlüsselwörter “ERFORDERLICH” oder “NÖTIG” bedeuten, dass die Definition eine absolute Anforderung der Spezifikation ist.

2. DARF NICHT
oder das Wort “VERBOTEN” Bedeutet, dass die Definition ein absolutes Verbot der Spezifikation ist.

3. SOLL
oder das Adjektiv “EMPFOHLEN” bedeutet, dass es in speziellen Situationen Gründe geben kann, diese Spezifikation zu ignorieren. Natürlich müssen die Auswirkungen voll und ganz verstanden und sorgfältig abgewägt werden, bevor von der Spezifikation abgewichen wird.

4. SOLL NICHT
oder “NICHT EMPFOHLEN” bedeutet, dass es gute Gründe in speziellen Situationen geben kann, dass dieses Verhalten akzeptabel, ja sogar nützlich sein kann. Natürlich müssen die Auswirkungen voll und ganz verstanden und sorgfältig abgewägt werden, bevor von der Spezifikation abgewichen wird.

5. DARF
oder “KANN”, “NICHT NÖTIG” oder das Adjektiv “OPTIONAL” bedeuten, dass dieses Verhalten wirklich optional ist.

Wichtig bei der Definition einer Interaktion oder Protokolls: Ein Anbieter kann entscheiden dieses Verhalten einzuschliessen, weil es das Produkt verbessert oder für einen speziellen Markt erforderlich ist. Ein anderer Anbieter kann dieses Verhalten weglassen. Eine Implementation die dieses Verhalten weglässt MUSS bereit sein, mit einer anderen Implementation welche dieses Verhalten einschliesst, zu interagieren. In der selben Art MUSS eine Implementation die dieses Verhalten einschliesst mit einer Implementation die dieses Verhalten weglässt interagieren können.

Anmerkung fürs Deutsche: Alle Schlüsselwörter DÜRFEN dekliniert und konjugiert werden. Die Grossschreibung ist ausreichend um die Schlüsselwörter zu erkennen. “NICHT” kann mit “KEIN” ersetzt werden, wie es im Deutschen üblich ist.

Abgrenzung

1. Leitlinie für die Verwendung

Die Gebote, die in diesem Memo definiert sind, sollen sparsam und mit Sorgfalt eingesetzt werden. Im speziellen ist es NÖTIG, sie nur dort zu benutzen, wo es für die Interaktion wichtig ist oder um nachteiliges Verhalten auszuschliessen. Sie DÜRFEN KEINE Implementationsdetails vorschreiben, welche unabhängig von der Interaktion sind.

2. Sicherheitsbedenken

Diese Begriffe werden oft verwendet um sicherheitsrelevantes Verhalten zu definieren. Ein MUSS oder SOLL wegzulassen oder etwas zu tun, dass als DARF NICHT oder SOLL NICHT definiert ist, kann subtile Auswirkungen haben. Autoren sollten sich Zeit nehmen, um über Sicherheitsauswirkungen nachzudenken, da die Anwender des Dokuments unter Umständen nicht über die selbe Erfahrung und Hintergrundwissen verfügen.

Danksagung

Ich danke den Autoren des RFCs 2119, welches es mir ermöglicht hat 2119de zu schreiben.

Die Definitionen basieren auf existierenden RFCs. Zusätzlich sind Anmerkungen einer Reihe von weiteren Personen eingeflossen, unter anderem Robert Ullmann, Thomas Narten, Neal McBurnett and Robert Elz.

Autor des original RFCs 2119:

Scott Bradner
email - sob@harvard.edu

Autor:

Jean-Louis Fuchs
email - ganwell@fangorn.ch