On 27 September 2017 at 17:22, tom p. <daedulus@xxxxxxxxxxxxx> wrote:
----- Original Message -----
From: "Matthew Kerwin" <matthew@xxxxxxxxxxxxx>
Sent: Tuesday, September 26, 2017 9:21 PM
> On 27 Sep. 2017 5:39 am, "Brian E Carpenter" <brian.e.carpenter@xxxxxxxxx> wrote:
>> It would be prudent to also include a Content-Disposition header with> So why don't we, the Internet standards people who believe in rough
> consensus and running code, request the RFC Editor (a friend of ours)
> to supply two text versions of each RFC, like
>
> https://www.rfc-editor.org/rfc/rfc8187.txt as today, with BOM if
relevant
> https://www.rfc-editor.org/rfc/rfc8187.ut8 containing pure UTF-8
with no
> BOM ever
>
>
an
> appropriate 'filename' parameter, since browsers tend to name all
> downloaded text/plain files as .txt irrespective of the URL.
>
> Not sure if this is bike-shedding or rat-holing.
Matthew
Where in the FTP protocol do I see a Content-Disposition header?
Probably the same place in it says you can use FTP to download https URLs. But the question of ftp/rsync/other more direct (non-http) methods of accessing the repository was why I was asking earlier about the behind-the-curtain storage. If they all serve from the same directory on the server, then it'd be best to have renamed/duplicate files (and appropriate httpd configuration for serving them); if they're in different places then there may be other/better options.
I always use FTP to download RFC because it (or at least my version
thereof) preserves the metadata whereas my HTTP client (Internet
Explorer) always mangles it.
Oh aye, that's always been part of my argument. The tools aren't great, the filesystems aren't great, nothing is great. If they were, there wouldn't be a problem.
Do both sounds like an excellent idea!
Indeed, that's why I wrote "also". The more annoying holes we patch over, the fewer people are likely to slip through one of them.
Cheers
--
Matthew Kerwin
http://matthew.kerwin.net.au/
http://matthew.kerwin.net.au/