Der Fehler ist wohl vielmehr ein allgemeiner gebräuchlicher, da beide Varianten als FTPS bezeichnet werden.
Sehe ich deutlich anders ... es gibt eine Internet Registry für
derartige Einträge.
Was dort nicht registriert ist (wenigstens als Provisorium wie z.B. ircs), ist kein Bestandteil des Standards und damit ist eine Angabe von "FTPS://irgendwas" (wie im AVM-GUI) einfach nur Bullshit-Bingo, erst recht für Port 21 ... nirgendwo im zuständigen RFC 4217 wird auch nur der Vorschlag unterbreitet, das "FTPS" zu nennen.
Wenn man den umgekehrten Weg gehen will und bei den
offiziell registrierten Ports beginnt, landet man für FTPS auch nicht bei 21, sondern bei 990. Bei allen "offiziellen" und provisorischen URI-Schemata mit der Erweiterung "S" für "Secure" gibt es immer auch einen abweichenden Port für die von Anfang an gesicherte Verbindung, da eine Kontaktaufnahme im Klartext auf einem TLS-Port zum Scheitern verurteilt ist.
Genauso falsch ist es eben, wenn jemand SMTP mit STARTTLS als SMTPS, IMAP mit STARTTLS als IMAPS (und so weiter) bezeichnet. Dann geht nämlich aus dem "
Uniform Resource Identifier" eben genau nicht mehr hervor,
wie man diesen Dienst nun ansprechen muß (als URI-Schema gibt es auch kein SMTPS und/oder IMAPS, aber wenigstens noch als Servicebezeichnung bei den Portnummern).
Bei AVM-Firmware im GUI ist die Angabe "ftps://<fritzbox-adresse>" also schlicht falsch ...
Wenn dann eine Anwendung ihrerseits "schlau genug" ist, um bei einem fehlgeschlagenen TLS-Connect auf Klartext mit späterem TLS-Start zurückzuschalten, ist das ein reines Komfortmerkmal dieser Anwendung und hat mit irgendeiner Standardisierung nichts mehr zu tun und auch dafür müßte die Angabe in der URL dann wenigstens den Port 21 noch spezifizieren, damit der "normale Benutzer" (ich nehme jetzt mal Igotinternet als Beispiel) nicht erst raten muß, welche Einstellung nun die richtige wäre. FTP heißt 21, FTPS heißt (mit etwas gutem Willen) 990. Punkt.
Alles andere ist logisch für mich nicht zu erklären, denn wenn Du z.B. mit einem Postmaster irgendwo in der großen weiten Welt kommunizieren und dem SMTP/STARTTLS als SMTPS verkaufen willst, wirst Du auch nur Lacher und/oder Unverständnis ernten. Das mach dann noch in einer für beide Seiten fremden Sprache (i.d.R. Englisch als Lingua franca) und dann weißt Du, warum da solche Sachen wie "allgemein gebräuchlich" berechtigterweise nicht in einem Standard aufgehen ... meine persönliche Meinung, wie gesagt.
Und auch wenn es alle/viele falsch machen, wird es dadurch ja noch nicht automatisch richtig ... ganz im Gegenteil. So werden dann nämlich festgeschriebene Standards eher aufgeweicht und in der Folge ergeben sich dann trotz eindeutiger Festlegungen gerne I14Y-Probleme, die man ohne solche Aktionen gar nicht hätte.
Wer das plastisch vor Augen geführt haben will, braucht nur mal eine Matrix zu erstellen, welcher FTP-Server mit welchem FTP-Client auch eine der beiden sicheren Varianten (FTPS bzw. FTP/AUTH TLS) wirklich beherrscht, bei der expliziten Variante (also mit TLS per Kommando) kommt dann noch die Frage dazu (wie Du schon geschrieben hast), ob dabei nur die Control-Verbindung (also Benutzerdaten
und Verzeichnislistings) oder auch die Datenverbindung (also per PUT/GET übertragene Dateiinhalte) verschlüsselt werden kann. Ich wäre sehr verwundert, wenn da ein einziges Produkt (mit halbwegs großer Verbreitung) dabei wäre, was mit allen anderen "kann". Spätestens wenn es dann nicht nur um Verschlüsselung, sondern auch um die Sicherung der Identität der Gegenstelle geht, streichen die meisten Programme die Segel (hängt auch immer etwas vom benutzten SSL-Stack ab).
