[rfc-i] Pagination requirements

[Peter Saint-Andre]

On 5/15/12 3:43 PM, Julian Reschke wrote:
> 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.

Yes, more and more specifications in the Apps Area, RAI Area, and even
Security Area need to say something about internationalization. They
don't all need to include non-ASCII characters, but for those that do
this issue needs to be addressed.

Peter

P.S. Here's a relevant paragraph from a discussion about visually
similar characters in the security considerations of an I-D I'm working
on (draft-ietf-precis-framework)...

   However, the problem is made more serious by introducing the full
   range of Unicode code points into protocol strings.  For example, the
   characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 from the
   Cherokee block look similar to the US-ASCII characters "STPETER" as
   they might look when presented in a "creative" font.

It would be helpful to include the actual characters, not just the
Unicode codepoint numbers:

   However, the problem is made more serious by introducing the full
   range of Unicode code points into protocol strings.  For example, the
   characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 from the
   Cherokee block, i.e., "ᏚᎢᎵᏋᎢᏋᏒ", look similar to the US-ASCII
   characters "STPETER" as they might look when presented in a
   "creative" font.