BTW, and for the record, this discussion addressed all of my comments.
Thanks!
Ben.
On Dec 11, 2008, at 1:20 PM, Ben Campbell wrote:
On Dec 11, 2008, at 11:08 AM, Ned Freed wrote:
(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.
Okay--no problem. It certainly does not make sense to change the
name of the draft at this stage.
-- 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.
No problem here--the only reason I pointed out was to make sure
people were thinking about it.
-- 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.
Understood, no problem.
Ned
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
