this is a priority in order to make
things work smoothly), since basically they need to issue multiple
roster requests and merge locally the rosters. If there is interest I
start writing a xep documenting the protocol
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
. These modifications
suit better the semantics of message stanzas, but we also accept that
we can miss receipts for messages which are actually delivered (just
to remember that when we need a prompt ack from an online resource iq
pubsub events work better).
--
Fabio Forno,
Bluendo srl http
be an incentive
for supporting presence subscriptions with the pubsub service.
bye
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
that's what Fabio is getting at.
Yep, last year we discussed several options for having some sort of
end to end flow control, and at the end the only working and simple
solution are IQs
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
and the client pulls their payload with IQs
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
Closing the Bytestream.
***
Because the changes are starting to become more significant, I've posted
an interim build here:
http://xmpp.org/extensions/tmp/xep-0047-1.3.html
Peter
--
Peter Saint-Andre
https://stpeter.im/
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id
of delivery and XEP 198
does not solve this).
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
must be turned on
- yep, it works just with presence subscriptions to the pubsub nodes,
but one of the features I usually miss in standard pubsub services for
real applications is a decent handling of presence subscriptions
--
Fabio Forno,
Ooros srl
jabber id: f...@jabber.bluendo.com
On Wed, Feb 17, 2010 at 4:25 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
***
I think it needs to be more specific about the error types, as you
suggest. So something like this:
***
It is also possible that the recipient might detect an error with the
data packet, e.g. because the
traffic.
When reopening a S2S connection it could happen that some IQs are lost
(noticed the problem with some servers) and still being able to retry
could be useful.
--
Fabio Forno,
Ooros srl
jabber id: f...@jabber.bluendo.com
method to understand which part of the message is
the real payload, and which part is just a fallback (usually a body
explaining why something has failed)
bye
--
Fabio Forno,
Ooros srl
jabber id: f...@jabber.bluendo.com
in paragraph 3.4, in the third bullet:
next/ and complete/ MUST not be used together.
bye
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
On Fri, Sep 25, 2009 at 11:38 AM, Dave Cridland d...@cridland.net wrote:
On Fri Sep 25 10:29:44 2009, Fabio Forno wrote:
Re-reading XEP-0050 for an implementation issue I've found nothing
that forbids sending the actions next/ and complete/ together.
Imho it is a nonsense and I think nobody
different persons showed up, so good luck!
;)
bye
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
talks about several related attacks, of which this one is probably the most
minor.
Just realized that I'm many messages behind in that thread, so ignore
my previous mail, I'm not adding entropy where there is already plenty
;)
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f
feedback for the infrastructure and even if the
council doesn't decide to accept them as XEPs I think that we could
provide some official space for discussion (e.g. more mailing lists?
;) )
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
. when
people really understand wave - I've still do 100% myself indeed ;) -
we'll see floods here)
bye
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
containing a binary value.
The great advantage of this format is that the type and the length of
each token is known in advance and no escaping is needed, therefore it
is possible to make very efficient parsers and serializers (in our
experiments 3x than normal xml serialization)
--
Fabio Forno,
Bluendo
On Sat, Sep 19, 2009 at 2:48 PM, Matthew Wild mwi...@gmail.com wrote:
Yep, jokes aside this is exactly the kind of thing I had in mind. :)
If anybody wants to experiment we have a python and a java
implementation, just ask... this is one those things that needs
feedback ;)
--
Fabio Forno
, for your use case, these are not the droids you are looking for.
I would stick with pubsub: a lot of people are working on it, so you will
probably find more good quality code for the server-side components.
+1
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
a
subdomain trusted and autoaccept all subscribe from that subdomain)
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
consideration about what is what we call a subdomain, but the correct
approach is indeed that. The protocol shall not have the concept of
subdomain, if somebody wants to consider something a subdomain for
configuration or application issue is free to do that.
--
Fabio Forno, Ph.D.
Bluendo srl http
are locally routed by most
servers even if there is no real address associated to them. Therefore
in general we think that they are something that exists only in the
server namespace
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
2009/9/10 Fabio Forno fabio.fo...@gmail.com:
Although the core XMPP technology defined in this specification does not
contain features to overcome this lack of reliability, XMPP extensions exist
to rectify this problem (for example [XEP-0198]).
I like this formulation
I don't know why
found (I wouldn't know how to avoid
it without parsing the inner xml)
Finally a question for server developers: where is the need of this
kind optimizations? Internal routing, c2s, s2s?
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
which is the real problem?
Just duplicated entries, which will be seen by the new client only,
and we can cope with them while merging the rosters and giving
precedence to the component's entries. The benefits are so high that
we can live with this little issue ;)
bye
--
Fabio Forno, Ph.D.
Bluendo
aesthetics
(and nobody forbids to use it privately, if you can't upgrade the
server)
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
their own roster to other clients? I'd
say no in the case, roster providers can be just domain jids.
bye
On Thu, Jul 16, 2009 at 12:11 PM, Fabio Fornofabio.fo...@gmail.com wrote:
On Thu, Jul 16, 2009 at 9:49 AM, Pedro Melom...@simplicidade.org wrote:
[...[
--
Fabio Forno, Ph.D.
Ooros srl
if e.g. I could share my roster with you?
I was just wondering if a client entity could be a roster provider for
a different client entity. I've no idea of possible applications, and
I'd forbid it, but perhaps it's just lack of vision ;)
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
:
iq type='get'
query xmlns='jabber:iq:roster' jid='k...@example.org'
foo xmlns='http://example.net/megaprotocol/'/
bar xmlns='http://example.net/otherthing/'/
/query
/iq
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
)
- the ability of handling multiple roster sources, as discussed in the
other thread in xep 144
The good thing of both is that they just add something that can be
ignored by unaware clients and servers.
--
Fabio Forno, Ph.D.
Bluendo srl
jabber id: f...@jabber.bluendo.com
for handling multiple sources the two namespaces are just a
temporary hack for allowing the messages pass through the server, but
the implementation is the same
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
, which are ugly as well,
but at least they are implemented
[1] I think that is one of the things where it is better to work in
private in small groups and start public discussion only when there is
a complete proposal
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f
requests with your favorite server codebases and I would bet they will
fix this before draft-ietf-xmpp-3921bis becomes an RFC. :)
What about clients that don't check the from, which is legit since
they trust the server? For them we introduce a temporary security
issue
--
Fabio Forno, Ph.D
into the server, is to directly tell the client
what to do.
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
nobody uses the same client for teh desktop or mobiles)
--
Fabio Forno, Ph.D.
Ooros srl
jabber id: f...@jabber.bluendo.com
is not
very usable, I think for the lack of testing since no transport is
using it)
- planning to use it, in that case any suggestion?
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
, so that we can compare the result with the contacts we have in
the roster and detect deletions too; as you say this can be done with
an ad hoc command too, in that case I'd like to write an example in
the xep in order to document the practice.
bye
--
Fabio Forno, Ph.D.
Bluendo srl http
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
send an ad hoc
command containing the block of roster commands that the client
should apply, ad we wait for the list of accepted commands as result
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
already started many times, but what do we define
as a conversation?
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
On Tue, Jun 2, 2009 at 10:20 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
OK. Feel free to work on the spec. I can give you SVN access. :)
Aye sir!
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
to the
sender after the user has processed the additions would solve the
problem (we just need a session-id for linking the this notification
to the triggering first request).
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
been established but no compression
has been activated. I see no harm in telling that stream compression
MAY be offered after TLS if TLS doesn't succeed in activating
compression (so far we haven't been able to to it with any server)
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber
On Thu, Apr 30, 2009 at 10:16 PM, Fabio Forno fabio.fo...@gmail.com wrote:
I've just a problem with the business rules, specifically these ones
# TLS compression and stream compression SHOULD NOT be used simultaneously.
# If both TLS (whether including TLS compression or not) and stream
(bootstrap=true?) rather than overload 'ver'.
Sorry but I don't get the purpose of this. Isn't sufficient to omit
ver for bootstrapping?
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
, not the last full roster update). That kind of thing
is great but IMHO it doesn't really belong in an RFC.
+1
In fact in our implementation based on the current xep we haven't seen
any real issue that can't be dealt with good heuristics
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber
and I don't want to use their ugly chat,
but my real JID and I don't want to give away my password)
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
and doing a bit of group and rule name standardization as
for dataforms could solve many of the problems with them.
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
On Thu, Apr 9, 2009 at 1:08 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
In fact I suppose someday
(not anytime soon!) some people might want to get rid of resource
entirely, but that'll happen in XMPP 2.0 after I've retired. :)
we are already discouraging them with eco xmpp :D
--
Fabio
always interpreted that as the null resource (while
just / should be the resource with length zero) and treated it as if
it were a XMPP entity.
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
packets (When throttling it makes sense to reduce it)
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
is
terrific for automatically adding/changing services accordingly to the
user context. Tomorrow or in the next days we can catchup via jabber
for exchanging ideas. Now it's 2am here, better go to bed ;)
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
like the JID give up
Day, in which users unregister from servers and uninstall their
favorite client ;)
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
On Tue, Mar 31, 2009 at 7:40 AM, Curtis King ck...@mumbo.ca wrote:
time makes a bad counter as it can go backwards and there are resolution
issues ;-)
[...]
+1
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
/2009-March/021409.html) we
saw that r/ stanzas after the regular ones could lead to some lack
of reliability, while it's better to just count stanzas and send back
a/ acks
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
the initial presence burst would
take tens of seconds in a mobile connection, having to wait for all
the acks)
bye
--
Fabio Forno, Ph.D.
Ooros srl
jabber id: f...@jabber.bluendo.com
of packets
must be acked one by one
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
all the 3 messages, while any number of them could
have been already processed and delivered to the correct recipient. If
the message itself contained the sequence number the server would be
able to discard duplicates.
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f
, and everything is bound to an
implicit sequence number bound to stanza count. It seems to work, the
only thing to decide is whether to count r a stanzas ;)
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
On Tue, Mar 31, 2009 at 6:27 PM, Fabio Forno fabio.fo...@gmail.com wrote:
Ok, so the r/ just triggers an ack, and everything is bound to an
implicit sequence number bound to stanza count. It seems to work, the
only thing to decide is whether to count r a stanzas ;)
Just realized: the max
On Tue, Mar 31, 2009 at 6:29 PM, Dave Cridland d...@cridland.net wrote:
Technically speaking, those aren't stanzas, which might answer the question.
And it confirms what I had in mind ;)
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
an event notification, otherwise it does nothing, avoiding
sending redundant data.
--
Fabio Forno, Ph.D.
Ooros srl
jabber id: f...@jabber.bluendo.com
)
--
Fabio Forno, Ph.D.
Ooros srl
jabber id: f...@jabber.bluendo.com
the 80% of the contacts must have changes avatar,
while in the normal situations (no avatar changed) I save the 80% of
the traffic
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
On Fri, Mar 20, 2009 at 1:22 AM, Fabio Forno fabio.fo...@gmail.com wrote:
Of course, I still question the need for 'u' at all if we're doing it like
this.
Now I remember: for limiting latency it's better to allow a window of
unacked stanzas (on slow mobile connections each roundtrip can
the following ack aren't atomically processed.
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
On Thu, Mar 19, 2009 at 11:21 PM, Fabio Forno fabio.fo...@gmail.com wrote:
I see one issue for perfect stream reliability: stanza suplication. An
example:
duplication of course ;)
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
the work)?
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
seconds)
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
VIPs group we must either put them temporarily in the VIPs group or
unset the privacy list, and I don't know if there ar workarounds for
this (but a service with which we can poke the presence of somebody
using an iq/
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f
, since the usual
pattern is browsing new data, not receiving some information that
usually has no or few chages. So I go for #1
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
with it?)
Besides that there is one more reference we are starting using: RFID
addresses, which allow to pinpoint the exact position of the device.
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
this should be general enough:
typerfid/type
ididscheme:id/id
(need to do some more research for confirming)
--
Fabio Forno, Ph.D.
Ooros srl
jabber id: f...@jabber.bluendo.com
was about to ask the same thing.
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
hundreds of
thousands of s2s connection, so let's face it! ;))
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
.
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
, and in a separate iq you set on/off
toggles for each group, at any time of the session.
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
is a bad idea?
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
it with a resource identifier that the server
generates; in this case, the server SHOULD NOT return a stanza error
(e.g., forbidden/) to the client but instead SHOULD communicate the
generated resource identifier to the client in the IQ result as shown
above
--
Fabio Forno, Ph.D.
Bluendo srl http
-long-sm-id'/
Do you mean using the full jid instead of the previd or in addition?
If it's just the jid it can work only if the server sets a resource
with some random data, otherwise it becomes extremely easy to hijack a
sesssion
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id
possible large item sets are
better handled by xep-59, which is more suitable for browsing
(disco#items included, but for pubsub nodes)
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
On Thu, Feb 19, 2009 at 10:45 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
I don't think the bandwidth difference is that big here, but I like the
idea of putting it in rfc3921bis so that more people implement it. ;-)
Evil plan! I wasn't considering this aspect: definitely there!
--
Fabio
Is the Oauth signature in xep 235 actually calculated with the given
values (and all escaping correct)? I'm trying to implement it and I
get different values, while I can reproduce the sign of main oauth
specs
Besides fireeagle are there any other services for testing it?
--
ff
: 9PQkM4YKgaM067wqrDGshXOwDW0=
Escaped signature: 9PQkM4YKgaM067wqrDGshXOwDW0%3D
I hope this helps.
seth
sure, thanks!
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
gems
thanks
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
and which not
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
the stanza (i.e., neither deliver it nor return
an error) if it is a presence stanza, (b) MUST return a
service-unavailable/ stanza error to the sender if it is an IQ
stanza, and (c) SHOULD treat the stanza as if it were addressed to
[EMAIL PROTECTED] if it is a message stanza.
--
Fabio Forno, Ph.D
of the form [EMAIL PROTECTED].
- 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.
bye
--
Fabio Forno, Ph.D.
Bluendo srl http
On Mon, Oct 20, 2008 at 6:16 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
I think that's a spec bug:
s/available/connected/
I think so. For me it makes more sense if in points 1 3 of paragrah
11 we use connected (after that I can start filing tickets across
the different server
if the
resource belongs to a connected user, even if not online. In this way
clients could perform some iq/ queries to well known services before
going online, thus eliminating one of the few useful cases for
invisibility
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: [EMAIL PROTECTED]
be overcome someway, but of
general stream behavior. Although if you find a way to send processing
instructions, sooner or later you'll need a way for sending chunks of
documents and this is easily done using bytestreams (also in band)
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
On Wed, Oct 8, 2008 at 12:20 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Fabio Forno wrote:
(sorry for the delays, but in the last two days of many standards_ml
mails went into the spam folder :( )
Hopefully I just put an end to that!
I think the problem comes mainly from the google talk
of privacy lists
to mere mortals.
I'd stay with the privacy list approach and discuss better ways for
setting them.
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: [EMAIL PROTECTED]
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: [EMAIL PROTECTED]
the case when the receiving server has more
restrictive policies about IBB than the sending one or the receiving
client is too slow, forcing to buffer a large number of packets.
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: [EMAIL PROTECTED]
On Wed, Jun 11, 2008 at 5:24 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
I don't know if existing clients and servers are that smart, but it
They will be if people discover that IBB is so good in passing through
firewalls.
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id
then a fixed bitrate, since it allows
severs to dynamically allocate bandwidth accordingly to actual usage.
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: [EMAIL PROTECTED]
1 - 100 of 152 matches
Mail list logo
