Re: Summary of Issues Raised to date

Mark E. Mallett wrote:

>On Tue, Mar 16, 2004 at 03:52:45PM -0500, Yakov Shafranovich wrote:
>  
>
>>How about this:
>>
>>* Filters can have mutliple outputs (e.g. reject, delay, deliver, label, 
>>etc.). If a filter labels a message, the labeling should not dictate 
>>actions to be taken downstream, only suggest and/or provide information 
>>for such actions.
>>    
>>
>
>Sorry to be picky, but I think that's redundant.  A filter can not
>possibly command something downstream to take an action, so saying
>that it shant do so doesn't really have any weight.  Plus, not all
>labels are intended to represent an analysis.  Maybe simply note that
>labels contain comments, some of which may represent conclusions that
>can be used by downstream processors if so desired.
>
>mm
>

I see a dissonance due to combining of multiple goals.  The implementors 
on this list want
to pare out weightless specifications that appear obvious to us, the 
architects want to provide
hints about purpose.

I see mm's point but I also respect ys's wish to make clear that a wide 
set of impractical
(yet common, naieve) wishes are out of bounds.  It is easy to imagine a 
unworkable standard
that mandates things like downstream compliance with labels if we aren't 
careful.

Maybe an "unworkable approaches" section would make sense and satisfy 
everyone.

-- 
[email protected].
"Once I tried to answer e-mail in the morning, but all I could manage
to say was 'you are an idiot' so I swore off the practice" -- Elizabeth Woods