Subject: Its the XML infoset that is key RE: Working toward unity on XML

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 16 Jun 2004 09:47:03 -0700

I disagree with Greg's characterization of the problem.

The key architectural advantage of XML is that you separate syntax
definition and data structure definition. This makes for a vastly better
result, it leads to much better consistency than you get with the ad hoc
approach that has been encouraged by yacc.

Regardless of the syntactic representation we should define SenderID in
terms of the XML Infoset. SPF has a slight amount of convoluted syntax, but
on the whole it reasonably clean - at least at present. The problem lies in
the fact that the only extension mechanism provided in SPF is a list of
attribute/value pairs. This allows a lot to be done but forces you into
convoluted dances when you have an extension that requires values that have
some structure.

Do not forget here that our objective here is to gain acceptance by the
Internet community at large. The endorsement of the IESG is significant but
so is the endorsement of the stakeholders.

What we definitely should not do is try to predict the disposition of the
IESG through clairvoyance as some are suggesting. If the IESG want to make a
point to the group then they should send us an email. I do not accept the
claim that we should change course here and make decisions on what have been
flagged as showstopper issues by key stakeholders on the basis of reading
tea leaves. If this is a showstopper issue for the IESG then it is Ted's
responsibility to tell us.

We have a completely principled architecture here. We are recognizing the
importance of both a clean architecture with clear separation of syntax and
data structures, we equally recognize the need to provide support for legacy
systems that use a less architecturally pure syntax.

If this proves indigestible to the IESG my guess is that the XML RFC will be
accepted as standard and the SPF RFC as informational. That suits me fine
since I don't think anyone in the Internet world takes the slightest piece
of notice of which status is applied. It will not change any product plans I
have and I don't imagine it will change the product or project plans of any
other party.

---

From: wayne <[email-masked]>
Date: Wed, 16 Jun 2004 13:13:27 -0500

> responsibility to tell us.

Who are these "key stakeholders" who have put a stake in the ground
about requiring XML and won't budge?

Is it the domain owners?  Hmmm... no.

The mail admins?  No, they tend to be against XML.

The MTA authors?  Well, many are likely to be pragmatic and support
XML, but that is far from flagging the removal of XML as a show
stopper.

So who is this Mysterious Stakeholder who seems to think it is
important enough in the email world to have a Monopoly Situation?  Is
it right to let this Mysterious Stakeholder dictate its requirements
for an engineering task force?  What if stakeholders such as Equally
Large, Another Outrageously Large, or Yet Another Huge Online
Organization step forward with their own (conflicting) demands?  Do we
try to appease everyone?

Will this Mysterious Stakeholder really refuse to support a MARID RFC
if its demands are not met?  Even when the US government (FTC) is
considering email authentication requirements?

I completely agree with Phill.  Trying to use tea leaves to divine the
position of the IESG is not reasonable, they should just openly tell
us.  On the other hand, I don't think it is productive to have vague
references to a Mysterious Stakeholders who can veto the widespread
adoption of a MARID RFC.

I think it is time to call the Mysterious Stakeholder's bluff.

Mysterious Stakeholder, please step forward and tell us:

1) When, if ever, you will release products that would support a MARID
   RFC if they include XML?

2) When, if ever, you will release products that would support a MARID
   RFC if they *do not* include XML?

-wayne