Re: [Standards] Jingle: UDP relays
adding my 2 cents for the comets from scott + It may be nice to upgrade XEP-0215 to discover network servers ( almost same functionality as of DNS SRV ) instead of just stun servers only ( as we discussed early in this list ) so it can look up properly turn servers and ports in some environments . thanx unni On 8/10/07, Scott Ludwig <[EMAIL PROTECTED]> wrote: > > On Aug 9, 2007 11:01 AM, Thiago Camargo <[EMAIL PROTECTED]> wrote: > > UDP Relays are just simple UDP routers. > > So you can bind Ports and IPs to the clients from your XMPP servers. > > Clients don't need to negotiate directly with Relay Servers(TURN for > instance). > > XMPP Servers can negotiate and allocate the tunnel to be used by the > client. > > > > Check these drafts: > > > > http://www.gliffy.com/publish/1178640/ > > http://www.gliffy.com/publish/1130091/ > > > > Regards, > > Thiago > > I suggest we just use STUN and TURN and get on with this. > > It's true that a special case client can have a special relationship > with a server, and allocate candidates any way it wants, and establish > a standard jingle p2p connection as long as those candidates work as > regular remote candidate for the peer during ICE connectivity > establishment. > > However, it would be nice for any Jingle compatible client to know how > to allocate address candidates from the service it is connected to. To > do this there needs to be standard protocols for discovering and using > these services. It's not complicated. > > Describing N ways to allocate candidates isn't useful for anyone. > There is nothing very special about STUN and TURN technically, except > that they are established and work. Let's use them and move on. >
Re: [Standards] Jingle: UDP relays
On Aug 9, 2007 11:01 AM, Thiago Camargo <[EMAIL PROTECTED]> wrote: > UDP Relays are just simple UDP routers. > So you can bind Ports and IPs to the clients from your XMPP servers. > Clients don't need to negotiate directly with Relay Servers(TURN for > instance). > XMPP Servers can negotiate and allocate the tunnel to be used by the client. > > Check these drafts: > > http://www.gliffy.com/publish/1178640/ > http://www.gliffy.com/publish/1130091/ > > Regards, > Thiago I suggest we just use STUN and TURN and get on with this. It's true that a special case client can have a special relationship with a server, and allocate candidates any way it wants, and establish a standard jingle p2p connection as long as those candidates work as regular remote candidate for the peer during ICE connectivity establishment. However, it would be nice for any Jingle compatible client to know how to allocate address candidates from the service it is connected to. To do this there needs to be standard protocols for discovering and using these services. It's not complicated. Describing N ways to allocate candidates isn't useful for anyone. There is nothing very special about STUN and TURN technically, except that they are established and work. Let's use them and move on.
Re: [Standards] NEW: XEP-0224 (Attention)
On Sat, Aug 11, 2007 at 02:06:19AM +0200, Andreas Monitzer wrote: > On Aug 11, 2007, at 01:57, Sergei Golovan wrote: > > >On 8/11/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote: > >>Hmm would that be so bad? A headline window will surely draw more > >>attention than a regular message. > > > >How this separate window would associate with a chat thread? > >Especially if chat and headline messages are stored in different > >histories. > > The message of the headline is not part of the discussion, and so > shouldn't be stored along the rest. There is no association. My suggestion is that you send a message of type chat to the full JID of the person you've been chatting with to get their attention. If we do that, your worries about headline messages are moot. > >IQ has a fixed clear structure. Its parsing usually performed by one > >routine, > > I don't know many XMPP implementations, but in libpurple, > is handled by a single function, whereas -handling is spread > around the whole XMPP plugin (since nearly every feature uses an iq > stanza at some point). It sounds as if the handling of IQ vs. message stanzas is different in different implementations, so I don't think we can take that as an argument one way or the other. It seems to me that these attention requests will be sent in the context of an existing chat. In that case, sending a chat message to the full JID would make sense: This is pretty much equivalent to IQ except that no ack is needed or expected. Which seems reasonable to me in this context. You're just saying "hey!" > >But it's not a big deal to process a message instead of IQ. What I > >want from any protocol detail is a feedback. XMPP would be much nicer > >if any stanza required an acknowledgement. Feel free to implement XEP-0198. Or just use SIP, they ack everything! > For now, messages and > >presences are thrown without an acknowledgement (except for an ugly > >presence usage in XEP-0045 AFAIK). So, I'd like to use them as seldom > >as possible. Only if using message is unavoidable it may be used. (If > >I could, I'd use IQ even for a regular messaging.) > > This sounds more like you have a general issue with the XMPP protocol > as such. This is outside the scope of my XEP, please discuss this on > this list on the topic of rfc3921bis. > > andy What Andy said. Peter
Re: [Standards] Jingle: UDP relays
Peter Saint-Andre wrote:
> At the recent XMPP devcon, I talked a bit with Thiago Camargo about NAT
> traversal and media relays. There are really two separate issues here:
>
> 1. Finding and using STUN servers for NAT traversal. This is discussed
> in XEP-0215.
>
> 2. Finding and using relay servers for media transport. Thiago suggests
> that a Jingle client could query its XMPP server for a UDP IP and port
> ("hostport") at a relay server and the XMPP server could reserve that
> hostport for use by the client. The hostport might exist at a TURN [1]
> server. However, as Rémi Denis-Courmont has pointed out [2] on the
> IETF's BEHAVE list, it is not necessary for the relay to be a TURN
> server. It's great if the relay is a TURN server, but it could be
> something else -- and the important point is that for the purposes of
> media relaying it doesn't really matter to the Jingle client whether the
> relay does TURN or something simpler. So Thiago convinced me that if we
> define a way for a Jingle client to ask its XMPP server for a UDP
> hostport at a relay, we would have an easy way for a client to do media
> relaying.
>
> At this point I think we could (a) modify XEP-0215 to include the
> hostport reservation functionality or (b) define a separate spec. I
> don't have a strong preference about this right now, but Thiago and I
> will look into the options sometime soon.
Thiago, I am looking at your proposed workflow:
http://www.gliffy.com/publish/1178640/
And I have a question: how can the Jingle client (connected to the XMPP
server via TCP) ask the XMPP server for a public address candiate? As
far as I can see, that won't work because the XMPP server doesn't know
anything about UDP and so can't tell the Jingle client what its public
UDP IP+port is.
However, asking a specially-configured XMPP server for a media relay
candidate might work because the XMPP server could communicate with the
media relay (TURN or something simpler) on behalf of the Jingle client.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0224 (Attention)
On Aug 11, 2007, at 01:57, Sergei Golovan wrote: On 8/11/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote: Hmm would that be so bad? A headline window will surely draw more attention than a regular message. How this separate window would associate with a chat thread? Especially if chat and headline messages are stored in different histories. The message of the headline is not part of the discussion, and so shouldn't be stored along the rest. There is no association. IQ has a fixed clear structure. Its parsing usually performed by one routine, I don't know many XMPP implementations, but in libpurple, is handled by a single function, whereas -handling is spread around the whole XMPP plugin (since nearly every feature uses an iq stanza at some point). But it's not a big deal to process a message instead of IQ. What I want from any protocol detail is a feedback. XMPP would be much nicer if any stanza required an acknowledgement. For now, messages and presences are thrown without an acknowledgement (except for an ugly presence usage in XEP-0045 AFAIK). So, I'd like to use them as seldom as possible. Only if using message is unavoidable it may be used. (If I could, I'd use IQ even for a regular messaging.) This sounds more like you have a general issue with the XMPP protocol as such. This is outside the scope of my XEP, please discuss this on this list on the topic of rfc3921bis. andy
Re: [Standards] NEW: XEP-0224 (Attention)
On 8/11/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote: > > include into this message, Tkabber will show it in a separate > > headlines window. > > Hmm would that be so bad? A headline window will surely draw more > attention than a regular message. How this separate window would associate with a chat thread? Especially if chat and headline messages are stored in different histories. > > > IQ is simple. Message is complicated. > > uh, why? There's much more code involved in an IQ stanza than in a > message. IQ has a fixed clear structure. Its parsing usually performed by one routine, and to add support for some IQ namespace one can do something like the following (example from Tkabber): iq::register_handler set query http://www.xmpp.org/extensions/xep-0224.html#ns ::plugins::attention::react Message is a much more complicated object. But it's not a big deal to process a message instead of IQ. What I want from any protocol detail is a feedback. XMPP would be much nicer if any stanza required an acknowledgement. For now, messages and presences are thrown without an acknowledgement (except for an ugly presence usage in XEP-0045 AFAIK). So, I'd like to use them as seldom as possible. Only if using message is unavoidable it may be used. (If I could, I'd use IQ even for a regular messaging.) Though, if XMPP is for information which worth nothing then everyone may use anything he wants. Cheers! -- Sergei Golovan
Re: [Standards] NEW: XEP-0224 (Attention)
On Aug 11, 2007, at 00:40, Sergei Golovan wrote: On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: If your client shows a message even though it doesn't understand the only child element in that message, then you should file a bug with the developers, because that violates RFC 3920. I know. And this bug will be fixed. Though I still think that headline messages aren't acceptable for drawing attention. If someone will include into this message, Tkabber will show it in a separate headlines window. Hmm would that be so bad? A headline window will surely draw more attention than a regular message. IQ is simple. Message is complicated. uh, why? There's much more code involved in an IQ stanza than in a message. andy
Re: [Standards] NEW: XEP-0224 (Attention)
On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > If your client shows a message even though it doesn't understand the > only child element in that message, then you should file a bug with the > developers, because that violates RFC 3920. I know. And this bug will be fixed. Though I still think that headline messages aren't acceptable for drawing attention. If someone will include into this message, Tkabber will show it in a separate headlines window. Or you want to add something like "client SHOULD ignore all information included into attention message"? IQ is simple. Message is complicated. Cheers! -- Sergei Golovan
Re: [Standards] NEW: XEP-0224 (Attention)
Andreas Monitzer wrote: > Specs shouldn't be designed around bugs of existing implementations... +1! smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0224 (Attention)
Sergei Golovan wrote: > On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> If it's a chat message then it won't be a strange headline message. If >> the message is empty except for the attention request then a client must >> ignore the message if it doesn't understand the attention namespace, so >> that won't result in strange empty messages. And several people on the >> list don't think that the attention request is something that we need to >> ack. But if others think this needs to be an IQ then I'm open to argument. > > I know at least one client which will show an empty headline message > (it's Tkabber, it can't imagine such strange headlines). Can someone > bet that it's the only one? If your client shows a message even though it doesn't understand the only child element in that message, then you should file a bug with the developers, because that violates RFC 3920. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0224 (Attention)
On Aug 11, 2007, at 00:13, Sergei Golovan wrote: I know at least one client which will show an empty headline message (it's Tkabber, it can't imagine such strange headlines). Can someone bet that it's the only one? libpurple also had this bug, but I fixed it this summer. Maybe someone can file a bug on Tkabber? Specs shouldn't be designed around bugs of existing implementations... andy
[Standards] whiteboarding and shared editing
In its meeting on Wednesday, the XMPP Council declined [1] to accept the most recent SVG whiteboarding proposal [2] as a XEP. However, the Council appreciates the efforts of those who have worked on the technology underlying that specification, which may provide helpful experiential input to standards-track work in this domain. The sense of the Council is that it would be more productive in the long term to define a generic technology for shared XML editing, similar to a previous proposal [3]. Such a technology could be used for whiteboarding with SVG as in a previous proposal [4], but also for shared editing of other XML formats such as XHTML, Open Document Format (ODF), and Atom. Limiting the approach to SVG whiteboarding alone will not provide for re-use of the technology for other applications. One approach previously explored would be to use the W3C's Remote Events in XML (REX) technology. [5] Unfortunately, REX has some limitations that would limit its usefulness for shared XML editing over XMPP, and in any case is patent-encumbered [6] so could not be used in an XSF specification. The Council will take it as an action item to investigate shared XML editing technologies in greater depth. There are challenging issues of synchronization involved (which would have been partially addressed by REX), as well as proper layering of the solution so that we can build multiple applications on top of the editing technology. At its next meeting the Council will discuss approaches for solving these problems, which may involve assigning a team or individual to work on solutions (as we have done in the past, e.g. when Peter Millard was tasked with working on Publish-Subscribe). As always, feedback is welcome. /psa [1] http://www.jabber.org/muc-logs/[EMAIL PROTECTED]/2007-08-08.html#12:53:57 [2] http://www.xmpp.org/extensions/inbox/whiteboard2.html [3] http://www.xmpp.org/extensions/inbox/sxde.html [4] http://www.xmpp.org/extensions/inbox/whiteboard.html [5] http://www.w3.org/TR/rex/ [6] http://www.w3.org/News/2007#item170 smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0224 (Attention)
On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > If it's a chat message then it won't be a strange headline message. If > the message is empty except for the attention request then a client must > ignore the message if it doesn't understand the attention namespace, so > that won't result in strange empty messages. And several people on the > list don't think that the attention request is something that we need to > ack. But if others think this needs to be an IQ then I'm open to argument. I know at least one client which will show an empty headline message (it's Tkabber, it can't imagine such strange headlines). Can someone bet that it's the only one? -- Sergei Golovan
Re: [Standards] NEW: XEP-0224 (Attention)
Sergei Golovan wrote: > On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> IMHO you should send a chat message to the full JID of the person you're >> chatting with. One message, delivered to one resource, not acked. A >> simple throw-away that says "hey!" > > Well, I feel tired little bit of this discussion. Great, we tired you out! ;-) > You may do with this XEP what you want :) It's not what I want, it's what makes the most sense -- or at least what reflects the consensus of the list. ;-) > But I still think that working with IQ in XMPP is easier than with > messages. And if a client doesn't support "attention poking via IQ" > then it's OK. But if a client doesn't support "attention poking via > message" then it will result in strange empty messages, or strange > headline messages or whatever. If it's a chat message then it won't be a strange headline message. If the message is empty except for the attention request then a client must ignore the message if it doesn't understand the attention namespace, so that won't result in strange empty messages. And several people on the list don't think that the attention request is something that we need to ack. But if others think this needs to be an IQ then I'm open to argument. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0224 (Attention)
On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > IMHO you should send a chat message to the full JID of the person you're > chatting with. One message, delivered to one resource, not acked. A > simple throw-away that says "hey!" Well, I feel tired little bit of this discussion. You may do with this XEP what you want :) But I still think that working with IQ in XMPP is easier than with messages. And if a client doesn't support "attention poking via IQ" then it's OK. But if a client doesn't support "attention poking via message" then it will result in strange empty messages, or strange headline messages or whatever. Cheers! -- Sergei Golovan
Re: [Standards] NEW: XEP-0224 (Attention)
Sergei Golovan wrote: > On 8/11/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote: >> I think he's talking about the network transfer waste, not the coding >> waste. Since all clients need some kind of handling sending iqs and >> receiving them, this is not really a concern. > > 'message type=headline' looks more wasteful than 'iq type=set' :) IMHO you should send a chat message to the full JID of the person you're chatting with. One message, delivered to one resource, not acked. A simple throw-away that says "hey!" smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0224 (Attention)
On 8/11/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote: > I think he's talking about the network transfer waste, not the coding > waste. Since all clients need some kind of handling sending iqs and > receiving them, this is not really a concern. 'message type=headline' looks more wasteful than 'iq type=set' :) -- Sergei Golovan
Re: [Standards] NEW: XEP-0224 (Attention)
Andreas Monitzer wrote: > On Aug 10, 2007, at 23:05, Sergei Golovan wrote: > >> On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >>> Sergei Golovan wrote: >>> OK then: >>> >>> But the recipient's client must send a reply if we use IQ, which seems >>> wasteful for a little toy like this. >> >> Well, the first working draft of this toy (IQ-based, with a mandatory >> reply) consists of 67 lines of code. Is it too wasteful? > > I think he's talking about the network transfer waste, not the coding > waste. Since all clients need some kind of handling sending iqs and > receiving them, this is not really a concern. Right. As I said in the jdev room (and I quote): [13:14:06] OMG you want a reliable transport for your stupid buzz messages?!?! smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] MUC message moderation
Mridul Muralidharan wrote: > > Hi Peter, > > Please note that the submitted specs are based on what have been > shipping for 2+ years now - so it is possible that subsequent xep's have > come out with different or better idioms - we can definitely change for > the better if it is consistent with the rest of the specs. OK, thanks for explaining the context. > Peter Saint-Andre wrote: >> As promised, here are some questions and comments on the proposed MUC >> message moderation specs: >> >> http://www.xmpp.org/extensions/inbox/msg_moderate.html >> >> http://www.xmpp.org/extensions/inbox/room_moderator.html >> >> >> 1. I think it makes sense to combine the two specs into one, with >> separate sections for the occupant and moderator use cases. >> > > > The msg_moderate spec talks about occupant to room interaction - which > is expected to be fairly stable across various moderation schemes. > > room_moderator spec talks about one realization (profile ?) of message > moderation where room moderators actively take up the role of message > moderator - and component decides on this based on the role & affiliation. > > While keeping the interaction between occupant and room stable, we could > have other backend moderation interactions satisfying various other > requirements - the occupant is agnostic to the actual moderation scheme. > > Hence the split - since both are logically different functions. I understand that moderation could occur in different ways (e.g., via a web interface). But I think it would be simpler for developers if everything is in one spec. >> 2. What is the rationale for sending out state changes via presence from >> the room's JID? >> >> http://www.xmpp.org/extensions/inbox/msg_moderate.html#moderation-state >> >> How will existing clients handle such state notifications? >> > > > The intention is for any occupant who does not understand the xep's to > continue to function without any error - but with reduced functionality > since they cant request for moderation. > I was not aware of these presence stanza's causing any problems - but we > could very well change that to message or iq if they satisfy the same > requirements. I think it is worth thinking about this. Currently clients would not know what to do with presence from the room. I know we've talked about that idea and I still think it's worth pursuing, but we're really changing the state of the room here. Let's say that people can subscribe to the room from outside -- would they get these presence updates? That would be odd -- they are intended only for people in the room. So I think an in-room message or in-room IQ would make more sense. Probably a message would be enough (I don't see a good reason to ack the status update). See also: http://www.xmpp.org/extensions/xep-0045.html#roomconfig-notify > Another alternative could be to discover if the client supports these > xep's (disco ?) and the usecases and stanza's described in msg_moderate > are applicable only to those. How so? In any case I think an in-room message would make the most sense. >> I think we need to come up with a generic approach here. Perhaps the >> authors of the message moderation proposal could collaborate with the >> authors of the MUCOL proposal (not yet submitted)? They use IQs, not >> presence. >> >> http://www.wimba.com/labs/mucol/ >> > > mucol defines a way to using particular media like whiteboarding. In > case of message moderation it is not a collaboration between > participants of the room. The communication is between the > user/moderator and room so probably we cannot co-relate them. I meant a generic approach to sending out notification of changes in the room state. Again see the in-room messages we send already: http://www.xmpp.org/extensions/xep-0045.html#roomconfig-notify >> 3. Why is the message sender forced to flag the message as intended for >> moderation? >> >> http://www.xmpp.org/extensions/inbox/msg_moderate.html#moderation-state >> >> It seems to me that this forces the client to be smart about the state >> of the room. Older clients may not be that smart, and in any case I >> think the room (MUC service) can intelligently decide how to handle > > > The affiliation/role of an occupant which can make use msg_moderate spec > is of one who does not have voice. > So, existing clients will not be able to send messages to the room > currently, and they will not be expecting this ability (like no text > area in client, etc). > > This proposal enables these users to participate in the discussion - > pending approval from moderator. > The intention here is to be explicit about exhibiting the fact that > occupants are requesting for a moderated message submission - and due to > the nature of submission, there are additional workflow and client side > UI aspects which make use of this information. But can't the room be smart about that? In my experience, lots of clients may ignore the fact that the user does not have voice
Re: [Standards] NEW: XEP-0224 (Attention)
On Aug 10, 2007, at 23:05, Sergei Golovan wrote: On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: Sergei Golovan wrote: OK then: But the recipient's client must send a reply if we use IQ, which seems wasteful for a little toy like this. Well, the first working draft of this toy (IQ-based, with a mandatory reply) consists of 67 lines of code. Is it too wasteful? I think he's talking about the network transfer waste, not the coding waste. Since all clients need some kind of handling sending iqs and receiving them, this is not really a concern. andy
Re: [Standards] NEW: XEP-0224 (Attention)
On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Sergei Golovan wrote: > OK then: > > But the recipient's client must send a reply if we use IQ, which seems > wasteful for a little toy like this. Well, the first working draft of this toy (IQ-based, with a mandatory reply) consists of 67 lines of code. Is it too wasteful? -- Sergei Golovan
Re: [Standards] NEW: XEP-0224 (Attention)
Sergei Golovan wrote: > On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> But the recipient must send a reply if we use IQ, which seems wasteful >> for a little toy like this. > > Not a recipient, but her client. As for Tkabber it will waste about > 3-5 lines of code. OK then: But the recipient's client must send a reply if we use IQ, which seems wasteful for a little toy like this. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0224 (Attention)
On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > > But the recipient must send a reply if we use IQ, which seems wasteful > for a little toy like this. Not a recipient, but her client. As for Tkabber it will waste about 3-5 lines of code. -- Sergei Golovan
Re: [Standards] NEW: XEP-0224 (Attention)
Sergei Golovan wrote: > On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> Peter Saint-Andre wrote: >> The more I think about it, the more it seems to me that this kind of >> feature is a "throwaway" -- do you really need to receive a reply? You >> just want to poke the other person. There's no need for a reliable >> transport with fancy error messages and all that. > > I think that if we can make less uncertainty an no cost (almost no > cost) we should always do that. If a client author doesn't want to > process replies it's up to him to ignore them. But the recipient must send a reply if we use IQ, which seems wasteful for a little toy like this. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0224 (Attention)
On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Peter Saint-Andre wrote: > The more I think about it, the more it seems to me that this kind of > feature is a "throwaway" -- do you really need to receive a reply? You > just want to poke the other person. There's no need for a reliable > transport with fancy error messages and all that. I think that if we can make less uncertainty an no cost (almost no cost) we should always do that. If a client author doesn't want to process replies it's up to him to ignore them. Cheers! -- Sergei Golovan
Re: [Standards] NEW: XEP-0224 (Attention)
Peter Saint-Andre wrote: > Andreas Monitzer wrote: >> On Aug 10, 2007, at 15:30, Sergei Golovan wrote: >> >>> I just want to get a result of attention query. >> Hmmm well, I personally wouldn't care about it (since you can't know if >> the user noticed it anyways), but I'm rather indifferent on it. What's >> the opinion of others on this list about it? > > IQ seems good to me. > > There are all sorts of potentially complicating factors involved here > (multiple resources) but I think they are relatively minor. Much depends > on the use case. Your examples showed one user sending the attention > request in the context of an existing chat session. In that context you > know the other person's resource and you are sending to that one because > you want to other person to pay attention to the chat session. If you > want to shake/buzz/etc. all of the user's resources then a message > headline would be better. We discussed it a bit more in the jdev room: http://www.jabber.org/muc-logs/[EMAIL PROTECTED]/2007-08-10.html#13:06:39 The more I think about it, the more it seems to me that this kind of feature is a "throwaway" -- do you really need to receive a reply? You just want to poke the other person. There's no need for a reliable transport with fancy error messages and all that. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] MUC rooms on roster.
Joe Hildebrand wrote: > > On Aug 10, 2007, at 11:52 AM, Peter Saint-Andre wrote: > >> Joe Hildebrand wrote: >>> 1) A new MUC role which effectively the opposite of visitor. Of course, >>> on the bar napkin, this got written as "rotisiv". :) A rotisiv can >>> potentially speak (broadcasting to all of the members of the room), but >>> can't see any of the messages that are broadcast to the room. As well, >>> rotisivs get presence from all of the participants and moderators of the >>> room, but nobody receives the rotisiv's presence from the room. >>> Obviously, an implementation might want ACLs to specify who can be a >>> rotisiv for a given room. >> >> I'm not sure why you wouldn't want visitors to receive messages, perhaps >> I'm missing something. I can understand why the room admins would not >> want to broadcast presence from visitors in a moderated room, but that's >> why we have the muc#roomconfig_presencebroadcast option. > > The use case is: > > - I'm not in the marketing group, but I'm rotisiv'ing it to see when any > of them arrive at the office > - I broadcast a message to the marketing group, asking for the new slide > deck template, so that whoever is available can help me > - You rotisiv the marketing group, you shouldn't see my presence through > the group, since I'm not a member > - You broadcast a message to the marketing group; I shouldn't see it, > because it's none of my business Oh, so this is for communities? I need to finish writing up our devcon discussions on that topic. Will try to do that in the next few days. But gosh "rotisiv" is such an ugly word. How about "ghost"? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
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 omnipresent, and existing potentially in all namespaces? :) Well, I take 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] MUC rooms on roster.
On Aug 10, 2007, at 11:52 AM, Peter Saint-Andre wrote: Joe Hildebrand wrote: 1) A new MUC role which effectively the opposite of visitor. Of course, on the bar napkin, this got written as "rotisiv". :) A rotisiv can potentially speak (broadcasting to all of the members of the room), but can't see any of the messages that are broadcast to the room. As well, rotisivs get presence from all of the participants and moderators of the room, but nobody receives the rotisiv's presence from the room. Obviously, an implementation might want ACLs to specify who can be a rotisiv for a given room. I'm not sure why you wouldn't want visitors to receive messages, perhaps I'm missing something. I can understand why the room admins would not want to broadcast presence from visitors in a moderated room, but that's why we have the muc#roomconfig_presencebroadcast option. The use case is: - I'm not in the marketing group, but I'm rotisiv'ing it to see when any of them arrive at the office - I broadcast a message to the marketing group, asking for the new slide deck template, so that whoever is available can help me - You rotisiv the marketing group, you shouldn't see my presence through the group, since I'm not a member - You broadcast a message to the marketing group; I shouldn't see it, because it's none of my business
Re: [Standards] NEW: XEP-0225 (Component Connections)
On Friday 10 August 2007 12:20 am, Ralph Meijer wrote: > 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. Good approach, and it makes sense given how XMPP works. Unfortunately, it requires a special data structure as opposed to a standard DOM, which does not have the notion of an inherited/default namespace (yes, I keep bringing up DOM... but standard XML tools are good.). It just occurred to me though, that maybe I could add my own namespaced attribute onto the elements indicating the default namespace, which would be stripped at the time of transmission. Yay for DOM hacks. :) > 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. This I'd argue with. Take my example again about . This element is defined to be in the jabber:client or jabber:server namespace. What is its meaning in an undefined or None namespace, according to your implementation? Presumably it gains either 'jabber:client' or 'jabber:server' meaning when it becomes time to process it. It must belong to one of those namespaces (or somehow both) at the time of processing, because otherwise the element would be meaningless. If you have stanza code that processes , but does not care about the namespace of the body element, then that to me is a little bit goofy. > 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 omnipresent, and existing potentially in all namespaces? :) -Justin
Re: [Standards] MUC rooms on roster.
Joe Hildebrand wrote: > On Aug 3, 2007, at 3:10 AM, Robin Redeker wrote: >> Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ? >> That would still be useful to store non-autmatically-joined MUCs I guess? >> Also that XEP offers also a way to auto-join MUCs. > > The more we talked about this around the office, the more we thought we > only needed two things to make this work for our use cases. > > 1) A new MUC role which effectively the opposite of visitor. Of course, > on the bar napkin, this got written as "rotisiv". :) A rotisiv can > potentially speak (broadcasting to all of the members of the room), but > can't see any of the messages that are broadcast to the room. As well, > rotisivs get presence from all of the participants and moderators of the > room, but nobody receives the rotisiv's presence from the room. > Obviously, an implementation might want ACLs to specify who can be a > rotisiv for a given room. I'm not sure why you wouldn't want visitors to receive messages, perhaps I'm missing something. I can understand why the room admins would not want to broadcast presence from visitors in a moderated room, but that's why we have the muc#roomconfig_presencebroadcast option. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0224 (Attention)
Andreas Monitzer wrote: > On Aug 10, 2007, at 15:30, Sergei Golovan wrote: > >> I just want to get a result of attention query. > > Hmmm well, I personally wouldn't care about it (since you can't know if > the user noticed it anyways), but I'm rather indifferent on it. What's > the opinion of others on this list about it? IQ seems good to me. There are all sorts of potentially complicating factors involved here (multiple resources) but I think they are relatively minor. Much depends on the use case. Your examples showed one user sending the attention request in the context of an existing chat session. In that context you know the other person's resource and you are sending to that one because you want to other person to pay attention to the chat session. If you want to shake/buzz/etc. all of the user's resources then a message headline would be better. And of course the XEP is just defining a payload format. A client could send it either by message or by IQ. If you want to buzz one resource, use IQ. If you want to buzz all resources, use message headline. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0224 (Attention)
Tomasz Sterna wrote: > Dnia 10-08-2007, pią o godzinie 16:11 +0100, Richard Dobson napisał(a): >> In that case you would just ignore the attempted shake for people who >> you dont want to be able to do it (and probably return an error of >> some sort), but you can still publish that you allow it in your caps >> if you allow it for some people in your roster, > > Maybe we should think of extending Caps to allow publishing different > capabilities to different contacts. Over complicated. We made some tradeoffs with caps (and indeed with presence itself) by using a broadcast model. If you don't want to advertise a feature to everyone in your roster, don't include it in the hash. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
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] Username Escaping with Gateway Registration
Ian Paterson wrote: > Peter Saint-Andre wrote: >> http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0100.xml?%40diffMode=u&%40diffWrap=s&r1=1092&r2=1134&u=3&ignore=&k= >> >> >> TinyURL: http://tinyurl.com/2dxv5j >> > > That looks good, thanks :-) Super, I've added that to the agenda for the next Council meeting: http://www.xmpp.org/council/agendas/2007-08-22.html Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] NEW: XEP-0224 (Attention)
Maybe we should think of extending Caps to allow publishing different capabilities to different contacts. Yea maybe, but we need to find a reason for it first, certainly in this case its not needed as in normal real world use people are just going to have it globally on or off, they arnt going to be bothered with enabling and disabling this tiny little feature for individual contacts, are there any other more actually credible use cases for it that we can think of? Richard
Re: [Standards] NEW: XEP-0224 (Attention)
Dnia 10-08-2007, pią o godzinie 16:11 +0100, Richard Dobson napisał(a): > In that case you would just ignore the attempted shake for people who > you dont want to be able to do it (and probably return an error of > some sort), but you can still publish that you allow it in your caps > if you allow it for some people in your roster, Maybe we should think of extending Caps to allow publishing different capabilities to different contacts. -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] NEW: XEP-0224 (Attention)
Unfortunately, no. I wouldn't like everyone in my roster to be able to shake my client window. Instead I would like to implement a sort of white list for this. And it's hard to represent in XEP-0115 hash that somone is allowed to ask an attention query and others aren't. In that case you would just ignore the attempted shake for people who you dont want to be able to do it (and probably return an error of some sort), but you can still publish that you allow it in your caps if you allow it for some people in your roster, I think your "whitelist" implementation is going to be pretty much in a minority and people are likely to just implement it how it works in MSN messenger and the like with a global on and off, normal users (Aunt Tilly) arnt going to be bothered with individually whitelisting specific users to allow it... Things dont need to be made overcomplicated. IQ is perfectly compatible with unsupported clients. They definitely reply with an error (if the client isn't an outdated Psi, which was known to swallow unsupported IQ stanzas). I would defianately vote to use IQ rather than message too. Also regards to the memory leak issue mentioned im not sure what thats all about, we shouldnt be hampering the design of optimum protocol just because of the possiblity that someone might have bugs in their software... Richard
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. and 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-0224 (Attention)
On 8/10/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote: > On Aug 10, 2007, at 15:30, Sergei Golovan wrote: > > > And I don't like to make many disco#info queries to determine > > current state of the remote client. > > That's what XEP-0115 is about, this is outside the scope of XEP-0224. Unfortunately, no. I wouldn't like everyone in my roster to be able to shake my client window. Instead I would like to implement a sort of white list for this. And it's hard to represent in XEP-0115 hash that somone is allowed to ask an attention query and others aren't. > Further, you can just send it to non-supporting clients, too. The XEP IQ is perfectly compatible with unsupported clients. They definitely reply with an error (if the client isn't an outdated Psi, which was known to swallow unsupported IQ stanzas). > just says that you have to check for support, not that you must not > send one to a non-supporting client (wouldn't do anything, though). I > guess the disco#info check should be changed to a SHOULD instead of a > MUST (I already changed that in my local version here). I think that without a feedback this XEP is only a toy, not more. (But since Jabber is good only as a toy anyway then it shouldn't matter much :) Cheers! -- Sergei Golovan
Re: [Standards] NEW: XEP-0224 (Attention)
On Aug 10, 2007, at 15:30, Sergei Golovan wrote: I just want to get a result of attention query. Hmmm well, I personally wouldn't care about it (since you can't know if the user noticed it anyways), but I'm rather indifferent on it. What's the opinion of others on this list about it? And I don't like to make many disco#info queries to determine current state of the remote client. That's what XEP-0115 is about, this is outside the scope of XEP-0224. Further, you can just send it to non-supporting clients, too. The XEP just says that you have to check for support, not that you must not send one to a non-supporting client (wouldn't do anything, though). I guess the disco#info check should be changed to a SHOULD instead of a MUST (I already changed that in my local version here). andy
Re: [Standards] NEW: XEP-0224 (Attention)
On 8/10/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote: > On Aug 10, 2007, at 15:12, Sergei Golovan wrote: > > > You're already use to determine XEP support. So, I think that > > anyway the message should be sent to a full JID. > > > > As for potential memory leak I would say that it's better to leave > > this problem to a client developer. There are always clients, which > > behave incorrectly. Do you want to completely avoid using s? > > No, but I want a specific reason to use an iq instead of a message. I just want to get a result of attention query. And I don't like to make many disco#info queries to determine current state of the remote client. -- Sergei Golovan
Re: [Standards] NEW: XEP-0224 (Attention)
On Aug 10, 2007, at 15:12, Sergei Golovan wrote: You're already use to determine XEP support. So, I think that anyway the message should be sent to a full JID. As for potential memory leak I would say that it's better to leave this problem to a client developer. There are always clients, which behave incorrectly. Do you want to completely avoid using s? No, but I want a specific reason to use an iq instead of a message. andy
Re: [Standards] NEW: XEP-0224 (Attention)
On 8/10/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote: > On Aug 09, 2007, at 21:55, Sergei Golovan wrote: > > >> I think that attention messages should not be sent with a , > >> but > >> should be a standalone message of type='headline', like so: > >> > >> >> to='[EMAIL PROTECTED]/home' > >> type='headline'> > >> > >> > > > > This message looks like but is better because the > > recipient may receive result in case of accepted attention or error in > > case of ignored one. The ability of getting a response even makes > > disco#info queries unnecessary. > > I chose to use instead of because you don't have to > specify a resource to send the message, and you don't need a reply on > this one (every -message is a potential memory leak, when the > receiving client doesn't behave properly), because even when the > client displays the attention grabbing event, you can't know if the > user has seen/heard it. Is there a serious reason to go to ? You're already use to determine XEP support. So, I think that anyway the message should be sent to a full JID. As for potential memory leak I would say that it's better to leave this problem to a client developer. There are always clients, which behave incorrectly. Do you want to completely avoid using s? Cheers! -- Sergei Golovan
Re: [Standards] NEW: XEP-0225 (Component Connections)
Hi Tomasz! Tomasz Sterna schrieb: 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? :-) It could be and I thought about that as well. But don't we work on client connections as much as we work on server connections as well? I'd say I am used to use both namespaces. Matthias
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-0224 (Attention)
On Aug 09, 2007, at 22:46, Olivier Goffart wrote: I think the lower important level is related and should be include to this XEP. If you don't want immediate attention, why send the attention grabbing message in the first place? I could see a usecase for "normal" and "urgent", but then again, once you do send that attention message, it's always urgent anyways. I don't think you can ask the originating users to make that distinction. I'd guess the local client could make that differentiation based on the own presence (don't play the attention sound when DND, only flash the screen, for example). andy
Re: [Standards] NEW: XEP-0224 (Attention)
On Aug 09, 2007, at 21:55, Sergei Golovan wrote: I think that attention messages should not be sent with a , but should be a standalone message of type='headline', like so: This message looks like but is better because the recipient may receive result in case of accepted attention or error in case of ignored one. The ability of getting a response even makes disco#info queries unnecessary. I chose to use instead of because you don't have to specify a resource to send the message, and you don't need a reply on this one (every -message is a potential memory leak, when the receiving client doesn't behave properly), because even when the client displays the attention grabbing event, you can't know if the user has seen/heard it. Is there a serious reason to go to ? The element is not required in this spec, but I could change it to SHOULD NOT contain, would that be better? andy
Re: [Standards] Username Escaping with Gateway Registration
Peter Saint-Andre wrote: Peter Saint-Andre wrote: Ian Paterson wrote: XEP-0100 "Gateway Interaction" doesn't, AFAICT, explain whether the username supplied at registration should be the "Legacy Service username" or the "Jabber username". [The difference between these usernames (typically escaping) is explained in section 6.2 (User Addressing).] Can anyone please enlighten me on which username should be used? The username used for registration is the LegacyUserAddress. I'll clarify this in the spec. See here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0100.xml?%40diffMode=u&%40diffWrap=s&r1=1092&r2=1134&u=3&ignore=&k= TinyURL: http://tinyurl.com/2dxv5j That looks good, thanks :-) - Ian
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)
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
