#6295 HIGH Update.: try opportunistic registration if authentication fails

[Zarro Boogs per Child]

#6295: try opportunistic registration if authentication fails
-------------------------------+--------------------------------------------
  Reporter:  robot101          |       Owner:  ApprovalForUpdate
      Type:  defect            |      Status:  new              
  Priority:  high              |   Milestone:  Update.1         
 Component:  presence-service  |     Version:                   
Resolution:                    |    Keywords:  Update.1?        
  Verified:  0                 |    Blocking:                   
 Blockedby:                    |  
-------------------------------+--------------------------------------------

Old description:

> Currently, laptops are configured in deployment to speak to a particular
> well-known Jabber hostname. However, there may be more than one school
> server which has an XMPP server answering to this hostname. This means
> that when people move between networks, they may also move between XMPP
> servers, arriving at a server where they have not registered (even though
> the flag says they have), so authentication will fail. David Woodhouse
> alerted me to the fact that this will happen in schools with >1 school
> server, and also that teachers may work at multiple schools, exacerbating
> the problem further.
>
> In order to avoid this, we should respond to authentication failures by
> trying to re-register, in case we've arrived at a different server with
> the same name, or even that the server has suffered data loss or been
> replaced. In fact, this may just allow us to stop tracking our
> registration state at all.
>
> If we don't do this, inexplicable collaboration failures will ensue.

New description:

 Currently, laptops are configured in deployment to speak to a particular
 well-known Jabber hostname. However, there may be more than one school
 server which has an XMPP server answering to this hostname. This means
 that when people move between networks, they may also move between XMPP
 servers, arriving at a server where they have not registered (even though
 the flag says they have ), so authentication will fail. David Woodhouse
 alerted me to the fact that this will happen in schools with >1 school
 server, and also that teachers may work at multiple schools, exacerbating
 the problem further.

 In order to avoid this, we should respond to authentication failures by
 trying to re-register, in case we've arrived at a different server with
 the same name, or even that the server has suffered data loss or been
 replaced. In fact, this may just allow us to stop tracking our
 registration state at all.

 If we don't do this, inexplicable collaboration failures will ensue.

--

Comment(by jg):

 Marco?  state of the sugar piece?

-- 
Ticket URL: <http://dev.laptop.org/ticket/6295#comment:13>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system