> 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. 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) Keith
- [idn] compatibility chars in draft-ietf-idn-nameprep Frank Ernens
- Re: [idn] compatibility chars in draft-ietf-idn-na... Paul Hoffman / IMC
- RE: [idn] compatibility chars in draft-ietf-idn-na... Jonathan Rosenne
- RE: [idn] compatibility chars in draft-ietf-idn-na... RJ Atkinson
- Re: [idn] compatibility chars in draft-ietf-idn-na... Keith Moore
- Re: [idn] compatibility chars in draft-ietf-idn-na... RJ Atkinson
- RE: [idn] compatibility chars in draft-ietf-idn-na... Paul Hoffman / IMC
- RE: [idn] compatibility chars in draft-ietf-idn-na... RJ Atkinson
- RE: [idn] compatibility chars in draft-ietf-idn-na... Paul Hoffman / IMC
- Re: [idn] compatibility chars in draft-ietf-idn-na... Harald Alvestrand
- Re: [idn] compatibility chars in draft-ietf-idn-na... James Seng
- Re: [idn] compatibility chars in draft-ietf-id... Harald Alvestrand
- RE: [idn] compatibility chars in draft-ietf-idn-na... Frank Ernens
