MVALID (was Re: M-Label or MVALID, and dangers with mappings?)
patrik at frobbit.se
Sun Apr 12 02:21:25 CEST 2009
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".
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.alvestrand.no/pipermail/idna-update/attachments/20090412/534e6fe2/attachment.pgp
More information about the Idna-update