Re: [Jmap] draft-ietf-jmap-mdn-06

[Bron Gondwana <[e-mail]>]

Great thanks! Hopefully you can attend the meeting next week too.

Cheers,

Bron.

On Wed, Jun 10, 2020, at 22:49, Raphael OUAZANA wrote:
> Hi Bron,

> No problem, I well received your previous answer, I was just very busy.

> I will try to take some time to dig into your remarks soon.

> Regards,

> Raphaël.

> Le 10 juin 2020 14:45, de [e-mail]
>> Oops, I realise I didn't also send this to the list when I replied before and may have got the wrong address.
>> 
>> I found some issues when putting together the shepherding doc and doing a really thorough readthrough of the spec and also looking at our implementation.
>> 
>> It would be good to be prepared to talk about these things at the interim meeting next week.
>> 
>> Cheers,
>> 
>> Bron.
>> 
>> On Wed, May 20, 2020, at 16:46, Bron Gondwana wrote:
>>> My apologies for the delay. I realised our implementation is incomplete, so I sat down with Neil (virtually!) and did a full readthrough. What do you know, we found more stuff to query. Sorry about that.
>>> 
>>> *Abstract:*
>>> 
>>> This may be a little too short - it doesn't explain what JMAP is or why it would be of interest. Possibly also something that the editors will pick up on, but it would be good to make it a little more "this is what JMAP is, and this is why having MDN support in JMAP is a good idea".
>>> 
>>> *1.3 Capabilities Object*
>>> 
>>> I would move both MDN/send and MDN/parse as being only present if urn:ietf:params:jmap:mdn is present in the accountCapabilities. Given that MDN/parse works on a blobId, and blobIds are per account, it makes sense that both of them require an account.
>>> 
>>> *2. MDN: forEmailId*
>>> 
>>> I would reverse the expression change from:
>>> 
>>> This argument can only be null when the MDN object
      is a server response for the "MDN/parse" method.
>>> 
>>> And instead say "This property MUST NOT be null for MDN/send, but may be null in the response from MDN/parse". That way we're not making statements about potential future extensions.
>>> 
>>> *2. MDN: finalRecipient*
>>> 
>>> We discussed that wildcard identities are possible in JMAP, which could make calculating finalRecipient more difficult. I would do two things here:
>>> 
>>> 1) make finalRecipient optional on MDN/send - if set, it overrides the value that would be calculated from the Identity.
>>> 
>>> 2) add to Security Considerations that the server SHOULD validate that the user is permitted to use the finalRecipient value and return a forbiddenFrom error if not.
>>> 
>>> *2. MDN: Disposition Object*
>>> 
>>> RFC8098 defines the strings as case insensitive. JSON values don't have to be case sensitive, but it would be much more like the rest of JMAP if you defined these values to be only lowercase via JMAP, e.g.
>>> 
>>>    o  sendingMode: "String" This MUST be one of the following strings:
      "mdn-sent-manually" / "mdn-sent-automatically"
>>> 
>>> And also add some text which says that these are defined case insensitive in 8098 but are case sensitive in this RFC and MUST be converted to lowercase by /parse.
>>> 
>>> If you disagree and think they should match what's in the raw file, then document needs to specify that these particular values are case insensitive.
>>> 
>>> *2.1 MDN Send***
>>> 
>>> You refer an "MDNError" but don't actually define it. From the examples it's clear that this is a SetError. I think it would be best to change that to:
>>> 
>>> o  notSent: "Id[SetError]|null"
>>> 
>>> Having done so, you can then enumerate the expected error types and reasons, with reference to the existing registry (apart from the new mdnAlreadySent error).
>>> 
>>> *2.1 MDN Send part 2*
>>> 
>>> This paragraph has problems:
>>> 
>>>    If the Account Id or Identity id given cannot be found, the MDN
   sending is rejected with an "invalidProperties" error.
>>> 
>>> One is the inconsistent spelling of accountId and identityId which I'm sure the editors would capture, but you may as well fix upfront.
>>> 
>>> Secondly, the correct error here in JMAP is invalidArguments and it rejects the entire method call, as these are method level arguments rather than properties on an individual MDN.
>>> 
>>> *2.1 MDN Send implicit Email/set***
>>> 
>>> It is not clear from this text whether an implicit Email/set is issued if there are no successfully sent MDNs (i.e. 'sent' is null). I am happy with either, but it needs to be clear!
>>> 
>>> It would be good to explain here exactly how the implicit Email/set would look, e.g.
>>> 
>>> For the following method call:
>>> 
>>>        [ "MDN/send", {
         "accountId": "ue150411c",
         "identityId": "I64588216",
         "send": {
           "k1546": {
             "forEmailId": "Md45b47b4877521042cec0938",
             "subject": "Read receipt for: World domination",
             "textBody": "This receipt shows that the email has been
                 displayed on your recipient's computer. There is no
                 guaranty it has been read or understood.",
             "reportingUA": "linagora.com; OpenPaaS",
             "disposition": {
               "actionMode": "manual-action",
               "sendingMode": "MDN-sent-manually",
               "type": "displayed"
             }
           }
         }
       }, "0" ]
>>> 
>>> The implicit Email/set call would be equivalent to:
>>> 
>>>        [ "Email/set", {
         "accountId": "ue150411c",
         "update": {
           "Md45b47b4877521042cec0938": {
             "keywords/$mdnsent": true
           }
         }
       }, "0" ]
>>> 
>>> *2.2 MDN/parse***
>>> 
>>> There reasons for "forEmailId" to be null could be expanded to include: "the server can't efficiently calculate the related email".
>>> 
>>> (I guess if there's more than one email with the same "Message-Id" header but different emailId then what gets returned here is undefined - could be any one of the emails, or could be null)
>>> 
>>> Again, the invalidProperties error should be invalidArguments.
>>> 
>>> *3.1 Sending an MDN***
>>> 
>>> The Email/set example is incorrect. Since the implicit request is a patch to "keywords/$mdnsent", a server would not be expected to echo the full value of the keywords property in the result, since it didn't unilaterally change it. I would expect this response:
>>> 
>>>      [ "Email/set", {
       "accountId": "ue150411c",
       "oldState": "23",
       "newState": "42",
       "updated": {
         "Md45b47b4877521042cec0938": {}
       }
     }, "0" ]]
>>> 
>>> Where "updated" maps the emailId from the forEmailId property to an empty object.
>>> 
>>> *All examples need to either have sendingMode changed to lowercase or the definition changed as above.*
>>> 
>>> *5. Security Considerations***
>>> 
>>> As mentioned above, we should talk about validating the finalRecipient if we allow it to be set by the client.
>>> 
>>> 
>>> Again, sorry about it taking so long to get back with this feedback - I bet you're frustrated at how slow the process is, and this time it's entirely my fault. I look forward to reviewing a -10 and actually shepherding this thing for real!
>>> 
>>> Cheers,
>>> 
>>> Bron.
>>> 
>>> On Tue, May 5, 2020, at 22:44, Bron Gondwana wrote:
>>>> Hi Raphael - I got Ken to follow up to you on it since he wrote our implementation. I see you've dealt with that in -09.
>>>> 
>>>> I'll do the shepherd writeup this week and submit it this week.
>>>> 
>>>> Cheers,
>>>> 
>>>> Bron.
>>>> 
>>>> On Wed, Apr 29, 2020, at 00:26, Raphael OUAZANA wrote:
>>>>> Hi Bron,

>>>>> Any news on this?

>>>>> Thanks,

>>>>> Raphaël.

>>>>> Le 20 mars 2020 09:24, de [e-mail]
>>>>>> I agree, I think I've fixed every comments with -08.

>>>>>> Thanks,

>>>>>> Raphaël.

>>>>>> Le 20 mars 2020 06:43, de [e-mail]
>>>>>>> Thanks for that. 
>>>>>>> 
>>>>>>> With that done, I BELIEVE that we -08 resolves every issue outstanding. Do you agree? I'll go ahead and do the shepherd writeup if so.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Bron.
>>>>>>> 
>>>>>>> On Thu, Mar 19, 2020, at 21:17, Raphael OUAZANA wrote:
>>>>>>>> 

>>>>>>>> Le 18 mars 2020 19:09, de [e-mail]
>>>>>>>>> 

>>>>>>>>> On 3/18/20 1:42 PM, Raphael OUAZANA wrote:
>>>>>>>>>> Hello,

>>>>>>>>>> Le 6 mars 2020 20:35, de [e-mail] 
>>>>>>>>>>> 

>>>>>>>>>>> On 3/5/20 7:40 PM, Ken Murchison wrote:
>>>>>>>>>>> > A few questions as I implement this in Cyrus:
>>>>>>>>>>> 

>>>>>>>>>>> 

>>>>>>>>>>> > - The JMAP server may not be able to determine the Final-Recipient of 
>>>>>>>>>>> > the original message was Bcc'd or sent to an alias. Should the MDN 
>>>>>>>>>>> > object include a 'from' property?
>>>>>>>>>>> 

>>>>>>>>>> 

>>>>>>>>>> It should match the email of the account, no?

>>>>>>>>> 

>>>>>>>>> If the email was sent to an email alias and eventually delivered to the underlying account, the sender of the MDN might want to have the MDN use the alias so as not to leak the real address of the account.

>>>>>>>>> 

>>>>>>>>>> Or maybe we should ask for an identity when sending an MDN, so that the user can choose which email appears in this field?

>>>>>>>>> 

>>>>>>>>> Yes, that is what I was thinking. If the user doesn't provide a from address, then we can default to the email of the account.

>>>>>>>> 

>>>>>>>> I will add an identity parameter, like in MessageSubmission. I will make it mandatory because for me it's not clear how we can get an email address from an account.

>>>>>>>> Regards,

>>>>>>>> Raphaël.

>>>>>>>>> 

>>>>>>>> _______________________________________________
>>>>>>>> Jmap mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/jmap
>>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>>>>>>>  [e-mail]
>>>>>>> 
>>>>>>> 
>>>> 
>>>> --
>>>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>>>>  [e-mail]
>>>> 
>>>> 
>>> 
>>> --
>>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>>>  [e-mail]
>>> 
>>> 
>> 
>> --
>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>>  [e-mail]
>> 
>> 
> _______________________________________________
> Jmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jmap
> 

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [e-mail]