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

[Ben Campbell <[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art