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]