Re: Sieve mime loop issues list

["Mark E. Mallett" <[e-mail]>]

On Fri, Mar 24, 2006 at 01:10:58PM -0000, Nigel Swinson wrote:
> > > #1: Need to deal with nested for_every_part loops. What will this do:
> > >     for_every_part { if (some test here) { for_every_part { ... } } }
> > 
> > My inclination is to ban them, or at least allow an implementation-defined
> > limit which can be set to 1. (Actually, such a limit is allowed implicitly for
> > almost anything in sieve by the base spec.)
> 
> I would like the nested for_every_part to operate on the child nodes
> of the current context body part, not always operate on all the body
> parts of the root message.  This to me is the obvious behaviour.  If Ned
> wants to (understandably) ban them from his implementation, that's fine
> by me ;o)

I agree.  Whether script writers will actually make use of such a
construct may be in question, but I am in favor of at least not
prohibiting it.  Per above, the draft could say that an implementation
must only support only 1 level of nesting but may support more.


> 
> > > #2: Need to decide if there would be a "mime" shorthand for testing the
> > > type/subtype, without requiring
> > 
> > >     if allof (mime :type "multipart", mime :subtype "alternative") ?
> > 
> > How about getting rid of :subtype and making :type check the whole thing? A
> > subtype is only meaningful in the context of a particular type; the only
> > exception to this are suffix tags, and checking those would require :matches
> > anyway. 
> >
> > And :matches can easily be used to check the primary type by itself. I see no
> > strong reason to prefer
> > 
> >     if mime :type "text" ...
> > 
> > over
> > 
> >     if mime :type :matches "text/*" ...
>  
> Although it isn't very explicit, I think I'm right in saying the
> default match type for mime is "is"?  So that means if :type matches
> against type/subtype, then I would be very confused if I wrote :type
> "text" and it didn't match against text/plain.

This because the word ":type" makes one think of "type" part of the
content type description?  (i.e., with a different :tag you wouldn't be
as confused?)  Personally I don't see it as all that confusing, but I
see the point, and a different :name would be reasonable.

 
> I suggest:
> - :type to match against type, 
> - :subtype to match against subtype
> - :contenttype to match against type/subtype

Having just one that selects the entire type/subtype string, allowing
the application of different match-types to the test, would make :type
and :subtype options somewhat redundant.  However, having :type and
:subtype don't really hurt, and are easy to implement.  But I think the
most important point is to have an option to test the entire string,
since as I mentioned

    allof (mime :anychild :type "multipart",
           mime :anychild :subtype "alternative")
and
    mime :anychild :contenttype "multipart/alternative"

are not necessarily equivalent (if the sub-tests of the first one match
different children).  Granted, there aren't that many subtypes that are
duplicated across the mime types world, and the above is not the best
example (maybe something with "xml" would be better), but that doesn't
mean we shouldn't be able to have a reliable atomic test.


> I prefer
> 
> >     header :mime
> >     exists :mime
> >     address :mime
> 
> Over 
> 
> >    mimeheader
> >    mimeexists
> >    mimeaddress

ditto

-mm-