mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: svn commit: r807187 - in /mina/sandbox/vysper/trunk/server/core/src: main/java/org/apache/vysper/xmpp/delivery/ main/java/org/apache/vysper/xmpp/modules/core/im/handler/ main/java/org/apache/vysper/xmpp/stanza/ main/java/org/apache/vysper/xmpp/st
Date Tue, 25 Aug 2009 14:20:36 GMT
(Sorry for top-posting)

Again, it all comes down to the difference between outbound and inbound.
I cannot stress enough how important it is to understand the fundamental
concept behind that.[1]

The client sends directed presence ('d-p') to the server for entering a
MUC room ('outbound'). The server then forwards the d-p to the MUC
server (be it local or remote), where it becomes 'inbound'. The inbound
stanza has (as I suspect) the FULL JID present as a FROM attribute, so
this should not really be a problem. Otherwise there is no way for the
client your chatting with to know where to reply to. (Note that some
clients like Psi display details about your contact's resource ids.)
MUC is in the very same position like a 'regular' receiver, say, another
smack client session chatting with you[2].

This is why components should not eavesdrop on outbound stanzas on the
sending client's session.
But I agree that MUC has to work this way a little bit longer because:

I'm currently building this logic[3] where we properly handle the
transfer between outbound and inbound, but it'll take a while. It works
for sending messages and subscribed presence ('subscribed' in opposite
to 'directed') but some cases are not yet handled properly.

This logic also handles combinations of online/offline users, full/bare
JIDs, depending on the stanza type and the type attribute.

This work is relevant for s2s, too.

I'm currently in good faith that I've got a pretty good understanding of
RFC3921. However, there probably are still misconceptions flying around
in my head. So it would be good if somebody else would be able to review
the changes I'm working on. :-)


[1] http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-00#section-4
[2] http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-00#section-5.1
[3] http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-00#section-8

Michael Jakl wrote:
> Hi!
> On Tue, Aug 25, 2009 at 15:24, Niklas Gustavsson<niklas@protocol7.com> wrote:
>> If the client send a full JID, that is true. But, as in the case of
>> Smack, the client might not send a "from" attribute at all, in which
>> case we will need to figure out a resource anyways (not sure yet what
>> the best way is or if the spec says this somewhere).
> Regarding the resource identifiers, I found this in the RFC3920:
> <quote>
> 3.4.  Resource Identifier
> The resource identifier is an optional tertiary identifier placed
> after the domain identifier and separated from the latter by the '/'
> character. A resource identifier may modify either a <node@domain> or
> a mere <domain> address. It usually represents a specific session,
> connection (e.g., a device or location), or object (e.g., a
> participant in a multi-user chat room) belonging to the entity
> associated with a node identifier. A resource identifier is opaque to
> both servers and other clients, and is typically defined by a client
> implementation when it provides the information necessary to complete
> Resource Binding (Resource Binding) (although it may be generated by a
> server on behalf of a client), after which it is referred to as a
> "connected resource". An entity MAY maintain multiple connected
> resources simultaneously, with each connected resource differentiated
> by a distinct resource identifier.
> </quote>
> Further in Section 7:
> <quote>
> 7.  Resource Binding
> In general this applies only to clients: in order to conform to the
> addressing format (Addressing Scheme) and stanza delivery rules
> (Server Rules for Handling XML Stanzas) specified herein, there MUST
> be a resource identifier associated with the <node@domain> of the
> client (which is either generated by the server or provided by the
> client application); this ensures that the address for use over that
> stream is a "full JID" of the form <node@domain/resource>.
> </quote>
> Is the client not bound for MUC? If it is, there should be the
> resource (and hence, the full JID) available... somewhere.
> It's likely that I missed something, I was just skimming the mails.
> HTH anyways,
> Michael

View raw message