Joel -
You are saying that there ought to be a third identifier type, besides
service and session identifiers, which is used to map a service of
interest to a particular stack on which an instance of this service is
running. This would enable a host to refer a third party to this
particular service instance.
I agree with you that such "service instance referrals" must be
possible. Where our opinions diverge is on whether we need a third
identifier type for it.
In my opinion, we don't need a third identifier type for service
instance referrals. The service identifiers, which we need in any case,
are already sufficient for this purpose: At the point where an
application wants to refer a third party to a particular service
instance, it is defining a new service that only said service instance
can provide. This new service can naturally have its own service
identifier. This service identifier, in turn, will map to the locators
of only the stack on which the referenced service instance in running.
Oh, and regarding session identifiers: Those are irrelevant for all of
the above. I agree with this. It is the service identifiers that matter.
- Christian
On Jul 3, 2009, Joel M. Halpern 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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
