🚀 go-pugleaf

Tops

- Internetvortrag
- Selbstverstaendnis der Gatebau
- Paradigmen
Mittag
- MsgID-Splitting
- Envelope-Adressen
- Definition Metamails
- Arbeitsgruppen
  - Zconnect
  - Z38/ArtNet/QuickMail
  - Fido
  - Maus
  - MagicNet/SevenNet/ProNet/LightNet
ANHANG:
- Teilnehmerliste

1. Internet
-----------
- Begriffsdefinitionen

Internet            : Int-based-Networks (z.B. Inter-EuNet)
                      400 Netze, 600000 Rechner, 10Mio. Benutzer
                      Schichten: Interface-Layer  (definiert Medien)
                                 Internet-Layer   (Adressierung 
                                             32 Bit -> Networkreil
                                                       Hostteil
                                             Klasse A:  7:23 (fuehrende 0)
                                                    B: 14:16 (fuehrende 10)
                                                    C: 21:8  (fuehrende 110)
                                  Transport-Layer (Routen)
                                                  (IP-Protokoll,
                                                   ICMP-Protokoll)
                                  Applikation-Layer (Host to Host-Verbindung)

                      Geschichte: Aloah-Net
                                  ArpaNet => ArpaInterNet
                                  InterNet

                      Organisation: IAB         IETF (InterNet Engineering Task Force
                                     |          IERFF InterNet Engineering
                                     +- RFC-Editor -- IANA
                                       Stati    a.) Proposed    (Verlautbarung)
                                       der      b.) Drafed      (Diskussion)
                                       RDC      c.) IN Standard
                                                d.) obsolate    (ueberholt)
                                       naehere Infos: RFC1060, 
                                                        1011, 
                                                        1009, 
                                                        1122, 
                                                        1123
                      Mailrouting: Direkte Zustellung
                                   Maps (Verbindung der Rechner, daraus wurden
                                         die Routen erstellt)
                                   DNS/X.500 -> schneller Verkehr
                                   Domain       kein direktes Routing
                                   Networkinformation
                                   Server  (Datenbank: DE_NIC [Deutschland], 
                                                       kennt alle Domains/
                                                       Rechner
                                            Die Anfrage wird entlang der Domain 
                                            bis zum Ziel verfolgt, zurueck 
                                            kommen die Adressen (IP-Nummer. 
                                            Z.B. pri 10 sol.ccc.de 
                                                 pri 100 arbi.uni.ol.de)
                                            Es handelt sich hierbei um MX-
                                            Eintraege (Mail Exchanger)
                                            Die Quelle versucht dann, die 
                                            Nachricht zu den einzelnen 
                                            Adressen zu senden, bis es klappte
                                           
                                   terra.sol.ccc.de (alt)
                                   terra@sol.uucp (veraltet)
                                   terra@sol.utexas.edv
                                   terra@sol.ccc.de
                      Verbindungen: Repeater (sendet nur Bits)
                                    Bridges  (local Area Networks)
                                    Router   (verbindet Lans mit Wans [auch 
                                              Lan-Lan])
                                    Relay    (verbindet Netze mit verschiedenen
                                              Protokollen)
                                    Gateway  (verbindet administrative Netze)
                                      Die Gateways zw. Mailboxnetzen sind
                                      haeufig Relays und Gateways gleichzeitig,
                                      da einerseits der administrative Bereich
                                      (Maggi und Z-Netz) und andererseits das
                                      Protokoll (MagicDOC und NetCall) 
                                      umgesetzt wird.
UUCP                : UUCP-based-Networks
technische Netzwerke: Technische Netzwerke unterscheiden sich in ihrem 
                      Pollformat (Beispiel: Z-Netz besteht aus den technischen
                                            Netzwerken NetCall3.8, Zconnect
                                            und RFC)
logische Netzwerke  : Logische Netzwerke unterscheiden sich durch ihre Admini-
                      stration (Beispiel: jede Domain im UseNet,
                                          MagicNet und SevenNet)
Remote Job Entry    : Rechner a schickt einen Batch an den Rechner b, Rechner b
                      fuehrt diesen Batch aus und meldet die Ergebnisse an 
                      Rechner a zurueck (Beispiel: UUCP)
Conferenzing Systems: beliebige Chatsysteme, die vernetzt sind
                      (Beispiel: BitNet-Relay-Chat,
                                 InterNet-Relay-Chat)

2. Selbstverstaendnis der Gatebau
--------------------------------
Aus obiger Definition geht hervor, das die bisherige Gatebau eigentlich eine 
Relaybau war. Es stellt sich jetzt jedoch die Frage, ob die Gatebau auch 
administrative Fragen klaeren soll, da sich beide Seiten beeinflussen. 
Prinzipiell macht die Gatebau nur Empfehlungen - sie ist keine Kontrollinstanz.
An der Gatebau'90 nahmen vier Netze teil. Dort wurden die technischen Voraus-
setzungen fuer saubere Gates definiert und im folgenden Jahr realisiert. 
Verschiedene Ungereimtheiten wurden auf der Gatebau'91 beredet, leider 
existiert kein Protokoll (allenfalls in Fragmenten).
Die Vorstellungen ueber die Aufgaben der Gatebau gehen von Diskussionsforum 
bezueglich Probleme bis zum Entwickeln von definierten Richtlinien, um 
Gateprogrammierern ihre Arbeit zu erleichtern. 
Die Entscheidung, ob die Empfehlungen der GateBau in den einzelnen Netzen 
akzeptiert werden, ist z.Zt. den einzelnen Netzen ueberlassen.

Sinn der Gatebau
a.) Wenn ein neues Netz an einen Verbund geht, muss es sich informieren, 
    was bisher wie warum geloest wurde um das Konzept zu verstehen.
b.) Die GateBau KANN keine definierte Loesung anbieten, weil dies voraussetzt, 
    dass es nur Netze gibt, die komplett fertig entwickelt wurden. Die GateBau 
    kann naturgemaess nur die Obermenge der Faehigkeiten eines Gates definieren, 
    welches zwei zu der Zeit der Gatebau existierende Netzen mit der aktuellen 
    Struktur verbinden soll (Stichwort Metamail)
c.) In der Dokumentation der Gatebau sollte expliziet erklaert werden, dass die 
    Dokumentation keinen Anspruch auf Vollstaendigkeit und immerwaehrende 
    Gueltigkeit erhebt.
d.) Das Problem der GateBau ist es auch, dass fast niemand der Teilnehmer von 
    seinem Netz explizit beauftragt wurde, sich um die Gateproblematik zu 
    kuemmern - von den Anwesenden Gateway-Beauftragten mal abgesehen.

3. Paradigmen
-------------
- Nicht alles, was technisch machbar ist, soll auch ermoeglicht werden (Zitat 
  Terra)
- Benutzer sollen ohne Probleme Gates benutzen koennen, also ohne sich vorher 
  darueber informieren zu muessen, wie Messages im Zielnetz verteilt werden, 
  welches Gate benutzt wird, welche Besonderheiten beruecksichtigt werden
  muessen, ...
- Dupes muessen verhindert werden
  Problem: Ein Netz ist ueber mehrere Gates mit einem anderen Netz verbunden.
           Node A schreibt einen Artikel, der ueber Gate zum anderen Netz 
           wandert. Gleichzeitig wandert die Nachricht in dem eigenen Netz 
           zum anderen Gate und kann von dort aus ebenfalls das Netz wechseln. 
           Ergebnis: Dieselbe Message befindet sich zweimal im Zielnetz. Dies 
           gilt es zu verhindern.
  Loesung: a.) administrativ: Es wird geklaert, welches Gate welche Bretter 
                              austauscht
           b.) technisch    : Es werden einheitliche Message-IDs generiert und
                              das Zielnetz killt die Dupes

Es gibt verschiedene Gateway-Typen:

  Art    Ziel                  Anforderungen
-----------------------------------------------------------------------------
   n     Fremdsysteme an ein   Es muessen Zustaendigkeits- und Ver-
         Netz anschliessen     teilungsbereiche geschaffen werden

  n+1    Fremdsysteme an ein   Es muss ein Zustaendigkeitsbereich ge-
         Netz anschliessen     schaffen werden, die Verteilung geschieht
         wilde Verteilung      wild. Daraus folgt: Einheitliche Message-
                               ID (nach GateBau), einheitliche Brettnamen

  n+2    gemischte Verteilung  Es muss ein Zustaendigkeitsbereich ge-       
         eines Netzes          schaffen werden, die Verteilung geschieht  
                               wild. Daraus folgt: Einheitliche Message-  
                               ID (nach GateBau), einheitliche Brettnamen 
                               Datenabgleich

  n+3    Transit               100% Transparenz


3.) MsgID-Splitting
-------------------
Messages werden auf eine Zielnetz-einheitliche Groesse aufgeteilt. Die 
Message-ID wird um einen laufenden Zaehler erweitert. Es muss eine Information
drueber mitgesendet werden, wieviele Teile existieren. Beim Verlassen des
Netzes muss die Mail wieder zusammengebaut werden (siehe Gatebau'91).


4.) Envelope-Adressen
---------------------

  RFC 821       HELO tpki.toppoint.de             physikalischer Absender und 
                MAIL FROM <kris@tpki.toppoint.de> Empfaenger
                RCPT TO: in@individual.net
                DATA
  RFC 822       From: kris@toppoint.de            logischer Absender und 
                To:   in@individual.net           Empfaenger
  RFC 1341-1349 Message-Body
  RFC 821       .
                QUIT

                HELO individual.net
                MAIL FROM: <in-request@individual.net>
                RCPT TO:   terra@sol.ccc.de
                DATA

- Z-Connect
                EMP: terra@sol.ccc.de (Frank Simon)  Empfaenger
                ABS: kris@tpki.toppoint.de           Absender
                WAB: in-request@individual.net       Weiterleitungs-Absender
                KOP: in@individual.net               Kopie-Empfaenger

                U-TO:                                zusaetzliche Info
                U-CC:
5.) Metamail
------------
5.1.) Minimale Header
---------------------
From (Realname)                          Absender
  Beispiel: From: terra@sol.ccc.de (Frank Simon)

To (Realname)/Newsgroups                 Empfaenger
  Beispiel: To: terra@sol.ccc.de (Frank Simon)

Message-Id                               ID der Mail
References (mehrere in eine Zeile [RFC]) Id der Originalmessage
  Beispiel: References: <123456xyz@sol.ccc.de>

X-Format                                 Urspruengliches Netzformat
  Beispiel: X-Format: Netcall 3.8

X-Gateway:                               letztes Gateway
  Beispiel: X-Gateway:  ui@bi-link.owl.de []
           Serviceadresse
                             Programmversion

Adressen werden grundsaetzlich lowercase uebertragen!!

5.2. optionale Header
---------------------
Return-Receipt-To User                   Empfangsbestaetigung 
  Beispiel: Return-Receipt-To: user@system.do.main           
  Jedes Gate meldet in einem solchen Fall, dass die Message das Gate ueber-
  schritten hat. Falls ein Zielnetz keine Empfangsbestaetigung kennt, wird dies
  ebenfalls vom Gate erledigt (siehe GateBau'91).

Reply-To User                            Antwort an einen anderen User
  Beispiel: Reply-To: user@system.do.main
            Reply-To: -

Followup-To Gruppe                       Antwort an eine andere Gruppe
  Beispiel: Followup-To: de.comm.gateway
            Followup-To: poster
            Followup-To: -

X-Error  Meldung                         Fehlermeldungen
  Beispiel: X-Error: unknown user gibbet_nit

X-Mailer Programminfo                    Information ueber den Quell-Mailer
  Beispiel: X-Mailer: Zerberus v5.1+1.0

Expires Datum                            Ab wann kann die Message geloescht werden
  Beispiel: Expires: 13.1.1993 MET

Superseedes Message-Id                   Ersetzt eine alte Nachricht
  Beispiel: Superseedes: <123456xyz@sol.ccc.de> 

X-Valid Datum                            Ab wann ist die Message gueltig
  Beispiel: X-Valid: 10.1.1993 MET

X-Face Bild                              64x64Pixelbild des Absenders


6.) Arbeitsgruppen
------------------
6.1. Zconnect
-------------

6.2. Z38/ArtNet/QuickMail
-------------------------

6.3. Fido
---------

6.4. Maus
---------

6.5. MagicNet/SevenNet/ProNet/LightNet
--------------------------------------

Anhang
======

Anwesenheitsliste
-----------------

Name                   Netz          Funktion                Adresse
---------------------------------------------------------------------------------------------
Ralf Ebert             MagicNet      Gateway-Beauftragter    rae@fussel.ruessel.sub.org
                       SevenNet
                       MausNet
Olaf Boos              SubNet        administrativer         blue_elephant@fussel.ruessel.sub.org
                       SevenNet      Domainverwalter         
                                     'seven.sub.org' und
                                     'ruessel.sub.org'
Martin Biskoping       SubNet        Gateway-Programmierer   marvin@aslan.eh.open.de 
                       SevenNet                             
Gunnar Klauberg        InterNet      Gateway-Programmierer   g.klauberg@cl-hh.comlink.de
                       Z-Net                              
Kristian               InterNet      Genius???               kris@tpki.toppoint.de
                       Z-Net                                
Axel Zinser            InterNet      Domainverwalter         fifi@han.de
                       uucp                                 
Christian Weisgerber   SubNet        Armer User :-(          naddy@mips.ruessel.sub.org
Dirk Meyer             Z-Net         Box-/Gateprogrammierer  dirk_meyer@asco.zer.sub.org
Thorsten Seidel        Fido          Gatewaybetreiber        2:242/55 oder 2:242/99
                       Z-Net        
Andreas Edler          LightNet      Gatewaybetreiber        ae@light.de
                       uucp          Gatewaybeauftragter     
Andreas Wittkemper     Z-Net         Pointprogrammierer      merkur@hot.zer
Hans-Dieter Honka      Pegasus       Gatewayprogrammierer    h.d.honka@bos.bos.sub.org
                       ArNet         Gatewaybetreiber        h.d.honka@bos.zer
                       QuickNet     
Juergen Stessun        MausNet       SysOp                   Juergen Sessun@pe.maus.de
Friedrich Laemmle       MausNet       SysOp                   Friedrich Laemmle@h.maus.de
Sebastian Hetze        In                                    she@soho.in-berlin.de
                       BerlinNet     
R. Heilehaus           In                                    heileh@zelaton.in_berlin.de
                       BerlinNet
Heinz Nopper           BerlinNet     SysOp                   h.nopper@isb.berlinnet.in-berlin.de        
                                     Gatewaybetreiber
Klaus Theiss           Zerberus      SysOp                   sysop@3landbox.comlink.de
                       APC
Uwe Wiesemann          Z-Net         SysOp                   sysop@ldb.comlink.de
                       InterNet
Matthias Watermann     CIS           Programmierer           matthias@olu.zer.de
                       Fido
                       APC
                       CL
Wolfgang Voelkner       MausNet       SysOp                   wpv@wvowl0.han.de
                       uucp          Gatewaybetreiber
Juergen Conradi         MausNet       Postmaster              jc@hb.maus.de
                       uucp
Roman Symann           MausNet       SysOp                   roman@roman.ivart.de
                       uucp
Joerg Stattaus          MausNet       SysOp                   js@ac.maus.de
                                     Gatewayprogrammierer
Kai Henningson         MausNet       SysOp                   kh@ms.mau.de
                                     Gatewayprogrammierer
Michael Keukert        MausNet       SysOp                   mk@ac2.maus.de
                       InterEuNet    Gatewaybetreiber
Goetz Schuckart         Z-Net         SysOp                   sysop@uranus.osko.ks.he.schule.de
                       UseNet        Gatewaybetreiber
Stefan Hellwig         Z-Net         CoSysOp                 sysop@uranus.osgo.ks.he.schule.de
                       UseNet        Betreuung
Dietrich Loebner        UseNet        Domainverantwortlicher  dl@cl-kh.comlink.de
                       Z-Net         'comlink.de'
Volker Ulle            SubNet        Domainverantwortlicher  v.ulle@a-link-h.comlink.de
                       Z-Net         'zer.sub.org'
Ralf Friedrich         ProNet        Netkoordinator          r.friedrich@input.zer.sub.org
                       SevenNet      Gatekoordinator
                       MagicNet      
Frank Simon            uucp                                  terra@sol.ccc.de
                       InterNet
                       Zerberus
Martin Husemann       
Gerald Joerns           Z-Net         ComPaed                  g.joerns@cops.zer
Jan-Erik Meyer-Luetgens UseNet        Beobachter              draco@unidoof.han.sub.org
                       Z-Net
Elmar Lecher           SevenNet      SysOp                   mc.fly@vmb.seven.sub.org
                       Z-Net         Mailbox-Programmierer  
                       Fido