Re: [Extra] sieve-fcc next steps

[Ned Freed <[e-mail]>]

> Hi Nedx


> On 06/10/2018 07:01 PM, Ned Freed wrote:
> >
> >> On 06/09/2018 08:49 PM, Ned Freed wrote:
> >> > Section 3.3. I suggest that for now this be made specific to the
> >> mailto:
> >> > method. If someone wants to write some requirements for tel: and
> >> xmpp: that's
> >> > fine too.

> Do you have suggestions as to how you would like to see the existing
> text modified?

On further reflection, since xmpp is only mentioned as an example an tel not at
all, I think this is OK. I'm still a little uncomfortable with mentioning xmpp
here since it might be interpreted as saying this specification  provides
everything you need to implement :fcc for xmpp - and I'm fairly sure it falls
short of this - but the value of the example seems to outweigh that.

That said, and given the lack of specificity of the specification in regards to
existing notification methods, I think it should be permissible to only
implement :fcc for a subset of the notification methods an implementation is
able to generate. So how about adding:

  An implementation MAY only support :fcc in conjunction with a subset
  of the notification methods it supports. An error errors if :fcc is
  combined with a notification method that doesn't support it.

And this in turn brings up another idea - how about adding a "fcc"
notify_method_capability (RFC 5435 section 5) that can be used to determine if
a given notification method supports :fcc? (With possible values "yes" and
"no", of course).

				Ned