요약

  • 1994년 3월의 RFC 1590은 메일에 한정된 ‘MIME 유형’이라는 말에서 여러 응용 프로그램이 공유할 ‘미디어 유형’으로 범위를 넓혔다. 제안은 공개 ietf-types 목록에서 의견을 받고, 2주 뒤 IANA 등록과 OID 배정을 요청할 수 있었다.
  • 공통 등록부에는 폭넓게 이름을 올리되, 메일 프로그램처럼 상대의 기능을 알 수 없는 환경은 별도의 적용 지침으로 널리 구현된 소수의 형식을 권할 수 있었다. 이름을 공유하는 일과 실제로 여는 일의 담당자가 갈렸다.

새 형식은 서류를 들고 줄을 섰다

사진 한 장, 음성 파일 한 개, 특정 프로그램의 문서 한 건이 창구 앞에 선다. 메일 프로그램과 자료 보관소가 각각 다른 이름을 붙이면 같은 물건이 여러 이름으로 불린다. 반대로 서로 다른 물건이 우연히 같은 이름을 차지할 수도 있다. 그렇다고 오래된 메일 프로그램이 이해하는 몇 종류만 세상에 존재한다고 처리하면 새 형식은 계속 지역 별칭을 만든다. Jon Postel의 RFC 1590은 공통 명부를 만들고, 각 프로그램의 선택은 따로 남겨 두었다.

앞선 RFC 1521의 MIME 체계는 메일 본문이 어떤 데이터인지 알리는 방법을 마련했다. 당시 비동기식 전자우편에서는 발신자가 수신자의 소프트웨어 기능을 미리 알기 어려웠다. 널리 쓰이는 형식 몇 가지에 집중하면 읽힐 가능성이 높았다. 그러나 같은 이름이 메일 밖에서도 필요해지자, 메일의 조심스러운 채택 기준을 모든 이름의 등록 장벽으로 만들 이유가 줄었다. RFC 1590은 이때부터 이름을 ‘미디어 유형’이라고 불렀다.

첫 단계는 공개 토론이다. 제안자는 유형과 하위 유형을 ietf-types 메일링리스트에 올린다. 등록 전 하위 유형에는 x- 표기를 쓴다. 다른 사람들은 이름이 헷갈리지 않는지, 참조한 버전이나 프로필이 정확한지, 관련 OID와 알려진 보안 문제는 무엇인지 물을 수 있다. 특정 용도에만 맞는 형식이라면 그 범위를 신청서에 밝힌다. 소프트웨어가 각자 임의의 이름을 굳혀 버리기 전에 충돌을 드러내는 장소였다.

2주가 지나면 제안자는 IANA에 유형과 자료를 제출한다. RFC는 합리적인 검토 기간을 거친 뒤 IANA가 등록하고, 자체 계열의 OID를 부여하며, 결과를 공개하는 절차를 적었다. 부록의 서식에는 유형과 하위 유형, 필수·선택 매개변수, 인코딩 고려 사항, 알려진 위험, 명세와 연락 담당자를 채우는 칸이 있다. 작은 서류처럼 보여도, 여러 응용 프로그램이 같은 데이터를 다른 이름으로 부를 때 생기는 혼란보다 값이 싸다.

모든 데이터 형식에 완벽하게 공개된 사양이 있던 것은 아니다. RFC 1590은 그런 경우 특정 소프트웨어 패키지와 버전을 명시해 데이터 스트림을 식별하는 길을 열었다. 예를 들어 어느 프로그램의 어느 판이 만든 문서인지 적는 방식이다. 공통 이름이 생겼어도 그것을 해석할 코드는 독자의 프로그램 안에 있어야 한다. 등록부는 형식의 정체를 함께 가리키고, 프로그램은 그 형식을 실제로 처리한다.

더 큰 분류를 새로 만들 때는 절차가 무거웠다. 새로운 최상위 유형은 RFC 또는 RFC가 될 수준의 문서와 표준화 절차를 요구했다. 기존 유형 아래 하위 유형을 더하는 일은 가벼운 행정 경로를 썼다. 또한 메일 환경에서 권할 형식의 목록은 해당 환경에 맞는 적용 지침이 정하도록 했다. 공통 서랍은 넓게 두고, 각 프로그램은 자신의 책상 위에 필요한 도구만 올려놓는 셈이다.

이 설계의 중심은 권한의 크기다. IANA는 모두가 참고할 이름을 기록한다. 형식을 제안한 사람은 무엇을 가리키는지 명확히 적는다. 프로그램 제작자는 그 바이트를 열 방법을 구현한다. RFC 1590의 2주 대기줄은 평범한 행정 절차였지만, 인터넷의 여러 응용 프로그램이 서로 같은 단어를 쓰게 하는 실용적인 장치였다.