Subject: RE: Comments on draft-ietf-marid-core-01 xml use

From: Greg Connor <[email-masked]>
Date: Sun, 13 Jun 2004 09:35:04 -0700

--Jim Lyon <[email-masked]> wrote:

>
> Arguing against XML, Alan DeKok says:  "Does that extensibility have to
> exist in DNS records?  I think
> that's the point of contention, here."
>
> It seems to me that as we invent extensions, the DNS records need to
> either contain the extension data, or contain some kind of information
> that points us to the extension data outside of DNS.
>
> It also seems reasonable that as extensions are invented, if the amount
> of data that needs to be communicated is small, it should probably go
> in-line in the DNS record. If the amount of data is large, it probably
> shouldn't.  This would argue that extensions that define flags and small
> constants should certainly go in the DNS record, and extensions that
> carry certificates as data almost certainly should not go in DNS.  In
> between, we have things like data containing email addresses (probably
> in DNS), and data containing public keys (possibly in DNS, but probably
> not).
>
> The point of using XML is to have confidence that we have sufficient
> syntactic flexibility to describe the probable future extensions,
> whether they contain data in-line or they contain pointers to external
> data.

Jim and I (among others) discussed this a bit off-line between sessions of 
the interim meeting.  Here are my thoughts on the subject.

1. New features may come along later, that allow more ways to include 
messages that might otherwise not be validated, or to reject messages that 
might otherwise be included.  Domain owners will want to use the features, 
and implementers will want to support them.

2. XML provides "syntactic extensibility" but not "feature extensibility". 
It is possible to use this to include other "interesting" data, but the new 
data should not alter the output of the validation function.  There is no 
magic way for XML to add new features to old implementations, or alters the 
behavior of existing features.

3. IF we decide we might need new features later (i.e. if we cannot rule 
out that we may need them) it is to our benefit to build in some manner of 
"feature extensibility".  This would allow use of the new feature if both 
the receiver and domain owner support it.  But, there must be a sensible 
way for old implementations to fall back on the core feature set while 
still honoring the domain owner's wishes, to the extent possible.

4. Adding new features on the fly doesn't have to be a scary thing.. it 
just requires some forethought in the spec that tells existing 
implementations how to navigate around the features it doesn't yet 
understand.

5. We should also take some precautions to ensure that typos are not 
mistakenly processed as "unknown features".

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

1. There should be a way to carry "extra data" that does not change the 
results of the authorization function (such as comments, contact names, 
pointers to the URL of a failure explanation message, etc).  The receiver 
is free to use or ignore these.  If they are used, they should not alter 
the actual result.

In XML the "extra" information could be added as a new root element, or a 
child of "ep" that is not "out", or a child of "out" that is not "m".  In 
SPF, the "extra" data is added as a modifier like "extra=hi_there".

2. New "feature" nodes may be added later, as long as there is a sensible 
way to route around them if they are not implemented by the receiver.  The 
"fallback" or "alternate" behavior should be specified by the domain owner. 

For example, in XML this could be implemented as:
  <ep><out><m default=fail>
    <a/>
    <mx/>
    <foobar alt=ignore/>
  </m></out></ep>

In SPF the fallback could be defined by a modifier that comes right before 
the unknown mechanism, such as v=spf1 a mx alt=ignore foobar -all

3. The "alt" tells the receiver what to do if the feature we are trying to 
use is not supported.  Possible values might be:
  alt=ignore  OK to ignore the unknown feature and continue processing the 
record
  alt=unknown If you can't understand the new feature, stop and return 
unknown
  alt=fail    If you can't understand the new feature, stop and return fail
  alt=error   If the feature is unknown, stop and return an error

If the fallback or alternate is not specified, the receiver should assume 
that the unknown feature or mechanism is a typo and abort processing of the 
record (alt=error).  Therefore it is the responsibility of those using the 
new feature to explicitly define their fallback behavior... not to do so 
will be considered an error.

4. Mechanisms in the original core feature set (as defined in the published 
spec) must not have an alt= tag.  It is not possible to skip over core 
features.  Any implementation that does not implement all features in the 
original core set should be deemed non-compliant.

5. A newer version of the spec may be published in the future, which rolls 
in new features and promotes them to "core" status.  If there is a new spec 
that collects new mechanisms and features, it should have its own URI and 
possibly its own prefix.  When publishing records in the new URI or new 
prefix, the alt= tag is not needed (and may be considered an error) because 
those features are now "core".  Similarly, receivers that are compliant 
with the future rolled-up spec must honor all features of that spec.

Why are we leaving it up to the domain owner to decide what the fallback 
should be?  Why wouldn't it work to just decide on a single fallback and 
run with it?

Consider two companies that might use domainkeys (or whatever feature). 
Company A might say "All our mail uses domainkeys.  If it doesn't have 
domainkeys, reject it.  If you are not able to check for domainkeys, all 
our mail should come from our address space anyway, so use "a mx ptr -all". 
In that case it makes sense to put domainkeys up front, because they are 
giving us the OK to reject mail without it, even if it comes from their IP 
space:
  v=spf1 alt=ignore +domainkeys alt=ignore -domainkeys:unsigned a mx ptr 
-all

Another company might choose to offer domain keys as a way to include mail 
that would otherwise be excluded (in other words, change their ?all to a 
-all).  Not all their mail is signed, but if it doesn't meet "a mx ptr" it 
must be signed.  Receivers who can't process domainkeys should use ?all.
  v=spf1 a mx ptr alt=unknown domainkeys -all

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?

Thanks
gregc
--
Greg Connor <[email-masked]>

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 13 Jun 2004 14:06:44 -0400

----- Original Message ----- 
From: "Greg Connor" <[email-masked]>
To: "Jim Lyon" <[email-masked]>; <[email-masked]>
Sent: Sunday, June 13, 2004 12:35 PM
Subject: RE: Comments on draft-ietf-marid-core-01 xml use

> [clip]

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