Тип середовища Message
Часто бажано при посилці пошти вкласти туди якесь інше повідомлення. Для вирішення цього завдання визначено спеціальний тип середовища message. Зокрема, для вкладення в повідомлення RFC-822 служить субтип rfc822.
Субтип message часто накладає обмеження на допустимі типи кодування. Ці обмеження описані для кожного специфічного субтипу. Поштові шлюзи, системи транспортування і інші поштові агенти іноді змінюють заголовки верхнього рівня в повідомленнях RFC-822. Зокрема, вони часто додають, видаляють і змінюють порядок полів заголовків. Ці операції заборонені для заголовків, вкладених в тіло повідомлення типу message.
У тілі об'єкта message / rfc822 Дозволені ніякі кодування крім 7bit, 8bit або binary. Поля заголовка повідомлення містять тільки US-ASCII в будь-якому регістрі, а інформація в тілі може бути закодована. Ні-US-ASCII-текст в заголовках інкапсульованого повідомлення може бути специфікований з використанням механізму, описаного в документі RFC-2047.
Субтип partial визначено, щоб дозволити розділяти на частини занадто великі об'єкти, які потім доставляються в вигляді окремих поштових повідомлень і автоматично відновлюються як єдине ціле приймають агентом користувача. Цей механізм може використовуватися, коли проміжний транспортний агент обмежує максимальний розмір поштового зв'язку. Тип середовища message / partial, таким чином, вказує, що тіло містить фрагмент деякого великого об'єкта.
Так як дані типу message можуть не бути закодовані у вигляді base64 або в лапках рядки друкованих символів, може виникнути проблема, якщо об'єкти message / partial створені в середовищі, яка підтримує двійковий або 8-бітовий обмін. Проблема виникає через те, що виконавчі дані треба буде розбити на кілька повідомлень message / partial, кожне з яких вимагає довічного транспорту. Якщо такі повідомлення зустрінуть по шляху шлюз з 7-бітової передачею, не буде ніякої можливості перекодувати ці фрагменти для 7-бітової середовища. Можна, звичайно, дочекатися приходу всіх складових частин, зібрати вихідний об'єкт, закодувати його за допомогою, наприклад, base64. після чого почати все з початку. Але навіть такий складний сценарій може виявитися нездійсненним через те, що фрагменти можуть транспортуватися різними шляхами. З цієї причини було специфіковане, що об'єкти типу message / partial повинні завжди мати транспортний кодування 7bit (за замовчуванням). Зокрема, навіть для середовищ, які підтримують двійковий або 8-бітовий обмін, використання транспортного кодування 8bit або binary для MIME-об'єктів типу message / partial заборонено. Це, в свою чергу, передбачає, що внутрішнє повідомлення не повинно використовувати кодування 8bit або binary. Так як деякі агенти пересилання повідомлень можуть вибрати автоматичну фрагментацію довгих повідомлень, а також через те, що ці агенти можуть використовувати різні пороги фрагментації, може так статися, що фрагменти після складання в свою чергу виявляться частинами повідомлення. Це цілком допустимо.
В поле Content-Type типу message / partial необхідно уточняти три параметра. id - унікальний ідентифікатор, який повинен використовуватися для прив'язки фрагментів один до одного. number - ціле число, яке є номером фрагмента. total - ціле число, що характеризує повне число фрагментів. Число фрагментів є опціонним і обов'язково присутній тільки в останньому фрагменті. Зауважимо також, що ці параметри можуть бути задані в будь-якому порядку. Таким чином, другий сегмент 3-фрагментного повідомлення може мати поля заголовка одного з наступних видів.
Але в третьому сегменті має бути специфіковане повне число фрагментів.
Зауважте, що нумерація фрагментів починається з 1, а не c 0.
Коли фрагменти об'єкта, розірвані таким способом, складаються разом, результатом завжди буде вихідний MIME-об'єкт, який може мати своє власне поле заголовка Content-Type і, отже, мати будь-який інший тип даних.
Семантика відновлених фрагментів повідомлень повинна відповідати внутрішньому повідомленням, а не з повідомленням, в яке воно вкладено. Це робить можливим, наприклад, посилку великого аудіоповідомлення у вигляді декількох повідомлень-фрагментів таким чином, що одержувач сприйме його як просте аудіоповідомлення, а не інкапсульоване повідомлення, що містить аудіоповідомлення. Така інкапсуляція розглядається як прозора. Коли формуються фрагменти і здійснюється збірка складових частин повідомлення message / partial, заголовки інкапсульованого повідомлення повинні об'єднуватися з заголовками вкладених об'єктів. При реалізації цієї процедури необхідно виконувати такі правила.
- Фрагментуються агенти повинні розділяти повідомлення тільки по межах рядків. Це обмеження вводиться через те, що при недотриманні даного правила виникне транспортна проблема збереження семантики повідомлення, що не закінчується послідовністю CRLF. Багато видів транспорту не здатні вирішити таку задачу
- Всі поля заголовка вихідного вкладеного повідомлення, за винятком тих, чиї імена починаються з "Content-", і специфічних полів заголовка Subject, Message-ID, Encrypted і MIMEVersion, повинні копіюватися в нове повідомлення
- Поля заголовка вкладеного повідомлення, що починаються з "Content-", плюс поля Subject, Message-ID, Encrypted і MIMEVersion, повинні бути додані до полів нового повідомлення. Будь-які поля заголовка, які не починаються з "Content-" (за винятком полів Subject, Message-ID, Encrypted і MIMEVersion) будуть проігноровані і відкинуті
- Всі поля заголовка другого і будь-яких подальших вкладених повідомлень відкидаються приймаючої програмою в процесі складання
Якщо аудіо-повідомлення розділене на два фрагмента, перша частина може виглядати як:
а друга частина може виглядати наступним чином:
Потім, коли фрагментоване повідомлення виявляється зібрано, результат, який з'явиться в користувача, повинен виглядати як:
Включення в заголовки другого і наступних секцій фрагментированного повідомлення поля References (посилання), яке вказує на Message-Id (ідентифікатор повідомлення) попередньої секції, може бути корисно для системи читати електронні листи, яка вміє відслідковувати посилання. Однак генерація полів References є опціонної.
Нарешті, слід зауважити, що поле Encrypted заголовка є застарілим через впровадження конфіденційної пошти PEM (Privacy Enhanced Messaging; RFC-1421, RFC-тисячу чотиреста двадцять два, RFC-1 423, RFC-1424), але правила, описані вище, не дивлячись ні на що , описують правильний шлях його обробки, якщо воно зустрінеться в контексті прямого і зворотного перетворення фрагментів message / partial.
Коли об'єкт MIME має тип message / external-body, він складається з заголовка, двох послідовностей CRLF і заголовка для інкапсульованого повідомлення. Якщо з'явиться ще одна пара послідовностей CRLF, це завершить заголовок інкапсульованого повідомлення. Однак, так як тіло інкапсульованого повідомлення саме є зовнішнім, воно не з'явиться слідом за заголовком. Наприклад, розглянемо наступне повідомлення:
Область в кінці, яку можна назвати тілом-фантомом, ігнорується для більшості повідомлень із зовнішнім тілом. Однак воно може використовуватися для зберігання допоміжної інформації для таких повідомлень, як це дійсно буває, коли типом доступу є mail-server. Єдиний тип доступу, описаний в цьому документі і використовує тіло-фантом. - це mail-server, але в майбутньому можуть бути дозволені інші типи.
Інкапсульовані заголовки у всіх об'єктах message / externalbody повинні включати в себе поле заголовка Content-ID, щоб надати унікальний ідентифікатор, який служить для посилання на дані. Цей ідентифікатор може бути використаний в процесі кешування і для розпізнавання вхідних даних, коли типом доступу є mailserver.
Зауважимо, що, як це специфіковане тут, лексеми, які описують дані зовнішнього тіла, такі, як імена файлів і команди поштового сервера, повинні бути записані з використанням символьного набору US-ASCII.
Типи доступу ftp і tftp
Тип доступу FTP або TFTP вказують, що тіло повідомлення є в вигляді файлу за допомогою протоколів FTP [RFC-959] або TFTP [RFC-783]. відповідно. Для цих типів доступу необхідні наступні параметри.
- NAME (ім'я). Файл, який містить тіло даних
- SITE (вузол). ЕОМ, з якою може бути отриманий файл за допомогою даного протоколу. Це повинно бути офіційно зареєстроване ім'я, а не псевдонім
- Перш ніж будь-які дані будуть вилучені за допомогою FTP. користувач повинен виконати процедуру аутентифікації (ввести ім'я та пароль) на машині, зазначеної в параметрі SITE. З міркувань безпеки ім'я і пароль НЕ специфицируются параметрами типу доступу, вони повинні бути отримані безпосередньо від користувача
Крім того, такі параметри є опціонними:
- DIRECTORY (каталог). Каталог, з якого повинен бути взятий файл з ім'ям, заданим параметром NAME
- MODE (режим). Рядок символів, яка не залежить від регістра введення і вказує на режим, який повинен використовуватися при добуванні інформації. Допустимими значеннями параметра типу доступу TFTP є NETASCII, OCTET і MAIL, як це визначено для протоколу TFTP [RFC- 783]. Допустимими значеннями параметра для типу доступу FTP є ASCII, EBCDIC. IMAGE і LOCALn, де "n" - ціле число, зазвичай 8. Вони відповідають типам вистави "A" "E" "I" і "L n", як це задано протоколом FTP [RFC-959]. Зауважимо, що BINARY і TENEX не є коректними значеннями для MODE і що замість цього слід використовувати OCTET. IMAGE або LOCAL8. Якщо параметр MODE не заданий, значенням за замовчуванням є NETASCII для TFTP і ASCII у всіх інших випадках
Тип доступу local-file
Тип доступу local-file вказує, що тіло даних є як файл на локальній ЕОМ. Для цього типу доступу визначені два додаткові параметри.
- NAME (ім'я). Файл, який містить тіло даних. Цей параметр є обов'язковим для типу доступу local-file
- SITE (вузол). Специфікатор домену для даної ЕОМ або набору машин, які мають доступ до даного інформаційного файлу. Цей опціонний параметр використовується для опису локального покажчика на дані, тобто вузол або групу вузлів, звідки даний файл доступний. В якості символів підміни в імені домена можуть використовуватися зірочки, як, наприклад, в "* .bellcore.com", щоб вказати на групу ЕОМ, звідки дані доступні безпосередньо
Тип доступу mail-server
Тип доступу mail-server вказує, що тіло даних є на поштовому сервері. Для цього типу доступу визначені два додаткові параметри.
Так як поштові сервери сприймають різноманітні синтаксиси, деякі з яких є багаторядковими, повна команда, яка повинна бути надіслана поштового сервера, не включається в якості параметра з полем заголовка content-type. Замість цього вона заноситься як тіло-фантом. коли тип середовища відповідає message / external-body. а типом доступу - mail-server.
На відміну від інших типів доступу, доступ до поштового сервера є асинхронним і відбувається в довільний момент часу. З цієї причини важливо, щоб існував механізм, за допомогою якого отримані дані могли бути зіставлені з вихідним об'єктом message / external-body. Поштові сервери MIME повинні використовувати той же поле Content-ID в повідомленні-відгуку, яке було використано в початкових об'єктах message / external-body, для того щоб полегшити таке зіставлення.