[vysper] initiating entity after resource binding

[Gerolf Seitz]

hi bernd,

in certain situations (eg probing presence information after initial
presence, see RFC3921:5.1.1)
it's necessary to get hold of the full JID. unfortunately it isn't provided
in the intial presence stanza
sent from the client.

while the resource is bound to the session in
AbstractSessionContext#bindResource, it's not stored anywhere,
so i was wondering whether #bindResource should reset the initiatingEntity
field to represent the full JID.

i saw the methods ResourceRegistry#getBoundResources, but this seems to be
too much effort to
finally get the resource identifier.

how about resetting the initialEntity field in
AbstractSessionContext#bindResource ?
(yes, next time i'll ask before committing :/ )

Cheers,
  Gerolf

[Bernd Fondermann-2]

On Sun, Apr 20, 2008 at 12:59 AM, Gerolf Seitz <gerolf.seitz@...> wrote:

> hi bernd,
>
>  in certain situations (eg probing presence information after initial
>  presence, see RFC3921:5.1.1)
>  it's necessary to get hold of the full JID. unfortunately it isn't provided
>  in the intial presence stanza
>  sent from the client.
>
>  while the resource is bound to the session in
>  AbstractSessionContext#bindResource, it's not stored anywhere,

it is stored, but not directly in the session.

>  so i was wondering whether #bindResource should reset the initiatingEntity
>  field to represent the full JID.

no, because a session is not restricted to one bound resource!

>  i saw the methods ResourceRegistry#getBoundResources, but this seems to be
>  too much effort to
>  finally get the resource identifier.

can we make it less effort without storing this information twice?
where there is a SessionContext, there is the Resource Registry, too,
via ServerContext.

>  how about resetting the initialEntity field in
>  AbstractSessionContext#bindResource ?
>  (yes, next time i'll ask before committing :/ )

bad idea, I think, since it might gets overwritten from a second
resource binding.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Gerolf Seitz]

you're right. that was stupid.
for now, i reverted the change and i will think about something.

regards,
  Gerolf

On Sun, Apr 20, 2008 at 8:00 AM, Bernd Fondermann <
bernd.fondermann@...> wrote:

> On Sun, Apr 20, 2008 at 12:59 AM, Gerolf Seitz <gerolf.seitz@...>
> wrote:
> > hi bernd,
> >
> >  in certain situations (eg probing presence information after initial
> >  presence, see RFC3921:5.1.1)
> >  it's necessary to get hold of the full JID. unfortunately it isn't
> provided
> >  in the intial presence stanza
> >  sent from the client.
> >
> >  while the resource is bound to the session in
> >  AbstractSessionContext#bindResource, it's not stored anywhere,
>
> it is stored, but not directly in the session.
>
> >  so i was wondering whether #bindResource should reset the
> initiatingEntity
> >  field to represent the full JID.
>
> no, because a session is not restricted to one bound resource!
>
> >  i saw the methods ResourceRegistry#getBoundResources, but this seems to
> be
> >  too much effort to
> >  finally get the resource identifier.
>
> can we make it less effort without storing this information twice?
> where there is a SessionContext, there is the Resource Registry, too,
> via ServerContext.
>
> >  how about resetting the initialEntity field in
> >  AbstractSessionContext#bindResource ?
> >  (yes, next time i'll ask before committing :/ )
>
> bad idea, I think, since it might gets overwritten from a second
> resource binding.
>
>  Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@...
> For additional commands, e-mail: labs-help@...
>
>

[Bernd Fondermann]

Gerolf Seitz wrote:
> you're right. that was stupid.

No, it wasn't. I should really have included a comment why the returned
resource is not used by the session.

> for now, i reverted the change and i will think about something.

I think the best is to use ResourceRegistry. I post separately about the
original problem.

   Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Bernd Fondermann]

Gerolf Seitz wrote:
> hi bernd,
>
> in certain situations (eg probing presence information after initial
> presence, see RFC3921:5.1.1)
> it's necessary to get hold of the full JID. unfortunately it isn't provided
> in the intial presence stanza
> sent from the client.

If a session is bound to more than one resource, how could we determine
which one to process with?

I quickly scanned 5.1.1 and it mentions the full jid.

Side-note: At any time, if there is something ambigious in the rfcs, I
recommend consulting dev@... mailing list or the most current
BIS-revision of the RFC, for example at
http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-04.html#roster
The BIS-process is due to replace RFC by newer RFC. The BIS docs have a
clearer structure and more examples.

Proposal: If the client does not send full JID (FJID), then we check the
session for a unique resource id. If there is not exactly one, we return
a stanza error. Else, we proceed with the FJID we determined.


   Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Gerolf Seitz]

hi Bernd,

If a session is bound to more than one resource, how could we determine
> which one to process with?


well, there are some places that use the initiating entity, and since we can
get the bare jid from a full jid,
i thought it wouldn't hurt to update the initiating entity to reflect the
first bound resource. and some guys from
jdev@... confirmed that too (though that's nothing
official).

>
> I quickly scanned 5.1.1 and it mentions the full jid.
>
> Side-note: At any time, if there is something ambigious in the rfcs, I
> recommend consulting dev@... mailing list or the most current
> BIS-revision of the RFC, for example at
>
> http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-04.html#roster
> The BIS-process is due to replace RFC by newer RFC. The BIS docs have a
> clearer structure and more examples.

thanks, that's good to know, because there are quite some places where the
RFC is not clear or gives room for interpretation.


> Proposal: If the client does not send full JID (FJID), then we check the
> session for a unique resource id. If there is not exactly one, we return a
> stanza error. Else, we proceed with the FJID we determined.
>

hm, i kinda really only want to return a stanza error when the rfc states to
do so.

as for the presence probing:
the rfc states that only the first ressource in a session should to that,
because all subsequent resource can use the presence information gathered
for the first bound resource. (sry, a bit off topic).



so, are you okay with something like this? (pseudocode)
String resId = bindResource(this);
if (resourcesForSession == 1) {
  modifyInitialEntity(resId);
}
return resId;


Regards,
  Gerolf

[Bernd Fondermann]

Gerolf Seitz wrote:

> hi Bernd,
>
> If a session is bound to more than one resource, how could we determine
>> which one to process with?
>
>
> well, there are some places that use the initiating entity, and since we can
> get the bare jid from a full jid,
> i thought it wouldn't hurt to update the initiating entity to reflect the
> first bound resource. and some guys from
> jdev@... confirmed that too (though that's nothing
> official).

but then we'd have to (remember to) strip the resource from the entity
everytime we do explicitly not need the resource.

we'd have to also incorporate the ugly logic of removing the resource on
  unbind and re-adding reasonable other one.

>> Proposal: If the client does not send full JID (FJID), then we check the
>> session for a unique resource id. If there is not exactly one, we return a
>> stanza error. Else, we proceed with the FJID we determined.
>>
>
> hm, i kinda really only want to return a stanza error when the rfc states to
> do so.

+1

> as for the presence probing:
> the rfc states that only the first ressource in a session should to that,
> because all subsequent resource can use the presence information gathered
> for the first bound resource. (sry, a bit off topic).

so this boils down to that essentially any resource can be used for that
but that the canonical choice is the first (and in most cases probably:
the only) resource.

> so, are you okay with something like this? (pseudocode)
> String resId = bindResource(this);
> if (resourcesForSession == 1) {
>   modifyInitialEntity(resId);
> }
> return resId;

against my initial opinion I am coming to the conclusion that we should
keep a list of bound resources in the session.
this is either with or without using modifyInitialEntity(resId). the
latter should be decided, IMHO, by what we need more often: bare or full
jid.

   Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...