[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] compatibility chars in draft-ietf-idn-nameprep
- To: Keith Moore <moore@cs.utk.edu>
- Subject: Re: [idn] compatibility chars in draft-ietf-idn-nameprep
- From: RJ Atkinson <rja@inet.org>
- Date: Wed, 16 Aug 2000 09:39:29 -0400
- Cc: idn@ops.ietf.org
- Delivery-date: Wed, 16 Aug 2000 06:45:03 -0700
- Envelope-to: idn-data@psg.com
At 09:20 16/08/00, Keith Moore wrote:
>> So, for that reason, I think that while it is reasonable
>> to prohibit certain characters from use "on the wire", it is
>> unreasonable to prohibit all user interfaces from converting from
>> a prohibited character to an *fully equivalent* allowed character.
>
>perhaps. but in such cases it's important that the protocol
>(and API) used doesn't confuse the two. If some layer translates
>a prohibited character into a permitted one, then the protocol
>and API need to provide the feedback to the application -
>here's what you typed, here's what I assumed you meant.
While it might be reasonable to suggest this behaviour,
it is outside the IETF's scope to require this of an API
that *by its very definition* is NOT an IETF standard.
Note that in my concept, the IDN protocol would only
accept/contain characters that were permitted and were already
normalised/canonicalised.
>That way it as at least possible to write applications which
>handle these things reasonably.
>
>(applications used to do this with domain names- if you typed in
>a name which mapped to a CNAME the app would then display the
>name indicated by the CNAME record)
Many modern applications do not do this. While some
might consider this a bug, it is commonly not done today.
Ran
rja@inet.org