Hallam-Baker, Phillip wrote:
The charter states "This working group will develop a DNS-based
mechanism for storing and distributing information associated
with that
authorization". If we limit the scope of the charter to the mechanism
for storing the data as opposed to how it is applied, we can avoid
restricting the use of data only at MTA level and not MUA.
I believe the opposite. I beleive that if we focus on only describing
the configuration of the outgoing mail servers using the DNS in the
normative part of the spec EVERYTHING else is non-normative.
So we give an example of how to apply the data at the incomming MTA.
We also provide an example of how to apply the data at an MUA with
reasonable assumptions being made about the intermediate servers. But
we do not require any particular approach here, this section is
non-normative.
The normative/non-normative split you are describing sounds good to me.
I do have a different concern with the scope - if we are describing the
configuration of the outgoing mail server, where do we draw the line?
Right now we are focusing on ways to tie in MTA to the domain among
other things, which is something present in several other protocols.
However, describing the configuration would probably encompass a whole
slew of other things, and might need a sightly different approach.
Perhaps you can provide other examples of configuration data aside from
accredidation?
As for accredidation, I don't see how that is relevant to the
"configuration" of the outgoing mail server. Perhaps you can elaborate?
Yakov