Lookup & NFC

[John C Klensin]

--On Thursday, 27 March, 2008 10:41 -0700 Shawn Steele
<Shawn.Steele at microsoft.com> wrote:

> I missed the part about mapping being moved to a different
> spec :)

The more important answer is that the intent of the spec is "if
you need this mapping, it is your job to apply it before you
invoke IDNA".  Taking NFC as an example, let's assume we have
two operating systems,

	* One of them gets strings into NFC form as soon as they
	are typed and verifies that (and corrects them if
	necessary) any time they are loaded or otherwise
	examined.
	
	* The other lets users type strings and carried them
	around in whatever form they are typed, presumably
	unnormalized.

For the first, it would clearly be silly for the internals of an
IDNA implementation to spend energy converting to NFC (although
as Mark has pointed out, I think on this list, the check that
the string is in NFC form is sufficiently simple and quick that
one might make it in the name of robustness).  For the second,
the spec requires that the application get the string into NFC
form before looking it up, but one would assume that would be
fairly natural.  As you implicitly point out, lookups of any
form would generally be expected to fail unless normalized
strings were compared to normalized strings.

best,
    john

> -----Original Message-----
> From: Shawn Steele
> Sent: aƞp̄et̄u t̄op̄a, iṡt̄a wiċa yazaƞ wi 27, 2008
> (Lakota Sioux) 10:40 AM To: idna-update at alvestrand.no
> Subject: Lookup & NFC
> 
> I'm confused about this requirement in the draft.  On a Mac,
> user entered labels wouldn't be in NFC, so during lookup I
> would expect to put them into NFC form.  I don't think that a
> user entered string should be disallowed because it wasn't
> NFC, so long as the lookup puts it in to NFC.  (or maybe NFKC?)
> 
> - Shawn
> 
> 
> --------------------------------------
> 
>  (lookup)
> 
> 5.4.  Validation and Character List Testing
> 
> ...
> 
>    o  Labels that are not in NFC form.
>