Ada artikel Wikipedia yang bagus tentang ini.
Iterasi NCP yang paling awal seperti yang digunakan oleh ARPAnet lebih seperti bit stream daripada byte stream, atau upaya untuk menegosiasikan ukuran byte yang nyaman; byte 8-bit hanya distandarisasi jauh kemudian. Ada juga beberapa upaya membuat protokol transfer file yang akan berfungsi di mesin yang berbeda (mail pada awalnya merupakan fungsi dari protokol FTP, terutama sebagai MAILdanMLFL perintah, kemudian dipecah menjadi MTP , kemudian SMTP .). Mesin-mesin itu sering memiliki pengkodean karakter yang berbeda - ASCII vs EBCDIC - atau bahkan ukuran byte yang berbeda, byte 8-bit vs 6-bit ...
Oleh karena itu, fungsi transfer surat pada awalnya didefinisikan untuk mentransfer pesan yang relatif singkat dalam teks biasa; khusus, "NVT-ASCII". Misalnya, RFC 772 mengatakan:
PENYIMPANAN DAN PENYIMPANAN MAIL
Mail ditransfer dari perangkat penyimpanan di host pengirim ke perangkat penyimpanan di host penerima. Mungkin perlu untuk melakukan transformasi tertentu pada surat karena representasi penyimpanan data dalam dua sistem berbeda. Sebagai contoh, NVT-ASCII memiliki representasi penyimpanan data yang berbeda dalam sistem yang berbeda. PDP-10 umumnya menyimpan NVT-ASCII sebagai lima karakter ASCII 7-bit, dibenarkan kiri dalam kata 36-bit. 360's store NVT-ASCII sebagai empat kode EBCDIC 8-bit dalam kata 32-bit. Multics menyimpan NVT-ASCII sebagai empat karakter 9-bit dalam sebuah kata 36-bit.
Demi kesederhanaan, semua data harus direpresentasikan dalam MTP sebagai NVT-ASCII. Ini berarti bahwa karakter harus dikonversi ke representasi NVT-ASCII standar ketika mengirim teks, terlepas dari apakah host pengirim dan penerima berbeda. Pengirim mengonversi data dari representasi karakter internal ke representasi NVT-ASCII 8-bit standar (lihat spesifikasi TELNET). Penerima mengubah data dari bentuk standar ke bentuk internalnya sendiri. Sesuai dengan standar ini, urutan harus digunakan untuk menunjukkan akhir dari satu baris teks.
Meskipun delapan bit ditransmisikan melalui kabel, bit ke-8 sering dibuang atau hancur, karena tidak ada persyaratan untuk melestarikannya; pada kenyataannya, beberapa protokol mengharuskan bit ke-8 diatur ke nol, seperti RFC SMTP awal seperti dikutip di bawah ini. Dengan kata lain, perangkat lunak itu tidak 8-bit bersih .
Transfer data
Koneksi TCP mendukung transmisi byte 8-bit. Data SMTP adalah karakter ASCII 7-bit. Setiap karakter ditransmisikan sebagai byte 8-bit dengan bit orde tinggi dihapus ke nol.
Ini bertahan untuk waktu yang lama bahkan setelah pengkodean karakter ISO-8859-# 8-bit menjadi luas. Meskipun beberapa server sudah bersih 8-bit, banyak yang lain tidak, dan secara acak mengirim data 8 bit akan menghasilkan pesan yang rusak.
Kemudian, "Extended SMTP" diterbitkan, memungkinkan server mail untuk menyatakan ekstensi SMTP yang mereka dukung; salah satunya adalah 8BITMIME, menunjukkan bahwa server penerima dapat dengan aman menerima data 8-bit. Bagian pesan MIME dapat memiliki " Content-Transfer-Encoding : 8bit", yang menunjukkan bahwa mereka tidak dikodekan dengan cara apa pun.
Namun, protokol SMTP tetap berbasis garis dan memiliki batas garis oktet 998, serta menggunakan .garis (0D 0A 2E 0D 0A) sebagai indikator "akhir pesan". Ini berarti bahwa meskipun sebagian besar file biner dapat dikirim tanpa diubah, masih mungkin bahwa file yang berisi urutan oktet ini akan ditafsirkan sebagai akhir dari pesan yang ditransfer, dan sisa file sebagai perintah SMTP, mungkin menyebabkan kerusakan. Demikian pula, "garis" lebih dari 998 oktet mungkin terputus oleh server penerima.
Pada tahun 2000, ekstensi ESMTP "BINARYMIME" diterbitkan sebagai RFC 3030 , memungkinkan transfer data biner mentah melalui SMTP. Pesan sekarang ditransfer dalam potongan panjang yang telah ditentukan sebelumnya, dengan potongan nol panjang digunakan sebagai terminator, dan Base64 & pengkodean serupa tidak diperlukan lagi. Sayangnya, beberapa server SMTP mendukung ekstensi ini; misalnya, Postfix atau Exim4 tidak beriklan CHUNKINGsebagai balasan untuk EHLO. Untuk memanfaatkan BINARYMIME, itu harus didukung oleh semua server di jalur pesan, yang bisa lebih dari satu atau dua.
Lihat juga: