Subject: [idn] should BOM be supported

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 30 Jan 2001 10:11:47 -0800

Encoding and where-to-do-nameprep issues aside, has the subject of byte
order mark been covered? I'm still trying to catch up with all of the
older material so if this topic has already come up, a quick answer will
be appreciated.

Anwyay, it seems to me that in order to provide for a truly international
namespace we need to allow for BOM within the labels. This is particularly
true given a mix of names in legacy TLDs which may conflict with any newer
internationalized TLDs which may be eventually developed. For example,
[arabic].sa needs to support right-to-left BOM for the [arabic] label
while also supporting traditional left-to-right encoding for the sa TLD
label.

I say its a potential issue because if [arabic] is required to be
represented in LTR form then a future (albeit only a potential) arabic TLD
for any of the Middle East nations could cause a variety of name
recognition and IP disputes.

Ignore the potential byte cost and encoding issues for the moment please.
Is this feasible? What other issues are there?

If the inclusion of BOM is not feasible for nameprep then should the issue
of byte ordering be dealt with as a part of nameprep process (dictate the
orderuing that must be used, but exclude BOM).

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

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 30 Jan 2001 12:45:11 -0800

> If the inclusion of BOM is not feasible for nameprep then should the
> issue of byte ordering be dealt with as a part of nameprep process
> (dictate the orderuing that must be used, but exclude BOM).

Following myself up, I had an off-line chat and a future version of
nameprep is likely to clarify that labels are handled left-to-right so any
formatting which is applied prior to this stage must be dealt with prior
to this stage. Explicit policy statement expected.

Thanks

---

From: [email-masked] (David C Lawrence)
Date: Tue, 30 Jan 2001 16:45:07 -0500 (EST)

Please note that the Byte Order Mark is not used in the bidirectional
algorithms.  Its purpose is to indicate the endianness of 16 bit and
32 bit characters, not to indicate the display direction.  I don't
think it would make much sense to use the BOM on a per-label basis.
More likely you'd see in places such as the start of a zone file that
is stored in UCS-2 or UCS-4, to indicate the byte order of the entire file.