Diskussion:Request for Comments

message: Hallo
Gibt es einen besonderen Grund, dass in der deutschen Wikipedia die RFC-Links alle nach faqs.org gehen, wärend sie in der englischen auf ietf.org leiten.
(vielleicht, um die Serverlast aufzuteilen?)
:Nein, mir fällt kein sinnvoller Grund ein, außer dass vielleicht vergessen wurde, eine Änderung der Interwiki-Tabelle in allen Wikipedias vorzunehmen. --Echoray 12:43, 27. Dez 2004 (CET)
thread_title:  ietf.org / faqs.org 

message: Ist der Discard-Service wirklich nur ein Scherz? Ich denke nicht! Auch wenn es auf den ersten Blick keinen Sinn macht, ich kann mir doch durchaus einen Anwendungsfall vorstellen: Benchmarking. Wenn ich die theoretische Bandbreite einer Verbindung messen will, dann schicke ich die Pakete am besten zum discard-Port. Dann hat der Server keine große Arbeit mit den Daten (wegschmeissen geht sehr schnell), und auch der Client kann sehr viel Datenvolumen erzeugen. Die gemessene Bandbreite wird also kaum von der Performance von Client und Server beeinflusst, sondern nur von der Verbindung. [So kann man selbst mit einem 486 einen DoS auf eine megabit-schnelle Leitung veranstalten, vorausgesetzt, die Gegenstelle bietet "discard"]
:Dazu habe ich dann eine Frage: Wie möchtest Du die Bandbreite ermitteln, wenn Du keinerlei Antwort erhältst? Damit kannst Du höchstens feststellen, wie schnell Deine Software die Pakete erzeugenund versenden kann...
:Zur Performancemessung kannst Du vielleicht den Echo-Service oder Du benutzt Echo-Pakete auf ICMP-Ebene. --Herr Schroeder 14:58, 25. Apr 2005 (CEST)
replies: text:  Der Discard Prozess ist kein scherz. Bereits 1972 wurd ein solcher für andere protokolle standardisiert, und dort auch bereits benötigt. Zur Performance messung in eine richtung bei TCP/IP wäre er durchaus zu gebrauchen, denn tcp/ip selbst macht hier einen ack und so kann man einfach die bandbreite in eine richtung messen (netcat /dev/zero nach host:port und dann schaun was rübergeht). weitere denkbare anwendungen sind, dass man programme hat die sehr einfach geschrieben sind und immer irgendwohin gesendet haben. discard services waren dann eine einfache möglichkeit eine sendekette abzubrechen (man bedenke, damals gabs wenig speicher und ein komplettes OS passte in 4kb). Im übrigen haben wir ja auch /dev/null, und das ist auch kein scherz. 84.176.207.202 14:49, 11. Aug 2006 (CEST)
thread_title:  Discard-Service 

message: Ich denke einige dieser RFCS sollten auch als lustige mit aufgenommen werden:
* RFC1606 bietet eine historische perspektive von IPv9 (das es natürlich erst in der zukunft gebe könnte). Wohl eine kleine parodie auf den gigantischen addressraum von IPv6
* RFC1437 stellt ein MIME format für den transport von materie vor.
* RFC748 ist auch noch ein kleiner netter witz für diejenigen die noch telnet protokollo kennen
* RFC3252 beschreibt das BLOAT protokoll. Es ist eine binärimplementation von TCP/IP in XML. Sehr gelungen.
* RFC2550 beschäftigt sich mit tem Y10K problem.
* RFC1607 ist eine durch die zeit zurückgeschickte mail aus dem jahre 2023. Da sind wir schon auf dem mars.
* RFC3091 das Pi generation prtokoll ist auch niht wirklich ernst gemeint
* RFC2551 beschreibt den "Roman Standards process". recht gelungen, alle zahlen sind sogar in römisch
* RFC2325 greift wieder einmal den Kaffee auf
* RFC2321 würde viele hotlines überflüssig machen
Generell lohnt es sich die rfcs nach "April 1 " zu durchsuchen. (ok, einige weihnachts oder neujahr rfcs gehen dabei flöten). Die meisten linux distros haben ein rfc paket auf das man dann (z)grep loslassen kann 84.176.207.202 14:49, 11. Aug 2006 (CEST)
thread_title:  Weitere lustige RFCS 

message: Ich arbeite gerade an einer kompletten Übersetzung des aktuellen (deutlich umfangreicheren) Gegenparts aus der englischen WP. Auch, da dies meine erste Übersetzung in der WP sein wird, habe ich mich bisher nur mit dem Abschnitt Humor in RFC befasst, siehe Benutzer:Mafutrct/Baustelle/Übersetzung_-_April_Fools'_Day_RFC. Sobald dieser Teil fertig ist, wollte ich mich dem Hauptartikel widmen. Wer möchte, kann gern mitarbeiten. --mafutrct 13:02, 21. Aug. 2008 (CEST)
thread_title:  RFC neu anlegen / Übersetzung 

message: Im Englischen bedeutet "comment" im Normalfall nicht Kommentar. Wenn der deutsche "Kommentar" gemeint ist wird im Englischen oft der Begriff "annotation" verwendet. Die ursprünglichen RFC waren unvollständig und mussten ausgearbeitet werden. Somit war ein "request for comment" im Deutschen eher als  "Aufforderung zur Aüßerung/Stellungnahme/Ergänzung" zu verstehen. Im Gegensatz zum Kommentar der ein bereits fertigen Werk "kommentiert (annotiation)", bezieht sich der Begriff "comment" hier klar auf "Work in Progress" und kann somit nicht mit Kommentar übersetzt werden. (nicht signierter Beitrag von 79.240.68.16 (Diskussion) 13:20, 24. Okt. 2011 (CEST)
replies: text: Gesprochene Sprachen sind eben nicht bijektiv zueinander. Dass die Rückübersetzung nicht hundertprozentig hinhaut bedeutet nicht dass es falsch sei "Comment" mit "Kommentar" zu übersetzen. Nach diesem Kriterium könnte man z.B. auch "Äußerung" (statement!) und "Ergänzung" (addition, supplement) verwerfen. Inhaltlich halte ich "Kommentar" im Sinne eines Dialoges auch für völlig zutreffend, denn ein solcher wird ja in Bezug auf ein RFC geführt. -- Theoprakt 01:32, 20. Jan. 2012 (CET)
thread_title:  requests for comments - falsche Übersetzung 

message: # "Draft Standard" wird heute nicht mehr verwendet. 
# Internet-Draft verweist per Anker-Link auf Draft Standard, was aber nicht zusammengehört. Ein Draft Standard ist ein veröffentlichtes RFC im Standard-Track. Ein Internet-Draft ist ein Entwurfsdokument, das nicht als RFC veröffentlicht ist. --Matthäus Wander 18:59, 6. Jun. 2018 (CEST)
replies: text: Nach Überarbeitung erledigt. --Matthäus Wander 21:08, 22. Dez. 2019 (CET)
thread_title:  Draft Standard / Internet-Draft 

message: * RFC 1 (erste RFC von Steve Crocker)
* RFC 768 (UDP)
* RFC 791 (IP)
* RFC 792 (ICMP)
* RFC 793 (TCP)
* RFC 821 (SMTP)
* RFC 822 (E-Mail-Format)
* RFC 950 (Subnetting)
* RFC 959 (FTP)
* RFC 1006 (ISO on TCP – ISO Transport Service on top of the TCP)
* RFC 1034 (DNS – Concepts and Facilities)
* RFC 1035 (DNS – Implementation and Specification)
* RFC 1036 (Usenet – Standard for Interchange of USENET Messages)
* RFC 1087 (Ethics and the Internet)
* RFC 1094 (NFS Version 2 Protocol Specification)
* RFC 1166 (IP-Adresse)
* RFC 1321 (MD5 Message-Digest Algorithm) durch RFC 6151 überarbeitet
* RFC 1436 (Gopher)
* RFC 1459 (IRC)
* RFC 1661 (PPP)
* RFC 1700 (Assigned Numbers)
* RFC 1738 (URLs)
* RFC 1813 (NFS Version 3 Protocol Specification)
* RFC 1939 (POP3)
* RFC 1945 (HTTP 1.0)
* RFC 2131 (DHCP)
* RFC 2222 (SASL)
* RFC 2440 (OpenPGP)
* RFC 2460 (IPv6)
* RFC 2606 (Zu Testzwecken reservierte Top-Level-Domains)
* RFC 2613 (Remote Network Monitoring)
* RFC 2616 (HTTP 1.1) veraltet
* RFC 2663 (NAT)
* RFC 2821 (SMTP)
* RFC 2822 (E-Mail-Format)
* RFC 3174 (SHA)
* RFC 3261 (SIP)
* RFC 3501 (IMAP Version 4 Protocol Specification)
* RFC 3530 (NFS Version 4 Protocol Specification)
* RFC 3920 (XMPP Core, sowie in RFC 3921 IM & Presence)
* RFC 3986 (URIs)
* RFC 4122 (UUID, Universally Unique IDentifier)
* RFC 4511 (LDAP)
* RFC 4870 (DomainKeys)
* RFC 5545 (iCalendar)
* RFC 7230 (HTTP 1.1)
* RFC 1462 = FYI 20 FYI on What is the Internet?
* RFC 1855 = FYI 28 Netiquette Guidelines
* RFC 1935 What is the Internet, Anyway?	
* RFC 2119 = BCP 14 Key words for use in RFCs to Indicate Requirement Levels
* RFC 2468 I REMEMBER IANA, ein Nachruf von Vinton Cerf für Jon Postel
* RFC 5000 = STD 1 Internet Official Protocol Standards, ein Überblick über die wichtigsten Internet Protokolle
Ich tue mich schwer mit der obigen Liste "wichtiger RFCs". Nach welchen Kriterien wurde diese zusammengestellt? Was ist die Botschaft, die der Leserin vermittelt werden soll? Ich würde dafür plädieren die Liste durch einen kurzen Fließtext zu ersetzen, der erklärt, dass RFCs die Netzwerkprotokolle um die TCP/IP-Protokollfamilie herum definieren, wie beispielsweise Web und E-Mail. Das Ziel wäre es nicht wichtige RFCs aufzuzählen (was nicht gelingen kann), sondern ein Gefühl dafür zu vermitteln, was die Bedeutung eines RFC ist und wofür es da ist. --Matthäus Wander 21:16, 22. Dez. 2019 (CET)
replies: text: Liste aus Artikel entfernt. --Matthäus Wander 18:50, 30. Dez. 2019 (CET)
thread_title:  Wichtige RFCs