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 <[EMAIL PROTECTED]>
To: Jabber/XMPP software development list <[EMAIL PROTECTED]>
Subject: Re: [jdev] BOM
Waqas Hussain wrote:
> On Fri, Nov 7, 2008 at 11:06 AM, Jonathan Dickinson
> <[EMAIL PROTECTED]> wrote:
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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?
Peter
