Re: [idn] Figuring out what can be displayed

[John C Klensin <klensin@jck.com>]

Adam,

With all due respect, this does not pass the laugh test.  Yes,
there are grounds for ignoring a "SHOULD".  That is why we call
it "SHOULD" and not "MUST".  But we don't describe things that
violate SHOULDs with phrases like "fully conforming", regardless
of the cause (please see RFC 1122 and 1123, full Internet
Standards, which 2119 does not supercede/obsolete).  I chose my
language carefully.

I decided caution and politeness was appropriate in my previous
note.  But, to drive the point home here, please identify at
least two operating systems in common use today in which an
application can accurately determine that it can display a
particular, arbitrarily-chosen, Unicode character.  (Determining
that it can't is easy -- any operating system that doesn't
support passing of Unicode characters to a print/display routine
would essentially permit applications to make that determination
at compile-time.)

     john


--On Tuesday, 10 September, 2002 21:01 +0000 "Adam M. Costello"
<idn.amc+0@nicemice.net.RemoveThisWord> wrote:

> John C Klensin <klensin@jck.com> wrote:
> 
>> > The spec says that an application SHOULD NOT show the ACE
>> > form if it can correctly display the Unicode form, and it
>> > SHOULD show the ACE form if it cannot correctly display the
>> > Unicode form.
>> 
>> So, an application must, ultimately, either decide that its
>> operating environment can handle Unicode acceptably...
>> 
>> Or the application must decide that it can't know
> 
> Those are not the symmetric choices.
> 
>> and therefore must display the ACE form always...
> 
> That does not follow from not knowing.
> 
> The cases are:
> 
>  1. The application can determine whether the environment can
> handle the     non-ACE form.  In this case, exactly one of the
> two recommendations     applies, and it's perfectly clear what
> to do.
> 
>  2. The application cannot know.  It is then faced with the
> following     two symmetric choices:
> 
>     2a. Optimistically try to display the non-ACE form, which
> might         or might not work.
> 
>     2b. Pessimistically display the ACE form, which is
> guaranteed to         look like garbage to humans and
> guaranteed to be okay for         software.
> 
>> If, in order to be fully-conformant, a specification requires
>> an implementation to make a decision based on something it
>> can't know,
> 
> The spec says "SHOULD".  RFC 2119 says "there may exist valid
> reasons in particular circumstances to ignore" a SHOULD.  I
> think the unavailability of sufficient information about the
> environment to determine whether the recommendation applies is
> a particular circumstance that qualifies as a valid reason to
> ignore the SHOULD.
> 
>> that is, IMO (in the language of RFC 2026) a "technical
>> omission", and one of fairly serious proportions.
> 
> It's an omission if something has been omitted.  What has been
> omitted?
> 
>> If we cannot provide a better model, the text cannot, I
>> think, say anything stronger than that the application MAY
>> show either the ACE or the Unicode form, at its discretion,
>> and leave this issue up to user pressure and implementation
>> quality.
> 
> We can do better than that.  When the application can
> determine whether the non-ACE form can be displayed, we don't
> need to leave it up to the application's discretion, we can
> prescribe the proper choice.
> 
> AMC
> 
> 
>