---- Original Message ----- From: "Denis Ovsienko" <denis@xxxxxxxxxxxxx> Sent: Friday, September 15, 2017 6:31 PM ---- On Fri, 15 Sep 2017 17:44:12 +0100 tom p. <daedulus@xxxxxxxxxxxxx> wrote ---- > Interesting. > > The euro symbol displays fine but depending on which utility I use to > display, I do get some blobs to indicate undisplayable characters. Thus > in the line which starts > into parameter valu .... > and ends > .... how to encode non-ASCII characters > > the 'e' of value is not an ASCII 'e' and my attempts to cut and paste > the line into this e-mail fails after the 'u' of 'values' suggesting > that there is a line terminator in there. > > Unless - of course - that letter I presume is 'e' is intended to be a > glyph outside normal ASCII with a line terminator function. As far as hexdump of https://www.rfc-editor.org/rfc/rfc8187.txt goes the character you are describing is a plain ASCII "e" (0x65): 00001f20 74 69 6f 6e 0a 20 20 20 69 6e 74 6f 20 70 61 72 |tion. into par| 00001f30 61 6d 65 74 65 72 20 76 61 6c 75 65 73 20 61 6e |ameter values an| 00001f40 64 20 61 6c 73 6f 20 68 6f 77 20 74 6f 20 65 6e |d also how to en| FireFox correctly displays the .txt file in Unicode by default, this likely has to do with the UTF-8 BOM at the beginning of the file (both observations are based on the file rsync'ed from rfc-editor.org). <tp> Denis Thanks for that. I need to dig some more. My oldest utility does not understand the BOM at the start of the file and displays it, well tries to. Other utilities suppress the BOM but then some give me those blobs, one of which I identified above, others do not, all pointed at the same file on the same disk, downloaded from RFC Editor web site (or a proxy thereof which is invisible to me). I do not use rsync. Um, I do not understand this but will dig some more. Tom Petch One thing I vaguely remember in related documents from around 2013 was that Unicode in the document text and in any person/organization names was supposed to have a 2nd ASCII version as a backup, does it still stand? Because in this RFC the Acknowledgements section does not provide a backup spelling for Martin Dürst. Not a big issue, just curious. Other than that, this is a remarkable milestone in a big work. Hopefully document authors will remember that more [technical] power implies more responsibility. -- Denis Ovsienko