본문으로 건너뛰기

RFC 2119

개념

IETF 문서에서 요구 수준을 나타내는 규범적 핵심어의 의미와 사용 지침을 정의한 Best Current Practice 문서

목차26개 항목

RFC 2119는 인터넷 기술 사양에서 요구 사항의 강도를 표현하는 MUST, SHOULD, MAY 등의 규범적 핵심어를 정의한 IETF 문서이다. Scott Bradner가 작성하여 1997년 3월에 발표되었으며, RFC 번호와 함께 BCP 14에 포함된 Best Current Practice 문서로 관리된다.

RFC 2119의 목적은 요구 사항을 표현하는 문장에 일관된 의미를 부여하는 것이다. 이 문서는 프로토콜의 기능이나 형식을 직접 규정하지 않고, 다른 기술 사양에서 사용되는 특정 핵심어가 어느 정도의 의무, 금지, 권고 또는 선택을 의미하는지를 정의한다.

2017년 5월에 발표된 RFC 8174는 RFC 2119를 갱신하여, 이러한 특수한 의미가 핵심어를 모두 대문자로 표기했을 때만 적용된다는 점을 명확히 했다. 현재 BCP 14는 RFC 2119와 RFC 8174로 구성된다.

문서 정보

항목 내용
제목 Key words for use in RFCs to Indicate Requirement Levels
문서 번호 RFC 2119
BCP 번호 BCP 14
작성자 Scott Bradner
발행 시기 1997년 3월
문서 범주 Best Current Practice
갱신 문서 RFC 8174
주요 목적 기술 사양에서 요구 수준을 나타내는 핵심어의 의미 정의

RFC 2119는 Internet Standards Track의 특정 성숙도 단계에 속하는 표준 사양이 아니라, 인터넷 공동체가 따를 현행 모범 관행을 기록하는 Best Current Practice 문서이다.

규범적 핵심어

RFC 2119는 요구 수준을 표현하는 핵심어를 다음과 같이 정의한다. 일부 핵심어는 동일한 요구 수준을 나타내는 동의어로 취급된다.

핵심어 동등한 표현 의미
MUST REQUIRED, SHALL 사양이 정하는 절대적인 요구 사항이다. 준수 구현은 해당 요구 사항을 따라야 한다.
MUST NOT SHALL NOT 사양이 정하는 절대적인 금지 사항이다. 준수 구현은 해당 동작을 해서는 안 된다.
SHOULD RECOMMENDED 일반적으로 따라야 하는 권고 사항이다. 특정 상황에서 이를 따르지 않을 타당한 이유가 있을 수 있지만, 다른 방식을 선택하기 전에 그 영향을 충분히 이해하고 신중하게 검토해야 한다.
SHOULD NOT NOT RECOMMENDED 일반적으로 피해야 하는 동작이다. 특정 상황에서 해당 동작이 허용되거나 유용할 수 있지만, 이를 구현하기 전에 그 영향을 충분히 이해하고 신중하게 검토해야 한다.
MAY OPTIONAL 구현 여부를 선택할 수 있는 기능이나 동작이다.

MUST와 MUST NOT

MUST는 사양의 절대적인 요구 사항을 나타낸다. REQUIRED와 SHALL도 같은 의미로 정의된다. MUST NOT은 절대적인 금지를 나타내며, SHALL NOT이 같은 의미로 사용된다.

이러한 표현은 단순히 작성자가 선호하는 구현 방식을 강조하기 위한 용도가 아니다. RFC 2119는 상호운용성을 확보하거나 잠재적으로 유해한 동작을 제한하기 위해 실제로 필요한 경우에만 절대적 요구 사항을 사용하도록 규정한다.

SHOULD와 SHOULD NOT

SHOULD는 선택 사항을 의미하지 않는다. 원칙적으로는 해당 요구 사항을 따르는 것이 권고되지만, 특정 상황에서는 이를 따르지 않을 타당한 이유가 존재할 수 있다. 이 경우 구현자는 다른 방식을 선택하기 전에 그에 따른 전체적인 영향을 이해하고 검토해야 한다.

SHOULD NOT도 절대적인 금지를 의미하지는 않는다. 특정 동작을 일반적으로 피해야 하지만, 제한된 상황에서는 그 동작이 허용 가능하거나 유용할 수 있다. 예외를 적용할 때에는 마찬가지로 그 영향을 이해하고 신중하게 판단해야 한다.

MAY와 OPTIONAL

MAY와 OPTIONAL은 해당 기능이나 동작의 구현 여부가 선택적이라는 의미이다. 구현자는 시장 요구, 제품 기능 또는 기타 이유에 따라 선택 기능을 포함하거나 제외할 수 있다.

선택 기능을 구현하지 않은 시스템은 해당 기능을 구현한 시스템과 상호운용할 수 있어야 하며, 반대의 경우도 마찬가지이다. 선택 기능 자체를 사용할 수 없는 데 따른 기능 축소는 허용되지만, 선택 기능의 유무가 기본적인 상호운용성을 불필요하게 훼손해서는 안 된다.

대문자 표기

RFC 2119의 원문은 요구 수준을 나타내는 핵심어가 흔히 대문자로 표기된다고 설명했다. 이 표현은 소문자로 작성된 일반 영어 단어에도 RFC 2119의 특수한 의미가 적용되는지를 두고 혼동을 일으켰다.

RFC 8174는 다음과 같이 표기 규칙을 명확히 했다.

  • 핵심어가 모두 대문자로 표기된 경우에만 BCP 14의 특수한 의미가 적용된다.
  • 소문자 또는 일반적인 문장 형태로 작성된 단어는 통상적인 영어 의미를 가진다.
  • 규범적인 내용을 작성할 때 반드시 RFC 2119 핵심어를 사용해야 하는 것은 아니다.
  • 핵심어를 사용하지 않은 문장도 문서의 구조와 문맥에 따라 규범적인 요구 사항이 될 수 있다.

예를 들어 MUST는 절대적인 요구 사항을 나타내지만, 일반 문장에 등장하는 must는 문서가 별도로 정의하지 않는 한 BCP 14의 규범적 핵심어로 해석되지 않는다.

RFC 8174 이후의 문서에서는 대체로 다음 의미의 선언을 문서 앞부분에 둔다.

이 문서에서 모두 대문자로 표기된 MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, OPTIONAL은 RFC 2119와 RFC 8174로 구성된 BCP 14에 따라 해석한다.

이 선언은 핵심어가 사용되는 문서의 해석 범위를 명시한다. 다만 RFC 8174는 이러한 선언이나 핵심어 자체가 규범적 문서를 작성하기 위한 필수 조건은 아니라고 설명한다.

BCP 14와의 관계

BCP는 Best Current Practice 문서를 식별하기 위한 안정적인 번호 체계이다. 하나의 BCP는 단일 RFC로 구성될 수도 있고, 동일한 절차나 지침을 다루는 여러 RFC의 집합으로 구성될 수도 있다. 포함되는 RFC는 BCP가 개정됨에 따라 변경될 수 있다.

flowchart LR
    B["BCP 14"]
    R1["RFC 2119<br/>핵심어의 의미 정의"]
    R2["RFC 8174<br/>대문자 표기 규칙 명확화"]

    B --> R1
    B --> R2
    R2 -. "갱신" .-> R1

RFC 2119는 각 핵심어의 요구 수준을 정의하고, RFC 8174는 그 정의가 모두 대문자로 작성된 핵심어에만 적용된다는 해석 규칙을 추가한다. 따라서 현대 IETF 문서에서 말하는 BCP 14의 규칙을 적용하려면 두 문서를 함께 고려해야 한다.

문서의 지위와 핵심어의 효력

RFC 2119는 핵심어의 효력이 해당 핵심어가 사용된 문서의 요구 수준이나 지위에 영향을 받는다고 설명한다. 따라서 문장에 MUST가 포함되어 있다는 사실만으로 해당 문서 자체가 Internet Standard가 되거나 Standards Track 문서로 분류되는 것은 아니다.

RFC 문서에는 Standards Track 문서 외에도 Best Current Practice, Informational, Experimental, Historic 등의 범주가 존재한다. 핵심어는 문서 내부의 요구 수준을 표현하지만, 문서의 공식적인 범주와 표준화 상태는 RFC 메타데이터와 관련 표준화 절차에 의해 별도로 결정된다.

사용 지침

상호운용성과 유해 동작

RFC 2119는 규범적 핵심어, 특히 절대적인 명령과 금지를 신중하고 제한적으로 사용하도록 요구한다. MUST나 MUST NOT은 다음과 같은 경우를 중심으로 사용된다.

  • 서로 독립적으로 개발된 구현 사이의 상호운용성을 확보해야 하는 경우
  • 보안 문제, 과도한 재전송 또는 자원 고갈과 같이 잠재적으로 유해한 동작을 제한해야 하는 경우
  • 여러 구현 방식 가운데 특정 방식만이 사양의 필수 조건을 충족하는 경우

반대로 상호운용성에 필요하지 않은 특정 내부 알고리즘, 데이터 구조 또는 구현 방법을 강제하기 위한 목적으로 MUST를 사용하는 것은 RFC 2119의 사용 지침에 부합하지 않는다.

보안 고려 사항

RFC 2119의 핵심어는 보안에 영향을 미치는 동작을 규정하는 데 자주 사용된다. 필수 요구 사항을 구현하지 않거나, 금지된 동작을 수행하거나, 권고 사항을 따르지 않을 때 발생하는 보안 영향은 명백하지 않을 수 있다.

RFC 2119는 문서 작성자가 요구 사항이나 권고 사항을 따르지 않았을 때의 보안상 결과를 설명해야 한다고 권고한다. 이는 구현자가 사양을 작성하는 과정에서 이루어진 논의와 경험을 모두 알고 있다고 가정할 수 없기 때문이다.

규범적 대상의 명확화

규범적 문장은 요구 사항을 이행해야 하는 대상을 식별할 수 있도록 작성하는 것이 일반적이다. 대상에는 프로토콜 구현, 서버, 클라이언트, 송신자, 수신자 또는 특정 데이터 처리 구성 요소 등이 포함될 수 있다.

다음 두 문장 가운데 두 번째 문장은 요구 사항의 적용 대상과 동작을 더 명확하게 표현한다.

잘못된 길이 값은 거부되어야 한다.

수신자는 잘못된 길이 값을 포함한 메시지를 MUST 거부한다.

이 예시는 특정 RFC의 실제 요구 사항이 아니라, 규범적 대상과 동작을 명시하는 문장 구조를 설명하기 위한 가상 예시이다.

가상 예시

다음 예시는 각 핵심어의 차이를 설명하기 위한 것으로 특정 프로토콜이나 표준의 실제 요구 사항이 아니다.

절대적인 요구 사항

서버는 요청 식별자를 모든 응답에 MUST 포함한다.

이 문장에서 요청 식별자의 포함은 사양을 준수하기 위한 필수 조건이다. 식별자를 포함하지 않는 서버는 해당 요구 사항을 충족하지 않는다.

조건부 권고 사항

클라이언트는 자원 제약이 없는 경우 연결을 SHOULD 재사용한다.

연결 재사용은 일반적으로 권고되지만, 메모리 제한이나 네트워크 환경과 같은 타당한 이유가 있는 구현은 다른 방식을 선택할 수 있다. 이 경우 구현자는 선택에 따른 영향을 검토해야 한다.

선택 기능

서버는 진단 정보를 제공하는 별도의 엔드포인트를 MAY 구현한다.

진단 엔드포인트의 구현 여부는 선택 사항이다. 해당 기능을 구현하지 않았다는 사실만으로 기본 프로토콜 요구 사항을 위반한 것은 아니다.

일반적인 오해

SHOULD는 단순한 선택 사항이다

SHOULD는 MAY와 동일하지 않다. MAY는 기능의 구현 여부가 본질적으로 선택적임을 나타내지만, SHOULD는 기본적으로 따라야 하는 권고를 나타낸다. SHOULD 요구 사항에서 벗어나려면 특정 상황에 적용되는 타당한 이유와 그에 따른 영향을 고려해야 한다.

MAY 기능은 다른 구현과 호환되지 않아도 된다

MAY는 기능 자체가 선택적이라는 뜻이지만, 선택 기능을 구현한 시스템과 구현하지 않은 시스템 사이의 기본적인 상호운용성까지 선택 사항이라는 뜻은 아니다. RFC 2119는 양쪽 구현이 선택 기능의 유무와 관계없이 상호운용할 준비가 되어 있어야 한다고 정의한다.

대문자로 쓴 모든 MUST가 자동으로 RFC 2119 용어가 된다

대문자 표기는 필요한 조건이지만, 문서가 BCP 14를 채택했는지와 해당 표현이 실제 규범적 문맥에서 사용되었는지도 함께 확인해야 한다. RFC 8174가 권고하는 선언문은 문서가 이러한 핵심어를 BCP 14의 의미로 사용한다는 사실을 명확히 하는 역할을 한다.

규범적인 문장에는 반드시 핵심어가 필요하다

RFC 8174는 규범적인 문장이 반드시 MUST, SHOULD, MAY 등의 핵심어를 포함해야 하는 것은 아니라고 명시한다. 핵심어는 의미의 명확성과 일관성을 제공하기 위한 수단이며, 문장의 규범성 전체를 결정하는 유일한 문법 장치는 아니다.

MUST는 가장 선호되는 구현 방법을 뜻한다

MUST는 선호도나 중요도를 강조하는 표현이 아니라 절대적인 준수 조건을 나타낸다. 상호운용성이나 유해 동작 제한에 필요하지 않은 구현 세부사항을 강제하는 목적으로 사용해서는 안 된다.

IETF 외부에서의 사용

RFC 2119의 핵심어 체계는 IETF 문서 외의 기술 사양에서도 참조된다. W3C의 적합성 시험 방법론은 W3C 사양에서 MUST, SHOULD, MAY 등의 RFC 2119 핵심어를 제품에 부과되는 요구 수준을 표시하는 데 사용한다고 설명한다.

다만 외부 사양은 자체적인 적합성 모델이나 표기 규칙을 추가로 정의할 수 있다. 따라서 특정 문서를 해석할 때에는 RFC 2119뿐 아니라 해당 문서가 선언한 규범적 용어의 적용 범위와 예외도 확인해야 한다.

역사

RFC 2119는 이전의 여러 RFC에서 사용되던 요구 수준 관련 정의를 종합하여 작성되었다. 원문은 Robert Ullmann, Thomas Narten, Neal McBurnett, Robert Elz 등을 포함한 여러 참여자의 제안이 반영되었다고 밝힌다.

RFC 2119가 발표되기 전인 1996년에는 RFC 2026이 인터넷 표준화 절차와 문서의 요구 수준을 설명하는 BCP 9로 발표되었다. RFC 2119는 이와 같은 표준화 환경에서 개별 사양의 요구 사항을 보다 일관되게 표현하기 위한 핵심어 정의를 제공했다.

RFC 2119 원문의 “흔히 대문자로 표기된다”라는 설명은 소문자 단어의 해석에 관한 모호성을 남겼다. RFC 8174는 2017년에 이 문제를 다루면서 특수한 의미가 모두 대문자로 표기된 경우에만 적용된다고 명시했다.

관련 개념

  • Request for Comments
  • Internet Engineering Task Force
  • Best Current Practice
  • Internet Standard
  • 규범적 요구 사항
  • 적합성
  • 상호운용성
  • RFC 8174
  • BCP 14

참고 자료

  • Bradner, Scott (1997), “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI: 10.17487/RFC2119, RFC Editor.
  • Leiba, Barry (2017), “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI: 10.17487/RFC8174, RFC Editor.
  • RFC Editor, “BCP 14 subseries contains 2 RFCs”.
  • Bradner, Scott (1996), “The Internet Standards Process — Revision 3”, BCP 9, RFC 2026, RFC Editor.
  • Internet Engineering Task Force, “About RFCs”.
  • World Wide Web Consortium, “A Method for Writing Testable Conformance Requirements”.