Subject: Terminology

From: Erik Nordmark <[email-masked]>
Date: Thu, 2 Oct 2003 00:28:48 +0200 (CEST)

> We clearly need two different words for two different actions:
> 
>    1. Handing over an "identifier" from one end-point to another,
>       with the intention of the receiving end-point being able to
>       contact the "identified" end-point in the future.
> 
>    2. Handing over an end of an (active) association from one
>       end-point to another.
> 
> I was using the term "referral" in the first sense, while you
> seem to be using in the second sense.

FWIW I've been thinking of #2 as "rehoming" while calling #1 "referral".

I think there is also overlapping terminology around "rendez-vous".
I've seen Keith More use this term for the case when applications on
node A and B communicate for a while, and A ends by saying "please contact 
me at A when done". At some later point in time B will use this to get back to
A.

But we are also using it to describe the process where one host finds
another; there are clearly elements of this more general finding
which could instead be described as "lookup".

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 02 Oct 2003 08:07:20 +0300

> FWIW I've been thinking of #2 as "rehoming" while calling #1 "referral".

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

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

      This is what I originally thought that referral means.  This
      is what seems to happen in FTP when you use a PORT command
      that refers to a third host.

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

      According to my poor understanding this is what Dave meant
      with referral, but I am probably wrong.  Erik seems to call
      this rehoming.  I don't have a name for this, since I have
      never seen this in real life.

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

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

--Pekka Nikander

---

From: Dave Crocker <[email-masked]>
Date: Thu, 2 Oct 2003 15:13:17 -0700

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>