Verzoek om commentaar

Van Wikipedia, de gratis encyclopedie
Spring naar navigatie Spring naar zoeken

Het verzoek om commentaar ( RFC ; Engels voor verzoek om commentaar ) is een reeks technische en organisatorische documenten op internet (oorspronkelijk Arpanet ) die sinds 7 april 1969 door de RFC-editor zijn gepubliceerd. Waren de documenten oorspronkelijk ter bespreking in de letterlijke zin van het woord ingediend, tegenwoordig vindt de bespreking plaats terwijl de concepten worden opgesteld, zodat een gepubliceerde RFC meestal een getaxeerde technische specificatie vertegenwoordigt. [1]

Sommige, maar niet alle, RFC's zijn internetstandaarden [2] RFC's standaardiseren de familie van internetprotocollen , bijvoorbeeld IPv6 ( RFC 8200 ), TCP ( RFC 793 ), UDP ( RFC 768 ), SMTP ( RFC 5321 ) en HTTP / 2 ( RFC 7540 ), en vormen zo de technische basis van internettoepassingen zoals e-mail of het World Wide Web .

Publicatieproces

Alle RFC's worden vóór publicatie beoordeeld. Het publicatieproces en de daarin gespecificeerde eisen verschillen al naar gelang een internetstandaard wordt gezocht of niet. Toekomstige internetstandaarden moeten aan hoge eisen voldoen en een gemeenschapsconsensus vertegenwoordigen van de Internet Engineering Task Force (IETF).

Alle ingediende concepten worden door de IETF gepubliceerd onder de naam " Internet Draft " (ID). Internetconcepten worden als onvoltooid beschouwd en mogen niet als referentie worden gebruikt. Ze verlopen na zes maanden (maar blijven online gearchiveerd), tenzij een nieuwe conceptversie wordt ingediend of het publicatieproces wordt gestart.

De RFC-editor publiceert nieuwe RFC's met doorlopende nummering als ASCII- tekstbestand en in andere documentformaten. Zodra een RFC is gepubliceerd, wordt de inhoud nooit gewijzigd. Correcties van redactionele of technische fouten worden als errata gepubliceerd ; de onjuiste RFC blijft echter ongewijzigd. Als een verouderde specificatie moet worden vervangen, doorloopt de nieuwe specificatie het gebruikelijke proces en wordt gepubliceerd onder een nieuw RFC-nummer. Het nieuwe document verwijst naar de oude RFC en verklaart deze achterhaald. Een nieuwe RFC kan ook slechts een deel van een bestaande RFC bijwerken of toevoegen zonder het hele document ongeldig te maken.

Reeks documenten

Geselecteerde RFC's worden ook gepubliceerd in verdere reeksen documenten, elk met een eigen nummering.

  • Internetstandaard (STD)
Internetstandaarden met de hoogste mate van volwassenheid worden ook gepubliceerd in de STD-documentenreeks.
De BCP-serie is in 1995 geïntroduceerd voor RFC's die technische informatie of administratieve specificaties bevatten die zijn goedgekeurd door de IETF. Dit onderscheidt BCP's van puur informatieve RFC's, waarover de IETF geen standpunt inneemt. Publicatie als internetstandaard is uitgesloten omdat BCP's geen netwerkprotocollen zijn . [3]
  • Voor uw informatie (FYI)
De FYI-serie werd in 1990 geïntroduceerd om informatieve RFC's bekend te maken bij een breed publiek, met name beginners. [4] De serie speelde zich af in 2011 [5]

Individuele RARE Technical Reports (RTR) zijn ook gepubliceerd als RFC. [6]

Goedkeuringsprocedure

Er zijn verschillende goedkeuringsprocedures voor RFC's, afhankelijk van waar het document vandaan komt. Zo'n proces staat bekend als een stroom . RFC 4844 definieert de volgende stromen:

  • IETF
Het document is afkomstig van een IETF-werkgroep of van een Area Director van de Internet Engineering Steering Group . Deze stream is de enige die opkomende internetstandaarden en de beste huidige praktijken mag indienen. RFC 2026 en anderen beschrijven de procedure.
  • IAB
Het document is afkomstig van de Internet Architecture Board . RFC 4845 beschrijft de procedure.
  • IRTF
Het document is afkomstig van de Internet Research Task Force . RFC 5743 beschrijft de procedure.
  • onafhankelijke indiening
Het document is afkomstig van een onafhankelijke bijdrager die het rechtstreeks indient bij de RFC-editor. Binnen de IETF is geen technische consensus vereist, waardoor publicatie als internetstandaard niet mogelijk is. RFC 4846 beschrijft de procedure.

RFC-status

Elke RFC heeft een documentstatus die, in tegenstelling tot de inhoud, later kan worden gewijzigd.

  • Onbekend
Er wordt geen status toegekend aan de RFC. Dit geldt voor sommige vroege RFC's.
  • Voorlopige versie
Geen RFC, want het is nog in de tekenfase.
  • Informatief (informatief)
Informatief document van welke aard dan ook, bijvoorbeeld terminologieverklaringen, gebruiksinstructies, problemen of nieuwe ideeën. Er zijn ook losse antwoorden op algemene vragen of overlijdensberichten.
  • Experimenteel
Protocolspecificatie die is gemaakt als onderdeel van een onderzoeks- of ontwikkelingsproject. Het doel is om binnen de netwerkgemeenschap meer ervaring op te doen om zo nodig in de toekomst op basis hiervan een internetstandaard te ontwikkelen. Het Sender Policy Framework begon bijvoorbeeld als een experimentele RFC 4408 en ging het standaardisatieproces in met RFC 7208 .
  • Beste huidige praktijk
Een technisch document dat bindend wordt door publicatie in de BCP-reeks van documenten.
  • Voorgestelde standaard , conceptstandaard en internetstandaard
Verschillende volwassenheidsniveaus van een internetstandaard . Voorgestelde normen zijn specificaties die een strenge beoordeling en consensus hebben ondergaan door de relevante IETF-werkgroep. Conceptnorm wordt niet langer als status gebruikt. [7] Internetstandaarden hebben de hoogste volwassenheid en worden ook gepubliceerd in de STD-documentenreeks.
  • Historisch (historisch) en verouderd (verouderd)
Verouderde specificaties worden door de IESG als historisch gemarkeerd wanneer het gebruik ervan niet langer wordt aanbevolen. Als een specificatie wordt vervangen door een nieuwe RFC, wordt de verouderde status gebruikt. Dit laatste heeft als doel om verouderde specificaties te identificeren die nog steeds relevant zijn, bijvoorbeeld omdat ze nog steeds wijdverbreid zijn.

formalisme

De IETF en de RFC-editor hechten veel belang aan formalisme:

  • Voorstellen voor nieuwe of gewijzigde RFC's worden duidelijk gedocumenteerd in alle wijzigingen vóór de formele publicatie.
  • Zodra een RFC eindelijk is gepubliceerd, is deze voor altijd openbaar en permanent. Het kan ook niet worden gecorrigeerd; het kan alleen worden vervangen door nieuwere RFC's.
  • De structuur en stijl van een RFC worden gespecificeerd door RFC 7322 .
  • RFC 2119 (BCP 14) definieert de terminologie van vereisten, waarvan de betekenis duidelijk is gedefinieerd om misverstanden bij de interpretatie ervan te voorkomen.
MOET en MOET NIET (equivalent: ZAL en ZAL NIET ) geven aan dat aan een vereiste moet worden voldaan.
MOET en MOET NIET (equivalent: AANBEVOLEN en NIET AANBEVOLEN ) geven aan dat een vereiste wordt aanbevolen, maar waar in gerechtvaardigde gevallen van kan worden afgeweken.
MAY (equivalent: OPTIONEEL ) specificeert een optie die naar eigen inzicht van de fabrikant kan worden geïmplementeerd.
  • Tekenreeksen en hun samenstelling worden formeel weergegeven met behulp van de Backus-Naur-vorm (BNF). Dit zorgt voor een duidelijke interpretatie, handig bij bijvoorbeeld het bouwen van URL's en URI's.

Al deze formalismen zorgen voor het vermijden van misverstanden bij de interpretatie en implementatie en dus voor het succes van de werking van internet. RFC 2822 (e-mail) en RFC 2616 (HTTP) zijn hiervan voorbeelden en evenzeer van hun succes.

Humor in RFC

Tussen de RFC's die internetstandaarden of best-practices beschrijven, zijn er altijd grappende RFC's die niet letterlijk genomen moeten worden, vaak ter gelegenheid van 1 april .

  • RFC 1925 , gepubliceerd op 1 april 1996, somt The Twelve Networking Truths op die beginnen met het fundamentele principe van It Has To Work .
  • Meestal zinloos lampschakelen is te vinden in RFC 3251 als een parodie op het MPLS- routeringsprotocol.
  • RFC 2795 behandelt de Infinite Monkey Theorem en beschrijft hoe een oneindig aantal apen kan worden gecoördineerd om de werken van Shakespeare te produceren.
  • Maar ook ware kunstwerken kunnen worden geïdentificeerd, zoals een lofzang op de Arpanet ( RFC 527 ), geschiedenis van de wetenschap in vers ( RFC 1121 ) of The Twelve Days of Christmas vanuit het perspectief van een gestresste netwerk admins ( RFC 1882 ).
  • Op 1 april 2001 werden de combinaties van "foo" en "bar" of hun varianten etymologisch bepaald in RFC 3092 .
  • Op 1 april 2003 werd een RFC ( RFC 3514 ) gepubliceerd, waarin werd opgeroepen om een ​​bit in de koptekst van IP-pakketten die in welke vorm dan ook "slecht" zijn, in te stellen om deze pakketten bij firewalls gemakkelijker uit te filteren om te kunnen . Dit komt omdat een bit in IPv4-headers dat het "Type of Service" aangeeft, normaal is ingesteld op 0, maar door sommige moderne applicaties op 1 is ingesteld. Sommige firewalls vertrouwen erop dat dit 0 is en beoordelen het pakket gewoon als slecht omdat het een niet-ondersteund servicetype is.
  • Op 1 april 2004 is een alwetend protocol ontwikkeld om de Amerikaanse overheid in staat te stellen alle vormen van computercriminaliteit te identificeren en te voorkomen ( RFC 3751 ). Nadat de vereisten voor dit protocol niet haalbaar waren gebleken, eindigt de tekst met de woorden: "Veel succes."
  • Op 1 april 2005 werd een nieuwe standaard gepresenteerd die moreel onberispelijke routering mogelijk maakt ( RFC 4041 ). Verder is de zeer oude UTF-8 , die gebruikmaakt van 8-bit eenheden , vervangen door UTF-9, die 9 bits (3×3) per byte toestaat ( RFC 4042 ).
  • Op 1 april 2007 werd een methode gepresenteerd voor de overdracht van IP met behulp van het knipperalfabet ( RFC 4824 ).
  • Op 1 april 2010 is het Transmission Control Protocol uitgebreid: De sfeer van het uitgezonden segment kan worden bepaald door emoticons in de header . Een segment kan bijvoorbeeld blij of gefrustreerd zijn ( RFC 5841 ).

Gerealiseerde April Fools' Day

Op 1 april houdt de RFC zich echter niet altijd aan de theorie. Op 6 maart 2001 werd een implementatie van de RFC 1149 A Standard for the Transmission of IP Datagrams on Avian Carriers (de verzending van IP-datagrammen per postduif ) gepresenteerd. De gemiddelde responstijd op een ping was echter 45 minuten, zodat regelmatig gebruik in echt gebruik niet te verwachten is. Dit leidde echter tot een verdere ontwikkeling van RFC 2549 IP over Avian Carriers met Quality of Service , maar ook dit gebruik is onwaarschijnlijk.

De Emacs- editor heeft al jaren een volledige implementatie van RFC 2324 : Het Hyper Text Coffee Pot Control Protocol (HTCPCP) wordt gebruikt voor het op afstand bedienen en bewaken van koffiemachines.

Tijdens het Hacking in Progress- evenement werd RFC 2322 , Beheer van IP-nummers door Peg DHCP , geformuleerd. Het definieert hoe IP-nummers met een viltstift op houten wasknijpers worden geschreven en op de bijbehorende kabel worden geklikt. Hoewel deze RFC als grap bedoeld was, wordt hij regelmatig gebruikt.

Met gpigen is er ook een gratis implementatie voor verschillende platforms voor het Pi Digit Generation Protocol .

web links

Individueel bewijs

  1. ^ H. Flanagan (red.): RFC 8700 - Vijftig jaar RFC's . IETF. December 2019. Ontvangen op 26 december 2019.
  2. C. Huitema, J. Postel, S. Crocker: RFC 1796 - Niet alle RFC's zijn standaarden . IETF. April 1995. Ontvangen 26 december 2019.
  3. RFC 1818 . - Beste huidige praktijken . [Errata: RFC 1818 ]. Augustus 1995. (Engels).
  4. RFC 1150 . - Ter info op ter info . [Errata: RFC 1150 ]. Maart 1990. (Engels).
  5. ^ R. Housley: RFC 6360 - Conclusie van FYI RFC Sub-Series . IETF. Augustus 2011. Ontvangen op 26 december 2019.
  6. ^ RTR-index . RFC-editor. Ontvangen 26 december 2019.
  7. ^ R. Housley, D. Crocker, E. Burger: RFC 6410 - Het terugbrengen van het standaardspoor tot twee volwassenheidsniveaus . IETF. Oktober 2011. Ontvangen op 26 december 2019.