Sieve ietf 64
1 / 8

SIEVE, IETF 64 - PowerPoint PPT Presentation

  • Uploaded on

SIEVE, IETF 64. Cyrus Daboo [email protected] Alexey Melnikov [email protected] 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

PowerPoint Slideshow about 'SIEVE, IETF 64' - tamarr

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

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]