인터넷 엔지니어링 태스크 포스 (IETF) N. Freed
의견 요청서: 6838 Oracle
BCP: 13 J. Klensin
폐기: 4288
범주: 모범 현행 관행 T. Hansen
ISSN: 2070-1721 AT&T Laboratories
2013년 1월
미디어 타입 명세 및 등록 절차
초록
이 문서는 HTTP, MIME 및 기타 인터넷 프로토콜에서 사용하기 위한
미디어 타입의 명세와 등록 절차를 정의한다.
이 메모의 상태
이 메모는 인터넷 모범 현행 관행을 문서화한다.
이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산물이다.
이는 IETF 공동체의 합의를 나타낸다. 이 문서는 공개 검토를
거쳤으며 인터넷 엔지니어링 운영 그룹(IESG)에 의해 출판 승인을
받았다. BCP에 관한 추가 정보는 RFC 5741 제 2절에서
확인할 수 있다.
이 문서의 현재 상태, 정오표, 그리고 이에 대한 피드백 제공 방법에
관한 정보는 다음에서 얻을 수 있다.
http://www.rfc-editor.org/info/rfc6838.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Freed 등 모범 현행 관행 [1페이지]
RFC 6838 미디어 타입 등록 2013년 1월
목차
1. 서론 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 역사적 참고 사항 . . . . . . . . . . . . . . . . . . . . 3
1.2. 이 문서에서 사용하는 규약 . . . . . . . . . . . . . . . 4
2. 미디어 타입 등록 예비 사항 . . . . . . . . . . . . . . . . 4
3. 등록 트리와 하위 타입 이름 . . . . . . . . . . . . . . . . 4
3.1. 표준 트리 . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. 벤더 트리 . . . . . . . . . . . . . . . . . . . . . . 6
3.3. 개인 또는 배니티 트리 . . . . . . . . . . . . . . . . 6
3.4. 미등록 x. 트리 . . . . . . . . . . . . . . . . . . . . 7
3.5. 추가 등록 트리 . . . . . . . . . . . . . . . . . . . . 7
4. 등록 요구 사항 . . . . . . . . . . . . . . . . . . . . . . 7
4.1. 기능성 요구 사항 . . . . . . . . . . . . . . . . . . . 8
4.2. 명명 요구 사항 . . . . . . . . . . . . . . . . . . . . 8
4.2.1. 텍스트 미디어 타입 . . . . . . . . . . . . . . . . . 9
4.2.2. 이미지 미디어 타입 . . . . . . . . . . . . . . . . 10
4.2.3. 오디오 미디어 타입 . . . . . . . . . . . . . . . . 10
4.2.4. 비디오 미디어 타입 . . . . . . . . . . . . . . . . 10
4.2.5. 애플리케이션 미디어 타입 . . . . . . . . . . . . . 11
4.2.6. 멀티파트 및 메시지 미디어 타입 . . . . . . . . . 11
4.2.7. 추가 최상위 타입 . . . . . . . . . . . . . . . . . 12
4.2.8. 구조화 문법 이름 접미사 . . . . . . . . . . . . . 12
4.2.9. 폐기된 별칭 . . . . . . . . . . . . . . . . . . . . 13
4.3. 매개변수 요구 사항 . . . . . . . . . . . . . . . . . . 13
4.4. 정규화 및 형식 요구 사항 . . . . . . . . . . . . . . . 14
4.5. 교환 권고 사항 . . . . . . . . . . . . . . . . . . . . 15
4.6. 보안 요구 사항 . . . . . . . . . . . . . . . . . . . . 15
4.7. XML 미디어 타입에 특화된 요구 사항 . . . . . . . . . 16
4.8. 인코딩 요구 사항 . . . . . . . . . . . . . . . . . . . 16
4.9. 사용 및 구현 비요구 사항 . . . . . . . . . . . . . . 17
4.10. 출판 요구 사항 . . . . . . . . . . . . . . . . . . . . 18
4.11. 프래그먼트 식별자 요구 사항 . . . . . . . . . . . . . 18
4.12. 추가 정보 . . . . . . . . . . . . . . . . . . . . . . 19
5. 미디어 타입 등록 절차 . . . . . . . . . . . . . . . . . . 19
5.1. 예비 공동체 검토 . . . . . . . . . . . . . . . . . . . 19
5.2. IANA에 요청 제출 . . . . . . . . . . . . . . . . . . . 20
5.2.1. 임시 등록 . . . . . . . . . . . . . . . . . . . . 20
5.3. 검토 및 승인 . . . . . . . . . . . . . . . . . . . . 21
5.4. 미디어 타입 등록에 대한 의견 . . . . . . . . . . . . 21
5.5. 변경 절차 . . . . . . . . . . . . . . . . . . . . . . 21
5.6. 등록 템플릿 . . . . . . . . . . . . . . . . . . . . . 22
6. 구조화 문법 접미사 등록 절차 . . . . . . . . . . . . . . 23
6.1. 변경 절차 . . . . . . . . . . . . . . . . . . . . . . 24
6.2. 구조화 문법 접미사 등록 템플릿 . . . . . . . . . . . 24
7. 보안 고려 사항 . . . . . . . . . . . . . . . . . . . . . 25
8. IANA 고려 사항 . . . . . . . . . . . . . . . . . . . . . 26
9. 감사의 말 . . . . . . . . . . . . . . . . . . . . . . . 27
Freed 등 모범 현행 관행 [2페이지]
RFC 6838 미디어 타입 등록 2013년 1월
10. 참고 문헌 . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. 규범적 참고 문헌 . . . . . . . . . . . . . . . . . . . 27
10.2. 정보성 참고 문헌 . . . . . . . . . . . . . . . . . . . 28
부록 A. 기득권 미디어 타입 . . . . . . . . . . . . . . . . . 30
부록 B. RFC 4288 이후의 변경 사항 . . . . . . . . . . . . . 30
1. 서론
최근 인터넷 프로토콜은 특정 영역에서 쉽게 확장될 수 있도록
신중하게 설계되어 왔다. 특히 HTTP [RFC2616] 및 MIME
[RFC2045]을 포함하되 이에 한정되지 않는 많은 프로토콜은
임의의 레이블이 붙은 콘텐츠를 운반할 수 있다.
그러한 콘텐츠에 레이블을 붙이는 데 사용되는 메커니즘은 미디어
타입이며, 이는 최상위 타입과 하위 타입으로 구성되고 다시 트리로
구조화된다. 선택적으로, 미디어 타입은 매개변수라고 알려진
부속 데이터를 정의할 수 있다.
이러한 레이블에는 등록 절차가 필요하다. 그래야 그러한 값의 집합이
합리적으로 질서 있고, 잘 명세되어 있으며, 공개적인 방식으로
정의된다.
이 문서는 미디어 타입 등록 기준을 명세하고, 인터넷 할당 번호
기관(IANA) 중앙 레지스트리에 미디어 타입(제5절)과 미디어 타입
구조화 접미사(제6절)를 등록하는 데 사용할 절차를 정의한다.
이러한 절차로 관리되는 미디어 타입 레지스트리의 위치는 다음과
같다.
http://www.iana.org/assignments/media-types/
1.1. 역사적 참고 사항
미디어 타입 등록 절차는 처음에는 비동기 인터넷 메일 환경의
맥락에서 사용할 미디어 타입을 등록하기 위해 정의되었다. 이 메일
환경에서는 원격 메일 시스템의 기능을 알 수 없을 때 상호운용성
가능성을 높이기 위해, 가능한 미디어 타입의 수를 제한할 필요가
있다. 미디어 타입이 새로운 환경에서 사용되고, 그러한 환경에서는
미디어 타입의 확산이 상호운용성에 방해가 되지 않게 되면서, 원래
절차는 지나치게 제한적임이 드러났고 일반화되어야 했다. 이는
처음에 [RFC2048]에서 이루어졌지만, 거기서 정의된 절차는
여전히 MIME 문서 집합의 일부였다. 이제 미디어 타입 명세 및 등록
절차는 MIME과 독립적임을 명확히 하기 위해 별도 문서가 되었다.
Freed 등 모범 현행 관행 [3페이지]
RFC 6838 미디어 타입 등록 2013년 1월
미디어 타입의 사용을 특정 환경으로 제한하거나 다른 환경에서의
사용을 금지하는 것이 바람직할 수 있다. 이 명세는 그러한 제한을
체계적인 방식으로 미디어 타입 등록에 통합한다. 추가 논의는
제4.9절을 참조한다.
1.2. 이 문서에서 사용하는 규약
이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"이라는
핵심 단어가 모두 대문자로 나타날 때에는 [RFC2119]에 설명된
대로 해석해야 한다. 이 단어들은 규범적 의미 없이 평범한 영어
단어로서 소문자나 혼합 대소문자로 나타날 수도 있다.
이 명세는 해당 문서의 부록 B에 정의된 핵심 규칙을 포함하여
확장 Backus-Naur 형식(ABNF) [RFC5234] 표기법을 사용한다.
2. 미디어 타입 등록 예비 사항
새로운 미디어 타입 하나 또는 여러 개의 등록은 등록 제안서 작성에서
시작된다. 아래에서 논의하는 것처럼 요구 사항이 서로 다른 여러
등록 트리 내에서 등록이 이루어질 수 있다. 일반적으로, 새로운
등록 제안서는 관련 트리에 적절한 방식으로 회람되고 검토된다.
제안서가 수용 가능하면 미디어 타입이 등록된다. 다음 절들은 서로
다른 각 등록 트리에 사용되는 요구 사항과 절차를 설명한다.
3. 등록 트리와 하위 타입 이름
등록 절차의 효율성과 유연성을 높이기 위해, 하위 타입 이름의 서로
다른 구조를 등록할 수 있다. 이는 예를 들어 인터넷 공동체에서 널리
지원하고 구현하도록 권장될 하위 타입이나, 독점 소프트웨어와
관련된 파일을 이동하는 데 사용되는 하위 타입과 같은 서로 다른
자연스러운 요구 사항을 수용하기 위한 것이다. 다음 하위 절들은
패싯 이름 사용으로 구별되는 등록 "트리"를 정의한다. 예를 들어
하위 타입 이름이 "tree." 접두사로 시작하는 경우가 있다. 이 문서
이전에 정의된 일부 미디어 타입은 아래에 설명된 명명 규약을 따르지
않는다는 점에 유의한다. 이에 관한 논의는 부록 A를 참조한다.
3.1. 표준 트리
표준 트리는 인터넷 공동체에 일반적 관심이 있는 타입을 위한 것이다.
표준 트리의 등록은 다음 중 하나여야 한다.
Freed 등 모범 현행 관행 [4페이지]
RFC 6838 미디어 타입 등록 2013년 1월
1. IETF 명세와 관련된 등록의 경우 IESG가 직접 승인한 것이거나,
2. 인정된 표준 관련 조직이 "Specification Required" IANA 등록
정책 [RFC5226]을 사용하여 등록한 것
(이는 전문가 검토를 함의한다).
첫 번째 절차는 IETF 합의 문서로부터의 등록에 사용되거나, 기득권
등록(부록 A 참조) 및/또는 그 밖에 불완전한 등록을 등록하는
것이 인터넷 공동체의 이익이 되는 드문 경우에 사용된다. 등록
제안서는 RFC로 출판되어야 한다. 등록 RFC가 IETF 스트림에 있는
경우, IETF 합의를 가져야 하며, 이는 표준 트랙, BCP, 정보성 또는
실험적 상태로 달성될 수 있다. 비-IETF RFC 스트림에 출판된 등록도
허용되며 IESG 승인을 필요로 한다. 등록은 독립적인 "등록 전용" RFC
형태일 수도 있고, 어떤 종류의 더 일반적인 명세에 통합될 수도 있다.
두 번째 경우, IESG는 등록 제출자가 인정된 표준 관련 조직을
대표하는지에 대해 일회성 결정을 내린다. 그 이후에는 미디어 타입
검토자(지정 전문가 또는 지정 전문가 그룹)가 이 문서에 명세된 대로
전문가 검토를 수행한다. 같은 출처로부터의 후속 제출에는 IESG가
관여하지 않는다. 형식은 제출하는 표준 관련 조직이 작성한 공식
표준 명세로 설명되어야 한다.
표준 트리의 미디어 타입은 부록 A에 설명된 절차를 사용하여
기득권으로 편입되지 않는 한 패싯 이름을 가져서는 안 된다.
표준 트리에 등록된 미디어 타입의 "소유자"는 표준 관련 조직
자체라고 가정한다. 명세의 수정 또는 변경은 최초 등록에 요구된
것과 같은 수준의 절차를 사용한다(예: 표준 트랙으로 제출된 등록은
또 다른 표준 트랙 RFC에서 개정될 수 있지만, 정보성 RFC에서
개정될 수는 없다).
인정된 표준 관련 조직의 표준 트리 등록은 IANA에 직접 제출되며,
승인 전에 전문가 검토 [RFC5226]를 거친다. 이 경우 전문가
검토자는 무엇보다도 요구되는 명세가 충분한 문서를 제공하는지
확인한다.
Freed 등 모범 현행 관행 [5페이지]
RFC 6838 미디어 타입 등록 2013년 1월
3.2. 벤더 트리
벤더 트리는 공개적으로 이용 가능한 제품과 관련된 미디어 타입에
사용된다. 이 맥락에서 "벤더"와 "제작자"는 매우 넓게 해석되며
동등한 것으로 간주된다. 업계 컨소시엄뿐만 아니라 인정된 표준 관련
조직에 해당하지 않는 비상업적 단체도 벤더 트리에 미디어 타입을
등록하는 것이 매우 적절할 수 있다는 점에 유의한다.
어떤 제품 또는 제품 집합과 관련된 파일을 교환해야 하는 사람은
누구나 벤더 트리에 등록할 수 있다. 그러나 해당 등록은 원칙적으로
등록되는 타입을 사용하는 소프트웨어를 제작하는 벤더 또는 조직에
속하며, 그 벤더 또는 조직은 제3자가 수행한 등록을 수정하거나
갱신하기 위해 언제든지 소유권을 주장할 수 있다. 추가 정보는
제5.5절을 참조한다.
제3자가 다른 사람을 대신하여 타입을 등록할 때에는 두 주체 모두가
등록의 변경 관리자(Change Controller) 필드에 기재되는 것이 좋다.
이에 대한 한 가지 가능한 형식은 "Foo, on behalf of Bar"가 될 수
있다.
벤더 트리 등록은 선행 패싯 "vnd."로 구별된다. 그 뒤에는 등록자의
재량에 따라 잘 알려진 제작자의 미디어 하위 타입 이름(예:
"vnd.mudpie")이나, IANA가 승인한 제작자 이름 지정 뒤에 미디어 타입
또는 제품 지정이 이어지는 형태(예: vnd.bigcompany.funnypictures)가
올 수 있다.
벤더 트리에 등록될 미디어 타입에 대한 공개 노출과 검토가 필수는
아니지만, 그러한 명세의 품질을 높이기 위해 검토에
media-types@iana.org 메일링 리스트를 사용하는 것이 권장된다. 벤더
트리의 등록은 IANA에 직접 제출될 수 있으며, 승인 전에 전문가 검토
[RFC5226]를 거친다.
3.3. 개인 또는 배니티 트리
실험적으로 만들어졌거나 상업적으로 배포되지 않는 제품의 일부로
만들어진 미디어 타입에 대한 등록은 개인 또는 배니티 트리에 등록될
수 있다. 등록은 선행 패싯 "prs."로 구별된다.
"개인" 등록과 관련 명세의 소유자는 등록을 수행하는 사람 또는
단체이거나, 아래 설명된 바와 같이 책임이 이전된 사람 또는 단체다.
Freed 등 모범 현행 관행 [6페이지]
RFC 6838 미디어 타입 등록 2013년 1월
개인 트리에 등록될 미디어 타입에 대한 공개 노출과 검토가 필수는
아니지만, 그러한 명세의 품질을 높이기 위해 검토에
media-types@iana.org 메일링 리스트(제5.1절 참조)를 사용하는 것이
권장된다. 개인 트리의 등록은 IANA에 직접 제출될 수 있으며, 승인
전에 전문가 검토 [RFC5226]를 거친다.
3.4. 미등록 x. 트리
첫 번째 패싯으로 "x."를 갖는 하위 타입 이름은 사적이고 로컬인
환경에서만 전적으로 사용되도록 의도된 타입에 사용할 수 있다. 이
트리의 타입은 등록될 수 없으며, 이를 교환하는 당사자들의 적극적
합의가 있을 때에만 사용되도록 의도된다.
그러나 위에서 설명한 벤더 및 개인 트리에 대한 단순화된 등록
절차로 인해, 미등록 타입을 사용할 필요는 드물어야 하며, 있다
하더라도 매우 드물어야 한다. 따라서 "x." 트리의 타입 사용은 강하게
권장되지 않는다.
"x-"로 시작하는 이름을 가진 타입은 더 이상 이 트리의 구성원으로
간주되지 않는다는 점에 유의한다([RFC6648] 참조). 또한 일반적으로
유용하고 널리 배포된 타입이 잘못하여 "x-" 이름 접두사를 갖게 된
경우, 부록 A에 정의된 절차를 따르면 현재 이름을 사용하여 대체
트리에 등록될 수 있음에 유의한다.
3.5. 추가 등록 트리
때때로 공동체의 필요에 따라, IETF 표준 조치에 의해 새로운 최상위
등록 트리가 만들어질 수 있다. 이러한 트리는 잘 알려진 영속적인
조직이 외부적으로 등록하고 관리할 수 있도록 만들어질 수 있다고
명시적으로 가정된다. 예를 들어 과학 학회는 자신들이 다루는 과학
분야에 특화된 미디어 타입을 등록할 수 있다. 일반적으로, 이러한
추가 등록 트리 중 하나에 대한 명세 검토의 품질은 인정된 표준 관련
조직에 의한 표준 트리 등록과 동등할 것으로 기대된다. IETF가 그러한
검토를 수행할 때에는, 해당 미디어 타입 주제와 관련하여 요청 조직이
가진 더 큰 전문성을 고려해야 한다.
4. 등록 요구 사항
미디어 타입 등록은 모두 다음 절에 제시된 다양한 요구 사항을
준수할 것으로 기대된다. 요구 사항의 세부 내용은 등록 트리에 따라
달라질 수 있으며, 이는 다음 절들에 다시 자세히 설명되어 있음에
유의한다.
Freed 등 모범 현행 관행 [7페이지]
RFC 6838 미디어 타입 등록 2013년 1월
4.1. 기능성 요구 사항
미디어 타입은 실제 미디어 형식으로 기능해야 한다. 전송 인코딩,
문자 집합, 또는 다른 타입의 별도 엔터티 모음으로 보는 것이 더
적절한 것의 등록은 허용되지 않는다. 예를 들어 base64 전송 인코딩
[RFC2045]을 디코드하는 애플리케이션이 존재하더라도, base64는
미디어 타입으로 등록될 수 없다.
이 요구 사항은 관련된 등록 트리와 관계없이 적용된다.
4.2. 명명 요구 사항
등록된 모든 미디어 타입에는 최상위 타입 이름과 하위 타입 이름이
할당되어야 한다. 이 이름들의 조합은 미디어 타입을 고유하게
식별하는 역할을 하며, 하위 타입 이름 패싯(또는 그 부재)은 등록
트리를 식별한다. 최상위 타입 이름과 하위 타입 이름은 모두 대소문자
구분이 없다.
타입 및 하위 타입 이름은 다음 ABNF를 준수해야 한다.
type-name = restricted-name
subtype-name = restricted-name
restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first = ALPHA / DIGIT
restricted-name-chars = ALPHA / DIGIT / "!" / "#" /
"$" / "&" / "-" / "^" / "_"
restricted-name-chars =/ "." ; 첫 번째 점 앞의 문자는 항상
; 패싯 이름을 지정한다
restricted-name-chars =/ "+" ; 마지막 더하기 뒤의 문자는 항상
; 구조화 문법 접미사를 지정한다
이 구문은 [RFC2045] 제 5.1절 또는 [RFC4288] 제 4.2절의
ABNF에서 허용하는 것보다 다소 더 제한적이라는 점에 유의한다. 또한
이 구문은 최대 127자까지의 이름을 허용하지만, 구현 제한으로 인해
그러한 긴 이름이 문제가 될 수 있음에 유의한다. 이러한 이유로
<type-name> 및 <subtype-name>은 64자로 제한하는 것이 좋다.
이름 구문은 "."를 다른 문자와 동등하게 취급하지만, 최초의 "."
앞에 있는 문자는 항상 등록 패싯을 지정한다. 이는 패싯 없는 표준
트리 등록이 하위 타입 이름에 마침표를 사용할 수 없음을 의미한다는
점에 유의한다.
Freed 등 모범 현행 관행 [8페이지]
RFC 6838 미디어 타입 등록 2013년 1월
마찬가지로, 하위 타입 이름의 마지막 "+"는 구조화 문법 지정자
접미사를 도입한다. 구조화 문법 접미사 요구 사항은 제4.2.8절에
명세되어 있다.
주어진 미디어 타입에 추가 이름을 할당할 수는 있지만, 같은 미디어
타입을 식별하기 위해 서로 다른 이름을 사용하는 것은 권장되지 않는다.
이러한 요구 사항은 관련된 등록 트리와 관계없이 적용된다.
최상위 타입의 선택은 관련 미디어 타입의 성격을 고려해야 한다.
최상위 타입의 새로운 하위 타입은 그 최상위 타입의 제한 사항이
있다면 이를 준수해야 한다. 다음 절들은 최초 최상위 타입 집합 각각과
그 관련 제한 사항을 설명한다. 추가로, HTTP 및 MIME을 포함하되 이에
한정되지 않는 다양한 프로토콜은 자신들이 운반할 수 있는 미디어
타입에 추가 제한을 부과할 수 있다. (MIME이 부과하는 제한에 관한
추가 정보는 [RFC2046]을 참조한다.)
4.2.1. 텍스트 미디어 타입
"text" 최상위 타입은 주로 텍스트 형식의 자료를 보내기 위한 것이다.
특히 [RFC2046]에 정의된 일반 평문 하위 타입인 "text/plain"을
포함하여, 텍스트의 많은 하위 타입은 "charset" 매개변수를 정의한다.
특정 텍스트 하위 타입에 "charset" 매개변수가 정의된 경우, 이는
[RFC2978]에 제시된 절차에 따라 정의된 문자 집합 이름을 지정하는 데
사용되어야 한다.
[RFC6657]에 명세된 바와 같이, 문자 집합 정보가 페이로드 내부에서
전달되는 경우(예: "text/xml")에는 "charset" 매개변수를 지정하지
않는 것이 좋다.
"charset" 매개변수가 지정되는 경우, 기본값을 지정하는 선택지를
제거하기 위해 필수 매개변수로 하는 것이 좋다. 이 조언에도 불구하고
매개변수를 선택 사항으로 해야 할 강한 이유가 있는 경우, 각 하위
타입은 자체 기본값을 지정할 수도 있고, 대안적으로 기본값이 없다고
지정할 수도 있다. 마지막으로, "UTF-8" 문자 집합 [RFC3629]을
기본값으로 선택하는 것이 좋다. 텍스트 하위 타입과 함께 "charset"
매개변수를 사용하는 것에 관한 추가 정보는 [RFC6657]을 참조한다.
어떤 접근 방식을 선택하든, 모든 새로운 text/* 등록은 문자 집합이
어떻게 결정되는지를 명확히 지정해야 한다. [RFC2046] 제 4.1.2절에
정의된 US-ASCII 기본값에 의존하는 것은 더 이상
Freed 등 모범 현행 관행 [9페이지]
RFC 6838 미디어 타입 등록 2013년 1월
허용되지 않는다. 설명 텍스트가 필요한 경우, 이는 등록의 추가 정보
절에 두는 것이 좋다.
평문은 서식 지정 명령, 글꼴 속성 명세, 처리 지시, 해석 지시 또는
콘텐츠 마크업을 제공하거나 허용하지 않는다. 평문은 단순히 선형적인
문자 시퀀스로 보이며, 줄 바꿈이나 페이지 바꿈으로 중단될 수 있다.
평문은 여러 문자가 텍스트의 같은 위치에 겹쳐 놓이는 것을 허용할 수
있다. 아랍어 및 히브리어와 같은 문자의 평문은 서로 다른 쓰기 방향을
가진 텍스트 구간을 임의로 섞을 수 있게 하는 기능도 포함할 수 있다.
평문을 넘어, "서식 있는 텍스트"라고 알려질 수 있는 것을 표현하는
형식이 많이 있다. 그러한 많은 표현의 흥미로운 특징은 이를 해석하는
소프트웨어가 없어도 어느 정도 읽을 수 있다는 것이다. 최고 수준에서
이를 이미지, 오디오 또는 읽을 수 없는 형태로 표현된 텍스트와 같은
읽을 수 없는 데이터와 구별하는 것이 유용하다. 적절한 해석
소프트웨어가 없을 때, "text"의 하위 타입은 사용자에게 제시하는 것이
합리적이지만, 대부분의 비텍스트 데이터에 대해서는 그렇지 않다.
그러한 서식 있는 텍스트 데이터는 "text"의 하위 타입을 사용하여
표현될 수 있다.
4.2.2. 이미지 미디어 타입
"image" 최상위 타입은 콘텐츠가 하나 이상의 개별 이미지를 지정함을
나타낸다. 하위 타입은 특정 이미지 형식을 명명한다.
4.2.3. 오디오 미디어 타입
"audio" 최상위 타입은 콘텐츠가 오디오 데이터를 포함함을 나타낸다.
하위 타입은 특정 오디오 형식을 명명한다.
4.2.4. 비디오 미디어 타입
"video" 최상위 타입은 콘텐츠가 시간에 따라 변하는 그림 이미지를
지정하며, 색상 및 조정된 사운드를 포함할 수 있음을 나타낸다.
'video'라는 용어는 특정 기술이나 형식을 가리키기보다 가장 일반적인
의미로 사용되며, 콤팩트하게 인코딩된 애니메이션 그림과 같은 하위
타입을 배제하려는 것이 아니다.
일반적으로 하나의 본문 안에 여러 종류의 미디어를 혼합하는 것은
권장되지 않지만 [RFC2046], 많은 비디오 형식이 동기화된 오디오
및/또는 텍스트에 대한 표현을 포함한다는 점이 인정되며, 이는
"video"의 하위 타입에 대해 명시적으로 허용된다.
Freed 등 모범 현행 관행 [10페이지]
RFC 6838 미디어 타입 등록 2013년 1월
4.2.5. 애플리케이션 미디어 타입
"application" 최상위 타입은 다른 타입 이름 어디에도 들어맞지 않는
개별 데이터, 특히 어떤 유형의 애플리케이션 프로그램에 의해 처리될
데이터를 위해 사용된다. 이는 사용자가 보거나 사용할 수 있기 전에
애플리케이션에 의해 처리되어야 하는 정보다. "application" 타입
이름의 예상 용도에는 파일 전송, 스프레드시트, 프레젠테이션, 일정
데이터, 그리고 "능동적"(계산적) 자료를 위한 언어가 포함되지만
이에 한정되지는 않는다. (특히 마지막 것은 구현자가 이해해야 하는
보안 문제를 일으킬 수 있다. [RFC2046]의 "application/postscript"
미디어 타입 등록은 이러한 문제를 처리하는 방법에 대한 좋은 예를
제공한다.)
예를 들어, 회의 일정 관리자는 제안된 회의 날짜에 관한 정보에 대한
표준 표현을 정의할 수 있다. 지능형 사용자 에이전트는 이 정보를
사용하여 사용자와 대화를 수행하고, 그 대화에 기반하여 추가 자료를
보낼 수 있다. 더 일반적으로, 적절히 특화된 언어의 프로그램이 원격
위치로 전달되어 수신자의 환경에서 자동 실행되는 여러 "능동적"
언어가 개발되어 왔다. 그러한 애플리케이션은 "application" 최상위
타입의 하위 타입으로 정의될 수 있다.
"application"의 하위 타입은 종종 데이터가 의도된 애플리케이션의
이름이거나 그 이름의 일부를 포함한다. 그러나 이것이 어떤
애플리케이션 프로그램 이름이든 단순히 "application"의 하위 타입으로
자유롭게 사용될 수 있음을 의미하지는 않는다. 하위 타입은 등록될
필요가 있다.
4.2.6. 멀티파트 및 메시지 미디어 타입
멀티파트와 메시지는 복합 타입이다. 즉, 이들은 각각 별도의 미디어
타입인 객체 0개 이상을 캡슐화하는 수단을 제공한다.
멀티파트 및 메시지의 모든 하위 타입은 [RFC2046]에 명세되고
[RFC6532] 제 3.5절에 의해 수정된 구문 규칙 및 기타 요구 사항을
준수해야 한다.
Freed 등 모범 현행 관행 [11페이지]
RFC 6838 미디어 타입 등록 2013년 1월
4.2.7. 추가 최상위 타입
어떤 경우에는 새로운 미디어 타입이 현재 정의된 어떤 최상위 타입
이름 아래에도 "들어맞지" 않을 수 있다. 그러한 경우는 매우 드물
것으로 예상된다. 그러나 그러한 경우가 발생하면, 이를 수용하기 위해
새로운 타입 이름을 정의할 수 있다. 새로운 최상위 타입 이름의 정의는
표준 트랙 RFC를 통해 수행되어야 하며, 추가 타입 이름을 정의하는 데
다른 메커니즘은 사용할 수 없다.
4.2.8. 구조화 문법 이름 접미사
MIME의 XML [RFC3023]은 미디어 타입의 기반 구조를 추가로 지정하기
위해 미디어 타입 정의에 대한 이러한 첫 번째 확장을 정의했다.
인용하면 다음과 같다.
이 문서는 또한 그러한 미디어 타입이 XML MIME(Multipurpose
Internet Mail Extensions) 엔터티를 나타낼 때 미디어 타입의
이름을 붙이기 위한 규약('+xml' 접미사 사용)을 표준화한다 ...
즉, 기본 하위 타입 이름에 붙일 접미사(그 경우에는 "+xml")를
지정했다.
이것이 출판된 이후, 다른 잘 알려진 구조화 구문에 이 접미사 규약을
사용하는 사실상의 관행이 생겨났다. 특히, "+der", "+fastinfoset",
"+json"과 같은 접미사가 붙은 미디어 타입이 등록되어 왔다. 이 명세는
이러한 관행을 공식화하고 구조화 타입 이름 접미사를 위한 레지스트리를
설정한다.
구조화 타입 이름 접미사를 등록할 수 있는지 여부에 대한 주된 지침은
그것이 쉽게 이용 가능한 설명으로 기술되어야 한다는 점이다. 바람직하게는
확립된 표준 관련 조직이 출판한 문서 안에 기술되고, RFC의 규범적
참고 문헌 절에서 사용할 수 있는 참조가 있어야 한다.
명명된 구조화 문법을 사용하는 미디어 타입은 등록될 때 해당 구조화
문법에 대한 적절히 등록된 "+suffix"를 사용하는 것이 좋다. 마찬가지로,
미디어 타입에는 실제로 사용하지 않는 구조화 문법의 접미사를 포함한
이름을 부여해서는 안 된다. 아직 등록되지 않은 구조화 문법에 대한
"+suffix" 구성은 향후 접미사 정의와 충돌할 가능성이 있으므로 사용하지
않는 것이 좋다.
Freed 등 모범 현행 관행 [12페이지]
RFC 6838 미디어 타입 등록 2013년 1월
4.2.9. 폐기된 별칭
어떤 경우에는 하나의 미디어 타입이 등록 전에 여러 이름으로 널리
배포되었을 수 있다. 그러한 경우에는 해당 미디어 타입에 대해 선호
이름을 선택해야 하며, 애플리케이션은 그 타입의 등록에 부합하기 위해
이 이름을 사용해야 한다. 그러나 해당 타입이 알려진 폐기된 별칭의
목록을 추가 정보로 제공할 수 있으며, 이는 애플리케이션이 미디어
타입을 올바르게 처리하는 데 도움을 주기 위한 것이다.
4.3. 매개변수 요구 사항
미디어 타입은 하나 이상의 미디어 타입 매개변수를 사용하기로 선택할
수 있으며, 또는 해당 하위 타입에 적용 가능한 매개변수 집합을 정의한
콘텐츠 타입의 하위 타입이라는 이유로 어떤 매개변수가 미디어 타입에
자동으로 제공될 수도 있다. 어느 경우든, 어떤 매개변수의 이름, 값,
의미도 미디어 타입이 표준 트리에 등록될 때에는 완전히 명세되어야
하며, 미디어 타입이 벤더 또는 개인 트리에 등록될 때에는 가능한 한
완전하게 명세되는 것이 좋다.
매개변수 이름은 미디어 타입 이름 및 값과 같은 구문을 갖는다.
parameter-name = restricted-name
이 구문은 [RFC2045]의 ABNF 및 [RFC2231]에 의해 수정된 ABNF에서
허용하는 것보다 다소 더 제한적이라는 점에 유의한다.
매개변수 이름은 대소문자 구분이 없으며, 이들이 나타나는 순서에는
아무런 의미도 부여되지 않는다. 특정 매개변수를 두 번 이상 지정하는
것은 오류다.
매개변수 값에 대해 정의된 구문은 없다. 따라서 등록은 매개변수 값
구문을 명세해야 한다. 추가로, 일부 전송 방식은 매개변수 값 구문에
제한을 부과하므로, 잠재적으로 문제가 될 수 있는 구문의 사용을
제한하도록 주의해야 한다. 예를 들어 순수 이진 값 매개변수는 일부
프로토콜에서 허용되지만 피하는 것이 가장 좋다.
프로토콜은 매개변수를 표현하는 방식을 어떻게 선택하느냐에 따라
매개변수 값 구문에 추가 제한을 부과할 수 있음에 유의한다. MIME
[RFC2045] [RFC2231]과 HTTP [RFC2045] [RFC5987]는 이진 매개변수뿐만 아니라 특정
문자 집합으로 표현된 매개변수 값도 허용하지만, 다른 프로토콜은
덜 유연할 수 있다.
표준 트리에 등록된 타입에서 새로운 기능을 도입하는 방법으로 새
매개변수를 정의하지 않는 것이 좋지만, 기존 기능을 달리 변경하지
않는 추가 정보를 전달하기 위해 새 매개변수를 추가할 수는 있다.
Freed 등 모범 현행 관행 [13페이지]
RFC 6838 미디어 타입 등록 2013년 1월
이에 대한 예로 JPEG와 같은 외부 명세의 개정 수준을 나타내는
"revision" 매개변수가 있을 수 있다. 벤더 또는 개인 트리에 등록된
미디어 타입에 대해서도 유사한 동작이 권장되지만 필수는 아니다.
매개변수의 변경(새 매개변수의 도입 포함)은 미디어 타입에 대한 다른
변경과 같은 방식으로 관리된다. 제5.5절을 참조한다.
4.4. 정규화 및 형식 요구 사항
등록된 모든 미디어 타입은 등록 트리와 관계없이 하나의 정규 데이터
형식을 사용해야 한다.
표준 트리에 등록된 모든 타입에 대해서는 해당 미디어 타입 형식에
관한 영구적이고 쉽게 이용 가능한 공개 명세가 존재해야 한다. 이
명세는 그 미디어 타입을 사용하는 독립 구현 간의 상호운용성이 가능할
만큼 충분히 자세한 내용을 제공해야 한다. 이 명세는 최소한 미디어
타입 등록 제안서 자체에 실제로 포함되어 있지 않다면 그 제안서에서
참조되어야 한다.
벤더 및 개인 트리에 등록된 미디어 타입의 형식과 처리 세부 사항에
관한 명세는 공개적으로 이용 가능할 수도 있고 그렇지 않을 수도 있다.
그러한 등록은 등록에서 어떤 소프트웨어와 버전이 그러한 미디어
타입을 생성하거나 처리하는지에 대한 정보로 제한하는 것이 명시적으로
허용된다. 따라서 등록에 형식 명세를 참조하거나 포함하는 것은
권장되지만 필수는 아니다. 그러나 의미 있는 명세의 공개적 이용
가능성은 다른 사용과 충돌이 없도록 이름만 예약하는 것과, 그 미디어
타입의 다른 구현 및 그들과의 유용한 상호운용 가능성을 갖는 것
사이의 차이를 만드는 경우가 많다는 점에 유의한다.
일부 미디어 타입은 특허 기술의 사용을 포함한다. 특허 기술을 포함한
미디어 타입의 등록은 명시적으로 허용된다. 그러나 미디어 타입의
명세가 표준 트랙 프로토콜의 일부인 경우, IETF 표준 트랙 프로토콜에서
특허 기술 사용에 관한 BCP
79 [RFC3979] 및 BCP 78 [RFC5378]에 제시된 제한을
준수해야 한다. 또한 표준 트리를 사용하는 다른 표준 관련 조직은
등록 시 준수해야 할 자체 지식 재산권 규칙을 가질 수 있다.
벤더 및 개인 트리 등록에 대한 지식 재산권(IPR) 공개는 권장되지만
필수는 아니다.
Freed 등 모범 현행 관행 [14페이지]
RFC 6838 미디어 타입 등록 2013년 1월
4.5. 교환 권고 사항
이상적으로 미디어 타입은 가능한 한 많은 시스템과 애플리케이션에서
상호 운용되도록 정의될 것이다. 그러나 일부 미디어 타입은 필연적으로
서로 다른 플랫폼 간 상호운용에 문제가 있을 수 있다. 서로 다른
버전, 바이트 순서, 게이트웨이 처리의 세부 사항과 관련된 문제가
발생할 수 있고 실제로 발생한다.
미디어 타입의 보편적 상호운용성이 요구되는 것은 아니지만, 알려진
상호운용성 문제는 가능한 경우 식별하는 것이 좋다. 미디어 타입의
출판이 상호운용성에 대한 철저한 검토를 요구하지는 않으며,
상호운용성 고려 사항 절은 지속적인 평가의 대상이다.
이 하위 절의 권고 사항은 관련된 등록 트리와 관계없이 적용된다.
4.6. 보안 요구 사항
표준 트리에 등록되는 모든 타입에 대해서는 보안 문제 분석이
수행되어야 한다. 벤더 또는 개인 트리에 등록되는 미디어 타입에 대한
유사한 분석은 권장되지만 필수는 아니다. 그러나 어떤 보안 분석이
수행되었는지 또는 수행되지 않았는지와 관계없이, 보안 문제에 대한
모든 설명은 등록 트리와 관계없이 가능한 한 정확해야 한다. 특히
보안 고려 사항은 "이 타입과 관련된 보안 문제가 없다"고 진술해서는
안 된다. 벤더 또는 개인 트리의 타입에 대한 보안 고려 사항은 "이
타입과 관련된 보안 문제는 평가되지 않았다"고 말할 수 있다.
어떤 트리에 등록된 미디어 타입이 안전하거나 위험으로부터 완전히
자유로워야 한다는 요구 사항은 전혀 없다. 그럼에도 불구하고 알려진
모든 보안 위험은 다시 등록 트리와 관계없이 미디어 타입 등록에서
식별되어야 한다.
모든 등록의 보안 고려 사항 절은 지속적인 평가와 수정의 대상이며,
특히 아래 제5.4절에 설명된 "미디어 타입에 대한 의견" 메커니즘을
사용하여 확장될 수 있다.
미디어 타입의 보안 분석에서 검토하고 설명해야 할 몇 가지 문제는
다음과 같다.
o 복잡한 미디어 타입은 수신자의 파일이나 기타 리소스에 대한 작업을
개시하는 지시문에 관한 규정을 포함할 수 있다. 많은 경우, 작성자가
제한 없이 임의의 작업을 지정할 수 있도록 하는 규정이 마련되어
있으며, 이는 치명적인 영향을 미칠 수 있다. 그러한 지시문과 이를
Freed 등 모범 현행 관행 [15페이지]
RFC 6838 미디어 타입 등록 2013년 1월
미디어 타입 등록에서 설명하는 방법의 예는 [RFC2046]의
application/postscript 미디어 타입 등록을 참조한다.
o 모든 보안 분석은 그러한 "능동 콘텐츠"를 사용하는지 여부를
명시해야 한다. 사용하는 경우, 미디어 타입의 애플리케이션이 그
미디어 타입의 사용자를 피해로부터 보호하기 위해 어떤 조치를
취했는지 또는 취해야 하는지를 명시해야 한다.
o 복잡한 미디어 타입은 수신자에게 직접 해롭지는 않지만 후속 공격을
용이하게 하거나 어떤 방식으로든 수신자의 프라이버시를 침해하는
정보 공개를 초래할 수 있는 작업을 개시하는 지시문에 관한 규정을
포함할 수 있다. 다시 말해, application/postscript 미디어 타입
등록은 그러한 지시문을 처리하는 방법을 보여 준다.
o 압축을 사용하는 미디어 타입은 소량의 데이터를 보내고, 이것이
수신되어 평가될 때 엄청나게 확장되어 수신자의 모든 리소스를
소비하게 하는 기회를 제공할 수 있다. 모든 미디어 타입은 압축을
사용하는지 여부를 명시하는 것이 좋다. 사용하는 경우, 그러한
공격을 피하기 위해 어떤 조치를 취해야 하는지 논의하는 것이 좋다.
o 미디어 타입은 어떤 종류의 보안 보장을 요구하지만 그 자체로 필요한
보안 메커니즘을 제공하지 않는 애플리케이션을 대상으로 할 수 있다.
예를 들어, 미디어 타입은 민감한 의료 정보의 저장을 위해 정의될 수
있으며, 이는 외부의 기밀성 및 무결성 보호 서비스를 필요로 하거나
보안 환경 내에서만 사용되도록 설계될 수 있다. 타입은 그러한
서비스가 필요한지 여부를 보안 고려 사항에 항상 문서화하는 것이
좋다.
4.7. XML 미디어 타입에 특화된 요구 사항
XML 미디어 타입 등록에 특화된 추가 요구 사항이 다수 있다. 이러한
요구 사항은 [RFC3023]에 명세되어 있다.
4.8. 인코딩 요구 사항
일부 전송 방식은 운반할 수 있는 데이터의 유형에 제한을 부과한다.
예를 들어, 인터넷 메일은 전통적으로 7비트 US-ASCII 텍스트로
제한되었다. 그러한 전송 제한을 우회하기 위해 인코딩 체계가 자주
사용된다.
Freed 등 모범 현행 관행 [16페이지]
RFC 6838 미디어 타입 등록 2013년 1월
따라서 미디어 타입이 어떤 종류의 데이터로 구성될 수 있는지를 등록의
일부로 기록하는 것이 유용하다. 이를 위해 "encoding considerations"
필드가 제공된다. 이 필드의 가능한 값은 다음과 같다.
7bit: 미디어 타입의 콘텐츠는 CRLF로 구분된 7비트 US-ASCII
텍스트만으로 구성된다.
8bit: 미디어 타입의 콘텐츠는 CRLF로 구분된 8비트 텍스트만으로
구성된다.
binary: 콘텐츠는 제한 없는 옥텟 시퀀스로 구성된다.
framed: 콘텐츠는 내부 프레이밍 또는 정렬 표시자가 없는 일련의
프레임 또는 패킷으로 구성된다. 데이터를 올바르게 해석하려면
연속 프레임 간 경계에 대한 지식 및 전송 메커니즘에 대한 지식을
포함하되 반드시 이에 한정되지 않는 추가적인 대역 외 정보가
필요하다. 이러한 종류의 미디어 타입은 단순히 파일에 저장되거나
옥텟의 단순 스트림으로 전송될 수 없다는 점에 유의한다. 따라서
그러한 미디어 타입은 많은 전통적 프로토콜에서 사용하기에 적합하지
않다. 프레임 인코딩에서 흔히 사용되는 전송 방식은 실시간 전송
프로토콜(RTP)이다. RTP를 사용하는 전송을 위해 정의된 프레임
인코딩에 대한 추가 규칙은 [RFC4855]에 제시되어 있다.
7비트 및 8비트 텍스트에 대한 추가 제한은 [RFC2046] 제
4.1.1절에 제시되어 있다.
4.9. 사용 및 구현 비요구 사항
송신자가 원격 메일 에이전트의 기능에 관한 정보를 자주 이용할 수
없는 비동기 메일 환경에서는, 널리 구현될 것으로 예상되는 "공통"
형식으로 사용되는 미디어 타입을 제한함으로써 최대의 상호운용성을
달성한다. 과거에는 이것이 가능한 미디어 타입 수를 제한해야 하는
이유로 주장되었고, 그 결과 미디어 타입 등록자에게 상당한 장벽과
지연을 초래하는 등록 절차가 생겼다.
그러나 "공통" 미디어 타입의 필요성이 새로운 미디어 타입의 등록을
제한할 것을 요구하지는 않는다. 특정 애플리케이션에 대해 제한된
미디어 타입 집합이 권장되는 경우, 그것은 해당 애플리케이션 및/또는
환경에 특화된 별도의 적용성 진술에서 주장되어야 한다.
따라서 미디어 타입의 보편적 지원 및 구현은 등록의 요구 사항이
아니다. 그러나 미디어 타입이
Freed 등 모범 현행 관행 [17페이지]
RFC 6838 미디어 타입 등록 2013년 1월
제한된 사용을 명시적으로 의도하는 경우, 이는 그 등록에 기록되어야
한다. 이를 위해 "Restrictions on Usage" 필드가 제공된다.
4.10. 출판 요구 사항
IETF 자체가 표준 트리에 등록하는 미디어 타입은 RFC로 출판되어야
한다. 벤더 및 개인 미디어 타입 등록의 RFC 출판은 허용되지만 필수는
아니다. 모든 경우에 IANA는 모든 미디어 타입 등록의 사본을 보관하고
이를 미디어 타입 등록 트리 자체의 일부로 "출판"한다.
앞서 언급한 바와 같이, 다른 표준 관련 조직이 작성한 문서에 정의된
미디어 타입에 대한 표준 트리 등록은 해당 조직이 작성한 공식 표준
명세로 설명되어야 한다. 또한 등록 템플릿의 모든 저작권은 IANA가
이를 IANA 레지스트리에 복사할 수 있도록 허용해야 한다.
표준 트리의 IETF 등록을 제외하면, 미디어 타입 등록은 IANA나 IETF의
지지, 승인 또는 권고를 의미하지 않으며, 명세가 충분하다는 인증조차
의미하지 않는다. IETF 표준이 되려면 프로토콜 또는 데이터 객체는
IETF 표준 절차를 거쳐야 한다. 적절한 경우 이는 추가 보장을 제공하지만,
미디어 타입의 편리한 등록을 위해서는 너무 어렵고 너무 긴 절차이다.
표준 트리는 인정된 표준 관련 조직에서 실질적인 검토와 승인 절차를
필요로 하는 미디어 타입을 위해 존재한다. 벤더 및 개인 트리는 그러한
절차를 필요로 하지 않는 미디어 타입을 위해 존재한다. 특정
애플리케이션에 대한 적용성 진술은 때때로 IETF에서 출판되어, 그러한
맥락에서 특히 유용함이 입증된 미디어 타입의 구현 및 지원을 권고할
것으로 예상된다.
위에서 논의한 바와 같이, 최상위 타입의 등록은 IETF에서의 표준 조치를
필요로 하며, 따라서 표준 트랙 RFC의 출판을 필요로 한다.
4.11. 프래그먼트 식별자 요구 사항
미디어 타입 등록은 해당 미디어 타입과 관련된 프래그먼트 식별자
([RFC3986] 제 3.5절에 명세됨)를 애플리케이션이 어떻게 해석해야
하는지를 지정할 수 있다.
Freed 등 모범 현행 관행 [18페이지]
RFC 6838 미디어 타입 등록 2013년 1월
미디어 타입은 의미적으로 유사한 미디어 타입에서 사용되는 프래그먼트
식별자 체계를 채택하도록 권장된다. 특히, 등록된 "+suffix"가 있는
명명된 구조화 문법을 사용하는 미디어 타입은 구조화 문법 접미사
등록에 제시된 프래그먼트 식별자 규칙이 무엇이든 이를 따라야 한다.
4.12. 추가 정보
다양한 종류의 선택적 정보는 이용 가능한 경우 미디어 타입 명세에
포함하는 것이 좋다.
o 매직 넘버(길이, 옥텟 값). 매직 넘버는 파일의 지정된 위치에 항상
존재하는 바이트 시퀀스이며, 따라서 엔터티가 주어진 미디어 타입임을
식별하는 데 사용할 수 있다.
o 어떤 파일이 주어진 미디어 타입을 포함함을 나타내기 위해 하나
이상의 플랫폼에서 흔히 사용되는 파일 이름 확장자.
o 주어진 미디어 타입을 포함하는 파일에 레이블을 붙이는 데 사용되는
Mac OS 파일 타입 코드(4옥텟). Macintosh 파일 타입 코드와 그 목적에
관한 일부 논의는 [MacOSFileTypes]에서 찾을 수 있다.
표준 트리의 등록인 경우, 이 추가 정보는 미디어 타입 형식의 공식
명세에서 제공될 수 있다. 이는 IANA 미디어 타입 등록 양식을 형식
명세 자체에 통합하여 수행하는 것이 제안된다.
5. 미디어 타입 등록 절차
미디어 타입 등록 절차는 공식 표준 절차가 아니라, 과도한 시간 지연
없이 공동체 의견과 타당성 검사를 가능하게 하기 위한 행정 절차이다.
표준 트리의 모든 IETF 등록에는 일반 IETF 절차를 따라야 한다. 인터넷
초안 게시가 필요한 첫 단계이며, 그 뒤에는 아래에서 논의하는 대로
media-types@iana.org 목록에 게시하는 절차가 따른다.
5.1. 예비 공동체 검토
표준 트리의 잠재적 미디어 타입 등록에 대한 통지는 검토를 위해
media-types@iana.org 메일링 리스트로 보내는 것이 좋다. 이 메일링
리스트는 제안된 미디어 및 접근 타입을 검토하기 위한 목적으로
만들어졌다. 다른 트리의 등록도 검토를 위해 이 목록으로 보낼 수
있다. 그렇게 하는 것은 전적으로 선택 사항이지만 강하게 권장된다.
Freed 등 모범 현행 관행 [19페이지]
RFC 6838 미디어 타입 등록 2013년 1월
이 목록에 공개 게시하는 의도는 타입/하위 타입 이름의 선택, 버전 및
외부 프로파일링 정보와 관련한 참조의 모호하지 않음, 그리고 모든
상호운용성 또는 보안 고려 사항에 대한 검토와 의견을 요청하는 것이다.
제출자는 언제든지 수정된 등록 제안서를 제출하거나 등록을 완전히
포기할 수 있다.
5.2. IANA에 요청 제출
IETF 자체가 표준 트리에 등록하는 미디어 타입은 일반 표준 절차의
일부로 IESG의 검토와 승인을 받아야 한다. 인정된 표준 관련 조직의
표준 트리 등록과 벤더 및 개인 트리의 등록은 연락 협정의 일부로 다른
약정이 이루어지지 않은 한 IANA에 직접 제출된다. 어느 경우든, 제출
전에 검토를 위해 등록을 media-types@iana.org 목록에 게시하는 것이
강하게 권장된다.
등록 요청은 iana@iana.org로 보낼 수 있다. 등록 요청을 위한 웹 양식도
제공된다.
http://www.iana.org/form/media-types
5.2.1. 임시 등록
표준화 절차는 완료하는 데 상당한 시간이 걸리는 경우가 많다.
프로토타이핑과 테스트를 용이하게 하기 위해, 미디어 타입을 포함하되
이에 한정되지 않는 식별자를 절차 초기에 할당하는 것이 도움이 되는
경우가 많다. 이렇게 하면 표준 개발 중에 사용된 식별자가 절차 완료
후에도 변경되지 않은 상태로 유지될 수 있으며, 구현과 문서를 갱신할
필요가 없다.
이에 따라 표준 트리에서 미디어 타입 이름을 조기에 할당하는 것을
지원하기 위해 임시 등록 절차가 제공된다. 표준 트리 타입에 대해
임시 등록을 IANA에 제출할 수 있다. 그러한 등록에서 유일하게 필요한
필드는 미디어 타입 이름과 연락처 정보(표준 관련 조직 이름 포함)이다.
임시 등록을 수신하면, IANA는 이름과 연락처 정보를 확인한 다음,
별도의 공개적으로 볼 수 있는 임시 등록 목록에 등록을 게시한다.
임시 등록은 언제든지 갱신되거나 포기될 수 있다. 등록이 포기되면
해당 미디어 타입은 어떤 의미에서도 더 이상 등록되어 있지 않다. 이후
다른 미할당 미디어 타입 이름과 똑같이 등록될 수 있다.
Freed 등 모범 현행 관행 [20페이지]
RFC 6838 미디어 타입 등록 2013년 1월
5.3. 검토 및 승인
임시 표준 트리 등록을 제외하고, IANA에 제출된 등록은 미디어 타입
검토자에게 전달된다. IETF 애플리케이션 영역 책임자가 임명하는
미디어 타입 검토자는 등록이 이 문서에 제시된 요구 사항을 충족하는지
확인하기 위해 검토한다. 이러한 요구 사항을 충족하지 못하는 등록은
수정을 위해 제출자에게 반환된다.
미디어 타입 검토자가 내린 결정은 [RFC2026] 제 6.5.4절에 명세된
절차를 사용하여 IESG에 이의 제기할 수 있다.
미디어 타입 등록이 검토를 통과하면, IANA는 미디어 타입을 등록하고
미디어 타입 등록을 공동체가 이용할 수 있도록 한다.
다른 표준 관련 조직의 표준 트리 등록인 경우, IANA는 제출자가 실제로
인정된 표준 관련 조직인지도 확인한다. 제출자가 현재 그러한 조직으로
인정되어 있지 않으면, IESG에 그 지위를 확인해 달라고 요청한다. 표준
트리 등록을 진행하려면 IESG의 인정이 먼저 확보되어야 한다.
5.4. 미디어 타입 등록에 대한 의견
등록된 미디어 타입에 대한 의견은 공동체 구성원이 IANA의
iana@iana.org로 제출할 수 있다. 이러한 의견은 미디어 타입 검토자가
검토한 다음 가능하다면 미디어 타입의 "소유자"에게 전달된다. 의견
제출자는 자신의 의견이 미디어 타입 등록 자체에 첨부되도록 요청할 수
있다. IANA가 미디어 타입 검토자와 협의하여 승인하면, 해당 의견은
타입 등록과 함께 접근 가능하게 된다.
5.5. 변경 절차
미디어 타입이 IANA에 의해 출판된 후, 소유자는 그 정의에 대한 변경을
요청할 수 있다. 위에서 서로 다른 등록 트리에 대해 설명한 내용은 각
유형의 등록에 대한 "소유자"를 지정한다. 원래 등록 요청에 적절했을
절차와 동일한 절차가 변경 요청을 처리하는 데 사용된다.
미디어 타입 등록은 삭제될 수 없다. 더 이상 사용에 적합하지 않다고
여겨지는 미디어 타입은 "intended use" 필드의 변경을 통해 OBSOLETE로
선언될 수 있다. 그러한 미디어 타입은 IANA가 출판하는 목록에 명확히
표시된다.
Freed 등 모범 현행 관행 [21페이지]
RFC 6838 미디어 타입 등록 2013년 1월
미디어 타입 정의에 대한 중대한 변경은 출판된 명세에 심각한 누락이나
오류가 있을 때에만 요청되어야 한다. 검토가 필요한 경우, 변경 요청이
이전 정의에서는 유효했던 엔터티를 새 정의에서는 무효로 만들면 변경
요청이 거부될 수 있다.
미디어 타입의 소유자는 IANA에 통지하여 책임을 다른 사람이나 기관에
넘길 수 있다. 이는 논의나 검토 없이 수행될 수 있다.
IESG는 미디어 타입에 대한 책임을 재할당할 수 있다. 가장 흔한 경우는
등록 작성자가 사망했거나 연락이 끊겼거나, 공동체에 중요한 변경을
수행할 수 없는 경우 그 타입에 대한 변경이 가능하도록 하기 위한
것이다.
5.6. 등록 템플릿
타입 이름:
하위 타입 이름:
필수 매개변수:
선택적 매개변수:
인코딩 고려 사항:
보안 고려 사항:
상호운용성 고려 사항:
출판된 명세:
이 미디어 타입을 사용하는 애플리케이션:
프래그먼트 식별자 고려 사항:
추가 정보:
이 타입의 폐기된 별칭 이름:
매직 넘버:
파일 확장자:
Macintosh 파일 타입 코드:
추가 정보를 위한 연락 담당자 및 이메일 주소:
Freed 등 모범 현행 관행 [22페이지]
RFC 6838 미디어 타입 등록 2013년 1월
의도된 사용:
(COMMON, LIMITED USE 또는 OBSOLETE 중 하나.)
사용 제한:
(미디어 타입을 사용할 수 있는 곳에 대한 모든 제한은 여기에 둔다.)
작성자:
변경 관리자:
임시 등록 여부? (표준 트리 전용):
(작성자가 흥미롭다고 판단하는 기타 정보는 이 줄 아래에 추가할 수
있다.)
원하는 경우 어떤 필드에서든 정확히 그렇게 쓰인 "N/A"를 사용할 수
있으며, 이는 해당 사항이 없거나 질문이 실수로 누락된 것이 아님을
강조하기 위한 것이다. 응답으로 오인될 수 있는 'none' 또는 다른 단어는
사용하지 않는다.
제한 사용 미디어 타입은 애플리케이션 목록에서 그 목록이 완전한지
여부도 기록하는 것이 좋다.
6. 구조화 문법 접미사 등록 절차
새로운 미디어 타입 등록과 함께 사용할 구조화 문법에 대한 "+suffix"
이름을 정의하려는 사람은 다음을 수행하는 것이 좋다.
1. IANA의 미디어 타입 이름 접미사 레지스트리를 확인하여, 해당
잘 정의된 구조화 문법에 대한 항목이 이미 있는지 여부를 확인한다.
2. 해당 접미사 체계에 대한 항목이 없으면, 템플릿(제6.2절에
명세됨)을 작성하고 이를 미디어 타입 등록에 포함한다. 템플릿은
인터넷 초안에 단독으로 또는 다른 프로토콜 명세의 일부로 포함될
수 있다. 템플릿은 다른 형식(다른 문서의 일부 또는 독립 문서로서)으로
제출될 수도 있지만, 그 내용은 BCP 78 [RFC5378]의 지침에 따라
"IETF 기여"로 취급된다.
3. 템플릿 사본 또는 이를 포함하는 문서에 대한 포인터(템플릿이 있는
절에 대한 구체적 참조 포함)를 media-types@iana.org 메일링 리스트로
보내 검토를 요청한다.
Freed 등 모범 현행 관행 [23페이지]
RFC 6838 미디어 타입 등록 2013년 1월
이는 미디어 타입 등록 검토 요청과 결합될 수 있다. 논의와 의견을
위해 합리적인 시간을 허용한다.
4. 검토 의견에 응답하고, 이 문서에 제시된 지침에 맞도록 필요한 경우
제안된 등록을 수정한다.
5. (갱신되었을 수 있는) 등록 템플릿 또는 이를 포함하는 문서에 대한
포인터를 IANA의 iana@iana.org로 제출한다.
구조화 문법 접미사 등록 요청을 받으면,
1. IANA는 제출물이 완전한지 확인한다. 절이 누락되었거나 인용이
올바르지 않으면, IANA는 등록 요청을 거부한다.
2. IANA는 현재 레지스트리에 같은 이름의 항목이 있는지 확인한다.
그러한 레지스트리가 존재하면, IANA는 등록 요청을 거부한다.
3. IANA는 해당 지침에 따라 등록 요청에 대한 전문가 검토를 요청한다.
4. 지정 전문가는 필요에 따라 추가 검토나 논의를 요청할 수 있다.
5. 전문가 검토가 등록을 권고하면, IANA는 해당 레지스트리에 등록을
추가한다.
최초 레지스트리 내용 명세 [RFC6839]는 구조화 문법 접미사 등록의
예를 제공한다.
6.1. 변경 절차
등록은 최초 등록에 필요한 것과 같은 메커니즘으로 각 레지스트리에서
갱신될 수 있다. 체계의 원래 정의가 IESG 승인 문서에 포함된 경우,
명세의 갱신도 IESG 승인을 필요로 한다.
6.2. 구조화 문법 접미사 등록 템플릿
이 템플릿은 구조화 문법 접미사 등록 요청에서 제공되어야 하는 필드를
설명한다.
이름
잘 정의된 구조화 문법의 전체 이름.
Freed 등 모범 현행 관행 [24페이지]
RFC 6838 미디어 타입 등록 2013년 1월
+suffix
문법에 부합함을 나타내는 데 사용되는 접미사.
참조
구조화 문법을 이해하는 데 필요한 모든 명세에 대한 완전한 인용을
포함한다.
인코딩 고려 사항
이 문법을 사용하는 모든 타입에 대한 인코딩 고려 사항에 관한 일반
지침은 여기에 제시되어야 한다. 제4.8절에 제시된 미디어 타입
인코딩 고려 사항에 대한 동일한 요구 사항이 여기에 적용된다.
상호운용성 고려 사항
이 구조화 문법을 사용하는 타입의 상호운용 가능한 사용과 관련된
모든 문제는 여기에 제시되어야 한다. 예로는 문법의 호환되지 않는
버전 존재, 특정 문자 집합과 문법을 결합하는 문제, 또는 다른 타입
또는 프로토콜과의 비호환성이 있다.
프래그먼트 식별자 고려 사항
이 문법을 사용하는 모든 타입에 대한 프래그먼트 식별자의 일반 처리는
여기에 설명되어야 한다.
보안 고려 사항
이 구조화 문법을 사용하는 미디어 타입들이 공유하는 보안 고려 사항은
여기에 명세되어야 한다. 제4.6절에 제시된 미디어 타입 보안 고려
사항에 대한 동일한 요구 사항이 여기에 적용되며, 단 접미사 등록에는
보안 고려 사항을 평가하지 않는 선택지가 제공되지 않는다는 예외가
있다.
연락처
추가 정보를 위해 연락할 사람(연락처 정보 포함).
작성자/변경 관리자.
이 접미사 등록을 변경할 권한이 있는 사람(연락처 정보 포함).
7. 보안 고려 사항
미디어 타입 및 미디어 타입 접미사 등록 모두에 대한 보안 요구 사항은
제4.6절에서 논의한다.
Freed 등 모범 현행 관행 [25페이지]
RFC 6838 미디어 타입 등록 2013년 1월
8. IANA 고려 사항
이 문서의 목적은 미디어 타입 및 구조화 문법 접미사를 위한 IANA
레지스트리와 이러한 레지스트리를 관리하는 절차를 정의하는 것이다.
추가로, 이 문서는 IANA가 IESG가 표준 트리의 미디어 타입 등록을
승인한 표준 관련 조직 목록을 유지할 것을 요구한다.
기존 미디어 타입 레지스트리는 임시 등록을 위한 절을 포함하도록
확장되었다. 표준 트리에서는 표준 트리 등록만 허용되며, IANA의 표준
관련 조직 목록에 있는 조직의 요청에 의한 경우에만 허용된다. 임시
등록에 관한 추가 정보는 제5.2.1절을 참조한다.
IANA는 또한 임시 레지스트리 상단에 다음 주석을 추가했다.
이 레지스트리는 일부 다른 임시 IANA 레지스트리와 달리 임시 사용만을
위한 것이다. 이 레지스트리의 항목은 최종 확정되어 주 미디어 타입
레지스트리로 이동되거나, 포기되어 삭제된다. 이 레지스트리의 항목은
개발 및 테스트 목적으로만 사용하기에 적합하다.
구조화 문법 이름 접미사 레지스트리는 다음과 같이 만들어졌다.
o 이름은 "Structured Syntax Suffix" 레지스트리이다.
o 등록 절차는 제6절에 명세되어 있다.
o 레지스트리 항목에 필요한 정보와 항목 형식은 제6.2절에
명세되어 있다.
o 레지스트리의 최초 내용은 [RFC6839]에 명세되어 있다.
미디어 타입 및 구조화 접미사 레지스트리의 항목은 IANA에 의해 원래
등록일과 해당 항목의 가장 최근 갱신일 모두로 주석 처리된다. 이 명세
구현 이전에 이루어진 등록은 필요한 경우 특정 날짜 대신 그러한
사실로 표시될 수 있다.
등록 항목은 여러 번 갱신될 수 있으므로, IANA는 또한 임의의 시점에서
등록의 상태를 확인할 수 있는 방식으로 각 등록에 대한 변경 이력을
유지한다.
Freed 등 모범 현행 관행 [26페이지]
RFC 6838 미디어 타입 등록 2013년 1월
마지막으로, 이 문서에 따라 IANA는 미디어 타입 검토 목록을 위한 새
이메일 주소 media-types@iana.org를 만들었으며, 이는 RFC 4288에
명세된 ietf-types@iana.org 주소를 대체한다. ietf-types@iana.org는
별칭으로 유지되었다.
9. 감사의 말
현재 저자들은 고(故) Jon Postel 박사에게 진 빚을 인정하고자 한다.
그의 IANA 등록 절차에 대한 일반 모델과 구체적 기여는 이 문서의
전신 [RFC2048] [RFC4288]을 형성했다. 우리는 현재 버전이 그가 동의했을
버전이기를 바라지만, 그 동의를 확인하는 것이 불가능하므로 유감스럽게도
그의 이름을 공동 저자에서 제거했다.
Randy Bush, Francis Dupont, Bjoern Hoehrmann, Barry Leiba, Murray
Kucherawy, Alexey Melnikov, S. Moonesamy, Mark Nottingham, Tom Petch,
Peter Saint-Andre, Jeni Tennison은 많은 유용한 검토 의견과 제안을
제공했다.
10. 참고 문헌
10.1. 규범적 참고 문헌
[RFC2045] Freed, N. and N. Borenstein, "다목적 인터넷
메일 확장(MIME) 제1부: 인터넷 메시지 본문의
형식", RFC 2045, 1996년 11월.
[RFC2046] Freed, N. and N. Borenstein, "다목적 인터넷
메일 확장(MIME) 제2부: 미디어 타입",
RFC 2046, 1996년 11월.
[RFC2119] Bradner, S., "RFC에서 요구 수준을 나타내기 위해
사용하는 핵심 단어", BCP 14, RFC 2119, 1997년 3월.
[RFC2978] Freed, N. and J. Postel, "IANA 문자 집합 등록
절차", BCP 19, RFC 2978, 2000년 10월.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML
미디어 타입", RFC 3023, 2001년 1월.
[RFC3629] Yergeau, F., "UTF-8, ISO 10646의 변환 형식",
STD 63, RFC 3629, 2003년 11월.
[RFC3979] Bradner, S., "IETF 기술의 지식 재산권",
BCP 79, RFC 3979, 2005년 3월.
Freed 등 모범 현행 관행 [27페이지]
RFC 6838 미디어 타입 등록 2013년 1월
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"통합 자원 식별자(URI): 일반 구문",
STD 66, RFC 3986, 2005년 1월.
[RFC4855] Casner, S., "RTP 페이로드 형식의 미디어 타입
등록", RFC 4855, 2007년 2월.
[RFC5226] Narten, T. and H. Alvestrand, "RFC에서 IANA 고려
사항 절을 작성하기 위한 지침",
BCP 26, RFC 5226, 2008년 5월.
[RFC5234] Crocker, D. and P. Overell, "구문 명세를 위한
확장 BNF: ABNF", STD 68, RFC 5234,
2008년 1월.
[RFC5378] Bradner, S. and J. Contreras, "기여자가 IETF
Trust에 제공하는 권리", BCP 78, RFC 5378,
2008년 11월.
[RFC6532] Yang, A., Steele, S., and N. Freed,
"국제화된 이메일 헤더", RFC 6532,
2012년 2월.
[RFC6657] Melnikov, A. and J. Reschke, "텍스트 미디어
타입에서 "charset" 매개변수 처리에 관한 MIME 갱신",
RFC 6657, 2012년 7월.
[RFC6839] Hansen, T. and A. Melnikov, "추가 미디어 타입
구조화 문법 접미사", RFC 6839,
2013년 1월.
10.2. 정보성 참고 문헌
[MacOSFileTypes] Apple Computer, Inc., "Mac OS: 파일 타입과
생성자 코드 및 파일 형식", Apple Knowledge
Base Article 55381, 1993년 6월,
<http://www.info.apple.com/kbnum/n55381>.
[RFC2026] Bradner, S., "인터넷 표준 절차 --
개정 3", BCP 9, RFC 2026, 1996년 10월.
[RFC2048] Freed, N., Klensin, J., and J. Postel,
"다목적 인터넷 메일 확장(MIME) 제4부:
등록 절차", BCP 13, RFC 2048,
1996년 11월.
Freed 등 모범 현행 관행 [28페이지]
RFC 6838 미디어 타입 등록 2013년 1월
[RFC2231] Freed, N. and K. Moore, "MIME 매개변수 값 및
인코딩된 단어 확장:
문자 집합, 언어 및 연속",
RFC 2231, 1997년 11월.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"하이퍼텍스트 전송 프로토콜 -- HTTP/1.1",
RFC 2616, 1999년 6월.
[RFC4288] Freed, N. and J. Klensin, "미디어 타입
명세 및 등록 절차",
BCP 13, RFC 4288, 2005년 12월.
[RFC5987] Reschke, J., "하이퍼텍스트 전송 프로토콜(HTTP)
헤더 필드 매개변수를 위한 문자 집합 및 언어 인코딩",
RFC 5987, 2010년 8월.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"애플리케이션 프로토콜에서 "X-" 접두사 및 유사
구조의 폐기", BCP 178, RFC 6648,
2012년 6월.
Freed 등 모범 현행 관행 [29페이지]
RFC 6838 미디어 타입 등록 2013년 1월
부록 A. 기득권 미디어 타입
1996년 이전에 등록된 패싯 없는 하위 타입 이름을 가진 여러 미디어
타입은 이 문서의 지침에 따라 등록되었다면 패싯 이름이 부여되어 벤더
또는 개인 트리에 배치되었을 것이다. 적절한 트리를 반영하도록 그러한
타입을 재등록하는 것은 권장되지만 필수는 아니다. 이 문서에 설명된
소유권 및 변경 제어 원칙은 그러한 타입이 위에서 설명한 트리에
등록된 것처럼 적용된다.
때때로 패싯 없는 하위 타입 이름을 가진 미디어 타입이 등록되지 않은
채 널리 배포된 경우도 있을 수 있다. (여기에는 "x-" 접두사로 시작하는
하위 타입 이름도 포함된다는 점에 유의한다.) 가능하다면 그러한
미디어 타입은 적절한 패싯 하위 타입 이름으로 재등록하는 것이 좋으며,
원래 이름을 식별하기 위해 폐기된 별칭을 사용할 수 있다(제4.2.9절
참조). 그러나 이것이 가능하지 않으면, 미디어 타입 검토자와 IESG 양쪽의
승인을 조건으로 해당 타입은 패싯 없는 이름으로 적절한 트리에 등록될
수 있다.
부록 B. RFC 4288 이후의 변경 사항
o 특정 구조화 문법의 사용을 나타내는 접미사가 이제 완전히 명세되었고
접미사 등록 절차가 정의되었다.
o 널리 배포된 미등록 패싯 없는 타입 이름을 벤더 또는 개인 트리에
등록하는 것이 이제 허용되며, 이는 미디어 타입 검토자와 IESG의
승인을 조건으로 한다.
o 표준 트리 등록 절차는 전문가 검토를 포함하도록 개정되었으며,
비-IETF 스트림 문서의 미디어 타입과 같은 경우를 다루도록
일반화되었다.
o 프래그먼트 식별자를 위한 필드가 등록 템플릿에 추가되었고,
프래그먼트 식별자 지정에 대한 간단한 지침이 추가되었다.
o 개인 트리 등록에 대한 명세 요구 사항은 벤더 트리와 동일하도록
변경되었다. 명세 이용 가능성을 권장하지만 필수로 하지는 않도록
텍스트가 변경되었다.
o 추가 트리를 정의하는 절차는 IETF 표준 조치가 필요하다고 명시하도록
명확해졌다.
o "x-" 이름을 가진 널리 배포된 타입은 이제 예외적으로 벤더 트리에
등록될 수 있다.
Freed 등 모범 현행 관행 [30페이지]
RFC 6838 미디어 타입 등록 2013년 1월
o 등록 변경에 대한 요구 사항은 사소한 변경을 더 쉽게 수행할 수 있도록
완화되었다.
o 등록 절차는 완전히 재구성되어, 표준 트리에서 IETF가 생성한 타입을
제외하고 모든 요청은 IESG가 아니라 IANA가 처리한다.
o 표준 트리에서 타입을 조기에 할당하기 위한 임시 등록 절차가
추가되었다.
o 이 문서 전반에 걸쳐 많은 편집상의 변경이 이루어져, 문서가 설명하는
요구 사항과 절차를 더 명확하고 따르기 쉽게 만들었다.
o 미디어 타입에 대해 폐기된 별칭 목록을 지정할 수 있는 기능이
추가되었다.
o "x-"로 시작하는 이름을 가진 타입은 더 이상 미등록 "x." 트리의
구성원으로 간주되지 않는다. 모든 패싯 없는 타입과 마찬가지로,
그러한 타입을 적절한 트리에 등록할 수 있도록 특별 절차가
추가되었다.
o 제3자가 등록한 타입에 대한 변경은 이제 지정된 변경 관리자가 해당
타입을 만든 벤더 또는 조직이 아니더라도 수행할 수 있다. 그러나
벤더 또는 조직은 언제든지 해당 타입에 대한 소유권과 변경 관리권을
주장하기로 선택할 수 있다.
o 제한 사용 미디어 타입은 이제 제공된, 해당 미디어 타입을 사용하는
애플리케이션 목록이 완전한지 여부를 기록하도록 요청된다.
o 미디어 타입 이름에 대한 ABNF는 이름이 영숫자 문자로 시작해야 한다는
요구를 포함하도록 더 제한되었다.
o 미디어 타입 등록 전에 메일링 리스트 검토가 더 이상 필수가 아니다.
또한 미디어 타입 검토 메일링 리스트와 관련된 주소가
media-types@iana.org로 변경되었다.
o text/* 미디어 타입에 대한 규칙은 [RFC6657]에 명세된 변경 사항을
반영하도록 갱신되었다.
Freed 등 모범 현행 관행 [31페이지]
RFC 6838 미디어 타입 등록 2013년 1월
저자 주소
Ned Freed
Oracle
800 Royal Oaks
Monrovia, CA 91016-6347
USA
이메일: ned+ietf@mrochek.com
John C. Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
이메일: john+ietf@jck.com
Tony Hansen
AT&T Laboratories
200 Laurel Ave.
Middletown, NJ 07748
USA
이메일: tony+mtsuffix@maillennium.att.com
Freed 등 모범 현행 관행 [32페이지]