Diskussion:Uniform Resource Identifier

Maskulinum oder Femininum?

Heißt es "die" oder "der URI"? Identifier müsste eigentlich männlich eingedeutscht werden, aber das ist bei URL auch so und doch hört man eigentlich ausschließlich "die URL". Intuitiver wär m.E. "die URI", eben weil es verwandt mit URL ist. Ich hab im Artikel auch nur "die URI" gelesen. Wie auch immer, ein entsprechender Hinweis gehört noch in den Artikel, unter "URL" steht auch ein solcher. Da ich mir diesbezüglich aber nicht sicher bin, stell ich die Frage einfach mal in die Runde: Ist es so wie oben beschrieben oder ist es nur männlich?

Es wird (leider) beides verwendet: „Die URI/URL“ in der Bedeutung von „die Internetadresse“, und „der URI/URL“ korrekt übersetzt mit „der einheitliche Quellen-Bezeichner/(an)zeiger“. Meiner Meinung nach sollte die maskuline Form bevorzugt Verwendung finden, weil die präzise Übersetzung des Originalbegriffs eben diese erfordert. Deshalb sollte diese Form auch in Wikipedia konsequent genutzt werden.

Ein Beispiel dafür, dass nicht ausschliesslich die feminine Form Verwendung findet, liefert unser Proxy:

Der angeforderte URL konnte nicht geholt werden

Während des Versuches, den URL http://www.vvhatever.de/ zu laden...

Der Cache war nicht in der Lage, den in der URL enthaltenen Hostnamen aufzulösen.

Da sieht man dann, dass nicht mal die Übersetzung konsistent ist ;-). Es müsste im letzten Satz heißen "den in dem URL".

Ich suche noch nach einer wirklich einleuchtenden Erklärung für den optionalen? Bestandteil www in einem übliche www-URL, z. B. http://www.quelle.de?

Lastverteilung. Die Idee war es, verschiedene Dienste auf verschiedenen Systemen (die ggf. örtlich voneinander getrennt stehend) zu realisieren, also z.B. http auf einem System, mail auf einem anderen, ftp auf einem dritten usw. Daraus ergeben sich dann die verschiedenen subdomains www.example.org, ftp.example.org usw. Jedem dieser Subdomains kann nun eine andere IP-Adresse zugeordnet sein. Beispiel:

$ host www.gmx.de mail.gmx.de
www.gmx.de has address 213.165.64.215
www.gmx.de mail is handled (pri=10) by mx0.gmx.net
mx0.gmx.net has address 213.165.64.100
mail.gmx.de has address 213.165.64.20

Häufiger wird inzwischen aber eher eine Technik wie Load-Balancing verwendet, da auch z.B. www nicht mehr von einem Rechner realisiert werden kann. Wenn man dann schon LB einführt, kann man natürlich auch gleich alles über die gleiche IP laufen lassen, der LB-Router kann dann je nach Protokoll unter einem anderen Subset von Servern denjenigen mit der niedrigsten Last auswählen.

Ob www optional ist oder nicht hängt vom jeweiligen Diensteanbieter an. Letztlich hat es sich eingebürgert, überall www. voranzuhängen (http wäre aus technischer Sicht korrekter gewesen, aber erklär das mal meiner Oma - dann verstest Du, warum www gewählt wurde), aber es gibt durchaus Ausnahmen, z.B. web.archive.org (wobei in dem Fall aber www.archive.org ebenfalls funktioniert). Um ein anderes Beispiel zu nennen <schleichwerbung>bothie.sharedaemon.org</schleichwerbung>. Hier ist es z.B. gar nicht erlaubt ein www voranzustellen. Macht man das erhält man eine Fehlermeldung (Domain löst nicht auf: Unable to determine IP address from host name for www.bothie.sharedaemon.org).

Das hat aber überhaupt nicht mit URI zu tun. Auch geht es nicht um Lastverteilung. Anders formuliert lautet die Frage nämlich: "Weshalb hat der Servername bei vielen Webauftritten ein 'www' davor, bei manchen aber nicht? Und weshalb funktioniert oft auch beides?" Und damit enthält die Frage schon die Antwort: weil beide Namen (mit und ohne 'www') auf den gleichen Server zeigen -- oder eben auch nicht.

Das ist bloß der Hostname und ist unabhängig von der URI/URL selbst. Jeder Rechner hat ein Name. Jeder Rechner kann Bestandteil einer Domäne sein und jede Domäne wiederum kann auch Bestandteil einer Domäne sein. Daraus folgt: "mail.gmx.de" = Hostname ("Rechnername") "mail" in der Domäne "gmx" in der Domäne "de" (Top-Level-Domain, TLD). Wichtig ist das für die Auflösung, denn wenn man die IP von "mail.gmx.de" nicht kennt, fragt man (zB Browser) zunächst den Nameserver von "mail.gmx.de" (falls vorhanden), falls man den Nameserver nicht kennt, fragt man den von "gmx.de" und falls man den auch nicht kennt, fragt man eben den Nameserver von "de" ("Rootserver"). Lange Reder, kurzer Sinn: Im Sinne der URI ist das bloß der Hostname und ist (in diesem Sinne) vergleichsweise beliebig. (nicht signierter Beitrag von 91.64.234.92 (Diskussion) 22:22, 9. Okt. 2012 (CEST))

codierung

erstens ist dieser satz nicht eindeutig: "Eine Erweiterung der URIs die nur aus druckbaren ASCII-Zeichen bestehen sind die Internationalized Resource Identifiers (IRIs)." hier fehlen mal sicher beistriche, weiters ist nicht klar, ob die erweiterung oder uris aus ascii-zeichen bestehen. weiter oben wird wieder behauptet, uris kann man mit "einer codierung" codieren. bitte das klarer formulieren (ich kenn mich selbst zu wenig aus)

Schrägstrich am Ende

Hat ein Schrägstrich am Ende eines URIs eine Bedeutung? Sind also z. B. die beiden URIs „http://de.wikipedia.org“ und „http://de.wikipedia.org/“ äquivalent? Oder gibt es feine Unterschiede? Der Grund meiner Frage: Ich selbst lasse einen abschließenden Schrägstrich immer weg, habe aber beobachtet, dass andere ihn hinzufügen. Ist das nur Geschmackssache? --jpp ?! 19:20, 25. Mär 2006 (CET)

Der Schrägstrich gibt generell den Pfadabschnitt an. Somit hier den Rootpfad. Fehlt er wird er vom Browser respektive Server selber hinzugefügt.

http://de.wikipedia.org = http://de.wikipedia.org/ = http://de.wikipedia.org/index.php (falls index.php defaultfile ist)

Falsch! Dies sind drei unterschiedlich URIs, weil es drei unterschiedliche Pfad-Abteile sind. Als http-URLs sind die ersten beiden zwar äquivalent, aber nicht als URI. Die dritte eine völlig andere URL, auch wenn der Server für alle drei die gleichen Daten liefert (weil index.php das defaultfile für dieses verzeichnis ist).

So weit ich weiß, wird beim Slash am Ende ein Verzeichnis erwartet, ohne Slash eine Datei. --128.176.151.205 23:29, 22. Aug. 2013 (CEST)

Es sind mehrere Fälle zu unterscheiden:

• Nur die Domain angegeben und Protokoll ist http, https, ftp und weitere in der Richtung: Die URI sind mit und ohne Schrägstrich am Ende äquivalent aber nicht gleich (weil sie halt unterschiedlich sind). Oben korrekt dargestellt.
• Zusätzlich zur Domain ist ein Pfad angegeben: Jedes hinzugefügte Zeichen verändert den Pfad und macht die URI womöglich ungültig.
  • Es ist freie Entscheidung des vergebenden Servers, was irgendwelche Schrägstriche bedeuten mögen. Der URI kennt weder ein Konzept von „Verzeichnis“ noch unterschiedlich davon einer Datei (meint Ressource). Aus dem Umstand, dass der URI mit einem Schrägstrich oder mit .php oder .html oder sonstwas endet, kann man zwar seine privaten Schlüsse ziehen, aber das ist nur ein häufiges Vorkommen und keine Notwendigkeit. Sehr oft enden URI ohne Schrägstrich oder „Dateiendung“, wenn sie auf ein „Verzeichnis“ zeigen. Es muss aber überhaupt keinerlei hierarchische Verzeichnisstruktur auf dem Server existieren, selbst wenn irgendwas mit Schrägstrichen gegliedert ist.

LG --PerfektesChaos 00:36, 23. Aug. 2013 (CEST)

Zeichensatz, Prozent-Kodierung

der Artikel verträgt noch folgende Ergänzung:

• welcher Zeichensatz genau darf (bzw. durfte, hat sich ja geändert) verwendet werden
• die Prozent-Kodierung sollte auf jeden Fall erwähnt werden, die begegnet einem ja in auch bei den URL der Wikipedia oft genut

Gruß, -- Schusch 09:46, 28. Nov. 2006 (CET)

Unterschied zwischen URL und URI ?

Eine bessere Unterscheidung zwischen URL und URI wäre hilfreich.

Es wird gesagt, dass URL eine Unterform von URI sei. Jedoch bei einem Vergleich beider Beschreibungen (Uniform_Resource_Identifier und Uniform_Resource_Locator) gibt es keine erkennbaren Unterschiede zwischen den Elementen/Bestandteilen einer URL und einer URI.

In Bezug auf obigen Absatz:

Hier mal ein kurzer Abschnitt aus dem RFC für URI der den Unterschied vllt etwas mehr verdeutlicht

RFC3986 URI

A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name.

Die Formulierung "identifizieren eine Ressource über ihren primären Zugriffsmechanismus" ist irreführend, da sie hauptsächlich auf das Protokoll und weniger auf den Ort der Speicherung abzielt. In der englischen Version ist dies wesentlich klarer: URL bezeichnet den Ort, URN den Namen. (nicht signierter Beitrag von 194.25.238.250 (Diskussion | Beiträge) 09:26, 30. Apr. 2010 (CEST))

Ich versuche es mal auf anschaulich:

• Die URN ist die eindeutige Identifikation des Inhalts einer Ressource. Bei einem gedruckten Buch kann man sich das als ISBN vorstellen.
• Die URL ist eine Information, an welchem Ort auf der Welt man sich die Ressource holen könnte.
  • Die gleiche URN-Ressource könnte an verschiedenen Orten auf der Welt abrufbar sein. Dementsprechend kann eine URN mehrere URL haben.
  • Das kennen wir auch unter dem Stichwort „mirror“.
  • Beim gedruckten Buch entspräche das der Information, in welcher Bücherei (Domain) in welchem Regal unter welcher Signatur das gleiche Buch greifbar wäre.
• Unter einer URL findet sich nicht immer die gleiche URN.
  • Der „Tipp des Tages“ ist jeden Tag ein anderer, der immer eine andere URN habe. Er ist aber immer an der gleichen URL zu finden.
• URI ist nun der Oberbegriff für URN und URL.
  • Dies bietet insofern Gemeinsamkeiten, als Zeichenkodierung und Eindeutigkeit sowie ein gewisser Grundaufbau (Namensräume, Syntax; Möglichkeit hierarchischer Formen) gleich sind. Der dahinter stehende Mechanismus ist hingegen unterschiedlich, und die Bedeutung unterscheidet sich fundamental bei URN und URL.

Mag das jemand einbauen? --PerfektesChaos 14:00, 19. Okt. 2012 (CEST)

Der Artikel wurde inzwischen ausgebaut. Mehr Material zum Thema URL./.URI:

• Wohlweislich schreibt HTML, dass das href-Attribut mit einer URI zu belegen ist. Schon seit langer Zeit (HTML4, 6.4 URIs) heißt es dazu: “Note that URIs include URLs”.
• Die Adressleiste des Browsers wird zwar intern meist als urlbar programmiert, weil man Webseiten über http aufsucht; aber tatsächlich ist es eine URI-Bar.
  • So kann bei Mozilla about:config oder bei Opera opera:config eingetragen werden; das sind aber keine URL, sondern interne Identifizierer nach privater URI-Syntax.
• Um einen URL (Locator) aus einem URN zu gewinnen, bedarf es eines Resolvers. So wäre DOI aufzulösen von einem URN doi:10.1000/182 in einen momentan möglichen Locator http://dx.doi.org/10.1000/182 oder eines Tages ein anderer.
  • Genauso könnten die Entwickler von Browsern ein inoffizielles wiki://wmf/w:de:URI auflösen, indem für die authority wmf die bekannten Umsetzungsregeln w:→wikipedia.org/wiki/ und de:→http://de. ausgeführt werden.

Hand-aufschreiberei wichtig?

mir erscheint dine information, man könne sie/ihn auch vonhand auf papier schreiben höchst überflüssig.

Das war aber eines der Entwurfsziele und ist eine wichtige Eigenschaft. --84.149.154.106 16:37, 15. Jul. 2007 (CEST)

Die Formulietung im Artikel klingt in der Tat etwas dümmlich und sehr banal. Was haltet Ihr von folgender Formulierung?

URIs können als Zeichenfolge (kodiert mit einem Zeichensatz) in digitale Dokumente, insbesondere solche im HTML-Format eingebunden werden. Eines der Konzeptziele beinhaltet auch, daß ein URI von Hand auf Papier aufschreibbar ist, es also z.B. keine versteckten oder extern eingebundenen Zeichen gibt. Einen Verweis von einer Webseite auf eine andere nennt man Hyperlink oder kurz Link.

--Carbenium 10:57, 23. Nov. 2008 (CET)

Link ist URL, nicht URI. Bitte nicht verwechseln.

Falsch, eine URL ist immer eine URI. --84.170.158.72 01:06, 7. Aug. 2019 (CEST)

Liste der Schema

Wo wird denn eine Liste der Schema und welche Programme dafür Standardmäßig zu verwenden sind gespeichert? Irgendwo "zentral" z.B. in der Registry, sodass alle Programme, z.B. Webbrowser darauf zugreifen können und dann eventuell das nötige Programm öffnen, oder macht das jeder Webbrowser für sich? Wenn ein neues Programm installiert wird, welches Standardmäßig bei einem bestimmten, bisher dem System noch Unbekannten Schema aufgerufen werden soll (z.B. ein Jabber-Client, der bei Schema xmpp: aufgerufen werden soll, während vorher z.B. IE anzeigt, dass für das Anzeigen des Inhalts das nötige Programm fehle), wo muss dieses Programm das neue Schema dann Anmelden: Bei jedem Webbrowser extra, oder gibt es dafür eine zentrale Datei, wo jedes Programm das zum Schema gehörige Standardprogramm abfragen kann? --80.130.219.212 20:28, 11. Nov. 2008 (CET)

Fehler in einem Beispiel

Die folgende URI aus den Beispielen ist nicht korrekt: <data:text/plain;charset=iso-8859-7,%be%fg%be>. Der Fehler liegt in dem Teil "%fg", was (normalerweise) eine hexadezimale Darstellung eines Zeichens ist. Jedoch gibt es nicht die hexadezimale Ziffer "g", "f" ist die letzte (dezimal 15). -- nix 12:52, 16. Jan. 2010 (CET)

Im Prinzip ja, aber das Beispiel steht so in RFC 2397, und es gibt keine Korrektur dazu. Ich zögere mit einer Änderung, weil mir unwahrscheinlich scheint, dass ein Fehler so lange unentdeckt in einer RFC steht. -- Stf 15:19, 16. Jan. 2010 (CET)

Ich denke nicht, dass der Fehler unentdeckt geblieben ist, sondern dass der Fehler einfach nur unwichtig ist, da er nur in einem Beispiel auftritt und nicht in der Definition. Dennoch sollte man auf den Fehler hinweisen. Das RFC-Dokument ist nicht änderbar, aber in dem Artikel hier kann ein entsprechender Hinweis auftauchen. Es ist und bleibt eine ungültige URI. -- nix 13:00, 18. Jan. 2010 (CET)

git

Ist git (git://...) ein standardisiertes Schema? Würde es sonst entfernen. --_{Nightfly85 | Disk} 10:28, 7. Sep. 2011 (CEST)

Absolute URI

sollte es nicht file:/// lauten? (nicht signierter Beitrag von 178.27.190.114 (Diskussion) 19:36, 21. Nov. 2011 (CET))

Ja. Die ersten beiden Slashes leiten den Authority/Host ein, der in diesem Fall leer ist und intern durch 'localhost' ergänzt wird. Der dritte Slash markiert das Root des 'Shares' und definiert damit einen absoluten Pfad. --188.45.148.162 01:21, 10. Okt. 2013 (CEST)

Pfad

Der Satz ist völlig unverständlich formuliert: "Falls eine authority angegeben wird, muss er mit einem Schrägstrich („/“) beginnen, andernfalls darf er nicht mit einem doppelten Schrägstrich („//“) beginnen."

http://de.wikipedia.org/w/index.php - Hier beginnt der Pfad entweder mit der authority "//de.wikipedia.org" und damit mit einem doppelten Schrägstrich, oder aber nur "/w/index.php" zählt als Pfad und dieser dürfte somit sowieso nie mit einem doppelten Schrägstrich beginnen. (de.wikipedia.org//pfad) --128.176.151.205 00:41, 23. Aug. 2013 (CEST)

Unter Uniform_Resource_Identifier#Aufbau steht »… besteht ein URI aus fünf Teilen: scheme (Schema), authority (Anbieter), path (Pfad) …«, authority ist demnach nicht Teil von path, der Pfad ist "/w/index.php". »dürfte somit sowieso nie mit einem doppelten Schrägstrich beginnen« trifft nur für den Fall zu, dass keine authority gegeben ist, ein »falscher« Pfad wäre also "//w/index.php", weil dann beim Zusammenfügen mit dem Schema – es entsteht bspw. "http://w/index.php" – die URI als authority "w" und Pfad "/index.php" geparst werden würde. Insofern ist »darf er nicht« eine ungeschickte Formulierung, in RFC 3986 steht dort »kann er nicht«.

'"http://de.wikipedia.org//pfad" ist hingegen eine gültige URI, weil sie die Bedingung erfüllt, dass der Pfad mit einem Schrägstrich beginnen muss (weil eine authority vorhanden ist). Danach können aber beliebig viele Schrägstriche folgen. Z.B. ist auch "http://de.wikipedia.org/////" gültig (unabhängig davon, dass sich ein solcher URI ggfs. nicht auf ein Filesystem mappen lässt). --Stf (Diskussion) 09:28, 23. Aug. 2013 (CEST)

Ich habe mal versucht, den Satz verständlicher zu formulieren. Hat sich wirklich erst beim zweiten Blick erschlossen, wenn man den Sachverhalt nicht sowieso schon verinnerlicht hatte. Liebe Grüße --PerfektesChaos 09:56, 23. Aug. 2013 (CEST)

Authority

Die Angabe von user und password kann man nicht generell als überholt bezeichnen. Als HTTP- oder FTP-URL im Browser ist sie im WAN oder Internet je nach Anwendung sicherlich risikoreich. Im Intranet kann sie auch risikolos sein. Ebenso als Angabe-Form von FTP-Zugängen, HTTP-Authentications, Email-Accounts, MySQL- oder File-Shares in einem Programm oder CMS, das dann mittels dieser gebündelten Beschreibung, allerdings in einer sicheren Methode auf die Ressourcen zugreift. -- 188.45.148.162 01:06, 10. Okt. 2013 (CEST)

Die Aussage wird in RFC 3986, Abschnitt 3.2.1 getroffen:

Use of the format "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data […] The passing of authentication information in clear text has proven to be a security risk in almost every case where it has been used.

Hab’ das mal im Artikel klarer formuliert. -- Stf (Diskussion) 11:33, 15. Mär. 2014 (CET)

Unterarten: Venn-Diagramm

Hallo, das verwendete Venn-Diagramm legt den Schluß nahe, dass es neben URLs und URNs noch weitere Teilmengen der URIs gibt oder geben könnte. Umgekehrt formuliert ist die Aussage "URIs sind die Vereinigung von URLs und URNs" entsrpechend dem Venn-Diagramm nicht korrekt. Dagegen wird in der englischen Version dieser Seite ein Euler-Diagramm verwendet, welches darstellt, dass URLs und URNs die Partitionen der URIs sind, obige Aussage als gilt. Meines Verständnisses nach ist erwähnte Aussage richtig bzw. das Euler-Diagramm korrekt. Zumindest ist ein mir bekannter Informatik-Professor dieser Ansicht. (nicht signierter Beitrag von 185.98.51.171 (Diskussion) 19:18, 3. Sep. 2015 (CEST))

Ach je, da hat uns mal jemand was Gutes tun wollen, und Jahre später dieses Bildchen spendiert.

Man sieht an dem gelben bis violetten Farbverlauf, dass es von der in der enWP gezeigten Vorlage inspiriert war.

Nun siehst du in dem türkisfarbenen Hintergrund, dass das eine Grundmenge von weder-URL-noch-URN sein solle; das war aber wohl eher dekorativ gemeint.

Wie wäre es, das Bildchen aus der enWP auch hier einzubinden, und sich dafür die Wichtigtuerei in der Bildunterschrift mit Venn und Euler zu sparen?

Es ist übrigens gar nicht gesagt, dass es da eine Schnittmenge von sowohl-URL-als-auch-URN gibt; ich sehe das eher als weder-noch. Man weiß es nicht.

LG --PerfektesChaos 20:12, 3. Sep. 2015 (CEST)

Es gibt durchaus URIs, die keine URLs und keine URNs sind, z.B. data-URIs. Das spricht gegen das Bild aus en. Für die Schnittmenge aus URL und URI ist die Situation schwieriger, da sehe ich nicht, wie man RFC 2141 und RFC 3986 unter einen Hut bringt. Aber sicher habe ich etwas übersehen. Müsste man mal recherchieren. --Stf (Diskussion) 09:00, 4. Sep. 2015 (CEST)

Ich denke, man sollte die Abbildung komplett rauswerfen, da sie mehr verwirrt als hilft.

Es gibt URI, die auf das Namens-Konzept abzielen (nicht notwendigerweise urn:, und URL, und dann allerlei und neumodisches, was Identifizierer ist, aber keine benannte Ressource im eigentlichen Sinn, und dann noch Sonderfälle wie data:. Nur mit Mühen kann ich mir was zusammenreimen, was sowohl Namens- wie auch Locator-Konzept vereint.

Der Standardfall ist URL oder alternativ Namens-Konzept, und das nimmt die weitaus größte Zahl der praktischen Anwendungsfälle ein. Die große türkisfarbene Grundmenge suggeriert optisch, in der Regel hätte man es mit weder-N-noch-L zu tun, was eine falsche Vorstellung ist, und es würde als Schnittmenge sowohl-N-als-auch-L geben, womit ich mich schwer tue.

LG --PerfektesChaos 11:21, 4. Sep. 2015 (CEST)

Na dann hab ich es mal rausgeworfen. -- Stf (Diskussion) 00:38, 5. Sep. 2015 (CEST)

Suffix-Referenzen

Mir fehlen Belege dafür das dieser Begriff mit dieser Bedeutung existiert.
Ich finde den Begriff auch eigenartig, denn es ist fraglich von was denn das www hier ein Suffix sein soll. Die Bemerkung in Klammern legt nahe, das das www das Suffix des DNS-Namen sein sollte, da die DNS rückwärts aufgebaut werden. Jedoch wäre mir neu, das der Aufbau der DNS, relevant dafür wäre, festzustellen, das ein vorgestllter Teil ein Suffix sei. Sucht man im Netz nach DNS Suffix so findet man diese Interpretation auch nicht (einfach?) - sondern meist bezieht sich das Suffix auf das Ende des DNS Namens.
Das heißt im Bezug auf den DNS Namen handelt es sich meinem Verständnis nach um ein Prefix. Sollte sich das Suffix in dem Begriff Suffix-Referenz darauf beziehen, das der gesammte Teil nach dem weggelassenen Scheme des wohl ein Suffix des Scheme sei, so finde ich die Erklärung dazu verwirrend.

URI: [scheme://][suffix]
DNS: prefix.wikipedia.org. --165.225.26.198 13:27, 9. Apr. 2021 (CEST)

RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax. Januar 2005. Abschnitt 4.5: Suffix Reference. (englisch).

Existiert also höchstoffiziell.

Ob der Begriff schlau gewählt worden war, ist eine andere Frage.

Kannste ja als ref in diesem Abschnitt unterbringen. Der ist wie es scheint eine zusammenfassende Übersetzung des RFC.

VG --PerfektesChaos 15:06, 9. Apr. 2021 (CEST)