Re: [idn] IDN refocus, v4

["Eric A. Hall" <ehall@ehsco.com>]

James Seng/Personal wrote:

> Our opinion on host vs domain name isnt really different :-). The
> question is which one do we do? Or both? All are valid answer.

The encoded values being passed around are supposed to -decode- as UCS
character codes, so it would seem best to maintain consistency across all
outputs. We do not want to make it more complex than necessary and
defining multiple extraction profiles would make processing much more
complex: "we promise that this encoding will represent a series of UCS
characters" should be it. For that reason, my opinion is that any UCS
character code (including those not yet assigned) should be valid for
internationalized domain names (with nameprep providing the host name
subset filter). Going that route incurs a responsibility to tell
implementations that they have to be careful with data they process, but
in truth we had that responsibility already given the broader exposure of
the combining characters.

> Do we need more than one IDN label encoding that protocols and
> applications can use to store and represent i18n domain names?

I would submit that we are describing transfer encodings and their
handling. The application media being used to transfer the encoded values
provide seven- and eight-bit paths. For the sake of maximum efficiency
with the applications that transfer and use the domain names, we should
provide seven- and eight-bit encodings. The encapsulation constraints in
DNS are difficult to work with but that does not change the above. We
should not be defining mandatory seven-bit encodings for eight-bit
applications especially if they are compliant with BCP18 for every unit of
protocol and/or application data.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/