Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords]

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 21 Jun 2004 15:47:12 -0700

> In light of that, I see that each of the three postings argue 
> that the 
> SPF syntax can't handle something that it wasn't designed to handle.  

That is why it would be an extension.

Seriously, why do you think 'out of scope' is an argument here? If it
was in scope it would not be an extension.

People have started to work on every one of the proposals made. I would
expect some of them at least to be proposed as subject matter for a
MARID extension group or a successor group. A detailed writeup of the
S/MIME proposal will be submitted before San Diego.

The problem with the SPF syntax is that it takes the APL approach.
Sure you can create a great syntax for one single purpose with 
a syntax that assigns functions to character symbols. But in language
design terms APL made remarkably impact for a language so widely used.

LISP on the other hand has spawned a whole familly of languages, 
ML, Prolog, Scheme, Orwell and the main advance Java made over C was
to abandon some of the more obfuscated syntax forms.

> 3) Phillip Hallam-Baker's examples
> These examples are a clear extension into other approaches.  None of 
> these examples has anything to do with domain authentication 
> of an IP.  
> To quote Phillip about such extensions: "...the number of degree of 
> freedom are huge".  To this end, these examples beg for 
> something much 
> larger than the part of the problem the current projects ever set out 
> to handle.

I was referring to the choices when you embedd the necessary data
structures in SPF. With XML or S-Expressions or any similar formal
data encoding scheme I can write a schema that most people can follow
without even reading the spec. There is much less room for mistakes.

> I understand the desire to design a more comprehensive mail policy 
> format.  And I understand the desire that such a format be extensible 
> for future approaches that are now only contemplated.  However, the 
> proposed XML syntax doesn't achieve this either:  While it is 
> true that 
> XML provides a much richer syntactic framework in which to extend an 
> original document format, it says nothing about the semantic 
> meaning of such extensions.

That is not the objective.

Your argument is like saying, "I understand that a prius has better
fuel efficiency than an SUV, but a Prius is no better since it does
not run on water"

> The myriad of possible extensions that have been expressed, 
> and their subtle effects of the semantics of the original format make 
> it clear that defining how clients are to interpret future extensions 
> would be difficult.

It is perfectly simple to interpret the presence of the S/MIME extensions.
If you understand the schema you follow that understanding, otherwise you 
ignore the information - like you would if you do not understand MARID.

> When a larger framework for mail policy 
> emerges, SPF can easily add a modifier for pointing to it.  
> Or perhaps 
> SPF will have run its course, and the newer framework will 
> simple take 
> over.  Either way is fine.

No, it is not fine. I cannot tell the media in June that I am enthusiastic
about MARID, then tell them in August that MARID is obsolete and must be 
abandonded.

---

From: Roy Badami <[email-masked]>
Date: Tue, 22 Jun 2004 00:34:01 +0100

>> However, the proposed XML syntax doesn't achieve this either:
    >> While it is true that XML provides a much richer syntactic
    >> framework in which to extend an original document format, it
    >> says nothing about the semantic meaning of such extensions.

    Hallam-Baker,> That is not the objective.

I think it's important, though.  If you have an extensible language,
you have to define what a MARIDv1 interpreter should do when it
encounters an extension it doesn't understand.  Should it ignore
attibutes it doesn't recognize, or refuse to interpret the policy at
all and simply return unknown?  Similarly for unrecognized elements...
But if you ignore them, then should they still be descended to look
for elements that _are_ recognized?

SPF, as I understand it says that unrecognized mechanisms cause the
policy to return unknown, but unrecognized modifiers are ignored.
It's not a paricularly flexible extension model (and could probably be
improved) but at least it defines the semantics...

I'm largely agnostic on the syntax issue, though I personally find the
SPF syntax more readable than the Caller ID syntax.  But I think any
extensible syntax proposal (and both SPF and XML fall into this
category to greater or lesser degrees) needs to define what a MARIDv1
parser does when it encounters a MARIDv2 or MARID+extensions record.

Saying that policies with unrecognized attributes or elements can't be
interpreted at all by a MARIDv1 parser is a sufficiently strong
deterent against deploying extensions that you'd be better off putting
your extensions in a completely new record so as to avoid preventing
all the MARIDv1 parsers out there from being able to read even the
basic MARIDv1 semantics of your policy.

The question then is whether there's some framework for extensions
that allows the construction of post-MARIDv1 policies which are still
useful to MARIDv1 parsers, without constraining the semantics of what
can be done in extensions to the point of causing people to deploy new
records anyway.

I'm not saying this can't be done, or that it shouldn't be done, but
I'm skeptical of the benefits of an extensible syntax in isolation of
a defined model for backwards compatibility.

For instance, considering XML attributes (since they're a simpler
problem than elements), would it make sense to split the attribute
name space into two or more classes (perhaps by initial letter) so
that unrecognized attributes in one class are ignored, and
unrecognized attributes in the another cause the policy as a whole to
be ignored.

Kind of like the X.509 distinction between critical and non-critical
extensions...  

Actually, I think SPF syntax could benefit from such an enhancement,
too.  Extension mechanisms and extension modifers could both carry a
flag to indicate whether they're critical.  Non-critical extensions
are ignored if not understood; critical extensions cause the policy as
a whole to be ignored if not understood (and hence return unknown).
Currently all extension mechanisms are implicitly critical and all
extension modifiers are implicitly non-critical, but there's no reason
why that needs to be the case...

	-roy