ietf-mta-filters
[Top] [All Lists]

Re: Comments on draft-daboo-sieve-mime-00.txt

2004-03-15 12:59:35

Hi Ned,
Thanks for your comments:

--On Monday, March 8, 2004 9:22 AM -0800 ned(_dot_)freed(_at_)mrochek(_dot_)com 
wrote:

| Having said that, I think the specifics of how this was done aren't
| right. First, as presently written this specification only extends the
| header test, and it does so by creating an entirely new test. But there
| are two other tests that are equally applicable to inner headers: exists
| and address. Either similar "mimeexists" and "mimeaddress" tests need to
| be added (and perhaps "mime" changed to "mimeheader"), or this needs to
| be done within the existing tests by adding a :mime parameter. I'm
| indifferent as to which one of these approaches is chosen, but we do need
| one of them.
|
| Second, I really don't like the use of an optional middle parameter to
| specify that the test is to be performed on a parameter value. This sort
| of thing is why we have labelled parameters: It should be done as
| :parameter or something similar. As for the use of a null parameter-names
| value to indicate a test of non-paramer material, this can done with
| :parameter as well, but I do worry that this is a bit tricky. OTOH, I
| haven't been able to come up with a differenent way to do it that I like
| better.

OK - here is another solution to the syntax. What I'm proposing is a mimeheader test that takes the following parameters:

:name - the name of a specific MIME header to test (can be a list of names)
:parameter-name - the name of a specific parameter name to test (can be a list)

:exists - test the existence of the specified items

:text - do comparisons against the content of the entire MIME header selected :value - do comparisons against the value of the MIME header, excluding parameters
:parameter-value - do comparisons on parameter values only

In the case of the later three parameters a comparator and text to compare against are also required, in the case of :exists, no additional items appear.

What I've done below is to enumerate the type of tests one might want to do with MIME headers together with new sample syntax for how those would appear in a SIEVE script:

1) Test the presence of a specific MIME header:

   if (mimeheader :name "Content-Foo" :exists)

2) Test the presence of a specific parameter in any MIME header:

   if (mimeheader :parameter-name "filename" :exists)

3) Test the presence of a specific parameter in a specific MIME header:

if (mimeheader :name "Content-Disposition" :parameter-name "filename" :exists)

4) Test for text anywhere in a specific MIME header

   if (mimeheader :name "Content-Disposition" :text :contains ".exe")

5) Test for text only in the value (not parameters) in a specific MIME header

   if (mimeheader :name "Content-Disposition" :value :contains "attach")

6) Test for text in any parameter values only in a specific MIME header

if (mimeheader :name "Content-Disposition" :parameter-value :contains ".exe")

7) Test for text in a specific parameter value only in a specific MIME header

if (mimeheader :name "Content-Disposition" :parameter-name "filename" :parameter-value :contains ".exe")

8) Test for text in any MIME header

   if (mimeheader :text :contains ".exe")

9) Test for text only in the value (not parameters) in any MIME header

   if (mimeheader :value :contains "7bit")

10) Test for text in any parameter values only in any MIME header

   if (mimeheader :parameter-value :contains "us-ascii")

11) Test for text in a specific parameter value only in any MIME header

if (mimeheader :parameter-name "filename" :parameter-value :contains ".exe")

I think the above deals with the issues you describe, except for the 'address' test. Arguably there are several different formats for header content that one might want to test against, so I wonder whether we need this to be extensible in some way. Certainly for the time being we could have a 'address [ADDRESS-PART]' parameter in mimeheader as well.

| Third, some references probably needs to be made to RFC 2231 and how to
| handle encoded parameters. I think the right answer here is to handle
| this the same way we already require that encoded words be handled.
|

Is it OK to simply require the concatenation of parameter value continuations that have been split according to 2231 syntax? Would you want a test to specifically look for the language information?

--
Cyrus Daboo