Subject: Re: [Extra] sieve-fcc next steps

From: Ned Freed <[email-masked]>
Date: Thu, 06 Sep 2018 07:09:06 -0700 (PDT)

I finally got a chance to take a look at the latest version, and I have
a few remaining comments.

The introduction says:

   It is sometimes desirable to have an archive of
   the messages generated by these commands.

This is a bit nonspecific and therefore confusing. I suggest changing it to
say something like:

  It is sometimes desirable for a Sieve user to maintain an
  archive of the messages generated by these commands.

The document contains the following example illustrating the use of the "fcc"
notification capability:

  if notify_method_capability "xmpp:" "Fcc" "yes" {
    ...

Although this check makes logical sense, it exposes an issue with the
underlying semantics of both notify_method_capability and valid_notify_method
in regards to the notification-uri and notification-uris parameters,
respectively.

I'll first note that while "xmpp:" is a syntactically valid URL according to
RFC 5122 and makes sense in an "fcc" capability check, it does not make
sense in an "online" capability check - for that the URL needs to include
the user whose online status is being checked.

Additionally, according to RFC 5435 section 4, the valid_notify_method test:

   MUST perform exactly the same validation as would be performed on the
   "method" parameter to the "notify" action.

And while the validation requirements aren't explicitly specified anywhere
AFAICT, in our implementation at least the :method URL has to specified a
recipient for the notification. And in fact RFC 5435 section 3.2 actually gives
"XMPP [XMPP] URI containing an XMPP identifier [XMPP-URI]" as an example, as
opposed to just saying "XMPP" URL.

And mailto: URLs have exactly the same issues: "mailto:" is syntactially
valid but makes no sense in an online capability check or as a :method
parameter value. RFC 5436 doesn't come out and say a recipient has to
be specified, but section 2.1 and the second bullet point of section 2.7
kind of assume it.

The situation is further complicated by the example in RFC 5435 section 4:

             if not valid_notify_method ["mailto:",
                     "http://gw.example.net/notify?test"] {
                 stop;
             }

Since "mailto:" lacks a recipient it's not a valid URL to specify in a :method
parameter to enotify, and so in our implementation at least it causes the test
to fail. (Note that the RFC doesn't actually say what the results of this test
are supposed to be, but I would assume it was expected to succeed.)

As to what to do about all this, I'm not sure. As far as the current draft is
concerned it probably suffices to add a sentence saying that the URL doesn't
need to specify a recipient or anything else for the "fcc" capability check.
But does nothing to address the underlying issues.

Moving on...

I was thinking that it would be good to note that the corresponding extension
must be enabled in order to use :flags, :create, and/or :specialuse with :fcc,
but repeating that in each section seems tedious. How about putting a note to
this effect after the example in section 3.5.4?

In regards to section 4 and our implementtion, you could say something like:

4.2 Oracle Communications Messaging Server

   The Oracle's Messaging Server product supports the :fcc extension in
   conjunction with both the notify and vacation extensions. The implementation
   meets all the requirements given in this document. The product also
   supports the imap4flags extension so the :flags may be used in conjunction 
   :fcc.

That's it for now.

				Ned