ietf-mxcomp
[Top] [All Lists]

Re: Comments on draft-ietf-marid-core-01 xml use

2004-06-13 10:59:54


----- Original Message ----- 
From: "Greg Connor" <gconnor(_at_)nekodojo(_dot_)org>
To: "Jim Lyon" <jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com>; 
<ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Sunday, June 13, 2004 12:35 PM
Subject: RE: Comments on draft-ietf-marid-core-01 xml use


Given the above goals, let me take a stab at a proposal.

[clip]

Final note, while XML has syntactic extensibility, it cannot get feature
extensibility for free, we have to do our homework ahead of time.
Conversely, plain SPF has a similar restriction, but adding a couple of
carefully chosen elements to the language can give us feature
extensibility
in a sensible way.  I am not expressing a preference for either XML or
plain SPF in this message.

Comments, feedback, flames?

You raised some good points, especially the idea of utililizing XML entity
attributes should be maximized as much as possible. This has technical
optimization consideration.

What we seem to be having here is a classic "chicken vs. egg" design
problem.  It seems to me we are getting lost on a format without having a
clear logic flow for all the possible issues.  Any format, linear or
hierarchical, will provide a solution on flexibility.

I personally believe a linear format has optimization considerations, but I
wouldn't use that as a sole basis to rule out XML.  I look at all the other
design issues that XML will mandate:

- XML parsing requirements.

This is can a costly development issue for many as it is not a traditional
or intrinsic component in languages libraries.  It is something that needs
to be imported.  Not a big deal for developers worth their salt, but not a
piece of cake either.  We currently use the lightweight PugXML ANSI
compatible C/C++ class.  *nix people can look at this for an open source
reliable XML parser.

In regards to Microsoft, the mantra for Microsoft .NET designs is 100% XML
based.  So for them, it makes a lot of sense.  Microsoft offers XML
components so for .NET or ActiveX or ATL Windows developers, it is more
possible for them.  But this can lead to another issue:

- XML namespace.

Clearly, without a doubt, any system that requires a namespace raises a red
flag that has electronic privacy (ECPA) implementations.  A XML parsing
component that requires the importing of the namespace gives the source
system an opportunity to track the usage of the structure.  Sorry, this is
an immediate a NO-NO in our long tradition for ethical design of software.
Pulled from our custom XML parsing implementation for MCEP.  The last thing
we want to hear from customers is "why is your mail software pinging
Microsoft?"

With that said, although XML is a serious technology and a requirement for a
product vendors keeping on par with industry directions across the board.

However, for this particular MARID implementation, I have technical design
problem with it.  Given the choice, I would rather have a linear approach.
It has nothing to do with being faith-based,  or to borrow a phrase,  "a
devil on your shoulder or a raised hair on your back,"  but it 100% about
the technical issues related to it - a relative high/cost design
implementation requirement vs. a narrow design specification scope need.

But obviously, we have a group, including a champion pushing the issue
strongly who prefers to make this the MARID format.  And you also have a
completing group that already have a strong following, with a system that
"works" without all the "extras" that an XML format will impose.

So my proposal would be, from a technical standpoint, is that there should
an minimum "anchor" format.  One that defines what client logic is to be
used.

Some examples:

   <ep type=TXT LMAP=CEP prefix=_SMTP.MARID/>
   <ep type=RR LMAP=CEP prefix=_SMTP.MARID/>
   <ep type=TXT LMAP=SPF prefix=/>

It will help define the LMAP technology in place, the record type and
possible prefix to be used.  Of course, with attribute defaults, the anchor
can be further minimized.

This will have a major benefit not only because it would be small and sweet,
but also  in my view, since the majority of the systems will only need a
small sub-set of all the possibilities,  the minimum anchor format may offer
validation logic just as well:

For example, for a small mail server with one MTA, it can have:

  <ep m=208.247.131.9/>


So for this chicken and egg problem,   my recommendation balanced with real
world design implementation issues and LMAP operations as well,  is to take
advantage of an entity attribute to help minimum the format, offer
flexibility to "methods" requirements and to also help define the domain
policy as well.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com