[rfc-i] Unicode characters for ASCII control characters
julian.reschke at gmx.de
Wed Jun 3 10:56:36 PDT 2015
On 2015-06-03 19:48, Paul Hoffman wrote:
> On Jun 3, 2015, at 10:40 AM, Julian Reschke <julian.reschke at greenbytes.de> wrote:
>> On 2015-06-03 19:06, Paul Hoffman wrote:
>>> On Jun 3, 2015, at 9:54 AM, Nico Williams <nico at cryptonector.com> wrote:
>>>> On Wed, Jun 03, 2015 at 12:33:33PM -0400, Phillip Hallam-Baker wrote:
>>>>>> On 6/3/15 9:02 AM, Phillip Hallam-Baker wrote:
>>>>>>> Does anyone know if there is a defined unicode character for
>>>>>>> 'printable non-printable' ? I had a look and could not see
>>>>> Found it! U+241E
>>>>> I think this should allow a lot more useful examples when writing specs
>>>>> with significant CRLF sequences.
>>>> Very nice!
>>> If we put the actual U+241E character in an RFC so that people can "see" the character, many people will copy-and-paste it into the programs, instead of using an U+001E character. I cannot imagine how you can word the surrounding text well enough to make it clear that you're just showing a character that you don't want them to copy-and-paste.
>> Well, in the old format they can't copy & paste,
> Sure they can. Phill just sent and example of plain text where someone who didn't understand could copy-and-paste.
Can you elaborate? How do I copy & paste from an RFC characters that are
not allowed in the RFC?
>> with this proposal they can't either. Not sure why this is a big problem.
> No one said that it is a "big problem".
OK :-) I thought you meant that that's a problem big enough so it
shouldn't be done that way. If it's not a big problem, why not do it
that way then?
>>> We have not heard any problems so far with people misunderstanding RFC 7464 and copying in the six characters "U+001E", or the four characters "001E", or even the two characters "RS". The proposal above seems likely to cause way more problems than it would fix.
>>> If you absolutely need to indicate that character as a single unit among other characters, in the upcoming v3 RFC format, you can include SVG artwork, and that artwork can use a little picture for RS (and for LF, which is also useful for RFC 7464 examples). That artwork would be quite clear and no one would expect to be able to copy-and-paste from the artwork.
>> That, IMHO, would be an abuse of SVG, and also be bad for accessibility.
> Fully disagree on both counts. Please justify the first. As for the second, the SVG would have have alt text saying what is being shown.
I'd say that using a vector graphics format to represent characters we
*could* use but don't *like* to use is a workaround for a problem we
But yes, alt text will help in that case.
>> As usually, things like this need to be done with care. I'd leave it to the production center.
> So, the IETF reviews the document with one set of content, then it appears differently in the RFC. That doesn't seem like a good solution.
That already happens all the time due to AUTH48 changes. I agree that's
something to avoid, but I believe that's an orthogonal discussion we
Best regards, Julian
More information about the rfc-interest