인터넷 엔지니어링 태스크 포스 (IETF) N. Freed
RFC(Request for Comments): 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에 정의된 핵심 규칙을 포함하여
Augmented Backus-Naur Form(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자가 다른 주체를 대신하여 유형을 등록하는 경우, 두
주체 모두 등록의 변경 관리자 필드에 기재하는 것이 좋습니다.
가능한 형식 중 하나는 "Bar를 대신한
Foo"입니다.
공급업체 트리 등록은 선행 패싯
"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" 하위 유형을 비롯한 많은 text 하위 유형은
"charset" 매개변수를 정의합니다. 특정 text 하위 유형에
"charset" 매개변수가 정의되어 있다면, 이 매개변수는
[RFC2978]에 제시된 절차에 따라 정의된 문자 집합 이름을
지정하는 데 반드시 사용되어야 합니다.
[RFC6657]에 명시된 대로, 문자 집합 정보가 페이로드 내부에서
전달되는 경우(예: "text/xml")에는 "charset" 매개변수를
지정하지 않는 것이 좋습니다.
"charset" 매개변수가 지정된다면 필수
매개변수로 하는 것이 좋으며, 기본값을 지정하는 선택지는 제거해야 합니다.
이 조언에도 불구하고 매개변수를 선택 사항으로 해야 할
강한 이유가 있다면 각 하위 유형은 자체 기본값을
지정하거나, 또는 기본값이 없다고
지정할 수 있습니다. 마지막으로 "UTF-8" 문자 집합 [RFC3629]을
기본값으로 선택하는 것이 좋습니다. text 하위 유형과 함께
"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. 멀티파트 및 메시지 미디어 유형
multipart와 message는 복합 유형입니다. 즉,
각각 별도의 미디어 유형인 0개 이상의 객체를 캡슐화하는
수단을 제공합니다.
multipart와 message의 모든 하위 유형은 반드시 [RFC2046]에
명시되고 [RFC6532]의 제 3.5절에서 개정된 구문 규칙 및
기타 요구 사항을 준수해야 합니다.
Freed 외 현행 최선 관행 [11페이지]
RFC 6838 미디어 유형 등록 2013년 1월
4.2.7. 추가 최상위 유형
경우에 따라 새로운 미디어 유형이 현재 정의된 어떤
최상위 유형 이름에도 "맞지" 않을 수 있습니다. 이러한 경우는 매우
드물 것으로 예상됩니다. 그러나 그러한 경우가 발생하면 이를
수용하기 위한 새로운 유형 이름을 정의할 수 있습니다. 새로운 최상위 유형 이름의
정의는 반드시 표준 트랙 RFC를 통해 이루어져야 하며, 추가 유형 이름을
정의하는 데 다른 메커니즘을 사용할 수 없습니다.
4.2.8. 구조화 구문 이름 접미사
MIME의 XML [RFC3023]은 해당 미디어 유형의 기반
구조를 추가로 지정하기 위한 미디어 유형 정의의
첫 번째 확장을 정의했습니다. 이를 인용하면 다음과 같습니다.
이 문서는 미디어 유형이
XML MIME(다목적 인터넷 메일 확장)
엔터티를 나타낼 때 미디어 유형 이름을 지정하는 규약
('+xml' 접미사 사용)도 표준화합니다.
즉, 기본 하위 유형 이름 뒤에 붙이는
접미사(이 경우 "+xml")를 지정했습니다.
이것이 게시된 이후 다른 잘 알려진 구조화 구문에도
이 접미사 규약을 사용하는 사실상의 관행이 생겨났습니다.
특히 "+der", "+fastinfoset", "+json" 같은 접미사를 가진
미디어 유형이 등록되었습니다. 이 명세는
이러한 관행을 공식화하고 구조화 유형 이름
접미사를 위한 레지스트리를 설정합니다.
구조화 유형 이름 접미사를 등록할 수 있는지 판단하는 주요 지침은
쉽게 이용할 수 있는 설명에 의해 기술되어 있고,
가급적 확립된 표준 관련 조직이 게시한 문서에 포함되어 있으며,
RFC의 규범적 참고 문헌 절에서 사용할 수 있는
참조가 존재해야 한다는 것입니다.
명명된 구조화 구문을 사용하는 미디어 유형은 등록할 때 해당
구조화 구문에 적합한 등록된 "+suffix"를 사용하는 것이 좋습니다.
마찬가지로 실제로 사용하지 않는 구조화 구문의 접미사를
포함하는 이름을 미디어 유형에 부여해서는 안 됩니다.
아직 등록되지 않은 구조화 구문에 대한 "+suffix" 구성은
향후 접미사 정의와 충돌할 가능성이 있으므로
사용하지 않는 것이 좋습니다.
Freed 외 현행 최선 관행 [12페이지]
RFC 6838 미디어 유형 등록 2013년 1월
4.2.9. 폐기된 별칭
경우에 따라 하나의 미디어 유형이 등록 전에 여러 이름으로
널리 배포되었을 수 있습니다. 이런 경우 해당 미디어 유형에 대해
선호 이름을 반드시 선택해야 하며, 애플리케이션은
유형 등록을 준수하기 위해 반드시 이 이름을 사용해야 합니다. 그러나
애플리케이션이 미디어 유형을 올바르게 처리하도록 돕기 위해
해당 유형에 알려져 있는 폐기된 별칭 목록을
추가 정보로 제공할 수 있습니다.
4.3. 매개변수 요구 사항
미디어 유형은 하나 이상의 미디어 유형 매개변수를 사용하도록 선택할 수
있으며, 또는 모든 하위 유형에 적용되는 매개변수 집합을 정의하는
콘텐츠 유형의 하위 유형이라는 이유로 일부 매개변수가 해당 미디어 유형에서
자동으로 사용 가능해질 수 있습니다. 어느 경우든
미디어 유형이 표준 트리에 등록될 때 모든 매개변수의
이름, 값 및 의미를 반드시 완전히 명세해야 하며,
미디어 유형이 공급업체 또는 개인 트리에 등록될 때는
가능한 한 완전하게 명세하는 것이 좋습니다.
매개변수 이름은 미디어 유형 이름 및 값과 같은 구문을 사용합니다.
parameter-name = restricted-name
이 구문은 [RFC2045]에 있으며 [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. 인코딩 요구 사항
일부 전송 방식은 운반할 수 있는 데이터 유형에
제한을 부과합니다. 예를 들어 인터넷 메일은 전통적으로 7bit
US-ASCII 텍스트로 제한되었습니다. 이러한 전송 제한을
우회하기 위해 인코딩 방식이 자주 사용됩니다.
Freed 외 현행 최선 관행 [16페이지]
RFC 6838 미디어 유형 등록 2013년 1월
따라서 등록의 일부로 미디어 유형이 어떤 종류의 데이터로
구성될 수 있는지 명시하는 것이 유용합니다. 이를 위해 "인코딩 고려 사항"
필드가 제공됩니다. 이 필드에 가능한 값은
다음과 같습니다.
7bit: 미디어 유형의 콘텐츠는 CRLF로
구분된 7bit US-ASCII 텍스트로만 구성됩니다.
8bit: 미디어 유형의 콘텐츠는 CRLF로
구분된 8bit 텍스트로만 구성됩니다.
binary: 콘텐츠는 제한 없는 옥텟 시퀀스로 구성됩니다.
framed: 콘텐츠는 내부 프레이밍 또는 정렬 표시가 없는
일련의 프레임이나 패킷으로 구성됩니다. 데이터를 올바르게
해석하려면 연속된 프레임 간의 경계에 대한 지식과
전송 메커니즘에 대한 지식을 포함하되 이에 한정되지 않는
추가적인 대역 외 정보가 필요합니다.
이런 종류의 미디어 유형은 단순히 파일에 저장하거나
단순한 옥텟 스트림으로 전송할 수 없으므로,
많은 전통적인 프로토콜에서 사용하기에 적합하지 않습니다.
프레임 인코딩에 일반적으로 사용되는 전송 방식은
실시간 전송 프로토콜(RTP)입니다. RTP를 사용한 전송을 위해
정의된 프레임 인코딩의 추가 규칙은
[RFC4855]에 제시되어 있습니다.
7bit 및 8bit 텍스트에 대한 추가 제한은 [RFC2046]의
제4.1.1절에 제시되어 있습니다.
4.9. 사용 및 구현 비요구 사항
원격 메일 에이전트의 기능에 관한 정보를 발신자가
자주 알 수 없는 비동기 메일 환경에서는 널리
구현될 것으로 예상되는 "일반적인" 형식으로 사용하는 미디어 유형을
제한함으로써 최대 상호 운용성을 얻을 수 있습니다.
과거에는 이것이 가능한 미디어 유형의 수를 제한해야 하는
이유로 제시되었고, 그 결과 미디어 유형을 등록하려는 사람에게
상당한 장벽과 지연을 초래하는 등록 절차가
만들어졌습니다.
그러나 "일반적인" 미디어 유형이 필요하다고 해서 새로운 미디어 유형의
등록을 제한할 필요는 없습니다. 특정 애플리케이션에 대해 제한된
미디어 유형 집합을 권고하려면 애플리케이션 및/또는 환경에
특정한 별도의 적용 가능성 기술서에서
이를 명시해야 합니다.
따라서 미디어 유형의 보편적인 지원 및 구현은
등록의 요구 사항이 아닙니다. 그러나 미디어 유형이
Freed 외 현행 최선 관행 [17페이지]
RFC 6838 미디어 유형 등록 2013년 1월
제한적으로 사용하도록 명시적으로 의도되었다면 등록에
반드시 이를 명시해야 합니다. 이를 위해 "사용 제한" 필드가
제공됩니다.
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 절차를
따라야 합니다. Internet Draft 게시가
필요한 첫 번째 단계이며, 그 다음 아래에서 설명하는 대로
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.org의 IANA에 제출할 수 있습니다. 이러한 의견은
미디어 유형 검토자가 검토한 다음 가능하면
미디어 유형의 "소유자"에게 전달됩니다. 의견 제출자는 자신의
의견을 미디어 유형 등록 자체에 첨부하도록 요청할 수 있으며,
IANA가 미디어 유형 검토자와 협의하여 승인하면
해당 의견을 유형 등록과 함께
접근 가능하게 합니다.
5.5. 변경 절차
미디어 유형이 IANA에 의해 게시된 후에는 소유자가
그 정의의 변경을 요청할 수 있습니다. 위의 각기 다른 등록 트리에
대한 설명은 각 등록 유형의 "소유자"를
지정합니다. 변경 요청을 처리할 때는 원래 등록 요청에
적합했던 것과 동일한 절차를
사용합니다.
미디어 유형 등록은 삭제할 수 없습니다. 더 이상 사용하기에
적절하지 않다고 판단되는 미디어 유형은 "의도된 사용" 필드를
변경하여 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절에 명시됨)을 작성하고 미디어 유형 등록과
함께 포함합니다. 템플릿은 Internet Draft에
단독으로 또는 다른 프로토콜 명세의 일부로
포함될 수 있습니다. 템플릿은 다른 형식
(다른 문서의 일부 또는 독립 문서)으로 제출할 수도 있지만,
그 내용은 BCP 78 [RFC5378]의 지침에 따라
"IETF 기여물"로 취급됩니다.
3. 템플릿 사본이나 템플릿이 포함된 문서를 가리키는
포인터(템플릿이 있는 절을 구체적으로 참조)를
media-types@iana.org 메일링 리스트로 보내 검토를 요청합니다.
Freed 외 현행 최선 관행 [23페이지]
RFC 6838 미디어 유형 등록 2013년 1월
이는 미디어 유형 등록 검토 요청과 결합할 수 있습니다.
논의와 의견을 위한 합리적인 시간을
허용합니다.
4. 검토 의견에 응답하고 제안된 등록이
이 문서에 제시된 지침에 부합하도록 필요한 경우
수정합니다.
5. (필요한 경우 갱신된) 등록 템플릿(또는 이를 포함하는
문서에 대한 포인터)을 iana@iana.org의 IANA에 제출합니다.
구조화 구문 접미사 등록 요청을 받으면,
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 이름은 "구조화 구문 접미사" 레지스트리입니다.
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. 감사의 말
현재 저자들은 IANA 등록 절차의 일반적인 모델과
구체적인 기여를 통해 이 문서의 전신인
[RFC2048] [RFC4288]을 형성한 고(故)
Jon Postel 박사에게 감사의 빚을 지고 있음을 밝히고자 합니다.
현재 버전이 그가 동의했을 만한 것이기를 바라지만,
그 동의를 확인할 수 없으므로 유감스럽게도
공동 저자에서 그의 이름을 삭제했습니다.
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페이지]