Exactly.
On 5/15/12 11:44 PM, Joe Hildebrand wrote:
That sounds fine to me. The real requirement is that the author is certain
that the field name is not going to collide with anyone else's field name
that might have a different meaning.
On 5/15/12 5:26 PM, Peter Saint-Andre
Thus I've checked in 1.2rc5:
http://xmpp.org/extensions/tmp/xep-0068-1.2.html
http://xmpp.org/extensions/diff/api/xep/0068/diff/1.1/vs/1.2rc5
http://xmpp.org/extensions/diff/api/xep/0068/diff/1.2rc4/vs/1.2rc5
(the diffs don't render yet, but should soon)
On 5/16/12 6:48 AM, Peter Saint-Andre
On Fri, 2012-05-11 at 09:42 -0600, Peter Saint-Andre wrote:
We do have a spec for Entity Time...
http://xmpp.org/extensions/xep-0202.html
Sorry, I had actually seen this, I should have referenced it in my first
mail. The problems I see with the XEP-0202 approach and the advantages
of adding a
From the original text, I think it's important to namespace, and I think it's
important to agree how a namespace is included in the field name. Precisely
how the namespace substring is formatted is less important; it can be a URI, a
URN, a Java reverse-domain, or something else.
On May 15,
On Wed, 2012-05-16 at 15:13 +0100, Jonny Lamb wrote:
How about: said new 'timezone' element in the XEP-0080 PEP node which
cross-references XEP-0202 in an attempt to keep them in sync?
You could also do this:
pubsub:publish node=../geoloc
item
geoloc:geoloc
lat/lon/
xep0202:time/
/...
Yay
The polling portion is easy. When you receive presence from a person, just
check there timezone using XEP-202. This is much less work then PEP.
Are you already using PEP (XEP-0163)? This is not something available by
default. Publishing GeoLocation is not mandatory with PEP either but just
On Wed, 2012-05-16 at 15:20 +, Todd Herman wrote:
Are you already using PEP (XEP-0163)? This is not something available
by default.
It's available on most popular and modern XMPP servers that I know of,
with gmail being the one exception.
(Sorry for the slight OT)
--
Kim Alvefur
On Wed, 2012-05-16 at 15:13 +0100, Jonny Lamb wrote:
will not work on Google's servers.
Btw, there are basically two solutions to this:
1) Work around it. (I.e. don't use PEP)
2) Get Google to add PEP support.
One of these is a real and long term solution. :)
--
Kim Alvefur z...@zash.se
PEP needs to be supported by the client, the side actually responsible for
publishing the information, to be of any use. Not all clients support PEP.
Also, most of the servers that support PEP (that I have seen) do not have it
active by default. That is what I meant.
-Original
I interpret that as follows.
OLD
The namespace of a field is assumed to be inherited from the
FORM_TYPE. When an organization or project defines a field that is used
in the context of a FORM_TYPE it does not manage (e.g., a non-XSF field
contained in a form whose FORM_TYPE is managed by the XSF,
On 5/16/12 8:13 AM, Jonny Lamb jonny.l...@collabora.co.uk wrote:
On Fri, 2012-05-11 at 09:42 -0600, Peter Saint-Andre wrote:
We do have a spec for Entity Time...
http://xmpp.org/extensions/xep-0202.html
Sorry, I had actually seen this, I should have referenced it in my first
mail. The
On Tue May 15 21:19:09 2012, Gunnar Hellström wrote:
1. I think it is quite common that the overhead in XMPP gets around
300 bytes per packet. (It might be 200 in some conditions.)
Where did this figure come from?
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
-
On Wed May 16 16:31:25 2012, Todd Herman wrote:
PEP needs to be supported by the client, the side actually
responsible for publishing the information, to be of any use. Not
all clients support PEP. Also, most of the servers that support
PEP (that I have seen) do not have it active by
Dave Cridland skrev 2012-05-16 21:45:
On Tue May 15 21:19:09 2012, Gunnar Hellström wrote:
1. I think it is quite common that the overhead in XMPP gets around
300 bytes per packet. (It might be 200 in some conditions.)
Where did this figure come from?
My own brief observations, mainly using
Version 0.5 of XEP-0268 (Incident Handling) has been released.
Abstract: This specification defines methods for incident reporting among XMPP
server deployments using the IODEF format produced by the IETF's INCH Working
Group.
Changelog: Simplified the processing model to send reports only in
On 5/16/12 4:49 PM, XMPP Extensions Editor wrote:
Version 0.5 of XEP-0268 (Incident Handling) has been released.
Abstract: This specification defines methods for incident reporting among
XMPP server deployments using the IODEF format produced by the IETF's INCH
Working Group.
Changelog:
16 matches
Mail list logo
