組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：王俊麗（王小毛   wangjunli_1029@163.net）
譯文發布時間：2001-9-10
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。




Network Working Group                                          J. Postel
Request for Comments: 1590                                           ISI
Updates: 1521                                                 March 1994
Category: Informational                   

多媒體類型注冊過程
(RFC 1590 ——Media Type Registration Procedure)

目錄
本文的地位：	2
摘要	2
1． 介紹	2
2. 媒體注冊類型過程	3
2.1. 提出注冊社團的要求	3
2.2. 注冊時向IANA提交內容類型	3
3. 具體問題的聲明	3
3.1. MIME要求有限的內容-類型	3
3.2. 印刷規格的要求	4
3.3. 安全考慮確定	4
3.4. 推薦和標準作用	4
4. 安全考慮	4
5. 致謝	4
6. 作者地址	5
7．參考資料	5
附錄 A IANA媒體類型注冊過程	5

本文的地位：
  本文提供了因特網通信信息，它并不是任何因特網的標準，本文的分布是不受限制的。
摘要
   在一些協議中允許用數據來代表不同的“媒體”，例如，文本、圖像、音頻、視頻，而且
還可以用數據表達這些媒體中不同的編碼格式，例如（在視頻中）jpeg，gif，ief和tiff。在
多媒體網際信息擴充協議（MIME）[1]中，定義了一些多媒體數據對象的初始類型和使用因
特網安排數字權威（IANA）來注冊附加類型的過程。在注冊MIME內容-類型和子類型的
要求和管理過程中，和媒體類型的其它應用中存在著一些問題。本文提出了這些問題，并具
體講了新媒體類型（內容-類型/子類型）注冊的過程。而且，本文也總結了這些媒體類型的
應用范圍，使得它在其它應用中可以用到相同的的注冊和規格。
1． 介紹
RFC1521[1]中定義了用MIME來注冊新數據類型的過程。設計注冊機制是為了對給定的
數據類型加以驗證，而且為了防止命名的沖突。隨著新的多媒體協議和存取機制的發展，這
一過程有望為因特網協議形成一個通用的注冊服務。這些類型以前被稱為“MIME”類型，現
在我們稱它們為“媒體類型”。
媒體類型（內容-類型/子類型）注冊過程最初在匿名郵件環境中被定義，在這一郵件環
境中，當遠程的郵件系統能力不為所知時，為了增加協同能力，有必要限制媒體類型的數量。
當媒體類型應用于新的環境，而且在這一環境中媒體類型的增加不會阻礙協同能力時，原始
過程應當受到極度限制，而且必須是通用的。
本文提出了產生的具體問題，而且就媒體類型注冊提供了一個管理過程。而且這一過程
也提出了將用到X.400MHS中的對象標識符（OIDs）映射為媒體類型所需的注冊要求。
2. 媒體注冊類型過程
以下是IANA用來復查和認可新媒體類型的過程。這并不是一個正式的標準過程，而是
一個在沒有十分超時的情況下允許團體發表評論和理智檢核的管理過程。
2.1. 提出注冊社團的要求
發送一個被提議的媒體類型（內容-類型/子類型）到“ietf-types@cs.utk.edu”郵件
列表中。郵件列表建立的唯一目的是復查被提議的媒體類型，被提議的內容-類型并未被正
式注冊，它必須用“X-”標記子類型名。
公眾張貼的目的是在于獲得關于內容-類型/子類型名字選擇的評論和反饋，關于版本和
外部輪廓信息的明確參考資料，選擇哪種OIDs和安全部分復查。需要說明的一點時，提出
的媒體類型不必對于每種可能的應用都有意義。如果媒體類型是有有限的或者是具體的用
途，那么它在提交是應當加以標注。
2.2. 注冊時向IANA提交內容類型
兩周后，向IANA提交提出的媒體類型以便注冊。請求和支持文檔發到iana@isi.edu，經
過一段復查時期，IANA將注冊媒體類型，在IANA分支中安排一個OID，并使這個媒體類型
注冊可行。
媒體類型注冊將記入匿名FTP錄，ftp.isi.edu:in notes/media-types，媒體類型將列在定期
出版的“Assigned Numbers”RFC[2]中。媒體類型描述可能印刷為信息RFC，通過將它發送
到“rfc-editor@isi.edu”(請遵照RFC作者[3]的指導)
3. 具體問題的聲明 
3.1. MIME要求有限的內容-類型
問題: 在異步郵件環境中,發送者對遠程的郵件代理能力的信息不可知,最大的協同能
力的獲取可通過限制那些期望被廣泛應用的“普通”內容-類型的數量。這就是限制可能的
內容-類型的原因，這樣導致了在注冊過程中，注冊內容-類型的明顯阻礙耽擱。
評論： “普通”內容-類型格式的需求不要求限制新的內容-類型注冊。實際上這一限
制可能導致由具體問題中分散的注冊而引起的阻礙協同能力。如果一套有限的內容類型被推
薦為特殊應用，那么這應當被應用或環境具體化分離應用聲明而證實。
3.2. 印刷規格的要求
問題： 內容-類型注冊要求一個RFC來具體化數據格式或者是一個印刷的數據流規格的
參考。因為共有的規格對大量廣泛應用和交換的對象是不可行的，所以在用內容-類型注冊
的文件附屬和分布時，這一要求可能是過于受限制了。
評論： MIME要求一個具體的內容-類型文件以便于清楚地確定一個一定義的類型。在
注冊內容-類型時，通過確定一個特定的軟件包和版本，這一目的可以被滿足，而且在注冊
中也是允許的。在一個不可用的規格中適當應用媒體類型應當在注冊中不成問題。
3.3. 安全考慮確定
　　 問題： 注冊過程要求任何與內容-類型相關的已知安全問題的確定。
     評論： 雖然并不要求內容-類型的安全或免于冒險。但是，已知的冒險應當是被確定
的。內容-類型的公眾并不要求徹底的安全檢查，而且安全部分從屬于連接評估。附加的安
全考慮應當由IANA在RFC上定期公布。
3.4. 推薦和標準作用
問題： 數據類型注冊用不著IANA或IETF的贊同或推薦，甚至不必證明規格是足夠
的。
評論：為了成為因特網的標準，協議、數據對象或者其它的，都必須通過IETF標準過
程，這一過程對注冊媒體類型的便利和實際需要來說實在是太難而且也是太長了。所以就希
望時不時的發行一些特定用途的陳述，以此來支持那些被證明特別有用的數據類型。
4. 安全考慮
本文并未提出具體的安全問題，而是概括了一個媒體類型的安全檢查過程。
5. 致謝
在本RFC中大多數是John Klensin和Greg raudreuil-編寫，我所作的工作只是修改了一
些句子，刪除了某些短語，重新安排了一些段落。也就說，對于所有不好的思想或是有損的
句子，我都是有責任的，而他們對于所有好的思想都是有貢獻的。
6. 作者地址
   Jon Postel   
   USC/Information Sciences Institute
   4676 Admiralty Way 
   Marina del Rey, CA  90292
   Phone: 310-822-1511
   Fax:   310-823-6714
   EMail: Postel@ISI.EDU7. 
7．參考資料
    [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail
       Extensions) Part One:  Mechanisms for Specifying and Describing
       the Format of Internet Message Bodies", RFC 1521, Bellcore,
       Innosoft, September 1993.
   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.
   [3] Postel,J., "Instructions to RFC Authors", RFC 1543,
       USC/Information Sciences Institute, October 1993.

附錄 A IANA媒體類型注冊過程
MIME已經被設計為有擴展機制的，而且希望隨著時間的增加，內容-類型/子類型對集
合和他們對應的參數將不斷增加。一些其它的MIME領域，顯著特征集合，消息外部類型
的存取-類型參數，和可能的內容-轉換-編碼值，都可能有新的定義值。
總之，內容-類型頭文件中的參數是用來向不同內容類型傳遞補充，而且當內容-類型和
子類型定義好時，它們的用途也就被定義了。新參數不應當被定義作介紹新功能的一個方法。
為了便于內容-類型和子類型（媒體類型）的旨在一種有序的，規格的，公開的狀態下發展，
MIME和其它應用對本RFC中定義的媒體類型應用注冊過程，它是以IANA作為這些數據
的中心注冊處。
為了簡化和標準化媒體注冊過程，本附錄給出向IANA新值注冊的模板。每個是以郵件
消息模板形式給定，在注冊是添入。
新內容-類型/子類型值的注冊：
注意總體上期望MIME由子類型來擴展，如果需要一個新的基礎高-水平類型，他的規
格必須公開為一個RFC或者是以一個RFC適當形式提高，而且它是屬于因特網標準過程。
RFC1590——Media Type Registration Procedure                                  多媒體類型注冊過程
1

5
ＲＦＣ文檔中文翻譯計劃