Diskussion:Request for Comments

der, die, das?

Der RFC? Die RFC? Das RFC? -- stw (Talk) 12:18, 17. Jul 2004 (CEST)

RFC=Request For Comments ("Bitte um Anmerkung"), demzufolge würde ich - so doof das sich anhört - die RFC sagen wollen... -- --GoreSplatter 02:32, 19. Jun 2006 (CEST)

Übersetzung von „the Request“:[1]

• die Bitte / Nachfrage
• das Gesuch / Ersuchen / Anliegen
• der Antrag / Wunsch

Die deutsche Übersetzung ist laut Duden auch nicht ausschlaggebend, was allgemeiner Sprachgebrauch wird und damit richtig. Google findet überwiegend „der Request“.

--84.157.213.37 20:59, 17. Jul. 2011 (CEST)

ietf.org / faqs.org

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)

Discard-Service

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)

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)

Weitere lustige RFCS

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)

RFC 1071

da fehlt aber rfc 1071. http://www.faqs.org/rfcs/rfc1071.html

Belg für "Die dazu benötigte Kaffeemaschine wurde 2005 ebenfalls gebaut"

Hallo
gibt es für den Satzt "Die dazu benötigte Kaffeemaschine wurde 2005 ebenfalls gebaut" ein beleg ?
Muh kuh 13:21, 13. Sep. 2007 (CEST)

Interessiert mich auch mal. Falls da bald nichts kommt, sollte man entweder den Satz herausnehmen oder eine klassische "Citation needed" basteln.

Fünf Jahre später ist der Satz immer noch drin und auch ich frage mich, wo dafür der Beleg ist? Vor allem interessiert mich, welche Kaffeemaschine das denn wäre ;D (Der Absatz wurde übrigens von einer IP eingefügt: [2] - nachfragen bringt also wohl nix...) -- Christallkeks (Diskussion) 07:55, 6. Nov. 2012 (CET)

Der Artikel Hyper Text Coffee Pot Control Protocol und sein englisches Pendant wissen und wussten nie etwas davon (der englische ist mit einem Scherzbild bebildert, das einen Server zeigt, der auf Webbrowseranfrage korrekterweise den HTTP-Statuscode 418 liefert, die restlichen Funktionen aus dem HTCPCP-Protokoll aber wohl ziemlich sicher nicht erfüllen dürfte, auch http://www.cs.rhul.ac.uk/home/joseph/teapot.html liefert keinen ernsthaften Hinweis darauf). Den unbelegten Satz hier entferne ich nun. --YMS (Diskussion) 10:34, 6. Nov. 2012 (CET)

Wunderbar, danke. -- Christallkeks (Diskussion) 02:40, 8. Nov. 2012 (CET)

RFC neu anlegen / Übersetzung

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)

requests for comments - falsche Übersetzung

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))

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)

Draft Standard / Internet-Draft

1. "Draft Standard" wird heute nicht mehr verwendet. [3]
2. 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)

Nach Überarbeitung erledigt. --Matthäus Wander 21:08, 22. Dez. 2019 (CET)

Wichtige RFCs

• 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)

Liste aus Artikel entfernt. --Matthäus Wander 18:50, 30. Dez. 2019 (CET)