djabberd <stream:features/> bug [Fwd: livejournal]

[Peter Saint-Andre]

This is not a bug. See for instance this text at the end of Section 6.2
of RFC 3920:

   Upon receiving the new stream header from the
   initiating entity, the receiving entity MUST respond by sending a
   new XML stream header to the initiating entity, along with any
   available features (but not including the STARTTLS and SASL
   features) or an empty <features/> element (to signify that no
   additional features are available)....

/psa

Brad Fitzpatrick wrote:
> What server are you running?
> 
> Where in the spec does it say this is wrong?  I thought it was a MUST to
> send stream features if the other side was version='1.0' or whatever.
> 
> 
> On Mon, 6 Nov 2006, Philipp Hancke wrote:
> 
>> Hi Brad,
>>
>> Carlo forwarded me this log showing a connect attempt from livejournal
>> to ve.symlynx.com. It seems that djabberd sends an empty
>> <stream:features/> when connecting to a remote server, which is
>> something I've never seen anyone doing.
>>
>> This puzzles ve.symlynx.com, which is responding with a
>> <improper-addressing/> error and closing the stream
>> (and eventually results in a connection failure).
>>
>> I wonder why this did not show up at that interop meeting...
>> could you fix it anyway please?
>>
>> Thanks in advance
>>
>> Philipp
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.danga.com/pipermail/djabberd/attachments/20061120/888e0187/smime.bin