Mapping and Variants

[Patrik Fältström]

And I do not understand your question. It must be because of lack of  
coffee. I thought the whole idea with mapping was to make it possible  
for people to "use" (note the quotation marks) upper and lower case  
characters in their domain names, but at the same time we then have to  
prohibit various dangerous combinations so that we do not _increase_  
the phishing issues. Either by mapping to the same character, or by  
having even more regular expressions (or both) in the standard.

I.e. I see the example being very valid.

YMMV...

    Patrik

On 9 mar 2009, at 09.25, Martin Duerst wrote:

> John said in an earlier mail
> (http://www.alvestrand.no/pipermail/idna-update/2009-March/ 
> 003751.html,
> second to last paragraph) that he thinks that if we do mapping,
> we have to map all of upper and lower case Latin a and Greek alpha
> to the same thing.
>
> The only thing I want is to very, very strongy question the above.
>
> Of course, somebody will registers AΑ, where the first is Latin
> and the second is Greek, e.g. on a third or fourth level, just
> because they can, but what I'm trying to say is that this is not
> a typical use case, and not one that we have to design mapping for
> (independent of whether mapping is part of the protocol
> (most probably not) or otherwise).
>
> Regards,   Martin.
>
>
> At 15:08 09/03/09, Patrik F舁tstr� wrote:
>> On 9 mar 2009, at 03.52, Martin Duerst wrote:
>>
>>> My point was that this is mainly theoretical, because mixing
>>> scripts in general, and very much in this case, is a bad idea,
>>> nonwithstanding examples where it actually might make some sense,
>>> such as μvolt. Can you give an example that makes a bit more
>>> sense than just "AA"?
>>
>> Martin, people will most certainly register this, "just because they
>> can". The example because of this I think is valid.
>>
>> You also have to remember that people do have interest in mixing
>> scripts, for example various scripts and latin.
>>
>> To limit the problems we do have in IDNA2008 two things that protect
>> against problems:
>>
>> - We have defined what is a U-label and A-label, and because of this,
>> it is a very very clear signal what codepoints should be used. If we
>> also have mappings, fine, but it is clear that those characters are  
>> in
>> the gray area whether they should be used for example in  
>> publications.
>>
>> - We have for the most problematic situations regular expressions  
>> that
>> limit the use of some codepoints that create real problems if they  
>> are
>> used in a non-intended-context.
>>
>> What do you want more? You want more regular expressions? You want to
>> reopen the discussion on mixing scripts again?
>>
>>   Patrik
>>
>>
>>
>> content-type: application/pgp-signature; x-mac- 
>> type=70674453;name=PGP.sig
>> content-description: This is a digitally signed message part
>> content-disposition: inline; filename=PGP.sig
>> content-transfer-encoding: 7bit
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.8 (Darwin)
>>
>> iD8DBQFJtLJErMabGguI180RAiejAJwPnN20mypjEy4cMccW8luTM8/c5wCfXxmG
>> S117mtZOxEs1rQNlATKwI7o=
>> =QXj6
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
> #-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp
>
>

-------------- 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/20090309/cb45b5e8/attachment.pgp