Właściwy typ nośnika MIME dla plików PDF

Jest to konwencja zdefiniowana w RFC 2045-Multipurpose Internet Mail Extensions (MIME) część pierwsza: Format treści wiadomości internetowych.

1. Prywatne [Podtyp] można zdefiniować wartości (zaczynające się od "X-") dwustronnie pomiędzy dwoma współpracującymi agentami bez poza rejestracją lub standaryzacją. Takie wartości nie może być zarejestrowany ani ustandaryzowany.

2. Nowe wartości standardowe powinny być zarejestrowane w IANA zgodnie z opisem w RFC 2048.

Podobne ograniczenie dotyczy typu najwyższego poziomu. Z tego samego źródła,

Jeśli z jakiegoś powodu ma być używany inny typ najwyższego poziomu, musi być podano nazwę zaczynającą się od " X -", aby wskazać jej Niestandardowy status i aby uniknąć potencjalnego konfliktu z przyszłą oficjalną nazwą.

(Należy zauważyć, że w RFC 2045, "[m]atching typu i podtypu nośnika jest zawsze niewrażliwe na wielkość liter", więc nie ma różnicy między interpretacja "X -" i " x -".)

Można więc zgadnąć, że "application/x-foo" zostało użyte przed zdefiniowaniem przez IANA "application/foo". I nadal może być używany przez ludzi, którzy nie są świadomi przydziału tokena IANA.

Jak powiedział Chris Hanson typy MIME są kontrolowane przez IANA. Jest to opisane w RFC 2048-Multipurpose Internet Mail Extensions (MIME) Część czwarta: procedury rejestracji . Według RFC 3778 , który jest cytowany przez IANA jako definicja "aplikacji / pdf",

Typ aplikacji / pdf media został po raz pierwszy zarejestrowany w 1993 roku przez Paula Lindnera do użytku przez protokół gopher; rejestracja została następnie zaktualizowana w 1994 roku przez Steve ' a Zillesa.

Typ "application / pdf" istnieje od ponad dekady. Wydaje mi się więc, że wszędzie tam, gdzie "application/x-pdf" został użyty w nowych aplikacjach, decyzja mogła nie być celowa.

Z rodzaju mediów Wikipedii,

Typ nośnika składa się z typu, podtypu i opcjonalnego parametry. Jako przykład, plik HTML może być oznaczony text / html; charset = UTF-8.

Typ nośnika składa się z nazwy typu najwyższego poziomu i nazwy podtypu, która jest dalej ułożone w tzw. "drzewa".

top-level type name / subtype name [ ; parameters ]

top-level type name / [ tree. ] subtype name [ +suffix ] [ ; parameters ]

Wszystkie typy nośników powinny być rejestrowane przy użyciu procedur rejestracji IANA. Obecnie tworzone są następujące drzewa: standard, vendor, personal lub vanity, niezarejestrowany x.

Standard:

Typy nośników w drzewie standardów nie używają żadnego aspektu drzewa (prefiksu).

type / media type name [+suffix]

Sprzedawca:

Drzewo dostawców jest używane dla typów nośników powiązanych z publicznie dostępnymi produkty. Używa vnd. aspekt.

type / vnd. media type name [+suffix] - used in the case of well-known producer

type / vnd. producer's name followed by media type name [+suffix] - producer's name must be approved by IANA

type / vnd. producer's name followed by product's name [+suffix] - producer's name must be approved by IANA

Drzewo osobiste lub próżność:

Osobiste lub Drzewko próżności zawiera typy multimediów tworzone eksperymentalnie lub jako część produktów, które nie są dystrybuowane komercyjnie. Wykorzystuje prs. facet.

type / prs. media type name [+suffix]

Niezarejestrowane x. tree:

Drzewo "x." może być używane dla typów nośników przeznaczonych wyłącznie do użytku w środowiskach prywatnych, lokalnych i tylko za aktywną zgodą strony je wymieniają. Typy w tym drzewie nie mogą być rejestrowane.

Zgodnie z poprzednią wersją RFC 6838-2048 (opublikowany w listopadzie 1996) rzadko, jeśli w ogóle, powinno być konieczne używać niezarejestrowanych typów eksperymentalnych, a jako takie stosowanie zarówno " x-" i formularzy" x. " zniechęca . Poprzednie wersje tego RFC-RFC 1590 i RFC 1521 stwierdzono, że użycie notacji "x -" dla nazwa podtypu może być używana dla podtypów niezarejestrowanych i prywatnych, ale zalecenie to zostało wycofane w listopadzie 1996 roku.

type / x. media type name [+suffix]

Jest więc jasne, że standard typ MIME typ application/pdf jest odpowiedni do użycia, podczas gdy należy unikać używania przestarzałego i niezarejestrowanego typu x-, jak podano w RFC 2048 i RFC 6838 .