Subject: Working toward unity on XML

From: Greg Connor <[email-masked]>
Date: Tue, 15 Jun 2004 22:14:11 -0700

I made the following comment during the jabber session yesterday, when it 
seemed we were moving further and further away from an agreement on XML:

> gconnor: I think the XML issue is a very small part of the important work
> we are doing within MARID. It's an implementation detail. We have made a
> lot of progress in terms of coming together on identities and features.
> let's not forget that. I know the XML issue pushes a lot of people's hot
> buttons. I don't want this issue, which I consider "not really central to
> the problem we are trying to solve" to tear the group apart

I don't have a strong vested interest in whether MARID get implemented in 
XML, plain SPF, or Java or Tcl for that matter.  I have some opinions, but 
I am not going to let my opinion stand in the way of the larger goal - 
MARID success and a proposed standard.

Here is my attempt to review some of the positions on the issue.  I agree 
with Marshall that there really needs to be some compromise between the two 
extremes or we are not going to be successful.  Therefore, please read this 
message through to the end before replying.

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.

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 <[email-masked]>

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 16 Jun 2004 01:12:54 -0500

> XML is extensible.  We can add new syntax later without breaking things.

DNS dictates the use of small messages containing public data. No amount
of pleading or stubbornness changes that.

Meanwhile, if the underlying goal behind the use of XML is infinite
extensibility, DNS is a poor choice. Per-user policy statements require
user-keyed lookups (email address instead of domain), future extensions
are likely to require authenticated access, and so forth. Most of all, the
service needs to be able to serve this data reliably and efficiently,
which DNS is unable to satisfy considering its optimizations.

In short, neither DNS nor the goal of extensibility are ultimately
satisfied by trying to force them to work together.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Jun 2004 00:32:48 -0700

On Tue, 2004-06-15 at 22:14, Greg Connor wrote:
<snip> 
>   1. What position you support

No parser is better.  Virtually all DNS data is returned structured in a
binary format to keep information concise and small.  This would require
either existing records other than TXT or a new record.  Attempting to
add into a single TXT record seems an outcome of seeing text as
synonymous with a polymorphic web page; a dangerous design practice for
DNS.  Excessive combining and dereferencing could be fatal for both DNS
and MAIL.

>   2. What other fallback or compromise positions you can live with, and

CSV-HNA-CSA~DNA : )

>   3. How strongly you feel about one or the other.

Neither are great.  Keeping XML controlled is not allowed it would seem,
but even SPF should be limited with more restrictions.  Can an assurance be
established?  Will benefits outweigh risk?  Would a hexidecimal encoding
of a structured array be more concise?

-Doug

---

From: Margaret Olson <[email-masked]>
Date: Wed, 16 Jun 2004 08:56:41 -0400

> Caller-ID (XML) has not had a huge publication rate.  This *may* be a
> case of domain owners vetoing XML, but there are many other 
> possibilities.
>
I do not think this has anything to do with XML vs SPF syntax; I think 
it's a reflection of the level and kind of information you have to 
gather in order to publish. As I have mentioned elsewhere, for most 
domains publishing to catch all P.R.D. is much different exercise than 
publishing the valid MAIL-FROM ip addresses. It's also much more 
valuable information for the receiver, and required for tracking 
reputation and accreditation by authoring domain rather than by 
channel.

Margaret.

---

From: "Sam Silberman" <[email-masked]>
Date: Wed, 16 Jun 2004 09:35:09 -0400

Nice write-up Greg!

[comments inline]

----- Original Message ----- 
From: "Greg Connor" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 16, 2004 1:14 AM
Subject: Working toward unity on XML

> Plain SPF MUST be supported.  XML SHOULD be supported.

The engineer side of my brain leans toward #3.     If we go this direction,
it will inevitable result in Position #4.

It is easier to publish a DNS record than deploy the software to use them.
It does not mater what we (or anyone) put on paper,  If the MTAs don't use
the MARID record, the exercise is moot.  Since the MTA authors and system
admins will have choices, they will choose the simplest approach that work
for them (not us).

No matter what we all think,  we are on the road to #4.

-Sam

---

From: Andrew Newton <[email-masked]>
Date: Wed, 16 Jun 2004 10:59:58 -0400

On Jun 16, 2004, at 1:14 AM, Greg Connor wrote:
> Domain owners are free to publish in either format.  People can vote 
> with their feet.
> If there is a clear winner in terms of market adoption, perhaps a 
> later version of our standard will deprecate one or the other.
>
>
>
> 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.
> 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.

The one thing that a standards specification must do, above getting 
past the standards process and finding community adoption, is to be 
interoperable.  Quite simply, with a two syntax system, one of two 
things must be done for interoperability: 1) the publisher needs to 
publish both syntaxes, or 2) the receiver needs to implement both 
syntaxes.

Additionally, a two syntax specification is many times more 
implementation work than a two record type system.  To support two 
record types with the same syntax, the necessary code is simply  
"lookup type Y; if no records then lookup type X".  For two separate 
syntaxes, the code paths are not nearly so similar.  In fact, they are 
dissimilar enough that semantic interpretation will yield different 
results (leading toward interoperability problems).

Finally, we must realize that any work put forward by the MARID working 
group will receive broader community review (IESG review and an 
IETF-wide last call).  To any outsider looking at a MARID draft 
specifying two syntaxes, it could easily appear that the working group 
did not come to consensus on a syntax and is attempting to route around 
that fact.

Both the SPF and XML syntaxes do the job at hand.  Both are workable.  
And both are extensible.  But we need to pick ONE.  So the question 
should be, which one has the extensibility we desire.

-andy

---

From: Edward Lewis <[email-masked]>
Date: Wed, 16 Jun 2004 11:23:45 -0400

At 10:59 -0400 6/16/04, Andrew Newton wrote:
>has the extensibility we desire.

Extensibility, per se, is desirable.  But, given that MARID WG is 
supposed to a "quick hit" effort, on a short time scale for that 
reason, I am not convinced that extensibility is a realistic 
(primary) goal.  Don't avoid it, but don't reach for it.

The TXT RR is being favored by the group for expediency, against the 
architectural sensibilities of (at least some) DNS protocol experts. 
I think that the expediency argument holds more water if the solution 
derived in this group targets the immediate problem with an 
immediately focused solution, rather than being too concerned with 
extensibility.

I find it odd that some would like to retain support for two 
different syntax's, yet resist proposing a new RR while maintaining 
the TXT RR for transition.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 16 Jun 2004 11:32:45 -0400

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" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 16, 2004 1:14 AM
Subject: Working toward unity on XML

> We are going to look silly and be irrelevant in 5 years if we don't allow

I'm too old to have regrets, but I think it already looks silly that the
solution proposed has so many questionable designs issues.

> Those implementing MTA and mail filters can start with SPF as it is
written
> Allows people to vote with their feet, sort of.  Software vendors have
some

---

From: wayne <[email-masked]>
Date: Wed, 16 Jun 2004 06:52:42 -0500

>> the problem we are trying to solve" to tear the group apart

This comment got a lot of support on the Jabber session.

I'm going to this message reply out-of-order

> 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.
>

For better or worse, I think that position 2 is the only option that
makes sense.

>   2. What other fallback or compromise positions you can live with, and

Position 4

>   3. How strongly you feel about one or the other.

I, personally, don't feel that strongly against XML, but I do think
things should be as simple as possible (but no simpler) and my
position reflects what I sense from the people on SPF-discuss that are
not involved in MARID.

Ok, now that I've answered the questions the way Greg asked for, I
have a few more comments.

I think it is critical to keep in mind that there are no protocol
police.  In effect, there are several groups of people who have
effective veto power over any of our choices.  If domain owners don't
like something, they won't publish records.  If mail admins don't like
something they won't check records.  If MTA authors don't like
something, they won't give mail admins a choice.  If the IESG doesn't
like something, they won't give us an RFC.

Caller-ID (XML) has not had a huge publication rate.  This *may* be a
case of domain owners vetoing XML, but there are many other possibilities.

> Position 2. Opposed to XML:

SPF-classic (SPF syntax) has had a far larger publication rate.  This
tells me that domain owners aren't vetoing SPF syntax.

> Position 3. Implement both, let domain owners decide:

Most domain owners who have published Caller-ID have also publish
SPF-classic.   There really isn't much to stop people from publishing
both. 

> Position 4. Leave it up to the MTA:

Here is the crux of the problem.  It is generally mail admins that are
the most vocal against XML, with a fair number of DNS folks and MTA
patch authors thrown in.  Again, there really isn't much to stop mail
admins from checking just one.

So, even if we officially say in the RFC that our is position 3), mail
admins have veto power and will convert the situation into position 4)
anyway.  I don't particularly like position 4), but in reality, I
don't think position 3) is an option on anything other than paper.

So, when you realize that position 3) is really position 4), you
accept that domain owners aren't vetoing position 2, and combined with
the KISS principle, I think that position 2) is the only one that
makes sense.

>> the problem we are trying to solve" to tear the group apart

The XML issue is not just tearing this group apart, it threatens the
adoption by mail admins of any RFC that uses XML.  I'm not going to
claim that the opposition of XML by mail admins is always rational,
but we must acknowledge and deal with this situation anyway.

-wayne

---

From: Chris Zumbrunn <[email-masked]>
Date: Wed, 16 Jun 2004 19:08:59 +0200

>  1. What position you support

Position 2. Opposed to XML
I'm against putting XML in DNS and I'm against forcing developers and 
admins to do XML parsing in MTAs.

>  2. What other fallback or compromise positions you can live with, and

Position 4. Plain SPF MUST be supported.  XML SHOULD be supported.
This position actually makes a lot of sense to me anyway because one 
can be much quicker deployed than the other.

I would SUGGEST the following to be considered as a possible compromise:
* The non-XML SPF DNS syntax would be extended so that DNS can contain 
a pointer to non-DNS based SPF policy data.
* An SMTP POLICY command would be added for MTAs to fetch that data 
from the designated source.
* That data could then be in any format that MTAs would be willing to 
read - including XML

I would ACCEPT pretty much any compromise:
It's not like I'd really have a choice ;-)  BUT: I might wait with 
implementing it until I have to!!!

>  3. How strongly you feel about one or the other.

See above :-)

Cheers, Chris

[email-masked]  +41 329 41 41 41
Chris Zumbrunn Ventures - http://www.czv.com/

---

From: Greg Connor <[email-masked]>
Date: Wed, 16 Jun 2004 10:19:39 -0700

> should be, which one has the extensibility we desire.

I appreciate the background info on IESG and IETF.  It is useful.  It 
sounds like you are saying "Pick ONE Language" should be considered a 
requirement of the group.  Do you believe strongly that it should?

In the case where we have to pick one and only one language, here is a new 
summary of issues and a new possible compromise position.

> Position 1. In favor of XML:

1. XML is it.

 * We see extensibility as a core requirement (at least syntax, but leaving 
the door open for features as well).  We see XML as synonymous with 
extensibility, and we see a customized language like SPF as inferior in 
this regard, and can clearly articulate why.
 * Also, we see MARID as a part of a larger scheme of "email policy 
documents" and we can clearly articulate what that means.
 * There may be size issues but we are willing to deal with that.
 * Supporting those domains that have already published SPF is not a big 
concern.

> Position 2. Opposed to XML:

2. SPF classic syntax

 * Extensibility is a reasonable goal, but should not get in the way of 
simplicity, human-readability, and byte-economy, which we see as more 
important.
 * We are not convinced of the need to bind MARID together with a larger 
"email policy" document that is not yet defined.
 * SPF classic is extensible by way of adding modifiers (e.g. 
domainkeys=all) and by new version tags (e.g. v=spf1d).  SPF records may 
contain unknown mechanism (like +dk) but pre-existing implementations will 
always stop and return "unknown" in that case.
 * Support for those domains that have already published SPF is important.

> Position 4. Leave it up to the MTA:

5. XML is the standard.  Receivers MAY also check other "legacy" formats.

 * We believe XML is likely to take over in the future.  Implementations 
are considered MARID-compliant if they read and understand XML TXT records 
published using a _prefix (such as _ep or _lmap)
 * It's up to sysadmins and MTA implementers if they want to support SPF 
records also.  A large number of MTAs will choose to do this anyway, given 
the large amount of data already published.  SPF data will be published at 
the domain itself, rather than at a _prefix label.
 * It is conceiveable that market forces may continue to create demand for 
SPF Classic even well after the initial deployment.  If people continue to 
use and support SPF Classic and XML fails to take off, a future RFC may 
codify the de-facto standard.

Here is my take on this.  During the jabber session, Jim Lyon expressed 
that it is important to him that MARID be a part of a larger context, and 
that "email policy document" is something that the world needs anyway. 
This sounds "nice" BUT I don't accept this as a "requirement".

Therefore, I am willing to accept compromise position 5 ONLY if there is a 
draft from MS saying "Here is why we need an Email Policy Document over and 
above MARID requirements" AND that draft receives favorable responses from 
MARID members.

Right now, I don't believe extensibility trumps simplicity, economy, and 
the large amount of data published in SPF classic format.

---

From: Jonathan Gardner <[email-masked]>
Date: Wed, 16 Jun 2004 10:50:59 -0700

>   3. How strongly you feel about one or the other.

1. Position 2: Plain SPF

2. I can't live with any other option. 

3. I feel very strongly about (1). I believe that if (1) isn't adopted, we 
will lose all credibility. There is the very real risk of SPF being adopted 
regardless of the IETF. SPF has already shown momentum. No other proposal 
has.

- -- 
Jonathan M. Gardner
Mass Mail Systems Developer, Amazon.com
[email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Wed, 16 Jun 2004 14:05:19 -0400

On Jun 16, 2004, at 1:19 PM, Greg Connor wrote:
>
> Here is my take on this.  During the jabber session, Jim Lyon 
> expressed that it is important to him that MARID be a part of a larger 
> context, and that "email policy document" is something that the world 
> needs anyway. This sounds "nice" BUT I don't accept this as a 
> "requirement".

And so this is the higher level question.  Just how much extensibility 
do we need?

-andy

ps.  thanks Greg.

---

From: Margaret Olson <[email-masked]>
Date: Wed, 16 Jun 2004 14:34:15 -0400

On Jun 16, 2004, at 2:05 PM, Andrew Newton wrote:

>> expressed that it is important to him that MARID be a part of a 
>> larger context, and that "email policy document" is something that 
>> the world needs anyway. This sounds "nice" BUT I don't accept this as 
>> a "requirement".
>
We need to be able to extend the kinds of information conveyed in the 
authentication record, without restriction; authentication is part of a 
larger solution space which is currently poorly understood. Jim Lyons 
provided some good examples.

We do not need to be able to change the result of the authentication 
test.

 From my point of view, backwards compatibility with SPF syntax with all 
extensions in XML is a perfectly reasonable compromise: it provides 
backwards compatibility for people who have already published and it 
provides the level of extensibility we need without inventing a new 
extensible language. Is it really unreasonable to expect the IESG to 
understand this argument? Surely this kind of compromise is common in 
engineering practical, deployable solutions.

Margaret.

---

From: Sean Comeau <[email-masked]>
Date: Wed, 16 Jun 2004 16:23:51 -0700

I agree that supporting two syntaxes is the worst possible option. 

> * Support for those domains that have already published SPF is important.

So far I haven't heard any good feature suggestions that require complex, 
structured arguements. I fear that supporting XML will lead to more complex 
client implementations resulting in more bugs. Many will try to create 
extentions and interoperability will suffer. This would cause mail admins 
more problems than it solves. As a mail admin I don't want to worry about 
what other sites running this implementation or that will do with my record.
They MUST all work exactly the same way. It has to be perfect, not sortof 
almost perfect like what we get with web browsers. 

I strongly believe that new features should be worked out by groups like this 
one rather than being added randomly by vendors. The fact that we must be more 
careful when adding features to SPF is a benefit not a problem. This protocol 
should do only one thing and do it well: stop header forgery. 

From most to least important: Simplicity, byte-economy, human-readability, 
extensibility.

---

From: Matthew Elvey <[email-masked]>
Date: Sat, 19 Jun 2004 14:52:50 -0700

On 6/15/04 10:14 PM, Greg Connor sent forth electrons to convey:

>
>
> I made the following comment during the jabber session yesterday, when 
> it seemed we were moving further and further away from an agreement on 
> XML:
>
>> gconnor: ...I don't want this issue, which I consider "not really 
>> central to

Postion 2: no XML

>  2. What other fallback or compromise positions you can live with, and

CSV+NBB+SPF records replacing HNA. ( ~= 40% solution)
Position 1: XML only

>  3. How strongly you feel about one or the other.

I feel strongly that we need to KISS.  Hence 3&4 are even worse than 1, 
all of which I oppose strongly.

We need to stick to DNS over UDP.  Otherwise we will end up with a cure 
that is worse than the disease.  Others have detailed the resource and 
interoperability impact.

> 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.

I'm not comfortable compromising because I have a real concern that with 
1, MARID is more likely to fail.