[Top] [All Lists]


2002-01-28 09:52:36

Hi!  I've just read the sieve-notify-01 draft closely for the first time.
Here are some questions and comments.

      - It has expired, and I notice that there were some discussions on the 
        mailing list last July and a promise of a new version soon -- what is
        its status now?

      - The draft's header lists the title incorrectly as

3.1 Notify action

      - I'd have expected an IANA registry that lists and fixes the
        methods and options and corresponding require: tags.

        Having these implementation-defined features without a way
        of verifying them makes me uneasy.

        Everything else in sieve is quite predictable; scripts as a whole
        either fail because they use unimplemented features or have well-defined
        meaning -- and here, all of a sudden, is this big, powerful,
        implementation-defined area that sends out messages that sometimes
        costs money without the author being able to automate verification
        that what they think a script means actually means it.

      - > The format of the notification is implementation-defined.
        > However, all content specified in the notify action, including Sieve
        > actions taken on the message, SHOULD be included.

        If I understand this correctly, you would like the notification to
        include a complete log of the sieve actions taken on the message, which 
        goes beyond "the content specified in the notify action"; it would
        also include pieces of sieve script before and after the line that
        issues the notification.  Right?

      - > If errors occurred in another action they SHOULD be reported
        > in the notification.
        And later:
        > Failures of other actions MAY be reported in the notification.

        This is in direct conflict with a rule in the sieve RFC 3028:

        > When an error occurs in a Sieve script, all processing stops.  


        - I would like $env-from$ (and related variables, if you add them)
          defined with a reference to the sieve "envelope" operator, not to
          RFC 2?821.  (The envelope used in sieve might not be an SMTP 
        - I strongly agree with the past discussion asking for more control
          over the formatting and over which parts are chosen.

        - In practice, I think limiting the length even of $from$ (and its
          related variables) and certainly of $subject$ would be a good thing.
          (Alternatively, allow implementation-defined limits on these things. )

          When I have completely free hand, I tend to truncate single-line
          texts in the middle, like this:

                Subject: [mailing-list] This is a long ta ... cess and a frog.
          It would be nice to be allowed to do this, but it's kind of
          difficult to specify.  (Maybe something is truncated in an
          implementation-defined manner to no more than N characters.)

          In response to July's discussion of whether this should be
          counting chars or bytes, for SMS, it only makes sense to count
          output bytes, not chars, since the limits one is trying to fit
          into are byte limits.

3.2 Denotify Action

      - This surprised me.  Couldn't generic sieve control structures be used
        to accomplish the same with fewer constructs and thus a simpler 
        I'd hate to see a precedent set where other, future extensions, in 
        to their specified action, also include an action-specific cancellation

        I don't really have much experience with this mechanism; maybe it's 
        if you write a lot, and complex, sieve scripts.  But this is supposed to
        be simple and small; I don't feel like this powerful mechanism fits 


Jutta Degener

<Prev in Thread] Current Thread [Next in Thread>
  • draft-martin-sieve-notify-01.txt, Jutta Degener <=