- From: María Ángeles Oteo <maoteo@novanotio.es>
- Date: Wed, 12 Jan 2011 16:10:05 +0100
- To: Dominique Hazael-Massieux <dom@w3.org>
- Cc: Rich Tibbett <rich.tibbett@gmail.com>, Frederick.Hirsch@nokia.com, public-device-apis@w3.org
Hi, I understand the issues about the abstract and the security chapters. I will try to provide an update on that asap. With regards to the scope and design of the API, the current approach was agreed in the last F2F. I would be happy to hear concrete proposals and implement them if they have wide group support. Anyway, this can be done after publishing a new draft. Best regards On Jan 12, 2011, at 2:10 PM, Dominique Hazael-Massieux wrote: > Le mercredi 12 janvier 2011 à 13:21 +0100, Rich Tibbett a écrit : > >> That said, I still think we should publish the existing >> editors draft as >> an updated draft of the document, given how we've vastly >> reduced the >> scope since the previous draft we published during the >> summer. >> >> >> I'm questioning the much bigger issue of the rational for this >> specification in the first place, not about milestones on the >> specification's roadmap. > > Right, but better defining the scope is an important piece of explaining > the rational of the spec. Since we already have a document as a FPWD out > there, showing that we don't actually intend to spec everything that was > put in that first draft seems like an important message. > >> On the 'saner way to compose body of messages' are you saying that URL >> Encoding a body string is the problem with URI schemes? > > There is URL encoding (on top of the character encoding questions), URL > size limitations, the difficulty of manipulating URLs in JavaScript in > general (although I understand this is being addressed). > >> Attachments provide a better use case but why, for example, could we >> not extend existing technologies - why could we not pass Blob URIs >> pointing to attachment files in the URI schemes instead? > > I'm not sure what you have in mind there; this might be the way to > address what I suggested above (tying the API more closely with URI > schemes), but it's hard to assess without a clearer example of what > you're envisioning. > > I've also remembered another (small) advantage of the API: the developer > gets a notification of whether the message was successfully sent or not > (and for what reason if not). > >> The user experience you mention didn't jump out at me on reading. > > Hmm... Re-reading the security considerations, they don't make that very > clear indeed. > >> Perhaps either the Abstract or Scope could clarify exactly what is >> covered, what the intended user experience is (informative would be >> fine) and how it works with either a local device or web service. The >> spec should also highlight the benefits of the API over existing >> methods (i.e. URI schemes) and why this stuff could not be integrated >> with these existing methods. > > Sounds good to me. > > 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 :) > > Dom > > > > >
Received on Wednesday, 12 January 2011 15:10:41 UTC