Zusammenfassung

  • RFC 1578 beschrieb Terminal-Einwahl, Store-and-Forward, SLIP/PPP und ein geroutetes LAN als verschiedene Zugangsformen mit unterschiedlichen Anwendungen und Betriebsfolgen.
  • Filterung gab einer Schule eine gewisse Kontrolle, aber keine absolute technische Garantie. Insbesondere konnte E-Mail einen verbleibenden Zustellweg bilden.
  • Die Acceptable Use Policy des Providers regelte dessen Verbindung. Zusätzlich brauchte die Schule eigene Regeln, Schulung, Unterstützung, Aufsicht und eine öffentliche Entscheidung über den Zugang von zu Hause.

Hinter dem Anschluss begann eine zweite Infrastruktur

RFC 1578 erschien im Februar 1994. Der Eintrag des RFC Editor weist ihn als Informational RFC und FYI 22 aus, nicht als Protokollstandard. Die Internet School Networking Group richtete ihn an Lehrkräfte, Bibliotheks- und Medienpersonal sowie Verwaltungen von Primar- und Sekundarschulen, die neu angeschlossen waren, indirekt zugriffen oder einen Anschluss erwogen.

Diese Nutzergruppe verfügte laut Dokument häufig über weniger Erfahrung mit Datennetzen und weniger technische sowie nutzerbezogene Unterstützung als andere Internet-Gruppen. Daher reichten die Fragen von Geräten und Kosten bis zu Personal, Unterricht, Sicherheit, Ethik und gemeinschaftlicher Verantwortung.

Das Netz betrat eine Institution, in der Minderjährige, Eltern, Lehrkräfte und Leitung verschiedene Rollen hatten. Der Router konnte diese Rollen nicht zusammenführen. Er konnte lediglich Daten weiterleiten.

Auch bei schulischen Mehrwertdiensten blieb der RFC vorsichtig. Ein Angebot konnte Lernsoftware, Projektkoordination und Support enthalten, ohne sämtliche Internet-Basisdienste bereitzustellen. Wer neben E-Mail auch Telnet und FTP nutzen konnte, war wahrscheinlich „im“ Internet. Das Wort wahrscheinlich ließ die technische Prüfung offen; ein Produktname war kein vollständiger Leistungsnachweis.

Vier Betriebsarten ergaben vier Beweisumfänge

In der kleinen Variante wählte sich ein Computer mit Modem und Terminalemulation bei einem entfernten Dienst ein. SLIP oder PPP machten den Computer in der mittleren Variante tatsächlich zu einem Internet-Host mit TCP/IP-Anwendungen. Eine feste Leitung und ein Router verbanden in der umfassenderen Variante das LAN einer Schule oder Abteilung.

Daneben stand Store-and-Forward mit UUCP. E-Mail und Usenet-Beiträge warteten bis zum geplanten Anruf beim nächsten Rechner. Mailinglisten und manche dateibezogenen Dienste konnten per E-Mail erreichbar bleiben, während interaktive Anwendungen eingeschränkt waren. Das Verfahren nutzte Telefonleitungen sparsam und ließ den Standort auswählen, welche Informationen er transportierte.

Eine funktionierende Terminalsitzung belegte die Erreichbarkeit des fernen Dienstes, nicht einen lokalen IP-Host. Eine PPP-Verbindung belegte die Fähigkeit eines Rechners, nicht die Versorgung aller Räume, ausreichende Kapazität oder einsatzbereite Betreuung. Ein aktiver Router belegte einen Pfad für das LAN, nicht die Funktionsfähigkeit der benötigten Unterrichtsanwendung. Eine später zugestellte Nachricht belegte keine Echtzeitkommunikation.

Wer alle Varianten in einem Feld „Schule angeschlossen“ zusammenfasste, verlor Ausgangsort, Konto, Anwendung, Zeitpunkt, Last und beobachtetes Ergebnis. Die physische Verbindung und der nutzbare Dienst waren getrennte Tatsachen.

Schulung und Unterstützung waren keine Zubehörteile

RFC 1578 bezeichnete Schulung als einen häufig vernachlässigten Bestandteil schulischer Technikpläne. Fehlende Schulung konnte den Plan scheitern lassen. Lehrkräfte, Bibliothekspersonal, Schüler, Verwaltung und weitere Beschäftigte benötigten Vorbereitung.

Beim Train-the-Trainer-Modell lernte zunächst eine kleine motivierte Gruppe und passte die Weitergabe an die Bedürfnisse der Kollegen an. Technische Unterstützung konnte auf Bezirksebene, durch Freiwillige aus Wirtschaft oder Verwaltung, durch den Provider oder teilweise aus der Ferne über das Netz erfolgen.

Der frühere RFC 1359 ordnete diese Seite für Institutionen allgemein. Sein offizieller Eintrag beschreibt ihn als Leitfaden zu erwartbaren Aufgaben beim Anschluss. Er trennte harte Kosten für Leitungen, Modems und Router von weichen Kosten für Ausbildung, Supportstrukturen und Anwendungen. Planung, Start, Produktion und Bewertung beziehungsweise Ausbau waren ebenfalls eigene Phasen.

Eine Schule konnte somit eine laufende Leitung und gleichzeitig eine unbezahlte Supportschuld besitzen. Ein engagierter Pionier konnte ohne Nachfolge arbeiten. Eine Richtlinie konnte veröffentlicht sein, ohne dass Nutzer sie anwenden konnten. Der Linkstatus enthielt keinen dieser Nachweise.

Der Filter beherrschte nicht seine Umgehungswege

RFC 1578 nannte Filterung als Vorteil von Store-and-Forward: Die Schule erhielt eine gewisse Kontrolle über verfügbare Informationen. Derselbe Text stellte jedoch fest, dass bei direktem und häufig auch bei indirektem Zugang keine technische Lösung sämtlichen Zugriff auf für Kinder ungeeignetes Material verhindern konnte.

E-Mail machte den Restweg konkret. Selbst wenn ein Repository oder eine Newsgruppe lokal nicht angeboten wurde, konnte jemand Inhalt als Nachricht senden. Kontrolle über eine Zustellfläche war keine Kontrolle über alle verbliebenen Pfade.

Das entwertete Filter nicht. Ein blockierter Abruf zeigte, dass eine Regel an einem bestimmten Kontrollpunkt zu einem bestimmten Zeitpunkt griff. Er zeigte nicht, dass E-Mail erfasst war, kein zweites Konto existierte oder ein anderer Dienst denselben Inhalt nicht erreichen konnte. Der Nachweis musste auf den getesteten Umfang begrenzt bleiben.

Der RFC ergänzte technische Maßnahmen deshalb um klare Regeln und Folgen, Ethikunterricht und angemessene Aufsicht. Zeit und Gelegenheit des Zugangs konnten beschränkt werden; verantwortlichen Umgang regulär zu lehren, galt als wünschenswerter als alleinige Überwachung. Eine Restunsicherheit blieb ausdrücklich bestehen: eine absolute Garantie war nahezu unmöglich.

Provider-AUP und Schulordnung hatten verschiedene Auftraggeber

Der Zugangsprovider sollte seine Acceptable Use Policy erklären. Sie konnte illegale und je nach Netz auch kommerzielle Nutzung verbieten. Sie galt für den von ihm betriebenen Anschluss.

RFC 1578 erklärte zusätzlich eine schulweite Richtlinie für unerlässlich. Der Provider entschied nicht, welcher Schüler ein Konto erhielt, wie eine Quelle in den Unterricht gelangte, wann Aufsicht erforderlich war, welche schulischen Folgen ein Verstoß hatte oder wie Eltern beteiligt wurden.

Beim Heimzugang wurde die Übergabe deutlich. Technische Verfügbarkeit beim Provider beantwortete nicht, ob die Schule Schülern diese Möglichkeit geben sollte. Der RFC empfahl eine öffentliche Besprechung zwischen Schule und Gemeinschaft, weil Eltern und Pädagogen Verantwortung für die Begleitung teilten. Möglichkeit, Erlaubnis und Verantwortung waren getrennt.

Ein Beleg für jede Behauptung

Konnektivität verlangt Angaben zu Zugangsart, Endpunkt, Leitungszustand und erreichtem Dienst. Fähigkeit verlangt einen Test der konkreten Anwendung vom vorgesehenen Ort und Konto. Schulung verlangt Teilnehmer und vorgeführte Aufgaben. Eine Richtlinie verlangt Entscheidungsgremium, Version, Datum und Geltungsbereich. Ein Filter verlangt Tests der erfassten Pfade und eine Liste der Restwege. Ein Ereignis verlangt Konto, Nachricht oder Sitzung, Zeitpunkt und Reaktion.

Die Providerrechnung belegt keine Lehrkompetenz. Ein Netzwerktest belegt keine E-Mail-Filterung. Ein Regeltext belegt kein Verständnis. Eine Sperre belegt nicht das Fehlen eines Alternativwegs. Ein Einzelfall beschreibt nicht den Normalbetrieb aller Nutzer.

RFC 1578 begrenzte auch seine eigene Dauer. Das Internet veränderte sich rasch; selbst als stabil ausgewählte Dienste konnten veralten. Künftige Überarbeitungen sollten die FYI-Nummer behalten, aber eine neue RFC-Nummer erhalten. Das Dokument verstand sich als revidierbare Hilfe, nicht als dauerhafte Instanz über den Schulen.

Der Anschluss war fertig. Entscheiden, schulen, unterstützen, beobachten und überarbeiten musste die Schule weiterhin selbst.

Quellen