[e2md] E2MD and Indirection -- a new problem statement

[Dean Willis <[e-mail]>]

I've heard Ray and Richard say that indirection might be appropriate in
some cases. If we're willing to factor that into the work, we might have 
an opportunity.

If we amended our problem statement to say that we would analyze the
initial use cases, determine which cases need to be "in the database"
and which need to be indirectly referenced, show how to indirectly
reference where needed, and provide guidance for future users on how to
make this determination and provide future guidance on dereferencing,
then I predict our problem statement would be MUCH more palatable to the 
opposition.

Let's try a re-write of my proxy-shill version and see if it gets
friendlier looking. This one's a bit rough, but it should convey the basics:

Goal of the E2MD Work
---------------------

An easily extensible framework for using the DNS to discover data that 
is related to an E.164 number also resolvable in the DNS. The 
framework's organizational model is expected to be based as closely as 
possible on the existing ENUM framework. The framework is expected to 
provide for a multiplicity of different data types and provide for a 
semantic definition of each data type as well as define its relationship 
with the aforementioned E.164 number. The framework is expected to 
provide for storing some data types directly in the DNS, and in other 
cases to store a reference to the data in the DNS, with that 
determination based on the nature of the data type and its use cases.

The framework is NOT expected to provide a selective query mechanism; 
rather, a DNS query for framework data associated with an E.164 number 
is expected to return all such data and data references known by the DNS 
to the querying node. The framework's expected query mechanism is 
expected to be straight-up DNS, and as such will make no considerations 
for authentication, authorization, or selective response based on the 
identity of the querying node. Further, the framework's query mechanism 
is expected to make no considerations for network congestion, 
reliability, integrity, privacy, or overly-large response sets beyond 
the inherent mechanisms of the DNS.

Where such considerations are significant, the framework is expected to 
provide guidance on the use of other protocols that will be used to 
retrieve the framework data referenced from the DNS, and such other 
protocols are expected to provide needed considerations for 
authentication, authorization, selective response based on the identity 
of the querying node, network congestion, reliability, integrity, 
privacy, and large responses. The framework is expected to provide for 
standardization and IANA registration of new data types without a 
requirement for IETF consensus on each new data type, using the existing 
ENUM service registration model.