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

--Jim Lyon <jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com> 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 <gconnor(_at_)nekodojo(_dot_)org>