Re: Messaging API Update

See my comments below

On Dec 13, 2010, at 4:32 PM, Dominique Hazael-Massieux wrote:

> Le lundi 13 décembre 2010 à 16:10 +0100, María Ángeles Oteo a écrit :
>>> 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.
> 
> But if we really want the folders attribute to reflect such a behavior,
> we need to specify it; if we leave it undefined, nobody can actually
> rely on it, making it more or less pointless. So I would still argue we
> should remove it until we actually define how it is handled (which I
> think we probably don't need in the first version of the API).

OK, let's remove it for the time being.
> 
>>> * 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".
> 
> Unless it is useful for developers in the specific scope of this API, I
> suggest this should be specified in the Message Reading API when it is
> developed.
> 
OK, it will be removed from the spec.

>>> * 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.
> 
> I think the semantics of sent/received are sufficiently different that
> they ought to be handled by different attributes; and again, I suggest
> we focus only on the current API.

The initial idea was that a message stored locally usually has just one
timestamp: for messages that have been received the timestamp is the
"reception time", for messages sent it is the "sending time", for messages
that have not been sent yet (e.g. Drafts) it is the "saving time". Anyway,
let's rename it for now and discuss this later on when creating the
"Reading API".

> 
>>> * 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.
> 
> I think the account that gets used is something that the user interface
> should take care of; typically, when I click on a mailto: link, my mail
> user agent lets me choose from which account I would be sending the
> mail.

I don't think we should specify such a behaviour as the only way for doing
it, in some cases an implementation may be configured to always use the
default account (because that is the end-user choice) so I would prefer to
leave it open, i.e. The implementation will choose the e-mail depending on
user preferences or through UI interaction.

> 
> 
>>> * 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. 
> 
> There are two aspects:
> * parameters that can be set when creating a message; it would see weird
> not to allow to set names (in addition to email addresses) when mailto:
> allows for it

I am not saying mailto does not allow it, what I am questioning if it is
really needed, and how much value does it add to developers, specially
when we have decided to simplify the API as much as possible. Anyway, if
the group feels this is the right approach I will implement it in the next
draft.

> * parameters that can be read from the Message object created; having to
> parse the fields to extract email address or names would be a disservice
> to developers when the browsers could fairly easily make them available
> through an object
> 
OK, I'll do it.


>> 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.
> 
> RFC5322 defines valid email addresses that include "Dominique
> Hazael-Massieux <dom@w3.org>" as well as dom@w3.org, and other niceties
> with quoting, line returns, etc.
> 
> If we need to restrict some of these fields of a "valid email address",
> I think we should use the HTML5 spec definition:
> http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#e-mail-state

OK, yes, it makes sense.


Thanks
Maria