Device APIs Working Group Teleconference -- 19 Mar 2012

<trackbot> Date: 19 March 2012

<Josh_Soref> Scribe: Josh_Soref

[ fjh describes Agenda ]

<OliverD> s!s/01:06 < darobin> RRSAgent, this meeting spans timezones!!

fjh: we'll look into splitting contacts apiece from data formats

Introductions

Bryan: Bryan Sullivan, AT&T

James: James Hawkins, Google

<fjh> Goals for F2F include the following: 1. progressing webintents, raising and resolving issues

Josh_Soref: Josh Soref, Scribe, RIM

Oliver Don, France Telecom

<fjh> 2. determining issues of integration of webintents with other DAP specifications such as Contacts in order to unblock work on those

Quiling_Pan: Quiling_Pan, Huawei
... From software
... Company

Roi: Roi, from Huawei device
... Welcome everyone to Shenzhen

<fjh> 3. Work through plans to develop System level APIs

<fjh> 4. Consider other possible new work such as NFC, review use cases etc

AAZ: From Huawei browser

Greg: Greg Billock, Google

AAB: Youngsun1, From Samsung

<fjh> 5. Resolve issues with current work items in order to progress, e.g. Feature permissions

<fjh> 6. Regular business

WonSuk: Samsung

<Jungkee> Jungkee Song

WonSuk: We worked on Battery

Jungkee: working on Tizen browser and NFC

<shan> Soonbo: Soonbo Han, From LGE

Claus: Claes, from Sony Mobile

Stephan, Fraunhofer FOKUS, webinos Webinos

Darobin: freelance, Co-chair

AA3: ...

[ introduction. Of China Unicom ]

<Bo_Chen> Bo_Chen from China Unicom

<derek> Derek Jiang from China Unicom

<zhang> chengyan zhang from china unicom

<kensaku> kensaku komatsu from NTT communications

<xingxin> xingxin li from china unicom

<aizu> Hiroyuki Aizu from TOSHIBA

RITTa: RITT, we focus on mobile Internet standards in China

Fjh: thanks shunan and deepanshu

Minutes approval

<fjh> RESOLUTION: Minutes from 13 March 2012 are approved

Host Presentation

Quiling_Pan: Good morning
... Huawei just joined W3C
... We just reorganized
... From focusing on carriers as customers
... To end users

[ organizational structure ]

[ growth chart ]

[ global presence ]

[ our customers ]

[ 300 carriers / 200 countries ]

<R_Berkoff> no audio bridge?

Quiling_Pan: before we focused on 3GPP and OMA
... Now we're looking to W3C

[ portfolios ]

<Deepanshu> The bridge is open now

<R_Berkoff> thx...audio ok

[ Terminal Company ]

<darobin> https://www.google.com/search?q=huawei+pegasus&hl=en&client=firefox-a&hs=k3o&rls=org.mozilla:en-GB:official&prmd=imvns&source=lnms&tbm=isch&ei=FN5nT6rXAo2eiQfulsm2Cg&sa=X&oi=mode_link&ct=mode&cd=2&ved=0CBQQ_AUoAQ&biw=1276&bih=671

<Deepanshu> Its huawei internal conference bridge: Dial in number: 0086 0755 28560880, Passcode: 010813889

[ Picture of Pegasus built of mobile phones ]

[ Internet Service ]

Quiling_Pan: TianTian browser

[ Research Standards ]

[ Why W3C? ]

Quiling_Pan: WebRTC
...

[ Shenzhen F2F ]

[ SkyB (TianTian ) Demo ]

[ Group Dinner ]

[ Visit to Huawei base on Thursday after meeting ]

Quiling_Pan: thank you

[ Applause ]

Deepanshu: Deepanshu
... I'm going to show you a browser we made for this meeting
... I will show the browser accessing camera and microphone
... We open the browser

[ clicks bookmark to Web application ]

Deepanshu: let me click take picture
... No consent prompt
... Because the click is deemed as consent
... Click record (for audio )
... There will be an icon
... You can select a contact from this phone's address book
... I will select myself
... You can get a preview
... And clicking send invokes the default email client
... Sending, done
... I can't prove conformance to DAP
... We don't have specifications

WebIntents

James: I'm going to talk about WebIntents
... Late high level bindings
... We shipped a prototype in Chrome 18 beta

<darobin> http://webintents.org/ -> Web Intents web site

James: We turned it off for Chrome 18
... It will be on for Chrome 19

<darobin> http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html -> Web Intents specification

James: I'll do a short demo

[ sets up presentation ]

James: Imagemator
... This Site is around 30 lines of code
... I can pick an image
... For this application,
... I chose the action "pick", and a type (mime type)

[ dialog chooser ]

James: this second application gets pictures from Picasa
... I've now connected to web applications
... I'm not sure if you're familiar with memes
... Maybe you're a start-up not focused on some thing, let the cloud do it for you.
... Mememator
... A service registers to support an action
...

<bryan_sullivan> ? link to demo

And the user chooses which to use

scribe: This solves the Nascar problem
... Too many icons for things users don't want
... Studies show that if someone doesn't like an icon, EG Facebook
... People won't want to share at all

Deepanshu: I presume there's a registry

James: currently, in Chrome

<bryan_sullivan> Can someone define the "nascar problem" or provide a link to info about it?

James: There's a proposal for Web applications to use a certain tag to let user agent recognize a service
... The actual of a user visiting a site
... Is partial interest / consent for registration

Deepanshu: do I get four Intent registration requests?

<fjh> Deepanshu notes may not want all intents on page to be registered by default

James: we're trying to move the user preference into the picker

<fjh> James notes that browser maintains registrations

James: And when you remove something, we try to understand that

Bryan: What is the Nascar problem?

Fjh: Nascar didn't Actually have that problem they sell the ads, but confusing clutter on a web page with too many ads
... It's all the pictures

<dsr> Nascar problem is the proliferation of too many ads on cars

Bryan: ok, it's all the noise from the pictures

Claes: have you considered
... Have you considered having a server registry?

James: not for Chrome

Claes: the specification doesn't currently talk about this?

James: not currently

<fjh> Josh: intents show sites user has already found

Deepanshu: is the intent that

<fjh> Deepanshu: yes, sites that have already been found are registered

[ scribe falls behind ]

James: how do you transfer data?
... You have to save locally and upload by hand
... Or make publicly available
... And tell the first page which services you use

<bryan_sullivan> I think the process of registration in a broader sense, e.g. through an out-of-band provisioning process etc is out of scope, as the W3C is focused on the user-centric model

Greg: the specification will focus on registration and data transmission
... But Chrome will help users when they don't have a provider

Fjh: so if you need to pick and don't have something
... You'll get a chance to install at the same time

James: Chrome has an application store

<Zakim> darobin, you wanted to bring up default/fallback intent handlers

James: This is expanding on schema.org

Darobin: there was a proposal for fallback

James: we can't tell sites there's no registered provider
... But we could let a Site offer a provider
... Which could become the default for that service

Oliver: most of the intents make sense....
... Discover doesn't

James: we intend to remove that

Bryan: there was an interest for Home networking

James: there's a conflict between extending and breaking
... Discovery didn't make sense

Greg: a design goal of Intents is to leave the namespace very open
... So when we botch an intent, there's space for people to replace them
... The intents sweet spot use case
... Is something light

<bryan_sullivan> if the discover verb will be removed how will that affect the intent of the use case described in http://www.w3.org/wiki/WebIntents/SonyMobile_-_Local_Network_Service_Discovery ?

Greg: But some things won't work

James: feel free to ask questions
... I'd like to talk about some modifications
... There's a proposal on whatwg to replace register protocol handler

<bryan_sullivan> Web Intents does seem to overlap with the register handler APIs

James: And register content handler with WebIntents

<Claes> The discovery intent might be needed for local network service discovery with Web Intents. Let us discuss this afternoon.

James: For Chrome 19, register content handler can be replaced by WebIntents
... For unknown content types, we will show a picker based on Intents
... Explicit intents
... An explicit intent is when a client wants to use the intent apiece with a specific handler

<OliverD> /s/api/api/

<darobin> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-February/034881.html -> drop RPH/RCH

Greg: for registration / authentication, the ui is an unspoofable

<dsr> [explicit intent == named instance of a service rather than a named type of service]

Greg: the explicit intent is very like defaulting
... I haven't thought it throughout completely

Fjh: the proposal is to replace RPC/RPH with WebIntents

<bryan_sullivan> Link to description of "explicit intents"?

Fjh: There was a "simplification" proposal which is basically the reverse

James: I appreciate feedback

<fjh> http://lists.w3.org/Archives/Public/public-web-intents/2012Feb/0006.html

James: You may have heard of Mozilla's work
... We heard from Tyler who suggested Web+ protocols

<fjh> fjh: I think you said that registerProtocolHandler and registerContentHander could be replaced by WebIntents

<fjh> James: yes

James: And listed all of the problems with it

<fjh> fjh: and this seems to be the inverse of the Hammond email re "simplification"

James: I should send them out

[yes ]

James: trying to make RPC/RPH work
... Just doesn't work
... We will send out that write-up

Bryan: to Class's presentation

[ Break ]

<OliverD> s!/s/api/api/!!

<bryan_sullivan> Can someone provide a link to Web Plus info, also as asked earlier a link to info on "explicit intents"?

<OliverD> s��

[ Reconvening ]

Huawei visit

Darobin: we'll end at 3pm on Thursday
... For the tour

WebIntents Presentation

<nwidell> nwidell (Niklas Widell) on the bridge

<fjh> james: a possible separate spec on webintents and UPnP registration

<fjh> ScribeNick: fjh

cathy: UPnP forum might need to be cooperating on this, specifically a new device type for WebIntents

<R_Berkoff> speak louder plz

cathy: do we have relevant services to be defined by type

<bryan_sullivan> Need services to be defined inside UPnP / DLNA? I'm not sure I got the point of that comment.

cathy: so we need to work on details with UPnP forum

<bryan_sullivan> everyone mute please, too much echo

<giuseppe> I'll write y question here

james: this work from claes looks very promising

<giuseppe> I was wondering if there is actually a need for an extension like descroibed in the presentation

<giuseppe> would be much easier for browser to map existing services on something like "view" verb

james: we should make UPnP DLNA deliverable to WebIntents task force

<giuseppe> we want to reuse existing devices

<giuseppe> any extension to UPnp will not work out of the box

<scribe> ACTION: claes to create new spec how WebIntents UPnP registration [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action01]

<trackbot> Created ACTION-510 - Create new spec how WebIntents UPnP registration [on Claes Nilsson - due 2012-03-27].

<bryan_sullivan> +1 to the idea of a new spec under the Web Intents TF - we will contribute requirements for that based upon the Web & TV HNTF needs

James to update webIntents wiki for this material

<giuseppe> no, e.g. you ca map "mediaRenderer" service on view

darobin: giuseppe is saying if we do this extension to UPnP then there is issue with many existing deployed devices

<bryan_sullivan> it's possible to new devices to act as a gateway to existing UPnP devices, right? So if we added a SSDP tag etc it could be a new feature supported by new devices.

<darobin> Claes: we should look at both alternatives

<darobin> ... the best solutions is if we can have the UPnP extension, but we should look at enabling existing devices

Josh_Soref: two docs, one to map existing UPnP verbs to WebIntents, one for existing UPnP existing

<Zakim> dsr, you wanted to note that UPnP service description may be sufficient by itself in some cases, but doesn't cover new things like websockets and server-sent events

dsr: note that UPnP service description may be sufficient by itself in some cases, but doesn't cover new things like websockets and server-sent events

darobin: will talk to guiseppe about having giuseppe drafting a doc to do webintents with existing UPnP

bryan: use cases to consider webintents for remote sensor access

claes: note that if controls are shown inline in the original page, then fact that there is service is not so visible to user

<bryan_sullivan> Web Intents could be extended in the short term to support access to existing devices through a gateway, e.g. a remote sensor service ("monitor" verb?) accessed through a gateway device on the home network. Such gateway devices might use SSE or WebSockets to deliver the sensor events, which can be passed to the client app through the Web Intent provider app.

claes: in this case client needs to understand details of UPnP control, making it much more complicated, possibly handled by libraries

<Zakim> fjh, you wanted to ask about discover verb

<Zakim> Josh_Soref, you wanted to suggest replacing Discover: media renderer with Show : video /*

james: often do not need playback controls on page so view might be enough,

<Josh_Soref> Claes: the third option

<Josh_Soref> ... Has a background service doing communication

<Josh_Soref> ... Using channel messaging between service and client

<bryan_sullivan> Can someone drop a link to the spec that defined "Channel Messaging"?

<jhawkins> James: It seems the two client experiences are orthogonal. Some clients may pay the dev cost of directly interacting with upnp device, while other clients merely want to 'play' a 'video'

<jhawkins> James: ...and the API should support both options

<darobin> http://dev.w3.org/html5/postmsg/ -> HTML5 Web Messaging

<Josh_Soref> [ slide shows UA ; service proxying ; TV ]

<Josh_Soref> Claes: Sony proposes WebIntents support UPnP

<Josh_Soref> ... With local discovery

<Josh_Soref> ... UPnP / mDNS

<Josh_Soref> ... UA needs to handle dynamic service availability

<Josh_Soref> ... Should discovery require user initiation ?

<Josh_Soref> ... Questions?

<Josh_Soref> Fjh: I'm confused by the background case

<Josh_Soref> ...

<Josh_Soref> ... You have a worker

<Josh_Soref> Claes: for when the server doesn't have a UI

<bryan_sullivan> Same-origin restrictions can be addressed by CORS, right?

<darobin> ACTION: giuseppe to figure out how to put together a document describing how to do Intents with existing UPnP (himself or by finding someone who does it) [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action02]

<trackbot> Created ACTION-511 - Figure out how to put together a document describing how to do Intents with existing UPnP (himself or by finding someone who does it) [on Giuseppe Pascale - due 2012-03-27].

<Josh_Soref> ... Or a website application is a sensor

<Zakim> fjh, you wanted to ask purpose for background version, to avoid security issues?

<Josh_Soref> Greg: do existing devices support XHR?

<Josh_Soref> Claes: yes, will put on wiki

<bryan_sullivan> Example of "high-level service specific protocols" that need to be specified (and does this mean new specs or references)?

<Josh_Soref> Greg: for background pages

<Josh_Soref> ... We've talked about that before

<Josh_Soref> ... We've also discussed transient registration

<Josh_Soref> ... For redelivery

<Josh_Soref> ... Where you want the same Intent should go to

<Josh_Soref> ... The current specification has new instances being loaded in new pages

<Josh_Soref> ... Our Chrome UI team is very concerned about a lack of a control surface

<Josh_Soref> ... To display Error cases

<Josh_Soref> ... Having controls by the device itself

<bryan_sullivan> Background Intent providers may need a heartbeat mechanism to ensure status is clear, i.e. if the intent "connection" drops the client app knows.

<Josh_Soref> ... Is the problem I have with printers

<bryan_sullivan> Or is that covered with error callbacks?

<Deepanshu> redial..................the chinese number (+8675528560880) should work

<Josh_Soref> ... It's hard with a printer to do things

<Josh_Soref> ... But you can do it with a computer

<giuseppe> I agree with what said now, you need both

<Josh_Soref> ... The specification doesn't prevent these things

s/* cool//

<bryan_sullivan> Re search initiation by the user or app, the permission of an app to automatically invoke search should at least be initially approved by the user, but can be persistent.

james: originally saw no need for background disposition, however added action for self to create UX disposition so we can think about this

<jcdufourd> there is definitely a need for allowing a service with no UI

james: need to make inline clear in spec for picker (action for james?)
... concerned about security

fjh: we need to review implications

Josh_Soref: UPnP is flawed, assumes everyone is well behaved and trusted, yet web is not well behaved and trusted

<bryan_sullivan> Security is addressed by the users which own/manage the devices that could offer Web Intents accessed services.

Josh_Soref: need to have user interaction to have tv to switch input port, thus we need this approach in general, including UPnP

<bryan_sullivan> And more specifically the abilities of those devices to control who/what/when services can be accessed.

bryan: lots of devices in the home, assume they are safe
... but not true if others come into house, etc. e.g. kids friends could access devices
... thus security a concern

<Josh_Soref> Bryan: kids' friends come over and content propagates

<Zakim> dsr, you wanted to note that further work on new discovery mechanisms could address privacy by limiting who can see which services are available as part of a broader framework for

<Josh_Soref> ... If I'm accessing content from a device, I assume the device owner has control over the content they're providing

so you could currently fingerprint a network

<Josh_Soref> Dsr: that's outside of scope

<Josh_Soref> Claes: thank you. We're also doing prototyping

<dsr> dsr: to note that further work on new discovery mechanisms could address privacy by limiting who can see which services are available as part of a broader framework for access control on publicly accessible local networks

<nwidell> Notes that discovery on home network requires me to give people access to that home network to start with

WebIntents issues brainstorm

<Josh_Soref> James: perhaps brain storming

<Josh_Soref> ... We have a W3C bugzilla product

<Josh_Soref> ... We have 45 minutes before lunch

<Josh_Soref> ... It would be great to have a set of deliverables after these two days

<Josh_Soref> ... This is just collecting questions

<Josh_Soref> ... No answers

<Josh_Soref> Darobin: in the minutes

<Josh_Soref> James: what does an identity indicate

<bryan_sullivan> How are Web Intent verb space managed

<Josh_Soref> ... Underlying implementation is OAUTH / BrowserID

<Josh_Soref> Fjh: how does intents work with proxy browsing

<darobin> RB: could this be modelled after the BrowserID interaction model?

<darobin> -> IDENTIFY

<Josh_Soref> James: we have a way to. Specify the type, how do we specify ye format (blob, file, url)?

<bryan_sullivan> We should consider the questions noted in the linked pages on the Web Intents wiki addressed, e.g. at http://glennjones.net/2011/10/choosing-the-right-words-web-intents/

<giuseppe> if I can add a verb point made by bryan, to be able to do a "mapping" spec on UpnP and other protocols we need a clear definition of each verb. I'm still not sure where the verbs will be defined

<darobin> RB: could that simply depend on the pre-agreed protocol?

<Josh_Soref> Darobin: can that be specified by the verb?

s/proxy browsing/ proxy browsing, e.g if portion of client processing is performed server side , http://en.wikipedia.org/wiki/Opera_(web_browser) /

<bryan_sullivan> Are there any versioning issues for intents?

<Josh_Soref> Deepanshu: with several intents registering on a single page, how can we make them register without disturbing the user

<Josh_Soref> James: how do we test webintents

<Josh_Soref> Darobin: in Class's proposal, we saw media types

fjh: how do we obtain access to local device services, presumably via DAP standard APIs, get adoption given both browser and device implementations

<Josh_Soref> Bryan: will there be versioning issues?

<Josh_Soref> James: is webintents dcom for the way?

<Josh_Soref> Bryan: if an intent provider changes, do I need to inform someone?

<Josh_Soref> James: what's the sweet spot, for schema.org

<Josh_Soref> ... Is it a potential solution for the data format problem

<Josh_Soref> Fjh: what happens when there are zillions of providers, to avoid tracking in the picker, is this a usability concern?

<bryan_sullivan> Does the user need to be informed when an Intent Provider webapp has changed, potentially in ways that could impact the user experience - e.g. use a last-modified value to show that the current provider webapp is different from the one approved by the user?

<Josh_Soref> Claes: can the user select a default service? Or is that a UI detail

<Josh_Soref> Jungkee: is there a way to do pipelining?

<Josh_Soref> James: is that for a single domain?

<Jungkee> Jungkee Josh !

pipelining - sounds like xproc for the web

<Josh_Soref> Won_Suk: if an application is on the device

<Josh_Soref> ... Can a client access that. Native application

<bryan_sullivan> Should there be any ability of the user to restrict Web Intents to only "well-known" intent verbs (types)?

<Josh_Soref> James: should the WebIntents specification document how to handle native applications

this was what I was asking as well, assuming DAP?

<jcdufourd> should we consider hierarchical intents (as a way to manage large numbers of intents) ? "subintents" available within the activity of a "top intent" ?

<Josh_Soref> Darobin: how does it work with Private Browsing

<Josh_Soref> Dsr: Re an earlier conversation

<Josh_Soref> What is the relationship between the requesting page and tthe providing page

<Josh_Soref> James: same concerns for explicit intents

in this casease intent is not standard so this is private agreement between client and service, how does user know

<Josh_Soref> Samarth: how does the UI integrate

<dsr> do we show the user in the picker that this is a non-standard intent, i.e. likely to me direct relationship between the site requesting the intent and the site providing that intent

<Josh_Soref> Greg: will clients want a UA provided UI for intents

<Josh_Soref> ... As in the case of a file upload widget

<dsr> s/to me/to be/

<Josh_Soref> Quiling_Pan: when I first read WebIntents

<Josh_Soref> ... It's a way for the...

<Josh_Soref> ... User Agent to understand the user's behaviors and do things in the future. If not, could it be done in the future

<bryan_sullivan> Still looking for info on what an "explicit intent" is. Does anyone have a link?

<Josh_Soref> Won_Suk: with WebRTC

<Josh_Soref> ... A Web application

<Josh_Soref> ... Could it be registered to handle video / audio

<dsr> my understanding Bryan, is that explicit intent is where the intent is for a specific service instance.

<Josh_Soref> James: what's the integration point for other working groups

http://www.vogella.de/articles/AndroidIntent/article.html#intents_explicit

<Josh_Soref> Darobin: do we need a REST document

<bryan_sullivan> thanks

<Josh_Soref> Deepanshu: can we come up with a document for intents and ensure interoperability

<Josh_Soref> James: what would a payment intent look like?

<bryan_sullivan> The vogella.de is about Android intents. Is the meaning the same for Web Intents?

<darobin> s/do we need a REST document/do we need a REST equivalent to document the architectural style of Intents/

<Josh_Soref> Josh_Soref: what would an NFC intent look like?

<Deepanshu> Deepanshu: can we come up with a list of intents (verb) and ensure interoperability?

<Josh_Soref> Oliver: is there a case for relaxing the same origin restriction

<Josh_Soref> Fjh: explicit intents??

<Josh_Soref> James: Explicit intents is when a page says "I want to use this specific service "

<Jack> As for performance be concerned, how to improve the web intent's performance?

<Josh_Soref> Fjh: are there any in-raised security concerns

<Josh_Soref> Greg: are there any spam/phishing risks

s/in-raised security concerns/security concerns that we have not identified with web intents/

<Josh_Soref> Dsr: intents is about using services you've found

<Josh_Soref> ... What is the relationship between services and searching for an intent

<Josh_Soref> ... Or intent based searches

<Josh_Soref> Darobin: every email client I've ever tried is horrible

<Josh_Soref> ... I'd like to source different pieces from different providers

<bryan_sullivan> (similar to the earlier question about users restricting Web Intent use to only standardized intent verbs) outside of a customized / managed browser, how can an enterprise restrict the set of intents that are available to an employee, for security reasons?

darobin: can composing applications using web intents to provide seamless ui, e.g. email

<Josh_Soref> James: do we have use cases for providing persistent acceptance for services

<Josh_Soref> ... Say that a Site is linked to another by default

<jcdufourd> what about sharing an intent "session" between two or more devices ?

<bryan_sullivan> How would the RPH and RCH functions be replaced by Web Intents, i.e. is Web Intents a true superset (or intended to be)?

<Josh_Soref> Josh_Soref: do we have a way for a user to save pipelines

<Josh_Soref> Fjh: what can we learn from previous groups?

s/groups/work, like ws* etc

<Josh_Soref> Bryan: outside a customized / managed browser, could IT restrict verbs and/or providers

<Josh_Soref> Darobin: android applications often do stupid things like asking for permission to do direct access instead of using the Android pick api

<Josh_Soref> James: what are the holes that android intents hit, and can we avoid them

<Josh_Soref> Greg: is it too easy to get a "user initiated action" in browsers

<Josh_Soref> Fjh: for privacy, is it too easy to "give consent"

<Josh_Soref> Fjh: do intents need to support auditing /forensics

need to be clear that active consent is informed and suitable for privacy

<Josh_Soref> James: how much UX is required to enable a Page to register an intent

<Josh_Soref> ... Currently we use. And information bar

<Josh_Soref> ... Is that too much/little

<Josh_Soref> Fjh: given flexibility of actions/implementation, can we change as we go forward

s/forward/and learn/

<Josh_Soref> Claes: assuming you have a page that wants to use several instances of an action + type

<Josh_Soref> ... And you want to take the same action for each

<Josh_Soref> ... How do you address that

<dsr> example being a number of sensors

<Josh_Soref> Hiro: how to specify a filter

<Josh_Soref> ... So a provider can refuse service for some requesting page

<Josh_Soref> Fjh: what are web intents not good for and when shouldn't they be used

<Josh_Soref> Darobin: what can we hide from providers

<Josh_Soref> Oliver: should we require ssl

<Josh_Soref> ... How do we avoid MITM attacks

<Josh_Soref> James: how much UI/UX requirements should be MUST

<Josh_Soref> James: for inline disposition, how much about the service should be mandated

fjh: what if we do not have a browser but use web intents, e.g. no chrome but use of webIntents

<Josh_Soref> James: what are more use cases for the background disposition

<Josh_Soref> Deepanshu: how do we educate users about intent registration so they can make a decision

s/a decision/an informed decision about accepting it/

<Josh_Soref> James: how closely is the Web permissions model

<Josh_Soref> ... Can we use its model for Intents registration

<Josh_Soref> Darobin: what would be an interesting use of Intents for the automotive industry

<Josh_Soref> Bryan: how does Intents work with html speech

<Josh_Soref> Fjh: what changes do we need to make to html5

<Deepanshu> Deepanshu: Given the current Intent registration proposal (info being registerd) how do we educate users about intent registration enough so they can make a decision?

<Josh_Soref> ... Or can they be done elsewhere

<Josh_Soref> [ Lunch ]

james: next steps?

fjh: suggest we group the questions, then once have groupings look at interest of various groups

<bryan_sullivan> What are the accessibility aspects to be considered in Web Intents?

<bryan_sullivan> ping

Web Intents Demo

slides from dsr -> http://www.w3.org/wiki/images/3/3b/Dsr-webintents-shenzhen.pdf

dsr: access to system level APIs might be useful from Chrome extensions to make more usable for developer for WebIntents

<darobin> DSR: maybe there is room for W3C to consider some form of service description language

dsr: may need W3C work on service description at higher level than UPnP to enable other discovery mechanisms such as zeroconf

<Josh_Soref> Scribe: Josh_Soref

<fjh> fjh: will the sources be available

<fjh> dsr: yes

James: stickies?

Deepanshu: not yet

IPR

Dsr: this is a joint deliverable
... Since WebApps is in the middle of rechartering
... And doesn't currently have WebIntents in its charter

<darobin> https://www.w3.org/2002/09/wbs/33280/webapps-2012/ -> WebApps call for review

Dsr: It would be okay once they recharter
... Or members not in DAP can give individual commitments

Darobin: the timeline for WebApps rechartering is April (review) and completion in May

<darobin> s/in May/probably in May/

<darobin> http://w3c-test.org/dap/contacts/ -> Contacts API

WebIntents transferrables etc

<fjh> Greg: spec already updated

Web Intents API changes

<fjh> greg: use case is for example sharing metadata such as filename, create time in addition to file blog, hence array addition

Greg: we have always planned to have web messaging
... We had hoped web messaging would have made this easier
... There are plans to make more things transferable / clonable
... Messaging is acknowledged to be asthetically challenged
... Ports end up in a different field than where they were sent to the original request
... There's also an additional extra accessor

Claes: I'd like to see some examples

Fjh: transferable are defined in the html5 specification

<fjh> ack: bryan

Greg: yes

Bryan: I didn't see much detail

Greg: yes, he specification is very geared to Browser developers
...
... We need to add stuff for Content developers

Contacts

Fjh: we stabilized a format for data
... Until Josh_Soref joined
... are we finding a card or an address book?

James: it's both, you could "pick" vCard, or Address Book, or email address

<fjh> http://www.w3.org/TR/contacts-api/

Fjh: when we did this originally, we wanted an interaction
... Maybe we should talk about how this UI (non mandatory) would work with WebIntents

<bryan_sullivan> I was going to comment that data minimization was a key consideration, and the browser UI was expected to manage what fields would be provided to the app, based upon user selection (or at least that's how I thought it was working).

[ fjh describes chooser ]

<bryan_sullivan> the data minimization is I think the responsibility of the Web Intent provider, not the browser in Web Intents

James: maybe for picking contact you can get more than one

<bryan_sullivan> the browser provides access to the Web Intent provider (allows selection among the providers), but is it intended for the browser to manage field-level access, or is that the responsibility of the Web Intent provider (the latter, I thought)

<dsr> The application could request specific fields for each contact, e.g. first name, salutations and email addresses. James notes this could be indicated in the intent extras field.

<bryan_sullivan> ... i.e. Josh said what I did

Josh_Soref: (I said what Bryan wrote)

James: Do we need his API now that we have WebIntents?

Josh_Soref: not as an API, just a definition as an intent action

Fjh: and something needs to define the data format
... And is there something for privacy to be taken from the contacts API

Darobin: since someone is writing a document for TAG
... Maybe it can go there

<darobin> ACTION: Robin to propose linking to "Privacy by Design in APIs" from Web Intents draft when it's ready [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action03]

<trackbot> Created ACTION-512 - Propose linking to "Privacy by Design in APIs" from Web Intents draft when it's ready [on Robin Berjon - due 2012-03-27].

James: adding a contact is the save action

Josh_Soref: or just returning a card as a file and having the content handler map to an Intent handler

James: the reason we had actions as urls
... Is to have documentation on apis at those urls
... WebIntents.Org/{action}
... But maybe it doesn't scale

Fjh: I'm concerned about IPR protection

Darobin: when we need to create a verb,

<bryan_sullivan> e.g. could we use "pick" for generic web search?

<fjh> ACTION: richt to consider updating Contacts specification to add WebIntents section [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action04]

<trackbot> Created ACTION-513 - Consider updating Contacts specification to add WebIntents section [on Richard Tibbett - due 2012-03-27].

Darobin: We need to get director approval and have a document

Greg: defining query language should be as a hint

<Zakim> bryan_sullivan, you wanted to ask if the "type" field of the intent is limited to MIME types, e.g. to the scalability issue raised by Robin

Josh_Soref: we already reached that conclusion in the contacts specification

Bryan: maybe already answered
... What can I pick?

James: schema.Org has noun definitions

<fjh> s/can I pick?/can I pick, e.g. organization/

Darobin: does it have an image type?

James: yes

<fjh> http://schema.org/

James: there's action * data * format
... Maybe saying that type can be a mime type or a schema.Org type

Darobin: we're circling around...
... The dark path is content negotiation

James: hypothetically, we mandate schema.org
... Drop mime type
... Schema.org specifies the data

<fjh> address information -> http://schema.org/PostalAddress

<bryan_sullivan> would the schema.org nouns e.g. allow me to define an Intent based service through which I can pick a news service?

Greg: not all binary types have formats in schema.org

<darobin> "text/uri-list;type=image/jpeg"

Greg: When you ask for text/uri-list

<bryan_sullivan> or pick a plumber?

Greg: How do you know what the contained type is?

<fjh> did schema.org reinvent OIDs?

Darobin: you end up with a type in your type.

Greg: the advantage is types are defined

At a known place

Darobin: pictures, and people
... Encoding

James: sounds like we'll use schema.org
... Things get complicated when you expand the namespace

Darobin: There's an IG for schemas

<darobin> ACTION: Robin to talk to the Web Schema group about using schema.org nouns for Intents [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action05]

<trackbot> Created ACTION-514 - Talk to the Web Schema group about using schema.org nouns for Intents [on Robin Berjon - due 2012-03-27].

Bryan: I should be able to pick for news

<fjh> http://schema.org/NewsArticle

Greg: some things are solved by specialized providers

<fjh> shall we have a wiki to document these types of decisions/changes - mime type to type + encoding?

Greg: mime types don't evolve fast enough (?_

James: did android not suffer from this as they used mime types

<fjh> Is there any issue with referencing schema.org, questions about governance etc

Greg: android types are very explicit using url ingredients

Fjh: eventually we create a specification
... And do interoperability testing

<Zakim> fjh, you wanted to ask about interop with open interface to schema.org

<fjh> how do we complete interop testing on webintents, especially with large scope of schema.org

<bryan_sullivan> aren't the issues for testing similar to Web Messaging, Workers, etc? The approaches being taken to test the requester/provider in those cases should also be usable as the model for Web Intents.

<fjh> josh: webIDL is example of testing, limited to testing 2 choices against 2 implementations, e.g. 2 different actions etc

<bryan_sullivan> other than that, the UI specific requirements would require specific tests

<fjh> josh: many browsers have automation support, can thus automate much of this

<fjh> darobin: not sure about iframes and testing

<fjh> ... for registration testing might be an issue

<fjh> designpush page http://designpush.pbworks.com/w/page/48061310/FrontPage

WebIntents Design Push

James: we met in Brighton
... Twitter's developer Site is inviting
... WebIntents.Org is a mess
... There was a lot of discussion on Picker UI
... A lot of it was me explaining the lessons we learned from implementing it in Chrome

Darobin: the Intent constructor argument length has grown too much
... I'm looking into talking with the Schema people

<fjh> ACTION: james to write webintents demo using schema.org objects, with split type and encoding [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action06]

<trackbot> Created ACTION-515 - Write webintents demo using schema.org objects, with split type and encoding [on James Salsman - due 2012-03-27].

James: Greg and I will look into splitting the type and encoding

<darobin> close ACTION-515

<trackbot> ACTION-515 Write webintents demo using schema.org objects, with split type and encoding closed

<fjh> james to write webintents demo using schema.org objects, with split type and encoding

James: darobin, what would it take to move to the object literal format?

Darobin: not much
... When you have 6, mostly optional arguments

James: ok

Work Modes

Josh_Soref: there are two main modes in W3C
... In one, groups discuss potential changes, reach a conclusion and the editor records it

<darobin> http://www.w3.org/wiki/WebIntents/ContactsAPI -> Contacts API example using Intents

<lgombos_> Laszlo nod that it is a break

Josh_Soref: In the other, the editor makes a change and then people review the changes

[ break for 30 minutes ]

<lgombos_> fjh, ok

<OliverD> s/fjh, ok//

<OliverD> s/Laszlo nod that it is a break//

<OliverD> s/19 March/20 March/

<OliverD> s|s/01:06 < darobin>||

<OliverD> s/Its huawei internal conference/It's a huawei internal conference/

<OliverD> s/EG/e.g./

<OliverD> s/(?_/(?)/

<fjh> s/from 13 March/from 14 March/

<fjh> fixed RESOLUTION to reflect correct date of approved minutes

<fjh> s/Minutes from 13 March 2012 are approved/Minutes from 14 March 2012 are approved/

<fjh> Date: 20 March 2012

WebIntents Brainstorm Triage

Darobin: Should WebIntents be concerned with identifying behavior patterns?
... For DAP group
... - out of scope for WebIntents. DAP can look
... Is WebIntents = DCOM for the Web?

[ Laughter ]

Darobin: How to improve WebIntents performance?
... - issue event on Intent load
... Do we need a REST style document for the interaction architecture

<fjh> I created wiki to record DAP issues related to WebIntents -> http://www.w3.org/2009/dap/wiki/WebIntent_Issues

James: Intents specifies not to do anything until the object is fully ready
... - window.event

<fjh> action for James to send item to list related to blocking and intent on window

<trackbot> Sorry, couldn't find user - for

James: But, we can move to adding an event to indicate when an event is ready
... how do we handle too many providers?

<fjh> james has action to send item to mail list related to blocking and webintents intent window item

James: The browser will handle it with heuristics / history
... Can the user select a default service?
... - a user agent could support this
... How do we specify type vs. Format?

<fjh> s/James has/AI James has/

James: - I have an action item on that
... Explicit intents
... - I'll send a proposal

<fjh> AI James to send proposal to split to type and encoding, related to schema.org

<fjh> s/james has/AI james has/

James: Should the UA warn if an Intent is rare?

Darobin: Is that a QoI / phishing issue?

Josh_Soref: it's QoI, but not having informative text means that non major browsers will miss important securiI issues.

Darobin: <intent> tag

Greg: advantage, explicit
... Doesn't work in head

scribe: Explicit also provides for fallback / alternative content

<fjh> it can become a pattern to learn, hence meta tag ambiguity might not be a problem

James: we need a way to crawl / index

<fjh> james asks what about imperative registration

James: Imperative handles unregistering

<fjh> s/imperative/declarative

<darobin> or rather

<fjh> james: benefits to body, include no parsing changing needed, easier to do many things like fallback etc

<fjh> josh: head has no real benefits, space limitations on head etc

<Zakim> bryan_sullivan, you wanted to ask if we could use the <link> tag and define a new relation type via RFC

<dsr> Not sure how strong the argument is about the length of the head, given that people can insert scripts and style sheet rules in the head, although that isn't great practice.

Bryan: link doesn't seem so out of place

James: the only extended link is the icon tag
... And we're talking about many more attributes
... Hixie seems less opposed
... IE and Safari are supportive

<fjh> james: waiting for 2 things - rph,rch proposal (done), privacy concern, planning to submit

James: Mozilla has one engineer working on it and some people opposed

Darobin: richt should have landed

<dsr> FPWD will accelerate work on implementation.

James: lifecycle, EG, intent disappears
... - I don't know
... When you pick something, we do a spinner
... If the page 404s, we do one thing
... If it 200s without the tag, then it's a different c

Greg: [ talks about onload ]

<fjh> conclusion of discussion is that current webintents draft is clear of lifecycle and needed actions

<fjh> no need to switch to events

<OliverD> Josh_Soref: Captive portals could clear the intent registration

<fjh> s/no need to switch to event/james will send proposal regarding use of events which should be equivalent

<OliverD> James: Could we catch the 200 an not update the intent registration?

<OliverD> Josh_Soref: for 200 thas a failure we could show the user a new service

<OliverD> ... the UA will keep track of failures and suggest the service is no longer available

<OliverD> James: Can a web intent be delivered to a native app?

<OliverD> ... Yes but this is future work

<OliverD> darobin: there are two parts to this, having access to native apps

<OliverD> ... and the browser providing access to local services like the addressbook

<OliverD> James: Lets add it to use cases

<OliverD> Josh_Soref: Modern browsers add an origin tag to files that are downloaded

<OliverD> ... Intents could tag things with a browser origin

<OliverD> ... when the app does the editing it does not see where it comes from but does see it is downloaded

<OliverD> James: is there a way to do pipelining

<fjh> not sure how this is obvious

<OliverD> Josh_Soref: it is an easy yes, but I want an easy fast way to do it

<OliverD> ... I want to be able to save all the steps and not have user interaction for each stage

<OliverD> James: There are concerns about always wanting to give permission

<OliverD> Josh_Soref: the browser should prompt the user to save intent chains with a name

<OliverD> ... that the user can then select later

<fjh> is this a use case topic?

<OliverD> James: are you saying that we see intent use in the middle of a chain and save it so that it does not neeed to be repeated?

<OliverD> gbillock: This sounds like something that could be handled through browser extensions

<darobin> [this is a collapsed pipeline]

<OliverD> Josh_Soref: [ Gives an example of a sequence of intents being used in sequence and the browser collapsing them into one operation ]

<OliverD> James: Intents require user interaction to initiate

<OliverD> ... Move this to use cases

<OliverD> ... Next question: how can intents handle streaming types

<darobin> RB: IIRC the proposal for Stream objects included them being cloneable, if so then we just return those for streaming types and we're done

<darobin> James: done

<darobin> Greg: they'll either be cloneable or transferable, or both

<OliverD> James: if an intent service changes do I need to tell someone?

<OliverD> ... if it answers to the same api but has different behaviour

<OliverD> Josh_Soref: market correction will handle this

<OliverD> ... Will there be an active ignore for intent registration

<OliverD> James: This is in Chrome

<OliverD> Josh_Soref: Should this be in the spec?

<OliverD> gbillock: Maybe as a should

<OliverD> bryan_sullivan: we need to consider how the user is informed of changes by intent providers

<OliverD> ... I do not think market correction is enough

<OliverD> ... a web intent ad service provider may be chosen by a user because they protect privacy

<OliverD> ... if they stop doing this the user should be informed

<OliverD> James: So what things do we need to tell the user about?

<OliverD> fjh: Does this need to be in the spec?

<OliverD> bryan_sullivan: we are opening a new pathway to user data

<bryan_sullivan> the use case for "I don't like this provider anymore" is similar to DNT and Tracking Selection Lists, i.e. the user can control what they want to use. But the intent of the question was to ensure notice to the user.

<OliverD> fjh: I agree we need to keep this in mind

<OliverD> James: Use of ssl e.g. for inline disposition

<OliverD> darobin: do we agree we need ssl for this?

<OliverD> Josh_Soref: we could decide that if we have inline it must have ssl

<OliverD> ... but we do not need to decide if we need inline at this stage

<OliverD> James: what are the concerns with using non ssl in inline?

<OliverD> gbillock: How much notification does the user need about the ssl status?

<OliverD> ... if we are not going to display this, we may want to mandate ssl

<OliverD> James: UX should not madate this

<Cathy> Can bryan_sullivan's question be addressed by having a mechanism to re-register an intent, where the intent parameters have not been changed?

<fjh> s/madate/mandate/

<OliverD> gbillock: I think making a reccomendation for this is sensible as it gets presented as if it is browser chrome

<OliverD> Josh_Soref: If the incentives are not right this will not be implemented correctly

<OliverD> ... Most sites still don't use ssl

<OliverD> ... we can improve the web by encouraging the right thing

<OliverD> ... this might be a time where we can force people to do the right thing by mandating it

<OliverD> James: This ups the cost significatnly

<OliverD> Josh_Soref: This is only for inline

<OliverD> ... the other form is still simpler

<OliverD> James: At what benfit for the user

<OliverD> ... ?

<OliverD> Josh_Soref: the user has a tendancy to think that whatever is in that context is safe

<OliverD> James: I think further discussion may be needed

<fjh> s/tendancy/tendency/

<Cathy> s/benfit/benefit/

<OliverD> Josh_Soref: I travel a lot and things that were safe can be unsafe on untrused networks

<darobin> ACTION: Josh to propose Security Considerations section on SSL for Intents sepc [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action07]

<trackbot> Created ACTION-516 - Propose Security Considerations section on SSL for Intents sepc [on Josh Soref - due 2012-03-27].

<OliverD> Cathy: Bryan was asking whether there is a way to notify the user

<OliverD> ... when the behaviour of the intent has changed

<OliverD> ... I wonder if there is a need for a reregistration mechanism

<OliverD> ... a way for the service page to anounce that something has changed

<OliverD> ... currently this is not handled

<OliverD> Josh_Soref: Automated phone systems ofen tell you they have changed their options

<OliverD> ... this is not that helpful, it's usualy just annoying

<OliverD> ... if a site really wants to change it's behaviour it can do so at a new url

<OliverD> s/it's/its/

<OliverD> Josh_Soref: we can stick this into best practice

<fjh> proposal to create best practice for web intent, e.g to change service details, cause error on page, use new url

<darobin> take the main shopping street (with the red keys) then second right then third left

Dinner plans

<OliverD> [ Deepanshu explains where we're going tonight ]

<OliverD> [ We depart at 6:15pm from this room ]

<darobin> in Room III on 2nd floor at 1815

Recess

<darobin> ok, good!

<darobin> richt: try to catch up with us rather than walk it on your own — you could possibly get lost :)

- DRAFT -

Device APIs Working Group Teleconference

19 Mar 2012

Attendees

Contents