Mapping Stability/Storage (was Re: M-Label or MVALID, and dangers with mappings?)

[Mark Davis]

Breaking these apart, because they are very different topics.
Mark


2009/4/10 Patrik Fältström <patrik at frobbit.se>

> Let me just throw out some thoughts that are in my head. I just can not get
> rid of them.
>
> 1. Stability / Storage
>
> I think it is good that we talk about M-Label, as we have been talking
> about A-Labels and U-Labels and we (specifically myself) *REALLY* like the
> fact A-Label and U-Label are defined terms. And that we have a 1:1 mapping
> between them. That they are stable. It makes it possible to reference those
> explicitly in other specifications.
>
> Now, I think as always that we always will have mappings. Applications will
> (and should) _ALWAYS_ try to "help" the user by trying to understand what
> the user want to "type". We have different keyboards, different input
> mechanisms etc, so mappings will exist on different abstraction layers. As
> Pete Resnick said some weeks ago.
>
> Anyway, I think we have to say though that what is stored, regardless of
> where and how it is stored MUST be the A-label/U-label. This because I think
> the "further away" from the A-Label/U-Label we come in the abstraction, the
> more divergence we will get regarding support for mappings. This is btw
> where I have seen many problems with IDNA2003. Some people have in fact
> stored what has been possible to use as "input" to the IDNA algorithm, and
> not the "output".
>
> Now you might say that if people did not read the IDNA2003 spec, why would
> they read the IDNA2008 spec, but I am not prepared on giving up due to that.


I'm sympathetic to the goal, but the problem is what is meant by "storage":
memory, APIs, modules, threads, processes, communication protocols, email
bodies, IM messages, hrefs, ...? See my email of a few weeks ago. It might
be better to focus on the transmitting of IDNAs

I think what we can say is programs SHOULD convert to the canonical U-Label
form before transmitting to other IDNA-aware programs, and to the A-Label
form before transmitting to non-IDNA-aware programs. (The above isn't formal
language, but you can see what I mean.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090411/42fcc1f1/attachment.htm