AFAIK the specific namespace prefix that gets bound to the namespace name is
not something that can or should be standardized. Rather, it is declared on
a
per-document basis using an xmlns attribute. Any agent out there that
supports
namespaces should support the use of xmlns to pick whatever prefix a given
document binds to the urn:ietf:params:xml:sieve namespace.
this choice of namespace prefix is the root cause of incompatibility
between namespace aware and unaware parsers
for example, 'sieve:abc' is just a name to unaware parsers while aware
parsers understand this as a namespace prefix and a local part. the
namespace prefix is resolved to a URI and that is used as the basis of
comparison. specifing a standard prefix (for example, sieve) ensures
that in both cases equality works as expected.
This is finally something I can understand as a rationale for wanting
to define a standard namespace prefix.
This doesn't appear to be specific to Sieve-in-XML either - if this makes sense
it should be something we're doing in similar XML specifications. So the first
thing I did was check out a bunch of other RFCs - not an exhaustive search but
I did check a dozen or so - to see if this has been done and if so, how. But
AFAICT this has not been done elsewhere. The closest thing to it are statements
of the general form "this document uses the prefix foo to identify the bar
namespace throughout". This falls far short of a "MUST use foo: as the
namespace prefix" or even a SHOULD. In fact some RFCs go out of their way to
make it clear the use of a particular prefix is NOT being standardized.
For example, RFC 5023 (ATOM) has this to say:
This specification uses the prefix "app:" for the namespace name. The prefix
"atom:" is used for "http://www.w3.org/2005/Atom";, the namespace name of the
Atom Syndication Format [RFC4287]. These namespace prefixes are not
semantically significant.
Note that last sentence and the lack of any compliance language.
In other words, this is apparently not current practice for IETF use of XML.
But should it be? I decided the answer to this general question is a little
above my pay grade. Fortunately, the IETF has this thing called the XML
directorate, where people with XML issues can reach out to folks with real
expertise.
I sent a query to the directorate yesterday, which included your statement
verbatim, and received two responses almost immediately, from Tim Bray and Lisa
Dusseault. (Tim you probably know - he's one of the coauthors of the XML
namespace specification, among other stuff. And Lisa is the area director
responsible for this WG.) I've asked for permission to resend their responses
to the Sieve WG, but in the meantime what I can say is that both were opposed
to doing this on the grounds that prefixes cannot be tied down this way because
of the potential for conflicts.
Given the apparently lack of stated support from others in the group and the
lack of support for this from the directorate, I now regard this issue
as closed.
for the class of application (enterprise mail servers is a name that's
sometimes used but quite possibly that's not familiar to others in the
group), unfortunately it is
Robert, developing enterprise and ISP class mail servers is what I do for a
living. I've been doing it for over 20 years now. So I think this is
something
I might know just a little bit about.
i am not unaware of your background but i fail to see why i should
respect your arguments when you are so clearly uninformed about a
class of mail server which are almost a decade old now
And by the same token, why should I respect any of your arguments when you
clearly have minimal knoeledge of overall email architecture, Sieve semanticss,
or IETF processes?
But really, this entire discussion has gone very far afield. Like it or not,
Sieve is intended to be a language used to process email messages at or
around
the time of final delivery.
The fact that it can be adapted for other uses may
be interesting to you but simply is not relevant in the context of the work
this group is chartered to do.
is this http://www.ietf.org/html.charters/sieve-charter.html the charter?
Yes.
Ned