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

[Matthew Horsfall <[e-mail]>]

On Tue, May 7, 2024, at 7:34 PM, Bron Gondwana wrote:
> Hi Ken and co,
> 
> I see that the ":reason" argument change was made 4 weeks ago and there's no other feedback.  Are you aware of any outstanding feedback?  Are any of you aware of any IPR that affects this document?

I've just gone through it and have some notes:

*Spelling issues:*

> The recipient user's email address matches the Calender

  Calender -> Calendar 

> are semantically equalivalent

  equalivalent -> equivalent 

> If the data is found to be sematically different

  sematically -> semantically

>  An email address in the external list matches the Calender User Address

  Calender -> Calendar 

*Incorrect example*

":errstr has been renamed to :reason" - The example still shows ":errstr":


   set "processcal_outcome" "no_action";
   set "processcal_error" "";

   processcalendar :outcome "processcal_outcome"
                   :errstr "processcal_error";

   if not string :is "${processcal_outcome}" ["added", "updated"] {
      addheader "X-ProcessCal-Outcome" "${processcal_outcome}";
      addheader "X-ProcessCal-Error" "${processcal_error}";
   }


When changing those we should probably also change "processcal_error" to be
"processcal_reason" and "X-ProcessCal-Error" to "X-ProcessCal-Reason".

*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> ]

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.

*Incorrect claim?*
**
Section 5.1 "Cyrus Server" says:

  This production level Sieve implementation supports all of the requirements described in this document. 

Which isn't quite true. It supports an older version of the document. Is it okay to go live with this text if Cyrus isn't there yet, or do we intend to be very quick about updating cyrus appropriately before this document
is published?

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

*Option inconsistencies:*

It's weird to me that :organizers uses the :extlist mechanism but :addresses doesn't. What's the reasoning there? 

Thanks, and sorry for the delay,

-- Matthew Horsfall (alh)