[rfc-i] Pagination requirements

Julian Reschke julian.reschke at gmx.de
Wed May 16 01:00:22 PDT 2012


On 2012-05-16 09:36, Martin Rex wrote:
> =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= wrote:
>>
>>>
>>> Could you point to a specific location in that document where you believe
>>> that the lack of non-ASCII glyphs is a problem, I don't see one.
>>
>> Look for all the places where it uses "&#x" (including the first place,
>> where it explains why and how this is used).
>
> The&#x notation is a perfectly reasonable example for using the escapes.
> Using the real characters would be extremely counterproductive.

-10

I regularly see people who are confused by octet, characters, and escaping.

Using one thing (*ML escapes) where they do not belong (inside a URI) is 
not only not helpful but outright confusing.

> ...
>> The fact that author names also may contain non-ASCII characters would
>> significantly change this percentage.
>
>
> That is a completely silly argument.
>
> In order to ensure that author names on english language standards
> can be inserted, printed, read, and typed into english language
> references of that document, supplying the author name in ASCII letters
> is imperative.  Using a representation that 90% of the worlds population
> would not be able to (a) recognize and (b) type on their keyboard when
> being handed a hardcopy printout is entirely useless (for the purpose
> of a standard).
> ...

You aren't the only one with this opinion, but it's just that, an opinion.

The rough consensus I think I have seen is that we should allow authors 
to use non-ASCII in contact information, but also include a way to 
augment it with a plain-ASCII version.

>>> Helpful?  How?  Your example comes out as garbled noise here:
>>
>> In that case, what about getting a newer mail user agent?
>
> I completely fail to the see the purpose of that.

So you're in the business of developing code according to IETF specs, 
but you don't see the purpose in upgrading your MUA to a version that 
implements the relevant RFCs?

> Using the cyrillic example (since none of my software visualizes
> the Cherokee stuff), simple using the original Latin-1 letters instead
> gives the EXACT same visual result on screen and on paper!  So it would be

No, it does not.

> ...
>> The newest version of FireFox is at least 12.0. Maybe you should upgrade
>> (if for nothing else, then for security reasons).
>
> FF 12.0 shows THE EXACT SAME output.  square outlines with hexdigits
> in them, which gives a _very_strong_hint_ that it is a font problem.
> (all my machines are either WinXP or WinXP 64-bit).  MSIE and Outlook
> show empty square boxes instead.
> ...

So XP doesn't have the glyphs. That's good to know. I agree that we 
should take font availability into account (so maybe StPeter's example 
is problematic), but on the other hand we need to draw a line which 
ancient systems we want to support.

>>>       Cyrillic:&#x0405;&#x0422;&#x0420;&#x0415;&#x0422;&#x0415;R<p>
>>>
>>> Anyway, I consider it completely unnecessary trying to demonstrate (and fail)
>>> that there exist different unicode codepoints that have similar glyphs.
>>> It is perfectly sufficient to state that this is the case and leave all
>>> the rest to the Unicode SDO.
>
>
> While I'm 100% positively certain that ASCII text will be easily
> readable and comprehensible in 2000 years from now,  XML, HTML and Unicode
> could easily require a Rosetta Stone.  Needless complexity.  Too much
> concern about the exterior appearance, ignorance of internal values.
> Plastic surgery without medical indication, Nip&Tuck syndrome.

If you truly believe this, then it's likely impossible to agree with you 
on anything that changes the current format.

Best regards, Julian


More information about the rfc-interest mailing list