Re: BOM ambiguity?

2012/7/13 Asmus Freytag <asmusf_at_ix.netcom.com>:
> A) treating NUL as ignorable is really deep legacy. Totally no longer
> appropriate for modern data.

I did not say that. But modern data heavily uses bytes as fillers for
padding, or as terminators in various enveloppe formats. There are
some more rare cases (though not exceptional) where they are used as
separators in lists of strings, often terminated by a double null i.e.
an empty string.

> B) there are many Unicode character codes with leading or trailing or other
> NUL bytes, so UTF-16 and UTF-32 cannot be exchanged under the assumption of
> "NUL is ignorable"

Also I dod not say that it was ignorable.

The very old applications where it was ignorable was in some terminal
protocols (it could be used for example for "pinging" and inform to
the remote side of a communication link that we are still active in
order to maintain a session wihout having to logon again, or restart
on ongoing unterminated transaction. There are better protocols today
that allow similar function without requiring any specific character,
using an envolope allowing a secondary out of band control for the
session over the same link (this includes for example HTTP, though
this protocol is not purely plain-text by itself).
Received on Fri Jul 13 2012 - 16:56:58 CDT