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-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-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] 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)
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] 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, 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] 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=sr1=1092r2=1134u=3ignore=k= TinyURL: http://tinyurl.com/2dxv5j That looks good, thanks :-) - Ian
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-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: 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-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-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] 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 and enable the user to send messages anyway. In your approach, the client would need to know that the user does not
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 body/, but should be a standalone message of type='headline', like so: message from='[EMAIL PROTECTED]/lab' to='[EMAIL PROTECTED]/home' type='headline' attention xmlns='http://www.xmpp.org/extensions/ xep-0224.html#ns'/ /message This message looks like iq/ but iq/ 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 message/ instead of iq/ because you don't have to specify a resource to send the message, and you don't need a reply on this one (every iq/-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 iq/? The body/ element is not required in this spec, but I could change it to SHOULD NOT contain, would that be better? andy
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 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)
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 body/, but should be a standalone message of type='headline', like so: message from='[EMAIL PROTECTED]/lab' to='[EMAIL PROTECTED]/home' type='headline' attention xmlns='http://www.xmpp.org/extensions/ xep-0224.html#ns'/ /message This message looks like iq/ but iq/ 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 message/ instead of iq/ because you don't have to specify a resource to send the message, and you don't need a reply on this one (every iq/-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 iq/? You're already use iq/ 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 iq/s? Cheers! -- Sergei Golovan
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)
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
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)
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)
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 body/ 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)
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, message/ is handled by a single function, whereas iq/-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] 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] 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.
