Fussnoten

[kontext] Die tatsächlich recht verbreitete Ausdrucksweise „Ausführung einer Prozedur in einem entfernten Adressraum” ist das Ergebnis von Fehlübersetzungen von Quellen wie [RFC707], Zitat aus Abschnitt „A COMMAND/RESPONSE PROTOCOL, THE BASIS FOR AN ALTERNATIVE APPROACH”, Unterpunkt „(1)” (kritische Formulierung hervorgehoben):

„Before he can address remote processes in terms like the following:
  execute function DELE with argument TEXTFILE
     on machine X
the applications programmer must first [...].”

Das Englische Verb „to address” bedeutet jedoch nicht „adressieren” (das wäre ein „falscher Freund”) sondern „anreden”, also „der eigenen Rede aussetzen” . Insofern kann im allgemeinsten Fall von RPC auch nicht von irgendwelchen (womöglich numerischen) „anderen Adressräumen” gesprochen werden, weil das Konzept der „Adresse” in der somit beschrieben „Grundidee” des entfernten Prozeduraufrufes nicht vorhanden ist.

In diesem Dokument wird deshalb das unbelastetere Wort „Kontext” verwendet.

[paris] Die lokale Ausdehnung einer Vernetzung wichtiger staatlicher Datenbanksysteme ist in Frankreich recht überschaubar, weil sich alle wichtigen staatlichen Einrichtungen auf dem Stadtgebiet von Paris befinden.

[rpc] „walld” (in etwa: „Write-to-All Daemon”) war eine verbreitete Anwendung von ONC RPC in Verbindung mit NFS, mit der entfernte Benutzer von NFS-Verzeichnissen über administrative Shutdowns u.ä. informiert werden konnten. Sicherheitsrisiken durch das Fehlen einer Authentisierung (im allgemeinen Fall) führten zu diversen „Security-Bulletins”, die vom Gebrauch abrieten (siehe z.B. [WALLD]).

[tirpc] IBM, Inc., laut [CSFAQ39] Lizenznehmer von ONC, stellt dies in [IBMTIRPC] so dar:

„Sun Microsystems developed open networking computers (ONC) RPC to easily separate and distribute a client application from a server mechanism. Transport independent remote procedure call (TI-RPC) or ONC+ RPC is the latest version of RPC to be released.”

Hewlett-Packard, Inc. schreibt in [HPTIRPC]:

„TI-RPC makes RPC applications transport-independent by delaying the binding of the application to a specific transport until the program is invoked. Previously, with transport-specific ONC RPC, this binding was done at compile time, meaning that the application could not take advantage of new transports unless the program was rebuilt. [...]”

[oncrpc] ONC RPC v2 weist in der Fassung gemäss RFC1831 zur Fassung in RFC1057 Verbesserungen z.B. beim Datenschutz auf, so wird zB Data Encryption Standard, DES nicht mehr hart codiert als Verschlüsselungsverfahren angegeben. Auch gab es „Kohärenz-Verbesserungen”, so gibt es einen Fehlerzustand „SYSTEM_ERR”, der ausdrückt, dass sich „irgendein anderer Fehler” ereignet hat, der im RPC-Protokoll nicht vorgesehen ist.

[dceonc] [HAUTPNFS] erwähnt zur Konkurrenz zwischen den RPC-Implementationen von ONC und DCE im Abschnitt „1990s” unter anderem:

„[...]. OSF attempted to make DCE RPC an IETF standard, but ultimately proved unwilling to give up change-control. [...]”

[dcefree] Der OSF und ihrer Nachfolgeorganisation, der Open Group wird von manchen Seiten eine unverhältnismässige Zögerlichkeit bei der Offenlegung von DCE vorgeworfen, die der (qualitativ ihren Mitbewerbern möglicherweise überlegenen) DCE-Technologie den Durchbruch zum Industriestandard schlussendlich verunmöglicht habe. Wenn man MSRPC als Implementation von DCE/RPC betrachtet (was angesichts der Anpassungen und Erweiterungen, die oftmals nicht frei zugänglich dokumentiert sind, wohl nicht effektiv geprüft werden kann), so war der DCE-Technologie wenigstens in einem Teilbereich die Etablierung auf einem Massenmarkt vergönnt, nämlich als integraler Teil von Microsoft Windows.

Das LGPL-DCE zeichnet sich übrigens durch ein BSD-make-basiertes Build-System und eine sehr unzugängliche Archivstruktur aus. Die Dokumentation ist eher eine Merkhilfe für eingearbeitete OSF-Programmierer in den frühen 1990er Jahren. Das System ist jedenfalls auf Systemen mit der GNU-Toolchain sowie auf MS Windows nicht ohne Änderungen zu übersetzen.