[Extra] Re: Working Group Last Call: draft-ietf-extra-processimip (and call for shepherd)

[Matthew Horsfall <[e-mail]>]

On Tue, May 14, 2024, at 7:02 AM, Ken Murchison wrote:
>> *Incompatible options?*
>> 
>> 1. 4.3 "Updates only argument" or 4.4 "Calendar ID Argument" could be clearer that they are incompatible with each other. I think they are mutually exclusive based off of the spec in Section 4 "Process Calendar Action":
>> 
>>     [ :updatesonly / :calendarid <string> ]
> I've added the following to 4.3 and similar text to 4.4:
> 
>    The :updatesonly and :calendarid (Section 4.4) arguments are
>    incompatible with each other.  It is an error if both arguments are
>    used in the same "processcalendar" action.
> 
> 
>> 2. It seems to me that :organizers and :allowpublic are also incompatible, if so we should spell that out. If not maybe we should explain how they aren't incompatible.
> They aren't incompatible.  :allowpublic can be used to allow METHOD:PUBLISH events (which have ORGANIZER, but no ATTENDEEs), and :organizers can be used to limit from whom such events would be accepted, E.g. local football team, a school, concert hall, etc.
> 

Okay, what's tripping me up is :allowpublic says this:

   The optional :allowpublic argument is used to tell the implementation
   that it can process calendar data that is not an iTIP message (it
   does not contain METHOD and/or ORGANIZER properties) or the METHOD is
   PUBLISH.

(The key bit being "data that is not an iTIP message). Where as :organizers says:
 Implementations MUST NOT process calendar data unless is it is a well-formed iTIP message 

I guess on multiple readings it becomes somewhat clearer that what's being said is :organizers is valid with :allowpublic, but only for cases where METHOD:PUBLISH... I think maybe we should add some text to that affect in the :organizers Section.

>> 
>> *Security considerations - more recommendations?*
>> 
>> Should the security section could maybe do more to recommend what is meant by a known sender? It could recommend not processing data if DKIM/DMARC/SPF fail, etc...
> Do you have some suggested text?
> 

Ugh not really. I thought there might be something standard to say or something I've seen before.

These two sections:

   *  Processcalendar SHOULD NOT process calendar data received from a
      potentially malicious sender.  The address and envelope [RFC5228]
      tests (optionally along with the extlists [RFC6134] extension) can
      be used to make processcalendar conditional on the sender not
      being "untrustworthy".

   *  Similarly, processcalendar SHOULD only process calendar data
      received from a known sender.  The address and envelope [RFC5228]
      tests (optionally along with the extlists [RFC6134] extension) can
      be used to make processcalendar conditional on the sender being
      "trustworthy".
We could add something along the lines of "Trustworthiness may depend on whether or not SPF/DKIM/DMARC passes or fails for a message. Or whether a signed message has a valid signature. How to pass this information to sieve and interpret it is out of scope of this document, but one could use special headers and https://www.rfc-editor.org/rfc/rfc5228.html#section-5.7 header checks"

But I don't know...

> 
> 
>> 
>> *Option inconsistencies:*
>> 
>> It's weird to me that :organizers uses the :extlist mechanism but :addresses doesn't. What's the reasoning there?
> Presumably a user has far fewer addresses/aliases that direct to them than they have people that they would be willing to accept event invitations from (allow list); the former being simple to enumerate in a stringlist and the latter being large enough to utilize an external list.
> 
> How do others feel about this?  Should we use the same construct for both?  I'd rather not require external lists for :addresses.
> 

That logic makes sense to me and is fine I think. Probably the ideal situation is they both support both forms, but I don't think it's worth changing now.

Thanks,

-- Matthew Horsfall (alh)