Diskussion:File Transfer Protocol

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

ASCII und Binary Mode[Quelltext bearbeiten]

Ich wurde gerne die unterschiede zwischen ASCII und Binary Mode dokumentieren, wie es im Englischen Version schon gibt, und wie es mir bei manuelle FTP immer doch wieder stört. Ich wurde dies auch schreiben, aber mein Holländer-Deutsch könnte die Deutsche allgemeinheit vielleicht nicht begeistern. Mein vorschlag: ich poste hier, jemand kontrolliert, es wird gepostet :) (übrigens mein erste wikipedia-beitrag, mit andere wiki's habe ich schon erfahrung)

Vorschlag:

Beim übertragen von Dateien können verschiedene Formate genutzt werden. Die zwei meist benutzten sind:

  1. ASCII mode
  2. Binary mode

Der Unterschied liegt in der Methode wie die Daten verschickt werden. Wenn ein Datei mittels des ASCII-typ übertragen wird, werden alle Buchstaben, Zahlen und Sonderzeichen mit deren ASCII-Zeichen übertragen. Der Server speichert diese text in dem für ihm gültigen Format (z.B. ein Unix-Server speichert die Datei in Unix-Format, ein Macintosh in Mac-Format). Dies ist ins besondere nützlich für die Zeilenumbrüche, da diese in verschiedenen Betriebssystemen unterschiedlich kodiert sind. Wenn ein Windows Rechner ein Klartext-Datei an ein Unix-Server schickt, werden die Zeilenvorschub (engl. Line Feed, kurz LF) automatisch durch Wagenrücklauf (engl. Carriage Return, kurz CR) und Zeilenvorschub (CRLF) ersetzt.

Es treten Probleme auf, wenn in der Datei Zeichen vorkommen, die nicht nur aus ASCII-Zeichen bestehen. Diese werden zu dem Server nicht richtig übertragen. Dies ist z.B. bei Ausführbaren Dateien oder Komprimierten Dateien der Fall. Wenn diese im ASCII-Modus hochgeladen werden, werden diese Dateien nicht mehr funktionieren.

Um solche Dateien zu übertragen, muss der Binary Mode (Binäre Modus) benutzt werden. Dieser Modus überträgt die Dateien bit für bit, und ist in sofern unabhängig vom eigentlichen Format der Datei.

Standardmäßig benutzen FTP-Programme den ASCII-Modus. Viele moderne FTP-Programme versuchen am Datei-Format festzustellen, ob ein Datei in Binary Mode hochgeladen werden soll.

In die FTP Spezifikationen sind noch zwei weitere Methoden definiert:

  1. EBCDIC mode
  2. Local mode

Ausser in einige große Mainframes werden diese Methoden aber selten benutzt.

Die Frage ist ob auch ein Verweis auf den Ablauf von ein Eingabeaufforderung ftp-Session nützlich/sinnvoll ist.

Ports für Daten- / Kontrollverbindung[Quelltext bearbeiten]

Im Artikel steht: "allgemein gilt: Port 20 - Datenübertragung, Port 21 - Initiierung der Session, Kommandoübertragung". Im meinem Skript zur Vorlesung Rechnernetze und auf [1] steht es genau umgekehrt. Wäre gut wenn sich das noch mal jemand verifizieren könnte und dann den Artikel abändert. Benutzer:Christof Steigner 00:10, 20. Okt. 2005 (CET)[Beantworten]

Der Wikipedia-Artikel ist in diesem Punkt korrekt. Im RFC 959 steht auf Seite 59
The FTP control connection is established via TCP between the user process port U and the server process port L. This protocol is assigned the service port 21 (25 octal), that is L=21.
Der Datenport wird in diesem RFC nicht erwähnt. Die IANA, welche u.a. die Port-Nummern verwaltet, schreibt in [2]
       ftp-data         20/tcp    File Transfer [Default Data]
       ftp              21/tcp    File Transfer [Control]
Wie kann ich dein Skript korrigieren? *g* -- Stefan506 08:40, 20. Okt 2005 (CEST)

Hmmm, scheint wirklich so das beide Quellen (mein Skript und der Link) falsch sind. Einmal mehr zeigt sich: Im Zweifelsfall immer eine Dreifach-Absicherung. Ich frage mich wer da wohl von wem den Fehler abgeschrieben hat ;). Ich könnte ja mal dem Prof ne mail schreiben und mich ein wenig einschleimen... Benutzer:Christof Steigner 01:38, 21. Okt. 2005 (CET)[Beantworten]

  • Ich war so frei die Nennung von Port 20 erstmal komplett zu entfernen, da dieser Port von praktisch allen aktuellen FTP-Servern nicht mehr verwendet wird und somit bestenfalls in einen History-Abschnitt gehören würde wenn es denn einen gäbe. --X4u 20:27, 26. Jun 2006 (CEST)
Quelle ? Und wie funktioniert das ohne ? Peritus 09:33, 4. Dez. 2006 (CET)[Beantworten]
Na, wenn das nur mit Port 20 funktionieren würde, könnte ja kein FTP-Server mehrere Clients bedienen. :)
Üblicherweise schickt der Client ein PORT-Kommando mit seinem wartenden Port, woraufhin der Server eine Verbindung zu eben diesem aufbaut. Falls aber Port 20 beim Client schon belegt ist (z.B. 2 FTP-Verbindungen gleichzeitig), kann er genausogut Port 15.345 in seinem PORT-Befehl übermitteln.
Im Passive Mode - der mittlerweile ja meistens genutzt wird - ist das eh schnurz, da schickt der Client ein PASV-Kommando, woraufhin der Server ihm einen Port nennt, zu dem er seine Daten-Verbindung verbinden soll. Das kann auch irgendein Port sein. Bei Servern mit Hunderten gleichzeitiger Benutzer ist das jedenfalls nicht immer Port 20. ;) --Markus Moll 17:48, 18. Mai 2007 (CEST)[Beantworten]

Wieso "telnet Verbindung"?[Quelltext bearbeiten]

Wieso "telnet Verbindung"? Es muss ja kein einzelnes Zeichen uebertragen werden koennen.

Richtig, habe ich rausgenommen. --AndreasB 05:26, 19. Dez 2004 (CET)

Unkommentierte Weblinks[Quelltext bearbeiten]

Ich habe die folgenden unkommentierten Weblinks als vollständigen Block aus dem Artikel rausgenommen. Für unkommentierte Weblinks sind es einfach zu viele - das hilft dem Leser nicht.

Wenn man für jeden genannten Link wenigstens stichwortartig die Relevanz erklären würde, wäre das schon besser.

Besser noch wäre es, wenn man die spezifische Funktionalität der genannten Programme mit auflisten und die Liste möglichst auf sorgfältig ausgewählte Software beschränken würde. Die Gründe für die Auswahl sollten natürlich bei jedem Link genannt werden. --HoHun 16:48, 17. Feb 2005 (CET)

Vielleicht ist dieses Konzept ganz nützlich, wenn man sich überlegt, was das Besondere an jedem Programm ist: Alleinstellungsmerkmal --HoHun 18:12, 21. Feb 2005 (CET)

Die meisten User können selbst googlen... (nicht signierter Beitrag von 89.247.22.59 (Diskussion) 21:09, 19. Januar 2009 (CET))

Beispiele für FTP-Clients[Quelltext bearbeiten]

Fast alle Webbrowser haben ebenfalls FTP implementiert und können als Clients für den Download von Dateien benutzt werden. Beispiel-URL für FTP: ftp://ftp.rfc-editor.org

Der Benutzername und das Passwort können auch direkt in die URL eingebaut werden: ftp://user:password@ftp.rfc-editor.org In Benutzernamen oder Kennwörtern, die ein @ enthalten, sollte dieses durch %40 ersetzt werden.

Beispiele für FTP-Server[Quelltext bearbeiten]


Es wäre praktisch wenigstens ein paar der Links (z.B. meistbenutzter freeware client pro OS, o.ä.) im Artikel einzubauen. Bei anderen Artikeln bzgl. Software ist das ähnlich. Das ist imo einer der großen Vorteile einer Online-Enzyklopädie. --Benjamin 6.Mai 2006

Kommandos[Quelltext bearbeiten]

In dem gleichnamigen Abschnitt auf der Hauptseite wird einfach von Kommandos gesprochen, die im Client einzutippen seien. Hier muss unterschieden werden:

  • FTP-Kommandos, definiert durch die RFCs, die das FTP-Protokoll ausmachen. Sie haben Nummern und werden vom Client afaik auch als solche gesendet.
  • Kommandos für das Programm "ftp", siehe auch die Begriffserklärungsseite FTP. Dies wären zum Beispiel lcd oder lls, sie sind mit ziemlicher Sicherheit nicht im FTP-Protokoll implentiert.

Anstatt einfach rumzumeckern habe ich mir die Freiheit genommen, einen neuen Artikel für diesen Standardclient zu schreiben, die Befehle rüberzukopieren und ein bisschen aufzuräumen. Vielleicht habe ich aber auch einfach komplett Unrecht - vielen dank für eine Stellungnahme :)

Grüße, --Benji 00:47, 19. Nov 2005 (CET)

Syntax für Browser FTP Zugriff[Quelltext bearbeiten]

Der Benutzername und das Passwort können auch direkt in die URL eingebaut werden: ftp://user:password@ftp.rfc-editor.org

genau das hab ich gesucht -> Syntax für Browser ftp Zugriff mit Passwort! bitte unbedingt in den Artikel einfliessen lassen. BeispielClients wären auch angebracht. (nicht signierter Beitrag von DataCore (Diskussion | Beiträge) )

Es handelt sich dabei um eine gängige Funktion moderner Browser und ist meines Wissens nicht genormt oder standarisiert.
Grüße, --Benji 01:09, 21. Okt. 2006 (CEST)[Beantworten]
PS: Zugegeben, es handelt sich dabei fast schon um einen Quasi-Standard bei URLs, wo Benutzer/Passwort-Kombinationen angegeben werden sollen. Dennoch liegt die Betonung auf dem quasi.
Ich finde es auch wichtig, so dass es mit rein muss,

hab auch genau deshalb die seite aufgerufen. Phfihülp

OSI-Schichtenmodell-Zuordnung[Quelltext bearbeiten]

Im Artikel steht "FTP ist in der Anwendungsschicht (Schicht Nr. 7) des OSI-Schichtenmodells angesiedelt."

Ist aber nicht das PROTOKOLL selbst in Schicht 6 anzusiedeln, waehrend die Client-Software in Schicht 7 zu finden ist?

Keine Ahnung.. Siehe OSI-Schichtenmodell#Die_sieben_Ebenen --77.186.110.126 21:23, 23. Feb. 2009 (CET)[Beantworten]
Das FTP-Protokoll gehört ganz eindeutig in Schicht 7. Client/Server-Software implementiert das Protokoll und gehört in dem Sinne zur gleichen Schicht, wobei in das OSI-Schichtenmodelle Protokolle, nicht Implementierungen, eingeordnet werden. --Benji 22:15, 23. Feb. 2009 (CET)[Beantworten]

Bitte Ordnung?[Quelltext bearbeiten]

Kann bitte jemand den eintrag "aufräumen?" man kommt auf die seite und alles total verwuselt mfg Taske

verstehe Artikel nicht.[Quelltext bearbeiten]

Im Artikel steht: Es (Das FTP-Protokoll) wird benutzt, um Dateien vom Server zum Client (Download), vom Client zum Server (Upload) oder clientgesteuert zwischen zwei Servern zu übertragen. Laut Artikel befinden sich also die zu übertragenden Files auf oder in einer Software. Nach meinem Milchmädchenverstand befinden sich die Files doch auf der Festplatte oder einem anderen Datenträger eines Rechners und somit auf einer Hardware. Denn ich kann stattdessen die Festplatte oder Datenträger in einen anderen Rechner einbauen, und das File so zu dem anderen Rechner "übertragen". Kann das vielleicht jemand aufklären? -- 84.132.115.152 05:18, 5. Jul. 2008 (CEST)[Beantworten]

Das Protokoll definiert einen Übertragungsstandard, wie zwei Programme auf verschiedenen Computern miteinander Dateien austauschen können. Ob diese Dateien in den jeweiligen Computern letztlich von der Festplatte, einer Ramdisk, einem Network Attached Storage oder ähnlichem kommen, spielt dabei keine Rolle – das Protokoll definiert die Übertragung "nur" bis zum Endprogramm und nicht weiter. --Benji 22:18, 23. Feb. 2009 (CET)[Beantworten]

Erklärung von passivem FTP kann nicht richtig sein.[Quelltext bearbeiten]

Damit das funktioniert, müßte "auf der Client-Seite ein Port jenseits 1023" beim Router/Gateway zur Weiterleitung hinterlegt sein. Woher soll der Router sonst wissen, für welchen Client im LAN die Datenpakete bestimmt sind?

Unser FTP-Server hat außerdem nur Port 21 zur Verfügung. Der kann nicht irgendwelche anderen Ports freigeben.

Funktioniert trotzdem alles. Also kann die Erklärung nicht richtig sein. --217.84.53.243 14:22, 7. Aug. 2008 (CEST)[Beantworten]

Ein Trugschluss. Der Client öffnet die Verbindung zum Server auf jenem TCP-Port, die der Router dann traversiert (AFAIK Masquerading). Der Router weiß dann genau, zwischen wem die Verbindung aktiv ist; er legt eine Art Zuordnung an zwischen lokaler IP-Adresse+TCP-Port und entfernter IP-Adresse+TCP-Port. --Benji 22:21, 23. Feb. 2009 (CET)[Beantworten]
Auch ich denke, daß die Erklärung beim Passivem FTP so nicht richtig sein kann ... Guenni60 (Diskussion) 15:06, 13. Jun. 2018 (CEST)[Beantworten]
RFC 959: The data transfer process, in its normal "active" state, establishes the data connection with the "listening" data port. The DTP can be placed in a "passive" state to listen for, rather than initiate a connection on the data port. The user-process default data port is the same as the control connection port (i.e., U). The server-process default data port is the port adjacent to the control connection port (i.e., L-1).
Weder aktiv noch passiv hat mit Portauswahl zu tun, die bei heute hüben wie drüben üblichen Firewalls ins Nichts führt, sondern nur damit, von welcher Seite die Datenportverbindung initiiert wird. Der Client hat standardmäßig nur einen Port, und auf dem bekommt er NAT und Firewalls zum Trotz alles was er selbst initiiert.
Der Artikel stellts komplizierter als es ist und nicht richtig dar.
--79.240.140.44 00:50, 2. Aug. 2023 (CEST)[Beantworten]

Dateiintegrität[Quelltext bearbeiten]

Sehe ich das richtig, dass das FTP Protokoll die Integrität (also die Korrektheit) der übertragenen Dateien nicht sicherstellt? Gäbe es dazu Alternativen, welche das sicherstellen? Auf diese könnte man in dem Artikel dann verweisen. --77.186.72.33 17:54, 22. Feb. 2009 (CET)[Beantworten]

FTP basiert auf dem TCP-Protokoll, welches sehr wohl die Integrität der übertragenen Blöcke sicherstellt, wenn auch mit einfachen Mitteln. Es ist allerdings wahr, dass FTP darauf keine weiteren Überprüfungsverfahren aufbaut, vgl. z.B. mit rsync. Manuell lässt sich das allerdings mit einfachen Mitteln nachprüfen, beispielsweise in dem man einfach die MD5-Summen der übertragenen Datei sowohl auf Server, als auch Client erstellt und vergleicht (siehe Überprüfung der MD5-Summe). In großem Umfang wird das auch gemacht, und zwar mit md5sums-Dateien, die dann (allerdings) auch per FTP übertragen werden. --Benji 22:25, 23. Feb. 2009 (CET)[Beantworten]
FTP stellt drei Transfermodi zur Auswahl, von denen einer große Dateien in Blöcke zerlegt und jeden fehlerhaft übertragenen Block automatisch nochmal überträgt, bis er fehlerfrei übertragen ist. --79.240.140.44 00:50, 2. Aug. 2023 (CEST)[Beantworten]
In welchem Modus werden denn Blöcke zerlegt und neu übertragen? --Matthäus Wander 08:51, 2. Aug. 2023 (CEST)[Beantworten]

Link zu ftplab.com entfernt[Quelltext bearbeiten]

Aufgrund der Einstufung als "suspicous" unter Google Safe Browsing habe ich den Link erstmal herausgenommen. Unbedarfte Nutzer könnten vielleicht Panik schieben, wenn sich plötzlich das Firefox-Fenster komplett rot färbt. Bitte beobachten und ggf. wieder einfügen. --DanielG 15:38, 28. Apr. 2009 (CEST)[Beantworten]

Warum überhaupt FTP?[Quelltext bearbeiten]

Wieso braucht es überhaupt dieses Dateiübertragungsverfahren? Wieso macht sowas nicht jeder Browser? Kann bitte jemand von Euch Fachleuten diese Info in den Artikel (am besten in die Einleitung) einbauen? Für Euch ist diese Info sicher banal, für Otto Normalverbraucher nicht. --Fah 12:03, 12. Mai 2010 (CEST)[Beantworten]

Weil es nicht nur Browser gibt!? Es ist durchaus noch in 2021 üblich, dass eine Menge IOT-Geräte ihre Updates über FTP (oder die Erweiterung FTPS) empfangen und ihre Logfiles etc. darüber zur Verfügung stellen. Im Embedded Bereich ist zwar inzwischen auch der eine oder andere Web-Browser anzutreffen, insbesondere seit nginx, aber meine bisherigen Arbeitgeber haben sich bewusst für FTPS und gegen HTTPS entschieden, weil die Kompatibilität einfacher zu erreichen ist und die Angriffsmuster besser zu beherrschen. --185.116.38.131 11:00, 4. Mai 2021 (CEST)[Beantworten]
Dein Hinweis an Fah ist komplett richtig, aber seine Frage ist bereits durch den Text "Im vollautomatischen Masseneinsatz im Unternehmen werden Integrationslösungen eingesetzt die im Regelfall auch FTP beherrschen." beantwortet gewesen.
BTW, habe mir erlaubt, die fehlende Einrückung bei Dir zu korrigieren
M.R. --2A02:560:426A:40FC:6463:B78B:60E:6586 13:26, 4. Mai 2021 (CEST)[Beantworten]
(Ich habe mal Leerzeilen reduziert und Einrückung erneut korrigiert) Es ist nicht immer sinnvoll auf "uralte" Beiträge (hier 11 Jahre) zu antworten. -- WikiMax - 13:53, 4. Mai 2021 (CEST)[Beantworten]
Ein Browser dient(e) nur dazu um HTML-Webseiten anzusehen, nicht zum Herunterladen und schon gar nicht zum Hinaufladen von beliebigen Dateien oder "manipuilieren" von Verzeichnissen.
Wieso macht nicht jeder Browser das? Gegenfrage: Warum kann nicht jedes Auto fliegen und kaffeekochen? Weil es nicht dafür konzipiert wurde. Früher in den Zeiten, als Disketten noch gängige Speichermedien und 16-Bit-Prozessoren noch gängige CPUs waren, Hauptspeichermodule in KB angegeben wurde, da sparte man sich auch gerne unnötige "Features" - und FTP war damals wie heute (heute auch SFTP) ein Feature, was nur eine Minderheit nutzt. -- WikiMax - 13:53, 4. Mai 2021 (CEST)[Beantworten]

Wow, nach nur 11 Jahren eine Antwort auf meine Frage, ich bin beeindruckt ^^ Nun, so nett (?) die Erläuterungen hier auf der Diskussionsseite auch gemeint sein mögen, meine Bitte war eigentlich gewesen, das im Artikel selbst klarzustellen, und zwar in laienverständlicher Form. Das sehe ich im Artikel nicht so recht realisiert. Tja, muss man bei Wikipedia diesen Anspruch inzwischen begraben? Ist das der Zweck geworden, Fachlexikon zu sein, statt Publikumslexikon? Ich verstehe ja, dass es besonders für technisch begabte Menschen eine Herausforderung sein mag, nicht-Fachleuten ihre Aussagen verständlich rüberzubringen (habe z.B. regelmässig mit meinem freundlichen und technisch fitten EDV-Mann solche Erfahrungen), umso mehr würde es mich freuen, wenn jemand von Euch Lust drauf hat... :) --Fah (Diskussion) 09:46, 22. Jun. 2021 (CEST)[Beantworten]

In der Frage scheint das Missverständnis zu stecken, das Web wäre zuerst dagewesen oder hätte ein vorrangiges Existenzrecht gegenüber anderen Internetanwendungen. In der Einleitung steht, FTP wurde 1985 spezifiziert, während bei Hypertext Transfer Protocol steht, dass es 1991 eingeführt wurde. Das beantwortet die Frage, warum man überhaupt ein eigenes Dateiübertragungsprotokoll braucht. Im Abschnitt File_Transfer_Protocol#FTP-Client ist erläutert, dass es früher von Browsern unterstützt wurde – und eben auch von anderer Software. Fehlt da jetzt noch was? Für eine lehrbuchartige Erläuterung ist ein Enzyklopädie-Artikel nicht der richtige Ort. --Matthäus Wander 22:33, 2. Aug. 2023 (CEST)[Beantworten]

Erklärung[Quelltext bearbeiten]

Also ich habe jetz schon eine computermäßig-"normale" Vorbildung und verstehe diesen Artikel beim besten Willen nicht. Vielleicht sollte man ihn mal so überarbeiten dass man ihn ohne Vorwissen (praktisch für Ottonormalverbraucher) verstehen kann.

Schon mal Danke im Vorraus -- (nicht signierter Beitrag von 129.187.209.137 (Diskussion) 15:42, 25. Okt. 2011 (CEST)) [Beantworten]

Also, leider sind Artikel zu technischen Themen oft sehr technisch formuliert, etwas aufpeppen könnte man das hier...
"FTP" ist genau das, was der Name sagt: Damit werden seit über 30 Jahren Dateien von A nach B übertagen. Das gab es zu ähnlichen Zeiten schon wie Email. Also lange vor dem WWW, sogar vor Gopher!
Jeder Browser sollte sowas können.. "ftp://" leitet einen Link zu entsprechenden Servern ein (so wie "http://" übrigens ums Hypertext-Transfer-Protocoll bittet, um es im Fenster des Browsers darzustellen).
Das Problem: Du "siehst" FTP meistens nicht, wie du ja auch HTTP nicht siehst, sondern du siehst Web-Seiten! Was du normalerweise siehst ist einfach eine Aufforderung, wohin die Datei gespeichert werden soll, die du gerade angeklickt hast.
Die meisten Browser stellen FTP-Sites einfach als Liste dar und erzeugen Links zum drauf klicken, ohne daß man großartig ein Webdesign basteln muß. Außerdem sind FTP-Server leicht über Textkonsolen bedienbar und damit auch über Scripte! Das wird oft unterschätzt, weil Menschen in GUI-Zeiten häufig nicht bedenken, daß fast alles, was sie selber im Webbrowser sehen, auf Scripten beruht (z.B. Google fragen, Youtube gucken...) --Jabo 01:01, 28. Okt. 2011 (CEST)[Beantworten]

Link zu wintotal.com[Quelltext bearbeiten]

Also, das ist zwar schon etwas informativ zu FTP, was der Wiki-Artikel an sich jedoch auch liefert. Aber "eigenen Heim-FTP-Server einrichten" ist eigentlich falsch. Da wird beschrieben, wie man einen solchen unter Windows einrichtet und das, soweit ich sehe, nicht versionsübergreifend.

Angesichts der Tatsache, daß 1. FTP nicht wirklich was mit Windows an sich zu tun hat und 2. es auf diversen anderen Plattformen allerhand Möglichkeiten gibt, einen solchen einzurichten, ist der Link lexikalisch irrelevant.

Darüberhinaus wird Bezug auf zu alte Windows- und Linux-Versionen genommen, was den falschen Eindruck erweckt, FTP habe was mit einem bestimmten OS oder deren GUI zu tun. Die Betitelung des Links impliziert aber, man könne da die Einrichtung eines FTP-Servers erlernen und nach Anleitung umsetzen. Ich würde den Link, der gerade erst aktualisiert wurde, lieber weg nehmen. --Jabo (Diskussion) 15:53, 21. Mär. 2013 (CET)[Beantworten]

Veraltetes Protokoll[Quelltext bearbeiten]

Meiner Meinung nach handelt es sich bei FTP um ein veraltetes Protokoll, dass nicht mehr verwendet werden sollte.
Dieser Hinweis fehlt im Artikel.
Warum veraltet und nicht mehr verwenden:
Aus Sicherheitsgründen: Es ist unsicher, da unverschlüsselt...

--Fosb (Diskussion) 13:21, 8. Jan. 2015 (CET)[Beantworten]

Es gibt den Abschnitt Sicherheit im Artikel, der das anspricht. Ob das Protokoll dadurch veraltet ist, könnte man gerne im Artikel diskutieren. Heute wirkt FTP wie aus einer anderen Zeit, aber es gibt bestimmt noch Szenarien, wo es Einsatz findet, etwa wo alte Hard- und Software in Betrieb ist oder die Einfachheit des Protokolls von Vorteil ist (vgl. die massive Verbreitung von Trivial_File_Transfer_Protocol in der Netzwerktechnik). --Benji (Diskussion) 14:32, 8. Jan. 2015 (CET)[Beantworten]
Bitte mit Beleg, da es sich um eine subjektive Bewertung handelt. --Matthäus Wander 07:56, 10. Jan. 2016 (CET)[Beantworten]

FTP-Adressierung im Browser[Quelltext bearbeiten]

Der Satz "Ein Beispiel für die Syntax einer FTP-Adressierung im Browser ist..." im Abschnitt "FTP-Software" ist ja nicht gerade eine fachliche Ausdrucksweise. Genau genommen handelt es sich dabei um die Beschreibung, wie eine URL zusammengesetzt ist, um auf eine Resource über das FTP-Protokoll zuzugreifen (falls diese gefunden wird).

Referenz auf RFC 959 und 1985 m.E. falsch[Quelltext bearbeiten]

Auch wenn heutige FTP-Implementationen durchweg auf RFC 959 beruhen und 959 schon lange zum "STD" geworden ist, ist der Ursprung definitiv nicht erst 1985, sondern mindestens RFC 765 aus 1980 [3]. Schon dort ist das heutige FTP sehr deutlich in Struktur und Befehlen zu erkennen, auch wenn es noch deutliche Änderungen in 959 gab.

Eine Formulierung der Art "basierend auf RFC 765 aus dem Jahr 1980, gilt die deutlich überarbeitete RFC 959 aus dem Jahr 1985 noch immer als Basis-Implementation aller FTP-Server und -Clients" wäre sinnvoll.

(persönliche Anmerkung: Habe im Herbst 1983 bereits an meiner Uni mit einer in den USA per FTP (765) Daten ausgetauscht) --185.116.38.131 10:48, 4. Mai 2021 (CEST)[Beantworten]

da stimme ich unumwunden zu: unsere englische Wikipedia-Schwester ist hier noch genauer: Wikipedia.en, History_of_FTP_servers, demnach ist die von Dir genannte 765 die erste mit TCP als Transport, davor gab es schon noch ältere RFCs. RFC 114 von 1971 ist laut mehrerer Quellen die erste. Weitere Quellen: HistoryOfFileTransferProtocol2 auf cs.odu.edu und tcpipguide.com, die letztere nennt allerdings erst die RFC 172 als erste Version. M.R.

--2A02:560:426A:40FC:6463:B78B:60E:6586 13:40, 4. Mai 2021 (CEST)[Beantworten]

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Diskussion:File_Transfer_Protocol&oldid=236059571“