Notwithstanding any confusion that may have entered the xml specs I would
suggest that:
An MTA looking to use a MARID record be permissive in all respects.
An MTA that is verifying its own MARID configuration be very restrictive and
do full validation on synyax and schema compliance.
Being permissive can be a problem, a lot of problems in the internet specs
comes from applications that have to take account of slop.
-----Original Message-----
From: Andrew Newton [mailto:andy(_at_)hxr(_dot_)us]
Sent: Thu Jun 03 22:16:40 2004
To: Ted Hardie
Cc: Jim Lyon; Douglas Otis; MARID
Subject: Re: Comments on draft-ietf-marid-core-01 xml use
On Jun 3, 2004, at 8:10 PM, Ted Hardie wrote:
As an aside, one of the options is to use
urn:ietf:params:xml:schema:marid:m1,
rather than marid-1. Some folks might find it easier to extend
underneath
the schema with this format; it doesn't change the extensibility
considerations,
at least as I read them.
I think this should be 'ns' and not 'schema'. These are XML namespace
declarations and not schema declarations. XML Schema is simply the
language being used to specify the validity of the XML instance, but an
implementation should certainly be free to go about XML validity in any
manner it wants so long as it is compliant. To be true to the first
part of the "be liberal in what you receive and conservative in what
you send" mantra, I actually recommend turning schema validation off
(plus, you get better performance).
Plus, the BCP 81 (is that right?) registry does not allow
sub-registries. In other words, each URN must be registered. There
can be no registration for "every URN under marid:". This is how Mr.
Mealling has described it to me when this came up in GEOPRIV.
I do think the extensibility considerations will need more work. This
requirement:
"A program MUST ignore any element or attribute whose meaning it does
not
understand." is very clear, and I appreciate that kind of clarity.
The processContents="lax" is a departure from the SPF model. Is this
intended?
-andy