In light of that, I see that each of the three postings argue
that the
SPF syntax can't handle something that it wasn't designed to handle.
That is why it would be an extension.
Seriously, why do you think 'out of scope' is an argument here? If it
was in scope it would not be an extension.
People have started to work on every one of the proposals made. I would
expect some of them at least to be proposed as subject matter for a
MARID extension group or a successor group. A detailed writeup of the
S/MIME proposal will be submitted before San Diego.
The problem with the SPF syntax is that it takes the APL approach.
Sure you can create a great syntax for one single purpose with
a syntax that assigns functions to character symbols. But in language
design terms APL made remarkably impact for a language so widely used.
LISP on the other hand has spawned a whole familly of languages,
ML, Prolog, Scheme, Orwell and the main advance Java made over C was
to abandon some of the more obfuscated syntax forms.
3) Phillip Hallam-Baker's examples
These examples are a clear extension into other approaches. None of
these examples has anything to do with domain authentication
of an IP.
To quote Phillip about such extensions: "...the number of degree of
freedom are huge". To this end, these examples beg for
something much
larger than the part of the problem the current projects ever set out
to handle.
I was referring to the choices when you embedd the necessary data
structures in SPF. With XML or S-Expressions or any similar formal
data encoding scheme I can write a schema that most people can follow
without even reading the spec. There is much less room for mistakes.
I understand the desire to design a more comprehensive mail policy
format. And I understand the desire that such a format be extensible
for future approaches that are now only contemplated. However, the
proposed XML syntax doesn't achieve this either: While it is
true that
XML provides a much richer syntactic framework in which to extend an
original document format, it says nothing about the semantic
meaning of such extensions.
That is not the objective.
Your argument is like saying, "I understand that a prius has better
fuel efficiency than an SUV, but a Prius is no better since it does
not run on water"
The myriad of possible extensions that have been expressed,
and their subtle effects of the semantics of the original format make
it clear that defining how clients are to interpret future extensions
would be difficult.
It is perfectly simple to interpret the presence of the S/MIME extensions.
If you understand the schema you follow that understanding, otherwise you
ignore the information - like you would if you do not understand MARID.
When a larger framework for mail policy
emerges, SPF can easily add a modifier for pointing to it.
Or perhaps
SPF will have run its course, and the newer framework will
simple take
over. Either way is fine.
No, it is not fine. I cannot tell the media in June that I am enthusiastic
about MARID, then tell them in August that MARID is obsolete and must be
abandonded.