Q1 is mapping on lookup permanent or transitional?
lisa.dusseault at gmail.com
Wed Apr 1 20:26:18 CEST 2009
I'm assuming by "mapping" we now mean that when the application has a
string that is not valid as an IDNA2008 label, it tries to help the
user arrive at the most appropriate valid label by folding case and
doing some normalization. Under this definition:
- I believe this is permanent; applications never lose the need to
help the user.
- I don't know if we can require it. Certain applications may only
get valid input, e.g. applications that receive labels from the DNS in
the first place, display them, and let them be chosen for further
lookup. Other applications may have no way to confirm a conversion,
and prefer to simply reject bad input.
- I don't know if we can require universally consistent conversion to
valid labels. Some regions may adopt variations for their own maximum
- I don't have an opinion on what normalization, or how much, is most
appropriate -- I'm too ignorant in this area.
- The design should be done with at least some independence of
IDNA2003. If we were going to IDNA2008 from scratch, what would the
most appropriate help for users be? After considering that
independently, we can consider what tradeoffs to make to that
conversion definition for best backward compatibility with IDNA2003.
- Is there some way we can guide where this happens? E.g. encourage
protocol libraries to have a "mapToValid" method as well as a
"lookupValid" method that only accepts valid input. That way,
application implementors get the tools they need to see what's going
on and choose whether to confirm a suggested conversion or fail.
On Tue, Mar 31, 2009 at 9:05 AM, Vint Cerf <vint at google.com> wrote:
> Q1: Should the proposed mapping on lookup in a revised IDNA2008
> protocol specification be a permanent feature of the protocol or
> should it have a finite lifetime? Should it be required or optional?
> This question is intended to be independent of the actual mapping that
> is done. If the question cannot be answered without having specific
> mapping in mind, we should recompose the question accordingly.
> Vint Cerf
> 1818 Library Street, Suite 400
> Reston, VA 20190
> vint at google.com
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update