🚀 go-pugleaf

Zunaechst sehe ich mich als der zustaendige Papst dazu aufgerufen,
einen der reinen Lehre widersprechenden Wortgebrauch als schreckliche
Haeresie zu brandmarken und zu verdammen...

(also im Sinne von "wehret den Anfaengen - wenn sich Missverstaendnisse,
die diesen Formulierungen entspringen, verbreiten, kann man eh alle
Hoffnung fahren lassen")

In article <5194@unido.informatik.uni-dortmund.de>,
id@unido.informatik.uni-dortmund.de (Ingo Dressler) writes:
|> Schicken Sie einfach eine mail an mirror@Germany.EU.net 
|> (= mirror@unido.uucp) und schreiben Sie Ihre eigene (hoffentlich 
|> korrekte) mail-Adresse (nach dem Muster user@site.uucp oder 
|> user@rechner.site.de, wenn Sie eine Domain-Adresse haben)
        ^^^^^^^^^^^^ !!!!
Unter "site" versteht man meist einen geographisch abgegrenzten Standort,
der mit der restlichen Netzwelt ueber eine (meistens einheitlich benutzte)
Einbindung (was mehrere Leitungen und direkte externe Nachbarn nicht
ausschliesst) kommuniziert. Der Begriff der "site" ist zwar wohl recht
unscharf; er unterscheidet sich aber ausreichend deutlich davon, was
Subdomains in DE erhalten kann. (Die letzten Feinheiten, warum mir auch
"rechner" nicht ganz behagen mag, spare ich mir, da diese doch der
Haarspalterei zu nahe kommen.) Ein Beispiel fuer eine Second-level-Domain,
die wirklich schwer als eine "site" verstanden werden kann, ist GMD.DE
(wer zaehlt die Aussenstellen, nennt die Namen?).  Noch deutlicher sind
vielleicht  FhG.DE und MPG.DE (fuer Fraunhofer- und Max-Planck-Institute).

Ich schlage fuer solche Beispiele vor  user@sub.domain.DE  (oder Varianten)
zu schreiben.
Ich moechte, dass jeder Anlass fuer die folgenden MISSverstaendnisse
vermieden wird:

- eine Subdomain bezeichnet eine Site (im oben angegebenen Sinn)
  (Domains sind organisatorische Konzepte!)

- das Routing fuer user@sub.domain.de erfolgt grundsaetzlich inkrementell 
  entlang der Domain-Hierarchie - etwa in den Schritten:
  erstmal bis  domain.de  bringen und dann weiter bis "sub"

Diesen Missverstaendnissen kann man sehr leicht unterliegen, insbesondere
weil in vielen Einzelfaellen diese Interpretationen sich mit der geuebten
Praxis in natuerlicher Weise decken; es ist aber wichtig zu erkennen,
wie in diesen Faellenn die Kausalitaet liegt.
So kann man daraus, dass selten eine "Site" mehrere Organisationen mit
verschiedenen Domains behaust, den Umkehrschluss ziehen, dass eine Organisation
(oder Domain) nur eine Site haben koenne.

Beispiel (aus Internet-Sicht, also mit SMTP/TCP/IP):

Mail an postmaster@fub01.ZEDAT.FU-Berlin.DE wird (unter gewissen
Randbedingungen - naemlich wenn bestimmte Systeme zum richtigen Zeitpunkt
NICHT erreichbar sind) ueber die Zwischenstationen

(a)	unido.Informatik.Uni-Dortmund.DE

(b)	methan.chemie.fu-berlin.de

(c)	phakir.zedat.fu-berlin.de

(d)	fub01.zedat.fu-berlin.de

weitergeleitet. Es waere falsch, nun zu meinen, dies waere die inkrementelle
Umsetzung des Domain-Namens fub01.ZEDAT.FU-Berlin.DE in

(a)	DE
(b)	FU-Berlin.DE
(c)	ZEDAT.FU-Berlin.DE
(d)	fub01.ZEDAT.FU-Berlin.DE

Richtig ist, dass der Domain-Name eine organisatorische Hierarchie
wiederspiegelt; wobei allerdings die beteiligten Organisation(seinheit)en
in Ihrer Zusammenarbeit (natuerlich) haeufig die technische Abwicklung
einer Aufgabenstellung (wie Mail-Routing) entlang der Hierarchie der
Aufbau-Organisation realisieren - notwendig ist das aber nicht.
(Am Rande bemerkt: normalerweise wird postmaster@fub01.ZEDAT.FU-Berlin.DE
"natuerlich" direkt zum Host fub01.ZEDAT.FU-Berlin.DE gebracht.)

Die Verhaeltnisse fuer Routing von Domains mit uucp als Mail-Transport 
(oder NJE in EARN/BITNET) spare ich mir zu erklaeren; das ist wegen
der technischen Beschraenkungen der unterliegenden Transport-Systeme
komplizierter - aber bzgl. meines Einwandes grundsaetzlich gleich.

Im Zweifel, daran die Dinge tatsaechlich klarer gemacht zu haben,
steige ich von der unfehlbaren cathedra meines paepslichen Amtes und gehe
zu den einfacheren Dingen ueber.

 
|> Bitte benutzen Sie DIESE Moeglichkeit, Ihren mailer und Ihre Verbindung
|> zu testen, bevor Sie den unido-postmaster anmailen und darum bitten,
|> Ihre mail zurueckzuschicken.
|>
|> Zur DFN-Konvention, die wir auf unido uebernehmen sollten, sage ich 
|> jetzt mal nichts. 
Selbstverstaendlich waere es sinnvoll, vernuenftige Konventionen, die
sich in anderen Netz-Organisationen eingespielt haben, sinngemaess
zu uebernehmen statt eigene zu erfinden, sofern nichts anderes dagegen
spricht (etwa denkbar: wenn EUnet auf europaeischer Basis 
mirror@<englischer-Landesname>.EU.net ist ein Reflektor) und es sich
tatsaechlich um die gleiche Sache handelt.


|> (Ist aber doch toll, dass man sowas in den *EUnet News* diskutieren kann,
|> oder? :-)))
Nun ja, selten dass ich in dieser Richtung Ehrenrettung betreiben kann:-( :
Die Kollegen haben die Einrichtung des Surname "Echo" fuer diverse O/R-Namen
mit A=DBP und C=DE schon per Mail diskutiert und abgesprochen; ich kann
versichern, dass dabei etliche Nachrichten auch per X.400 transportiert worden
sind, waehrend ich mich nicht erinnern kann, diese Diskussion in irgendeiner
News-Gruppe bemerkt zu haben.
... und wo soll denn nun sinnvollerweise diskutiert werden, ob das deutsche
EUnet sich der existierenden Konvention anschliesst?  Ich zweifle an der
Weisheit eines Versuchs unter QOM auf cadmus2.DFN.DE (192.76.176.2)!

Auch im Sinn meiner Kampagne die Dinge moeglichst praezise zu benennen
scheint es mir aber sinnvoll auf die Unterschiede in der Aufgabenstellung
zwischen c=DE;a=DBP;p=DFN;ou=ZPL;s=Echo und mirror@germany.EU.net hinzuweisen:

ein wichtiger Aspekt bei mirror@germany.EU.net ist es, evt. Deformationen
der Adressinformation beim Durchgang durch MTAs untersuchen zu koennen
und auch dann wenn solche Fehler vorliegen Tests noch automatisch zu
unterstuetzen - dies ist ein Problem, dass innerhalb der X.400-Welt nicht
auftreten kann (nun ja falls doch, wirds wirklich haarig - und da in Software
kein Fehler unmoeglich ist,...). Wohlgemerkt sieht es am Rande der X.400-Welt
- bei den Gateways - anders aus.  Eine solche Funktion erlaubt es natuerlich
dann auch Information ueber die Benutzbarkeit des Pfades zu einem bestimmten
MTA zu erhalten - diese Funktion kann man aber - wie von Bodo Rueskamp schon
bemerkt - auch mit einem kleinen schmutzigen Trick ohne explizite
Unterstuetzung auf dem Ziel-MTA erreichen (ich verwende gerne
mail -s "Test - please ignore" boomerang@ir.gend.wo < /dev/null). 
Wenn der Postmaster nicht dauernd Kopien von unzustellbarer Mail an die 
Geschwister Bounce&Boomerang sehen und wegwerfen wollen, ist dann allerdings 
die Einrichtung eines wohlbekannten Reflektors naheliegend.

Im Gegensatz dazu bietet X.400 aber keine Moeglichkeit ohne Unterstuetzung
"einfach so" einen MTA zu adressieren; die Geschwister Bounce&Boomerang
erzeugen da nach meiner Erfahrung auch nur Fehlermeldungen, die keine
ernsthaften Rueckschluesse auf den Ort der Meldungserzeugung zulassen.
Dementsprechend geht es bei s=Echo darum einzelne MTAs ansprechbar zu machen.

Da sich ja wohl auch die Benutzung unterscheidet (Adresse in Subject: ./.
Ruecksendung an den - natuerlich - unverfaelschten Absender), ist ein
Unterschied zwischen local-part des unido-Reflektors und Surname der
Reflektoren im DFN-MHS vermutlich sogar zu begruessen.
Bei Namensgleichheit waechst auch die Wahrscheinlichkeit, dass die
Gateway-Mapping-Funktion probiert wird, die ich in meinem letzten Beitrag
als Alptraum dargestellt habe:-)

So - und um die Ueberlaenge noch mehr zu strapazieren - noch ein Wort
zur kuenstlichen Intelligenz: Ich bin ziemlich sicher, dass die Nachbehandlung
eines nicht-trivialen diff-Outputs mit sort eine Datenrepraesentation
ergibt, die sich auch mit kuenstlicher Intelligenz nichtmehr sinnvoll
interpretieren laesst.

In bewaehrter Haarspalterei
   Ruediger Volk


Universitaet Dortmund, Informatik IRB
Postfach 500 500
D-W-4600 Dortmund 50
Germany

E-Mail: rv@Informatik.Uni-Dortmund.DE    (or rv@unido.uucp, rv@unido.bitnet)
Phone:  +49 231 755 4760                 Fax:  +49 231 755 2386

===============================================================================

(aus der potentiellen Leserpost: "vielleicht sollte fuer weitere Kapitel 
des Romans "Krieg und Frieden" dieses Netz-Tolstoi doch noch eine Gruppe
dnet.experten.subtilitaeten eroeffnet werden...")