[rfc-i] Pagination requirements
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