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
