- From: Robin Berjon <robin@robineko.com>
- Date: Tue, 10 Aug 2010 15:30:36 +0200
- To: Thomas Roessler <tlr@w3.org>
- Cc: María Ángeles Oteo <maoteo@novanotio.es>, <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>
On Aug 5, 2010, at 11:06 , Thomas Roessler wrote: > 1. EMail address syntax is a fairly complex beast. Please refer to specific productions from RFC 5822 when talking about things like e-mail addresses. (You could either mean an address, a mailbox, or an addr-spec. Note that an address may include a list of mailboxes.) In terms of the complexity of what we might need to expose, isn't there a point at which we can cop out and just give a DOMString, leaving it up to a library to expose the vicious intricacies of email syntax (and letting the vast majority of people not care about what is essentially a steaming pile of corner cases)? > 2. We currently model a message as a (text) "body" and an array of blobs that we call "attachments." > > Please use the terminology from RFC 2045 section 2 in order to model MIME. Also note that the model we use might very well be sane for composing e-mails (we have a choice about the complexity of the messages that we permit to be constructed through this API), but that it won't work on the receiving end. A message can have a multipart as its body, any of whose parts can be a multipart or a message by itself. That's not properly modeled in the current API. Any chance that we could "simply" use File API: Directories and Systems to model MIME messages? I guess that a multipart email message could be seen as a VFS (if we had to). > Several of the observations here beg a more general question: To what extent do we expect this API to be ever taken up outside of widget environments? That's a very good question — ideally I'd like to see some simple use cases here for the Web side. -- Robin Berjon robineko — hired gun, higher standards http://robineko.com/
Received on Tuesday, 10 August 2010 15:53:03 UTC