---- 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). 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