Re: draft-ietf-impp-pres-01

Dave Crocker <[email protected]> Tue, 14 Jan 2003 11:56:33 -0800
Newsgroups gmane.ietf.impp
Organization Brandenburg InternetWorking
Message-ID <[email protected]>
Thanos,

Tuesday, January 14, 2003, 9:28:14 AM, you wrote:
Thanos> I don't see how the multiple subscriptions has anything to do with this.
Thanos> Multiple subscriptions work even if you relax the uniqueness reqt:

An identifier is useless if it is not unique.  So there is no "relaxing" of
the uniqueness requirement.

However there certainly are legitimate choices about the way to ensure the
uniqueness.  These involve tradeoffs in the scope of utility for the
identifier and the bit-efficiency needed to encode it.

The simple choice is between what I will call self-identified uniqueness,
versus context-based uniqueness. The former contains all of the data
necessary to ensure uniqueness, within the identifier itself. Email
addresses are an example.  So are URIs.

The latter relies on some larger context to ensure uniqueness. TCP port
numbers are an example since they are relative to the IP address. For that
matter, the definition of a TCP connection is an aggregation of such
context, relying on IP address/port pairs from both connection participants
to define the unique connection identifier.

The choice between self-defining and context-based identifiers is probably
best made in terms of lifetime and encoding constraints.  If the identifier
is long-lived -- and especially if it might be used in other contexts --
then it is better to make it self-defining.

If it is essential to save bits, then context-based identifiers are probably
preferred.  However note that this establishes a critical dependency.  For
example, the dependency that TCP connections have on the underlying IP
address has constrained the ability to pursue some mechanisms that would
help with multihoming and mobility.


d/
-- 
 Dave <mailto:[email protected]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850




  [reminder: [email protected] for non-technical discussions, please]