[rfc-i] Pagination requirements

Julian Reschke julian.reschke at gmx.de
Tue May 15 14:43:54 PDT 2012


On 2012-05-15 23:34, Martin Rex wrote:
> Julian Reschke wrote:
>>
>>> RFCs specify data and functions in abstract fashion, program source code
>>> specify a particular implementation.  If the RFC can not get along with
>>> plain ASCII, then it is probably not a technical specification that
>>> others want to implement, but rather demo/marketing/sales material.
>>
>> OMG. Did you ignore the whole requirements discussion?
>>
>> Did you ever have to write/review/implement a document that deals with I18N?
>
> No, I'm not in the Human UI business.
>
> For protocols and machine-level interop, visualization of glyphs outside
> of US-ASCII is irrelevant.

OK; my conclusion is that you indeed do not understand where the 
requirement comes from, and that you do not care.

> Just how many documents in the IETF RFC series are there where positioning
> or shape of non-ascii glyphs are vitally important.  I would assume that
> those are few, and probably _not_ scattered over all IETF areas and
> protocol layers.

It's simply extremely hard to explain in a specification how to deal 
with non-ASCII characters if you can't use them.

Read RFC 3987, then please come back and explain why this is not a problem.

> It might be more appropriate to address such documents with a specific
> exception, rather than a "the tail wagging the dog" approach.

So the exception would be ... what? "Non-ASCII characters are allowed 
for examples in specs dealing with I18N." That's exactly what was proposed.

Best regards, Julian




More information about the rfc-interest mailing list