>> 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