Archaic scripts

[Erik van der Poel]

Hi Lisa,

I agree that there is no bright line between upgradable and
unupgradable software, but if we choose to say anything about this in
the RFCs, it would probably just be a recommendation, to nudge things
in the direction of better interoperability. In a sense, *all* RFCs
are just recommendations, made in the hope that they will maintain or
foster interoperability, right?

There *is* a bright line between protocols that only support LDH- and
A-labels and those that support U-labels. For example, there is a
draft that aims to specify how things would be done in SMTP (with
U-labels). If a mobile phone manufacturer would like to burn the
program in ROM, they can have the mobile phone deal with LDH- and
A-labels only, leaving U-label translation to the software on the
mobile carrier's ("server") side.

Of course, this bright line was crossed by the HTML browser and
plug-in developers shortly after IDNA2003 stabilized, even though
there are clear warnings in the RFCs about IDNA-unaware domain name
slots. Shame on those early developers.

However, no matter what we write or don't write about unupgradable
software, I still recommend that we allow pieces of software that
receive Punycode labels to look them up in DNS, without having to
decode them and check for DISALLOWED, CONTEXT*, etc. This allows those
pieces of software to remain unchanged and still work, even if an
unassigned codepoint is assigned, a contextual rule is changed, etc.
I.e. better interoperability.

This puts the onus on those that attempt to convert Unicode labels to
A-labels for registration or lookup, and those that attempt to convert
Punycode labels to Unicode for safe and unconfusing display. This is
as it should be.

Erik

On Fri, May 9, 2008 at 6:58 AM, Lisa Dusseault <ldusseault at commerce.net> wrote:
>
> On May 8, 2008, at 4:01 PM, Erik van der Poel wrote:
>
>>
>> If we lock down the DISALLOWED set too tightly, we may regret it
>> later. One way to avoid locking it down is to recommend that
>> burned-in-ROM and other unupgradable software only use protocols that
>> use LDH- and A-labels. All pieces of software, whether IDNA-aware or
>> not, are explicitly permitted to look up Punycode labels, without
>> decoding them to check for DISALLOWED, CONTEXT*, etc.
>
> Not that this point is essential to most of your argument, but recommending
> that unupgradable software only use certain protocols is a completely
> infeasible requirement or recommendation for the IETF to make.  Even if we
> thought such a recommendation would be paid attention to, there's no bright
> line between "upgradable" and "unupgradable" software -- even software that
> is in theory upgradable is often in practice locked into particular versions
> for years, skipping even vital security upgrades.  So even if implementors
> followed such a requirement, we still can't expect timely upgrades of
> codepoint listings.
>
> There's also no bright line between protocols or software that use LDH- and
> A-labels and those that don't, right?  As you point out, even IDNA-unaware
> software may look up Punycode labels, and naturally those implementations
> won't follow requirements we make on limiting lookups.
>
> Lisa
>