Специфікація MIME
MIME (Multipurpose Internet Mail Extension)
У певному сенсі стандарт MIME ортогонален стандарту RFC822. Якщо останній докладно описує в заголовку поштового повідомлення текстове тіло листи і механізм його розсилки, то MIME, головним чином, зорієнтований на опис в заголовку листа структури тіла поштового повідомлення і можливості складання листа з інформаційних одиниць різних типів.
У стандарті зарезервовано кілька способів подання різнорідної інформації. Для цієї мети використовуються спеціальні поля заголовка поштового повідомлення:- поле версії MIME, яке використовується для ідентифікації повідомлення, підготовленого в новому стандарті;
- поле опису типу інформації в тексті листа, яке дозволяє забезпечити правильну інтерпретації даних;
- поле типу кодування інформації в тексті листа, що вказує на тип процедури декодування;
- два додаткових поля, зарезервованих для більш детального опису тіла повідомлення.
Стандарт MIME розроблений як розширюється специфікація, в якій мається на увазі, що число типів даних буде рости в міру розвитку форм представлення даних. При цьому слід враховувати, що анархія типів (безмежне їх збільшення) теж не припустима. Кожен новий тип в обов'язковому порядку повинен бути зареєстрований в IANA (Internet Assigned Numbers Authority). Зупинимося докладніше на формі і призначення полів, обумовлених стандартом.
Поле типу кодування поштового повідомлення (Content-Transfer-Encoding).
Багато дані передаються по пошті в їх початковому вигляді. Це можуть бути 7bit символи, 8bit символи, 64base символи і т.п. Однак при роботі в різнорідних поштових середовищах необхідно визначити механізм їх подання в стандартному вигляді - US-ASCII. Для цього існують процедури кодування такого сорту даних. Найбільш широко застосовувана - uuencode. Для того, щоб при отриманні дані були б правильно розпаковані і введено в стандарт поле "Сontent-Transfer-Encoding". Синтаксис цього поля наступний:
Поле версії MIME (MIME-Version)
Поле версії вказується в заголовку поштового повідомлення і дозволяє визначити програму розсилки пошти, що повідомлення підготовлено в стандарті MIME. Формат поля виглядає як:
Поле версії вказується в загальному заголовку поштового повідомлення і відноситься до всього повідомленням цілком. Тут доречно зазначити, що на відміну від стандарту RFC822, стандарт MIME дозволяє перемішувати поля заголовка повідомлення з тілом повідомлення. Тому все поля діляться на два класи: загальні поля заголовка, які записуються на початку поштового повідомлення і приватні поля заголовка, які відносяться тільки до окремих частин складеного повідомлення і записуються перед ними.
Поле типу змісту тіла поштового повідомлення (Content-Type)
Зупинимося докладніше на кожному з типів, дозволених стандартом MIME.
"Richtext" визначає текст з вбудованими в нього спеціальними керуючими послідовностями, які відповідно до стандарту мови розмітки документів SGML називаються тегами. Таги вдають із себе послідовність символів типу "<строка-символов>"." Рядок-символів "визначає котра управляє вплив. Таги діляться на таги початку елемента тексту ("<.>") І теги кінця елемента тексту (""). Як приклад такої розмітки можна навести такий фрагмент тексту:
У цьому фрагменті
"Multipart".
Цей тип змісту тіла поштового повідомлення визначає змішаний документ. Змішаний документ може складатися з фрагментів даних різного типу. Даний тип має ряд підтипів.
Підтип "mixed" - задає повідомлення, що складається з декількох фрагментів, які розділені між собою кордоном, що задається як параметр підтипу. Наведемо простий приклад:
Підтип "digest" призначений для багатоцільового поштового повідомлення, коли різним частинам хочуть приписати більш детальну інформацію, ніж просто тип:
Наведений приклад показує як можна скористатися підтипом "digest" для розсилки пошти різним користувачам і по-різному приводу, використовуючи поля "From:" і "Subject" в якості приватних заголовків.
Тип "message".
Даний тип призначений для роботи зі звичайними поштовими повідомленнями, які проте не можуть бути передані поштою по різного роду причин. Ці причини пояснюються підтипами даного типу.
Підтип "partial" призначений для передачі одного великого повідомлення по частинам для подальшої автоматичної збірки у одержувача.
Цей механізм може стати в нагоді, коли проміжні поштові шлюзи обмежують індивідуальний розмір пересилаються листів. Т.ч. цей підтип говорить про те, що лист містить лише частина великого послання.
- "Id" - унікальний ідентифікатор, що дозволяє виявити інші частини послання.
- "Number" - ціле число, що означає номер частини послання.
- "Total" - ціле число, що означає загальну кількість частин. Потрібно лише в останній частині і не обов'язковий (хоча рекомендується) для попередніх частин. Ці параметри можуть слідувати в довільному порядку.
- Всі поля заголовка частини 1, крім починаються з "Content-" і спеціальних "Message-ID", "Encrypted" і "MIME-Version" повинні бути скопійовані в заголовок нового (загального) листи.
- Тільки поля заголовка вкладення листа, що починаються з "Content-", а також поля "Message-ID", "Encrypted" і "MIME-Version", повинні бути додані до заголовку нового спільного листа, всі інші поля повинні ігноруватися
- Заголовки другої і наступних частин цілком ігноруються.
Зауваження з кодування тіла MIME-листи, укладеного всередині тіла message / partial: так як дані типу "message" ніколи не можуть бути кодовані в Base64 або Quoted-Printable, наступна проблема може виникнути в разі, якщо тіла листів типу message / partial створені в системі, яка підтримує 8-бітний транспорт. Двійкові дані будуть розбиті на декілька message / partial-об'єктів, кожному з яких потрібно транспортування в двійковому вигляді. Якби таких об'єктів довелося пройти через шлюз в 7-бітну транспортну середу, їх неможливо було б перекодувати в сеімбітную форму без очікування прибуття всіх частин послання, збирання їх воєдино і потім кодування цілого послання в 7-бітну систему кодування (base64 або quoted-printable) . Поскльку існує ймовірність, що різні частини підуть різними шляхами (через різні шлюзи), то подібне рішення не типово. Тому MIME визначає, що листи типу message / partial повинні мати 7-бітну систему кодування і відповідне їй значення поля content-transfer-encoding. Навіть для систем з транспортом, що підтримує "8-біт" і "binary", забороняється їх використання для даних message / partial.
Багато поштові агенти можуть автоматично фрагментировать великі листи.
Включення поля "References" в заголовки другої і наступних частин, що посилається на ідентифікатор попередній частині, може виявитися корисним для поштових програм, які розуміють і обробних посилання. Однак, наявність цього поля не обов'язково.
Поле заголовка "Encrypted" вийшло з ужитку, але вищенаведені правила забезпечують коректну його інтерпретацію, якщо воно зустрічається при обробці фрагментів типу message / partial. Наведемо приклад передачі аудіо повідомлення розбитого на частини:
Атрибути підтипу визначають ідентифікатор повідомлення (id), номер порції (number) і загальне число порцій (total). Слід звернути увагу на те, що кожна частина має своє поле "Content-Type". Це означає, що всі повідомлення може складатися з частин різних типів.
Іншим підтипом є "External-Body", який дозволяє посилатися на зовнішні, щодо повідомлення, інформаційні джерела. Цей підтип схожий на гіпертекстове посилання на тип "text". Наведемо конкретний приклад:
Єдиний завжди обов'язковий параметр для 'message / external-body' - "access-type". Інші параметри можуть бути чи не бути обов'язковими в залежності від значення параметра "access-type".
Значення цього параметра - слово, нечувствительное до регістру букв, що означає механізм доступу, за допомогою якого файл або дані можуть бути отримані. Значення можуть бути наступними (але не обмежуються цим поруч): "FTP", "ANON-FTP", "TFTP", "AFS", "LOCAL-FILE" та "MAIL-SERVER". Майбутні можливі значення, крім експериментальних, що починаються з "X-", повинні бути зареєстровані в IANA.
Додатково, наступні три параметри є необов'язковими для всіх способів доступу:
EXPIRATION - Дата (RFC 822 "date-time" синтаксис допускає 4 цифри в цьому полі), після якої існування зовнішніх даних не гарантується.
SIZE - розмір (в байтах) даних. Дозволяє одержувачеві вирішити, витрачати чи ресурси на зчитування зовнішніх даних. Розмір вказується для канонічної форми даних (тобто, до застосування будь-яких перетворень).
PERMISSION - нечувствительное до регістру букв поле, яке говорить про те, очікується чи ні, що клієнт може перезаписувати дані. За замовчуванням або коли цей параметр має значення "read", потрібно було, що клієнт не має на це права, і що якщо дані одного разу лічені, то більше вони не знадобляться. Якщо PERMISSION має значення "read-write", будь-яка локальна копія може розглядатися лише як кеш. "Read" і "write" - єдині зумовлені значення для PERMISSION.
Вкладені заголовки у ВСІХ тілах типу message / external-body ПОВИННІ включати поле заголовка Content-ID для завдання унікального ідентифікатора, що вказує на зовнішні дані.
Позначення, що описують дані типу external-body, такі як імена файлів або команди mail-сервера, повинні бути в символьному наборі US-ASCII.
Як і для типу message / partial, тіло типу message / external-body має мати значення content-transfer-encoding "7-bit" (за замовчуванням). Зокрема, навіть в системах, поддержіавющіх 8-бітний транспорт, застосування content-transfer-encoding "8-bit" і "binary" заборонено для даних типу message / external-body.