Re: Review of the Messaging API

Hi Robin,

Per my ACTION-400 (bad request), I've incorporated (most of) your
feedback to the editors draft of the API:
http://dev.w3.org/2009/dap/messaging/

I've incorporated all the editorial feedback.

Some comments on the more open aspects of your feedback below.

Le mercredi 25 mai 2011 à 15:33 +0200, Robin Berjon a écrit :

>     • "a callback on success / error when a message is sent."
> Actually, given the implementation strategies we discussed, the
> callback will never indicate that a message has been sent or failed to
> — simply that it's been passed on to the platform's application that
> handles sending such messages (or that that has failed).

I've reworded it as "a callback on success (resp. error) when a message
is successfully passed (resp. has failed to pass) to the platform’s
application that handles sending such messages.."

>     • "The following code extracts illustrate how to create and send
> messages.\n\nSending an MMS with an attached picture, if device
> supports it." -> "The following code shows how to send a message with
> an attachment." The example itself should probably be rewritten to be
> more complete and realistic (e.g. triggered from some user interaction
> since it fetches a file from a form that needs to be populated first).

I've made the example a bit more complete. I've resisted the temptation
of using the capture attribute :)

> # Security Considerations
> 
>     • "In general, user’s consent is expected to be confirmed for each
> invocation of the sendMessage methods." I think that this is confusing
> because it gives the impression that there should be some form of
> in-browser UI prompt for permission, when in fact what is meant is
> that whatever is used for permission (typically, bringing up the
> platform MUA) should happen every time. I think the section could be
> reworded to clarify the expectation that invoking the applicable
> platform agent is probably the expected implementation, and derive the
> security implications from that).
 
I've added: 
        Typically, the user agent would bring forward the application
        responsible for editing/sending the type of message with
        pre-filled entries, and the ability for the user to send the
        message through the said application (after edits if she wants
        so).


> # Supported messaging types
> 
>     • "Using a single method to send message across many protocols
> make it impossible to detect whether a given user agent supports a
> specific messaging protocol." Should we add a canSendMessage() method
> which would return unknown/yes/probably?

Hmm... That has the sour taste of DOM hasFeature(), which never really
gave useful answers. That remains to me the major weakness of the API as
it stands.

Here is a random idea: maybe we make sendMessage() an additional method
of HTMLAnchorElement that is only available when the user agent knows
how to send a message for the given URI scheme?

So, instead of doing 
  navigator.sendMessage("maitlo:dom@w3.org", attachments, ...);
you would create a DOM element matching <a href="mailto:dom@w3.org">,
and invoke sendMessage on the resulting node (without the first param,
obviously). 


> # SMS specific concerns
> 
>     • "depends on language encoding the content" -> "depends on the
> encoding of the content"
>     • Personally, I would drop this section. It touches on underlying
> issues that are not concerns at the API level.

Dropped.


> # DeviceMessaging
> 
>     • "The DeviceMessaging object is exposed on the navigator.device"
> I think we agreed to drop navigator.device and expose everything on
> navigator (or on whatever else — I don't care).

Hmm... navigator.sendMessage() seems quite ambitious; I've put it down
there at this time, but added a note about it being a strawman proposal.

>     • I don't think that we should call the first parameter "to", it
> should be "uri" otherwise there will be confusion.

Good point; fixed.

>     • I always get mixed up with these: should it be sequence<Blob> or
> Blob[]?

Since this is used as an argument to an operation, a sequence is fine.

>     • I really think that we need a success callback. You may have a
> UI that depends on the successful transmission of the message (if only
> to the MUA) and since it's async you can't know what's going on
> otherwise. Granted, it won't provide much useful information but it's
> still something.

I've re-enabled it, but I'm still not sure that most MUA can actually
report anything useful to the browser; we'll know more about this once
we see implementations.

> # MessagingError
> 
>     • "Adds Messaging API specific error codes." I think we can drop
> this note.
> 
>     • The following errors are unlikely to ever be triggered:
> IO_ERROR, MESSAGE_SIZE_EXCEEDED, PERMISSION_DENIED_ERROR,
> TIMEOUT_ERROR
> 
>     • NOT_SUPPORTED_ERROR should clearly be used to represent
> unsupported schemes.
> 
>     • PENDING_OPERATION_ERROR is the error that other specs use to
> prevent running two tasks at once. I don't think that it's applicable
> here.

Rewritten accordingly.

>     • One attack vector (which should be documented in the security
> section) is that you could just keep calling sendMessage to flood the
> user's device with a zillion message prompts. There should be a
> TOO_MANY_MESSAGES error for when a UA-dependent rate of messages per
> minute (I'd put it very low) is reached. Note that we're not
> introducing a new security issues, just load the following HTML in
> your browser (at least in Firefox):
> 
>     <body onload='while (true) window.location =
> "mailto:robin@berjon.com"'>
> 
> Or, maybe don't do it.

I haven't added anything on that yet; I wonder if there is something
already written on pop-up external applications that I could refer to
instead.

Dom

Received on Monday, 4 July 2011 13:10:04 UTC