Hi Scott -
In fact, I see only two purposes for which the Internet architecture
must have identifiers:
(1) service identification, identifying a piece of communication
software that responds to incoming contact establishment attempts
(2) session identification, identifying the protocol state
corresponding
to a particular session after contact establishment
First, let's avoid thinking of the Internet in client/server concepts.
Yes, thinking in client-server concepts would be too limiting. And we
are not. "Service" here is defined as a piece of communication software
that responds to incoming contact establishment attempts. This includes
both peer-to-peer and client-server applications. (FWIW, it also
includes
"applications" further down the stack, such as the ICMP Echo service.)
I repeat the litany of five identifier functions :-) ...
Many things certainly need to be identified. But again, most identifier
types are not core elements of Internet architecture because they are
specific to certain services. An example is host identifiers, which per
se are of use only in management applications.
Further, I would exclude authentication and authorization credentials
from the definition of identifier. Credentials are useful to prove
ownership of an identifier, but they are not identifiers themselves.
Let me comment more specifically on your proposed five identifier types:
* for access, to use a visited network at all.
Network access identifiers are certainly needed. But they are specific
to the access authorization service, and exchanged only within this
service. Also, network access identifiers are likely to be specific to
certain networks. Hence I would not consider them core elements of
Internet architecture.
In my personal view, the core elements of Internet architecture are
those which enable you to establish communications in general, such as
with said access authorization service. And those are service
identifiers for initial contact, and session identifiers afterwards.
* for initially finding something you want to talk to. Examples would
be domain names and SIP URIs. These might correspond to your
"service identification".
Agree, these are service identifiers.
* for initial contact, in order to establish sessions. These include
authentication and authorization identifiers.
These are service identifiers as well, plus credentials.
* for session control: initial authentication and association of
locators with sessions, as well as re-authentication when locators
change.
These are session identifiers. Supplementary credentials may be needed
for security reasons.
* for referrals, whereby one endpoint tells another about yet a third.
Referrals are important. But you don't need an extra identifier for it.
Service identifiers serve this purpose already.
Reading your email further:
However,
* You might be able to use the same identifiers for different
functions. That is, you may be able to use the same identifier as
input to multiple identification functions.
* Also, a single identification function can take multiple
identifiers.
* Finally, different layers will repeat the same functions. For
example, you may have multiple authentication functions, or
"session" control at multiple layers.
Absolutely. The actual identifiers used may end up being more than just
two. E.g., we may find that the use of host identifiers as a component
in service identification has advantages engineering-wise. This is why
we are only talking about "identification purposes" at this stage, and
not yet about actual sets of identifier types.
- Christian
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
