요약

  • RFC 8174는 선언된 관례에 따라 완전히 대문자로 쓰인 단어에만 BCP 14의 특별한 의미를 예약합니다. 소문자는 영어의 일반적 의미를 유지합니다.
  • 그렇다고 해서 타이포그래피가 규범성의 완전한 증거가 되는 것은 아닙니다. 규범적 텍스트는 이런 단어를 쓰지 않을 수도 있고, 용어의 강제력은 문서의 수준에도 의존합니다.
  • 신뢰할 수 있는 기록에는 문서의 버전과 상태, 관례, 완전한 문장, 행위 주체, 행위, 예외, 증거, 관찰된 결과가 필요합니다. 대문자를 세는 것만으로는 후보를 얻을 뿐입니다.

검색이 찾은 것은 완성된 규칙이 아니라 지표였다

RFC를 훑으며 모든MUST를 통제 목록 스프레드시트로 내보내는 도구를 상상하기는 쉽습니다. 보고서는 정확해 보입니다. 그러나 그것은 여전히 인용을 지시로, 논의를 명령으로, 초안을 발행된 결정으로 잘못 분류할 수 있습니다.

또한 문장의 주체, 행위를 활성화하는 조건, 그 범위를 제한하는 참조된 정의를 알지 못할 수 있습니다. 이런 데이터는 의무를 꾸며주는 것이 아니라 의무 자체를 구성합니다.

RFC 8174의 기여는 구체적인 모호성 하나를 제거하면서 자동화의 경계를 그려낸 것이었습니다. 토큰은 정밀하게 찾을 수 있습니다. 그러나 권한과 컴플라이언스에는 여전히 맥락이 필요합니다.

「종종 대문자로」라는 표현은 두 가지 문법을 남겨두었다

Scott Bradner의 RFC 2119는 IETF에 공통 어휘를 주었습니다.MUST는 사양의 절대적 요구이고,MUST NOT은 절대적 금지입니다.SHOULD는 결과를 이해한 후에만 타당한 이유로 벗어날 수 있게 허용합니다.MAY는 어떤 기능을 실제로 선택 사항으로 만들되, 서로 다른 갈래를 선택하는 구현체들 간의 상호운용성을 보호합니다.

원문은 이 단어들이 「종종」 대문자로 쓰인다고 말했습니다. 이 표현은 실무적 의문을 열어두었습니다. 소문자must는 스타일상 오탈자가 붙은 정의된 용어인가, 아니면 그냥 평범한 단어인가?

Leiba가 이 의문을 닫았습니다. BCP 14의 의미는 전형적으로 대문자인 형태에만 적용됩니다. 그 외의 형태는 영어의 일반적 의미를 유지합니다. 현재의 공식은 문서 자체가 이 관례를 선언하도록 요구합니다.

소문자가 문장을 비규범적으로 만들지는 않는다

이 정리에서 잘못된 규칙을 뽑아낼 수 있습니다. 대문자는 규범적이고 소문자는 아니다. RFC 8174는 그런 독법을 막습니다. 키워드를 사용하는 것이 의무는 아니며, 상당한 양의 규범적 텍스트가 이 단어들을 쓰지 않는다고 명시합니다.

따라서 독립적인 두 질문이 있습니다. 첫째는 어떤 단어가 BCP 14의 특별한 의미를 불러오는가입니다. 둘째는 그 문장이 규범적 권한을 갖는가, 그 범위는 무엇인가, 그 권한은 어디에서 오는가입니다.

두 질문에 같은 정규식으로 답하는 시스템은 평범한 산문으로 쓰인 의무를 놓치고, 예시나 인용으로부터 의무를 만들어냅니다. 거버넌스를 단순화하는 것이 아니라 그 오류를 숨기는 것입니다.

강제력은 문서에서 온다

RFC 2119 자체가 자기 용어의 강제력은 문서의 요구 수준에 따라 달라진다고 경고합니다. 큰 글자가 초안을 표준으로 만들거나, 정보성 RFC를 상호운용성 명령으로 만들거나, 사적 정책을 IETF 합의로 만들지는 않습니다.

저자는 단어를 통제합니다. 작업 그룹과 승인자는 절차와 상태를 통제합니다. RFC Editor는 수용된 의미를 보존합니다. 제조사는 코드에 어떻게 반영되는지 결정하고, 운영자와 검증기관은 행동을 관찰합니다.

BCP 14 관례는 이 주체들 사이의 영수증을 개선합니다. 어느 쪽도 대체하지 않습니다. 그래서 도입부 텍스트와 참고문헌이 용어의 눈에 보이는 형태만큼이나 중요합니다.

SHOULD에는 예외에 관한 결정이 담겨 있다

MUST,SHOULD,MAY를 강도 조절기의 세 단계로 다루면 설계가 빈약해집니다.MUST는 선택을 닫습니다.SHOULD는 타당한 이유와 결과 평가에 조건부로 열린 출구를 유지합니다.MAY는 환경이 용인해야 하는 선택을 엽니다.

현재 IETF 저자 지침은SHOULD를 특히 문제가 많은 것으로 지목합니다. 왜MUST를 쓰지 않는지, 벗어나면 무슨 일이 생기는지를 설명해야 합니다. 단순히 「선택 사항」이라고 표시하면 구현자가 결정에 필요한 부분을 없애버립니다.

성실한 매트릭스는 주체, 행위, 사전조건, 예외, 상호운용성 효과를 기록합니다. 대문자 단어는 진입점이지 행 전체가 아닙니다.

편집 매뉴얼이 다른 문법을 증명한다

RFC 7322는 RFC 2119의 용어를 사용하지 않는다고 선언합니다. 그런 다음 소문자must와should를 쓰고 지역 편집 의미를 정의합니다. RFC Editor가 자동으로 적용할 변경과 논의될 수 있는 권고를 구분하는 것입니다.

이것은 모순이 아닙니다. 그 선언은 독자가 소문자를 결함 있는 BCP 14로 해석하지 않게 합니다. 문서는 자기 지시를 지배하는 문법을 미리 알리는 것입니다.

또한 매뉴얼은 RFC 2119의 해석을 채택할 때 규범적 참고문헌으로 인용하도록 요구하고, 그렇지 않으면 올바른 해석을 정의해야 한다고 말합니다. 용어의 친숙함은 그 출처를 대신하지 못합니다.

구조적 마크업은 문장을 감싸지 의무를 감싸지 않는다

RFCXML에는 정의된 구문을 위한 선택적<bcp14>요소가 있습니다.MUST나SHOULD NOT을 강조하고 도구를 돕는 데 쓸 수 있습니다. 문서는 이것이 요구 전체를 감싸서는 안 된다고 안내합니다.

스키마의 경계는 시사적입니다. 마크업된 대상은 팀이 구현해야 하는 규칙보다 작습니다. 주체, 동사, 조건, 예외, 참조는 문장과 문서의 나머지 부분에 삽니다.

마크업은 후보를 찾기 위한 고품질 신호입니다. 그것을 그대로 실행 가능한 통제로 바꾸면 XML이 담고 있지 않은 결정을 XML에 부여하는 셈입니다.

타이포그래피는 어휘를 인증하지 명령을 인증하지 않는다

Barry Leiba는 대문자에 독립적인 권한을 부여하지 않았습니다. 독자가 어떤 단어가 BCP 14 정의를 쓰는지, 언제 평범한 영어로 말하는지 알 수 있도록 보장한 것입니다.

합의와 문서 상태가 권한을 제공합니다. 문장이 범위를 제공합니다. 코드와 검증이 컴플라이언스의 증거를 제공합니다. 이 어느 층도 글자의 모양만으로 완전히 추론할 수 없습니다.

신중한 자동화는 용어를 찾되 그 보관 사슬을 유지합니다. 누가 의무를 지는지, 어느 버전 기준인지, 어떤 예외가 있는지, 어떤 관찰을 통해 확인하는지를 물어야 합니다. 그 시점에 대문자는 자기 역할을 다한 것입니다.

출처