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

[Brad Fitzpatrick]

On Tue, 21 Nov 2006, Peter Saint-Andre wrote:

> Philipp Hancke wrote:
> > Peter Saint-Andre wrote:
> >> 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
> >>
> >
> > In 3920, stream:features is always sent from the receiving entity to
> > the initiating entity, never the other way round.
> >
> > What I was reporting was a (empty) stream:features element sent from
> > server1 to server2 after step 3 in the s2s example (5.4).
> >
> > Should that be silently ignored?
>
> Oh, I don't think the initiating server should be sending stream
> features. I mean it's not evil, but it's not expected. We could define
> how to handle that, but in the absence of such a definition I think the
> receiving server should ignore it.

Peter, tell us to change djabberd and we will, but for now I'm just
watching from the sidelines.

Philipp, which jabber server are you running?  Because I don't believe
we've run into this problem before with anybody else.

- Brad