Hello,
Peter Saint-Andre wrote:
And then a section that talks about the id, how it's opaque to the
initiating entity, that any characters allowed in an XML attribute
may be used, it must not be reused, and that it has a max size of
say... 4k. If Mickael wants to encode his id as the full
On 3/13/09 1:58 AM, Mickael Remond wrote:
Hello,
Peter Saint-Andre wrote:
And then a section that talks about the id, how it's opaque to the
initiating entity, that any characters allowed in an XML attribute
may be used, it must not be reused, and that it has a max size of
say... 4k.
On 3/12/09 10:06 PM, Joe Hildebrand wrote:
On Mar 12, 2009, at 4:29 PM, Peter Saint-Andre wrote:
The phrase when the server gives stream features for resumption could
mean two things:
1. Whenever a server that supports stream resumption sends stream
features.
OR
2. When a server
Sorry, just catching up on the thread. An interesting discussion. :)
On 3/7/09 10:45 AM, Joe Hildebrand wrote:
On Mar 7, 2009, at 2:07 AM, Dave Cridland wrote:
On Sat Mar 7 00:49:30 2009, Joe Hildebrand wrote:
I actually think that moving stream management after the bind is a
good thing.
On 3/12/09 8:03 AM, Peter Saint-Andre wrote:
On 3/7/09 10:45 AM, Joe Hildebrand wrote:
On Mar 7, 2009, at 2:07 AM, Dave Cridland wrote:
On Sat Mar 7 00:49:30 2009, Joe Hildebrand wrote:
- When the server gives stream features for resumption, it MAY
include a hostname/IP and port on
On Mar 12, 2009, at 4:29 PM, Peter Saint-Andre wrote:
The phrase when the server gives stream features for resumption
could
mean two things:
1. Whenever a server that supports stream resumption sends stream
features.
OR
2. When a server sends stream features to an initiating entity
On Sat Mar 7 00:49:30 2009, Joe Hildebrand wrote:
I actually think that moving stream management after the bind is a
good thing. Much more flexible, and a relatively minor change.
I think moving sm-id generation - which is the real issue - until
after resumable sessions are enabled, and
Dave Cridland wrote:
On Fri Mar 6 06:39:19 2009, Curtis King wrote:
The xep needs some filling out or maybe be split into two separate
xeps. IMHO, resuming a session is only useful for C2S connections.
Why bother with S2S connections.
Resuming S2S sessions is mostly concerned with
On Mar 7, 2009, at 2:07 AM, Dave Cridland wrote:
On Sat Mar 7 00:49:30 2009, Joe Hildebrand wrote:
I actually think that moving stream management after the bind is a
good thing. Much more flexible, and a relatively minor change.
I think moving sm-id generation - which is the real issue -
On Fri Mar 6 06:39:19 2009, Curtis King wrote:
The xep needs some filling out or maybe be split into two separate
xeps. IMHO, resuming a session is only useful for C2S connections.
Why bother with S2S connections.
Resuming S2S sessions is mostly concerned with reliability, rather
than
By harcoding the node in sm-id, who is immutable during the session
you cannot move the session to the node the user is resuming the
session. It will not work on second resume.
We need the full jid but it seems we are alone, so I see no point in
fighting for that.
--
Mickaël Rémond
On Fri Mar 6 12:40:27 2009, Mickaël Rémond wrote:
By harcoding the node in sm-id, who is immutable during the session
you cannot move the session to the node the user is resuming the
session. It will not work on second resume.
Right, I see.
I'd actually thought that the sm-id you'd use
On Mar 6, 2009, at 12:40 PM, Mickaël Rémond wrote:
By harcoding the node in sm-id, who is immutable during the session
you cannot move the session to the node the user is resuming the
session.
So maybe this is the real problem.
If we allow a new sm-id to be set in the middle of a session
On Mar 5, 2009, at 5:11 PM, Dave Cridland wrote:
On Thu Mar 5 18:19:53 2009, Mickael Remond wrote:
So do we all agree that either way (using jid on resume or starting
stream management after bind), the XEP needs to be modified ?
Not on this basis, no.
I actually think that moving stream
Hi,
On Feb 27, 2009, at 1:50 PM, Mickael Remond wrote:
Dave Cridland wrote:
On Thu Feb 26 21:40:44 2009, Fabio Forno wrote:
On Thu, Feb 26, 2009 at 5:05 PM, Mickael Remond
mickael.rem...@process-one.net wrote:
With the JID you can simply reconnect to the existing running
session
without
Hello,
Pedro Melo wrote:
In my view, opaque is applied to the client point of view. I have no
problems that a field, generated by the server, and only used by the
same server (server here could mean a set of servers working together)
has some meaning to it.
I would imagine for example,
On 5-Mar-09, at 8:41 AM, Mickael Remond wrote:
So, you have to build another routing table at the implementation
level.
I have been given many reason why the sm-id was something sufficent
enough, but no reason explaining why requiring the full JID to
resume a
session was a bad design
On Thu Mar 5 17:16:44 2009, Curtis King wrote:
On 5-Mar-09, at 8:41 AM, Mickael Remond wrote:
So, you have to build another routing table at the implementation
level.
I have been given many reason why the sm-id was something sufficent
enough, but no reason explaining why requiring the
Hello,
Curtis King wrote:
On 5-Mar-09, at 8:41 AM, Mickael Remond wrote:
So, you have to build another routing table at the implementation
level.
I have been given many reason why the sm-id was something sufficent
enough, but no reason explaining why requiring the full JID to
resume
On 5-Mar-09, at 10:19 AM, Mickael Remond wrote:
resource conflict, using just the full jid would not handle this
situation. You need something else to make sure you are resuming the
correct session for the correct client. So, the id needs to-be
something opaque and non-deterministic to the
On 5-Mar-09, at 9:55 AM, Dave Cridland wrote:
XEP-0198 can restore a session after the server has noticed the TCP
session down, in principle, in which case the full_jid is
unroutable, and actually available for another session if one gets
there first - it's possible that in some cases, a
Hello Curtis,
Curtis King wrote:
On 5-Mar-09, at 10:19 AM, Mickael Remond wrote:
The resource conflict is still handled / enforced on opening new
session. And if the session you want to resume has been kicked due to
resource conflict, sm-id will not match, so your session resume will
not
On Thu Mar 5 18:19:53 2009, Mickael Remond wrote:
So do we all agree that either way (using jid on resume or starting
stream management after bind), the XEP needs to be modified ?
Not on this basis, no.
Sorry, I *knew* something was nagging me about all this...
We also need to deal with S2S
You seem to-be missing what I'm saying on both points,
On 5-Mar-09, at 12:29 PM, Mickael Remond wrote:
You need both full-jid and sm-id.
My previous post mention that full jid is needed for
routing (finding
the session) and sm-id is needed as access key.
The sm-id can include the full
On 28-Feb-09, at 11:49 AM, Justin Karneges wrote:
On Saturday 28 February 2009 10:59:57 Curtis King wrote:
On 28-Feb-09, at 6:10 AM, Mickael Remond wrote:
I still think requiring the full JID is the best approach as it maps
with how to locate a session in the server when sending a message
On 28-Feb-09, at 6:10 AM, Mickael Remond wrote:
I still think requiring the full JID is the best approach as it maps
with how to locate a session in the server when sending a message to a
client.
I think that an more reasonable requirement would be session
management can not be enabled
On Saturday 28 February 2009 10:59:57 Curtis King wrote:
On 28-Feb-09, at 6:10 AM, Mickael Remond wrote:
I still think requiring the full JID is the best approach as it maps
with how to locate a session in the server when sending a message to a
client.
I think that an more reasonable
On Thu, Feb 26, 2009 at 10:47 PM, Dave Cridland d...@cridland.net wrote:
Because the server chooses the sm-id, it can encode the full jid into it if
needs be.
Yep that was what I meant.
BTW: is there in same place (rfcs, xeps) a recommendation saying that
relying on a resource set by clients
Hello,
Dave Cridland wrote:
On Thu Feb 26 21:40:44 2009, Fabio Forno wrote:
On Thu, Feb 26, 2009 at 5:05 PM, Mickael Remond
mickael.rem...@process-one.net wrote:
With the JID you can simply reconnect to the existing running
session
without having another shared state. It makes a big
Hello,
Fabio Forno wrote:
Yep that was what I meant.
BTW: is there in same place (rfcs, xeps) a recommendation saying that
relying on a resource set by clients is a bad idea?
I am not sure I understand what you mean. The client is choosing the
resource. That's by definition a client
On Fri, Feb 27, 2009 at 2:51 PM, Mickael Remond
mickael.rem...@process-one.net wrote:
Yep that was what I meant.
BTW: is there in same place (rfcs, xeps) a recommendation saying that
relying on a resource set by clients is a bad idea?
I am not sure I understand what you mean. The client is
On Fri Feb 27 13:50:05 2009, Mickael Remond wrote:
My point was to avoid giving meaning to opaque data. Yes, we can do
that, but if it is a good practice and a usefull information for
several
server, I think we can expect the XEP to promote that.
No, I disagree, the sm-id is allocated by
Le 27 févr. 09 à 15:34, Dave Cridland a écrit :
No, I disagree, the sm-id is allocated by the server, the server can
put as much meaning into it as it wants. It's still opaque to the
client.
If the server's implementation means that it needs to have access to
the full jid, then it
Hello,
Dave Cridland wrote:
No, I disagree, the sm-id is allocated by the server, the server can
put as much meaning into it as it wants. It's still opaque to the
client.
If I read the spec correctly the stream feature packet that contains the
sm-id is send before the bind, right ?
So, you
On Fri Feb 27 15:41:39 2009, Mickael Remond wrote:
If I read the spec correctly the stream feature packet that
contains the
sm-id is send before the bind, right ?
So, you do not have the full JID (you miss the resource) at this
time
and as a result, cannot include it as a server in the
Hello,
As a follow-up of the latest XMPP summit in Brussels, we would like to
request a small but useful addition to XEP-0198.
The feedback is in session resumption:
Is it possible to require the client to pass the full JID of the session
being resumed ?
With the JID you can simply reconnect
On Thu, Feb 26, 2009 at 5:05 PM, Mickael Remond
mickael.rem...@process-one.net wrote:
Hello,
As a follow-up of the latest XMPP summit in Brussels, we would like to
request a small but useful addition to XEP-0198.
The feedback is in session resumption:
Is it possible to require the client
On Thu Feb 26 21:40:44 2009, Fabio Forno wrote:
On Thu, Feb 26, 2009 at 5:05 PM, Mickael Remond
mickael.rem...@process-one.net wrote:
With the JID you can simply reconnect to the existing running
session
without having another shared state. It makes a big difference
for large scale
38 matches
Mail list logo
