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, that I could have a sm-id as ID,HMAC > where I can check if the ID was not tampered with. The sm-id is opaque > to the client and has meaning to the server. Yes, but the problem is that this decision adds yet another routing criteria on the server (looking up where is the session you want to resume is a routing algorithm). Most of the routing on the server is done through JID and you have all the infrastructure in place on the server to cope with that. Using another new id is creating a new routing criteria. Why O why do we need that :) We have seen from previous comment that you cannot use full JID in this opaque data, because that's an information you do not have at the time you generate the sm-id. 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 decision. sm-id is an access key. We still need to specify which session you are resuming. This is two different needs and I do not see any good reason not to acknowledge that in the protocol. Yes, you could hack something mixing the two (let's suppose for an instant it could work), but why not make it clear that both information are important from the beginning ? I feel a bit alone to defend this view, and I am suddently afraid to have been struck by early Elzeimer disease :) -- Mickaël Rémond http://www.process-one.net/
