Dave Crocker wrote:
> So let's hear what constraints and requirements folks deem
> essential for this meta-syntax, and why. And given that the spec
> already has a proposal, I'll suggest that anyone claiming it is not
> sufficient would help things a lot by explaining why.
In general, the draft misses clear indications and guidelines for the
implementation. There is not even a single example. Let me quote an
implementor's perspective: "People should be able to take 5 minutes of
their time to briefly look through the document, see exactly what's
going on. Make it crystal clear, right up front, how you go about to
implement this, and leave the technical details and dry, formal
specifications, to some other part of the document."
Very nicely put. This is the main thing I think is wrong with the document.
Another point: Is it useful to retrieve the untagged mailbox value?
(E.g. could that be a way to patch, say, ezmlm?) If it is, it would be
helpful to have a syntax that delivers a good level of confidence that
a given token is a BATV-tagged representation of some tagging scheme
even if that was not known at implementation time.
And this is what I was getting at when I said that I'm concerned that the
labelling is insufficiently unique in format. Mind you, I'm not proposing a
change here, merely expressing concern.
Should the
tag-types be loadable at runtime from some configuration file? Are
they case sensitive?
No, that's the wrong way to do it because nce those configurations are deployed
it becomes very difficult to add new schemes. This is why the syntax needs to
be distinguisable without having to look for a known tag at the beginning.
Ned