요약

  • 1982년 8월 RFC 822는 정식으로 발표되는 전자우편 확장 필드와 사용자가 정의하는 필드를 갈랐다. 앞의 이름은 X-로 시작할 수 없게 하여 뒤의 이름 공간을 보호했다.
  • 보호 장치는 나중에 별칭 관리 비용을 낳았다. 1997년 1월 RFC 2068은 호환성을 위해 HTTP에서 x-gzip/x-compress를 gzip/compress와 동등하게 다루라고 했다. 2007년 12월 RFC 5064는 Archived-At을 표준화하면서 옛 이름 X-Archived-At도 기술하고 등록했다.
  • 2012년 6월 RFC 6648은 새 응용 프로토콜의 문자형 매개변수에 X-를 붙이는 관행을 폐기했다. 프로그램은 이름의 접두사만 보고 표준 여부나 안전성을 판단해서는 안 되며, 등록부가 그 상태를 기록해야 한다.

시험작을 위한 별도 서랍

메시지 필드에는 이름과 값이 있다. 받는 프로그램은 이름을 보고 값을 해석할 방법을 고른다. 서로 다른 집단이 다른 뜻에 같은 이름을 붙이면 메시지가 경계를 넘을 때 충돌한다. 지역 시험작에 별도의 이름 공간을 주는 방안은 그래서 매력적이었다. 위원회의 허가를 받기 전에도 기능을 시험할 수 있고, 훗날 공식 확장에 쓸 이름도 남겨둘 수 있다.

1982년 8월 발표된 RFC 822는 이 구획을 전자우편에 명시했다. 정식 문서로 정의될 확장 필드의 이름은 절대 X-로 시작하지 않는다. 사용자 정의 필드는 보호된 영역을 얻게 된다. 조직은 전 세계의 공통 규칙을 먼저 만들지 않고도 자기 메시지에 필요한 정보를 담을 수 있었다.

문제는 사람에게는 상태 표시인 그 글자가 프로그램에는 정확한 식별자의 일부라는 데 있다. X-Example을 읽도록 만든 코드는 나중에 Example이 공식 이름이 됐다는 소식을 듣고 저절로 새 글자를 이해하지 않는다. 기관의 판단은 문서에서 바꿀 수 있지만, 이미 보낸 메시지와 실행 중인 프로그램의 문자열은 그대로 남는다.

사용자가 없는 시험작이라면 개명이 쉽다. 성공한 시험작은 다르다. 발신자가 쓰고, 수신자가 읽고, 보관소가 저장한 옛 이름은 지워 버리기 어렵다. 정식 이름을 발표해도 새 이름만 추가되고 임시 서랍은 비워지지 않을 수 있다.

HTTP가 두 이름의 값을 먼저 치렀다

1997년 1월 RFC 2068에 비용이 짧고 선명하게 남아 있다. 이전 HTTP 구현과 호환하려면 응용 프로그램이 x-gzip을 gzip과, x-compress를 compress와 동등하게 봐야 한다는 지시다. 표준 작성자는 깔끔한 새 이름 하나를 골라 옛 이름을 잊을 수 없었다. 이전 프로그램이 그 표기를 이미 사용하고 있었기 때문이다.

이것은 문장 취향의 문제가 아니다. 보내는 쪽이 한 이름으로 콘텐츠 부호화를 알리고 받는 쪽이 다른 이름만 알면 본문을 잘못 처리할 수 있다. 응답을 전달하거나 저장하는 중간 시스템도 둘의 관계를 알아야 한다. 실험 표시는 결국 표준이 가르쳐야 할 입력 규칙이 됐다.

전자우편에서도 분류 규칙 자체가 바뀌었다. 2001년 4월 RFC 2822는 RFC 822를 대체하고 선택 필드를 설명하면서 과거의 정식 확장과 사용자 필드 구문 구분을 이어받지 않았다. 새 규격에서 경계를 지우는 일과 이전 메일에 적힌 이름을 지우는 일은 별개다. 과거 메시지를 읽는 프로그램도 계속 돌아간다.

2007년 12월 RFC 5064는 그 잔여물을 구체적으로 보여준다. 보관된 메일 사본의 URI를 나타내는 Archived-At을 정하면서, 호환성을 위해 선행 이름 X-Archived-At도 설명했다. 이전 필드는 읽어도 되지만 새 메시지를 만들 때는 생성하지 말라고 권했다. 오래된 이름은 폐기된 상태로 새 이름 옆에 등록됐다. 정식 채택은 옛 이름을 읽을 책임까지 없애지는 못했다.

두 사례의 규칙은 다르다. HTTP는 특정 부호화 이름 두 쌍에 동등성을 명시했다. 메일은 옛 입력을 허용하며 새 출력을 권했다. 어느 문서도 당시 전체 프로그램 중 몇 개가 각 표기를 썼는지 세지 않았다. 그 규모를 알려면 날짜가 적힌 구현 자료나 메시지 표본이 필요하다. 그러나 두 이름 사이의 다리를 유지해야 한다는 사실은 원문에 적혀 있다.

이름표가 신분증 자리에서 내려오다

2012년 6월 IETF Best Current Practice로 나온 RFC 6648은 이 과정을 일반화했다. 비표준 이름이 널리 퍼진 뒤 다른 공식 이름을 만들면 옛 구현은 접두사 형태만, 새 구현은 공식 형태만 알 수 있다. 서로 연결되려면 새 프로그램이 옛 이름을 오래 받아들여야 한다. 실험용으로 나눈 공간이 사실상의 표준 공간으로 변한다.

문서는 새 응용 프로토콜의 문자형 매개변수에 X-를 붙이지 말라고 권했다. 기존 필드를 한꺼번에 지우라는 명령은 아니다. 옛 이름의 유지와 이전은 각각의 관리자에게 맡겼다. 사적인 실험도 금지하지 않았고 특정 프로토콜에 이미 있는 규칙도 자동으로 무효화하지 않았다. 버린 것은 현재의 제도적 상태를 네트워크 이름에 새기는 습관이다.

받는 프로그램에는 더 중요한 금지선이 있다. X-가 있고 없는 것만으로 표준 여부를 추정해서는 안 된다. 접두사가 없는 이름을 안전하다고, 붙은 이름을 위험하다고 외양만으로 판단해서도 안 된다. 이름은 값을 식별하는 열쇠이지, 등록증이나 보안 심사 결과가 아니다.

대신 프로토콜 설계자는 충분히 넓고 등록이 쉬운 이름 등록부를 마련해야 한다. 필요하면 잠정 등록과 영구 등록을 둘 수 있다. 접두사가 붙은 기존 이름의 등록을 금할 이유도 없다. 이름의 상태는 철자에서 추측하는 것이 아니라 등록 내용에서 확인해야 한다. 아이디어가 성숙해지면 등록 내용을 바꾸되, 모든 프로그램이 두 번째 이름을 배워야 할 필요는 줄어든다.

무턱대고 앞의 두 글자를 떼는 것도 위험하다. 정식 심사를 거치며 시험판과 새 판의 의미나 보안 성질이 달라질 수 있다. RFC 2068이 준 x-gzip의 동등성은 그 부호화에 대한 구체적인 규칙이다. 모든 X- 필드를 자동으로 바꿔도 된다는 일반 명령이 아니다. 각각의 새 이름과 옛 이름은 실제 뜻을 비교해야 한다.

성공한 실험일수록 옛 이름이 오래 산다

1982년의 구획은 시험할 자유를 줬다. 2012년의 수정은 성공한 뒤의 질서를 인정했다. 프로그램은 그 이름을 읽고, 보관소는 그 이름을 저장하고, 다른 시스템은 그 동작을 기대한다. 표준 기구가 새 이름을 발표할 무렵 옛 이름에는 이미 사용자가 있다.

원자료에는 비용이 기록돼 있다. 1997년 HTTP 표준은 두 부호화 이름을 연결했다. 2007년 메일 표준은 폐기된 선행 이름을 후계 이름 옆에 등록했다. 특정 시기에 각 이름을 실제로 쓴 제품의 수는 구현 기록을 봐야 한다. 이름을 공식화하는 권한과 이미 쓰는 이름을 곧바로 지우는 능력이 다른 곳에 있다는 점은 충분히 드러난다. 등록부는 기관이 고친다. 실행 중인 코드와 보관된 메시지는 읽기의 비용을 결정한다.

RFC 6648은 오래된 서랍을 비우지 않았다. 새 실험에 똑같은 서랍을 만들지 말라고 요청했다. 실험의 지위는 고칠 수 있는 등록 기록에 두고, 네트워크에 실린 이름은 성숙한 뒤에도 안정적으로 유지하자는 결정이었다.