Not exactly - you still don't know whether you have received all
initial presences yet or if there are still initial presences to come.
Why do you need to know that?
Rich
I am, but that isn't the problem, as the connection is hardly at 100%
use. There's only little traffic. All other services are not affected
when I sign in, so this isn't the problem, as they would suffer from
insufficent bandwidth as well if it's the ejabberd eating all the
bandwidth.
Just be
Those are not really network issues, but protocol issues: When I sign
in, about 50 s2s connections need to be opened - and TLS needs to be
negotiated on a lot of them. As my TLS key is 4096 bits RSA, this can
take quite a while. IMO this is a protocol problem, because s2s links
are clossed to
Even if it is fixed in my server, the problem still exists if every
other server still closes the connection after 10 minutes. I think
some standarization here would help.
I don't see why a config/policy issue needs standardising, its entirely
up to the server administrator to set their own
Well, basically, it's two problems: The spam of popups when you log in
and the delayed presence.
We've already found that there isn't a spam popup problem if your client
implements long established protocols (jabber:x:delay) correctly.
The real problem with the presence flood is that they come
Yes, similar, except I'd like to hang extra elements off it, instead
of extra attributes.
Surely you can just namespace an element then instead of just an
attribute to accomplish that? As far as I can see whether its an
attribute or an element is just semantics, as long as its appropriately
I don't need a new protocol actually. I would like to have the ability
to add extra namespaced nodes to each , that would solve all my
pet peeves with roster entries.
Like how Google Talk works?
http://code.google.com/apis/talk/jep_extensions/roster_attributes.html
The way google does it woul
btw, smart implementations (jabberd) stamp the reply to presence
probes with jabber:x:delay so that a client can tell the difference
between a contact thatbecomes available and one that is available.
Which still does not solve the presence flood.
Yes it does, if its stamped with jabb
Maciek Niedzielski wrote:
JabberForum wrote:
I am not sure to understand all what you say... but probably is it
because of my flawed English. But from what I think to understand, this
is exactly what I say: currently the client does not announce pubsub
support (or any support of anything at all)
B) RTT delays
The introduction of Stanza Repeaters gives us RTT delays whenever a
list needs changing. That just strikes me as worrying - I don't think
anyone has clear figures on how much delay would be introduced, but
I'm sure you'll agree that additional latency does not a performance
im
Since pretty much everyone considers privacy lists a not so successful
invention, I don't think IESG would object a lot if we were to say
"We've been there, we wore that t-shirt, it didn't look good."
Who were they? I must have missed those messages on this list.
The IESG would certainly under
The repeaters concept doesn't solve the privacy list interactions
either.
Why not? For each list of folks that a server wants to send presence
to, it creates a list. If that list has different people on it for
different reasons, it creates different lists. In the case of
presence, the se
Did you reread the smart unicast (I still prefer version 0.0.3 version
- http://smarticast.psyced.org/jep-smart-presence.html, but the 0.0.4
version in the editors inbox has it's merits, too) and
address-lists (http://www.xmpp.org/extensions/inbox/address-lists.html)
proposals and the reasons why
Very funny. :P
We use messages there in part because using IQs would require knowing
the full JID (and stock pubsub services do not know that).
But that's neither here nor there. The question is whether:
(1) acking an occasional roster push from the server to the client
(where BTW the server
Thanks for taking the time for the explanation, whilst I still think it
would be advantageous for clients to not gage any meaning from the
version ids (or whatever we are now going to call them) and just leave
all the logic to the server to deal with, i'm not too bothered as to
what format they
A few hours of testing does not a reliable protocol make. Under what
conditions? Is this a public server that people can test against?
No you are correct, but even so the tone of some of the messages on this
subject as far as I read them said that it wouldn't work, and under my
limited test
Peter Saint-Andre wrote:
Alexander Gnauck wrote:
Peter Saint-Andre schrieb:
Here is revised text:
The value of the 'version' attribute SHOULD be a non-negative
integer representing a strictly increasing sequence number that
is increased with any change to the roster (whether or not th
You can't use timestamps - they're not strictly increasing, for
various reasons.
Why does it need to be strictly increasing? As already explained the
version identifiers should IMO be opaque and just be a server
implementation issue, I still can't see any reason why this needs to be
set in st
yes I think we should recommend a an increasing integer. But should
allow any string. So if some server vendor prefers hash codes or GUIDs
for the versioning then this is fine for me too.
Exactly.
Sometimes flexibility comes back to bite you. I'd prefer to keep things
simple if we can. What
+1. I can't see any reason for the spec to require more than a
increasing version number.
I would prefer if it were just an opaque string, certainly as far as the
client in concerned there is no need for it to do anything other than
store the most recent version identifier it has received and
I wrote timestamps in my other mail, but any strictly growing sequence
of number is fine
I think it would be better for implementation flexibility/ease for the
timestamp/version number to be opaque as far as the client in concerned,
only the server needs to understand how to interpret it.
Ri
Maciek Niedzielski wrote:
Richard Dobson pisze:
Extended disco would probably be a good place for the language(s) if
you are wanting to associate it with the user I would have thought.
Disco? If I can speak 3 Arabic dialects (to use Boyd's example),
advertising this in my disco won'
Boyd Fletcher wrote:
but wouldn’t that add additional overhead to make more queries and it
would require more code changes in the clients.
Not really no, clients will already support disco so no massive code
changes, and if the client support caps too they will already have
queried this informa
Fletcher, Boyd C. CIV US USJFCOM JFL J9935 wrote:
I think the idea of associating lang with contact is a good one and we
essentially do that in transverse. We sound out presence msgs with xml:lang
tags and transverse uses that to determine in which language the client should
respond.
We would
agree, my point of view is just that binary xml is not the only issue
with mobile terminals, there is a wider set of problems to be
considered for optimizing the connection (some such as stanza
acknowledgments are already there, though I don't know how many
servers handle them, others such as li
Tomasz Sterna wrote:
Dnia 2008-02-08, Pt o godzinie 20:54 +, Richard Dobson pisze:
But surely in those cases the JIDs would be something like:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
What I _really_ don't like with it, is mapping one namespace to many
namespaces in
It depends on which SMS gateway is provided by your mobile operator and
and who operates the number you're trying to reach. And yes, it's mostly
about money and other limits that mobile operators have in their gateways.
(So for example, if my phone is operated by operator A, and I'm trying
to se
Peter Saint-Andre wrote:
Lauri Kaila wrote:
A small note. When there already is a session, instead of normal IBB,
the payload could be carried inside info-messages. Maybe not a good
idea, but possible.
I hadn't considered that. Yes, it's possible. I was trying to keep
Jingle File Transfer as c
Well, then the XEP should say something about that or even better that
this protocol should be used instead of XEP-0092 since it's generally
bad to have two standards with the same or nearly the same purpose. In
the end the target of a standardization organization is to have just
one protocol fo
Kevin Smith wrote:
On Jan 22, 2008 6:02 AM, Tobias Markmann <[EMAIL PROTECTED]> wrote:
URL: http://www.xmpp.org/extensions/inbox/clientinfo.html
What are the enhancements of this XEP compared to XEP-0092? Why should
one implement this XEP and not XEP-0092? Since both XEPs seem to do
t
How does the browser know what to do with a realm that is an XMPP URI?
Is there a browser plugin that passes that off to a Jabber client so it
can send the token request to the agent?
If you are writing a browser plugin surely its better to use a custom
auth scheme so its not quite so hacky, a
Alternative option is to define new HTTP auth scheme. This is probably
the "right" way to go, but... it *requires* browser support, as there
will be no backward compatible mode.
Yet another alternative is to change protocol flow:
1. server sends you auth agent JID (and only this) as realm
2. u
But surely in that case then you have the tooltip appear immediately
saying "Requesting..." which changes to the client version once its
received.
It did, and I still got the bug report from six different people. I'm
not necessarily saying this is the wrong way to do it, but sharing a
data
save that much
bandwidth if we send all the information all the time instead of
sending it
as an answer to iq:version flood? The flood at least can be aimed
only at
contacts triggered by the user's interest (like showing tooltip,
getting user
info, opening the conversation window,...). I actu
Do you have any opinion on the disco for individual games?
I see basically three ways to do it:
1. include games in normal disco as feature
2. use info/item nodes in normal disco
3. some "own" third way, as we did
Number 1 could blow up the disco response considerably, while Number 2
and 3 all
Some notes to slightly enhance the protocol, rather than doing the
following:
[EMAIL
PROTECTED]@capulet.com-checkers-1591-02-21T12:56:15Z-1234
You have been invited to a game of Checkers by
[EMAIL PROTECTED]
Hello Juliet,
would you like to play a little game
But you do not need to change MUC, it is much easier done with letting
MUC be the same and just add something, then redefining the protocol and
duplicating the work.
I never said MUC needed changing.
You can use standard MUC and RPC, you just need another "player" who
plays the "doom" of the g
That will only work if you trust each party to follow the same set of rules
governing the game and not to make invalid moves/cheat, it is far better to
have a third party (i.e. a gaming server, or maybe one of the participants)
receiving all the moves and verifying them before distributing them
Andrew Plotkin wrote:
On Sat, 12 Jan 2008, Michal 'vorner' Vaner wrote:
On Sat, Jan 12, 2008 at 12:21:43AM +0100, Torsten Grote wrote:
we concentrate on One-to-One gaming, since MUG will need server support.
Is it really needed? A gaming support on server? Couldn't this be done
trough ordina
What's going on with XEP-101: HTTP Authentication Using Jabber
Tickets[2]? It's "Deferred", yet it seems to, more or less, do the
same thing in a better fashion.
Although the HTTP client needs to support a new authentication method,
this seems closer to the ideal. But the authentication
This is fine, but will never get traction in the larger population. If
you want users on IE6 (30% of web traffic) to be able to authenticate
to your application using xmpp, then you need to find a methodology
that works across browsers. (not only that but I'm a bit leary of web
technologies that
I don't see an attribute 'cid' in the HTML/XHTML specs.
Yea its a MIME multipart/related thing rather than HTML specifically.
Richard
Have a look at the following XEP which I worked on in the past:
http://www.xmpp.org/extensions/xep-0101.html
If I am getting what you are trying to do correctly I think this is the
sort of thing you might be after.
Ever tried to get FTP protocol through FW/NAT?
It requires protocol level command channel tracking, to find out related
data channels and let them in.
Special handling, special modules, special setup - ergo: nobody bothers.
Well as has been already pointed out by Dave what you are talking abo
Tomasz Sterna wrote:
Dnia 05-11-2007, Pn o godzinie 16:24 +, Richard Dobson pisze:
Personally I think it would be better to do as someone already
suggested
and have a separate connection for framed blobs that you maintain or
establish when needed to send those
And repeat the FTP
You do not want to use 65 too much. If I skip the fact it is going to
get deprecated by jingle, probably, it is really heavy for small blobs,
like an icon or a funny image in a message. (Of course, it is the right
way for 1GB file you want to send).
Jingle doesnt depreciate XEP-0065 as far as I
I strongly suspect, given the way the discussion is going, that we
either have to consider framing everything - and that's a huge break
from XMPP - or else we need an escape mechanism that works. Or, of
course, we decide to give up and frame using XML as now, and use
base64 to cope.
Personall
The XML in this doesnt really look very valid with regard to the various
prefixes in it as the prefix namespaces dont appear to have been
defined, it is also trying to reuse the stream prefix which will already
be used in the stream which seems dangerous.
Or:
- company policy forbids p2p file transfer
- server-side virus checking desired/required before download
It is difficult to define consistent requirements for consumer-oriented
services on the open internet and employee-oriented services within
enterprise deployments.
Virus scanning coul
Tobias Markmann wrote:
I use if for direct file transfers of big files too because the
BitTorrent clients are able to continue abort transfers and validate
the transferred data via hashs. As far as I know none of the protocols
listed in the proposed XEP support continue abort/paused transfers b
Some sort of reputation system (XMPP.net federation?) would probably be
handy here so that people coming from previously unheard of domains or
blacklisted ones cannot add new rooms.
Like this?
https://stpeter.im/?p=1988
Yes that sort of thing, we just need to move forward with it.
Open user registration is something else - you're effectively allowing
someone to create a new identity there. (I don't think "CAPTCHA" is the
way forward here either). I think that's the root cause, here.
I don't think CAPTCHAs will really solve the problem, which so far is
not botnets but poor
And why should we put the version number in the node ?
If it is to substitute the XEP-0092, I think it's the wrong way. (Because it
break compatibility with xep-0115 1.3 (if the capabilities doesn't change
between versions 1.3.4b to 1.3.4c)
Personally I think the client version informati
Joe Hildebrand wrote:
As an aside to the discussion on priority ties, I think it would be
cool for us to have a defined mechanism for sending messages to all
online (non-negative priority) resources. Message type='headline' has
never been fully exploited, nor terribly well-described, and I pro
It's unclear exactly what you mean. You want a Jingle method as one
option in stream initiation, like this?
Not quite, it would be more like this:
urn:xmpp:jingle:bytestreams
http://jabber.org/protocol/bytest
Peter Saint-Andre wrote:
Richard Dobson wrote:
No, it would work the other way around -- it enables you to re-use your
existing SOCK5 and IBB code, but for the negotiation you'd use Jingle
instead of SI.
Ah I see, I thought so, I was suggesting doing things the other way
around which wou
No, it would work the other way around -- it enables you to re-use your
existing SOCK5 and IBB code, but for the negotiation you'd use Jingle
instead of SI.
Ah I see, I thought so, I was suggesting doing things the other way
around which would be far more backwards compatible as you wouldnt nee
Peter Saint-Andre wrote:
Richard Dobson wrote:
jingle bytestream
-
When we come to implement file transfer using jingle I would suggest
that rather than creating a brand new backwards incompatible file
transfer protocol that we simply implement a new jingle bytestream
transport just like
Yes, but (certainly on my phone) it cuts the GPRS while you do so.
Fair enough, mine doesn't, must be a limitation either with your handset
or your network provider (I would expect its just the handset trying to
maximize battery life and radio usage, as you arn't entirely likely to
be needing
I digress, but... you cannot surf and call on GPRS at the same time,
generally. This is why if someone calls a GSM phone while you are
loading a webpage, they will generally go straight to voicemail.
Just to correct you here but they wont goto voicemail (if you are
connected to WAP using a di
Remko Tronçon wrote:
This would likely be either
- explicit statement in all xeps that define a feature that the client
shouldn't trust caps (complex to maintain, simple to implement)
- an extension to caps to say "maybe supported, query disco to know for
sure". (complicates caps, add
I think there might be a point in this. Basicly i expect a caps capable
client to completely ignore disco (outside of the caps usage) for a contact
that does caps. So if some feature is not in caps i'd assume the client
doesn't have that feature, unless a) the xep specifies (explicitly!) that
ca
Maybe we should think of extending Caps to allow publishing different
capabilities to different contacts.
Yea maybe, but we need to find a reason for it first, certainly in this
case its not needed as in normal real world use people are just going to
have it globally on or off, they arnt
Unfortunately, no. I wouldn't like everyone in my roster to be able to
shake my client window. Instead I would like to implement a sort of
white list for this. And it's hard to represent in XEP-0115 hash that
somone is allowed to ask an attention query and others aren't.
In that case you wo
The message IS backwards compatible!
It is not, since no tag is included. It will be
when stanza looks like:
This is *not* a joke ;-)
This is not a joke ;-)
http://notajoke.org
Or something like this.
Also since the text element is not namespaced technically its illegal in
It is since you cannot uniquely separate the JID into its
node+domain+resource parts.
You cannot tell which the node part is. In my example
User JID: [EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/coci
the node part may be: mats\40home.se\2fcoci\40home.se\2fmats
The problem is escaping
But then the XEP is wrong since it includes the "/" character to be
escaped.
No its not, it is specifying escaping of the node portion of the JID, it
specifically says you must not escape the resource.
Richard
The key is that it is impossible to identify the "real" "@".
Any thoughts?
This was already discussed at length on either this list or might have
been jdev a few weeks ago, your first way is the only valid one as
everything after the first / is the resource pretty much no matter what
it cont
Yes, it is a good idea to define more granular errors for these
conditions. I'll try to add those to the -04 draft, since I will
probably submit the -03 draft today and won't have time to do this
(mostly today I'm just going to check for egregious errors). The reason
for the hurry is that there'
In my working copy of rfc3921bis I have:
***
The server SHOULD return a error to the client if the
roster set violates any of the following rules:
1. The element MAY contain a 'name' attribute, but the value
of the 'name' attribute SHOULD NOT be more than 1023 characters
The server needs these limits in order to figure out how to size
database tables, so there exists a reason. Given that constraint,
there are two paths to go down:
1) specify a maximum length
2) specify a way for the client to find out the maximum length
either way, you need to specify what h
If user1 is able to break my communications with user2 (by fooling my
client with incorrect capabilities) without requiring of my approval I
would call this a security issue.
Yes I know, but personally I dont think its a true security issue, I
would only truely call it a security issue if it al
Personally I think the easiest solution to the percieved "security"
issue (personally im not conviced you can really call it a true security
issue) is if you are going to create a long lived cache (i.e. on disk or
such like) that before you decide on your definative value to cache
generically (
73 matches
Mail list logo
