Re: Review: browser use case; e-mail compatibility? (Re: Message API Status)

Suresh, Thomas,

On Aug 23, 2010, at 11:40 , Thomas Roessler wrote:
> Robin suggested to use plain strings and leave parsing of e-mail headers to Web Applications. I think that that's probably a bad idea -- I'd be happy if implementations of the API got this right, and I'm nervous about web applications doing so.

Just to clarify, I didn't necessarily say that all email headers ought to be exposed as strings. For instance, a straightforward one such as Date: can be mapped to ECMAScript Date (or perhaps more likely our own TimeZonedDate).

My concern is over headers that accept complex values but rarely see usage matching the full breadth of that complexity. I'm not advocating for violating the standard, but rather signalling the notion that we /may/ wish to look for an approach simpler than exposing everything that could be. To be perfectly honest I don't have an agenda here. My chief goal is to make the group, and more specifically the people who have a vested interest in shipping this specification, aware of the trade-ofs so that we can collectively make an informed decision.

This is an attempt at capturing what I think is the *smallest* part of the standard that does not violate it (short of resorting to strings for some parts). Amongst the things that it does not expose are comments, anything marked obsolete in RFC 5322, and any header defined elsewhere (they are exposed, but as a list of strings). Using this will be clunky, and it will be unpleasant to write tests for as well. I guess that we could add stringifiers to make it easier to code to (of course, that means more tests!). The IDL does not enforce some rules such as not having From and Sender be the same and other such things.

Also note that this only takes *headers* into consideration. For modelling of the body I described a potential model at http://www.w3.org/mid/99005E9A-2AFD-404C-823A-0DF235C3049D@robineko.com.

We could perhaps decide that not everything needs to be exposed. For instance, the traces or resent headers could perhaps not be exposed. But this returns us to the same old question: what is the scope of this API and what are the use cases guiding it?

[NoInterfaceObject]
interface EmailMessage {
    attribute TimezonedDate date;
    attribute Mailbox[] from;
    attribute Address? sender;
    attribute Address[] replyTo;
    attribute Address[] to;
    attribute Address[] cc;
    attribute BccField? bcc;
    attribute EmailAddress? messageId;
    attribute EmailAddress[] inReplyTo;
    attribute EmailAddress[] references;
    attribute DOMString? subject;
    attribute DOMString[] comments;
    attribute DOMString[] keywords;
    attribute Resent[] resents;
    attribute Trace[] traces;
    attribute HeaderField[] optionalFields;
};

[NoInterfaceObject]
interface HeaderField {
    attribute DOMString name;
    attribute DOMString value;
};

// it is legal to send a Bcc: header with no value as an indication that Bcc copies were
// sent but are (naturally) not retranscribed for the recipient
[NoInterfaceObject]
interface BccField {
    attribute boolean isEmpty;
    attribute addresses Address[];
};

// abstract interface
[NoInterfaceObject]
interface Address {
    attribute DOMString name; // means different things for mailbox and group
};

[NoInterfaceObject]
interface Mailbox : Address {
    attribute EmailAddress address;
};

[NoInterfaceObject]
interface Group : Address {
    attribute Mailbox[] groups;
};

// this is needed because people always parse email addresses wrong
[NoInterfaceObject]
interface EmailAddress {
    attribute DOMString localPart;
    attribute DOMString domain;
};

[NoInterfaceObject]
interface Resent {
    attribute TimezonedDate resentDate;
    attribute Mailbox[] resentFrom;
    attribute Mailbox resentSender;
    attribute Address[] resentTo;
    attribute Address[] resentCc;
    attribute BccField resentBcc;
    attribute EmailAddress resentMessageId;
};

[NoInterfaceObject]
interface Trace {
    attribute ReturnPath? returnPath;
    attribute Received[] receivedList;
};

// may be present but empty
[NoInterfaceObject]
interface ReturnPath {
    attribute boolean isEmpty;
    attribute address Address;
};

[NoInterfaceObject]
interface Received {
    attribute ReceivedToken[] tokens;
    attribute TimezonedDate date;
};

[NoInterfaceObject]
interface ReceivedToken {
    attribute DOMString type; // "word", "address", or "domain"
    attribute EmailAddress? address; // if "domain", the localPart will be the empty string
    address DOMString? word;
};


--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Tuesday, 24 August 2010 11:27:05 UTC