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

From: Ken Murchison <[email-masked]>
Date: Tue, 17 Jul 2018 17:32:20 -0400

Hi Ned,

Poking you on this so I have a better idea what you're looking for and 
we can update the WG on our status on Thu morning.

On 06/15/2018 06:45 PM, Ken Murchison wrote:
> 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?
>

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ned Freed <[email-masked]>
Date: Thu, 19 Jul 2018 07:32:57 -0700 (PDT)

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

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