1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609 4610 4611 4612 4613 4614 4615 4616 4617 4618 4619 4620 4621 4622 4623 4624 4625 4626 4627 4628 4629 4630 4631 4632 4633 4634 4635 4636 4637 4638 4639 4640 4641 4642 4643 4644 4645 4646 4647 4648 4649 4650 4651 4652 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770 4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4806 4807 4808 4809 4810 4811 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879 4880 4881 4882 4883 4884 4885 4886 4887 4888 4889 4890 4891 4892 4893 4894 4895 4896 4897 4898 4899 4900 4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 4915 4916 4917 4918 4919 4920 4921 4922 4923 4924 4925 4926 4927 4928 4929 4930 4931 4932 4933 4934 4935 4936 4937 4938 4939 4940 4941 4942 4943 4944 4945 4946 4947 4948 4949 4950 4951 4952 4953 4954 4955 4956 4957 4958 4959 4960 4961 4962 4963 4964 4965 4966 4967 4968 4969 4970 4971 4972 4973 4974 4975 4976 4977 4978 4979 4980 4981 4982 4983 4984 4985 4986 4987 4988 4989 4990 4991 4992 4993 4994 4995 4996 4997 4998 4999 5000 5001 5002 5003 5004 5005 5006 5007 5008 5009 5010 5011 5012 5013 5014 5015 5016 5017 5018 5019 5020 5021 5022 5023 5024 5025 5026 5027 5028 5029 5030 5031 5032 5033 5034 5035 5036 5037 5038 5039 5040 5041 5042 5043 5044 5045 5046 5047 5048 5049 5050 5051 5052 5053 5054 5055 5056 5057 5058 5059 5060 5061 5062 5063 5064 5065 5066 5067 5068 5069 5070 5071 5072 5073 5074 5075 5076 5077 5078 5079 5080 5081 5082 5083 5084 5085 5086 5087 5088 5089 5090 5091 5092 5093 5094 5095 5096 5097 5098 5099 5100 5101 5102 5103 5104 5105 5106 5107 5108 5109 5110 5111 5112 5113 5114 5115 5116 5117 5118 5119 5120 5121 5122 5123 5124 5125 5126 5127 5128 5129 5130 5131 5132 5133 5134 5135 5136 5137 5138 5139 5140 5141 5142 5143 5144 5145 5146 5147 5148 5149 5150 5151 5152 5153 5154 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 5175 5176 5177 5178 5179 5180 5181 5182 5183 5184 5185 5186 5187 5188 5189 5190 5191 5192 5193 5194 5195 5196 5197 5198 5199 5200 5201 5202 5203 5204 5205 5206 5207 5208 5209 5210 5211 5212 5213 5214 5215 5216 5217 5218 5219 5220 5221 5222 5223 5224 5225 5226 5227 5228 5229 5230 5231 5232 5233 5234 5235 5236 5237 5238 5239 5240 5241 5242 5243 5244 5245 5246 5247 5248 5249 5250 5251 5252 5253 5254 5255 5256 5257 5258 5259 5260 5261 5262 5263 5264 5265
|
Network Working Group N. Borenstein, Bellcore
Request for Comments: 1341 N. Freed, Innosoft
June 1992
MIME (Multipurpose Internet Mail Extensions):
Mechanisms for Specifying and Describing
the Format of Internet Message Bodies
Status of this Memo
This RFC specifies an IAB standards track protocol for the
Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of
the "IAB Official Protocol Standards" for the
standardization state and status of this protocol.
Distribution of this memo is unlimited.
Abstract
RFC 822 defines a message representation protocol which
specifies considerable detail about message headers, but
which leaves the message content, or message body, as flat
ASCII text. This document redefines the format of message
bodies to allow multi-part textual and non-textual message
bodies to be represented and exchanged without loss of
information. This is based on earlier work documented in
RFC 934 and RFC 1049, but extends and revises that work.
Because RFC 822 said so little about message bodies, this
document is largely orthogonal to (rather than a revision
of) RFC 822.
In particular, this document is designed to provide
facilities to include multiple objects in a single message,
to represent body text in character sets other than US-
ASCII, to represent formatted multi-font text messages, to
represent non-textual material such as images and audio
fragments, and generally to facilitate later extensions
defining new types of Internet mail for use by cooperating
mail agents.
This document does NOT extend Internet mail header fields to
permit anything other than US-ASCII text data. It is
recognized that such extensions are necessary, and they are
the subject of a companion document [RFC -1342].
A table of contents appears at the end of this document.
Borenstein & Freed [Page i]
1 Introduction
Since its publication in 1982, RFC 822 [RFC-822] has defined
the standard format of textual mail messages on the
Internet. Its success has been such that the RFC 822 format
has been adopted, wholly or partially, well beyond the
confines of the Internet and the Internet SMTP transport
defined by RFC 821 [RFC-821]. As the format has seen wider
use, a number of limitations have proven increasingly
restrictive for the user community.
RFC 822 was intended to specify a format for text messages.
As such, non-text messages, such as multimedia messages that
might include audio or images, are simply not mentioned.
Even in the case of text, however, RFC 822 is inadequate for
the needs of mail users whose languages require the use of
character sets richer than US ASCII [US-ASCII]. Since RFC
822 does not specify mechanisms for mail containing audio,
video, Asian language text, or even text in most European
languages, additional specifications are needed
One of the notable limitations of RFC 821/822 based mail
systems is the fact that they limit the contents of
electronic mail messages to relatively short lines of
seven-bit ASCII. This forces users to convert any non-
textual data that they may wish to send into seven-bit bytes
representable as printable ASCII characters before invoking
a local mail UA (User Agent, a program with which human
users send and receive mail). Examples of such encodings
currently used in the Internet include pure hexadecimal,
uuencode, the 3-in-4 base 64 scheme specified in RFC 1113,
the Andrew Toolkit Representation [ATK], and many others.
The limitations of RFC 822 mail become even more apparent as
gateways are designed to allow for the exchange of mail
messages between RFC 822 hosts and X.400 hosts. X.400 [X400]
specifies mechanisms for the inclusion of non-textual body
parts within electronic mail messages. The current
standards for the mapping of X.400 messages to RFC 822
messages specify that either X.400 non-textual body parts
should be converted to (not encoded in) an ASCII format, or
that they should be discarded, notifying the RFC 822 user
that discarding has occurred. This is clearly undesirable,
as information that a user may wish to receive is lost.
Even though a user's UA may not have the capability of
dealing with the non-textual body part, the user might have
some mechanism external to the UA that can extract useful
information from the body part. Moreover, it does not allow
for the fact that the message may eventually be gatewayed
back into an X.400 message handling system (i.e., the X.400
message is "tunneled" through Internet mail), where the
non-textual information would definitely become useful
again.
Borenstein & Freed [Page 1]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
This document describes several mechanisms that combine to
solve most of these problems without introducing any serious
incompatibilities with the existing world of RFC 822 mail.
In particular, it describes:
1. A MIME-Version header field, which uses a version number
to declare a message to be conformant with this
specification and allows mail processing agents to
distinguish between such messages and those generated
by older or non-conformant software, which is presumed
to lack such a field.
2. A Content-Type header field, generalized from RFC 1049
[RFC-1049], which can be used to specify the type and
subtype of data in the body of a message and to fully
specify the native representation (encoding) of such
data.
2.a. A "text" Content-Type value, which can be used to
represent textual information in a number of
character sets and formatted text description
languages in a standardized manner.
2.b. A "multipart" Content-Type value, which can be
used to combine several body parts, possibly of
differing types of data, into a single message.
2.c. An "application" Content-Type value, which can be
used to transmit application data or binary data,
and hence, among other uses, to implement an
electronic mail file transfer service.
2.d. A "message" Content-Type value, for encapsulating
a mail message.
2.e An "image" Content-Type value, for transmitting
still image (picture) data.
2.f. An "audio" Content-Type value, for transmitting
audio or voice data.
2.g. A "video" Content-Type value, for transmitting
video or moving image data, possibly with audio as
part of the composite video data format.
3. A Content-Transfer-Encoding header field, which can be
used to specify an auxiliary encoding that was applied
to the data in order to allow it to pass through mail
transport mechanisms which may have data or character
set limitations.
4. Two optional header fields that can be used to further
describe the data in a message body, the Content-ID and
Content-Description header fields.
Borenstein & Freed [Page 2]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
MIME has been carefully designed as an extensible mechanism,
and it is expected that the set of content-type/subtype
pairs and their associated parameters will grow
significantly with time. Several other MIME fields, notably
including character set names, are likely to have new values
defined over time. In order to ensure that the set of such
values is developed in an orderly, well-specified, and
public manner, MIME defines a registration process which
uses the Internet Assigned Numbers Authority (IANA) as a
central registry for such values. Appendix F provides
details about how IANA registration is accomplished.
Finally, to specify and promote interoperability, Appendix A
of this document provides a basic applicability statement
for a subset of the above mechanisms that defines a minimal
level of "conformance" with this document.
HISTORICAL NOTE: Several of the mechanisms described in
this document may seem somewhat strange or even baroque at
first reading. It is important to note that compatibility
with existing standards AND robustness across existing
practice were two of the highest priorities of the working
group that developed this document. In particular,
compatibility was always favored over elegance.
2 Notations, Conventions, and Generic BNF Grammar
This document is being published in two versions, one as
plain ASCII text and one as PostScript. The latter is
recommended, though the textual contents are identical. An
Andrew-format copy of this document is also available from
the first author (Borenstein).
Although the mechanisms specified in this document are all
described in prose, most are also described formally in the
modified BNF notation of RFC 822. Implementors will need to
be familiar with this notation in order to understand this
specification, and are referred to RFC 822 for a complete
explanation of the modified BNF notation.
Some of the modified BNF in this document makes reference to
syntactic entities that are defined in RFC 822 and not in
this document. A complete formal grammar, then, is obtained
by combining the collected grammar appendix of this document
with that of RFC 822.
The term CRLF, in this document, refers to the sequence of
the two ASCII characters CR (13) and LF (10) which, taken
together, in this order, denote a line break in RFC 822
mail.
The term "character set", wherever it is used in this
document, refers to a coded character set, in the sense of
ISO character set standardization work, and must not be
Borenstein & Freed [Page 3]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
misinterpreted as meaning "a set of characters."
The term "message", when not further qualified, means either
the (complete or "top-level") message being transferred on a
network, or a message encapsulated in a body of type
"message".
The term "body part", in this document, means one of the
parts of the body of a multipart entity. A body part has a
header and a body, so it makes sense to speak about the body
of a body part.
The term "entity", in this document, means either a message
or a body part. All kinds of entities share the property
that they have a header and a body.
The term "body", when not further qualified, means the body
of an entity, that is the body of either a message or of a
body part.
Note : the previous four definitions are clearly circular.
This is unavoidable, since the overal structure of a MIME
message is indeed recursive.
In this document, all numeric and octet values are given in
decimal notation.
It must be noted that Content-Type values, subtypes, and
parameter names as defined in this document are case-
insensitive. However, parameter values are case-sensitive
unless otherwise specified for the specific parameter.
FORMATTING NOTE: This document has been carefully formatted
for ease of reading. The PostScript version of this
document, in particular, places notes like this one, which
may be skipped by the reader, in a smaller, italicized,
font, and indents it as well. In the text version, only the
indentation is preserved, so if you are reading the text
version of this you might consider using the PostScript
version instead. However, all such notes will be indented
and preceded by "NOTE:" or some similar introduction, even
in the text version.
The primary purpose of these non-essential notes is to
convey information about the rationale of this document, or
to place this document in the proper historical or
evolutionary context. Such information may be skipped by
those who are focused entirely on building a compliant
implementation, but may be of use to those who wish to
understand why this document is written as it is.
For ease of recognition, all BNF definitions have been
placed in a fixed-width font in the PostScript version of
this document.
Borenstein & Freed [Page 4]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
3 The MIME-Version Header Field
Since RFC 822 was published in 1982, there has really been
only one format standard for Internet messages, and there
has been little perceived need to declare the format
standard in use. This document is an independent document
that complements RFC 822. Although the extensions in this
document have been defined in such a way as to be compatible
with RFC 822, there are still circumstances in which it
might be desirable for a mail-processing agent to know
whether a message was composed with the new standard in
mind.
Therefore, this document defines a new header field, "MIME-
Version", which is to be used to declare the version of the
Internet message body format standard in use.
Messages composed in accordance with this document MUST
include such a header field, with the following verbatim
text:
MIME-Version: 1.0
The presence of this header field is an assertion that the
message has been composed in compliance with this document.
Since it is possible that a future document might extend the
message format standard again, a formal BNF is given for the
content of the MIME-Version field:
MIME-Version := text
Thus, future format specifiers, which might replace or
extend "1.0", are (minimally) constrained by the definition
of "text", which appears in RFC 822.
Note that the MIME-Version header field is required at the
top level of a message. It is not required for each body
part of a multipart entity. It is required for the embedded
headers of a body of type "message" if and only if the
embedded message is itself claimed to be MIME-compliant.
Borenstein & Freed [Page 5]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
4 The Content-Type Header Field
The purpose of the Content-Type field is to describe the
data contained in the body fully enough that the receiving
user agent can pick an appropriate agent or mechanism to
present the data to the user, or otherwise deal with the
data in an appropriate manner.
HISTORICAL NOTE: The Content-Type header field was first
defined in RFC 1049. RFC 1049 Content-types used a simpler
and less powerful syntax, but one that is largely compatible
with the mechanism given here.
The Content-Type header field is used to specify the nature
of the data in the body of an entity, by giving type and
subtype identifiers, and by providing auxiliary information
that may be required for certain types. After the type and
subtype names, the remainder of the header field is simply a
set of parameters, specified in an attribute/value notation.
The set of meaningful parameters differs for the different
types. The ordering of parameters is not significant.
Among the defined parameters is a "charset" parameter by
which the character set used in the body may be declared.
Comments are allowed in accordance with RFC 822 rules for
structured header fields.
In general, the top-level Content-Type is used to declare
the general type of data, while the subtype specifies a
specific format for that type of data. Thus, a Content-Type
of "image/xyz" is enough to tell a user agent that the data
is an image, even if the user agent has no knowledge of the
specific image format "xyz". Such information can be used,
for example, to decide whether or not to show a user the raw
data from an unrecognized subtype -- such an action might be
reasonable for unrecognized subtypes of text, but not for
unrecognized subtypes of image or audio. For this reason,
registered subtypes of audio, image, text, and video, should
not contain embedded information that is really of a
different type. Such compound types should be represented
using the "multipart" or "application" types.
Parameters are modifiers of the content-subtype, and do not
fundamentally affect the requirements of the host system.
Although most parameters make sense only with certain
content-types, others are "global" in the sense that they
might apply to any subtype. For example, the "boundary"
parameter makes sense only for the "multipart" content-type,
but the "charset" parameter might make sense with several
content-types.
An initial set of seven Content-Types is defined by this
document. This set of top-level names is intended to be
substantially complete. It is expected that additions to
the larger set of supported types can generally be
Borenstein & Freed [Page 6]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
accomplished by the creation of new subtypes of these
initial types. In the future, more top-level types may be
defined only by an extension to this standard. If another
primary type is to be used for any reason, it must be given
a name starting with "X-" to indicate its non-standard
status and to avoid a potential conflict with a future
official name.
In the Extended BNF notation of RFC 822, a Content-Type
header field value is defined as follows:
Content-Type := type "/" subtype *[";" parameter]
type := "application" / "audio"
/ "image" / "message"
/ "multipart" / "text"
/ "video" / x-token
x-token := <The two characters "X-" followed, with no
intervening white space, by any token>
subtype := token
parameter := attribute "=" value
attribute := token
value := token / quoted-string
token := 1*<any CHAR except SPACE, CTLs, or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in
/ "," / ";" / ":" / "\" / <"> ; quoted-string,
/ "/" / "[" / "]" / "?" / "." ; to use within
/ "=" ; parameter values
Note that the definition of "tspecials" is the same as the
RFC 822 definition of "specials" with the addition of the
three characters "/", "?", and "=".
Note also that a subtype specification is MANDATORY. There
are no default subtypes.
The type, subtype, and parameter names are not case
sensitive. For example, TEXT, Text, and TeXt are all
equivalent. Parameter values are normally case sensitive,
but certain parameters are interpreted to be case-
insensitive, depending on the intended use. (For example,
multipart boundaries are case-sensitive, but the "access-
type" for message/External-body is not case-sensitive.)
Beyond this syntax, the only constraint on the definition of
subtype names is the desire that their uses must not
conflict. That is, it would be undesirable to have two
Borenstein & Freed [Page 7]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
different communities using "Content-Type:
application/foobar" to mean two different things. The
process of defining new content-subtypes, then, is not
intended to be a mechanism for imposing restrictions, but
simply a mechanism for publicizing the usages. There are,
therefore, two acceptable mechanisms for defining new
Content-Type subtypes:
1. Private values (starting with "X-") may be
defined bilaterally between two cooperating
agents without outside registration or
standardization.
2. New standard values must be documented,
registered with, and approved by IANA, as
described in Appendix F. Where intended for
public use, the formats they refer to must
also be defined by a published specification,
and possibly offered for standardization.
The seven standard initial predefined Content-Types are
detailed in the bulk of this document. They are:
text -- textual information. The primary subtype,
"plain", indicates plain (unformatted) text. No
special software is required to get the full
meaning of the text, aside from support for the
indicated character set. Subtypes are to be used
for enriched text in forms where application
software may enhance the appearance of the text,
but such software must not be required in order to
get the general idea of the content. Possible
subtypes thus include any readable word processor
format. A very simple and portable subtype,
richtext, is defined in this document.
multipart -- data consisting of multiple parts of
independent data types. Four initial subtypes
are defined, including the primary "mixed"
subtype, "alternative" for representing the same
data in multiple formats, "parallel" for parts
intended to be viewed simultaneously, and "digest"
for multipart entities in which each part is of
type "message".
message -- an encapsulated message. A body of
Content-Type "message" is itself a fully formatted
RFC 822 conformant message which may contain its
own different Content-Type header field. The
primary subtype is "rfc822". The "partial"
subtype is defined for partial messages, to permit
the fragmented transmission of bodies that are
thought to be too large to be passed through mail
transport facilities. Another subtype,
"External-body", is defined for specifying large
bodies by reference to an external data source.
Borenstein & Freed [Page 8]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
image -- image data. Image requires a display device
(such as a graphical display, a printer, or a FAX
machine) to view the information. Initial
subtypes are defined for two widely-used image
formats, jpeg and gif.
audio -- audio data, with initial subtype "basic".
Audio requires an audio output device (such as a
speaker or a telephone) to "display" the contents.
video -- video data. Video requires the capability to
display moving images, typically including
specialized hardware and software. The initial
subtype is "mpeg".
application -- some other kind of data, typically
either uninterpreted binary data or information to
be processed by a mail-based application. The
primary subtype, "octet-stream", is to be used in
the case of uninterpreted binary data, in which
case the simplest recommended action is to offer
to write the information into a file for the user.
Two additional subtypes, "ODA" and "PostScript",
are defined for transporting ODA and PostScript
documents in bodies. Other expected uses for
"application" include spreadsheets, data for
mail-based scheduling systems, and languages for
"active" (computational) email. (Note that active
email entails several securityconsiderations,
which are discussed later in this memo,
particularly in the context of
application/PostScript.)
Default RFC 822 messages are typed by this protocol as plain
text in the US-ASCII character set, which can be explicitly
specified as "Content-type: text/plain; charset=us-ascii".
If no Content-Type is specified, either by error or by an
older user agent, this default is assumed. In the presence
of a MIME-Version header field, a receiving User Agent can
also assume that plain US-ASCII text was the sender's
intent. In the absence of a MIME-Version specification,
plain US-ASCII text must still be assumed, but the sender's
intent might have been otherwise.
RATIONALE: In the absence of any Content-Type header field
or MIME-Version header field, it is impossible to be certain
that a message is actually text in the US-ASCII character
set, since it might well be a message that, using the
conventions that predate this document, includes text in
another character set or non-textual data in a manner that
cannot be automatically recognized (e.g., a uuencoded
compressed UNIX tar file). Although there is no fully
acceptable alternative to treating such untyped messages as
"text/plain; charset=us-ascii", implementors should remain
aware that if a message lacks both the MIME-Version and the
Content-Type header fields, it may in practice contain
almost anything.
Borenstein & Freed [Page 9]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
It should be noted that the list of Content-Type values
given here may be augmented in time, via the mechanisms
described above, and that the set of subtypes is expected to
grow substantially.
When a mail reader encounters mail with an unknown Content-
type value, it should generally treat it as equivalent to
"application/octet-stream", as described later in this
document.
5 The Content-Transfer-Encoding Header Field
Many Content-Types which could usefully be transported via
email are represented, in their "natural" format, as 8-bit
character or binary data. Such data cannot be transmitted
over some transport protocols. For example, RFC 821
restricts mail messages to 7-bit US-ASCII data with 1000
character lines.
It is necessary, therefore, to define a standard mechanism
for re-encoding such data into a 7-bit short-line format.
This document specifies that such encodings will be
indicated by a new "Content-Transfer-Encoding" header field.
The Content-Transfer-Encoding field is used to indicate the
type of transformation that has been used in order to
represent the body in an acceptable manner for transport.
Unlike Content-Types, a proliferation of Content-Transfer-
Encoding values is undesirable and unnecessary. However,
establishing only a single Content-Transfer-Encoding
mechanism does not seem possible. There is a tradeoff
between the desire for a compact and efficient encoding of
largely-binary data and the desire for a readable encoding
of data that is mostly, but not entirely, 7-bit data. For
this reason, at least two encoding mechanisms are necessary:
a "readable" encoding and a "dense" encoding.
The Content-Transfer-Encoding field is designed to specify
an invertible mapping between the "native" representation of
a type of data and a representation that can be readily
exchanged using 7 bit mail transport protocols, such as
those defined by RFC 821 (SMTP). This field has not been
defined by any previous standard. The field's value is a
single token specifying the type of encoding, as enumerated
below. Formally:
Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" / x-token
These values are not case sensitive. That is, Base64 and
BASE64 and bAsE64 are all equivalent. An encoding type of
7BIT requires that the body is already in a seven-bit mail-
ready representation. This is the default value -- that is,
Borenstein & Freed [Page 10]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
"Content-Transfer-Encoding: 7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.
The values "8bit", "7bit", and "binary" all imply that NO
encoding has been performed. However, they are potentially
useful as indications of the kind of data contained in the
object, and therefore of the kind of encoding that might
need to be performed for transmission in a given transport
system. "7bit" means that the data is all represented as
short lines of US-ASCII data. "8bit" means that the lines
are short, but there may be non-ASCII characters (octets
with the high-order bit set). "Binary" means that not only
may non-ASCII characters be present, but also that the lines
are not necessarily short enough for SMTP transport.
The difference between "8bit" (or any other conceivable
bit-width token) and the "binary" token is that "binary"
does not require adherence to any limits on line length or
to the SMTP CRLF semantics, while the bit-width tokens do
require such adherence. If the body contains data in any
bit-width other than 7-bit, the appropriate bit-width
Content-Transfer-Encoding token must be used (e.g., "8bit"
for unencoded 8 bit wide data). If the body contains binary
data, the "binary" Content-Transfer-Encoding token must be
used.
NOTE: The distinction between the Content-Transfer-Encoding
values of "binary," "8bit," etc. may seem unimportant, in
that all of them really mean "none" -- that is, there has
been no encoding of the data for transport. However, clear
labeling will be of enormous value to gateways between
future mail transport systems with differing capabilities in
transporting data that do not meet the restrictions of RFC
821 transport.
As of the publication of this document, there are no
standardized Internet transports for which it is legitimate
to include unencoded 8-bit or binary data in mail bodies.
Thus there are no circumstances in which the "8bit" or
"binary" Content-Transfer-Encoding is actually legal on the
Internet. However, in the event that 8-bit or binary mail
transport becomes a reality in Internet mail, or when this
document is used in conjunction with any other 8-bit or
binary-capable transport mechanism, 8-bit or binary bodies
should be labeled as such using this mechanism.
NOTE: The five values defined for the Content-Transfer-
Encoding field imply nothing about the Content-Type other
than the algorithm by which it was encoded or the transport
system requirements if unencoded.
Implementors may, if necessary, define new Content-
Transfer-Encoding values, but must use an x-token, which is
a name prefixed by "X-" to indicate its non-standard status,
Borenstein & Freed [Page 11]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
e.g., "Content-Transfer-Encoding: x-my-new-encoding".
However, unlike Content-Types and subtypes, the creation of
new Content-Transfer-Encoding values is explicitly and
strongly discouraged, as it seems likely to hinder
interoperability with little potential benefit. Their use
is allowed only as the result of an agreement between
cooperating user agents.
If a Content-Transfer-Encoding header field appears as part
of a message header, it applies to the entire body of that
message. If a Content-Transfer-Encoding header field
appears as part of a body part's headers, it applies only to
the body of that body part. If an entity is of type
"multipart" or "message", the Content-Transfer-Encoding is
not permitted to have any value other than a bit width
(e.g., "7bit", "8bit", etc.) or "binary".
It should be noted that email is character-oriented, so that
the mechanisms described here are mechanisms for encoding
arbitrary byte streams, not bit streams. If a bit stream is
to be encoded via one of these mechanisms, it must first be
converted to an 8-bit byte stream using the network standard
bit order ("big-endian"), in which the earlier bits in a
stream become the higher-order bits in a byte. A bit stream
not ending at an 8-bit boundary must be padded with zeroes.
This document provides a mechanism for noting the addition
of such padding in the case of the application Content-Type,
which has a "padding" parameter.
The encoding mechanisms defined here explicitly encode all
data in ASCII. Thus, for example, suppose an entity has
header fields such as:
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64
This should be interpreted to mean that the body is a base64
ASCII encoding of data that was originally in ISO-8859-1,
and will be in that character set again after decoding.
The following sections will define the two standard encoding
mechanisms. The definition of new content-transfer-
encodings is explicitly discouraged and should only occur
when absolutely necessary. All content-transfer-encoding
namespace except that beginning with "X-" is explicitly
reserved to the IANA for future use. Private agreements
about content-transfer-encodings are also explicitly
discouraged.
Certain Content-Transfer-Encoding values may only be used on
certain Content-Types. In particular, it is expressly
forbidden to use any encodings other than "7bit", "8bit", or
"binary" with any Content-Type that recursively includes
other Content-Type fields, notably the "multipart" and
Borenstein & Freed [Page 12]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
"message" Content-Types. All encodings that are desired for
bodies of type multipart or message must be done at the
innermost level, by encoding the actual body that needs to
be encoded.
NOTE ON ENCODING RESTRICTIONS: Though the prohibition
against using content-transfer-encodings on data of type
multipart or message may seem overly restrictive, it is
necessary to prevent nested encodings, in which data are
passed through an encoding algorithm multiple times, and
must be decoded multiple times in order to be properly
viewed. Nested encodings add considerable complexity to
user agents: aside from the obvious efficiency problems
with such multiple encodings, they can obscure the basic
structure of a message. In particular, they can imply that
several decoding operations are necessary simply to find out
what types of objects a message contains. Banning nested
encodings may complicate the job of certain mail gateways,
but this seems less of a problem than the effect of nested
encodings on user agents.
NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-
TRANSFER-ENCODING: It may seem that the Content-Transfer-
Encoding could be inferred from the characteristics of the
Content-Type that is to be encoded, or, at the very least,
that certain Content-Transfer-Encodings could be mandated
for use with specific Content-Types. There are several
reasons why this is not the case. First, given the varying
types of transports used for mail, some encodings may be
appropriate for some Content-Type/transport combinations and
not for others. (For example, in an 8-bit transport, no
encoding would be required for text in certain character
sets, while such encodings are clearly required for 7-bit
SMTP.) Second, certain Content-Types may require different
types of transfer encoding under different circumstances.
For example, many PostScript bodies might consist entirely
of short lines of 7-bit data and hence require little or no
encoding. Other PostScript bodies (especially those using
Level 2 PostScript's binary encoding mechanism) may only be
reasonably represented using a binary transport encoding.
Finally, since Content-Type is intended to be an open-ended
specification mechanism, strict specification of an
association between Content-Types and encodings effectively
couples the specification of an application protocol with a
specific lower-level transport. This is not desirable since
the developers of a Content-Type should not have to be aware
of all the transports in use and what their limitations are.
NOTE ON TRANSLATING ENCODINGS: The quoted-printable and
base64 encodings are designed so that conversion between
them is possible. The only issue that arises in such a
conversion is the handling of line breaks. When converting
from quoted-printable to base64 a line break must be
converted into a CRLF sequence. Similarly, a CRLF sequence
Borenstein & Freed [Page 13]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
in base64 data should be converted to a quoted-printable
line break, but ONLY when converting text data.
NOTE ON CANONICAL ENCODING MODEL: There was some
confusion, in earlier drafts of this memo, regarding the
model for when email data was to be converted to canonical
form and encoded, and in particular how this process would
affect the treatment of CRLFs, given that the representation
of newlines varies greatly from system to system. For this
reason, a canonical model for encoding is presented as
Appendix H.
5.1 Quoted-Printable Content-Transfer-Encoding
The Quoted-Printable encoding is intended to represent data
that largely consists of octets that correspond to printable
characters in the ASCII character set. It encodes the data
in such a way that the resulting octets are unlikely to be
modified by mail transport. If the data being encoded are
mostly ASCII text, the encoded form of the data remains
largely recognizable by humans. A body which is entirely
ASCII may also be encoded in Quoted-Printable to ensure the
integrity of the data should the message pass through a
character-translating, and/or line-wrapping gateway.
In this encoding, octets are to be represented as determined
by the following rules:
Rule #1: (General 8-bit representation) Any octet,
except those indicating a line break according to the
newline convention of the canonical form of the data
being encoded, may be represented by an "=" followed by
a two digit hexadecimal representation of the octet's
value. The digits of the hexadecimal alphabet, for this
purpose, are "0123456789ABCDEF". Uppercase letters must
be
used when sending hexadecimal data, though a robust
implementation may choose to recognize lowercase
letters on receipt. Thus, for example, the value 12
(ASCII form feed) can be represented by "=0C", and the
value 61 (ASCII EQUAL SIGN) can be represented by
"=3D". Except when the following rules allow an
alternative encoding, this rule is mandatory.
Rule #2: (Literal representation) Octets with decimal
values of 33 through 60 inclusive, and 62 through 126,
inclusive, MAY be represented as the ASCII characters
which correspond to those octets (EXCLAMATION POINT
through LESS THAN, and GREATER THAN through TILDE,
respectively).
Rule #3: (White Space): Octets with values of 9 and 32
MAY be represented as ASCII TAB (HT) and SPACE
characters, respectively, but MUST NOT be so
Borenstein & Freed [Page 14]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
represented at the end of an encoded line. Any TAB (HT)
or SPACE characters on an encoded line MUST thus be
followed on that line by a printable character. In
particular, an "=" at the end of an encoded line,
indicating a soft line break (see rule #5) may follow
one or more TAB (HT) or SPACE characters. It follows
that an octet with value 9 or 32 appearing at the end
of an encoded line must be represented according to
Rule #1. This rule is necessary because some MTAs
(Message Transport Agents, programs which transport
messages from one user to another, or perform a part of
such transfers) are known to pad lines of text with
SPACEs, and others are known to remove "white space"
characters from the end of a line. Therefore, when
decoding a Quoted-Printable body, any trailing white
space on a line must be deleted, as it will necessarily
have been added by intermediate transport agents.
Rule #4 (Line Breaks): A line break in a text body
part, independent of what its representation is
following the canonical representation of the data
being encoded, must be represented by a (RFC 822) line
break, which is a CRLF sequence, in the Quoted-
Printable encoding. If isolated CRs and LFs, or LF CR
and CR LF sequences are allowed to appear in binary
data according to the canonical form, they must be
represented using the "=0D", "=0A", "=0A=0D" and
"=0D=0A" notations respectively.
Note that many implementation may elect to encode the
local representation of various content types directly.
In particular, this may apply to plain text material on
systems that use newline conventions other than CRLF
delimiters. Such an implementation is permissible, but
the generation of line breaks must be generalized to
account for the case where alternate representations of
newline sequences are used.
Rule #5 (Soft Line Breaks): The Quoted-Printable
encoding REQUIRES that encoded lines be no more than 76
characters long. If longer lines are to be encoded with
the Quoted-Printable encoding, 'soft' line breaks must
be used. An equal sign as the last character on a
encoded line indicates such a non-significant ('soft')
line break in the encoded text. Thus if the "raw" form
of the line is a single unencoded line that says:
Now's the time for all folk to come to the aid of
their country.
This can be represented, in the Quoted-Printable
encoding, as
Borenstein & Freed [Page 15]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Now's the time =
for all folk to come=
to the aid of their country.
This provides a mechanism with which long lines are
encoded in such a way as to be restored by the user
agent. The 76 character limit does not count the
trailing CRLF, but counts all other characters,
including any equal signs.
Since the hyphen character ("-") is represented as itself in
the Quoted-Printable encoding, care must be taken, when
encapsulating a quoted-printable encoded body in a multipart
entity, to ensure that the encapsulation boundary does not
appear anywhere in the encoded body. (A good strategy is to
choose a boundary that includes a character sequence such as
"=_" which can never appear in a quoted-printable body. See
the definition of multipart messages later in this
document.)
NOTE: The quoted-printable encoding represents something of
a compromise between readability and reliability in
transport. Bodies encoded with the quoted-printable
encoding will work reliably over most mail gateways, but may
not work perfectly over a few gateways, notably those
involving translation into EBCDIC. (In theory, an EBCDIC
gateway could decode a quoted-printable body and re-encode
it using base64, but such gateways do not yet exist.) A
higher level of confidence is offered by the base64
Content-Transfer-Encoding. A way to get reasonably reliable
transport through EBCDIC gateways is to also quote the ASCII
characters
!"#$@[\]^`{|}~
according to rule #1. See Appendix B for more information.
Because quoted-printable data is generally assumed to be
line-oriented, it is to be expected that the breaks between
the lines of quoted printable data may be altered in
transport, in the same manner that plain text mail has
always been altered in Internet mail when passing between
systems with differing newline conventions. If such
alterations are likely to constitute a corruption of the
data, it is probably more sensible to use the base64
encoding rather than the quoted-printable encoding.
Borenstein & Freed [Page 16]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
5.2 Base64 Content-Transfer-Encoding
The Base64 Content-Transfer-Encoding is designed to
represent arbitrary sequences of octets in a form that is
not humanly readable. The encoding and decoding algorithms
are simple, but the encoded data are consistently only about
33 percent larger than the unencoded data. This encoding is
based on the one used in Privacy Enhanced Mail applications,
as defined in RFC 1113. The base64 encoding is adapted
from RFC 1113, with one change: base64 eliminates the "*"
mechanism for embedded clear text.
A 65-character subset of US-ASCII is used, enabling 6 bits
to be represented per printable character. (The extra 65th
character, "=", is used to signify a special processing
function.)
NOTE: This subset has the important property that it is
represented identically in all versions of ISO 646,
including US ASCII, and all characters in the subset are
also represented identically in all versions of EBCDIC.
Other popular encodings, such as the encoding used by the
UUENCODE utility and the base85 encoding specified as part
of Level 2 PostScript, do not share these properties, and
thus do not fulfill the portability requirements a binary
transport encoding for mail must meet.
The encoding process represents 24-bit groups of input bits
as output strings of 4 encoded characters. Proceeding from
left to right, a 24-bit input group is formed by
concatenating 3 8-bit input groups. These 24 bits are then
treated as 4 concatenated 6-bit groups, each of which is
translated into a single digit in the base64 alphabet. When
encoding a bit stream via the base64 encoding, the bit
stream must be presumed to be ordered with the most-
significant-bit first. That is, the first bit in the stream
will be the high-order bit in the first byte, and the eighth
bit will be the low-order bit in the first byte, and so on.
Each 6-bit group is used as an index into an array of 64
printable characters. The character referenced by the index
is placed in the output string. These characters, identified
in Table 1, below, are selected so as to be universally
representable, and the set excludes characters with
particular significance to SMTP (e.g., ".", "CR", "LF") and
to the encapsulation boundaries defined in this document
(e.g., "-").
Borenstein & Freed [Page 17]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Table 1: The Base64 Alphabet
Value Encoding Value Encoding Value Encoding Value
Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
The output stream (encoded bytes) must be represented in
lines of no more than 76 characters each. All line breaks
or other characters not found in Table 1 must be ignored by
decoding software. In base64 data, characters other than
those in Table 1, line breaks, and other white space
probably indicate a transmission error, about which a
warning message or even a message rejection might be
appropriate under some circumstances.
Special processing is performed if fewer than 24 bits are
available at the end of the data being encoded. A full
encoding quantum is always completed at the end of a body.
When fewer than 24 input bits are available in an input
group, zero bits are added (on the right) to form an
integral number of 6-bit groups. Output character positions
which are not required to represent actual input data are
set to the character "=". Since all base64 input is an
integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an
integral multiple of 24 bits; here, the final unit of
encoded output will be an integral multiple of 4 characters
with no "=" padding, (2) the final quantum of encoding input
is exactly 8 bits; here, the final unit of encoded output
will be two characters followed by two "=" padding
characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will
be three characters followed by one "=" padding character.
Care must be taken to use the proper octets for line breaks
if base64 encoding is applied directly to text material that
has not been converted to canonical form. In particular,
text line breaks should be converted into CRLF sequences
Borenstein & Freed [Page 18]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
prior to base64 encoding. The important thing to note is
that this may be done directly by the encoder rather than in
a prior canonicalization step in some implementations.
NOTE: There is no need to worry about quoting apparent
encapsulation boundaries within base64-encoded parts of
multipart entities because no hyphen characters are used in
the base64 encoding.
6 Additional Optional Content- Header Fields
6.1 Optional Content-ID Header Field
In constructing a high-level user agent, it may be desirable
to allow one body to make reference to another.
Accordingly, bodies may be labeled using the "Content-ID"
header field, which is syntactically identical to the
"Message-ID" header field:
Content-ID := msg-id
Like the Message-ID values, Content-ID values must be
generated to be as unique as possible.
6.2 Optional Content-Description Header Field
The ability to associate some descriptive information with a
given body is often desirable. For example, it may be useful
to mark an "image" body as "a picture of the Space Shuttle
Endeavor." Such text may be placed in the Content-
Description header field.
Content-Description := *text
The description is presumed to be given in the US-ASCII
character set, although the mechanism specified in [RFC-
1342] may be used for non-US-ASCII Content-Description
values.
Borenstein & Freed [Page 19]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
7 The Predefined Content-Type Values
This document defines seven initial Content-Type values and
an extension mechanism for private or experimental types.
Further standard types must be defined by new published
specifications. It is expected that most innovation in new
types of mail will take place as subtypes of the seven types
defined here. The most essential characteristics of the
seven content-types are summarized in Appendix G.
7.1 The Text Content-Type
The text Content-Type is intended for sending material which
is principally textual in form. It is the default Content-
Type. A "charset" parameter may be used to indicate the
character set of the body text. The primary subtype of text
is "plain". This indicates plain (unformatted) text. The
default Content-Type for Internet mail is "text/plain;
charset=us-ascii".
Beyond plain text, there are many formats for representing
what might be known as "extended text" -- text with embedded
formatting and presentation information. An interesting
characteristic of many such representations is that they are
to some extent readable even without the software that
interprets them. It is useful, then, to distinguish them,
at the highest level, from such unreadable data as images,
audio, or text represented in an unreadable form. In the
absence of appropriate interpretation software, it is
reasonable to show subtypes of text to the user, while it is
not reasonable to do so with most nontextual data.
Such formatted textual data should be represented using
subtypes of text. Plausible subtypes of text are typically
given by the common name of the representation format, e.g.,
"text/richtext".
7.1.1 The charset parameter
A critical parameter that may be specified in the Content-
Type field for text data is the character set. This is
specified with a "charset" parameter, as in:
Content-type: text/plain; charset=us-ascii
Unlike some other parameter values, the values of the
charset parameter are NOT case sensitive. The default
character set, which must be assumed in the absence of a
charset parameter, is US-ASCII.
An initial list of predefined character set names can be
found at the end of this section. Additional character sets
may be registered with IANA as described in Appendix F,
although the standardization of their use requires the usual
Borenstein & Freed [Page 20]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
IAB review and approval. Note that if the specified
character set includes 8-bit data, a Content-Transfer-
Encoding header field and a corresponding encoding on the
data are required in order to transmit the body via some
mail transfer protocols, such as SMTP.
The default character set, US-ASCII, has been the subject of
some confusion and ambiguity in the past. Not only were
there some ambiguities in the definition, there have been
wide variations in practice. In order to eliminate such
ambiguity and variations in the future, it is strongly
recommended that new user agents explicitly specify a
character set via the Content-Type header field. "US-ASCII"
does not indicate an arbitrary seven-bit character code, but
specifies that the body uses character coding that uses the
exact correspondence of codes to characters specified in
ASCII. National use variations of ISO 646 [ISO-646] are NOT
ASCII and their use in Internet mail is explicitly
discouraged. The omission of the ISO 646 character set is
deliberate in this regard. The character set name of "US-
ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only.
The character set name "ASCII" is reserved and must not be
used for any purpose.
NOTE: RFC 821 explicitly specifies "ASCII", and references
an earlier version of the American Standard. Insofar as one
of the purposes of specifying a Content-Type and character
set is to permit the receiver to unambiguously determine how
the sender intended the coded message to be interpreted,
assuming anything other than "strict ASCII" as the default
would risk unintentional and incompatible changes to the
semantics of messages now being transmitted. This also
implies that messages containing characters coded according
to national variations on ISO 646, or using code-switching
procedures (e.g., those of ISO 2022), as well as 8-bit or
multiple octet character encodings MUST use an appropriate
character set specification to be consistent with this
specification.
The complete US-ASCII character set is listed in [US-ASCII].
Note that the control characters including DEL (0-31, 127)
have no defined meaning apart from the combination CRLF
(ASCII values 13 and 10) indicating a new line. Two of the
characters have de facto meanings in wide use: FF (12) often
means "start subsequent text on the beginning of a new
page"; and TAB or HT (9) often (though not always) means
"move the cursor to the next available column after the
current position where the column number is a multiple of 8
(counting the first column as column 0)." Apart from this,
any use of the control characters or DEL in a body must be
part of a private agreement between the sender and
recipient. Such private agreements are discouraged and
should be replaced by the other capabilities of this
document.
Borenstein & Freed [Page 21]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
NOTE: Beyond US-ASCII, an enormous proliferation of
character sets is possible. It is the opinion of the IETF
working group that a large number of character sets is NOT a
good thing. We would prefer to specify a single character
set that can be used universally for representing all of the
world's languages in electronic mail. Unfortunately,
existing practice in several communities seems to point to
the continued use of multiple character sets in the near
future. For this reason, we define names for a small number
of character sets for which a strong constituent base
exists. It is our hope that ISO 10646 or some other
effort will eventually define a single world character set
which can then be specified for use in Internet mail, but in
the advance of that definition we cannot specify the use of
ISO 10646, Unicode, or any other character set whose
definition is, as of this writing, incomplete.
The defined charset values are:
US-ASCII -- as defined in [US-ASCII].
ISO-8859-X -- where "X" is to be replaced, as
necessary, for the parts of ISO-8859 [ISO-
8859]. Note that the ISO 646 character sets
have deliberately been omitted in favor of
their 8859 replacements, which are the
designated character sets for Internet mail.
As of the publication of this document, the
legitimate values for "X" are the digits 1
through 9.
Note that the character set used, if anything other than
US-ASCII, must always be explicitly specified in the
Content-Type field.
No other character set name may be used in Internet mail
without the publication of a formal specification and its
registration with IANA as described in Appendix F, or by
private agreement, in which case the character set name must
begin with "X-".
Implementors are discouraged from defining new character
sets for mail use unless absolutely necessary.
The "charset" parameter has been defined primarily for the
purpose of textual data, and is described in this section
for that reason. However, it is conceivable that non-
textual data might also wish to specify a charset value for
some purpose, in which case the same syntax and values
should be used.
In general, mail-sending software should always use the
"lowest common denominator" character set possible. For
example, if a body contains only US-ASCII characters, it
Borenstein & Freed [Page 22]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
should be marked as being in the US-ASCII character set, not
ISO-8859-1, which, like all the ISO-8859 family of character
sets, is a superset of US-ASCII. More generally, if a
widely-used character set is a subset of another character
set, and a body contains only characters in the widely-used
subset, it should be labeled as being in that subset. This
will increase the chances that the recipient will be able to
view the mail correctly.
7.1.2 The Text/plain subtype
The primary subtype of text is "plain". This indicates
plain (unformatted) text. The default Content-Type for
Internet mail, "text/plain; charset=us-ascii", describes
existing Internet practice, that is, it is the type of body
defined by RFC 822.
7.1.3 The Text/richtext subtype
In order to promote the wider interoperability of simple
formatted text, this document defines an extremely simple
subtype of "text", the "richtext" subtype. This subtype was
designed to meet the following criteria:
1. The syntax must be extremely simple to parse,
so that even teletype-oriented mail systems can
easily strip away the formatting information and
leave only the readable text.
2. The syntax must be extensible to allow for new
formatting commands that are deemed essential.
3. The capabilities must be extremely limited, to
ensure that it can represent no more than is
likely to be representable by the user's primary
word processor. While this limits what can be
sent, it increases the likelihood that what is
sent can be properly displayed.
4. The syntax must be compatible with SGML, so
that, with an appropriate DTD (Document Type
Definition, the standard mechanism for defining a
document type using SGML), a general SGML parser
could be made to parse richtext. However, despite
this compatibility, the syntax should be far
simpler than full SGML, so that no SGML knowledge
is required in order to implement it.
The syntax of "richtext" is very simple. It is assumed, at
the top-level, to be in the US-ASCII character set, unless
of course a different charset parameter was specified in the
Content-type field. All characters represent themselves,
with the exception of the "<" character (ASCII 60), which is
used to mark the beginning of a formatting command.
Borenstein & Freed [Page 23]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Formatting instructions consist of formatting commands
surrounded by angle brackets ("<>", ASCII 60 and 62). Each
formatting command may be no more than 40 characters in
length, all in US-ASCII, restricted to the alphanumeric and
hyphen ("-") characters. Formatting commands may be preceded
by a forward slash or solidus ("/", ASCII 47), making them
negations, and such negations must always exist to balance
the initial opening commands, except as noted below. Thus,
if the formatting command "<bold>" appears at some point,
there must later be a "</bold>" to balance it. There are
only three exceptions to this "balancing" rule: First, the
command "<lt>" is used to represent a literal "<" character.
Second, the command "<nl>" is used to represent a required
line break. (Otherwise, CRLFs in the data are treated as
equivalent to a single SPACE character.) Finally, the
command "<np>" is used to represent a page break. (NOTE:
The 40 character limit on formatting commands does not
include the "<", ">", or "/" characters that might be
attached to such commands.)
Initially defined formatting commands, not all of which will
be implemented by all richtext implementations, include:
Bold -- causes the subsequent text to be in a bold
font.
Italic -- causes the subsequent text to be in an italic
font.
Fixed -- causes the subsequent text to be in a fixed
width font.
Smaller -- causes the subsequent text to be in a
smaller font.
Bigger -- causes the subsequent text to be in a bigger
font.
Underline -- causes the subsequent text to be
underlined.
Center -- causes the subsequent text to be centered.
FlushLeft -- causes the subsequent text to be left
justified.
FlushRight -- causes the subsequent text to be right
justified.
Indent -- causes the subsequent text to be indented at
the left margin.
IndentRight -- causes the subsequent text to be
indented at the right margin.
Outdent -- causes the subsequent text to be outdented
at the left margin.
OutdentRight -- causes the subsequent text to be
outdented at the right margin.
SamePage -- causes the subsequent text to be grouped,
if possible, on one page.
Subscript -- causes the subsequent text to be
interpreted as a subscript.
Borenstein & Freed [Page 24]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Superscript -- causes the subsequent text to be
interpreted as a superscript.
Heading -- causes the subsequent text to be interpreted
as a page heading.
Footing -- causes the subsequent text to be interpreted
as a page footing.
ISO-8859-X (for any value of X that is legal as a
"charset" parameter) -- causes the subsequent text
to be interpreted as text in the appropriate
character set.
US-ASCII -- causes the subsequent text to be
interpreted as text in the US-ASCII character set.
Excerpt -- causes the subsequent text to be interpreted
as a textual excerpt from another source.
Typically this will be displayed using indentation
and an alternate font, but such decisions are up
to the viewer.
Paragraph -- causes the subsequent text to be
interpreted as a single paragraph, with
appropriate paragraph breaks (typically blank
space) before and after.
Signature -- causes the subsequent text to be
interpreted as a "signature". Some systems may
wish to display signatures in a smaller font or
otherwise set them apart from the main text of the
message.
Comment -- causes the subsequent text to be interpreted
as a comment, and hence not shown to the reader.
No-op -- has no effect on the subsequent text.
lt -- <lt> is replaced by a literal "<" character. No
balancing </lt> is allowed.
nl -- <nl> causes a line break. No balancing </nl> is
allowed.
np -- <np> causes a page break. No balancing </np> is
allowed.
Each positive formatting command affects all subsequent text
until the matching negative formatting command. Such pairs
of formatting commands must be properly balanced and nested.
Thus, a proper way to describe text in bold italics is:
<bold><italic>the-text</italic></bold>
or, alternately,
<italic><bold>the-text</bold></italic>
but, in particular, the following is illegal
richtext:
<bold><italic>the-text</bold></italic>
NOTE: The nesting requirement for formatting commands
imposes a slightly higher burden upon the composers of
Borenstein & Freed [Page 25]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
richtext bodies, but potentially simplifies richtext
displayers by allowing them to be stack-based. The main
goal of richtext is to be simple enough to make multifont,
formatted email widely readable, so that those with the
capability of sending it will be able to do so with
confidence. Thus slightly increased complexity in the
composing software was deemed a reasonable tradeoff for
simplified reading software. Nonetheless, implementors of
richtext readers are encouraged to follow the general
Internet guidelines of being conservative in what you send
and liberal in what you accept. Those implementations that
can do so are encouraged to deal reasonably with improperly
nested richtext.
Implementations must regard any unrecognized formatting
command as equivalent to "No-op", thus facilitating future
extensions to "richtext". Private extensions may be defined
using formatting commands that begin with "X-", by analogy
to Internet mail header field names.
It is worth noting that no special behavior is required for
the TAB (HT) character. It is recommended, however, that, at
least when fixed-width fonts are in use, the common
semantics of the TAB (HT) character should be observed,
namely that it moves to the next column position that is a
multiple of 8. (In other words, if a TAB (HT) occurs in
column n, where the leftmost column is column 0, then that
TAB (HT) should be replaced by 8-(n mod 8) SPACE
characters.)
Richtext also differentiates between "hard" and "soft" line
breaks. A line break (CRLF) in the richtext data stream is
interpreted as a "soft" line break, one that is included
only for purposes of mail transport, and is to be treated as
white space by richtext interpreters. To include a "hard"
line break (one that must be displayed as such), the "<nl>"
or "<paragraph> formatting constructs should be used. In
general, a soft line break should be treated as white space,
but when soft line breaks immediately follow a <nl> or a
</paragraph> tag they should be ignored rather than treated
as white space.
Putting all this together, the following "text/richtext"
body fragment:
<bold>Now</bold> is the time for
<italic>all</italic> good men
<smaller>(and <lt>women>)</smaller> to
<ignoreme></ignoreme> come
to the aid of their
<nl>
Borenstein & Freed [Page 26]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
beloved <nl><nl>country. <comment> Stupid
quote! </comment> -- the end
represents the following formatted text (which will, no
doubt, look cryptic in the text-only version of this
document):
Now is the time for all good men (and <women>) to
come to the aid of their
beloved
country. -- the end
Richtext conformance: A minimal richtext implementation is
one that simply converts "<lt>" to "<", converts CRLFs to
SPACE, converts <nl> to a newline according to local newline
convention, removes everything between a <comment> command
and the next balancing </comment> command, and removes all
other formatting commands (all text enclosed in angle
brackets).
NOTE ON THE RELATIONSHIP OF RICHTEXT TO SGML: Richtext is
decidedly not SGML, and must not be used to transport
arbitrary SGML documents. Those who wish to use SGML
document types as a mail transport format must define a new
text or application subtype, e.g., "text/sgml-dtd-whatever"
or "application/sgml-dtd-whatever", depending on the
perceived readability of the DTD in use. Richtext is
designed to be compatible with SGML, and specifically so
that it will be possible to define a richtext DTD if one is
needed. However, this does not imply that arbitrary SGML
can be called richtext, nor that richtext implementors have
any need to understand SGML; the description in this
document is a complete definition of richtext, which is far
simpler than complete SGML.
NOTE ON THE INTENDED USE OF RICHTEXT: It is recognized that
implementors of future mail systems will want rich text
functionality far beyond that currently defined for
richtext. The intent of richtext is to provide a common
format for expressing that functionality in a form in which
much of it, at least, will be understood by interoperating
software. Thus, in particular, software with a richer
notion of formatted text than richtext can still use
richtext as its basic representation, but can extend it with
new formatting commands and by hiding information specific
to that software system in richtext comments. As such
systems evolve, it is expected that the definition of
richtext will be further refined by future published
specifications, but richtext as defined here provides a
platform on which evolutionary refinements can be based.
IMPLEMENTATION NOTE: In some environments, it might be
impossible to combine certain richtext formatting commands,
Borenstein & Freed [Page 27]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
whereas in others they might be combined easily. For
example, the combination of <bold> and <italic> might
produce bold italics on systems that support such fonts, but
there exist systems that can make text bold or italicized,
but not both. In such cases, the most recently issued
recognized formatting command should be preferred.
One of the major goals in the design of richtext was to make
it so simple that even text-only mailers will implement
richtext-to-plain-text translators, thus increasing the
likelihood that multifont text will become "safe" to use
very widely. To demonstrate this simplicity, an extremely
simple 35-line C program that converts richtext input into
plain text output is included in Appendix D.
Borenstein & Freed [Page 28]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
7.2 The Multipart Content-Type
In the case of multiple part messages, in which one or more
different sets of data are combined in a single body, a
"multipart" Content-Type field must appear in the entity's
header. The body must then contain one or more "body parts,"
each preceded by an encapsulation boundary, and the last one
followed by a closing boundary. Each part starts with an
encapsulation boundary, and then contains a body part
consisting of header area, a blank line, and a body area.
Thus a body part is similar to an RFC 822 message in syntax,
but different in meaning.
A body part is NOT to be interpreted as actually being an
RFC 822 message. To begin with, NO header fields are
actually required in body parts. A body part that starts
with a blank line, therefore, is allowed and is a body part
for which all default values are to be assumed. In such a
case, the absence of a Content-Type header field implies
that the encapsulation is plain US-ASCII text. The only
header fields that have defined meaning for body parts are
those the names of which begin with "Content-". All other
header fields are generally to be ignored in body parts.
Although they should generally be retained in mail
processing, they may be discarded by gateways if necessary.
Such other fields are permitted to appear in body parts but
should not be depended on. "X-" fields may be created for
experimental or private purposes, with the recognition that
the information they contain may be lost at some gateways.
The distinction between an RFC 822 message and a body part
is subtle, but important. A gateway between Internet and
X.400 mail, for example, must be able to tell the difference
between a body part that contains an image and a body part
that contains an encapsulated message, the body of which is
an image. In order to represent the latter, the body part
must have "Content-Type: message", and its body (after the
blank line) must be the encapsulated message, with its own
"Content-Type: image" header field. The use of similar
syntax facilitates the conversion of messages to body parts,
and vice versa, but the distinction between the two must be
understood by implementors. (For the special case in which
all parts actually are messages, a "digest" subtype is also
defined.)
As stated previously, each body part is preceded by an
encapsulation boundary. The encapsulation boundary MUST NOT
appear inside any of the encapsulated parts. Thus, it is
crucial that the composing agent be able to choose and
specify the unique boundary that will separate the parts.
All present and future subtypes of the "multipart" type must
use an identical syntax. Subtypes may differ in their
semantics, and may impose additional restrictions on syntax,
Borenstein & Freed [Page 29]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
but must conform to the required syntax for the multipart
type. This requirement ensures that all conformant user
agents will at least be able to recognize and separate the
parts of any multipart entity, even of an unrecognized
subtype.
As stated in the definition of the Content-Transfer-Encoding
field, no encoding other than "7bit", "8bit", or "binary" is
permitted for entities of type "multipart". The multipart
delimiters and header fields are always 7-bit ASCII in any
case, and data within the body parts can be encoded on a
part-by-part basis, with Content-Transfer-Encoding fields
for each appropriate body part.
Mail gateways, relays, and other mail handling agents are
commonly known to alter the top-level header of an RFC 822
message. In particular, they frequently add, remove, or
reorder header fields. Such alterations are explicitly
forbidden for the body part headers embedded in the bodies
of messages of type "multipart."
7.2.1 Multipart: The common syntax
All subtypes of "multipart" share a common syntax, defined
in this section. A simple example of a multipart message
also appears in this section. An example of a more complex
multipart message is given in Appendix C.
The Content-Type field for multipart entities requires one
parameter, "boundary", which is used to specify the
encapsulation boundary. The encapsulation boundary is
defined as a line consisting entirely of two hyphen
characters ("-", decimal code 45) followed by the boundary
parameter value from the Content-Type header field.
NOTE: The hyphens are for rough compatibility with the
earlier RFC 934 method of message encapsulation, and for
ease of searching for the boundaries in some
implementations. However, it should be noted that multipart
messages are NOT completely compatible with RFC 934
encapsulations; in particular, they do not obey RFC 934
quoting conventions for embedded lines that begin with
hyphens. This mechanism was chosen over the RFC 934
mechanism because the latter causes lines to grow with each
level of quoting. The combination of this growth with the
fact that SMTP implementations sometimes wrap long lines
made the RFC 934 mechanism unsuitable for use in the event
that deeply-nested multipart structuring is ever desired.
Thus, a typical multipart Content-Type header field might
look like this:
Content-Type: multipart/mixed;
Borenstein & Freed [Page 30]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
boundary=gc0p4Jq0M2Yt08jU534c0p
This indicates that the entity consists of several parts,
each itself with a structure that is syntactically identical
to an RFC 822 message, except that the header area might be
completely empty, and that the parts are each preceded by
the line
--gc0p4Jq0M2Yt08jU534c0p
Note that the encapsulation boundary must occur at the
beginning of a line, i.e., following a CRLF, and that that
initial CRLF is considered to be part of the encapsulation
boundary rather than part of the preceding part. The
boundary must be followed immediately either by another CRLF
and the header fields for the next part, or by two CRLFs, in
which case there are no header fields for the next part (and
it is therefore assumed to be of Content-Type text/plain).
NOTE: The CRLF preceding the encapsulation line is
considered part of the boundary so that it is possible to
have a part that does not end with a CRLF (line break).
Body parts that must be considered to end with line breaks,
therefore, should have two CRLFs preceding the encapsulation
line, the first of which is part of the preceding body part,
and the second of which is part of the encapsulation
boundary.
The requirement that the encapsulation boundary begins with
a CRLF implies that the body of a multipart entity must
itself begin with a CRLF before the first encapsulation line
-- that is, if the "preamble" area is not used, the entity
headers must be followed by TWO CRLFs. This is indeed how
such entities should be composed. A tolerant mail reading
program, however, may interpret a body of type multipart
that begins with an encapsulation line NOT initiated by a
CRLF as also being an encapsulation boundary, but a
compliant mail sending program must not generate such
entities.
Encapsulation boundaries must not appear within the
encapsulations, and must be no longer than 70 characters,
not counting the two leading hyphens.
The encapsulation boundary following the last body part is a
distinguished delimiter that indicates that no further body
parts will follow. Such a delimiter is identical to the
previous delimiters, with the addition of two more hyphens
at the end of the line:
--gc0p4Jq0M2Yt08jU534c0p--
There appears to be room for additional information prior to
the first encapsulation boundary and following the final
Borenstein & Freed [Page 31]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
boundary. These areas should generally be left blank, and
implementations should ignore anything that appears before
the first boundary or after the last one.
NOTE: These "preamble" and "epilogue" areas are not used
because of the lack of proper typing of these parts and the
lack of clear semantics for handling these areas at
gateways, particularly X.400 gateways.
NOTE: Because encapsulation boundaries must not appear in
the body parts being encapsulated, a user agent must
exercise care to choose a unique boundary. The boundary in
the example above could have been the result of an algorithm
designed to produce boundaries with a very low probability
of already existing in the data to be encapsulated without
having to prescan the data. Alternate algorithms might
result in more 'readable' boundaries for a recipient with an
old user agent, but would require more attention to the
possibility that the boundary might appear in the
encapsulated part. The simplest boundary possible is
something like "---", with a closing boundary of "-----".
As a very simple example, the following multipart message
has two parts, both of them plain text, one of them
explicitly typed and one of them implicitly typed:
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple
boundary"
This is the preamble. It is to be ignored, though it
is a handy place for mail composers to include an
explanatory note to non-MIME compliant readers.
--simple boundary
This is implicitly typed plain ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
This is explicitly typed plain ASCII text.
It DOES end with a linebreak.
--simple boundary--
This is the epilogue. It is also to be ignored.
The use of a Content-Type of multipart in a body part within
another multipart entity is explicitly allowed. In such
cases, for obvious reasons, care must be taken to ensure
that each nested multipart entity must use a different
boundary delimiter. See Appendix C for an example of nested
Borenstein & Freed [Page 32]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
multipart entities.
The use of the multipart Content-Type with only a single
body part may be useful in certain contexts, and is
explicitly permitted.
The only mandatory parameter for the multipart Content-Type
is the boundary parameter, which consists of 1 to 70
characters from a set of characters known to be very robust
through email gateways, and NOT ending with white space.
(If a boundary appears to end with white space, the white
space must be presumed to have been added by a gateway, and
should be deleted.) It is formally specified by the
following BNF:
boundary := 0*69<bchars> bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /
"_"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
Overall, the body of a multipart entity may be specified as
follows:
multipart-body := preamble 1*encapsulation
close-delimiter epilogue
encapsulation := delimiter CRLF body-part
delimiter := CRLF "--" boundary ; taken from Content-Type
field.
; when content-type is
multipart
; There must be no space
; between "--" and boundary.
close-delimiter := delimiter "--" ; Again, no space before
"--"
preamble := *text ; to be ignored upon
receipt.
epilogue := *text ; to be ignored upon
receipt.
body-part = <"message" as defined in RFC 822,
with all header fields optional, and with the
specified delimiter not occurring anywhere in
the message body, either on a line by itself
or as a substring anywhere. Note that the
Borenstein & Freed [Page 33]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
semantics of a part differ from the semantics
of a message, as described in the text.>
NOTE: Conspicuously missing from the multipart type is a
notion of structured, related body parts. In general, it
seems premature to try to standardize interpart structure
yet. It is recommended that those wishing to provide a more
structured or integrated multipart messaging facility should
define a subtype of multipart that is syntactically
identical, but that always expects the inclusion of a
distinguished part that can be used to specify the structure
and integration of the other parts, probably referring to
them by their Content-ID field. If this approach is used,
other implementations will not recognize the new subtype,
but will treat it as the primary subtype (multipart/mixed)
and will thus be able to show the user the parts that are
recognized.
7.2.2 The Multipart/mixed (primary) subtype
The primary subtype for multipart, "mixed", is intended for
use when the body parts are independent and intended to be
displayed serially. Any multipart subtypes that an
implementation does not recognize should be treated as being
of subtype "mixed".
7.2.3 The Multipart/alternative subtype
The multipart/alternative type is syntactically identical to
multipart/mixed, but the semantics are different. In
particular, each of the parts is an "alternative" version of
the same information. User agents should recognize that the
content of the various parts are interchangeable. The user
agent should either choose the "best" type based on the
user's environment and preferences, or offer the user the
available alternatives. In general, choosing the best type
means displaying only the LAST part that can be displayed.
This may be used, for example, to send mail in a fancy text
format in such a way that it can easily be displayed
anywhere:
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
...plain text version of message goes here....
Borenstein & Freed [Page 34]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
--boundary42
Content-Type: text/richtext
.... richtext version of same message goes here ...
--boundary42
Content-Type: text/x-whatever
.... fanciest formatted version of same message goes here
...
--boundary42--
In this example, users whose mail system understood the
"text/x-whatever" format would see only the fancy version,
while other users would see only the richtext or plain text
version, depending on the capabilities of their system.
In general, user agents that compose multipart/alternative
entities should place the body parts in increasing order of
preference, that is, with the preferred format last. For
fancy text, the sending user agent should put the plainest
format first and the richest format last. Receiving user
agents should pick and display the last format they are
capable of displaying. In the case where one of the
alternatives is itself of type "multipart" and contains
unrecognized sub-parts, the user agent may choose either to
show that alternative, an earlier alternative, or both.
NOTE: From an implementor's perspective, it might seem more
sensible to reverse this ordering, and have the plainest
alternative last. However, placing the plainest alternative
first is the friendliest possible option when
mutlipart/alternative entities are viewed using a non-MIME-
compliant mail reader. While this approach does impose some
burden on compliant mail readers, interoperability with
older mail readers was deemed to be more important in this
case.
It may be the case that some user agents, if they can
recognize more than one of the formats, will prefer to offer
the user the choice of which format to view. This makes
sense, for example, if mail includes both a nicely-formatted
image version and an easily-edited text version. What is
most critical, however, is that the user not automatically
be shown multiple versions of the same data. Either the
user should be shown the last recognized version or should
explicitly be given the choice.
Borenstein & Freed [Page 35]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
7.2.4 The Multipart/digest subtype
This document defines a "digest" subtype of the multipart
Content-Type. This type is syntactically identical to
multipart/mixed, but the semantics are different. In
particular, in a digest, the default Content-Type value for
a body part is changed from "text/plain" to
"message/rfc822". This is done to allow a more readable
digest format that is largely compatible (except for the
quoting convention) with RFC 934.
A digest in this format might, then, look something like
this:
From: Moderator-Address
MIME-Version: 1.0
Subject: Internet Digest, volume 42
Content-Type: multipart/digest;
boundary="---- next message ----"
------ next message ----
From: someone-else
Subject: my opinion
...body goes here ...
------ next message ----
From: someone-else-again
Subject: my different opinion
... another body goes here...
------ next message ------
7.2.5 The Multipart/parallel subtype
This document defines a "parallel" subtype of the multipart
Content-Type. This type is syntactically identical to
multipart/mixed, but the semantics are different. In
particular, in a parallel entity, all of the parts are
intended to be presented in parallel, i.e., simultaneously,
on hardware and software that are capable of doing so.
Composing agents should be aware that many mail readers will
lack this capability and will show the parts serially in any
event.
Borenstein & Freed [Page 36]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
7.3 The Message Content-Type
It is frequently desirable, in sending mail, to encapsulate
another mail message. For this common operation, a special
Content-Type, "message", is defined. The primary subtype,
message/rfc822, has no required parameters in the Content-
Type field. Additional subtypes, "partial" and "External-
body", do have required parameters. These subtypes are
explained below.
NOTE: It has been suggested that subtypes of message might
be defined for forwarded or rejected messages. However,
forwarded and rejected messages can be handled as multipart
messages in which the first part contains any control or
descriptive information, and a second part, of type
message/rfc822, is the forwarded or rejected message.
Composing rejection and forwarding messages in this manner
will preserve the type information on the original message
and allow it to be correctly presented to the recipient, and
hence is strongly encouraged.
As stated in the definition of the Content-Transfer-Encoding
field, no encoding other than "7bit", "8bit", or "binary" is
permitted for messages or parts of type "message". The
message header fields are always US-ASCII in any case, and
data within the body can still be encoded, in which case the
Content-Transfer-Encoding header field in the encapsulated
message will reflect this. Non-ASCII text in the headers of
an encapsulated message can be specified using the
mechanisms described in [RFC-1342].
Mail gateways, relays, and other mail handling agents are
commonly known to alter the top-level header of an RFC 822
message. In particular, they frequently add, remove, or
reorder header fields. Such alterations are explicitly
forbidden for the encapsulated headers embedded in the
bodies of messages of type "message."
7.3.1 The Message/rfc822 (primary) subtype
A Content-Type of "message/rfc822" indicates that the body
contains an encapsulated message, with the syntax of an RFC
822 message.
7.3.2 The Message/Partial subtype
A subtype of message, "partial", is defined in order to
allow large objects to be delivered as several separate
pieces of mail and automatically reassembled by the
receiving user agent. (The concept is similar to IP
fragmentation/reassembly in the basic Internet Protocols.)
This mechanism can be used when intermediate transport
agents limit the size of individual messages that can be
sent. Content-Type "message/partial" thus indicates that
Borenstein & Freed [Page 37]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
the body contains a fragment of a larger message.
Three parameters must be specified in the Content-Type field
of type message/partial: The first, "id", is a unique
identifier, as close to a world-unique identifier as
possible, to be used to match the parts together. (In
general, the identifier is essentially a message-id; if
placed in double quotes, it can be any message-id, in
accordance with the BNF for "parameter" given earlier in
this specification.) The second, "number", an integer, is
the part number, which indicates where this part fits into
the sequence of fragments. The third, "total", another
integer, is the total number of parts. This third subfield
is required on the final part, and is optional on the
earlier parts. Note also that these parameters may be given
in any order.
Thus, part 2 of a 3-part message may have either of the
following header fields:
Content-Type: Message/Partial;
number=2; total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
Content-Type: Message/Partial;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
number=2
But part 3 MUST specify the total number of parts:
Content-Type: Message/Partial;
number=3; total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
Note that part numbering begins with 1, not 0.
When the parts of a message broken up in this manner are put
together, the result is a complete RFC 822 format message,
which may have its own Content-Type header field, and thus
may contain any other data type.
Message fragmentation and reassembly: The semantics of a
reassembled partial message must be those of the "inner"
message, rather than of a message containing the inner
message. This makes it possible, for example, to send a
large audio message as several partial messages, and still
have it appear to the recipient as a simple audio message
rather than as an encapsulated message containing an audio
message. That is, the encapsulation of the message is
considered to be "transparent".
When generating and reassembling the parts of a
message/partial message, the headers of the encapsulated
message must be merged with the headers of the enclosing
Borenstein & Freed [Page 38]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
entities. In this process the following rules must be
observed:
(1) All of the headers from the initial enclosing
entity (part one), except those that start with
"Content-" and "Message-ID", must be copied, in
order, to the new message.
(2) Only those headers in the enclosed message
which start with "Content-" and "Message-ID" must
be appended, in order, to the headers of the new
message. Any headers in the enclosed message
which do not start with "Content-" (except for
"Message-ID") will be ignored.
(3) All of the headers from the second and any
subsequent messages will be ignored.
For example, if an audio message is broken into two parts,
the first part might look something like this:
X-Weird-Header-1: Foo
From: Bill@host.com
To: joe@otherhost.com
Subject: Audio mail
Message-ID: id1@host.com
MIME-Version: 1.0
Content-type: message/partial;
id="ABC@host.com";
number=1; total=2
X-Weird-Header-1: Bar
X-Weird-Header-2: Hello
Message-ID: anotherid@foo.com
Content-type: audio/basic
Content-transfer-encoding: base64
... first half of encoded audio data goes here...
and the second half might look something like this:
From: Bill@host.com
To: joe@otherhost.com
Subject: Audio mail
MIME-Version: 1.0
Message-ID: id2@host.com
Content-type: message/partial;
id="ABC@host.com"; number=2; total=2
... second half of encoded audio data goes here...
Then, when the fragmented message is reassembled, the
resulting message to be displayed to the user should look
something like this:
Borenstein & Freed [Page 39]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
X-Weird-Header-1: Foo
From: Bill@host.com
To: joe@otherhost.com
Subject: Audio mail
Message-ID: anotherid@foo.com
MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64
... first half of encoded audio data goes here...
... second half of encoded audio data goes here...
It should be noted that, because some message transfer
agents may choose to automatically fragment large messages,
and because such agents may use different fragmentation
thresholds, it is possible that the pieces of a partial
message, upon reassembly, may prove themselves to comprise a
partial message. This is explicitly permitted.
It should also be noted that the inclusion of a "References"
field in the headers of the second and subsequent pieces of
a fragmented message that references the Message-Id on the
previous piece may be of benefit to mail readers that
understand and track references. However, the generation of
such "References" fields is entirely optional.
7.3.3 The Message/External-Body subtype
The external-body subtype indicates that the actual body
data are not included, but merely referenced. In this case,
the parameters describe a mechanism for accessing the
external data.
When a message body or body part is of type
"message/external-body", it consists of a header, two
consecutive CRLFs, and the message header for the
encapsulated message. If another pair of consecutive CRLFs
appears, this of course ends the message header for the
encapsulated message. However, since the encapsulated
message's body is itself external, it does NOT appear in the
area that follows. For example, consider the following
message:
Content-type: message/external-body; access-
type=local-file;
name=/u/nsb/Me.gif
Content-type: image/gif
THIS IS NOT REALLY THE BODY!
The area at the end, which might be called the "phantom
body", is ignored for most external-body messages. However,
it may be used to contain auxilliary information for some
Borenstein & Freed [Page 40]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
such messages, as indeed it is when the access-type is
"mail-server". Of the access-types defined by this
document, the phantom body is used only when the access-type
is "mail-server". In all other cases, the phantom body is
ignored.
The only always-mandatory parameter for message/external-
body is "access-type"; all of the other parameters may be
mandatory or optional depending on the value of access-type.
ACCESS-TYPE -- One or more case-insensitive words,
comma-separated, indicating supported access
mechanisms by which the file or data may be
obtained. Values include, but are not limited to,
"FTP", "ANON-FTP", "TFTP", "AFS", "LOCAL-FILE",
and "MAIL-SERVER". Future values, except for
experimental values beginning with "X-", must be
registered with IANA, as described in Appendix F .
In addition, the following two parameters are optional for
ALL access-types:
EXPIRATION -- The date (in the RFC 822 "date-time"
syntax, as extended by RFC 1123 to permit 4 digits
in the date field) after which the existence of
the external data is not guaranteed.
SIZE -- The size (in octets) of the data. The
intent of this parameter is to help the recipient
decide whether or not to expend the necessary
resources to retrieve the external data.
PERMISSION -- A field that indicates whether or
not it is expected that clients might also attempt
to overwrite the data. By default, or if
permission is "read", the assumption is that they
are not, and that if the data is retrieved once,
it is never needed again. If PERMISSION is "read-
write", this assumption is invalid, and any local
copy must be considered no more than a cache.
"Read" and "Read-write" are the only defined
values of permission.
The precise semantics of the access-types defined here are
described in the sections that follow.
7.3.3.1 The "ftp" and "tftp" access-types
An access-type of FTP or TFTP indicates that the message
body is accessible as a file using the FTP [RFC-959] or TFTP
[RFC-783] protocols, respectively. For these access-types,
the following additional parameters are mandatory:
Borenstein & Freed [Page 41]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
NAME -- The name of the file that contains the
actual body data.
SITE -- A machine from which the file may be
obtained, using the given protocol
Before the data is retrieved, using these protocols, the
user will generally need to be asked to provide a login id
and a password for the machine named by the site parameter.
In addition, the following optional parameters may also
appear when the access-type is FTP or ANON-FTP:
DIRECTORY -- A directory from which the data named
by NAME should be retrieved.
MODE -- A transfer mode for retrieving the
information, e.g. "image".
7.3.3.2 The "anon-ftp" access-type
The "anon-ftp" access-type is identical to the "ftp" access
type, except that the user need not be asked to provide a
name and password for the specified site. Instead, the ftp
protocol will be used with login "anonymous" and a password
that corresponds to the user's email address.
7.3.3.3 The "local-file" and "afs" access-types
An access-type of "local-file" indicates that the actual
body is accessible as a file on the local machine. An
access-type of "afs" indicates that the file is accessible
via the global AFS file system. In both cases, only a
single parameter is required:
NAME -- The name of the file that contains the
actual body data.
The following optional parameter may be used to describe the
locality of reference for the data, that is, the site or
sites at which the file is expected to be visible:
SITE -- A domain specifier for a machine or set of
machines that are known to have access to the data
file. Asterisks may be used for wildcard matching
to a part of a domain name, such as
"*.bellcore.com", to indicate a set of machines on
which the data should be directly visible, while a
single asterisk may be used to indicate a file
that is expected to be universally available,
e.g., via a global file system.
7.3.3.4 The "mail-server" access-type
Borenstein & Freed [Page 42]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
The "mail-server" access-type indicates that the actual body
is available from a mail server. The mandatory parameter
for this access-type is:
SERVER -- The email address of the mail server
from which the actual body data can be obtained.
Because mail servers accept a variety of syntax, some of
which is multiline, the full command to be sent to a mail
server is not included as a parameter on the content-type
line. Instead, it may be provided as the "phantom body"
when the content-type is message/external-body and the
access-type is mail-server.
Note that MIME does not define a mail server syntax.
Rather, it allows the inclusion of arbitrary mail server
commands in the phantom body. Implementations should
include the phantom body in the body of the message it sends
to the mail server address to retrieve the relevant data.
Borenstein & Freed [Page 43]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
7.3.3.5 Examples and Further Explanations
With the emerging possibility of very wide-area file
systems, it becomes very hard to know in advance the set of
machines where a file will and will not be accessible
directly from the file system. Therefore it may make sense
to provide both a file name, to be tried directly, and the
name of one or more sites from which the file is known to be
accessible. An implementation can try to retrieve remote
files using FTP or any other protocol, using anonymous file
retrieval or prompting the user for the necessary name and
password. If an external body is accessible via multiple
mechanisms, the sender may include multiple parts of type
message/external-body within an entity of type
multipart/alternative.
However, the external-body mechanism is not intended to be
limited to file retrieval, as shown by the mail-server
access-type. Beyond this, one can imagine, for example,
using a video server for external references to video clips.
If an entity is of type "message/external-body", then the
body of the entity will contain the header fields of the
encapsulated message. The body itself is to be found in the
external location. This means that if the body of the
"message/external-body" message contains two consecutive
CRLFs, everything after those pairs is NOT part of the
message itself. For most message/external-body messages,
this trailing area must simply be ignored. However, it is a
convenient place for additional data that cannot be included
in the content-type header field. In particular, if the
"access-type" value is "mail-server", then the trailing area
must contain commands to be sent to the mail server at the
address given by NAME@SITE, where NAME and SITE are the
values of the NAME and SITE parameters, respectively.
The embedded message header fields which appear in the body
of the message/external-body data can be used to declare the
Content-type of the external body. Thus a complete
message/external-body message, referring to a document in
PostScript format, might look like this:
From: Whomever
Subject: whatever
MIME-Version: 1.0
Message-ID: id1@host.com
Content-Type: multipart/alternative; boundary=42
--42
Content-Type: message/external-body;
name="BodyFormats.ps";
Borenstein & Freed [Page 44]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
site="thumper.bellcore.com";
access-type=ANON-FTP;
directory="pub";
mode="image";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
--42
Content-Type: message/external-body;
name="/u/nsb/writing/rfcs/RFC-XXXX.ps";
site="thumper.bellcore.com";
access-type=AFS
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
--42
Content-Type: message/external-body;
access-type=mail-server
server="listserv@bogus.bitnet";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
get rfc-xxxx doc
--42--
Like the message/partial type, the message/external-body
type is intended to be transparent, that is, to convey the
data type in the external body rather than to convey a
message with a body of that type. Thus the headers on the
outer and inner parts must be merged using the same rules as
for message/partial. In particular, this means that the
Content-type header is overridden, but the From and Subject
headers are preserved.
Note that since the external bodies are not transported as
mail, they need not conform to the 7-bit and line length
requirements, but might in fact be binary files. Thus a
Content-Transfer-Encoding is not generally necessary, though
it is permitted.
Note that the body of a message of type "message/external-
body" is governed by the basic syntax for an RFC 822
message. In particular, anything before the first
consecutive pair of CRLFs is header information, while
anything after it is body information, which is ignored for
most access-types.
Borenstein & Freed [Page 45]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
7.4 The Application Content-Type
The "application" Content-Type is to be used for data which
do not fit in any of the other categories, and particularly
for data to be processed by mail-based uses of application
programs. This is information which must be processed by an
application before it is viewable or usable to a user.
Expected uses for Content-Type application include mail-
based file transfer, spreadsheets, data for mail-based
scheduling systems, and languages for "active"
(computational) email. (The latter, in particular, can pose
security problems which should be understood by
implementors, and are considered in detail in the discussion
of the application/PostScript content-type.)
For example, a meeting scheduler might define a standard
representation for information about proposed meeting dates.
An intelligent user agent would use this information to
conduct a dialog with the user, and might then send further
mail based on that dialog. More generally, there have been
several "active" messaging languages developed in which
programs in a suitably specialized language are sent through
the mail and automatically run in the recipient's
environment.
Such applications may be defined as subtypes of the
"application" Content-Type. This document defines three
subtypes: octet-stream, ODA, and PostScript.
In general, the subtype of application will often be the
name of the application for which the data are intended.
This does not mean, however, that any application program
name may be used freely as a subtype of application. Such
usages must be registered with IANA, as described in
Appendix F.
7.4.1 The Application/Octet-Stream (primary) subtype
The primary subtype of application, "octet-stream", may be
used to indicate that a body contains binary data. The set
of possible parameters includes, but is not limited to:
NAME -- a suggested name for the binary data if
stored as a file.
TYPE -- the general type or category of binary
data. This is intended as information for the
human recipient rather than for any automatic
processing.
CONVERSIONS -- the set of operations that have
been performed on the data before putting it in
the mail (and before any Content-Transfer-Encoding
that might have been applied). If multiple
Borenstein & Freed [Page 46]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
conversions have occurred, they must be separated
by commas and specified in the order they were
applied -- that is, the leftmost conversion must
have occurred first, and conversions are undone
from right to left. Note that NO conversion
values are defined by this document. Any
conversion values that that do not begin with "X-"
must be preceded by a published specification and
by registration with IANA, as described in
Appendix F.
PADDING -- the number of bits of padding that were
appended to the bitstream comprising the actual
contents to produce the enclosed byte-oriented
data. This is useful for enclosing a bitstream in
a body when the total number of bits is not a
multiple of the byte size.
The values for these attributes are left undefined at
present, but may require specification in the future. An
example of a common (though UNIX-specific) usage might be:
Content-Type: application/octet-stream;
name=foo.tar.Z; type=tar;
conversions="x-encrypt,x-compress"
However, it should be noted that the use of such conversions
is explicitly discouraged due to a lack of portability and
standardization. The use of uuencode is particularly
discouraged, in favor of the Content-Transfer-Encoding
mechanism, which is both more standardized and more portable
across mail boundaries.
The recommended action for an implementation that receives
application/octet-stream mail is to simply offer to put the
data in a file, with any Content-Transfer-Encoding undone,
or perhaps to use it as input to a user-specified process.
To reduce the danger of transmitting rogue programs through
the mail, it is strongly recommended that implementations
NOT implement a path-search mechanism whereby an arbitrary
program named in the Content-Type parameter (e.g., an
"interpreter=" parameter) is found and executed using the
mail body as input.
7.4.2 The Application/PostScript subtype
A Content-Type of "application/postscript" indicates a
PostScript program. The language is defined in
[POSTSCRIPT]. It is recommended that Postscript as sent
through email should use Postscript document structuring
conventions if at all possible, and correctly.
Borenstein & Freed [Page 47]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
The execution of general-purpose PostScript interpreters
entails serious security risks, and implementors are
discouraged from simply sending PostScript email bodies to
"off-the-shelf" interpreters. While it is usually safe to
send PostScript to a printer, where the potential for harm
is greatly constrained, implementors should consider all of
the following before they add interactive display of
PostScript bodies to their mail readers.
The remainder of this section outlines some, though probably
not all, of the possible problems with sending PostScript
through the mail.
Dangerous operations in the PostScript language include, but
may not be limited to, the PostScript operators deletefile,
renamefile, filenameforall, and file. File is only
dangerous when applied to something other than standard
input or output. Implementations may also define additional
nonstandard file operators; these may also pose a threat to
security. Filenameforall, the wildcard file search
operator, may appear at first glance to be harmless. Note,
however, that this operator has the potential to reveal
information about what files the recipient has access to,
and this information may itself be sensitive. Message
senders should avoid the use of potentially dangerous file
operators, since these operators are quite likely to be
unavailable in secure PostScript implementations. Message-
receiving and -displaying software should either completely
disable all potentially dangerous file operators or take
special care not to delegate any special authority to their
operation. These operators should be viewed as being done by
an outside agency when interpreting PostScript documents.
Such disabling and/or checking should be done completely
outside of the reach of the PostScript language itself; care
should be taken to insure that no method exists for
reenabling full-function versions of these operators.
The PostScript language provides facilities for exiting the
normal interpreter, or server, loop. Changes made in this
"outer" environment are customarily retained across
documents, and may in some cases be retained semipermanently
in nonvolatile memory. The operators associated with exiting
the interpreter loop have the potential to interfere with
subsequent document processing. As such, their unrestrained
use constitutes a threat of service denial. PostScript
operators that exit the interpreter loop include, but may
not be limited to, the exitserver and startjob operators.
Message-sending software should not generate PostScript that
depends on exiting the interpreter loop to operate. The
ability to exit will probably be unavailable in secure
PostScript implementations. Message-receiving and
-displaying software should, if possible, disable the
ability to make retained changes to the PostScript
environment. Eliminate the startjob and exitserver commands.
Borenstein & Freed [Page 48]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
If these commands cannot be eliminated, at least set the
password associated with them to a hard-to-guess value.
PostScript provides operators for setting system-wide and
device-specific parameters. These parameter settings may be
retained across jobs and may potentially pose a threat to
the correct operation of the interpreter. The PostScript
operators that set system and device parameters include, but
may not be limited to, the setsystemparams and setdevparams
operators. Message-sending software should not generate
PostScript that depends on the setting of system or device
parameters to operate correctly. The ability to set these
parameters will probably be unavailable in secure PostScript
implementations. Message-receiving and -displaying software
should, if possible, disable the ability to change system
and device parameters. If these operators cannot be
disabled, at least set the password associated with them to
a hard-to-guess value.
Some PostScript implementations provide nonstandard
facilities for the direct loading and execution of machine
code. Such facilities are quite obviously open to
substantial abuse. Message-sending software should not
make use of such features. Besides being totally hardware-
specific, they are also likely to be unavailable in secure
implementations of PostScript. Message-receiving and
-displaying software should not allow such operators to be
used if they exist.
PostScript is an extensible language, and many, if not most,
implementations of it provide a number of their own
extensions. This document does not deal with such extensions
explicitly since they constitute an unknown factor.
Message-sending software should not make use of nonstandard
extensions; they are likely to be missing from some
implementations. Message-receiving and -displaying software
should make sure that any nonstandard PostScript operators
are secure and don't present any kind of threat.
It is possible to write PostScript that consumes huge
amounts of various system resources. It is also possible to
write PostScript programs that loop infinitely. Both types
of programs have the potential to cause damage if sent to
unsuspecting recipients. Message-sending software should
avoid the construction and dissemination of such programs,
which is antisocial. Message-receiving and -displaying
software should provide appropriate mechanisms to abort
processing of a document after a reasonable amount of time
has elapsed. In addition, PostScript interpreters should be
limited to the consumption of only a reasonable amount of
any given system resource.
Finally, bugs may exist in some PostScript interpreters
which could possibly be exploited to gain unauthorized
Borenstein & Freed [Page 49]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
access to a recipient's system. Apart from noting this
possibility, there is no specific action to take to prevent
this, apart from the timely correction of such bugs if any
are found.
7.4.3 The Application/ODA subtype
The "ODA" subtype of application is used to indicate that a
body contains information encoded according to the Office
Document Architecture [ODA] standards, using the ODIF
representation format. For application/oda, the Content-
Type line should also specify an attribute/value pair that
indicates the document application profile (DAP), using the
key word "profile". Thus an appropriate header field might
look like this:
Content-Type: application/oda; profile=Q112
Consult the ODA standard [ODA] for further information.
Borenstein & Freed [Page 50]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
7.5 The Image Content-Type
A Content-Type of "image" indicates that the bodycontains an
image. The subtype names the specific image format. These
names are case insensitive. Two initial subtypes are "jpeg"
for the JPEG format, JFIF encoding, and "gif" for GIF format
[GIF].
The list of image subtypes given here is neither exclusive
nor exhaustive, and is expected to grow as more types are
registered with IANA, as described in Appendix F.
7.6 The Audio Content-Type
A Content-Type of "audio" indicates that the body contains
audio data. Although there is not yet a consensus on an
"ideal" audio format for use with computers, there is a
pressing need for a format capable of providing
interoperable behavior.
The initial subtype of "basic" is specified to meet this
requirement by providing an absolutely minimal lowest common
denominator audio format. It is expected that richer
formats for higher quality and/or lower bandwidth audio will
be defined by a later document.
The content of the "audio/basic" subtype is audio encoded
using 8-bit ISDN u-law [PCM]. When this subtype is present,
a sample rate of 8000 Hz and a single channel is assumed.
7.7 The Video Content-Type
A Content-Type of "video" indicates that the body contains a
time-varying-picture image, possibly with color and
coordinated sound. The term "video" is used extremely
generically, rather than with reference to any particular
technology or format, and is not meant to preclude subtypes
such as animated drawings encoded compactly. The subtype
"mpeg" refers to video coded according to the MPEG standard
[MPEG].
Note that although in general this document strongly
discourages the mixing of multiple media in a single body,
it is recognized that many so-called "video" formats include
a representation for synchronized audio, and this is
explicitly permitted for subtypes of "video".
7.8 Experimental Content-Type Values
A Content-Type value beginning with the characters "X-" is a
private value, to be used by consenting mail systems by
mutual agreement. Any format without a rigorous and public
definition must be named with an "X-" prefix, and publicly
specified values shall never begin with "X-". (Older
Borenstein & Freed [Page 51]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
versions of the widely-used Andrew system use the "X-BE2"
name, so new systems should probably choose a different
name.)
In general, the use of "X-" top-level types is strongly
discouraged. Implementors should invent subtypes of the
existing types whenever possible. The invention of new
types is intended to be restricted primarily to the
development of new media types for email, such as digital
odors or holography, and not for new data formats in
general. In many cases, a subtype of application will be
more appropriate than a new top-level type.
Borenstein & Freed [Page 52]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Summary
Using the MIME-Version, Content-Type, and Content-Transfer-
Encoding header fields, it is possible to include, in a
standardized way, arbitrary types of data objects with RFC
822 conformant mail messages. No restrictions imposed by
either RFC 821 or RFC 822 are violated, and care has been
taken to avoid problems caused by additional restrictions
imposed by the characteristics of some Internet mail
transport mechanisms (see Appendix B). The "multipart" and
"message" Content-Types allow mixing and hierarchical
structuring of objects of different types in a single
message. Further Content-Types provide a standardized
mechanism for tagging messages or body parts as audio,
image, or several other kinds of data. A distinguished
parameter syntax allows further specification of data format
details, particularly the specification of alternate
character sets. Additional optional header fields provide
mechanisms for certain extensions deemed desirable by many
implementors. Finally, a number of useful Content-Types are
defined for general use by consenting user agents, notably
text/richtext, message/partial, and message/external-body.
Borenstein & Freed [Page 53]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Acknowledgements
This document is the result of the collective effort of a
large number of people, at several IETF meetings, on the
IETF-SMTP and IETF-822 mailing lists, and elsewhere.
Although any enumeration seems doomed to suffer from
egregious omissions, the following are among the many
contributors to this effort:
Harald Tveit Alvestrand Timo Lehtinen
Randall Atkinson John R. MacMillan
Philippe Brandon Rick McGowan
Kevin Carosso Leo Mclaughlin
Uhhyung Choi Goli Montaser-Kohsari
Cristian Constantinof Keith Moore
Mark Crispin Tom Moore
Dave Crocker Erik Naggum
Terry Crowley Mark Needleman
Walt Daniels John Noerenberg
Frank Dawson Mats Ohrman
Hitoshi Doi Julian Onions
Kevin Donnelly Michael Patton
Keith Edwards David J. Pepper
Chris Eich Blake C. Ramsdell
Johnny Eriksson Luc Rooijakkers
Craig Everhart Marshall T. Rose
Patrik Faeltstroem Jonathan Rosenberg
Erik E. Fair Jan Rynning
Roger Fajman Harri Salminen
Alain Fontaine Michael Sanderson
James M. Galvin Masahiro Sekiguchi
Philip Gladstone Mark Sherman
Thomas Gordon Keld Simonsen
Phill Gross Bob Smart
James Hamilton Peter Speck
Steve Hardcastle-Kille Henry Spencer
David Herron Einar Stefferud
Bruce Howard Michael Stein
Bill Janssen Klaus Steinberger
Olle Jaernefors Peter Svanberg
Risto Kankkunen James Thompson
Phil Karn Steve Uhler
Alan Katz Stuart Vance
Tim Kehres Erik van der Poel
Neil Katin Guido van Rossum
Kyuho Kim Peter Vanderbilt
Anders Klemets Greg Vaudreuil
John Klensin Ed Vielmetti
Valdis Kletniek Ryan Waldron
Jim Knowles Wally Wedel
Stev Knowles Sven-Ove Westberg
Bob Kummerfeld Brian Wideen
Borenstein & Freed [Page 54]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Pekka Kytolaakso John Wobus
Stellan Lagerstr.m Glenn Wright
Vincent Lau Rayan Zachariassen
Donald Lindsay David Zimmerman
The authors apologize for any omissions from this list,
which are certainly unintentional.
Borenstein & Freed [Page 55]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Appendix A -- Minimal MIME-Conformance
The mechanisms described in this document are open-ended.
It is definitely not expected that all implementations will
support all of the Content-Types described, nor that they
will all share the same extensions. In order to promote
interoperability, however, it is useful to define the
concept of "MIME-conformance" to define a certain level of
implementation that allows the useful interworking of
messages with content that differs from US ASCII text. In
this section, we specify the requirements for such
conformance.
A mail user agent that is MIME-conformant MUST:
1. Always generate a "MIME-Version: 1.0" header
field.
2. Recognize the Content-Transfer-Encoding header
field, and decode all received data encoded with
either the quoted-printable or base64
implementations. Encode any data sent that is
not in seven-bit mail-ready representation using
one of these transformations and include the
appropriate Content-Transfer-Encoding header
field, unless the underlying transport mechanism
supports non-seven-bit data, as SMTP does not.
3. Recognize and interpret the Content-Type
header field, and avoid showing users raw data
with a Content-Type field other than text. Be
able to send at least text/plain messages, with
the character set specified as a parameter if it
is not US-ASCII.
4. Explicitly handle the following Content-Type
values, to at least the following extents:
Text:
-- Recognize and display "text" mail
with the character set "US-ASCII."
-- Recognize other character sets at
least to the extent of being able
to inform the user about what
character set the message uses.
-- Recognize the "ISO-8859-*" character
sets to the extent of being able to
display those characters that are
common to ISO-8859-* and US-ASCII,
namely all characters represented
by octet values 0-127.
-- For unrecognized subtypes, show or
offer to show the user the "raw"
version of the data. An ability at
Borenstein & Freed [Page 56]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
least to convert "text/richtext" to
plain text, as shown in Appendix D,
is encouraged, but not required for
conformance.
Message:
--Recognize and display at least the
primary (822) encapsulation.
Multipart:
-- Recognize the primary (mixed)
subtype. Display all relevant
information on the message level
and the body part header level and
then display or offer to display
each of the body parts
individually.
-- Recognize the "alternative" subtype,
and avoid showing the user
redundant parts of
multipart/alternative mail.
-- Treat any unrecognized subtypes as if
they were "mixed".
Application:
-- Offer the ability to remove either of
the two types of Content-Transfer-
Encoding defined in this document
and put the resulting information
in a user file.
5. Upon encountering any unrecognized Content-
Type, an implementation must treat it as if it had
a Content-Type of "application/octet-stream" with
no parameter sub-arguments. How such data are
handled is up to an implementation, but likely
options for handling such unrecognized data
include offering the user to write it into a file
(decoded from its mail transport format) or
offering the user to name a program to which the
decoded data should be passed as input.
Unrecognized predefined types, which in a MIME-
conformant mailer might still include audio,
image, or video, should also be treated in this
way.
A user agent that meets the above conditions is said to be
MIME-conformant. The meaning of this phrase is that it is
assumed to be "safe" to send virtually any kind of
properly-marked data to users of such mail systems, because
such systems will at least be able to treat the data as
undifferentiated binary, and will not simply splash it onto
the screen of unsuspecting users. There is another sense
in which it is always "safe" to send data in a format that
is MIME-conformant, which is that such data will not break
or be broken by any known systems that are conformant with
RFC 821 and RFC 822. User agents that are MIME-conformant
Borenstein & Freed [Page 57]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
have the additional guarantee that the user will not be
shown data that were never intended to be viewed as text.
Borenstein & Freed [Page 58]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Appendix B -- General Guidelines For Sending Email Data
Internet email is not a perfect, homogeneous system. Mail
may become corrupted at several stages in its travel to a
final destination. Specifically, email sent throughout the
Internet may travel across many networking technologies.
Many networking and mail technologies do not support the
full functionality possible in the SMTP transport
environment. Mail traversing these systems is likely to be
modified in such a way that it can be transported.
There exist many widely-deployed non-conformant MTAs in the
Internet. These MTAs, speaking the SMTP protocol, alter
messages on the fly to take advantage of the internal data
structure of the hosts they are implemented on, or are just
plain broken.
The following guidelines may be useful to anyone devising a
data format (Content-Type) that will survive the widest
range of networking technologies and known broken MTAs
unscathed. Note that anything encoded in the base64
encoding will satisfy these rules, but that some well-known
mechanisms, notably the UNIX uuencode facility, will not.
Note also that anything encoded in the Quoted-Printable
encoding will survive most gateways intact, but possibly not
some gateways to systems that use the EBCDIC character set.
(1) Under some circumstances the encoding used for
data may change as part of normal gateway or user
agent operation. In particular, conversion from
base64 to quoted-printable and vice versa may be
necessary. This may result in the confusion of
CRLF sequences with line breaks in text body
parts. As such, the persistence of CRLF as
something other than a line break should not be
relied on.
(2) Many systems may elect to represent and store
text data using local newline conventions. Local
newline conventions may not match the RFC822 CRLF
convention -- systems are known that use plain CR,
plain LF, CRLF, or counted records. The result is
that isolated CR and LF characters are not well
tolerated in general; they may be lost or
converted to delimiters on some systems, and hence
should not be relied on.
(3) TAB (HT) characters may be misinterpreted or
may be automatically converted to variable numbers
of spaces. This is unavoidable in some
environments, notably those not based on the ASCII
character set. Such conversion is STRONGLY
DISCOURAGED, but it may occur, and mail formats
should not rely on the persistence of TAB (HT)
Borenstein & Freed [Page 59]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
characters.
(4) Lines longer than 76 characters may be wrapped
or truncated in some environments. Line wrapping
and line truncation are STRONGLY DISCOURAGED, but
unavoidable in some cases. Applications which
require long lines should somehow differentiate
between soft and hard line breaks. (A simple way
to do this is to use the quoted-printable
encoding.)
(5) Trailing "white space" characters (SPACE, TAB
(HT)) on a line may be discarded by some transport
agents, while other transport agents may pad lines
with these characters so that all lines in a mail
file are of equal length. The persistence of
trailing white space, therefore, should not be
relied on.
(6) Many mail domains use variations on the ASCII
character set, or use character sets such as
EBCDIC which contain most but not all of the US-
ASCII characters. The correct translation of
characters not in the "invariant" set cannot be
depended on across character converting gateways.
For example, this situation is a problem when
sending uuencoded information across BITNET, an
EBCDIC system. Similar problems can occur without
crossing a gateway, since many Internet hosts use
character sets other than ASCII internally. The
definition of Printable Strings in X.400 adds
further restrictions in certain special cases. In
particular, the only characters that are known to
be consistent across all gateways are the 73
characters that correspond to the upper and lower
case letters A-Z and a-z, the 10 digits 0-9, and
the following eleven special characters:
"'" (ASCII code 39)
"(" (ASCII code 40)
")" (ASCII code 41)
"+" (ASCII code 43)
"," (ASCII code 44)
"-" (ASCII code 45)
"." (ASCII code 46)
"/" (ASCII code 47)
":" (ASCII code 58)
"=" (ASCII code 61)
"?" (ASCII code 63)
A maximally portable mail representation, such as
the base64 encoding, will confine itself to
relatively short lines of text in which the only
meaningful characters are taken from this set of
Borenstein & Freed [Page 60]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
73 characters.
Please note that the above list is NOT a list of recommended
practices for MTAs. RFC 821 MTAs are prohibited from
altering the character of white space or wrapping long
lines. These BAD and illegal practices are known to occur
on established networks, and implementions should be robust
in dealing with the bad effects they can cause.
Borenstein & Freed [Page 61]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Appendix C -- A Complex Multipart Example
What follows is the outline of a complex multipart message.
This message has five parts to be displayed serially: two
introductory plain text parts, an embedded multipart
message, a richtext part, and a closing encapsulated text
message in a non-ASCII character set. The embedded
multipart message has two parts to be displayed in parallel,
a picture and an audio fragment.
MIME-Version: 1.0
From: Nathaniel Borenstein <nsb@bellcore.com>
Subject: A multipart example
Content-Type: multipart/mixed;
boundary=unique-boundary-1
This is the preamble area of a multipart message.
Mail readers that understand multipart format
should ignore this preamble.
If you are reading this text, you might want to
consider changing to a mail reader that understands
how to properly display multipart messages.
--unique-boundary-1
...Some text appears here...
[Note that the preceding blank line means
no header fields were given and this is text,
with charset US ASCII. It could have been
done with explicit typing as in the next part.]
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
This could have been part of the previous part,
but illustrates explicit versus implicit
typing of body parts.
--unique-boundary-1
Content-Type: multipart/parallel;
boundary=unique-boundary-2
--unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64
... base64-encoded 8000 Hz single-channel
u-law-format audio data goes here....
--unique-boundary-2
Content-Type: image/gif
Content-Transfer-Encoding: Base64
Borenstein & Freed [Page 62]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
... base64-encoded image data goes here....
--unique-boundary-2--
--unique-boundary-1
Content-type: text/richtext
This is <bold><italic>richtext.</italic></bold>
<nl><nl>Isn't it
<bigger><bigger>cool?</bigger></bigger>
--unique-boundary-1
Content-Type: message/rfc822
From: (name in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable
... Additional text in ISO-8859-1 goes here ...
--unique-boundary-1--
Borenstein & Freed [Page 63]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Appendix D -- A Simple Richtext-to-Text Translator in C
One of the major goals in the design of the richtext subtype
of the text Content-Type is to make formatted text so simple
that even text-only mailers will implement richtext-to-
plain-text translators, thus increasing the likelihood that
multifont text will become "safe" to use very widely. To
demonstrate this simplicity, what follows is an extremely
simple 44-line C program that converts richtext input into
plain text output:
#include <stdio.h>
#include <ctype.h>
main() {
int c, i;
char token[50];
while((c = getc(stdin)) != EOF) {
if (c == '<') {
for (i=0; (i<49 && (c = getc(stdin)) != '>'
&& c != EOF); ++i) {
token[i] = isupper(c) ? tolower(c) : c;
}
if (c == EOF) break;
if (c != '>') while ((c = getc(stdin)) !=
'>'
&& c != EOF) {;}
if (c == EOF) break;
token[i] = '\0';
if (!strcmp(token, "lt")) {
putc('<', stdout);
} else if (!strcmp(token, "nl")) {
putc('\n', stdout);
} else if (!strcmp(token, "/paragraph")) {
fputs("\n\n", stdout);
} else if (!strcmp(token, "comment")) {
int commct=1;
while (commct > 0) {
while ((c = getc(stdin)) != '<'
&& c != EOF) ;
if (c == EOF) break;
for (i=0; (c = getc(stdin)) != '>'
&& c != EOF; ++i) {
token[i] = isupper(c) ?
tolower(c) : c;
}
if (c== EOF) break;
token[i] = NULL;
if (!strcmp(token, "/comment")) --
commct;
if (!strcmp(token, "comment"))
++commct;
Borenstein & Freed [Page 64]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
}
} /* Ignore all other tokens */
} else if (c != '\n') putc(c, stdout);
}
putc('\n', stdout); /* for good measure */
}
It should be noted that one can do considerably better than
this in displaying richtext data on a dumb terminal. In
particular, one can replace font information such as "bold"
with textual emphasis (like *this* or _T_H_I_S_). One can
also properly handle the richtext formatting commands
regarding indentation, justification, and others. However,
the above program is all that is necessary in order to
present richtext on a dumb terminal.
Borenstein & Freed [Page 65]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Appendix E -- Collected Grammar
This appendix contains the complete BNF grammar for all the
syntax specified by this document.
By itself, however, this grammar is incomplete. It refers
to several entities that are defined by RFC 822. Rather
than reproduce those definitions here, and risk
unintentional differences between the two, this document
simply refers the reader to RFC 822 for the remaining
definitions. Wherever a term is undefined, it refers to the
RFC 822 definition.
attribute := token
body-part = <"message" as defined in RFC 822,
with all header fields optional, and with the
specified delimiter not occurring anywhere in
the message body, either on a line by itself
or as a substring anywhere.>
boundary := 0*69<bchars> bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /
"_"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
close-delimiter := delimiter "--"
Content-Description := *text
Content-ID := msg-id
Content-Transfer-Encoding := "BASE64" / "QUOTED-
PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" / x-token
Content-Type := type "/" subtype *[";" parameter]
delimiter := CRLF "--" boundary ; taken from Content-Type
field.
; when content-type is
multipart
; There should be no space
; between "--" and boundary.
encapsulation := delimiter CRLF body-part
epilogue := *text ; to be ignored upon
receipt.
Borenstein & Freed [Page 66]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
MIME-Version := 1*text
multipart-body := preamble 1*encapsulation close-delimiter
epilogue
parameter := attribute "=" value
preamble := *text ; to be ignored upon
receipt.
subtype := token
token := 1*<any CHAR except SPACE, CTLs, or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in
/ "," / ";" / ":" / "\" / <"> ; quoted-string,
/ "/" / "[" / "]" / "?" / "." ; to use within
/ "=" ; parameter values
type := "application" / "audio" ; case-
insensitive
/ "image" / "message"
/ "multipart" / "text"
/ "video" / x-token
value := token / quoted-string
x-token := <The two characters "X-" followed, with no
intervening white space, by any token>
Borenstein & Freed [Page 67]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Appendix F -- IANA Registration Procedures
MIME has been carefully designed to have extensible
mechanisms, and it is expected that the set of content-
type/subtype pairs and their associated parameters will grow
significantly with time. Several other MIME fields, notably
character set names, access-type parameters for the
message/external-body type, conversions parameters for the
application type, and possibly even Content-Transfer-
Encoding values, are likely to have new values defined over
time. In order to ensure that the set of such values is
developed in an orderly, well-specified, and public manner,
MIME defines a registration process which uses the Internet
Assigned Numbers Authority (IANA) as a central registry for
such values.
In general, parameters in the content-type header field are
used to convey supplemental information for various content
types, and their use is defined when the content-type and
subtype are defined. New parameters should not be defined
as a way to introduce new functionality.
In order to simplify and standardize the registration
process, this appendix gives templates for the registration
of new values with IANA. Each of these is given in the form
of an email message template, to be filled in by the
registering party.
F.1 Registration of New Content-type/subtype Values
Note that MIME is generally expected to be extended by
subtypes. If a new fundamental top-level type is needed,
its specification should be published as an RFC or
submitted in a form suitable to become an RFC, and be
subject to the Internet standards process.
To: IANA@isi.edu
Subject: Registration of new MIME content-type/subtype
MIME type name:
(If the above is not an existing top-level MIME type,
please explain why an existing type cannot be used.)
MIME subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Borenstein & Freed [Page 68]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Published specification:
(The published specification must be an Internet RFC or
RFC-to-be if a new top-level type is being defined, and
must be a publicly available specification in any
case.)
Person & email address to contact for further
information:
F.2 Registration of New Character Set Values
To: IANA@isi.edu
Subject: Registration of new MIME character set value
MIME character set name:
Published specification:
(The published specification must be an Internet RFC or
RFC-to-be or an international standard.)
Person & email address to contact for further
information:
F.3 Registration of New Access-type Values for
Message/external-body
To: IANA@isi.edu
Subject: Registration of new MIME Access-type for
Message/external-body content-type
MIME access-type name:
Required parameters:
Optional parameters:
Published specification:
(The published specification must be an Internet RFC or
RFC-to-be.)
Person & email address to contact for further
information:
F.4 Registration of New Conversions Values for Application
To: IANA@isi.edu
Subject: Registration of new MIME Conversions value
for Application content-type
MIME Conversions name:
Borenstein & Freed [Page 69]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Published specification:
(The published specification must be an Internet RFC or
RFC-to-be.)
Person & email address to contact for further
information:
Borenstein & Freed [Page 70]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Appendix G -- Summary of the Seven Content-types
Content-type: text
Subtypes defined by this document: plain, richtext
Important Parameters: charset
Encoding notes: quoted-printable generally preferred if an
encoding is needed and the character set is mostly an
ASCII superset.
Security considerations: Rich text formats such as TeX and
Troff often contain mechanisms for executing arbitrary
commands or file system operations, and should not be
used automatically unless these security problems have
been addressed. Even plain text may contain control
characters that can be used to exploit the capabilities
of "intelligent" terminals and cause security
violations. User interfaces designed to run on such
terminals should be aware of and try to prevent such
problems.
________________________________________________________________
Content-type: multipart
Subtypes defined by this document: mixed, alternative,
digest, parallel.
Important Parameters: boundary
Encoding notes: No content-transfer-encoding is permitted.
________________________________________________________________
Content-type: message
Subtypes defined by this document: rfc822, partial,
external-body
Important Parameters: id, number, total
Encoding notes: No content-transfer-encoding is permitted.
________________________________________________________________
Content-type: application
Subtypes defined by this document: octet-stream,
postscript, oda
Important Parameters: profile
Borenstein & Freed [Page 71]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Encoding notes: base64 generally preferred for octet-stream
or other unreadable subtypes.
Security considerations: This type is intended for the
transmission of data to be interpreted by locally-installed
programs. If used, for example, to transmit executable
binary programs or programs in general-purpose interpreted
languages, such as LISP programs or shell scripts, severe
security problems could result. In general, authors of
mail-reading agents are cautioned against giving their
systems the power to execute mail-based application data
without carefully considering the security implications.
While it is certainly possible to define safe application
formats and even safe interpreters for unsafe formats, each
interpreter should be evaluated separately for possible
security problems.
________________________________________________________________
Content-type: image
Subtypes defined by this document: jpeg, gif
Important Parameters: none
Encoding notes: base64 generally preferred
________________________________________________________________
Content-type: audio
Subtypes defined by this document: basic
Important Parameters: none
Encoding notes: base64 generally preferred
________________________________________________________________
Content-type: video
Subtypes defined by this document: mpeg
Important Parameters: none
Encoding notes: base64 generally preferred
Borenstein & Freed [Page 72]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Appendix H -- Canonical Encoding Model
There was some confusion, in earlier drafts of this memo,
regarding the model for when email data was to be converted
to canonical form and encoded, and in particular how this
process would affect the treatment of CRLFs, given that the
representation of newlines varies greatly from system to
system. For this reason, a canonical model for encoding is
presented below.
The process of composing a MIME message part can be modelled
as being done in a number of steps. Note that these steps
are roughly similar to those steps used in RFC1113:
Step 1. Creation of local form.
The body part to be transmitted is created in the system's
native format. The native character set is used, and where
appropriate local end of line conventions are used as well.
The may be a UNIX-style text file, or a Sun raster image, or
a VMS indexed file, or audio data in a system-dependent
format stored only in memory, or anything else that
corresponds to the local model for the representation of
some form of information.
Step 2. Conversion to canonical form.
The entire body part, including "out-of-band" information
such as record lengths and possibly file attribute
information, is converted to a universal canonical form.
The specific content type of the body part as well as its
associated attributes dictate the nature of the canonical
form that is used. Conversion to the proper canonical form
may involve character set conversion, transformation of
audio data, compression, or various other operations
specific to the various content types.
For example, in the case of text/plain data, the text must
be converted to a supported character set and lines must be
delimited with CRLF delimiters in accordance with RFC822.
Note that the restriction on line lengths implied by RFC822
is eliminated if the next step employs either quoted-
printable or base64 encoding.
Step 3. Apply transfer encoding.
A Content-Transfer-Encoding appropriate for this body part
is applied. Note that there is no fixed relationship
between the content type and the transfer encoding. In
particular, it may be appropriate to base the choice of
base64 or quoted-printable on character frequency counts
which are specific to a given instance of body part.
Borenstein & Freed [Page 73]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Step 4. Insertion into message.
The encoded object is inserted into a MIME message with
appropriate body part headers and boundary markers.
It is vital to note that these steps are only a model; they
are specifically NOT a blueprint for how an actual system
would be built. In particular, the model fails to account
for two common designs:
1. In many cases the conversion to a canonical
form prior to encoding will be subsumed into the
encoder itself, which understands local formats
directly. For example, the local newline
convention for text bodyparts might be carried
through to the encoder itself along with knowledge
of what that format is.
2. The output of the encoders may have to pass
through one or more additional steps prior to
being transmitted as a message. As such, the
output of the encoder may not be compliant with
the formats specified by RFC822. In particular,
once again it may be appropriate for the
converter's output to be expressed using local
newline conventions rather than using the standard
RFC822 CRLF delimiters.
Other implementation variations are conceivable as well.
The only important aspect of this discussion is that the
resulting messages are consistent with those produced by the
model described here.
Borenstein & Freed [Page 74]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
References
[US-ASCII] Coded Character Set--7-Bit American Standard Code
for Information Interchange, ANSI X3.4-1986.
[ATK] Borenstein, Nathaniel S., Multimedia Applications
Development with the Andrew Toolkit, Prentice-Hall, 1990.
[GIF] Graphics Interchange Format (Version 89a), Compuserve,
Inc., Columbus, Ohio, 1990.
[ISO-2022] International Standard--Information Processing--
ISO 7-bit and 8-bit coded character sets--Code extension
techniques, ISO 2022:1986.
[ISO-8859] Information Processing -- 8-bit Single-Byte Coded
Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO
8859-1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2,
1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part
4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5:
Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6:
Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7:
Latin/Greek alphabet, ISO 8859-7, 1987. Part 8:
Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin
alphabet No. 5, ISO 8859-9, 1990.
[ISO-646] International Standard--Information Processing--
ISO 7-bit coded character set for information interchange,
ISO 646:1983.
[MPEG] Video Coding Draft Standard ISO 11172 CD, ISO
IEC/TJC1/SC2/WG11 (Motion Picture Experts Group), May, 1991.
[ODA] ISO 8613; Information Processing: Text and Office
System; Office Document Architecture (ODA) and Interchange
Format (ODIF), Part 1-8, 1989.
[PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva,
1972, "Pulse Code Modulation (PCM) of Voice Frequencies".
[POSTSCRIPT] Adobe Systems, Inc., PostScript Language
Reference Manual, Addison-Wesley, 1985.
[X400] Schicker, Pietro, "Message Handling Systems, X.400",
Message Handling Systems and Distributed Applications, E.
Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-
Holland, 1989, pp. 3-41.
[RFC-783] Sollins, K.R. TFTP Protocol (revision 2). June,
1981, MIT, RFC-783.
[RFC-821] Postel, J.B. Simple Mail Transfer Protocol.
August, 1982, USC/Information Sciences Institute, RFC-821.
Borenstein & Freed [Page 75]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
[RFC-822] Crocker, D. Standard for the format of ARPA
Internet text messages. August, 1982, UDEL, RFC-822.
[RFC-934] Rose, M.T.; Stefferud, E.A. Proposed standard
for message encapsulation. January, 1985, Delaware
and NMA, RFC-934.
[RFC-959] Postel, J.B.; Reynolds, J.K. File Transfer
Protocol. October, 1985, USC/Information Sciences
Institute, RFC-959.
[RFC-1049] Sirbu, M.A. Content-Type header field for
Internet messages. March, 1988, CMU, RFC-1049.
[RFC-1113] Linn, J. Privacy enhancement for Internet
electronic mail: Part I - message encipherment and
authentication procedures. August, 1989, IAB Privacy Task
Force, RFC-1113.
[RFC-1154] Robinson, D.; Ullmann, R. Encoding header field
for Internet messages. April, 1990, Prime Computer,
Inc., RFC-1154.
[RFC-1342] Moore, Keith, Representation of Non-Ascii Text in
Internet Message Headers. June, 1992, University of
Tennessee, RFC-1342.
Security Considerations
Security issues are discussed in Section 7.4.2 and in
Appendix G. Implementors should pay special attention to
the security implications of any mail content-types that can
cause the remote execution of any actions in the recipient's
environment. In such cases, the discussion of the
applicaton/postscript content-type in Section 7.4.2 may
serve as a model for considering other content-types with
remote execution capabilities.
Borenstein & Freed [Page 76]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Authors' Addresses
For more information, the authors of this document may be
contacted via Internet mail:
Nathaniel S. Borenstein
MRE 2D-296, Bellcore
445 South St.
Morristown, NJ 07962-1910
Phone: +1 201 829 4270
Fax: +1 201 829 7019
Email: nsb@bellcore.com
Ned Freed
Innosoft International, Inc.
250 West First Street
Suite 240
Claremont, CA 91711
Phone: +1 714 624 7907
Fax: +1 714 621 5319
Email: ned@innosoft.com
Borenstein & Freed [Page 77]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
THIS PAGE INTENTIONALLY LEFT BLANK.
Please discard this page and place the following table of
contents after the title page.
Borenstein & Freed [Page i]
Table of Contents
1 Introduction....................................... 1
2 Notations, Conventions, and Generic BNF Grammar.... 3
3 The MIME-Version Header Field...................... 5
4 The Content-Type Header Field...................... 6
5 The Content-Transfer-Encoding Header Field......... 10
5.1 Quoted-Printable Content-Transfer-Encoding......... 14
5.2 Base64 Content-Transfer-Encoding................... 17
6 Additional Optional Content- Header Fields......... 19
6.1 Optional Content-ID Header Field................... 19
6.2 Optional Content-Description Header Field.......... 19
7 The Predefined Content-Type Values................. 20
7.1 The Text Content-Type.............................. 20
7.1.1 The charset parameter.............................. 20
7.1.2 The Text/plain subtype............................. 23
7.1.3 The Text/richtext subtype.......................... 23
7.2 The Multipart Content-Type......................... 29
7.2.1 Multipart: The common syntax...................... 30
7.2.2 The Multipart/mixed (primary) subtype.............. 34
7.2.3 The Multipart/alternative subtype.................. 34
7.2.4 The Multipart/digest subtype....................... 36
7.2.5 The Multipart/parallel subtype..................... 36
7.3 The Message Content-Type........................... 37
7.3.1 The Message/rfc822 (primary) subtype............... 37
7.3.2 The Message/Partial subtype........................ 37
7.3.3 The Message/External-Body subtype.................. 40
7.4 The Application Content-Type....................... 46
7.4.1 The Application/Octet-Stream (primary) subtype..... 46
7.4.2 The Application/PostScript subtype................. 47
7.4.3 The Application/ODA subtype........................ 50
7.5 The Image Content-Type............................. 51
7.6 The Audio Content-Type............................. 51
7.7 The Video Content-Type............................. 51
7.8 Experimental Content-Type Values................... 51
Summary............................................ 53
Acknowledgements................................... 54
Appendix A -- Minimal MIME-Conformance............. 56
Appendix B -- General Guidelines For Sending Email Data59
Appendix C -- A Complex Multipart Example.......... 62
Appendix D -- A Simple Richtext-to-Text Translator in C64
Appendix E -- Collected Grammar.................... 66
Appendix F -- IANA Registration Procedures......... 68
F.1 Registration of New Content-type/subtype Values..68
F.2 Registration of New Character Set Values...... 69
F.3 Registration of New Access-type Values for Message/external-body69
F.4 Registration of New Conversions Values for Application69
Appendix G -- Summary of the Seven Content-types... 71
Appendix H -- Canonical Encoding Model............. 73
References......................................... 75
Security Considerations............................ 76
Authors' Addresses................................. 77
Borenstein & Freed [Page ii]
Borenstein & Freed [Page iii]
|