Before defining *how* the data is stored in DNS, we should work on
*what* that data is. There is a significant disagreement on
what kind of
data should be included among different proposals, and this
is something
that is more important than how the actual data is stored.
Agreed, moreover how many different ways do we need to express
the same data?
What is the best way to deal with the forwarding problem?
should we attempt to define a macro language as Meng has
done? Should we attempt some other means of addressing this
problem? Does this mean that the charter should allow
discussion of mechanisms other than pure DNS publication
rules?
This is akin to writing up the book before figuring out
what the cover page and the
title should be, as opposed to picking a title and the picture on the
cover, before writing the content.
We should probably discuss use cases and requirements.
I believe use cases would be very helpful. Not the normal
alice talks to bob use cases. I want to see the salient
header features.
My belief is that there are only really two interesting
use cases:
1) Mail is sent to alice(_at_)example(_dot_)com, possibly forwarded
under the same name via relays controlled by the sender
or receiver's ISP.
2) Mail is send to email(_at_)alias(_dot_)example(_dot_)com and forwarded
under a different name, either through the action of a
mailing list or a mail forwarding arrangement.
There are also uninteresting use cases like going through
open relays.
Case (2) is where all the corner cases come from. One way
to address this problem is by defining the actions of
forwarders that change names very carefully.
As much as some of us may be interested in your "war stories" about
fighting the "gods" of the IETF, this is not proper forum for
that type of discussion.
If it is asserted that a party has a legitimate interest in the
direction of a spec it is legitimate to point out that they should
be ignored.
Phill