Đăng ký thành viên của một loại Media Type hoặc các loại bắt đầu với việc xây dựng một đề nghị đăng ký. Đăng ký có thể xảy ra tại cây đăng ký (Registration trees) khác nhau, trong đó có những yêu cầu khác nhau như được thảo luận dưới đây. Nhìn chung, đề nghị đăng ký mới được lưu thông và xem xét trong một thời trang phù hợp với cây có liên quan. Các Media-Type sau đó sẽ được đăng ký nếu đề nghị được chấp nhận. Những phần sau mô tả các yêu cầu và thủ tục được sử dụng cho mỗi cây đăng ký khác nhau.
3.3.4.1.1 Đăng ký Cây (Tree) và Subtype Names
Để nâng cao hiệu quả và linh hoạt của quá trình đăng ký, các cấu trúc khác nhau của các tên subtype có thể đăng ký theo các yêu cầu khác. Ví dụ như, một subtype sẽ được đề nghị hỗ trợ rộng và thực hiện bởi các cộng đồng Internet hay subtype được sử dụng để di chuyển các tập tin liên quan đến phần mềm độc quyền. Các
phần phụ sau xác định đăng ký "cây", phân biệt bởi việc sử dụng các tên mặt (ví dụ, tên của các hình thức "tree.subtree ... type").
1. Cây IETF: là dành cho các loại lợi ích chung cho cộng đồng Internet. Đăng ký thành viên trong cây IETF là chấp thuận yêu cầu của IESG và xuất bản của việc đăng ký Media-Types như một số hình thức của RFC.
2. Cây Vendor: được sử dụng cho các Media-Types liên kết với các sản phẩm thương mại. "Vendor" hay "Producer" được hiểu như tương đương và rất rộng rãi trong ngữ cảnh này.
3. Cây Personal hoặc Vanity: Đăng ký cho các Media-Types được tạo thử nghiệm hoặc là một phần của sản phẩm không được phân phối thương mại có thể được đăng ký tại các Cây Personal hoặc Vanity. Việc đăng ký được phân biệt bởi các mặt hàng đầu "prs.".
4. Cây đặc biệt ‘x.’: Để thuận tiện và đối xứng với sơ đồ đăng ký, tên Media- tyes với "x." được sử dụng cho mục đích đó mà tên bắt đầu bằng "x-" thường được áp dụng. Những loại là chưa đăng ký, thử nghiệm, và nên được sử dụng chỉ với những thỏa thuận hoạt động của các bên trao đổi chúng.
3.3.4.1.2 Yêu cầu đăng ký
1. Yêu cầu chức năng:
Các Media-Types phải có chức năng như một định dạng Media-Type thực tế: Đăng ký thành viên của những thứ như là một bảng mã chuyển nhượng, một tập ký tự, hoặc là một bộ sưu tập của các thực thể riêng biệt trong các loại hình khác, là không được phép. Ví dụ, mặc dù các ứng dụng tồn tại để giải mã các mã hóa base64 [RFC 2045], base64 không thể đăng ký như là một Media-Type.
Yêu cầu này áp dụng với mọi cây đăng ký 2. Yêu cầu đặt tên:
Tất cả các Media-Type được đăng ký phải được gán với loại MIME và subtype name. Sự kết hợp của các ‘name’ này sau đó phục vụ để nhận diện các loại Media- Type và định dạng của tên subtype xác định cây đăng ký.
Yêu cầu này áp dụng với mọi cây đăng ký 3. Yêu cầu tham số:
Các loại phương Media-type có thể chọn để sử dụng một hoặc nhiều tham số định dạng MIME, hoặc một số tham số có thể được tự động tạo sẵn cho các loại Media- type. Trong cả hai trường hợp, tên, giá trị, và ý nghĩa của bất kỳ thông số phải được hoàn toàn xác định khi một Media-type được đăng ký trong cây IETF, và cần được xác định là hoàn toàn nhất có thể khi các loại phương tiện truyền thông đăng ký tại các cây Vendor hoặc Personal.
4. Yêu cầu an ninh:
Một phân tích của các vấn đề an ninh là cần thiết cho tất cả các kiểu đăng ký tại các cây IETF. (Điều này là phù hợp với các yêu cầu cơ bản cho tất cả các giao thức IETF) Một phân tích tương tự cho Media-Type đăng ký tại các cây Vendor hoặc Personal. Khuyến khích nhưng không bắt buộc. Tuy nhiên, bất kể những gì phân tích an ninh đã hoặc chưa được thực hiện, tất cả các mô tả về các vấn đề an ninh phải được là chính xác nhất có thể đăng ký bất kể loại cây. In particular, a statement that there are "no security issues associated with this type" must not be confused with "the security issues associates with this type have not been assessed". Trong đó, một tuyên bố rằng có "không có vấn đề bảo mật liên kết với ‘this type’" không phải là nhầm lẫn với " những vấn đề an ninh liên quan đến kiểu này không được đánh giá".
5. Yêu cầu xuất bản:
Đề xuất cho các Media-TYpe đăng ký trong cây IETF phải được công bố như là RFC. RFC công bố của Vendor và Media-type đề nghị cá nhân được khuyến khích nhưng không bắt buộc. Trong mọi trường hợp IANA sẽ giữ được bản sao của tất cả
các đề xuất Media-type và "publish" chúng như là một phần của cây đăng ký Media-type đó.
3.3.4.1.3 Thủ tục đăng ký
Thủ tục sau đây đã được thực hiện bởi các IANA để xem xét và phê duyệt các loại phương tiện truyền thông mới. Đây không phải là một tiêu chuẩn chính, mà là một thủ tục hành chính nhằm cho phép cộng đồng nhận xét và kiểm tra sanity không chậm trễ thời gian quá nhiều. Đối với đăng ký trong cây IETF, các quá trình IETF bình thường nên được theo sau. Để đăng ký tại các cây Vendor hoặc Personal, bước xem xét ban đầu được mô tả dưới đây có thể được bỏ qua và các loại hình đăng ký trực tiếp bằng cách gửi mẫu và giải thích tới ANA.
3.3.4.2 External Body Access Types 3.3.4.2.1 Yêu cầu đăng ký
Bao gồm các thành phần - Yêu cầu đặt tên - Yêu cầu kỹ thuật - Yêu cầu xuất bản - Yêu cầu an ninh 3.3.4.2.2 Thủ tục đăng ký
Bao gồm các thành phần:
- Loại truy cập cộng động - Loại truy cập Reviewer - IANA đăng ký
3.3.4.3 Chuyển bảng mã
Chuyển bảng mã được sử dụng cho các mục đích sau:
1. Nhiều Transports, đặc biệt là Transports tin nhắn, chỉ có thể xử lý dữ liệu bao gồm các dòng tương đối ngắn của văn bản. Hiện cũng có thể được hạn chế nghiêm trọng về những gì các ký tự có thể được sử dụng trong những dòng văn bản - một Transports đang bị giới hạn đến một tập hợp con nhỏ bảng mã US-ASCII và những ngoài ra không thể xử lý chuỗi ký tự nào đó. Chuyển mã hóa được sử dụng để biến đổi dữ liệu nhị phân thành dạng văn bản transport.
2. Hình ảnh, âm thanh, video và các thực thể ứng dụng đôi khi có dung lượng quá lớn Thuật toán nén thường có hiệu quả trong việc giảm kích thước của các thực thể lớn.
3. Mã hóa Transports có thể được định nghĩa như là một phương tiện đại diện cho các định dạng mã hóa trong một bối cảnh MIME.
3.3 Giao thức truyền tin NNTP