[Standards] [Fwd: Re: [jdev] BOM]

Peter Saint-Andre stpeter at stpeter.im
Fri Nov 14 18:08:06 UTC 2008

FYI. I propose adding the following text to the character encoding
section (12.6) of rfc3920bis:


Note: Because it is mandatory for an XMPP implementation to support all
and only the UTF-8 encoding and because UTF-8 always has the same byte
order, an implementation MUST NOT send a byte order mark ("BOM") at the
beginning of the data stream.


-------- Original Message --------
Date: Thu, 13 Nov 2008 16:35:19 -0700
From: Peter Saint-Andre <stpeter at stpeter.im>
To: Jabber/XMPP software development list <jdev at jabber.org>
Subject: Re: [jdev] BOM

Waqas Hussain wrote:
> On Fri, Nov 7, 2008 at 11:06 AM, Jonathan Dickinson
> <jonathan.dickinson at k2.com> wrote:
>>> -----Original Message-----
>>> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of Peter Saint-Andre
>>> Sent: 07 November 2008 01:51 AM
>>> To: Jabber/XMPP software development list
>>> Subject: Re: [jdev] BOM
>>> Jonathan Dickinson wrote:
>>>> Much obliged. As a case of interopability, maybe something like:
>>>> entities MUST NOT send byte order marks, however, they MUST tolerate
>>>> them.
>>>  I'm not sure exactly what "tolerate" means.
>> Receiving entities shouldn't fall over when they get a BOM at the start of the stream: like the clients that I used to test my server did.
>> -- Jonathan
> Considering that no servers send out BOMs, and pretty much no clients
> do either, I don't really see much point in requiring all XMPP
> software to handle BOMs.

Having done a bit more research, my position is now this: given that
XMPP is UTF-8 and that UTF-8 always has the same byte order, why would
we ever need to include or support a byte order mark in XMPP?


More information about the Standards mailing list