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

On 6 Aug 2010, at 11:03, María Ángeles Oteo wrote:

> Hi Thomas,
> Thanks for your feedback, see below my comments/questions.
> 
> Today I start my Holidays so I am afraid I won't be able to update the spec
> until late August. Maybe any of the other editors can do it in the meantime.

I look forward to reviewing revised text; meanwhile, a few comments inline.

> Best regards
> María 
> 
>> -----Original Message-----
>> From: public-device-apis-request@w3.org [mailto:public-device-apis-
>> request@w3.org] On Behalf Of Thomas Roessler
>> Sent: jueves, 05 de agosto de 2010 11:06
>> To: María Ángeles Oteo
>> Cc: Thomas Roessler; Frederick.Hirsch@nokia.com; public-device-
>> apis@w3.org
>> Subject: Review: browser use case; e-mail compatibility? (Re: Message
>> API Status)
>> 
>> I had taken ACTION-222 to review the security considerations.
>> 
>> I took the opportunity to do a more general review of the overall API,
>> and noticed a few things along the way:
>> 
>> 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.)
>> 
> 
> OK, so are you suggesting that when the spec speaks about e-mail address we
> include a reference to RFC 5322? I agree with that proposal.

We also have a few choices to make as to how we model an address for sending purposes.

For receiving purposes, we need to figure out how to model things like lists of mailboxes as part of an address.

> 
>> 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.
> 
> OK, I was assuming that the implementation should be the responsible for
> creating the multipart message (obviously with the current version with only
> 1 part). We could add support for multipart for MMS/Email. The question is
> whether it should be just an alternative or the only way to create an
> MMS/Email (i.e. body cannot be a DOMString anymore)? 

Again: On the sending end, we have lots of choices to make, and can plausibly say that we're only ever sending a text body and a few attachments. (Whether there are folks with other requirements is a question we need to ask -- but at least, the choice is technically plausible.)

The receiving end is where we'll have challenges.

>> The effect of message notification, on the other hand, is significantly
>> more nefarious from a privacy perspective, since it enables monitoring
>> of my message in-flow. I don't know that a simple authorization as
>> envisioned by the current security considerations will be appropriate.
>> 
> 
> What other kind of authorization you have in mind? I think that a
> single-shot prompt as suggested is already very restrictive.

I don't have a good suggestion -- that's precisely what's making me nervous here.

Received on Friday, 6 August 2010 09:11:26 UTC