SIEVE, IETF 64 - PowerPoint PPT Presentation

Sieve ietf 64
1 / 8

  • Uploaded on
  • Presentation posted in: General

SIEVE, IETF 64. Cyrus Daboo Alexey Melnikov Documents ready for IESG. Vacation Clarify how hash is constructed when the :subject parameter is not specified. Default autoreply subject when the original message had no subject. Spamtest IMAP Flags

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Sieve ietf 64


Cyrus Daboo

Alexey Melnikov

Documents ready for iesg

Documents ready for IESG

  • Vacation

    • Clarify how hash is constructed when the :subject parameter is not specified.

    • Default autoreply subject when the original message had no subject.

  • Spamtest

  • IMAP Flags

  • Relational

  • Edit header

  • Body

    • Waiting for comparators

Base document

Base document

  • Add text about stripping leading/trailing spaces in the header test.

  • Sort out text on comparators.Clarify that comparator works as a black box for matching purposes.

  • Clarify that matching works on Unicode characters.

  • Matching is related to substring operation for a collation (if not available for a collation - error)

  • Define ABNF for MATCH-TYPE, etc.



  • Collation/lowercase/uppercase issue: US-ASCII only or Stringprep profile?

Notifications admin

Notifications – admin

  • Editors for different documents:

    • Main document - Barry & Alexey

    • “mailto“ notification method - Barry & Michael.

    • "xmpp“ – Alexey and ?

    • "sms" -?

Notifications issues page 1

Notifications – issues (page 1)

  • Remove denotify (many voices in favour). This will also remove the notify ":id" parameter.

  • Need a way of extracting message body like in the original Tim Martin's draft?

    • Kjetil has suggested a way, but "body" extension explicitly prevents setting of variables from body.

  • The notification method parameter is optional. What should be done when it is not given? Is it Ok for an implementation to do nothing, if no default is configured?(suggested by Michael Haardt)

  • Handling of unrecognized notification methods (URI schemes) - error or ignored?

  • Require a capability for notification methods?[I personally don't want to - what if notification method is part of a user's config and stored, say, in LDAP?]Or maybe we need a test if a particular notification method is available?

Notifications issues continued

Notifications – issues (continued)

  • Suggestion to add :from (Michael Haardt)

  • Should we allow to suppress identical notifications? (Like suppressing identical copies on fileinto)

  • Options versa extending URIs.

    • Do we need options? (sounds like we do)

    • Do we want to turn :priority and :from into options?

Refuse reject


  • Some minor editorial changes needed.

  • Should we use one action that does MDN, DSN or protocol level refusal?

  • If the answer to #2 is "yes", there are several options what to do with the document:

    • keep reject capability, change the reject action to allow it to generate DSNs/protocol level refusal

    • change the capability name for the combined reject (e.g. we can use "refuse"), keep using the reject action. Define what to do if both "reject" and "refuse" capabilities are required.

    • obsolete "reject" action and start using "refuse". New capability name.[selecting a, b or c might affect references in "vacation" draft]

  • Login