RFC

RFC 는 인터넷 기술 문서에 번호를 붙여 누구나 읽게 내놓는 문서 모음입니다. 웹 요청이 무엇을 뜻하는지 같은 약속이 한 편씩 번호를 달고 나옵니다. 한 번 나온 문서는 고치지 않습니다. 바꿀 것이 생기면 새 번호로 다시 냅니다.

상세

동아리 방 벽에 붙은 쪽지를 떠올리면 가깝습니다. 누구든 「이렇게 해 보면 어떨까」를 한 장 적어 붙입니다. 붙은 순서대로 귀퉁이에 번호가 하나씩 올라갑니다. 번호가 있다고 다 지켜야 하는 것은 아닙니다. 다 같이 지키기로 한 쪽지도, 그냥 적어 둔 생각도 섞여 있습니다.

RFC(Request for Comments)는 인터넷 기술 문서를 번호 순서대로 모아 내는 문서 시리즈입니다. 우리말로 옮기면 「의견 요청」입니다. 백엔드 개발자가 매일 쓰는 HTTP(Hypertext Transfer Protocol)도 판이 여럿입니다. 그 모든 판이 함께 쓰는 뜻은 RFC 9110 「HTTP Semantics」 한 편이 정합니다. 누구나 인터넷에서 돈을 내지 않고 읽을 수 있습니다.

이 시리즈에는 인터넷 표준 문서만 들어 있지 않습니다. 절차를 적은 문서, 정보를 알리는 문서, 사고 실험, 아직 설익은 아이디어, 연구 논문, 역사 기록, 농담 글, 추모 글까지 같은 번호 줄에 섞여 왔습니다. 인터넷 표준에 관련된 문서는 전부 RFC 로 나옵니다. 거꾸로 RFC 가 전부 표준 관련 문서인 것은 아닙니다.

이 시리즈가 맡은 일은 인터넷 기술 규격을 적은 글을 모아 보관하는 것입니다. 지금 시리즈의 목표는 발행한 글을 정본으로 내놓고 영구히 보존하는 것입니다. 모아 두는 데가 없으면 어느 글이 정본인지 가릴 수 없습니다. 번호 하나가 고치지 않는 본문 하나를 가리키니 누가 인용해도 같은 문장을 펴 봅니다.

한 편이 나오는 길

문서를 승인하는 창구가 여럿입니다. 이 창구를 스트림(stream)이라고 부릅니다. 스트림마다 자기 승인 절차가 있습니다. 문서 내용에 대한 책임도 그 스트림의 승인 기구가 집니다. 스트림이 무엇무엇인지는 「갈래」 절에서 봅니다.

승인이 끝난 문서는 모두 같은 발행 창구로 갑니다. 발행 실무는 RFC Editor 기능이 맡습니다. 그 가운데 문장과 형식을 다듬어 내고 번호를 붙이는 일은 RFC Production Center 가 합니다. 틀린 곳을 모아 두는 정오표(errata) 시스템도 이곳이 운영합니다. 스트림이 여럿이어도 시리즈는 하나로 관리합니다.

발행된 RFC 첫머리에서 먼저 볼 줄은 둘입니다. 첫 줄에는 그 문서를 승인한 스트림 이름이 적힙니다. Category 줄에는 처음 나올 때의 상태가 적힙니다.

Category 줄에 찍히는 상태는 지금 기준으로 다섯 가운데 하나입니다. 인터넷 표준이 되려는 규격이 밟는 단계 줄을 표준 트랙(Standards Track)이라고 부릅니다. 나머지 넷은 운영 관행을 정한 Best Current Practice, 정보를 알리는 Informational, 실험 단계의 Experimental, 낡은 규격에 붙는 Historic 입니다. 상태마다 무엇이 다른지는 「갈래」 절에서 봅니다.

번호와 고치지 않는 본문

RFC 번호는 문서를 발행할 때 붙습니다. 번호 하나가 문서 한 편을 가리킵니다. 같은 규격을 고쳐 다시 내면 그 새 문서는 새 RFC 번호를 받습니다.

발행된 RFC 는 바뀌지 않습니다. 오늘 읽는 RFC 9110 과 몇 해 뒤에 읽는 RFC 9110 은 같은 문장입니다. 번호만 대면 누구나 같은 본문을 펴 봅니다.

이것은 시리즈가 예부터 중요하게 지켜 온 성질로 꼽힙니다. 이 성질에 영향을 주는 정책 제안도 낼 수는 있습니다. 그 가운데 성질에 해를 끼칠 수 있는 제안은 더 엄격히 심사하도록 되어 있습니다. 바꾸더라도 일부러, 결과를 따져 본 뒤에 바꾸게 하려는 것입니다.

고쳐 낸 새 문서는 첫머리에 옛 문서와의 관계를 적습니다. 지금 정해진 관계는 Obsoletes(폐기)와 Updates(갱신) 둘입니다. RFC 9110 은 첫머리 Obsoletes 줄에 7231 을 적어 RFC 7231 을 폐기했습니다. 같은 줄의 7230 은 일부만 폐기했습니다. 그 범위는 Abstract 에 「portions of 7230」으로 적혀 있습니다. 그래서 RFC 번호를 근거로 든 글을 읽을 때는 그 번호가 뒤 문서에 폐기됐는지부터 확인합니다.

문서 밖에 붙는 정오표와 상태

본문을 못 고치니 틀린 곳은 문서 밖에 모읍니다. 이 모음이 정오표입니다. RFC 의 정오표를 받고 관리하고 보여 주는 온라인 시스템이 따로 있습니다. 본문은 손대지 않은 채 틀린 문장과 고친 문장을 나란히 붙여 둡니다.

상태도 문서 밖에서 봅니다. 문서 첫머리에 적힌 상태는 처음 나왔을 때의 것입니다. 뒤에 Historic 같은 다른 상태로 바뀌어도 문서 안에는 그 변화를 적을 수 없습니다.

지금 나오는 RFC 는 첫머리 상태 문단 끝에 정보 페이지 주소를 답니다. 그 페이지에는 문서가 갱신이나 폐기됐는지, 정오표가 있는지 같은 정보가 실릴 수 있습니다. 이 문구와 주소는 바뀔 수 있습니다. 1990년대에 나온 RFC 2026 · RFC 2119 · RFC 1311 의 첫머리에는 이 줄이 없습니다. 지금 상태와 정오표는 그 페이지에서 봅니다.

flowchart TD
    A["스트림 다섯 가운데 한 곳이<br/>승인한 문서"] --> B["RFC Production Center 가<br/>다듬고 번호를 붙여 발행"]
    B --> C["RFC 본문<br/>이 뒤로 안 바뀐다"]
    C -.->|틀린 곳| D["정오표<br/>문서 밖에 붙는다"]
    C -.->|상태가 바뀜| E["정보 페이지<br/>문서 밖에 적힌다"]
    F["고쳐 낸 새 문서<br/>새 RFC 번호"] -->|Obsoletes 또는 Updates| C

그림의 위쪽 세 칸이 발행입니다. 아래쪽 점선 둘은 발행 뒤에 생기는 변화입니다. 본문 칸으로 들어오는 화살표는 새 문서가 옛 문서를 가리키는 관계 하나뿐입니다. 본문 칸에서 나가는 변화는 전부 문서 밖에 적힙니다.

인터넷 초안과 가르는 선

RFC 가 되기 전의 작업본은 인터넷 초안(Internet-Draft)이라고 부릅니다. IETF(Internet Engineering Task Force, 인터넷 기술 규격을 만드는 공개 공동체)에서 규격을 만드는 동안 그 작업본이 인터넷 초안으로 공개되어 검토를 받습니다.

인터넷 초안에는 공식 상태가 없습니다. 언제든 바뀌거나 지워질 수 있습니다. 여섯 달 넘게 새 판이 안 올라오고 RFC 로 내자는 권고도 못 받으면 초안 목록에서 지워집니다.

논문이나 보고서, 제안 요청서가 인터넷 초안을 근거로 들어서는 안 됩니다. 제품이 인터넷 초안을 따른다고 내세워서도 안 됩니다. RFC 로 나오리라고 무리 없이 예상할 수 있는 표준 트랙 규격은 초안 대신 「Work in Progress」라는 말로 가리킬 수 있습니다.

이 시리즈의 RFC 는 모두 RFC 번호를 답니다. 번호가 없는 문서는 이름이 「RFC」여도 이 시리즈가 아닙니다.

출처 문서

이 절은 RFC 시리즈 자신의 규칙을 정한 문서들의 번호·판·상태·대체 관계를 모읍니다. 정본은 rfc-editor.org 가 내는 각 문서의 원문입니다. 스트림 칸은 문서 첫 줄에 찍힌 이름입니다. 상태 칸은 Category 줄입니다.

표의 IAB 는 Internet Architecture Board(인터넷 구조 위원회)입니다. 상태 칸의 BCP 는 Best Current Practice 의 줄임말입니다. 표 안에 제목으로 나오는 STD(Standard)도 줄임말입니다. BCP 와 STD 는 RFC 번호와 따로 붙는 하위 번호입니다.

마지막 칸은 각 문서가 자기 첫머리에 적은 관계입니다. 이 표의 문서 가운데서는 RFC 9280 이 RFC 8729 와 RFC 7841 을, RFC 6410 이 RFC 2026 을, RFC 8174 가 RFC 2119 를 갱신했습니다.

상태 칸을 보면 시리즈의 틀을 정한 세 문서(RFC 8729 · RFC 9280 · RFC 7841)가 전부 IAB 스트림의 Informational 문서입니다. 세 문서의 상태 문단에는 「IAB 가 승인한 문서는 어느 단계의 인터넷 표준 후보도 아니다」가 적혀 있습니다. 표준을 만드는 절차는 표준 트랙 문서가 아니라 BCP 번호를 단 문서가 정합니다. 이 표의 RFC 2026 과 RFC 6410 이 BCP 9 를 답니다.

IETF 절차와 RFC 스트림의 지금 내용을 보려면 어느 번호를 펴야 하는지는 RFC 7841 §2 가 2016년에 목록으로 들었습니다. RFC 2026 · RFC 5742 · RFC 4844 · RFC 6410 · RFC 7127 과 그 뒤를 이은 문서입니다. 다만 이 목록의 RFC 4844 는 2020년에 위 표의 RFC 8729 가 폐기했습니다. RFC 4844 자리에 지금 펴 볼 문서는 RFC 8729 입니다.

RFC 9280 §6 은 시리즈 전체의 정책을 내는 Editorial 스트림을 새로 만들었습니다. 이 스트림의 문서는 전부 Informational 로 나갑니다. 그 상태와 상관없이 이 문서들이 시리즈 전체의 정책을 정합니다.

flowchart TD
    N9280["RFC 9280 · 2022년"] -->|갱신| N8729["RFC 8729 · 2020년"]
    N9280 -->|갱신| N7841["RFC 7841 · 2016년"]
    N9280 -->|폐기| N8728["RFC 8728"]
    N8729 -->|폐기| N4844["RFC 4844"]
    N7841 -->|폐기| N5741["RFC 5741"]

화살표는 모두 새 문서에서 옛 문서로 갑니다. 라벨이 관계를 가릅니다. RFC 4844 나 RFC 5741 을 근거로 든 옛 글은 이미 폐기된 문서를 본 것입니다.

RFC 9280 이 RFC 8729 를 갱신한 대목 하나는 RFC Editor 역할을 셋으로 대체한 것입니다. 정책안을 쓰는 공개 모임 RSWG(RFC Series Working Group), 그 안을 승인하는 기구 RSAB(RFC Series Approval Board), 자문 편집자 RSCE(RFC Series Consulting Editor)입니다. 다만 「RFC Editor 기능」이라는 이름은 남아 있습니다. 지금은 이 셋에 RFC Production Center 와 IETF LLC(IETF Administration Limited Liability Company)를 더한 다섯을 묶어 부르는 이름입니다. 앞 절에서 발행 실무를 맡는다고 한 RFC Editor 가 이 묶음입니다.

RSAB 의 이름 풀이는 RFC 9280 안에서도 갈립니다. Abstract 와 §2 는 Approval Board 로, §1 은 Advisory Board 로 적습니다. 이 편은 하는 일에 맞는 Approval Board 를 씁니다.

요구 강도

RFC 를 읽다 보면 대문자로 적은 영어 낱말이 자주 나옵니다. 구현하는 쪽이 얼마나 반드시 지켜야 하는지를 나타내는 낱말입니다. 뜻은 RFC 2119 §1~§5 가 정합니다.

RFC 8174 §2 는 이 뜻이 전부 대문자로 적었을 때만 붙는다고 고쳤습니다. 소문자 「should」는 평범한 영어 뜻입니다.

규범 문장은 구현이 지켜야 할 요구를 적은 문장입니다. 이 낱말을 꼭 써야 규범 문장이 되는 것은 아닙니다. 낱말 없이 적은 규범 문장도 규범입니다. RFC 2119 와 RFC 8174 를 묶은 번호가 BCP 14 입니다.

이 낱말들의 무게는 그 낱말을 쓴 문서의 요구 수준(requirement level)에 따라 달라집니다.

이 시리즈가 정하지 않은 것

이 절은 시리즈의 규칙 문서들이 값을 안 박고 밖으로 넘긴 두 대목을 봅니다. 하나는 보관과 색인의 구체적인 요구 사항입니다. 다른 하나는 새 스트림을 만드는 요건과 절차입니다.

보관과 색인의 요구 사항은 원칙적으로 공동체 합의 문서가 정해야 합니다. 실무로는 시리즈가 시작된 뒤로 쌓여 온 보관소를 이어 씁니다. 구체적인 요구 사항은 계약과 작업 명세로 정합니다. 한쪽은 RFC Editor 기능이고 다른 한쪽은 IETF 의 운영을 떠받치는 조직입니다.

새 스트림을 만드는 요건과 절차는 RFC 9280 §6 이 범위 밖으로 둡니다. 2020년에 나온 RFC 8729 §5 는 새 스트림이 당장 생길 것으로 보지 않았습니다. 만들지 않는 편이 낫다(NOT be created)는 쪽이었습니다. 그런데 2022년에 나온 RFC 9280 이 다섯째 스트림을 만들었습니다.

본문 주장과 근거 절

이 편이 세운 주장마다 어느 문서의 어느 절을 근거로 삼았는지 모은 표입니다.

예시

이 절은 스트림과 상태가 다른 RFC 두 편의 첫머리를 나란히 놓습니다. 그리고 정오표가 붙은 실물 하나를 봅니다. 첫머리는 RFC 마다 같은 틀이라 두 편을 견주면 어느 줄이 무엇을 알리는지 드러납니다.

RFC 9110 의 첫머리

HTTP 의 뜻을 정한 문서입니다. IETF 스트림의 표준 트랙 문서입니다.

Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
Request for Comments: 9110                                         Adobe
STD: 97                                               M. Nottingham, Ed.
Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235,                    Fastly
           7538, 7615, 7694                              J. Reschke, Ed.
Updates: 3864                                                 greenbytes
Category: Standards Track                                      June 2022
ISSN: 2070-1721

                             HTTP Semantics

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9110.

왼쪽 줄을 위에서부터 읽습니다.

ISSN 은 International Standard Serial Number(국제 표준 연속 간행물 번호)입니다. 문서 한 편이 아니라 시리즈 제목 하나를 가리킵니다. 그래서 이 줄을 단 RFC 는 모두 같은 값을 답니다. RFC 2026 과 RFC 2119 의 첫머리에는 이 줄이 없습니다.

그 아래 「Status of This Memo」는 문단 셋입니다. 첫 문단은 상태를 한 문장으로 밝힙니다. 둘째 문단은 어느 스트림에서 어떤 검토를 거쳤는지 적습니다. 셋째 문단이 지금 상태와 정오표를 볼 정보 페이지 주소입니다.

RFC 9110 의 둘째 문단을 읽으면 이 문서가 IETF 공동체의 합의임을 알 수 있습니다. 공개 검토도 받았습니다. IESG(Internet Engineering Steering Group, IETF 스트림 문서의 발행을 승인하는 기구)가 발행을 승인했다고도 적혀 있습니다.

RFC 8700 의 첫머리

RFC 시리즈 50주년을 맞아 낸 회고 문서입니다. IAB 스트림의 Informational 문서입니다.

Internet Architecture Board (IAB)                       H. Flanagan, Ed.
Request for Comments: 8700                                    RFC Editor
Updates: 2555, 5540                                        December 2019
Category: Informational
ISSN: 2070-1721

                          Fifty Years of RFCs

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Architecture Board (IAB)
   and represents information that the IAB has deemed valuable to
   provide for permanent record.  It represents the consensus of the
   Internet Architecture Board (IAB).  Documents approved for
   publication by the IAB are not candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8700.

RFC 9110 과 아래 다섯 곳을 견줍니다.

상태 첫 문단의 문장은 상태마다 정해져 있습니다. 아래는 RFC 7841 이 정한 지금의 문구입니다. Best Current Practice 문서는 「This memo documents an Internet Best Current Practice.」로 엽니다. Experimental 문서의 첫 문단은 「it is published for examination, experimental implementation, and evaluation.」로 끝납니다. Historic 문서는 「it is published for the historical record.」로 끝납니다.

옛 RFC 의 문구는 다릅니다. 1996년에 나온 RFC 2026 의 상태 문단은 「This document specifies an Internet Best Current Practices for the Internet Community」로 엽니다. 그래도 지금 나온 문서라면 첫 문단 한 줄만 읽어도 얼마나 무겁게 읽을지 알 수 있습니다.

RFC 9110 의 정오표 7419번

rfc-editor.org 의 RFC 9110 정오표 페이지에 올라 있는 보고 하나입니다.

Errata-ID: 7419
Status: Verified
Type: Technical
Reported By: Dave Shawley
Date Reported: 2023-04-11
Verified by: Francesca Palombini
Date Verified: 2023-10-23

Section 8.3.2 says:
In the fields defined by this document, charset names appear either
in parameters (Content-Type), or, for Accept-Encoding, in the form of
a plain token.

It should say:
In the fields defined by this document, charset names appear either
in parameters (Content-Type), or, for Accept-Charset, in the form of
a plain token.

RFC 9110 §8.3.2 의 한 문장에서 헤더 이름 Accept-Encoding 을 Accept-Charset 으로 고치라는 보고입니다. 2023년 4월에 들어와 같은 해 10월에 확인(Verified)을 받았습니다.

2026년 10월 기준 RFC 9110 §8.3.2 본문에는 여전히 「for Accept-Encoding」이 적혀 있습니다. 확인을 받은 정정도 본문은 바꾸지 않고 정오표 페이지에 붙습니다. RFC 를 구현 근거로 쓸 때 본문과 함께 정오표 페이지를 여는 까닭이 이것입니다.

배경

1969년 봄, 인터넷의 전신이 된 연구용 망 ARPANET(ARPA wide-area networking, ARPA 광역망)을 설계하던 작은 모임이 있었습니다. 이 모임(Network Working Group)은 논의를 적어 남기기로 했습니다. 메모를 묶는 일을 맡은 스티브 크로커(Steve Crocker)는 이 메모가 갖지도 않은 권위를 내세우는 것처럼 보일까 걱정했습니다. 어딘가 있을 공식 프로토콜 설계자들의 기분을 상하게 할까 봐서였습니다.

적어 둔 글은 저절로 권위가 있는 것처럼 읽히기 쉽습니다. 덜 다듬은 생각은 내놓기를 꺼리게 됩니다. 이 두 가지를 덜어 내려고 세운 규칙이 「누구나 무엇이든 말할 수 있고 어느 것도 공식이 아니다」였습니다. 이 점을 드러내려고 동료 빌 듀발(Bill Duvall)의 제안을 받아 메모에 「Request for Comments」라는 이름표를 붙였습니다.

첫 편 RFC 1 은 1969년 4월 7일에 나왔습니다. 같은 달 나온 RFC 3 은 메모가 다듬은 글보다 제때 나온 글이기를 바랐습니다. 한 문장짜리 메모도 받았습니다.

초기 RFC 의 목표는 기록을 남기는 것이 아니라 대화를 여는 것이었습니다. 발행 절차가 격식을 갖췄습니다. 읽는 사람도 늘었습니다. 그러면서 목표가 바뀌었습니다.

2019년에는 발행된 RFC 가 8500편을 넘었습니다. 지금 시리즈의 목표는 발행한 글을 정본으로 내놓고 영구히 보존하는 것입니다. 이름만 처음 것이 남았습니다. 그래서 이름만 보고 RFC 를 초안으로 읽으면 틀립니다.

갈래

RFC 한 편에는 두 축이 찍힙니다. 하나는 스트림입니다. 어느 창구가 승인했는지를 알립니다. 다른 하나는 상태입니다. 얼마나 무겁게 읽을지를 알립니다. 스트림은 첫머리 첫 줄에 적힙니다. 상태는 두 군데에 나뉘어 적힙니다. Category 줄에는 표준 트랙인지 아닌지까지가 찍힙니다. 표준 트랙 안의 어느 단계인지는 정보 페이지에서 봅니다. 여기에 표준과 관행 문서에만 붙는 하위 번호가 하나 더 있습니다.

스트림

스트림은 다섯입니다. 넷이 먼저 있었습니다. 다섯째 Editorial 스트림은 2022년에 더해졌습니다. 아래 표에 나오는 IRTF 는 Internet Research Task Force(인터넷 연구 태스크포스)입니다. IAB 아래 활동으로 세워진 연구 조직입니다.

Editorial 스트림은 시리즈 전체의 정책만 냅니다. 정책안은 RSWG 가 씁니다. IETF 와 따로 도는 공개 모임입니다. 그 안을 RSAB 가 승인하거나 RSWG 로 돌려보냅니다. RSAB 에는 각 스트림 대표와 RSCE 가 들어갑니다.

flowchart TD
    subgraph B["RSAB — 승인 기구"]
        M1["각 스트림 대표"]
        M2["RSCE — 출판 전문가"]
    end
    W["RSWG — 정책안을 쓴다"] --> B
    B -->|승인| P["Editorial 스트림 RFC<br/>Informational 로 나간다"]
    B -->|돌려보냄| W

승인을 받은 정책안만 Editorial 스트림의 RFC 로 나옵니다. 돌려보낸 안은 RSWG 가 고치거나 거둡니다.

표준 트랙과 BCP 문서는 IETF 스트림만 낼 수 있습니다. 다른 스트림의 문서는 대개 IETF 가 보안·혼잡 제어·이미 배포된 프로토콜과 잘못 얽히는지를 검토하지 않습니다. 그래서 IETF 는 이런 문서가 어떤 목적에 맞는지 알지 못한다고 밝힙니다.

옛 RFC 는 첫 줄에 스트림 대신 모두 「Network Working Group」을 적었습니다. RFC 2026 과 RFC 2119 의 첫머리가 그렇습니다.

상태

상태는 문서를 얼마나 무겁게 읽을지 알립니다. Category 줄에 찍히는 값은 지금 기준으로 다섯 가운데 하나입니다. 그중 표준 트랙은 그 안에서 다시 단계 둘로 갈립니다.

이 두 단계 이름은 Category 줄에 안 찍힙니다. RFC 9110 은 인터넷 표준이어서 STD 97 을 달았지만 Category 줄은 Standards Track 입니다. 어느 단계인지는 정보 페이지에서 봅니다.

표준 트랙 단계는 2011년에 셋에서 둘로 줄었습니다. 그 전에는 제안 표준과 인터넷 표준 사이에 Draft Standard 가 있었습니다. 지금의 인터넷 표준 단계는 옛 Draft Standard 와 Standard 를 합친 것입니다. 그때 Draft Standard 였던 문서는 따로 손대지 않으면 그 딱지를 그대로 갖고 있습니다. 옛 글이 단계를 셋으로 적고 있으면 2011년 전 기준입니다.

flowchart TD
    subgraph OLD["2011년 전 · 단계 셋"]
        O1["Proposed Standard"]
        O2["Draft Standard"]
        O3["Standard"]
    end
    subgraph NEW["2011년 뒤 · 단계 둘"]
        N1["제안 표준"]
        N2["인터넷 표준"]
    end
    O1 --> N1
    O3 -->|곧바로 재분류| N2
    O2 --> K["Draft Standard 딱지를<br/>그대로 달고 있다"]

그림의 위 묶음이 2011년 전 단계 셋입니다. 아래 묶음이 지금의 둘입니다. Standard 문서는 곧바로 인터넷 표준으로 재분류됐습니다. Draft Standard 문서는 그 묶음에 들어가지 못하고 옛 딱지를 답니다.

제안 표준 문서를 그대로 인터넷 표준으로 올리는 재분류는 새 RFC 를 내지 않습니다. 분류만 바꿉니다. 다만 오르는 길에 규격을 고쳐 다시 내는 일도 흔합니다. 재분류도 앞서 본 것처럼 문서 첫머리가 아니라 정보 페이지에 나타납니다.

하위 번호 STD 와 BCP

RFC 번호 말고 하위 번호가 따로 붙는 문서가 있습니다. 인터넷 표준 단계에 오른 규격은 STD 번호를 받습니다. BCP 로 승인된 문서는 BCP 번호를 받습니다. 어느 쪽이든 원래 RFC 번호는 그대로 갖습니다.

RFC 번호는 문서 한 편을 가리킵니다. STD 번호는 문서가 아니라 표준 하나를 가리킵니다. 그래서 한 표준이 여러 문서에 나뉘어 있으면 문서마다 같은 STD 번호를 답니다. DNS(Domain Name System)가 그런 예입니다. 1992년 기준으로 DNS 규격은 RFC 1034 와 RFC 1035 를 합친 것이었습니다. 두 편 모두 STD 13 을 달았습니다.

같은 표준을 고쳐 새 문서로 내면 RFC 번호는 새로 받습니다. STD 번호는 그대로 이어받습니다. BCP 도 같은 방식입니다. 앞 절의 요구 강도 두 문서는 BCP 14 를 함께 답니다. RFC 2026 과 RFC 6410 은 BCP 9 를 함께 답니다.

flowchart TD
    subgraph STD13["STD 13 · DNS"]
        R1034["RFC 1034"]
        R1035["RFC 1035"]
    end
    subgraph BCP14["BCP 14 · 요구 강도 낱말"]
        R2119["RFC 2119"]
        R8174["RFC 8174"]
    end
    subgraph BCP9["BCP 9 · 표준화 절차"]
        R2026["RFC 2026"]
        R6410["RFC 6410"]
    end

그림은 이 편이 다룬 묶음 셋입니다. 한 묶음 안의 문서들이 같은 하위 번호를 답니다. 그 하위 번호를 다는 문서가 묶음 안의 둘뿐이라는 뜻은 아닙니다.

관련 항목

RFC 를 만들고 내는 조직

IETF · IESG · RFC Editor · 워킹그룹 · IAB · IRTF · IANA · ISOC · RFC Production Center · RSWG · RSAB · RFC Series Consulting Editor · IETF LLC · Network Working Group

RFC 첫머리에 찍히는 값

RFC 스트림 · Independent Submission · Editorial Stream · Obsoletes · Updates · Status of This Memo · ISSN

RFC 가 거치는 단계와 상태

Internet-Draft · 제안 표준 · 인터넷 표준 · 표준 트랙 · BCP · STD · 정오표 · 대략적 합의 · Draft Standard · Informational · Experimental · Historic

RFC 시리즈의 규칙을 정한 문서

RFC 8729 · RFC 9280 · RFC 7841 · RFC 2026 · RFC 6410 · RFC 1311 · RFC 7322 · RFC 8700 · RFC 1 · RFC 3

RFC 로 정의된 프로토콜과 포맷

HTTP · RFC 9110 · TCP · UDP · IP · DNS · RFC 1034 · RFC 1035 · TLS · JSON · URI · TZif

RFC 를 읽을 때 만나는 요구 강도 낱말

RFC 2119 · RFC 8174 · BCP 14 · MUST · SHOULD · MAY

RFC 와 나란히 표준 문서를 내는 기구

ISO · IEEE · W3C · WHATWG · ITU-T

RFC 번호를 근거로 드는 기술 주제

지연 · 윤초 · 쿠키 · 문자 인코딩 · 라우팅 · ARPANET