Re: [Gen-art] Gen-ART Belated LC review of draft-freed-sieve-ihave-03

(IETF list removed from cc list)

> Comments:

> A few minor nits that should not block anything:

> -- Is this a sieve wg submission or and individual submission? The
> title looks like an individual, but it's listed as a wg submission in
> the datatracker. (The answer to this does not change my review in any
> way; it's just a procedural question.)

As Alexey already commented, this is a WG document despite the name. However,
given the confusion this has caused (I believe this is the third time I've seen
this question raised) I'm making a note that while it's too late for this
document, in the future it's much better to change the document name when its
WG-attachment status changes. Lesson learned.

> -- Don't forget the new boilerplate.

I haven't forgotten it, I just don't know what to do about it. This document
was processed using xml2rc 1.33, which is the latest release. There's a
preliminary version of xml2rfc for those "living on the edge" that reportedly
generates the newer-but-apparently-still-not-quite-right-and-going-to-change-again
boilerplate.

I spend much of my working life "living on the edge" in terms of running
prerelease versions of messaging software, directory servers, and even
operating systems. I have no choice in this - it's my job to do so. This
provides me with ample excitement and I really don't need or want any more. I
therefore make it a firm policy not to run betas of ANYTHING ELSE unless I'm
forced to.

IMNSHO IETF management has completely screwed the pooch on this one. Either the
new boilerplate, previously discovered but recently reported flaws
notwithstanding, is sufficiently better than the old to be worth using, or it
isn't. If it is it should be pushed out and xml2rfc 1.34 should be finalized
and released ASAP. If it isn't it should be withdrawn and all deadlines and
other bureaucratic nonsense associated with it rescinded.  Really, there is no
viable middle ground here. (John Klensin's posting on this was, if anything,
too kind.)

In any case, I'm not going to update to a beta xml2rfc unless I'm specifically
told by the IESG that I have to. And if that means the I-D thing won't accept
my revisions, so be it. And I really don't think this is an unreasonable
position to take.

> -- section 4, last paragraph: It might help to put this statement up
> front in the document, since it significantly constrains the scope.

Actually, it doesn't really do that, but this is something you'd only know if
you followed the design philosophy and overall development arc of Sieve. So far
there have been a total of 10 Sieve extensions approved as proposed standards.
And there are about 7 more in various stages of development. Of these exactly
one document - variables - specifies something that's incompatible with being
enabled by ihave. (And to be fair, the reason use with variables is prohibited
is not because it couldn't be done, but rather that ir precludes certain forms
of precompilation we believe are useful for high performance Sieve processing.)

More generally, extensions which change the underlying grammar, while not
flatly forbidden (no reason to box ourselves in here), are so strongly
discouraged that the few times such things have been suggested they have
immediately gone down in flames. One of the key advantages of Sieve is that you
don't have to muck with your parsed in order to add support for new extensions.
This has led to far less resistance to getting extensions deployed than I've
seen in any other language I've tracked. (And before I started doing IETF
standards work I used to be involved in ANSI/ISO language standardization.)

In other words, it is actually quite likely we'll never see another extension
that is incompatible with ihave.

So unless I see some additional commentary saying this is worth promoting
to a more prominent place, I'm going to leave it alone.

				Ned
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art