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

[Ben Campbell <[e-mail]>]

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