Re: Messaging API update (was: Messaging API usage)

On Thu, Jan 13, 2011 at 11:23 AM, Dominique Hazael-Massieux <dom@w3.org>wrote:

> > I would still be OK with moving ahead with publishing, but maybe it
> > makes more sense to make another editing pass if the scope of the work
> > still needs clarification even for a group insider :)
>
> Based on yesterday's discussions on the call and per my ACTION-325, I've
> reworked slightly the messaging API to clarify its scope and its
> intended approach to securing user consent:
> http://dev.w3.org/2009/dap/messaging/
>
> For instance, the intro now has:
>        These APIs complement what sms:, mms:, and mailto: URI schemes
>

+provide+ (typo)


>        with:
>            * the possibility to attach files to messages,
>            * a callback on success / error when a message is sent.
>
> I've removed the "MUST" from security considerations and reworded it in
> something that I hope express more clearly the intent that was
> discussed.
>

This is on the right track.


>
> I've also added an issue in the API definitions to note that we're
> working on converging more towards a URI scheme-based approach.
>
> I've also made another change that is possibly more controversial, or at
> least not directly aligned with my mandate: I've removed the "From"
> field of the *Message interfaces. As far as I can tell, they would be a
> pretty big privacy hole compared to the URI scheme model: if that field
> would get filled when a message is sent, it would mean that a Web page
> would get my email address or phone number when sending a message
> through the API!
>

Right. That is a valid concern and I agree with this change.


>
> (if this is too big a change compared to what the group is ready for in
> the short timeframe we've discussed, I won't have a problem with
> reverting it and adding an issue in the document to note the problem)
>
> Full diff of my changes at
>
> http://dev.w3.org/cvsweb/2009/dap/messaging/Overview.html.diff?r1=1.27&r2=1.31&f=h
>
> Rich, let me know if you see other edits that would help address your
> earlier concerns.
>

Your changes look (tentatively) good. I'd still like to see a lot more URI
integration but that has been noted as something we will address going
forward.

Assuming we could provide attachments in the existing URI schemes, I'm
unsure of whether the other stated benefit (being notified on successful
sending) provides enough motivation to develop this API.

- Rich