"Eric A. Hall" <[EMAIL PROTECTED]> wrote: > > The simplest fully-precise definition is: An ACE label is a label > > that gets altered when ToUnicode is applied to it. > > In terms of the specific context of domain names embedded in data > streams, wouldn't the simplest definition be: any label that begins > with the ACE prefix?
Sorry, I meant the simplest definition consistent with the usage in the IDNA draft. Your proposed definition is simpler, but it defines a different concept from the one the IDNA draft is trying to define. I wanted a term for non-WYSIWYG label, that is, a label that doesn't directly say what it means, and is therefore displayed differently in IDNA-aware applications versus IDN-unaware applications. Obviously, the definition "label that gets altered by ToUnicode" corresponds exactly to this concept. > The problem scenario is having an app decode and display the name, but > where DNS does not. This allows for a hostile party to provide a link > to www.zz--amazon.com which decodes for display as www.amazon.com on > the compliant browser, but where DNS is sending the victim party to > www.zz--amazon.com. I don't think there is a problem. The ToUnicode operation will never return an all-ASCII label that differs from the input. If the input is zz--amazon then the result cannot be amazon, because amazon is all-ASCII. ToUnicode never alters invalid ACE labels. If zz--amazon is an invalid ACE label, then ToUnicode will leave it unchanged, and therefore the IDNA-compliant application will display it as zz--amazon. AMC
