[Standards] XEP-0292 vCard4 Reinventing the Wheel?
Hi, I'm currently looking at XEP-0292. While I welcome a better specification than vcard-temp, there's one thing I don't quite understand: Why doesn't it use plain PEP, instead defining its own protocol? This way, all of the servers have to specifically implement support for it, which slows down adoption tremendously. XEP-0084 demonstrated quite well how to publish a large PEP node without the other clients having to download the whole thing more than once. Why isn't this technique used here? Regards, Andreas Monitzer
Re: [Standards] Planned Updates to XEP-0301 (Real Time Text) -- 1s vs 250ms interval
XEP-0301 (Real Time Text) -- http://www.xmpp.org/extensions/xep-0301.html >I did not realize that you described a case with increasing latency. > My comment was for a long but steady latency. > > Now to my second question: Do you want to change anything in the > specification as a conclusion of this discussion? > I suggest to not change anything, since we have what we need in section 10.2. I don't think changes are needed to 10.2 either. Everybody who made comments so far (you and Bernard) appears to be already covered by section 10.2 of XEP-0301, if necessary for those special cases. On a related note, it is rare to have a connection above ~1000ms ping that is 'steady' on a prolonged period -- usually it's fluctuating a lot when pings are that high. Anybody else with XEP-0301 comments / suggestions / changes? Thanks! Mark Rejhon www.realjabber.org Thanks, Mark Rejhon
Re: [Standards] Microblogging: XEP-0277 and beyond
On Friday, August 19, 2011 10:10:01 AM Joe Hildebrand wrote:
> On 8/18/11 2:55 PM, "Justin Karneges"
>
> wrote:
> > I have a protocol flow for reliable pubsub that I've not yet publicized,
> > but essentially the idea is to include Result Set Management (XEP-0059)
> > UID values in pubsub event notifications. The client can then notice if
> > it missed an item
> > and use iq-get to catch up.
> >
> > Maybe this could go in some "RSM with PubSub" XEP that sorely needs to be
> > written.
>
> I like the direction you're heading with this. While we're at it, we need
> something similar for PEP that uses date/timestamps on implicit subscribes,
> since one implicit subscription goes to multiple publishing nodes, each of
> which have different RSM ids. The hope is that you could cache between
> sessions, and only receive PEP updates for things that have changed. This
> would be a huge win for XEP-292 PEP-based vCard, particularly if avatars
> are included.
To fetch items since some timestamp, I'm encoding that in the item retrieval
request using client-meaningful RSM ids. For example, you could do an iq-get
for items since RSM id "time:{isodate}". This type of id would only be used
in requests. (Note: I'm open to using a different approach for letting the
client specify positions, but this seemed simple enough).
In the context of PEP, it would just be a matter of putting this same type of
position spec into the subscription request, and then each remote node would
reply with all items since that time (or just the one item only if it has
changed, I think PEP is always singleton?).
> One thing we have going for us is that a re-publish of an existing item (by
> id) replaces the previous version, so a little bit of overlap between
> sessions is ok
Indeed. In my case I consider a time-based query to be inclusive, so as to
not miss updates occuring within the same second. In the rare case you pick
up the same item again, it's harmless.
Justin
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 18.08.2011 23:00, schrieb Alexander Holler: Am 18.08.2011 15:43, schrieb Peter Saint-Andre: I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an effort to incorporate developer feedback I've received since the last version 3 years ago. The XMPP Council would like to vote on these revisions before the end of September or possibly early October, so it would be great if folks could check the diff in the next few weeks: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 A rendered version is here: http://xmpp.org/extensions/tmp/xep-0045-1.25.html Thanks for the update. I will try to read (again) as much as I can. Here is my current list of open questions: - Which nicks are reserved? (owner, admins, members) - Owners, admins ormembers without reserved nicks? - What happens with reserved nicks when someone changes his nick? Does the reserved nick changes too? I don't know why fully-anonymous rooms got removed, according tothe history this was done 2002. But I think there are good reasons for rooms where even moderators or owners shouldn't be able to see real JIDs. E.g. thinking about countries where people have to fear speaking freely without beeing anonymous. There might be possibilities to discover real JIDs when access to the machine running the service is available, but if someone (a owner or moderator) doesn't have such, he can't be get under pressure to reveal real JIDs because he just can't see them. So here are my 2ยข for in regard to fully-anonymous rooms: - muc_fullyanonymous in service discovery is missing, - make a note about problems with fully-anonymous rooms, e.g how to ban someone without revealing his jid in the list of outcasts, how to remove an outcast if the outcast was done based on the nick only, possible solution: outcasts with a timeout). Besides removing outcasts, I think anything else could be handled through the use of nicks only. To not having the need to define how fully-anonymous rooms are handled, maybe the xep could just list the value 'none' for whois (no change needed), add muc_fullyanonymous to service discovery and say everything else in regard to how fully-anonymous rooms are handled (if supported) is implementation specific. Regards, Alexander
Re: [Standards] Microblogging: XEP-0277 and beyond
On 8/18/11 2:55 PM, "Justin Karneges" wrote: > I have a protocol flow for reliable pubsub that I've not yet publicized, but > essentially the idea is to include Result Set Management (XEP-0059) UID values > in pubsub event notifications. The client can then notice if it missed an > item > and use iq-get to catch up. > > Maybe this could go in some "RSM with PubSub" XEP that sorely needs to be > written. I like the direction you're heading with this. While we're at it, we need something similar for PEP that uses date/timestamps on implicit subscribes, since one implicit subscription goes to multiple publishing nodes, each of which have different RSM ids. The hope is that you could cache between sessions, and only receive PEP updates for things that have changed. This would be a huge win for XEP-292 PEP-based vCard, particularly if avatars are included. One thing we have going for us is that a re-publish of an existing item (by id) replaces the previous version, so a little bit of overlap between sessions is ok If there's any way to incorporate that into your thinking so we end up with a consistent design, it would be cool. -- Joe Hildebrand
