From: Frank.Simon@sol.ccc.de (Frank Simon)
Newsgroups: de.admin.misc,de.comm.gateways
Subject: GK-Ergaenzung: CoC
Date: 15 Apr 92 12:50:39 +0200
Article-I.D.: sol.3584
Organisation: Solar System, Ls 441, Oldenburg, Germany


		      Code of Conduct for Gateways
		      ----------------------------

Version: 15.4.1992

Definitionen
------------
1-Way-Gateway - es wird eine Bretterhierachie von einen Netz (Urnetz) in ein
    	        anderes Netz (Zielnetz) weitergeleitet. 
2-Way-Gateway - Ein solches Gateway stellt in Wirklichkeit zwei Gateways der
		Art 1-Way-Gateway dar und muss entsprechend auch arbeiten.
Urnetz	      - Das Netz an mensch selbst teilnimmt. 
Zielnetz      - Das Netz welches mit News aus dem Urnetz versorgt wird.
Zustaendigkeit- Ein Gateway fuehlt sich fuer einen geschlossenen und eindeutig
		definiertes Gebiet zustaendig. Dabei ist Gebiet netztopologisch
		und nicht geographisch zu verstehen.

Das 2-Way-Gateway kann also "formal" auf ein 1-Way-Gateway zurueckgefuehrt
werden und daher gelten alle Aussagen die Folgen fuer das 1-Way-Gateway.

(1) Das Gateway hat zu garantieren, dass es nur News in das Urnetz
    weiterleitet, welche aus seinem Zustaendigkeitsgebiet des Zielnetzes
    stammt. Andere News sind nicht weiterzuleiten. 

(2) Als Konsequenz aus (1) folgt: Ein System des Zielnetzes, welches 
    Nachrichten in das Urnetz schickt, muss sich bei dem Gateway angemeldet
    haben. Der Gateway-Betreiber hat dafuer zu Sorgen (z.B. durch Info-
    material), dass der Systembetreiber im Zielnetz ueber die Besonderheiten
    des Urnetzes informiert ist. Dies kann z.B. allgemein die Nettiqette
    sein oder speziell eine Realnamepflicht, etc.

(3) Der Gatewaybetreiber sollte versuchen die Einhaltung der Nettiqette des 
    Urnetzes soweit wie moeglichst technisch abzusichern. Beispielsweise das 
    Abbilden von Realnames oder das erzeugen von FollowUp-To-Zeilen damit 
    Kommentare in Diskussionsgruppen landen, usw.
    Verstoesse gegen die Nettiqette werden von Benutzern oder Betreibern eines 
    Systems im Zielnetz durchgefuehrt. Der Gatewaybetreiber kann dafuer nicht 
    haftbar gemacht werden. Nettiqetteverstoesse werden so behandelt, als 
    waere das System im Zielnetz ein System im Urnetz. Dies bedeutet nix 
    weiter als: Gleiche Behandlung fuer alle. Wer auf einen Zerberus-
    System im Subnet arbeitet (in de.*), dann hat er sich an die dortige
    Nettiqette zu halten.

(4) Der Gatewaybetreiber hat Massnahmen zu ergreifen um folgene Eigenschaft
    zu erfuellen: Auf jede Nachricht muss geantwortet werden koennen, durch
    einfache Benutzung der netzueblichen Kommandos. Beispielsweise muesste
    im Zerberus das Verwenden des Kommandos "ANTWORTEN" und "KOMMENTIEREN" 
    ausnahmslos funktionieren. Diese Aussagen gelten fuer Urnetz und Zielnetz 
    gleichermassen. Der Benutzer muss keine "technische" Massnahmen ergreifen, 
    als die ihm vertrauten um das andere Netz zu erreichen. Die Aufklaerung 
    der Benutzer z.B. ueber die Nettiqette in anderen Bretter/News-Hierachien
    muss durch den Systembetreiber (nicht Gatewaybetreiber) vorgenommen 
    werden.

(5) a) Die technische Implemenation fuer News&Mail der Gateways soll - soweit 
       nicht gute Gruende dagegen sprechen - RFC-konform sein.  
    b) Die GateBau'90 (sobald schriftlich niedergelegt: GateBau '91) ist eine 
       Empfehlung zur Implementation von Gateways, soweit sie nicht 5a wider-
       spricht.
    

Newsgroups: de.admin.misc,de.comm.gateways