Re: Terminology

[Dave Crocker <dhc@dcrocker.net>]

Pekka,

PN> Oh well.  English seems to be hard language.  I think that we
PN> have at least three different scenarios here.

Unfortunately, I think that the problem is not with the language we are
using. I do not think that any of this would go more smoothly in
spanish, japanese or tamil.

Rather, I think we have been using non-technical terms without defining
their technical use. Consequently the use has not been precise.

Although I'd like the words to have a "natural" meaning that is
reasonable, I am more concerned with having precise terms used
consistently.

Unfortunately, the way to deal with a pattern of imprecise use is not to
re-define existing terms, but to throw them away. As Erik notes, we
should mostly not use "address" but should instead use "locator" and
(perhaps) identifier. We need to do the same thing for these other
terms.

So let's stop using _Rendezvous_.



PN>   1)  Node A has an A-B session with node B.  A sends an identifier
PN>       of node C over the A-B session, allowing B to start a new
PN>       session with C.

I think this is consistent with Erik's usage.

So, yes, it seems like calling this _Referral_ is ok.

In other words, A is referring B over to C. The referral is stateless,
with respect to the A-B association.


PN>   2)  Node A has an A-B session with node B.  A starts a new A-C
PN>       session with node C, and hands over its (A's) end of the
PN>       active A-B session to C, so that the A-B session now becomes
PN>       a C-B session, allowing B and C can communicate directly.
PN>       A is no more involved in communication.

The essential part of this is that A hands its part of an association
over to C.  The detail of 'starts a new A-C session' is not essential to
the activity.

This sounds like _Rehoming_ in the way that Erik was suggesting.  Yes?


PN>       According to my poor understanding this is what Dave meant
PN>       with referral, but I am probably wrong.

I think your understanding was/is just fine.  I also think my usage was
bad.  Calling this rehoming strikes me as better.   For both words, I
think the usages are closer to their 'natural' meanings.


PN>   3)  Node A has a session with node B.  A sends one of its own,
PN>       application level identifiers, say A_app, and the corresponding
PN>       "identity" to node B, allowing node B to appear as A_app in the
PN>       future.

PN>       I would call this rehoming, since now the (application level)
PN>       entity Aapp that was earlier located at node A is now located
PN>       at node B.

Oh my goodness. Yes, this is an interesting scenario. And I think that,
yes, 2 and 3 are variations on the concept of rehoming.

But I also think that #3 is beyond anything we currently need to deal
with.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>