1 / 8

SIEVE, IETF 64

SIEVE, IETF 64. Cyrus Daboo cyrus@daboo.name Alexey Melnikov alexey.melnikov@isode.com. 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

tamarr
Télécharger la présentation

SIEVE, IETF 64

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SIEVE, IETF 64 Cyrus Daboo cyrus@daboo.name Alexey Melnikov alexey.melnikov@isode.com

  2. 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

  3. 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.

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

  5. Notifications – admin • Editors for different documents: • Main document - Barry & Alexey • “mailto“ notification method - Barry & Michael. • "xmpp“ – Alexey and ? • "sms" -?

  6. 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?

  7. 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?

  8. 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]

More Related