RFC 2119

RFC 2119 는 표준 문서가 규칙마다 얼마나 반드시 지켜야 하는지를 낱말 하나로 밝히게 해 줍니다. MUST 나 SHOULD 처럼 흔한 영어 낱말 열한 개를 골라 뜻을 못박아 두었습니다. 다른 표준 문서는 첫머리에 한 문단을 붙여 이 뜻을 끌어다 씁니다.

상세

이 문서가 정하는 것

RFC 2119 의 RFC 는 Request for Comments 의 줄임말입니다. 인터넷 기술을 다루는 문서에 번호를 붙여 내놓는 문서 묶음입니다. 이 문서는 그 2119번입니다. 1997년 3월에 나왔습니다.

이 문서는 기술을 하나도 정하지 않습니다. 대신 요구 강도를 나타내는 낱말을 정합니다. 요구 강도란 규칙 하나를 얼마나 반드시 지켜야 하는가입니다. 정하는 것은 둘입니다. 그 낱말들의 뜻과, 그 낱말을 써도 되는 경우입니다.

이 낱말은 IETF(Internet Engineering Task Force)의 문서에서 쓰입니다. IETF 는 인터넷 표준을 만드는 단체입니다. 문서 제목을 우리말로 옮기면 「RFC 에서 요구 강도를 나타내는 데 쓰는 핵심 낱말」입니다.

이 낱말들은 뜻이 잘 정해져 있습니다. 그래서 대문자로 적어 두면 문서의 또렷함과 일관성을 크게 높일 수 있습니다.

뜻이 정해진 열한 낱말

정해진 낱말은 열한 개입니다. MUST NOT 처럼 두 낱말로 된 것도 하나로 칩니다. 뜻이 같은 것끼리 묶으면 다섯 덩이가 됩니다. 한 덩이 안에서는 어느 쪽을 골라 써도 뜻이 같습니다.

한 줄에 같이 놓인 낱말은 골라 쓰는 취향만 다릅니다. REQUIRED 를 만나면 MUST 를 만난 것과 같게 읽으면 됩니다.

어겼을 때 생기는 일

요구 강도의 차이는 규칙을 안 지켰을 때 무슨 일이 생기는지에서 드러납니다. 이 소절은 MUST · SHOULD · MAY 를 어긴 구현이 저마다 무엇을 치르는지 봅니다.

MUST 는 그 표준의 절대적 요구입니다. 어긴 구현은 그 표준을 따르지 않은 것입니다. 「대체로 따른다」는 없습니다.

SHOULD 는 어길 길을 열어 둡니다. 특정한 상황에서는 따르지 않을 타당한 이유가 있을 수 있기 때문입니다.

대신 조건을 답니다. 다른 길을 고르기 전에 따라오는 결과를 전부 이해해야 합니다. 그 결과를 신중하게 저울질해야 합니다. SHOULD 는 「안 해도 된다」가 아니라 「특정한 상황에서 따져 본 이유가 있으면 안 해도 된다」입니다.

MAY 가 붙은 항목은 정말로 선택입니다. 한 업체는 시장이 요구해서 그 항목을 넣을 수 있습니다. 다른 업체는 같은 항목을 뺄 수 있습니다.

대신 조건이 하나 붙습니다. 그 기능을 넣은 구현과 안 넣은 구현은 서로 통할 준비가 돼 있어야 합니다(MUST). 둘이 통할 때 그 기능 하나는 빠집니다. 기능이 줄어든 채로 통할 수도 있습니다.

이 조건은 상호운용성을 지키는 단서입니다. 상호운용성은 서로 다른 구현이 서로 통하는 성질입니다.

대문자일 때만 그 뜻

RFC 2119 는 이 낱말들이 「흔히 대문자로 적힌다」고만 했습니다. 이 문구 탓에 소문자 must 나 should 를 어떻게 읽을지 헷갈림이 생겼습니다.

2017년 5월에 나온 RFC 8174 가 이 헷갈림을 정리했습니다. 전부 대문자로 적었을 때만 정해진 뜻입니다. 소문자면 보통 영어 낱말의 뜻입니다. RFC 2119 와 RFC 8174 가 정한 뜻의 영향을 받지 않습니다.

한 가지가 더 분명해졌습니다. 이 낱말을 쓰는 것 자체는 의무가 아닙니다. 지켜야 할 규칙을 정하는 문장을 규범 문장이라 합니다. 대문자 낱말을 쓰지 않는 규범 문장이 많습니다. 그 문장도 규범입니다.

규칙 한 줄을 읽는 쪽에서 보면 판단은 이렇게 갈립니다.

flowchart TD
    A["규칙에 붙은 영어 낱말"] --> B{"전부 대문자인가"}
    B -->|아니다| C["보통 영어 낱말의 뜻이다<br/>정해진 뜻의 영향을 받지 않는다"]
    B -->|맞다| D{"어느 낱말인가"}
    D -->|MUST| E["어기면 이 표준을<br/>안 지킨 것이다"]
    D -->|SHOULD| F["특정한 상황에서 따져 본 이유가<br/>있으면 어겨도 된다"]
    D -->|MAY| G["넣든 안 넣든 된다<br/>대신 서로 통해야 한다"]

인용 문단과 BCP 14

표준 문서는 이 뜻을 자기 문서 안으로 들이려고 첫머리 가까이에 정해진 한 문단을 붙입니다. 이 문단을 인용 문단이라 부릅니다. 인용 문단에는 옛 꼴과 새 꼴이 있습니다.

옛 꼴은 RFC 2119 가 1997년에 내놓은 문단입니다. 낱말 열 개를 늘어놓습니다. 그리고 「RFC 2119 에 적힌 대로 읽어라」라고 합니다. NOT RECOMMENDED 는 이 목록에 없습니다.

새 꼴을 보기 전에 번호 하나를 짚어야 합니다. RFC 2119 는 RFC 번호 말고 BCP 번호도 받았습니다. BCP(Best Current Practice, 현행 최선 관행)는 RFC 가운데 관행을 정해 두는 문서에 따로 매기는 번호 갈래입니다. RFC 2119 가 그 갈래에서 받은 번호가 14 입니다.

BCP 번호를 받아도 RFC 번호는 남습니다. 두 번호는 가리키는 대상이 다릅니다. RFC 번호는 문서 한 편에 붙습니다. BCP 번호는 관행 하나에 붙습니다. 한 BCP 가 RFC 여러 편으로 이루어질 수 있습니다.

새 문서가 옛 문서를 갱신하면 같은 BCP 번호를 씁니다. 그래서 BCP 14 는 지금 두 문서로 이루어집니다. RFC 2119 와, 그것을 갱신한 RFC 8174 입니다.

새 꼴은 RFC 8174 가 2017년에 낸 문단입니다. NOT RECOMMENDED 를 더해 열한 낱말을 늘어놓습니다. 가리키는 곳은 「BCP 14 [RFC2119] [RFC8174]」입니다. BCP 14 라는 번호 아래 두 문서를 함께 가리킵니다. 「전부 대문자로 적혔을 때만」이라는 조건도 붙었습니다.

두 꼴이 무엇을 가리키는지 그리면 이렇습니다.

flowchart TD
    O["옛 꼴 인용 문단 · 1997년"] --> D
    N["새 꼴 인용 문단 · 2017년"] --> C
    subgraph C["BCP 14"]
        D["RFC 2119 · 낱말 열한 개의 뜻"]
        E["RFC 8174 · 대문자일 때만 그 뜻"]
    end

두 꼴의 문단 원문은 뒤의 예시 절에 있습니다.

문서를 쓰는 쪽의 단서

이 소절은 표준 문서를 쓰는 저자에게 붙는 단서 둘을 봅니다. 하나는 이 낱말을 아껴 쓰라는 것입니다. 다른 하나는 보안 영향을 풀어 적으라는 것입니다.

이 낱말들은 조심해서 아껴 써야 합니다. 써도 되는 경우는 둘입니다. 하나는 서로 다른 구현이 서로 통하는 데 그 규칙이 정말로 필요할 때입니다. 다른 하나는 해를 끼칠 수 있는 동작을 묶어 둘 때입니다. 재전송을 제한하는 규칙이 이쪽 예입니다.

RFC 2119 는 막아 둔 쓰임도 예로 듭니다. 상호운용에 필요하지 않은 특정 방법을 구현하는 쪽에 강요하려고 이 낱말을 쓰면 안 됩니다. 규칙 하나에 대문자 낱말을 붙일지는 이렇게 갈립니다.

flowchart TD
    A["규칙에 대문자 낱말을 붙이려 한다"] --> B{"서로 통하는 데<br/>정말로 필요한가"}
    B -->|맞다| C["써도 된다"]
    B -->|아니다| D{"해를 끼칠 수 있는<br/>동작을 묶나<br/>예: 재전송 제한"}
    D -->|맞다| C
    D -->|아니다| E["쓰지 않는다"]

둘째 단서는 보안입니다. 이 낱말들은 보안에 영향을 주는 동작을 정하는 데 자주 쓰입니다. MUST · SHOULD 를 구현하지 않았을 때 보안에 생기는 영향은 아주 미묘할 수 있습니다. MUST NOT · SHOULD NOT 이라고 한 것을 했을 때도 같습니다.

그래서 저자는 권고나 요구를 안 따랐을 때의 보안 영향을 시간을 들여 풀어 적어야 합니다. 구현하는 사람 대부분은 그 표준 문서를 만든 경험과 토론을 겪지 않았기 때문입니다.

낱말이 실린 문서의 요구 수준

규칙 한 줄에 요구 강도가 있습니다. 그 규칙이 실린 문서에도 요구 수준이 따로 있습니다. 요구 강도는 규칙 한 줄의 무게입니다. 문서의 요구 수준은 그 규칙이 실린 문서 쪽의 무게입니다.

RFC 2119 는 낱말의 힘이 문서의 요구 수준에 따라 달라진다고 적습니다. 같은 MUST 라도 어느 문서에 실렸느냐가 그 힘을 바꿉니다. 문서의 요구 수준을 어떻게 매기는지는 RFC 2119 가 정하지 않습니다. 어느 문서가 어느 수준인지는 자료에 없습니다(미확인).

출처 문서

이 절은 RFC 2119 의 번호 · 상태 · 갱신 관계를 적습니다. 그리고 본문의 주장이 어느 문서 몇 절에서 왔는지 짚습니다. 정본은 rfc-editor.org 가 내는 원문입니다. 문서 머리가 번호와 상태를 함께 적습니다.

Network Working Group                                         S. Bradner
Request for Comments: 2119                            Harvard University
BCP: 14                                                       March 1997
Category: Best Current Practice


        Key words for use in RFCs to Indicate Requirement Levels

번호는 RFC 2119, 발행은 1997년 3월입니다. 분류(Category)는 Best Current Practice 입니다. BCP 14 번을 받았습니다.

저자는 Harvard University 의 S. Bradner 입니다. rfc-editor.org 정보 페이지에 따르면 이 문서는 개인 제출(Individual Submission)로 들어왔습니다.

갱신 관계

RFC 2119 는 폐기(Obsoleted)되지 않았습니다. 갱신(Updated)만 됐습니다. 정보 페이지의 「Updated by」 줄에 RFC 8174 하나가 올라 있습니다. 정오표(Errata, 펴낸 뒤 보고된 오류 목록)도 따로 올라 있습니다.

Internet Engineering Task Force (IETF)                          B. Leiba
Request for Comments: 8174                           Huawei Technologies
BCP: 14                                                         May 2017
Updates: 2119
Category: Best Current Practice
ISSN: 2070-1721


       Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

RFC 8174 는 2017년 5월에 B. Leiba 가 냈습니다. 머리의 「Updates: 2119」 가 갱신 관계를 밝힙니다. 같은 BCP 14 번을 달았습니다.

이 문서는 IETF 공동체의 합의를 거쳤습니다. IESG(Internet Engineering Steering Group)의 발행 승인도 받았습니다.

RFC 8174 에도 RFC 2119 의 §7 처럼 보안 고려 사항(Security Considerations) 절이 있습니다. 그 절은 이 문서가 절차만 다룬다고 적습니다. 그래서 관련된 보안 고려 사항이 없다고 밝힙니다.

rfc-editor.org 의 BCP 14 정보 페이지는 「BCP 14 subseries contains 2 RFCs」 라는 제목 아래 이 두 문서를 나란히 올려 둡니다.

RFC 2119 자신이 건 요구

RFC 2119 도 자기 문서 안에서 대문자 MUST 를 씁니다. 낱말 이름으로 든 경우를 빼면, 요구로 쓴 대문자 MUST 는 두 절에만 나옵니다.

나머지 절의 must · should 는 소문자입니다. §3 SHOULD 의 「must be understood」와 §6 첫 문장의 「must be used with care and sparingly」가 그렇습니다. 이 소문자들은 1997년에 쓰였습니다. 대문자일 때만 정해진 뜻이라는 RFC 8174 의 규정은 그 뒤 2017년에 나왔습니다.

본문 주장과 근거 절

아래 표에는 뒤 절에서 다룰 RFC 1122 · RFC 7322 도 나옵니다. RFC 2026 은 인터넷 표준을 만드는 절차를 정한 문서입니다. RFC 7841 은 RFC 의 머리와 정해진 문구를 정한 문서입니다.

예시

이 절은 남의 표준 문서가 RFC 2119 를 끌어다 쓰는 예 둘을 봅니다. IETF 문서인 RFC 9110 과, IETF 밖 문서인 시맨틱 버저닝 2.0.0 입니다. 둘 다 인용 문단과 그 아래 규범 문장을 같이 봅니다.

RFC 9110 의 인용 문단과 Host 규칙

RFC 9110 은 HTTP(HyperText Transfer Protocol)의 의미를 정하는 표준 문서입니다. 2022년 6월에 정식 표준화 절차(Standards Track)를 밟는 문서로 나왔습니다. §2.2 Requirements Notation 의 첫 문단이 새 꼴 인용 문단을 낱말 하나 안 바꾸고 옮겨 왔습니다.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

NOT RECOMMENDED 까지 열한 낱말을 다 늘어놓습니다. 끝에는 「전부 대문자로 적혔을 때만, 그리고 그때만」이라는 조건이 붙습니다.

이 문단이 있어서 RFC 9110 안의 대문자 낱말은 BCP 14 의 뜻으로 읽힙니다. §7.2 Host and :authority 의 한 문단에 MUST 문장과 SHOULD 문장이 나란히 있습니다.

A user agent MUST generate a Host header field in a request
unless it sends that information as an ":authority" pseudo-header
field.  A user agent that sends Host SHOULD send it as the first
field in the header section of a request.

요청을 보내는 쪽인 사용자 에이전트는 요청에 Host 헤더를 반드시 넣어야 합니다(MUST). 예외는 같은 정보를 「:authority」 라는 의사 헤더 필드로 보낼 때 하나입니다. 이 예외 없이 Host 를 빼먹으면 그 표준을 안 지킨 것입니다.

Host 를 보낸다면 헤더 맨 앞 필드로 보내라는 것은 SHOULD 입니다. 따져 본 이유가 있으면 다른 순서로 보내도 표준을 어긴 것이 아닙니다.

시맨틱 버저닝 2.0.0 의 인용 문단

IETF 밖에서도 이 문단을 빌려 씁니다. 버전 번호를 매기는 규칙인 시맨틱 버저닝 2.0.0 이 그런 예입니다. 규칙 목록 바로 위에 이 문단이 있습니다. 첫 규칙이 곧바로 대문자 낱말을 씁니다.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be
interpreted as described in RFC 2119.

1. Software using Semantic Versioning MUST declare a public API. This API
could be declared in the code itself or exist strictly in documentation.
However it is done, it SHOULD be precise and comprehensive.

첫 규칙은 시맨틱 버저닝을 쓰는 소프트웨어가 공개 API(Application Programming Interface)를 반드시 밝혀야 한다는 것입니다(MUST). 그 API 를 정밀하고 빠짐없이 밝히라는 것은 SHOULD 입니다.

두 인용 문단을 견주면 차이가 셋입니다.

시맨틱 버저닝의 문단은 옛 꼴 인용 문단과 같은 꼴입니다. RFC 9110 의 문단은 새 꼴입니다. 표의 차이 셋이 두 꼴의 차이입니다.

배경

RFC 2119 가 나오기 전에도 여러 표준 문서가 요구를 나타내려고 낱말 몇 개를 썼습니다. 그 낱말은 흔히 대문자로 적었습니다. 그런데 그 뜻은 여러 RFC 가 저마다 자기 문서 안에서 따로 정의했습니다.

1989년 10월에 나온 RFC 1122 가 그런 예입니다. 인터넷 호스트가 지켜야 할 통신 요구사항을 정한 문서입니다. 문서 안의 한 절에서 MUST · SHOULD · MAY 를 스스로 정의합니다.

이 문서는 준수 등급까지 둡니다. MUST 를 하나라도 못 지키면 준수가 아닙니다. MUST 와 SHOULD 를 다 지키면 「무조건 준수」입니다.

SHOULD 가운데 못 지킨 것이 있어도 MUST 를 다 지켰다면 「조건부 준수」입니다.

같은 낱말을 문서마다 따로 정의하면 같은 정의를 문서마다 다시 적어야 합니다. RFC 2119 는 여러 RFC 의 정의를 합쳐 한 문서로 세웠습니다. 뒤에 나오는 문서는 첫머리 한 문단으로 그 정의를 끌어다 씁니다. 이 낱말을 쓰는 것 자체는 지금도 의무가 아닙니다.

세 문서를 나온 차례로 놓으면 이렇습니다.

timeline
    1989년 10월 : RFC 1122 : MUST · SHOULD · MAY 를 문서 안에서 스스로 정의
    1997년 3월 : RFC 2119 : 여러 RFC 의 정의를 합침 · BCP 14
    2017년 5월 : RFC 8174 : 대문자일 때만 그 뜻 · RFC 2119 를 갱신

경계

이 절은 RFC 2119 를 인용하지 않은 RFC 에서 대문자 낱말을 어떻게 읽는지 판정합니다. 판정 근거는 RFC 7322 입니다. RFC 를 다듬어 펴내는 RFC 에디터가 낸 표기 지침입니다.

RFC 2119 를 인용하지 않은 RFC 에 대문자 MUST 가 있으면, 그것은 RFC 2119 의 MUST 인가. 바로 그렇다고 볼 수 없습니다. 그 문서가 따로 적은 해석부터 찾아야 합니다.

RFC 2119 는 IETF 문서의 대문자 낱말에 기본 해석을 줍니다. RFC 로 나오는 문서가 이 기본 해석을 쓰려면 RFC 2119 를 인용해야 합니다. 규범 참조로도 넣어야 합니다. 규범 참조는 그 문서를 지키려면 함께 읽어야 하는 참조입니다. 이 해석을 쓰지 않는 문서는 올바른 해석을 문서 안에 적어야 합니다.

판정을 가르는 것은 RFC 2119 를 인용했느냐입니다. 인용 문단이 옛 꼴이어도 RFC 2119 를 인용한 것입니다. 옛 꼴은 RFC 2119 를 이름으로 가리키기 때문입니다.

RFC 7322 자신이 RFC 2119 의 해석을 쓰지 않는 문서입니다. §3 첫 문단이 자기 해석을 적습니다. 대문자 낱말의 예는 아닙니다. 대신 소문자 must · should 에 뜻을 따로 정합니다.

This Style Guide does not use terminology as defined in RFC 2119
[BCP14].  In this document, lowercase use of "must" and "should"
indicates changes the RFC Editor will make automatically to conform
with this Style Guide versus those that may be questioned if not
applied.

이 문서는 RFC 2119 가 정한 뜻으로 낱말을 쓰지 않는다고 먼저 밝힙니다. 소문자 must 는 RFC 에디터가 자동으로 고치는 변경을 뜻합니다. 저자가 고를 수 있는 것이 아닙니다. 소문자 should 는 RFC 에디터가 권하는 쓰임입니다. 따르는 것이 의무는 아닙니다. 같은 must 라도 그 문서가 적은 해석이 뜻을 정합니다.

관련 항목

BCP 14 를 이루는 문서와 번호 체계

RFC 8174 · BCP · STD · RFC 2026 · RFC 7841 · 인터넷 표준

이 문서가 뜻을 정한 낱말

MUST · MUST NOT · REQUIRED · SHALL · SHALL NOT · SHOULD · SHOULD NOT · RECOMMENDED · NOT RECOMMENDED · MAY · OPTIONAL

이 낱말들을 끌어다 쓰는 표준 문서

RFC 9110 · RFC 9111 · JWT · OAuth 2.0 · JSON · 시맨틱 버저닝 · DOM · WCAG

요구 강도 낱말을 자기 문서 안에서 따로 정한 규약

RFC 1122 · RFC 7322 · XML · ISO · IEEE

RFC 를 펴내는 단체와 절차

RFC · IETF · IESG · IANA · RFC 에디터 · 인터넷 드래프트 · 표준화 트랙 · 정오표 · 보안 고려 사항

요구 강도가 겨냥하는 목표

상호운용성 · 적합성 · 준수 시험 · 참조 구현 · 명세