Joel, I think you are right here and I got it all wrong when claiming that host-ID, hereafter stack-ID, should be coupled together with a session-ID. Now I agree that they should be separated - when separated only the server need to have a stack-ID, the client doesn't need to have one. Then we are close to a HTTP session token solution, aren't we?
http://en.wikipedia.org/wiki/Session_(computer_science) -- patte On Sat, Jul 4, 2009 at 5:36 AM, Joel M. Halpern<[email protected]> wrote: > The reason this (naming the set of locators that lead to the same entity) > leads to a stack ID (or node, host, something) is that I want that > collective property available before I start communicating. > Referrals are the easy case. I am trying to refer someone to a specific > entity. They do not have a session with that entity. So a session ID is > clearly totally useless for a referral. > > I believe that similar constraints apply at the time of initial > communication establishment, in that there is a semantic difference between > using multiple locators for a target to establish communication and trying > to establish communicaiton with multiple "equivalent but distinct" targets. > I consider it helpful to udnerstand that distinction. > > It seems clear to me that one of the important properties of a communication > session is the pair (or worse, if one likes multiparty sessions) of entities > that are talking. But session identification is much more specific than > just naming the communicating parties, or even the available interfaces. At > this stage of the game I do not care whether session IDs are minted using > the stack IDs, or minted out of whole cloth using bilateral state. Either > can work. I am not arguing that session IDs inherently require stack IDs. > They don't. I am arguing that stack IDs are useful separate from session > IDs. > > Yours, > Joel > > Christian Vogt wrote: >> >> On Jul 1, 2009, Joel M. Halpern wrote: >> >>> It seems to me however that it is useful to be able to explicitly tell >>> which locators go with the same communicating entity, as distinct from >>> the larger set of locators which might go with the same service [...] >> >> Joel - >> >> Yes, we absolutely need this. But why does this imply the need for a >> host or stack identifier? Session identifiers already map to the set of >> locators that go to the same communicating entity. This is why we need >> to distinguish them from service identifiers, which in turn may map to >> locators of different communicating entities. >> >> - Christian >> >> >> >> > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
