On 30/11/2020 13:25, Carsten Bormann wrote:
On 2020-11-30, at 13:37, tom petch <daedulus@xxxxxxxxxxxxx> wrote:
not respecting the ASCII control characters such as I got last week when an RFC was turned into a stream without formatting
This is getting a bit confused.
Recent RFCs (from RFC 8650 on) have not been ASCII, even in the plain-text version.
Even if the author’s text was ASCII-only Unicode, upon publishing a UTF-8 BOM is added.
(I think that is wrong, but that is a separate discussion, and I’m obviously in the rough here.)
Also, recent RFCs in plain-text version have not been paginated, which maybe what you call a “stream”.
(I also think that is suboptimal, but that is yet another discussion again.)
Carsten
Yes, we are on the same page here so I went back to RFC5347 which
predates the recent changes and which has lost its layout. This loss of
layout used to be a common problem because of differing conventions over
the use of ASCII CR-LF to separate lines, as opposed to just one of the
ASCII control characters. I do not have ready access to a hex editor
and so cannot see if that is the case but it would not surprise me if
the web browser, Internet Explorer, was doing something to the ASCII
control characters; on the other hand, FTP is rich in options in this
area, it being a significant issue at the time of publication of RFC959,
so it just could be that FTP is getting it right whereas HTTP/HTML is
not making any changes and renders me an unusable stream of bytes!
Tom Petch
None if this is dependent on the mode of access.
Note that Web browsers might be adding BOMs or might be changing their behavior based on the presence of a BOM, which may be part of the unexplained effects you might be seeing. Preferably, don’t use Web browsers or other sources of intelligent behavior.
Grüße, Carsten
.
