Re: [Standards] presence priority -1 issues
Jack Moffitt wrote: 1. stanzas to the bare JID should not be send to this client because no user will read it. Use message storage or whatever a server may do with such a message. Agreed, and this required by RFC 3921. (Section 11.1 Rule 4.1). 2. stanzas to the full JID should be send to this client. There is a reason why the sender used the full JID for that message. It could be an IBB using message for two non-chat applications exchanging data. Also required by RFC 3921. (section 11.1 Rule 1). 3. should be send to all clients or two non-chat clients will never find each other to send messages to the full JID. Also required by RFC 3921. (Section 11.1 Rule 4.2). OK good, we all agree on the proper behavior and the spec seems to be consistent with those expectations. Now it's just a question of getting implementations to do the right thing. :) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0231 (Data Element) - local caching
On Tue, 29 Jul 2008 19:49:01 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Ahoj Pavle! > > Pavel Simerda wrote: > > Hello, > > > > I have some suggestions for XEP-0231 (Data Element). > > Thanks for looking at this spec so thoroughly. > I actually have some questions. First, lolek from the jabbim.cz project is going to propose a XEP for text emoticons. I like his ideas but I suggested him to use Data Element instead of a custom solution. He still has doubts but I promised him to try to sort it out and to help him with language corrections of his document too. I didn't find in the specs what should be used for domain ID in the CID. The examples apparently use the domain part of JID that is not unique for the clients. I looked at the RFC and still don't know a proper mapping to XMPP. His original idea was to use a cryptographic hash function and not a CID. He also pointed out he misses a feature that would allow a client to advertise which mimetypes it supports. This is another questions... if it's just emoticons, should we just support png and mng types or add some accept-advertisement facility? Is there a written policy for image formats in XMPP extensions? > > Right now, as the example shows: > > > > > to='[EMAIL PROTECTED]' > > type='groupchat'> > > Yet here's a spot. > > > > > > > > Yet here's a spot. > > > > > src='cid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit'/> > > > > > > > >> alt='A spot' > > cid='[EMAIL PROTECTED]' > > type='image/png'> > > iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP > > C/xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA > > AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J > > REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq > > ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0 > > vr4MkhoXe0rZigBJRU5ErkJggg== > > > > > > > > Note: in this particular example the data is very short, this may > > not be the case in real world where people tend to ignore the size > > of data they send. > > Yes, that's just about the smallest image I could find. The spec says > that the image should not be more than 8k (which is twice the > suggested size of an IBB chunk) but we don't know if people will > typically send images that are smaller or larger than 8k -- I think > smaller but I don't know that yet. > Might it be advertised by the client/server? And rejected if the other party tries to send a bigger one (just to force them to fix it)? > > We send data once for every session (and omit for subsequent > > messages). > > In this case it's important to define "session" (see rfc321bis). Is > it a chat session, a presence session, or something else? > Exactly. > > This has two important implications: > > > > 1) The other entity may or may not cache it for the session and > > reuse it. That is good. > > > > 2) If an entity keeps the data for a longer time (e.g. for weeks > > or even permanently), this cache will never be used. As the sending > > entity always resends the data for a new session. > > > > What I propose is: > > > > * By default the sending entity would not send the data. It would > >merely reference it by its cid url. > > * Let the recieving client follow "3.4 Retrieving Uncached Media > > Data" if the data is not cached (no real change, this is already > > being done). > > I think I like that approach. It introduces a round trip for the IQ, > which might introduce some latency. But it puts the burden for > "storing" and "serving" the image on the sender, which might > discourage abuse of in-band images. > > > * Reserve the possibility of sending the data immediately with the > >message for the *specific* case that the sending client actually > >knows the recieving party cannot have the data cached (e.g. the > >data was never sent before). This behavior should be considered > >optional. > > In that case the sender needs to keep a list of every JID to which it > has ever sent the image. That seems suboptimal. I didn't write it exactly as I meant it. There may be cases we are knowingly sending something really new. But we might just as well drop this feature if you think it's better. I'm afraid some people will object. > And I suppose the recipient might have received the image from > another sender at some point, or might have received the image > through other means (e.g., an emoticon "bundle"). The problem is... that we really want the users to get what we send them. If they got it from someone else, we need to secure it by a hash function, not a mere ID. It would have to actually check the hash when caching. Another issue would be the particular hash functions. Some client authors or users may want to prevent using data from third parties protected by weak hash functions. That's why I only considered cach
Re: [Standards] XEP-0231 (Data Element) - local caching
Ahoj Pavle!
Pavel Simerda wrote:
Hello,
I have some suggestions for XEP-0231 (Data Element).
Thanks for looking at this spec so thoroughly.
Right now, as the example shows:
Yet here's a spot.
Yet here's a spot.
alt='A spot'
cid='[EMAIL PROTECTED]'
type='image/png'>
iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP
C/xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA
AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
vr4MkhoXe0rZigBJRU5ErkJggg==
Note: in this particular example the data is very short, this may not
be the case in real world where people tend to ignore the size of data
they send.
Yes, that's just about the smallest image I could find. The spec says
that the image should not be more than 8k (which is twice the suggested
size of an IBB chunk) but we don't know if people will typically send
images that are smaller or larger than 8k -- I think smaller but I don't
know that yet.
We send data once for every session (and omit for subsequent messages).
In this case it's important to define "session" (see rfc321bis). Is it a
chat session, a presence session, or something else?
This has two important implications:
1) The other entity may or may not cache it for the session and reuse
it. That is good.
2) If an entity keeps the data for a longer time (e.g. for weeks
or even permanently), this cache will never be used. As the sending
entity always resends the data for a new session.
What I propose is:
* By default the sending entity would not send the data. It would
merely reference it by its cid url.
* Let the recieving client follow "3.4 Retrieving Uncached Media Data"
if the data is not cached (no real change, this is already being
done).
I think I like that approach. It introduces a round trip for the IQ,
which might introduce some latency. But it puts the burden for "storing"
and "serving" the image on the sender, which might discourage abuse of
in-band images.
* Reserve the possibility of sending the data immediately with the
message for the *specific* case that the sending client actually
knows the recieving party cannot have the data cached (e.g. the
data was never sent before). This behavior should be considered
optional.
In that case the sender needs to keep a list of every JID to which it
has ever sent the image. That seems suboptimal.
And I suppose the recipient might have received the image from another
sender at some point, or might have received the image through other
means (e.g., an emoticon "bundle").
I further propose we add some informational section about generation
of CIDs. Although it's specified elsewhere, I believe this XEP will be
very useful and will be referenced from many future XEPs (and maybe
improved as well - possibly some server caching etc). I think the
informational section could suggest UUIDs generated by hashing the
actual content.
Yes I think that would be helpful.
Another thing that could be considered... is to add some sort of
caching hint attribute that would suggest how long its reasonable to
cache a particular resource.
Do you think that would really be helpful? I'm still thinking about it...
Maybe we could borrow from HTTP Cookies
but allow (suggest) the clients to have some mechanisms for limiting the
time, size and number of cached objects.
There are many possibilities, I will just describe one of them.
Do you have examples of these?
cache="no"
- no reason for caching the file will not be used again
Perhaps a thumbnail related to file transfer or some other ephemeral image?
cache="session"
- we suggest the recieving party only caches for this
particular session
Perhaps also a thumbnail, or an image related to a whiteboarding session?
cache="12"
- we suggest caching for twelve days from the last use of this cid (!)
- for every use (recieved reference) the recieving client should reset
the date we count from
Perhaps images included in an XHTML notification from a blogging service
or somesuch?
cache="unlimited"
- we suggest the client picks the longest time it allows (it could
possibly cache some small pieces of data permanenty)
Perhaps a commonly-used emoticon?
Of course, the client MAY ignore the caching hit. In this case it
SHOULD NOT cache at all.
Why not? My client could ignore caching hints because it has its own
local policy (e.g. cache images only from people in my "Friends" group,
but cache those forever because I want to keep them in message history).
Or my client could ignore caching hints because it simply can't cache
images (no room on the device, web client, etc.).
If the cache attribute is not specified, we should decide on a
reasonable default value ('session' or '1'
Re: [Standards] XEP-0154: User Profile - enterprise vs. simple
Hello, I'm going to describe the issues we discussed in the jdev MUC room from my point of view. I'll also try to offer something new :). dwd pointed out many issues with enterprise-grade solutions and user profiles. stpeter suggested that these may also affect bigger public services (e.g. Facebook). I unfortunately missed these issues in my previous posts. *For all*: please read at least sections (1) through (3), they're short. 1) Common requirements - getting user profiles Servers must support *XEP-0163: Personal Eventing via Pubsub* to push the profile data to the client. Clients must be able to recieve PEP data, parse the profile data, and implement UI for viewing it. 2) The simpler case - user publishes his xmpp-based profile Clients should be able to *set* at least the most basic information. We need PEP support, profile data structure knowledge and UI for setting the data. Note: No additional server requirements, PEP is ok for us. 3) The harder case - server publishes a pre-existing non-xmpp profile with its own structure on behalf of the user a) viewing profile The server has to map the profile to the profile schema as well as it can and publish it with the PEP. The mapping may not be obvious in some cases. The client just views what it gets. b) setting profile The server may or may not allow the user to set the profile data through Jabber. What's more, the server should be able to specify which fields are read-write and which read-only (or even absent in the data model). This requires a totally different approach to setting the profile. 4) The controversy - model versus protocol In the simple case (2), we define a data model for user profiles. We also specify methods to retrieve them and publish them. Client authors design the UI. But in (3), we actually define an intermediate presentation layer so other clients understand the data and can present them in the UI. We omit or fix fields on the server-side and limit the flexibility we would otherwise offer. Many backend stores will only offer basic info and contacts. Shall we drop all other info sections and disallow any future extensions? I believe we should not! 5) Possible solutions for profile setting I believe we agree on the need to split the user profile into several PEP nodes (groups of fields) to avoid unnecessary data flows. We have to define fixed sets of fields (with value formats) to allow client authors to create usable viewing user interfaces. When we start thinking about setting the profile, the controversy shows itself. a) We could require user profile setting implementation on both the client and server side and disallow PEP publishing (this is effectively what the current version does, it uses PEP syntax but requires special handling!). But this means that we cannot use User Profile without server support which is weird! We're only using PEP events but not publishing features. This also means the client implementation will be a bit more complicated than necessary for (2). The added server-side and client-side complexity may extend the vcard-temp's usage and defer real-world implementation of XEP-0154. b) As the setting method for the backend-based profiles is totally different, it follows we could just ignore it and leave it to a different protocol/extension. No required server support (except for backend-based profiles). We're using PEP's publishing functionality. Client support only consists of PEP, profile elements and user interface. A backend-based profile server would reject any publishing requests with an appropriate error. Additionally, there would be a disco feature(s) that would warn the client not to set the profile (as it will be rejected anyway). Usually we announce features but this would rather be an exception from implied functionality of PEP. Disco would also say which URIs should not be set via PEP. Note: Backend-based settings would be done the same way it is done without Jabber. Additionally, we can use HTML forms over HTTP (with a web browser) or any user interaction technology, including ad-hoc commands. c) If we stick with (b) but we need the missing protocol for setting backend-based profile, we can do it. We can use service discovery to discover support for flexible profile setting. This disco feature also suggest we SHOULD NOT set the profile via PEP. The steps for a client to set a profile could be as follows: * we discover server requires special handling of some PEP (profile-related) nodes * we discover which nodes are to be handled specially * we let the user set the non-backend nodes without restriction * for a backend-based node, we take following steps: * we ask the server which fields we can set * we let the user fill in (modify) data (in an appropriate UI) * we send the data to the server (finished) This would be best described by stanzas with answers from the server. d) Waits for you to write. Note: (a) is difficult and unnecessary, (b)
Re: [Standards] New Proto-XEP: Multi-User Gaming
Arne König wrote: Hi Jack, Jack Moffitt wrote: It is quite easy to extend MUC. One way is through plugins in your muc implementation. For example, Chesspark creates a new role in our game MUCs called "player". Players don't normally receive messages to the room from non-players. This is so that people watching the game cannot interrupt them or help them accidentally. However, player chat is seen by everyone. There are two different thing to look to at here. First is the protocol level. Extending the MUC protocol is fine. But changing the routing actually breaks MUC since routing in MUC isn't intended to be changed. I think it's OK to change the routing, e.g. with a special extension in the message. So if the MUC room receives a message of type groupchat without the message, it reflects the message to all occupants. But if the message has a special extension (e.g., specifying a certain team) then the message is reflected in a special way (not broadcasted to all recipients). This could also be done (more easily perhaps) via bots, such as [EMAIL PROTECTED]/red for the "Red Team" and [EMAIL PROTECTED]/blue for the "Blue Team" or whatever. The second problem is the implementation. Adding a role to the chat requires changes in both server and client MUC implementations. In many implementation that is hard to accomplish. We try do create a protocol that can be implemented in most clients and servers. If you take Openfire for example. Their MUC component doesn't have a plugin infrastructure. Thus to change the routing of MUC you would have to rewrite the whole component. On the client-side you have multi-protocol clients with similar problems. It sounds like you need to use better implementations on the server side. :) But I agree that you'd like to use stock clients, so you need to minimize the diff for the client-to-service protocol. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] presence priority -1 issues
> 1. stanzas to the bare JID should not be send to this client > because no user will read it. Use message storage or whatever a > server may do with such a message. Agreed, and this required by RFC 3921. (Section 11.1 Rule 4.1). > 2. stanzas to the full JID should be send to this client. > There is a reason why the sender used the full JID for that > message. It could be an IBB using message for two non-chat > applications exchanging data. Also required by RFC 3921. (section 11.1 Rule 1). > 3. should be send to all clients or two non-chat clients > will never find each other to send messages to the full JID. Also required by RFC 3921. (Section 11.1 Rule 4.2). Clearly Jabberd2 and Google Talk are not compliant in this respect and need to be fixed. I'm preparing a detailed bug report for both, but if those guys are listening, please fix this asap pretty please... with sugar on top? jack.
Re: [Standards] XEP-0154: User Profile - comments
On Mon, 28 Jul 2008 21:21:02 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Ahoj Pavle! ;-) > > Pavel Simerda wrote: > > Hello, > > > > I finally got to examine the XEP-0154 (User Profile). > > Thanks for the review. It was fun :). > > When reading > > through I realized how big a job it was to synchronize the items and > > names with various standards and other XEPs. > > I think it was mostly bookkeeping, but thanks. > > > 1) Look at the examples at > > http://www.xmpp.org/extensions/xep-0163.html (Personal Eventing via > > Pubsub). Now look at the examples of XEP-0154. > > > > The biggest difference is the added complexity and data because of > > the data form syntax. These are actually no forms but data with a > > particular structure. > > I'm not a huge fan of x:data here either. > > > I read carefully the arguments for data forms but most of them also > > apply to structured formats. Then there is database storage which > > I consider a non-issue (I can give more details if needed) and > > extensibility that should be IMO done differently (more details > > later). > > > > Possible solution: Replace all of the data forms syntax with > > variable names > > by custom elements of the same (or similar) names. At the same time > > I propose to keep up with the examples in XEP-0154. > > > > Example: > > > > > > > > > > > > > > > > > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > would be changed (if we make no other changes) to: > > > > > > > > > > > > > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > > > > > > > > > Another possibility: a simple name-value format would work just as > well as x:data, for example: Possibly. I preffered XML names for this but it depends on what logic we use in the extensibility stuff (see down this mail). > > > > > > > > > > > > > > > (Btw, the element was missing in at least one of the > > examples, if my understanding is correct.) > > Probably. :) > > > 2) I believe that the answer to the query for user information > > should be reasonably short. This would have several consequences. > > > > * it would be possible to use with mobile client (I still have > > problems with vcard images on my mobile) > > * it would not be then necessary to implement special techniques > > for partial profile getting/setting > > Those are good goals. > > > Possible solution: Don't include any data except short text. This > > includes: > > * User pictures (aka avatars) > > I'm not sure that user pictures are the same as avatars. But perhaps > it's better to host such data via HTTP? > > > * Long 'about' texts > > * Piles of unnecessary or uninteresting information > > Unnecessary or uninteresting to whom? To most people. Better stated: to those that don't explicitly request them (formerly this was solved by selecting individual fields that is imho suboptimal). > > These requirements are very easy to achieve. We only need to divide > > the former monolithic profile/extended vcard. We would need more > > namespaces. > > > > Example separation: > > > > * urn:xmpp:tmp:profile:basic - Contact information, birthday, > > nameday, etc... > > * urn:xmpp:tmp:profile:about - About text (as in vcard-temp) > > * urn:xmpp:tmp:profile:picture - User picture / photo > > That seems reasonable. > > > Use cases: > > * I have a desktop client and good connection but lots of contacts. > >I want my client to first get the information about users and > > then (possibly) the pictures. > > * I have a mobile client and/on slow internet connection. I just > > want to check my friend's phone number. Downloading other contact > > info is considered a reasonable overhead (I may need it if the phone > >number is not published anyway). Downloading user's picture and a > >long about section *cannot*. > > * User's picture changes, I don't need to download his > > about/contacts. > > * User's contacts change, I don't need to recieve all the other > >(unchanged) stuff. > > What is this "download" stuff? Isn't the data pushed to you via PEP? Recieve would be a better word, maybe. But it is actually downloaded by the client when pushed. > > 3) home / work addresses > > > > There are several solutions for designating home/work addresses. As > > far as I understand the current XEP, we need to distinguish three > > types of contact information pieces: generic, home and work. > > > > Home and work addresses are usually presented in separate tabs. > > There could be also usecases where home information is irrelevant > > or has a different publishing policy than work information. What > > I'm not sure about is the generic info, any suggestions? > > > > Possible solu
Re: [Standards] pubsub simplification
On Tue Jul 29 15:18:01 2008, Peter Saint-Andre wrote: Ralph Meijer wrote: Dave Cridland wrote: On Tue Jul 29 06:49:41 2008, Kevin Smith wrote: On Mon, Jul 28, 2008 at 9:58 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > In accordance with XMPP Council consensus, I have provisionally separated > all the information about pubsub collections into a new spec: > I wonder if at the same time we might want to move the information about > presence integration from XEP-0060 back to XEP-0163? I'm in favour of splitting collections, but not so much of splitting out presence - we spent quite a long time deciding that 163 should only be a profile of 60, from what I recall. As a suggestion - and I'm only highlighting options - we could split out the fancier things into one or more new specifications, leaving XEP-0060 as a core, with extra XEPs holding additional features, and XEP-0163 binds XEP-0060 and a selection of brightly coloured coat hangers into the profile that is PEP. I'm not sure if this is a good idea, mind - it's not clear to me if this gives a net benefit or not - but it would keep XEP-0163's "profile" status. I was thinking the same thing, indeed. Right. So not all pubsub-related features would be defined in XEP-0060, because certain "profiles" (the only example we have so far is PEP) would define new node configuration options and the like. The result would be that XEP-0060 defines the core (is that just "pub" and "sub"?) whilst other specs define things like collections, presence integration, filtered notifications, subscription options, management of subscription requests by the node owner and other such administrative tasks, etc. So we'd have a stripped-down XEP-0060 and a bunch of extensions to the pubsub core. But, in this scenario - and I reiterate, I'm not sold on it yet myself - XEP-0163 would remain just a profile, gathering together a set of mandatory options and default behaviours, rather than defining anything new itself. Another profile would probably appear which described a different set for "traditional pubsub". Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] pubsub simplification
Peter Saint-Andre wrote: Ralph Meijer wrote: Dave Cridland wrote: On Tue Jul 29 06:49:41 2008, Kevin Smith wrote: On Mon, Jul 28, 2008 at 9:58 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > In accordance with XMPP Council consensus, I have provisionally separated > all the information about pubsub collections into a new spec: > I wonder if at the same time we might want to move the information about > presence integration from XEP-0060 back to XEP-0163? I'm in favour of splitting collections, but not so much of splitting out presence - we spent quite a long time deciding that 163 should only be a profile of 60, from what I recall. As a suggestion - and I'm only highlighting options - we could split out the fancier things into one or more new specifications, leaving XEP-0060 as a core, with extra XEPs holding additional features, and XEP-0163 binds XEP-0060 and a selection of brightly coloured coat hangers into the profile that is PEP. I'm not sure if this is a good idea, mind - it's not clear to me if this gives a net benefit or not - but it would keep XEP-0163's "profile" status. I was thinking the same thing, indeed. Right. So not all pubsub-related features would be defined in XEP-0060, because certain "profiles" (the only example we have so far is PEP) would define new node configuration options and the like. The result would be that XEP-0060 defines the core (is that just "pub" and "sub"?) whilst other specs define things like collections, presence integration, filtered notifications, subscription options, management of subscription requests by the node owner and other such administrative tasks, etc. So we'd have a stripped-down XEP-0060 and a bunch of extensions to the pubsub core. I don't think that is what Dave suggests. Rather, leaving XEP-0163 as is and split XEP-0060 up in multiple documents, probably requiring reference updates. ralphm
Re: [Standards] New Proto-XEP: Multi-User Gaming
Hi Jack, Jack Moffitt wrote: > It is quite easy to extend MUC. One way is through plugins in your > muc implementation. For example, Chesspark creates a new role in our > game MUCs called "player". Players don't normally receive messages to > the room from non-players. This is so that people watching the game > cannot interrupt them or help them accidentally. However, player chat > is seen by everyone. There are two different thing to look to at here. First is the protocol level. Extending the MUC protocol is fine. But changing the routing actually breaks MUC since routing in MUC isn't intended to be changed. The second problem is the implementation. Adding a role to the chat requires changes in both server and client MUC implementations. In many implementation that is hard to accomplish. We try do create a protocol that can be implemented in most clients and servers. If you take Openfire for example. Their MUC component doesn't have a plugin infrastructure. Thus to change the routing of MUC you would have to rewrite the whole component. On the client-side you have multi-protocol clients with similar problems. >> For example if we join a game room it's complicated to handle the MUC >> affiliation, MUC role, game role and the game state in the existing >> stanzas and to enter the room in two steps make the process slow and we >> have redundant messages. > > I think you're prematurely optimizing here. At Chesspark the arbiter > sends a game start message to both players that tells them which room > to join. Arbiter and both players all join the room. Arbiter sets > the appropriate roles for the players and sends state. Players send > iq requests to arbiter directly to affect game state, and arbiter > broadcasts state changes to the room for everyone. When new people > join, arbiter directly messages them the current state. > > It's not a single stanza, but it is not overly verbose and it works > great. It's very easy to put hooks into the MUC component to fast > track messages from trusted components, and this can make processing > messages extremely efficient. Most things you describe don't conflict with our proposal. The only thing that we don't do is send states through the MUC room since we try to seperate all game messages from chat. Our proposal defines the communication between the game service (arbiter) and the clients. It also provides a way to discover the associated chat. Everything besides that is implementation specific. The service may create the MUC room, configure it accordingly, update player statuses (give voice to every player, no voice for spectators). >> Also routing game turns can be incompatible with the MUC rooms, so that >> we can't provide messages to only a part of the players (for example a >> team). > > We already do this with our palaver extension for new roles. You > could easily have a team role with a name or id, and then do delivery > based on that. Or you could utilize multiple muc rooms. But you don't need any of those hacks if you don't misuse the MUC for game messages. Team chat is a special problem that should be handled by the game protocol itself. This again should be no big problem as long as you use team chats only for chat. > This is an age old debate in the jabber community. Whether games need > a muc or an arbiter. In the general case an arbiter is necessary, and > certainly MUCs are natural tools for gaming. We've been doing > multiplayer XMPP games for 3 years now, and I can tell you that MUCs > work very well. I agree that you need both an arbiter and a chat. But MUCs are natural tools for chat, not for gaming. > We do this as well, and the component is named Arbiter (as mentioned > above). It does allow the clients to be simpler, although for some > games this savings is not great if you want to provide a great UI. > For example, none of the Chesspark clients have to know the specific > rules of any chess variant, but they do need general information on > how pieces can move if you want to support features like allowed > square highlighting. I suppose you could do this through the > protocol, but it could potentially be a lot of data to send. There are definitely cases were it may be useful to allow a client to "guess" a move. Whether that are chess variants or games with incomplete knowledge. We will add support for that. > I suggest anyone that is working in this area should also create a > Chesspark account (it's free and works with your existing jabber > accounts) and look at the protocol a little bit. We've not yet > documented it, but we do plan to do so, and our clients are GPL. I > gave a small presentation of it at XMPP Summit 5, and if anyone is > interested, I'm happy to write up a summary on my blog. Where can we download the source for the client? We only saw a link for the windows installer. Also we would appreciate you describing your protocol further. Thanks for your feedback, Arne
Re: [Standards] rfc3920bis -06
Dirk Meyer wrote: Sorry for the late answer, I've been very busy the last weeks. Peter Saint-Andre wrote: Dirk Meyer wrote: The same is true for presence (in RFC 39210. I found the presence handling much too complicate to implement. It took me longer than adding PubSub and XTLS support. Yes, presence is complex. Sorry about that. Did you implement it in a server or a client? Only client but IIRC adding a friend to the roster resulted in getting an iq result without sending a get or set. Very confusing. So you sent and you received an IQ result from your server? That sounds like a server bug. 11.2.3.3. Full JID --- If the JID contained in the 'to' attribute is of the form <[EMAIL PROTECTED]/resource> and there is no connected resource that exactly matches the full JID, the stanza shall be processed as if the JID were of the form <[EMAIL PROTECTED]>. Is this also true for IQ stanzas? That would be very confusing if I query one entity for services and send something to it, it is gone and some other entity gets it. What happens if I send a get-IQ and my application crashes. Does the result go to a different entity? No, it doesn't, because IQs to the bare JID are handled by the server itself on behalf of the bare JID, not delivered to another resource. Right, my fault. If my application uses the full JID it has a reason to do so. I also would prefer the same for messages (which I can get with XEP-0079). What is "the same" here? I mean when I send a message to the full JID it MUST send be routed to that JID, just like for IQ stanzas. When chatting I use the bare JID and talk to the client with the best priority. When something chooses a full JID it has a reason to do so and a server should hinor that. Yes, directed presence works that way. If the JID contained in the 'to' attribute is of the form <[EMAIL PROTECTED]/resource> and there is a connected resource that exactly matches the full JID, the server SHOULD deliver the stanza to that connected resource. I would prefer MUST It needs to be a conditional MUST, because the server MUST NOT deliver a message stanza to you if: 1. According to XEP-0016 you are blocking messages from the sender. 2. According to RFC 3920 your resource has negative presence priority. So maybe not "MUST send to this resource" but "MUST NOT send the message to a different resource". This keeps XEP-0016 in place. So you are suggesting that a message addressed to a full JID would never be delivered to another resource (or stored offline?) if that resource does not exist. Correct? I hadn't considered that option. And about negative priorities, I think if someone uses a full JID it has a reason for this, no matter what the priority is. My basic problem is how to handle two non-chat applications? They must have a negative priority to prevent receiving user chat messages but they may want to "chat" between each other. A message that is addressed to a resource with a negative priority is delivered to that resource. The only thing that negative priority does is prohibit delivery to that resource if the message was addressed to the bare JID, not the full JID. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] pubsub simplification
Ralph Meijer wrote: Dave Cridland wrote: On Tue Jul 29 06:49:41 2008, Kevin Smith wrote: On Mon, Jul 28, 2008 at 9:58 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > In accordance with XMPP Council consensus, I have provisionally separated > all the information about pubsub collections into a new spec: > I wonder if at the same time we might want to move the information about > presence integration from XEP-0060 back to XEP-0163? I'm in favour of splitting collections, but not so much of splitting out presence - we spent quite a long time deciding that 163 should only be a profile of 60, from what I recall. As a suggestion - and I'm only highlighting options - we could split out the fancier things into one or more new specifications, leaving XEP-0060 as a core, with extra XEPs holding additional features, and XEP-0163 binds XEP-0060 and a selection of brightly coloured coat hangers into the profile that is PEP. I'm not sure if this is a good idea, mind - it's not clear to me if this gives a net benefit or not - but it would keep XEP-0163's "profile" status. I was thinking the same thing, indeed. Right. So not all pubsub-related features would be defined in XEP-0060, because certain "profiles" (the only example we have so far is PEP) would define new node configuration options and the like. The result would be that XEP-0060 defines the core (is that just "pub" and "sub"?) whilst other specs define things like collections, presence integration, filtered notifications, subscription options, management of subscription requests by the node owner and other such administrative tasks, etc. So we'd have a stripped-down XEP-0060 and a bunch of extensions to the pubsub core. Or at least that's how I understood our conversation in Portland. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] online users counter
Andreas Monitzer wrote: On Jul 29, 2008, at 14:11, Sylvain Mundialco wrote: Hi. Have one question here. Is there a way to query the xmpp server to know the total users currently online. Is it define in one of the xep ? Hi, ejabberd uses Ad-Hoc commands for this, returning a form with the requested information. http://www.xmpp.org/extensions/xep-0050.html Isn't this feature defined in XEP-0133? http://www.xmpp.org/extensions/xep-0133.html#get-online-users-num /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] online users counter
On Jul 29, 2008, at 14:11, Sylvain Mundialco wrote: Hi. Have one question here. Is there a way to query the xmpp server to know the total users currently online. Is it define in one of the xep ? Hi, ejabberd uses Ad-Hoc commands for this, returning a form with the requested information. http://www.xmpp.org/extensions/xep-0050.html andy
Re: [Standards] online users counter
On Tue, Jul 29, 2008 at 2:11 PM, Sylvain Mundialco <[EMAIL PROTECTED]> wrote: > Is there a way to query the xmpp server to know the total users currently > online. Is it define in one of the xep ? Yes: XEP-0039: Statistics Gathering http://www.xmpp.org/extensions/xep-0039.html
Re: [Standards] online users counter
On Tue, Jul 29, 2008 at 2:11 PM, Sylvain Mundialco <[EMAIL PROTECTED]> wrote: > Hi. Have one question here. > > Is there a way to query the xmpp server to know the total users currently > online. Is it define in one of the xep ? > > Sylvain > Hi, There is a deprecated Statistics Gathering XEP, http://www.xmpp.org/extensions/xep-0039.html . Maybe it fits your needs and I know of ejabberd that it has support for this. Cheers, Tobias
[Standards] online users counter
Hi. Have one question here. Is there a way to query the xmpp server to know the total users currently online. Is it define in one of the xep ? Sylvain<>
Re: [Standards] pubsub simplification
Dave Cridland wrote: On Tue Jul 29 06:49:41 2008, Kevin Smith wrote: On Mon, Jul 28, 2008 at 9:58 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > In accordance with XMPP Council consensus, I have provisionally separated > all the information about pubsub collections into a new spec: > I wonder if at the same time we might want to move the information about > presence integration from XEP-0060 back to XEP-0163? I'm in favour of splitting collections, but not so much of splitting out presence - we spent quite a long time deciding that 163 should only be a profile of 60, from what I recall. As a suggestion - and I'm only highlighting options - we could split out the fancier things into one or more new specifications, leaving XEP-0060 as a core, with extra XEPs holding additional features, and XEP-0163 binds XEP-0060 and a selection of brightly coloured coat hangers into the profile that is PEP. I'm not sure if this is a good idea, mind - it's not clear to me if this gives a net benefit or not - but it would keep XEP-0163's "profile" status. I was thinking the same thing, indeed. ralphm
Re: [Standards] pubsub simplification
On Tue Jul 29 06:49:41 2008, Kevin Smith wrote: On Mon, Jul 28, 2008 at 9:58 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > In accordance with XMPP Council consensus, I have provisionally separated > all the information about pubsub collections into a new spec: > I wonder if at the same time we might want to move the information about > presence integration from XEP-0060 back to XEP-0163? I'm in favour of splitting collections, but not so much of splitting out presence - we spent quite a long time deciding that 163 should only be a profile of 60, from what I recall. As a suggestion - and I'm only highlighting options - we could split out the fancier things into one or more new specifications, leaving XEP-0060 as a core, with extra XEPs holding additional features, and XEP-0163 binds XEP-0060 and a selection of brightly coloured coat hangers into the profile that is PEP. I'm not sure if this is a good idea, mind - it's not clear to me if this gives a net benefit or not - but it would keep XEP-0163's "profile" status. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
