3 ms·

Of course the terms "Internet" wouldn't be used for another decade (and deployed even later) but the rfc-editor's index is more recent than that. There are som

by gumby 3y ago

Of course the terms "Internet" wouldn't be used for another decade (and deployed even later) but the rfc-editor's index is more recent than that. There are some implications of RFC 20 right in the abstract that are obscure today. > use of standard 7-bit ASCII embedded in an 8 bit byte whose high order bit is always 0. This was very important because character sets had still not been standardized back then, though ASCII newer non-IBM systems tended to choose ASCII by default. Even then, since byte and word lengths varied, multiple character sets were common even on a single machine (e.g. both ascii and SIXBIT) so specifying the 8-bit byte (and IBMism IIRC) was necessary. 36-bit words were quite popular in research machines and back in '69 I think all the arpanet hosts were 36-bit PDP-10s, which supported bytes of width 1-36 bits. You can still see remnants of these machines in some older protocols. As a consequence, the FTP protocol had a "binary mode" and a "text mode" because you can't safely transfer binary data from machines with incompatible word sizes and endianness. Text mode guaranteed a stream of seven bit characters in the correct order. If you specified the wrong transfer mode you usually ended up with gibberish. > SRI uses "." (ASCII X'2E' or 2/14) as the end-of-line character, where as UCLA uses X'OD' or 0/13 (carriage return). You can see that this issue also goes way back. So if you think things were better before the confusion of utf-8 vs other representations, or were better before Windows code pages, well, they weren't.

_notreallyme_ 3y ago
> the FTP protocol had a "binary mode" and a "text mode" because you can't safely transfer binary data from machines with incompatible word sizes and endianness I'm not sure to follow you here. The TYPE modes are ASCII, IMAGE, EBCDIC and Local byte size. The "binary mode" being Image and "text mode" being ASCII in current FTP clients. The IMAGE mode is the one that actually transfers file as they really are without any changes. The other 3 formats are actually used for character conversion, with an additional parameters to specify telnet or ASA conversion, and even changing the byte size in case of L. In the end, the "text mode" is the one that will tend to corrupt your file (thanks to the CR/LF, LF/CR, LF discrepancy between the 3 major desktop OS). Always choose TYPE IN (Image Non-print) by default!
- bawolff 3y ago
  I think SMTP would be a more relevant example.
  - gumby 3y ago
    Does smtp have another mode other than text?
    - bawolff 3y ago
      SMTP generally assumes you only have 7bit transfer. You have to negotiate a protocol extension (8bitmime) to send bytes with a leading 1. https://datatracker.ietf.org/doc/html/rfc6152 https://datatracker.ietf.org/doc/html/rfc6152
- gumby 3y ago
  Thanks for the reminder — it’s been decades since I thought about FTP, much less used it. While we’re at it, let’s not forget that it was originally also the transport for network mail!
Someone 3y ago
> 36-bit PDP-10s, which supported bytes of width 1-36 bits. I thought they only supported (some) elements of bit sizes that divided 36, but http://www.hakmem.org/pdp-10.html#Byte http://www.hakmem.org/pdp-10.html#Byte thought me: “In the PDP-10 a "byte" is some number of contiguous bits within one word. A byte pointer is a quantity (which occupies a whole word) which describes the location of a byte. There are three parts to the description of a byte: the word (i.e., address) in which the byte occurs, the position of the byte within the word, and the length of the byte”

by gumby 3y ago

_notreallyme_ 3y ago

> the FTP protocol had a "binary mode" and a "text mode" because you can't safely transfer binary data from machines with incompatible word sizes and endianness I'm not sure to follow you here. The TYPE modes are ASCII, IMAGE, EBCDIC and Local byte size. The "binary mode" being Image and "text mode" being ASCII in current FTP clients. The IMAGE mode is the one that actually transfers file as they really are without any changes. The other 3 formats are actually used for character conversion, with an additional parameters to specify telnet or ASA conversion, and even changing the byte size in case of L. In the end, the "text mode" is the one that will tend to corrupt your file (thanks to the CR/LF, LF/CR, LF discrepancy between the 3 major desktop OS). Always choose TYPE IN (Image Non-print) by default!

bawolff 3y ago
I think SMTP would be a more relevant example.
- gumby 3y ago
  Does smtp have another mode other than text?
  - bawolff 3y ago
    SMTP generally assumes you only have 7bit transfer. You have to negotiate a protocol extension (8bitmime) to send bytes with a leading 1. https://datatracker.ietf.org/doc/html/rfc6152 https://datatracker.ietf.org/doc/html/rfc6152
gumby 3y ago
Thanks for the reminder — it’s been decades since I thought about FTP, much less used it. While we’re at it, let’s not forget that it was originally also the transport for network mail!

Someone 3y ago

> 36-bit PDP-10s, which supported bytes of width 1-36 bits. I thought they only supported (some) elements of bit sizes that divided 36, but http://www.hakmem.org/pdp-10.html#Byte http://www.hakmem.org/pdp-10.html#Byte thought me: “In the PDP-10 a "byte" is some number of contiguous bits within one word. A byte pointer is a quantity (which occupies a whole word) which describes the location of a byte. There are three parts to the description of a byte: the word (i.e., address) in which the byte occurs, the position of the byte within the word, and the length of the byte”