Re: draft-freed-sieve-in-xml status?

[Ned Freed <[e-mail]>]

> On Sun, Dec 14, 2008 at 6:06 PM, Ned Freed <[e-mail]> wrote:
> >> i note that the draft describes the infoset rather than defining it in
> >> the standard way. is there a reason for this decision?
> >
> > I don't know what "the standard way" is you're referring to. Perhaps you
> > could provide a reference to an RFC where this has been used?

> AIUI XML is maintained by w3c (rather than IEFT) so is a
> recommendation. http://www.w3.org/TR/xml-infoset/ is the current
> document.

Quite true, however, the IETF has its own specification for XML is supposed to
be used in RFCs: RFC 3470. And while infosets are mentioned as one approach to
specifying things about an XML format, there's no recommendation, let alone
requirement, that they be used.

> > This document is a little unusual in that it's defining a mapping of, if you
> > will, a non-XML infoset onto XML. As such, the natural approach seemed to be to
> > first discuss the structure of the language being mapped, then explain the
> > mapping, and finish up with additional unique-to-XML semantics.

> i agree that most of this arangement is natural. it's just jumping to
> a schema seems - to me - a little premature and inflexible.

First of all, the use of XML Schema is in fact too inflexible to be allowed
to continue. The next revision will use Relax instead.

But I'm sitll a little confused as to what you're asking for here. If you're
asking for removal of the explicit inline XML syntax examples in favor of a
more abstract approach, I'd be fine with that if there's a WG consensus to make
such a change.

Beyond that, however, lies a slippery slope. If what you're after is a
restatement of Sieve elements and semantics in infoset form, that is not going
to happen on my watch. RFC 5228 is the definitive source of information about
such things. It may be a little awkward for implementors to have to interpolate
back through the specifications to get at the meaning of things they have in
their XML, but the alternative of having two separate specifications that are
bound to be inconsistent in some way or other is much worse.

> > This approach is perhaps not the best choice for someone coming at this trying
> > to get at Sieve semantics starting with XML, but I believe consumers of the
> > document with that mindset will be distinctly in the minority. The main focus
> > here is to provide people familiar with Sieve a means of mapping Sieve to XML
> > so that XML tools can be applied.

> my experience is entirely opposite

> developers that use the java libraries i work on have good XML but
> lack a good understanding of underlying mail technologies (for example
> sieve). there is a large and growing requirement for integration
> between mail and enterprise systems (typically coding in Java and .NET
> but also ruby and python). developers from enterprise backgrounds are
> typically strong on web+xml but very weak on mail.

Yep, I've seen a lot of this as well. And the problem emcompasses far more than
Sieve: For example, a lot of people who are unfamiliar with email don't
understand very basic concepts such as the separation between envelope and
message content. (This particular issue actually pokes through into Sieve in
the form of whether an envelope or header test is appropriate.)

But here's the dilemma: This stuff is complicated and in some cases fairly
subtle. This in turn means that the reiteration of even a subset of the
underlying design principles that implementors need to know takes up a lot of
space and will still fall short of the mark of giving the necessary guidance.
But it may lead to the belief that reading this specification (or for that
matter this one and RFC 5228) is in fact sufficient to understand how to use
Sieve. It quite simply isn't.

IMO what's needed is a proper architectural specification for email. We're
trying to get one of those done, but progress has been very slow.

> i think that there needs to be an equal focus should be on allowing
> mainstream enterprise developers familar with XML and web technologies
> to apply familiar methods and techniques to mail. this will allow
> easier and more efficient editor development.

I wish it was this easy. The mistakes I see such people make regularly cannot
be addressed by reiteration of Sieve's design here.

> FWIW i think that the draft works quite well from this perspective but
> an annotated schema

I'm far from convinced that an annotated schema will solve this problem. But in
any case, annotatiing the schema would be fine with me. I'll try and do that
when I post an update with the Relax schema.

> with an appropriate open source (eg MIT) license
> would be very useful way of introducing developers to Sieve.

I've already commented on this in a separate response.

> > Had this been the more usual case of simply defining an XML formal, I have to
> > admit that I would have gone with the informal approach used in, say, RFC 2629.
> > I'm not all that keen on lots of formalism  - IMO it often hinders
> > understanding more than it helps.

> IMHO the problem is getting the right level of formalism

> more modern approaches to specification (eg Atom
> http://www.rfc-editor.org/rfc/rfc5023.txt etc) tend to make the schema
> only informative and the description of the infoset normative. this
> would be more flexible for example, by allowing different schema
> langauges to be used, alterations in namespace or additional
> annotations in foreign vocabularies.

But doesn't this fly in the face of your earlier suggestion of doing this
by annotating the schema?

				Ned