요약

  • RFC 2234는 인터넷 명세들이 표기법 정의의 사본을 함께 실어 다니던 시기 이후 ABNF에 독립된 문서를 부여했습니다.
  • 공통 문법 언어는 규칙을 참조하고 조합하기 쉽게 만들었지만, 구현이 모든 프로토콜을 동일하게 해석한다는 것을 증명하지는 못했습니다.

오랫동안 하나의 명세는 프로토콜 메시지 구문을 서술하면서 그 구문을 작성하는 데 쓰인 표기법까지 설명했습니다. 이 중복은 이해할 수 있는 것이었습니다. RFC 2234가 나중에 회고하듯 초기 ARPANET에서는 개별 명세가 각자의 ABNF 정의를 함께 실었기 때문입니다. RFC 733과 RFC 822 같은 이메일 명세가 공통 참조 지점이 되었습니다. 그러나 하나의 프로토콜 문서 안에 박혀 있는 설명은 범용 문법 언어를 찾기에 불편한 장소였습니다.

1997년 11월에 발표된 RFC 2234는 그 정의를 분리해 다른 명세가 필요한 부분만 선택적으로 인용할 수 있게 했습니다. 이 변화는 "인터넷이 하나의 파서를 채택했다"는 것이 아니었습니다. 더 좁고 더 유용한 것이었습니다. 표준 저자가 규칙 이름, 단말 기호, 반복, 선택(alternatives), 수치 범위, 그룹화에 관한 공유된 설명을 독자에게 안내하도록 하여, 조용히 지역 변형을 재생산하는 대신 참조하게 만든 것입니다. 그 구문은 여전히 수용되는 문자열을 서술하는 언어였지, 배치된 구현에 관한 실행 가능한 증거는 아니었습니다.

그 가치는 서로 구분해 둔 경계에서 가장 쉽게 드러납니다. ABNF는 구문을 서술합니다. 프로토콜 문서는 어떤 ABNF 규칙이 자신의 메시지를 정의하는지 결정합니다. 전송 환경은 단말 값이 어떻게 인코딩되는지 결정합니다. 파서는 그 선택을 구현합니다. RFC 2234는 하나의 문법이 서로 다른 외부 인코딩으로 사용될 수 있으며 그 인코딩은 ABNF의 범위 밖에 둔다고 명시합니다. 그래서 이 표기법은 하나의 프로토콜보다 더 멀리 갈 수 있었지만, 그것 자체만으로 연결상의 바이트를 둘러싼 모든 논쟁을 종결할 수는 없었습니다.

이 문법은 조각으로 조립할 수도 있었습니다.=/연산자는 다른 곳에서 이미 정의된 규칙에 선택지를 추가합니다. RFC 2234는 이것이 공통 부모 규칙 집합에서 파생하는, 그 외에는 독립적인 명세들에 도움이 될 수 있다고 말합니다. 이는 파서가 실행 시점에 확장을 찾아내도록 지시하는 것이 아니라 문서 조합을 위한 편의 장치입니다. 프로토콜 저자는 여전히 어떤 문서들이 그 규칙을 구성하는지 밝혀야 하고, 독자는 그 범위를 이해해야 합니다.

이것은 소박한 형태의 인터넷 조율입니다. 규칙을 작성할 때 쓰는 어휘를 표준화하고, 프로토콜 고유의 규칙은 별도로 두며, 인코딩 선택은 보이는 곳에 두는 것입니다. RFC 2234는 불일치에 이름을 붙였다고 해서 불일치를 지우지 않았습니다. 불일치의 한 층위를 가리키기 쉽게 만들었을 뿐입니다. 그 계보—RFC 4234와 이어지는 RFC 5234—는 공유된 언어가 시대를 초월한 것이 아니라 계속 개정될 수 있음을 보여 줍니다. RFC 7405는 나중에 UTF-8 관련 구문을 다루었고, 이 후속 개정을 1997년 문서에 소급해서 투영해서는 안 됩니다.

따라서 ABNF의 역사는 산문이 수학으로 대체되었다는 이야기가 아닙니다. 프로토콜 산문은 여전히 목적과 맥락을 제공하며, 문법은 형식에 관한 하나의 압축된 서술을 줍니다. 유용한 조치는 문법 자체의 정의가, 그 문법이 표현에 도움을 주는 모든 프로토콜 내부가 아닌 다른 곳에 살도록 한 것입니다. 이로써 재사용은 인용 가능해졌고, 구현에 관한 주장은 그것이 속한 곳, 즉 구현 증거 자리에 남았습니다.

출처:RFC 2234;RFC 2234 Datatracker 기록;RFC 2234 Datatracker 이력;RFC 2234 RFC Editor 기록;RFC 733;RFC 822;RFC 4234;RFC 4234 RFC Editor 기록;RFC 5234;RFC 5234 RFC Editor 기록;RFC 7405;RFC 2119;IETF running-code 에세이;최소 명세 에세이;현실 층위 에세이.