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

[Patrik Fältström]

On 11 apr 2009, at 20.07, Patrik Fältström wrote:

> On 11 apr 2009, at 18.14, Mark Davis wrote:
>
>> We would then define MSUBJECT in Tables using much the same process  
>> as you
>> have for PVALID, via combinations of properties and exceptions.
>
> And what would those rules looks like?

The reason why I ask for the rules for individual codepoints has to do  
with the fact that I think you Mark suggest a _procedure_ that should  
be walked through with a _label_ before even trying to look at  
individual codepoints and ensure all of them are PVALID (etc).

If you for example look at normalization, then you might have mappings  
from more than one codepoint to one (PVALID) codepoint, right? That  
does not though make each one of the individual codepoints in the  
input (substring) MVALID (using my terminology).

What I was after was the mapping from _individual_ codepoints to  
something, in a way that can be standardized. I THINK that might be  
the simple "lowercasing" (I intentionally use a sloppy terminology  
here) that might make the IDNA2003-IDNA2008 transision problematic.

So, I think we have the following:

1. User thinks of something
2. User expresses this in some way to a computer (for example by  
typing in some input mechanism)
3. The computer interpret this to some Unicode "stuff"
4. The application tries to "help" interpreting what was really meant
5. Recommended transformation happens, normalization etc
6. Recommended transition mapping happens
7. The result is U-label that is verified
8. The equivalent A-label is used

I think the difference here between what you and I talk about might  
be(?) that you talk about step 5, while I talk about step 6.

Maybe the best thing is to keep the mapping completely out of tables,  
so that the A-label/U-label definition is crystal clear?

Hmm...I start to think that is the best, as I think you talk about a  
"standardized process for cleaning up what applications think are  
domain names that a user enter".

    Patrik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.alvestrand.no/pipermail/idna-update/attachments/20090412/534e6fe2/attachment.pgp