Greg,
You touched base with many fair issues on both sides.
In our anti-spam product SMTP component (upgrade with new LMAP support
released in in April), we added support forr DMP, SPF and MCEP. The reason
was to be open and flexible and to means what works or not. I have just
posted a survey in our support group to get some feedback on which polices
they have defined. Also, I have the following stated in our online Setup
documents.
"CEP is relatively new and it is nearly equivalent in logic to SPF CEP
does not
have the large support yet as SPF. However, it should go without saying
Microsoft
CEP will become a major new internet standard in short time once it is
added
to their software packages."
So even though from a technical support, I don't agree with the decision of
using XML, we are not dumb either. I guess this holds with your position
3.
[Side Note: I can not use CID as a acroynmn because it an 20 year old
display scripting MACRO keyword and acroymn for Caller ID in our modem
hosting product for modem CID Verification Support, logging and reporting.
So logically, I used a new acroymn that is more techncally appropiate based
on the Title of Microsoft own document - MCEP for Microsoft' Caller-id Email
Policy. Just in case if people were wondering.]
So with that said, I would like to say the following:
Think about it what the new SMTP + MARID design requirements will be:
- RFC 2821
- RFC 2822
- RFC MARID
- Standard XML Library (for common behavior (including problems)).
plus all the rest that come from this?
- RFC 2376 (XML Media Types)?
- RFC 3470 Guidelines for the Use of Extensible Markup
Language (XML) within IETF Protocols.?
- RFC 3688 The IETF XML Registry?
Is this the level of complexity we are looking for such a narrow scope of a
problem with a limited half-life?
I believe this would be among the first time, if not the first, in the
annals of internet development that a new standard will include a major
provision for the usage of a 3rd party technology and/or sub-system.
No big deal right?
Well, it will imply the unrealistic belief that everyone will borrow or use
the same or similar set of tools. In other words, it ignores the probability
developer will re-invent the wheel and write their own parsers. A possible
false security blanket due to possible "differences" where potential
exploits will evolve and target.
It would be a wrong assumption *all* Windows developers are using Microsoft
component engineering technologies for product development. In fact, using
the Microsoft XML components will introduce additional Windows OS
sub-systems that may not be desirable for product design - ATL, DCOM,
ACTIVEX. Once you do, you open yourself up to the Microsoft security
nightmares the world has endured. The high quality of non Microsoft
products for Windows platform is typically based on not using these poorly
designed sub-systems from Microsoft which continue to this day to have new
security issues. In short, the XML requirement will increase the vendors
quality assurance requirements when in reality, it wasn't something that was
necesary if only it made life easier for some people.
We will use XML, if need be, but with our design, it will be own design. No
problem, but absolutely a Microsoft dependency will not be introduced at
this level. If this is people want, fine, but overall, I think you need
not worry about what people will think 5 years from now, but rather what
this high level requirement being imposes. It makes it all look silly
today!! It is such a narrow scope, this XML introduction and the debate
that followed because of it should not be the reason this WG is now
threathen, but instead, the reason it should not be used.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Greg Connor" <gconnor(_at_)nekodojo(_dot_)org>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Wednesday, June 16, 2004 1:14 AM
Subject: Working toward unity on XML
Position 1. In favor of XML:
XML is extensible. We can add new syntax later without breaking things.
Our MARID data should be part of a larger picture of "email policy".
There are standard tools out there to parse XML that we can re-use.
We are going to look silly and be irrelevant in 5 years if we don't allow
extensions.
I'm too old to have regrets, but I think it already looks silly that the
solution proposed has so many questionable designs issues.
Position 2. Opposed to XML:
XML records are too big for what we want.
Rampant extensibility might lead to inconsistent results later.
An XML parser would be too big for my MTA or other mail-analyzing program.
Keep It Simple. Testing an XML parser would be onerous compared to other
testing needed.
Mistrust of Microsoft and their motives for wanting XML
If we implement something too big or complex, we will look silly and be
irrelevant in 5 years.
Position 3. Implement both, let domain owners decide:
Plain SPF and XML MUST be supported by all implementations.
Domain owners are free to publish in either format. People can vote with
their feet.
If there is no extension really needed, plain text will probably be
preferred because it is more readable.
If there is some extension that people end up needing, the XML may be
preferred in the future.
If there is a clear winner in terms of market adoption, perhaps a later
version of our standard will deprecate one or the other.
Position 4. Leave it up to the MTA:
Plain SPF MUST be supported. XML SHOULD be supported.
Those implementing MTA and mail filters can start with SPF as it is
written
today, and are encouraged to support XML also, but reading and acting on
only the Plain SPF format is also allowed.
Software vendors that don't support XML do so at their own risk. Users
who
feel they need XML support may complain. The software not supporting XML
may get negative reviews later, or have a checkmark missing on the feature
grid. Patches later might be needed.
Software that understand SPF now will be pretty much ready-to-go as is.
Domain owners may choose XML but might be faced with less support among
receivers.
Assuming the XML may be extended and the plain format might not be, when
both are present, the XML should be used, falling back to SPF plain only
if
the MTA doesn't support XML.
Allows people to vote with their feet, sort of. Software vendors have
some
freedom to choose, but are ultimately accountable to the customers.
More thoughts on extensibility:
There are two kinds of extensibility, and there is some disagreement as to
which we want, if any.
"Feature" or "semantic" extensibility adds new mechanisms later, and may
change the output of the checking function, or even add new inputs to the
function. This can be supported, if done carefully. Either an
intelligent
default, or an "alt=" type of statement attached to the extended feature,
would be needed in order for the software of today to "navigate around"
the
data points we throw at it tomorrow. There is some support for this kind
of extensibility, but there are also others who feel strongly that we
should NOT be able to add new features on the fly, as this would lead to
inconsistent behavior among some implementations and that's not good.
Regarding feature extensibility, my guess is there are probably a lot of
people who like it, but their support is lukewarm and they aren't
passionate about it enough to defend it. At the same time, there are
probably some people who feel strongly enough to come out swinging against
such flexibility, fearing that the new extensions won't add enough value
to
offset the potential harm in flaky software not doing extensibility right
or not being consistent with each other.
We also have "syntax" extensibility, which allows us to thrown in new data
later, but only as "extra" or "not core" data. The new data might give
extra info (like publish a domain's desire to receive problem reports) or
it might be something not relevant to MARID at all (like whether a domain
uses domainkeys, or where to find accreditation, or something like that).
Just syntax extensions, with no feature extensions, are easy to add (to
any
language, not just XML) as long as the rules are clear from the start.
For
example, no "extra" data will ever result in a change to the
accept/deny/unknown function. An MTA can either ignore it totally, or
complain that it's a possible typo, depending on where the data appears.
(For example, an "ep" might have nodes other than "out" and "out" might
have nodes other than "m", but nodes within "m" should be of a recognized
type or the implementation should interpret this as a typo and throw an
error)
More about size:
XML is going to be a bit bigger than plain SPF or other plain-token
language. Frankly, I don't see size to be a big issue... it is a concern,
but not enough of a concern for me to exert a veto or leave the party
early. We will have an include-type mechanism for stitching together
records. DNS *does* actually have a mechanism for fetching larger
records,
even though it may be blocked by some firewalls... I think it's the
responsibility of the domain owner to make sure that the record fits in a
response packet, and test this, and those who choose to publish larger
records should do so at their own risk.
Wrap up, and where to go from here:
I would prefer not to see replies to this post where people tear it up and
match one or two sentences of mine with some quick comeback of theirs.
That's a great style for arguing, but I think the time for arguing is
past.
Most people who care about the issue have made most of the intelligent
arguments they are going to make.
What I would really prefer to see is a few paragraphs that say:
1. What position you support
2. What other fallback or compromise positions you can live with, and
3. How strongly you feel about one or the other.
If you respond supporting one extreme, and don't state a compromise
position that you can live with (either 3 or 4 or something else I haven't
spelled out), then you might want to add a footnote saying why you believe
this issue is enough of a dealbreaker that you are not willing to
compromise, and why you are willing to let MARID fail rather than give in
on the issue.
This is where the rubber really meets the road, and the hard work of the
working group starts. Failure to reach any agreement is a *guaranteed*
way
to look silly and be irrelevant in 5 years :) Let's all try to work
together and rise to the challenge. We can do this.
Thanks for your time.
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>