Re: [Standards] NEW: XEP-0225 (Component Connections)
Ralph Meijer wrote: jabber:server and jabber:client both don't make much sense for component streams. I think we have a couple of choices here: 1. Use a separate namespace for the component streams. 2. Choose from jabber:server and jabber:client 3. Iff we do a new version of XMPP (i.e. 1.0), we could choose one namespace for all connections. I strongly prefer 1 over 2, I prefer that too. Not sure I strongly prefer just yet. :) but if we do 2, I'd choose jabber:server. I'm agnostic on that. Either way, we're forcing a square peg into a round hole. Option 3 is something that could be considered, but if you want to be interoperable with client and server implementations that implement versions =1.0, you still have to do some juggling at the edges. However you would change the namespaces to and from that new namespace and use the new namespace internally. We've always tried not to break older software. I see no good reason to change that policy now. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0225 (Component Connections)
I'm a bit torn about this, comments inline.
On Wed, 2007-08-08 at 15:11 -0700, Justin Karneges wrote:
On Wednesday 08 August 2007 1:44 pm, Peter Saint-Andre wrote:
XMPP Extensions Editor wrote:
Version 0.1 of XEP-0225 (Component Connections) has been released.
Abstract: This document specifies a standards-track XMPP protocol
extension that enables server components to connect to XMPP servers.
One of the items up for discussion is the default namespace for
component connections. At the XMPP DevCon we thought that it would be
good to use 'jabber:client', but I know that both Matthias Wimmer and
Ralph Meijer have some arguments for 'jabber:server'. So perhaps we
could have a debate about that. :)
For namespace-aware implementations, these multiple namespaces are a real
pain. body xmlns='jabber:client' and body xmlns='jabber:server' have
identical meaning: a body of a message. Yet, namespace-aware implementations
will consider these to be two distinct elements. This affects the creating
and parsing of all RFC 3920 and 3921 XML data. You need to write code that
understands both namespaces and can output under either namespace (depending
on whether a stanza is going out on c2s or s2s).
In jabberd2, I believe all XML is internally handled in the jabber:client
namespace. I did the same thing in Ambrosia. When a stanza arrives over
s2s, I iterate over the DOM and change all namespace instances
of 'jabber:server' to 'jabber:client' (note here that I'm not talking about
xmlns attributes, but rather the namespace property of each DOM element).
This allows me to reuse all of my existing stanza parsing and generation code
based on a single namespace ('jabber:client').
Since I am interesting how others do this, I'll first describe how I go
about this.
My namespace handing code has None besides the typical empty and
non-empty namespace names. None means inheriting from whatever is the
default namespace of the parent (or closest ancestor that sets this. So,
I convert the namespace to None on incoming messages and to the stream
namespace on outgoing messages.
This keeps namespace changes at the edges. Not having a defined default
namespace the elements in transit between parts of the server make sense
to me, as they don't actually belong to any of the currently defined
stream namespaces.
That said, all server implementations need to do this namespace juggling
anyway, so I don't see how it is an extra burden to do this for another
namespace, too.
Additionally, I think indicating support for a feature or connection type
simply through a namespace declaration is weird. A namespace declaration
indicates what namespace child elements should be assigned to, when you
actually have child elements. By itself it doesn't have much meaning.
Namespace declarations don't show up in DOM either (they do show up in SAX
though, which is how I handle them). I personally think it was a mistake to
use namespace declarations to indicate c2s vs s2s, or to indicate dialback
support, and so I vote not repeating this mistake. This means
no 'jabber:component' or such. The choice should be between 'jabber:client'
and 'jabber:server' for the namespace. Use a real attribute or element to
indicate component support.
I can sympathize with the reasoning, actually. This is a clear case of
hist(e|o)ric reasons. I have to agree with Rachel and Peter here,
though, that jabber:server and jabber:client both don't make much sense
for component streams. I think we have a couple of choices here:
1. Use a separate namespace for the component streams.
2. Choose from jabber:server and jabber:client
3. Iff we do a new version of XMPP (i.e. 1.0), we could choose one
namespace for all connections.
I strongly prefer 1 over 2, but if we do 2, I'd choose jabber:server.
Option 3 is something that could be considered, but if you want to be
interoperable with client and server implementations that implement
versions =1.0, you still have to do some juggling at the edges. However
you would change the namespaces to and from that new namespace and use
the new namespace internally.
--
Groetjes,
ralphm
Re: [Standards] NEW: XEP-0225 (Component Connections)
Hello, i am for jabber:client because i don't like the namespace switching in software. But this does not help that much if we stick with other namespaces on s2s connections forever. Alex
Re: [Standards] NEW: XEP-0225 (Component Connections)
Hi Justin! Justin Karneges schrieb: I don't have a strong preference really. A component feels a bit more like a client because it is a local connection, plus c2s connections are simpler than s2s connections. Let's pick one and be done with it. :) The reason why I for the most part suggest using jabber:server instead of jabber:client is, that in the jabber:client namespace the from attribute on stanza is optional, while on jabber:server it is not. I think this is one of the biggest differences between these two namespaces. In fact I think it's the only difference. ;-) There's an even bigger one: server connections can only send stanzas in one direction. Although that's more of a protocol thing than a schema thing, if you want to get picky. :) That's exactly what I thought. You will probably implement s2s and component connections in different components, so that the protocol part is not that important. - But the schema is shared between both if they use the same namespace. That's why I would pick the jabber:server namespace. BTW: Even jabber:server connections do not have to be unidirectional, that is only a (current) restriction if you use SASL for authentication. (It meight even happen, that this restriction will be dropped sometime in the future, at least I would not be surprized.) As I said, I think there are reasons to go with either jabber:client or jabber:server. It may more more a matter of picking one than choosing based on some reasoning. I always figured components were more like clients than servers. Clients and components make single outbound connections, and construct and parse stanzas for server routing. In contrast, servers do very little stanza manipulation (and, depending on how your server is designed, even the roster stuff might be in a component). ... you might even do the roster stuff on a different server, that is connected using a s2s connection to the other server. I already set this up once. It is stanza manipulation that really kicks your ass when it comes to the different namespaces, and so sharing the same one as clients would be useful I think. In jabberd14 and as you (?) said at least in jabberd2 as well (don't know the other servers) all handling is internally done in the same namespace. This can be jabber:server (like in jabberd14 for the reasons from above) or jabber:client (like in jabberd2) and does not make a big difference for the server (it's just reading both namespaces as the same namespace and when serializing XML it's using the expected namespace on that connection to serialize the common internal namespace). So if everybody else preferes the jabber:client namespace I can live with that. But I'd prefere to use 'jabber:server'. Even if have a bit of the expression, that people merely prefere 'jabber:client' just because more people seem to work on clients or client connections were they are more used with using 'jabber:client' as the standard namespace, than working on s2s connections. Matthias
Re: [Standards] NEW: XEP-0225 (Component Connections)
Dnia 10-08-2007, pią o godzinie 10:26 +0200, Matthias Wimmer napisał(a): But I'd prefere to use 'jabber:server'. Even if have a bit of the expression, that people merely prefere 'jabber:client' just because more people seem to work on clients or client connections were they are more used with using 'jabber:client' as the standard namespace, than working on s2s connections. Could it be, that I prefer jabber:server for the same reason? :-) -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] NEW: XEP-0225 (Component Connections)
Hello On Fri, Aug 10, 2007 at 11:19:59AM -0700, Justin Karneges wrote: That said, all server implementations need to do this namespace juggling anyway, so I don't see how it is an extra burden to do this for another namespace, too. What doesn't sit well with me is this idea of the standard elements having to live under any random namespace. The namespace is what gives them meaning. If we only ever have exactly two (or potentially with a component namespace, exactly three) possible namespaces for the elements, maybe that is fine. What is not fine is having to worry that someday down the line we may invent yet another namespace that the standard elements must be able to operate under. Is body omnipresent, and existing potentially in all namespaces? :) Well, I take body/ does what it does if it is in the same namespace with stanzas, and it does not much matter which kind of stanza it is (client, server, whatever). Technically, it is the namespace that gives the meaning, but - if you look at the xml document/stream - it is the body that inherited the namespace and does not have the xmlns= attribute (do I sound like XML heretic to you?). -- Security warning: Do not expose this email to direct sunlight. It may lead to undefined behaviour, including possible data or life loses. Michal 'vorner' Vaner pgpf3tKIm9RN6.pgp Description: PGP signature
Re: [Standards] NEW: XEP-0225 (Component Connections)
Dnia 08-08-2007, śro o godzinie 15:11 -0700, Justin Karneges napisał(a): I vote not repeating this mistake. This means no 'jabber:component' or such. The choice should be between 'jabber:client' and 'jabber:server' for the namespace. Use a real attribute or element to indicate component support. +1 -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] NEW: XEP-0225 (Component Connections)
Tomasz Sterna wrote: Dnia 08-08-2007, śro o godzinie 15:11 -0700, Justin Karneges napisał(a): I vote not repeating this mistake. This means no 'jabber:component' or such. The choice should be between 'jabber:client' and 'jabber:server' for the namespace. Use a real attribute or element to indicate component support. +1 I don't have a strong preference really. A component feels a bit more like a client because it is a local connection, plus c2s connections are simpler than s2s connections. Let's pick one and be done with it. :) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0225 (Component Connections)
Hi Peter! Peter Saint-Andre schrieb: I don't have a strong preference really. A component feels a bit more like a client because it is a local connection, plus c2s connections are simpler than s2s connections. Let's pick one and be done with it. :) The reason why I for the most part suggest using jabber:server instead of jabber:client is, that in the jabber:client namespace the from attribute on stanza is optional, while on jabber:server it is not. I think this is one of the biggest differences between these two namespaces. So the component connection which also forces this stanza attribute to be present matches better the jabber:server namespace. Minor reasons: - I'd say that component connections are more like a s2s connection, as you do not manage sessions from them in the server. pre-2.0 versions of jabberd2 even did not have a dedicated s2s component but did s2s directly in the router (where also components connect to). - Both with s2s and components you typically route one or more domains completely to the same desination. With c2s you only route single users out of a domain. Matthias
Re: [Standards] NEW: XEP-0225 (Component Connections)
XMPP Extensions Editor wrote: Version 0.1 of XEP-0225 (Component Connections) has been released. Abstract: This document specifies a standards-track XMPP protocol extension that enables server components to connect to XMPP servers. One of the items up for discussion is the default namespace for component connections. At the XMPP DevCon we thought that it would be good to use 'jabber:client', but I know that both Matthias Wimmer and Ralph Meijer have some arguments for 'jabber:server'. So perhaps we could have a debate about that. :) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0225 (Component Connections)
On Aug 8, 2007, at 1:44 PM, Peter Saint-Andre wrote: XMPP Extensions Editor wrote: Version 0.1 of XEP-0225 (Component Connections) has been released. Abstract: This document specifies a standards-track XMPP protocol extension that enables server components to connect to XMPP servers. One of the items up for discussion is the default namespace for component connections. At the XMPP DevCon we thought that it would be good to use 'jabber:client', but I know that both Matthias Wimmer and Ralph Meijer have some arguments for 'jabber:server'. So perhaps we could have a debate about that. :) It does not quite seem to fit into either. I know it would be a real pain, but maybe this deserves its own namespace? jabber:internal, perhaps? Or jabber:service? -- Rachel Blackman [EMAIL PROTECTED] Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] NEW: XEP-0225 (Component Connections)
Rachel Blackman wrote: On Aug 8, 2007, at 1:44 PM, Peter Saint-Andre wrote: XMPP Extensions Editor wrote: Version 0.1 of XEP-0225 (Component Connections) has been released. Abstract: This document specifies a standards-track XMPP protocol extension that enables server components to connect to XMPP servers. One of the items up for discussion is the default namespace for component connections. At the XMPP DevCon we thought that it would be good to use 'jabber:client', but I know that both Matthias Wimmer and Ralph Meijer have some arguments for 'jabber:server'. So perhaps we could have a debate about that. :) It does not quite seem to fit into either. I know it would be a real pain, but maybe this deserves its own namespace? jabber:internal, perhaps? Or jabber:service? People seem to want to re-use an existing namespace. I tend to agree with you, urn:xmpp:component seems like a good idea so that we don't overload one of the existing namespaces. I'm especially concerned about how the server would know whether to offer hostname binding and properly authenticate the component if we re-use an existing default namespace. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0225 (Component Connections)
On Wednesday 08 August 2007 1:44 pm, Peter Saint-Andre wrote:
XMPP Extensions Editor wrote:
Version 0.1 of XEP-0225 (Component Connections) has been released.
Abstract: This document specifies a standards-track XMPP protocol
extension that enables server components to connect to XMPP servers.
One of the items up for discussion is the default namespace for
component connections. At the XMPP DevCon we thought that it would be
good to use 'jabber:client', but I know that both Matthias Wimmer and
Ralph Meijer have some arguments for 'jabber:server'. So perhaps we
could have a debate about that. :)
For namespace-aware implementations, these multiple namespaces are a real
pain. body xmlns='jabber:client' and body xmlns='jabber:server' have
identical meaning: a body of a message. Yet, namespace-aware implementations
will consider these to be two distinct elements. This affects the creating
and parsing of all RFC 3920 and 3921 XML data. You need to write code that
understands both namespaces and can output under either namespace (depending
on whether a stanza is going out on c2s or s2s).
In jabberd2, I believe all XML is internally handled in the jabber:client
namespace. I did the same thing in Ambrosia. When a stanza arrives over
s2s, I iterate over the DOM and change all namespace instances
of 'jabber:server' to 'jabber:client' (note here that I'm not talking about
xmlns attributes, but rather the namespace property of each DOM element).
This allows me to reuse all of my existing stanza parsing and generation code
based on a single namespace ('jabber:client').
Additionally, I think indicating support for a feature or connection type
simply through a namespace declaration is weird. A namespace declaration
indicates what namespace child elements should be assigned to, when you
actually have child elements. By itself it doesn't have much meaning.
Namespace declarations don't show up in DOM either (they do show up in SAX
though, which is how I handle them). I personally think it was a mistake to
use namespace declarations to indicate c2s vs s2s, or to indicate dialback
support, and so I vote not repeating this mistake. This means
no 'jabber:component' or such. The choice should be between 'jabber:client'
and 'jabber:server' for the namespace. Use a real attribute or element to
indicate component support.
-Justin
