Re: Call for Community Feedback: Retiring IETF FTP Service

[tom petch <[e-mail]>]

On 30/11/2020 13:25, Carsten Bormann wrote:
> On 2020-11-30, at 13:37, tom petch <[e-mail]> 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
>
> .
>