Hi,
so I have just implemented something with XEP-0114 (client side) and I
have a few questions.
(1) In my case, the component was locale. And I imagine that's quite
the most common case. But that's definitely not an obligation
(especially as we could imagine "component service providers"). Hence
TLS encryption should be possible.
Maybe it is, but XEP-0114, definitely tells nothing about it. It looks
like the way-to-do is connecting and directly handshake in plain text.
Maybe a <features/> logics would be nice. It would allow TLS, compression, etc.
This could be added in the same time we pass to an SASL authentication
for component.
(2) Is there not any default port (xmpp-component) for components,
same as we have default ports for xmpp-client and xmpp-server?
Or do we consider it the same as the "secret", which is that anyway
every component is expected to use a different port, that is known
only by configuration?
Note that this point does not annoy me. After all, components are
specific configured items (and usually limited) so we can consider the
port as a "configuration-only" information. Nevertheless a text about
this point may be worth added in the XEP to better explain the logics.
Also I think a server implementation should allow for multiple
components on a single port (I did not test if they already do this. I
just say we should add the text). If your server has 20 components,
you might prefer not to have to each time you add a component, open a
new port, but simply use the same as for your other components.
(3) The current logics seems to be that the component connects as
component.shakespeare.lit, keeps a long-live connection and from there
sends stanzas as [localpart@]component.shakespeare.lit[/resource] and
process any message sent to such an address.
That makes sense in this very common connection logics.
Now I have a use case where I would like to be able my component to
connect as different "entities" on this component. Basically I cannot
make a long-live connection. So I just want to be able to connect
several times.
For instance the component could connect as:
<stream:stream
xmlns='jabber:component:accept'
xmlns:stream='http://etherx.jabber.org/streams'
to='plays.shakespeare.lit/someresource'>
Or it could be also with a localpart (basically any JID that the
component plays.shakespeare.lit has control on).
For this kind of use case, we would want routing rules.
Basically if I connect with component domain part only, I would want
to receive any stanza. But if there is a stanza sent to a given
resource, and if the component is connected with this resource
specifically, it would grab the priority to receive this stanza. On
the other hand, the component connected with a resource must not
receive any stanza if another precise resource is specified.
And so on. Basically I propose to take into account this new kind of
component connection logics with routing rules (that we could now
discuss, or I could just propose the list of rules which I have in
mind).
That does not prevent the current usual logics: a single connection,
long-live, as the main component domain part. But that allows new
logics with multiple connections and appropriate routing.
What do you think of this?
Jehan
