Re: Messaging API Update

Hi Dom,

 Thanks for your feedback, please find my comments inline.

 With regards to the comments on "folder", "id" and "timestamp" attributes I think we should keep them as they are (see below the reasons why). However, if for the sake of simplicity the group considers better to remove/rename them, I'll do it.

Best Regards


On Dec 2, 2010, at 2:16 PM, Dominique Hazael-Massieux wrote:

> Hi Maria,
> 
> Le mardi 30 novembre 2010 à 17:46 +0100, María Ángeles Oteo a écrit :
>> Messaging API has been updated according to the decision taken during last F2F.
>> Comments are welcome
> 
> This looks overall very good, and very much in line with what we
> discussing during the F2F, thanks. I'm hoping we can publish it as an
> update to the current public draft soon.
> 
> A few comments:
> * I don't think the "folder" property should be included in the *Message
> interfaces, since it's not clear it would serve any useful purpose in
> the "send" use case; if we need it for other operations, we should add
> it then

The idea was that after executing the send() method, the folder attribute was updated. It might provide info about the folder in which the message is stored after the send method is invoked, depending on the sending operation result. For instance, when sending fails, the implementation may store a copy in the drafts folder.

> 
> * I'm not clear whether we need the id property either; is there any use
> case you have in mind for it?

Similarly, id should be also updated after invoking send(). This would allow to look for the messages that have been set through the future "Message Reading API".

> 
> * the timestamp property should be only about "sent" time, and should
> probably renamed to sent_time? It might also benefit from being turned
> into a TZDate once we have a spec for that

We kept the old name (timestamp) because I believed the same Message Interface could be reused in other messaging APIs. I.e. timestamp could be the sent time for sent messages and the received time for received messages.

> 
> * accountId in EmailProperties seems also to be out of scope for this
> API

Agreed, we may need to clarify that the default e-mail account will be used.

> 
> * the to field of the email address currently refers to the definition
> of RFC 5322, which is quite a complicated beast to parse
> http://tools.ietf.org/html/rfc5322#page-16
> While I can see the value of accepting these values in the createEmail()
> function, I think the data exposed through the to[] property should be
> objects (with e.g. address and name fields) rather than unparsed
> strings. This would presumably also affect the from, cc and bcc
> properties, and the relevant MMSProperties. I'm not sure if similar
> treatments need to be applied to the MSIDN fields in SMS and MMS from
> fields. 

I don't think we need to allow developers to specify names in to/cc/bcc fields. All they need for sending messages is the e-mail address/MSISDN. 

The reason for referring to RFC5322 is specifying the format of that attribute, as we need to explain what a valid e-mail address is.

> 
> * there is an extraneous "." after the name of the "bcc" property in
> EmailProperties
> 

OK, will fix.

> Dom
> 
> 
> 
>

Received on Monday, 13 December 2010 15:11:17 UTC