Re: [Standards] Comments on SIFT
> With per-message filtering this changes to something like this:
>
> 3. loop over the resultset and send all _allowed_ messages to the
> newly available resource
> 4. for each sent message, DELETE FROM offline_messages WHERE JID ==
> ${account_jid} and MESSAGEID == $(unique_message_id)
>
> This could be optimized somewhat, but would still be relatively complex.
This is a non-issue. The problem here is how expensive it is to find
each message to delete, but you have a list of IDs. You can avoid all
the overhead of multiple queries by sending a single SQL statement:
DELETE FROM offline_messages WHERE jid == ${account_id} and message_id
IN (@unique_message_ids)
This should probably be more efficient than the non-allow case,
because there are less messages to delete than the full list.
jack.
Re: [Standards] LAST CALL: XEP-0244 (IO Data)
>> > What I would prefer: >> > >> > 1. An Asynchronous Ad-Hoc Commands XEP. >> >> I agree that it makes sense to split the asynchronicity stuff out of >> XEP-0244 into a separate spec -- perhaps a new XEP but I think >> preferably a revised version of XEP-0050 so that everything about the >> core of ad-hoc commands is in one specification. > > A revised XEP-0050 sounds fine. +1 from me. jack.
Re: [Standards] XEP-0175 feedback
I'm fine with those amendments, Dave. jack.
Re: [Standards] XEP-0175 1.2rc1
> No! trace data should, at most, just be logged. It's intended to have no > semantic value. By using it to identify a particular anonymous user (across > sessions) you are adding a semantic. I don't have strong feeling for this, but I thought I'd point out the following. This was Andy's use case: "I anticipate looking at a large number of anonymous BOSH connections and wanting to know which blogs they are looking at without having to look up their pubsub subscriptions." That sounds a lot like logging to me. jack.
Re: [Standards] XEP-0175 1.2rc1
> My use is more of a lazy hack. I want to use the anonymous JID > resource to store information about BOSH clients. For example, we > could have a number of web pages on different domains connecting via > proxy to a single BOSH service and we would like to know at a glance > the domain name of the site they are connecting from Wouldn't a better way to do this be the RFC 4505 trace data? You could put shuch data into the element and use it on the backend or whereever to identify users this way. I assume that is the purpose of trace data. This however, may not be well supported in servers. I only thought of it as I saw it mentioned at the end of the recommendation section of the XEP 175 changes. jack.
[Standards] XEP-0175 feedback
In general, the proposed changes in v1.2 at http://xmpp.org/extensions/tmp/xep-0175-1.2.html are sound ones. I do however have some minor points to raise. 1) The current wording states that anonymous users SHOULD NOT be able to establish long term relationships. I believe this is too strong. I think that it will be quite common to use SASL ANONYMOUS clients to do things like pubsub scriptions and creating muc rooms. My team and I have done this in nearly every app we've written. I do however agree that it makes sense to tear these down once the session is over. I propose the following wording instead: Anonymous users MAY establish relationships with services and users if allowed by sever policy such as presence subscriptions, multi-user chat rooms, and pubsub subscriptions. If a server permits these relationships, it MUST cancel such relationships when the user's session ends. I might add another sentence as well: It is not recommended that SASL ANONYMOUS users add human contacts to their rosters, as this may create odd user experiences. 2) The next line states that users SHOULD NOT store things on the server, and that if so the server MUST delete them. This is also overly restrictive. I can see several use cases where one would want to temporarily store something on the server and retrieve it in another session, similar to an HTTP cookie. I think that it should be the server operators perogative to allow or disallow storage and to determine when that storage is undone. Perhaps changing the MUST to MAY is enough. I do think that Peter's previous feedback of there being two different scenarios is spot on. Some of us see this as "what should SASL ANONYMOUS users be able to do on jabber.org" and some of us are not running IM servers, but using SASL ANONYMOUS as a tool in a bigger application. I think the above wording proposals are good enough for both cases, but if people feel strongly otherwise, I think we may have to split this into two sections of recommendations for the different use cases. jack.
[Standards] SASL digest-uri issues
So RFC 2831 says: digest-uri-value = serv-type "/" host [ "/" serv-name ] and RFC 3920 does not seem to specify anything else. Implementations seem to expect xmpp/DOMAIN whre DOMAIN is the domain part of the JID. One reading of 2831 might lead one to implement something like: xmpp/talk.google.com/gmail.com This is actually bad news, because BOSH clients will not be able to get this extra SRV information, unless the connection manager returns it somehow. Should we add some language to 3920bis to lock this down so that we don't have implementations that are incapable of BOSH? jack.
Re: [Standards] Namespaces, specifications, and protocol life cycles
> urn:xmpp:protoname:1 > > That last portion we'll treat as a version number. Any time we cause > incompatibility between versions of the XEP, we update it. (Note, that's not > "every new XEP"). I dislike this solution. One reason is that matching against two choices (one with :tmp: and one without) is a fairly easy XPath expression. It's also easy to transition code from :tmp: to code without :tmp: over time. Adding in a number means that you now have to use regular expressions in your XPath or have potentially three or more possible choices. Another reason is that we may end up with various incompatible implementations instead of delaying implementation. It's pretty easy to make an argument that server XYZ should drop the :tmp: namespace in the next major version once a draft has reached a certain point. It's a lot different to ask people to switch from version 2 to version 3. Elsewhere in this thread someone stated that MIME is stuck at 1.0. HTTP is at 1.1 and may never move. In reality the standards don't change so much that version numbers are needed in the URNs. I'd like to see a clearer statement of the problem to solve rather than so much debate over nuances of a proposed solution. It seems there is some hesitancy over implementing a protocol containing :tmp: in the name. There is also of course the problem if distinguishing between versions of a particular protocol when it has gone through some major revisions. I don't know that there is a good solution for the latter problem. All protocols experience this catch-22 at the start. Implementations are slow to move forward when the protocol changes enough to warrant significant investment to retool code. It's true that some protocols use version numbers for this, but typically the amount of versions being supported is either quite low, or care is taken such that each version is merely a superset of an earlier version (ie, HTML, HTTP). The other mechanism is to make new protocol or layer over one. This happened with TLS for example. In our own world, vcard avatars are an example where the protocol got, not a new version, but a new name. > When they pass a certain maturity level, they become "urn:xmpp:protoname". > This is great, but we don't do this until they pass a maturity level which > is often hard to judge without implementation experience. There is another solution to the reluctance to implement which also takes some of the ambiguity out of the time line here. That is to issue the canonical urn as soon as a XEP draft is accepted by the council. Why wait until it has reached some nebulous maturity level? If we accept a XEP, immediately issue it a urn. This is early enough in the life cycle that it should not affect implementers, and urns are infinite in number. We need not worry about wasting them. If we are worried about name space collisions I suggest adopting a year into the urn like so: urn:xmpp:2008:microblogging If that protocol became historic or was otherwise out of us, we could issue urn:xmpp:2010:microblogging to whatever took over. I'm not sure we have so many XEPs that such a convention is needed. Hopefully I'm not missing something. As it stands, I'm not convinced versioning URNs is warranted or helpful. jack.
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] New Proto-XEP: Multi-User Gaming
> Our problem is that we found no elegant way to extent MUC with all the > features it provides. Because MUC is big and provides features we don't > need and it's difficult to integrate our idea in MUC. 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. Another way to extend muc is just to invent some new adhoc comments and implement them in the muc. > 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. > 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. > On the other hand implementing a small new gaming protocol is simpler > as to find a way to modify the existing MUC implementations that it can > be used for gaming. We think our proposal is very flexible so it's > possible to implement small game clients without MUC (and for example > use another client for communicate) or support additionally ways of > communication such as jingle. 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. >> Does it mean the server part must know the rules? > > Yes, since we need server support for gaming (for routing, saving games > such as the client don't have the complete knowlege), the server has to > know the game rules. This can support simpler and smaller clients and we > have a sigle point of trust for validation. 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. 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. jack.
Re: [Standards] presence priority -1 issues
>> It's possible this is just a UI problem. > > I remember chatting to Pedro Melo about this back in February, and I > believe our conclusion back then was just that clients will start > showing -1 as a non-chat resource, or somesuch, depending on how > general usage pans out Ok, fair enough, but there are other problems. Jabberd2 and Google Talk both refuse to send presence to resources at priority -1. This is fatal for us with Speeqe since this means you will never receive muc presence from the room. I haven't tested this yet with Palaver, but this is the case with ejabberd 2.x muc component when using either jabberd2 or google talk accounts to access them. I hope that I am just missing something. jack.
[Standards] presence priority -1 issues
At XMPP Summit 5 this past week it became clear that lots of people are using or are planning to use presence priorities of -1 to allow specialized clients access to various XMPP resources. At Speeqe we do this so that our MUC client doesn't steal private messages. I believe that Fritzy at Seesmic said that Twhirl would soon start doing this now that they have XMPP support there for Identi.ca. This has lead me to discover some small usability problems. It looks like the spec requires that users with presence priority -1 be shown as available, but I'm not sure if I'm missing something in the spec or if it is just underspecced. http://www.xmpp.org/rfcs/rfc3921.html#presence-resp-probes says that the server must reply from all "available" resources, but it does not say how this interacts with negative presence priorities. The unwelcome side-effect of this is that if you are online only in negative priority mode you show as available to all your contacts, but you cannot receive any messages to the bare jid. This is pretty confusing for people trying to talk to you. Is this a nuisance we have to live with? Can a clarification be made here? Can the different server authors tell us what they have done in this edge case? Thoughts? jack.
Re: [Standards] XEP-0045: roomnick case
Currently in XEP-0045, roomnicks are case-sensitive. To be precise roomnicks are handled according to the Resourceprep profile of stringprep: http://www.xmpp.org/extensions/xep-0045.html#bizrules-jids This means that the following roomnicks are all different: StPeter stpeter STPETER Some people have pointed out that this can be confusing to end users. Not only this, but it's very easy to "steal" someone's identity when they are not there. You just log in with their normal nick. At Chesspark we make all public rooms non-anonymous and we always show the full jid or (if they are in your roster) the roster nick for that person. That way no one is ever confused who is who. So we've basically solved this in the client. All this nick stuff stuff is so IRCish anyway. It's nice if what you want is an anonymous room, but for everything else, it's just a mess IMO. After trying several solutions we found that this was least confusing to everyone and we have gotten no complaints except for the occasional jerk that signs up with a name like st.peter or stpeter_, but there's little you can do about that but ban the offenders. jack.
