Michael, Software currently under development could use the identifiers for choosing whether to require or emit BOM, like the file requirements checker I have to write, and ICU/uconv.
The inability to update to one standard all possible consuming software one might encounter (or for that matter human customers' opinions) is precisely why producing and checking software has to handle both possibilities. What would you mean by "the right thing" as far as emitting BOM? Should file conversion programs only allow output of non-BOM? (or with-BOM?) Or should they take the specification in an argument separate from the charset name? As said before this unnecessarily requires extra logic. Joseph -----Original Message----- From: Michael (michka) Kaplan [mailto:michka@;trigeminal.com] Sent: Monday, November 04, 2002 7:23 AM To: Joseph Boyle; Unicode Mailing List Subject: Re: PRODUCING and DESCRIBING UTF-8 with and without BOM From: "Joseph Boyle" <[EMAIL PROTECTED]> > Thanks for the dozens of responses discussing consumers' behavior on > UTF-8 BOM. This is actually not what I'm concerned with, as I have to > take it as a > given that there is both software that wants UTF-8 BOM and software > that doesn't want it. > > Could we evaluate the need for separate identifiers for producing or > describing UTF-8 with and without BOM, or viable alternatives to use > in control input to a file encoding converter program or encoding > checker program. Joseph, How on earth could a separate identier be USED unless software were updated to use it? And if they are updating to do this, why couldn't they just fix it anyway to do the right thing? There is no need here for separate identifiers, as they would not solve the problem, to the extent that a problem actually exists (I have yet to see proof that there is such a problem?). MichKa
