RFC 1341 osiągnął już pełnoletność (wydano go 19 lat temu), więc w działce IT można go uznać za zabytek
1. RFC1341 jest "Obsoleted by: 1521" (masz na górze dokumentu, który zacytowałeś).
2. RFC1521 (swoją drogą, też pełnoletni - rocznik 1993) jest "Obsoleted by: 2045, 2046, 2047, 2048, 2049" - i te należy poczytać
Ja odsyłam na początek do RFC 2045 (który, swoją drogą jest uaktualniony przez 2184, 2231, 5335), do punktu "6.2. Content-Transfer-Encodings Semantics"
Z tego punktu (a także z p.6) wynika, że: jeśli przesyłasz conajwyżej znaki z górnej połówki ASCII (kody 128-255), możesz użyć kodowania "8bit". Przydatne przy kodowaniu polskich liter w iso8859-2 (kiedyś ten standard był dość powszechny). W dzisiejszych czasach jest to "do 998 znaków pomiędzy wystąpieniami CRLF" (p.2.8 w RFC 2045, choć wywodzi się to po części z czasów RFC821). Nie jesteś w stanie zagwarantować tego w formatach typowo binarnych (grafika, muzyka, archiwa etc). Wniosek jest prosty - do tych typów danych kodowanie 8bit nie będzie wyborem.
Kolejna rzecz, to wybór odpowiedniego "content-encoding". Lista oficjalna jest w p. 6.1. Jeśli ją przejrzysz, dostaniesz listę content encoding:
1. 7bit
2. 8bit
3. binary
4. quoted-printable
5. base64
6. ietf-token / x-token
Pierwsze dwa można skreślić. Ostatni jest używany do "voice messages", więc też skreślamy. base64 nie lubisz, więc skreślmy. Zostaje "binary" i "quoted-printable". O quoted-printable można powiedzieć tylko tyle, że jeśli znak jest spoza zakresu "7bit", to zapisuje ten znak w postaci trzech, np. znak o ASCII=255 zapisze jako "=FF". Przy binarkach wychodzi potrojenie objętości. Koszmar, bo base64 daje narzut rzędu kilkunast procent, a nie 33%.
Zostaje nieszczęsny "binary"... Co z nim? Odpowiedź nie jest prosta. Można, pod pewnymi warunkami. Warunki opisane są w RFC6152. W skrócie:
- serwer odbierający musi być RFC6152-compliant (w fazie negocjacji na komendę EHLO
musi dać odpowiedź "
250 8BITMIME")
- koniec danych binarnych trzeba jakoś zasygnalizować - tuż po zakończeniu bloku danych należy wysłać CR, LF, "." CR, LF (w sumie 5 znaków) lub trzy sekwencje ".", CR, LF (w sumie 9 znaków).
Niestety - nadal obowiązuje RFC5321 (patrz p.2.4 tegoż RFC), więc limit tysiąca znaków w linii (u nich nazywane jako "between two CRLF pairs"), a ponadto nieco dalej napisali:
This restriction means that this extension provides the necessary facilities for transferring a MIME object with the 8BIT content-transfer-encoding, it DOES NOT provide a means of transferring an object with the BINARY content-transfer-encoding.Wychodzi na to, że jeśli chcesz być "legalny", to zostaje Ci base64. Choć większość serwerów powinna umieć sobie poradzić z dłuższymi niż 1KB ciągami binarnymi... Kurde, jak mnie najdzie, to sobie potestuję...