See also: IRC log
<trackbot> Date: 20 March 2012
<scribe> Scribe: Josh_Soref
[ fjh describes Agenda ]
fjh: we'll look into splitting contacts API from data formats
... Goals for F2F include the following:
1. progressing WebIntents, raising and resolving issues
2. determining issues of integration of WebIntents with other DAP specifications such as Contacts in order to unblock work on those
3. Work through plans to develop System level APIs
4. Consider other possible new work such as NFC, review use cases etc.
5. Resolve issues with current work items in order to progress, e.g. Feature permissions
6. Regular business
bryan: Bryan Sullivan, AT&T
jhawkins: James Hawkins, Google
Josh_Soref: Josh Soref, Scribe, RIM
OliverD: Oliver Don, France Telecom
shunan: Shunan Fan, Huawei Terminal
Quiling_Pan: Quiling Pan, Huawei
... From software
... Company
Ruinan: Ruinan Sun, from Huawei device
... Welcome everyone to Shenzhen
Jack: Zhifeng Liu, From Huawei browser
gbillock: Greg Billock, Google
Youngsun: Youngsun Ryu, From Samsung
Wonsuk: Wonsuk Lee, Samsung
... We worked on Battery
Jungkee: Jungkee Song, working on Tizen browser and NFC
<shan> Soonbo Han, From LGE
Claes: Claes Nilsson, from Sony Mobile
Stephan_Steglich: Stephan Steglich, Fraunhofer FOKUS, webinos Webinos
darobin: Robin Berjon, freelance, Co-chair
Bo_Chen: ...
[ 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
Research Institute of Telecommunications Transmission (China)
fjh: thanks shunan and deepanshu
<fjh> RESOLUTION: Minutes from 14 March 2012 are approved
RESOLUTION: Minutes from 14 March 2012 are approved
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 ]
Quiling_Pan: before we focused on 3GPP and OMA
... Now we're looking to W3C
[ portfolios ]
[ Terminal Company ]
[ 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: ... 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
jhawkins: 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
jhawkins: 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
jhawkins: I'll do a short demo
[ sets up presentation ]
jhawkins: 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 ]
jhawkins: 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> ? link to demo
Deepanshu: I presume there's a registry
jhawkins: currently, in Chrome
... 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
jhawkins: we're trying to move the user preference into the picker
<fjh> James notes that browser maintains registrations
jhawkins: And when you remove something, we try to understand that
jhawkins: And the user chooses which to use
... This solves the Nascar problem
... Too many icons for things users don't want
... Studies show that if someone doesn't like an icon, e.g. Facebook
... People won't want to share at all
<bryan> Can someone define the "Nascar problem" or provide a link to info about it?
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?
jhawkins: not for Chrome
Claes: the specification doesn't currently talk about this?
jhawkins: not currently
Josh_Soref: intents show sites user has already found
Deepanshu: is the intent that
... yes, sites that have already been found are registered
[ scribe falls behind ]
jhawkins: 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> 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
gbillock: 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
jhawkins: Chrome has an application store
<Zakim> darobin, you wanted to bring up default/fallback intent handlers
jhawkins: This is expanding on schema.org
darobin: there was a proposal for fallback
jhawkins: 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
OliverD: most of the intents make sense....
... Discover doesn't
jhawkins: we intend to remove that
bryan: there was an interest for Home networking
jhawkins: there's a conflict between extending and breaking
... Discovery didn't make sense
gbillock: 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> 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 ?
gbillock: But some things won't work
jhawkins: 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> Web Intents does seem to overlap with the register handler APIs
jhawkins: 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.
jhawkins: 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 API with a specific handler
<darobin> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-February/034881.html -> drop RPH/RCH
gbillock: for registration / authentication, the UI is an unspoofable
<dsr> [explicit intent == named instance of a service rather than a named type of service]
gbillock: 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> Link to description of "explicit intents"?
fjh: There was a "simplification" proposal which is basically the reverse
jhawkins: I appreciate feedback
<fjh> http://lists.w3.org/Archives/Public/public-web-intents/2012Feb/0006.html
jhawkins: You may have heard of Mozilla's work
... We heard from Tyler who suggested Web+ protocols
... And listed all of the problems with it
... I should send them out
fjh: I think you said that registerProtocolHandler and registerContentHander could be replaced by WebIntents
jhawkins: yes
fjh: and this seems to be the inverse of the Hammond email re "simplification"
[yes ]
jhawkins: trying to make RPC/RPH work
... Just doesn't work
... We will send out that write-up
bryan: to Class's presentation
[ Break ]
<bryan> Can someone provide a link to Web Plus info, also as asked earlier a link to info on "explicit intents"?
[ Reconvening ]
darobin: we'll end at 3pm on Thursday
... For the tour
<nwidell> nwidell (Niklas Widell) on the bridge
jhawkins: a possible separate spec on WebIntents and UPnP registration
Cathy: UPnP forum might need to be cooperating on this, specifically a new device type for WebIntents
... do we have relevant services to be defined by type
<bryan> 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
jhawkins: this work from Claes looks very promising
<giuseppe> I was wondering if there is actually a need for an extension like described in the presentation
<giuseppe> would be much easier for browser to map existing services on something like "view" verb
jhawkins: 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
<fjh> 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> +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 can 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> 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.
Claes: we should look at both alternatives
... 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 giuseppe 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> 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 /*
jhawkins: often do not need playback controls on page so view might be enough,
Claes: the third option
... Has a background service doing communication
... Using channel messaging between service and client
<bryan> Can someone drop a link to the spec that defined "Channel Messaging"?
jhawkins: 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'
... ...and the API should support both options
<darobin> http://dev.w3.org/html5/postmsg/ -> HTML5 Web Messaging
[ slide shows UA ; service proxying ; TV ]
Claes: Sony proposes WebIntents support UPnP
... With local discovery
... UPnP / mDNS
... UA needs to handle dynamic service availability
... Should discovery require user initiation ?
... Questions?
fjh: I'm confused by the background case
...
... You have a worker
Claes: for when the server doesn't have a UI
<bryan> 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].
Claes: Or a website application is a sensor
<Zakim> fjh, you wanted to ask purpose for background version, to avoid security issues?
gbillock: do existing devices support XHR?
Claes: yes
<bryan> Example of "high-level service specific protocols" that need to be specified (and does this mean new specs or references)?
gbillock: for background pages
... We've talked about that before
... We've also discussed transient registration
... For redelivery
... Where you want the same Intent should go to
... The current specification has new instances being loaded in new pages
... Our Chrome UI team is very concerned about a lack of a control surface
... To display Error cases
... Having controls by the device itself
<bryan> Background Intent providers may need a heartbeat mechanism to ensure status is clear, i.e. if the intent "connection" drops the client app knows.
gbillock: Is the problem I have with printers
<bryan> Or is that covered with error callbacks?
gbillock: It's hard with a printer to do things
... But you can do it with a computer
<giuseppe> I agree with what said now, you need both
gbillock: The specification doesn't prevent these things
<bryan> 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.
jhawkins: 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
jhawkins: 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> 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> 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
... 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
bryan: If I'm accessing content from a device, I assume the device owner has control over the content they're providing
<fjh> so you could currently fingerprint a network
dsr: that's outside of scope
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
jhawkins: perhaps brain storming
... We have a W3C bugzilla product
... We have 45 minutes before lunch
... It would be great to have a set of deliverables after these two days
... This is just collecting questions
... No answers
darobin: in the minutes
jhawkins: what does an identity indicate
<bryan> How are Web Intent verb space managed
jhawkins: Underlying implementation is OAUTH / BrowserID
fjh: how does intents work with proxy browsing, e.g. if portion of client processing is performed server side , http://en.wikipedia.org/wiki/Opera_(web_browser)
<darobin> darobin: could this be modeled after the BrowserID interaction model?
<darobin> -> IDENTIFY
jhawkins: we have a way to. Specify the type, how do we specify ye format (blob, file, url)?
<bryan> 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> darobin: could that simply depend on the pre-agreed protocol?
darobin: can that be specified by the verb?
<bryan> Are there any versioning issues for intents?
Deepanshu: with several intents registering on a single page, how can we make them register without disturbing the user
jhawkins: how do we test WebIntents
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
bryan: will there be versioning issues?
jhawkins: is WebIntents DCOM for the way?
bryan: if an intent provider changes, do I need to inform someone?
jhawkins: what's the sweet spot, for schema.org
... Is it a potential solution for the data format problem
fjh: what happens when there are zillions of providers in the picker, is this a usability concern?
<bryan> 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?
Claes: can the user select a default service? Or is that a UI detail
Jungkee: is there a way to do pipelining?
jhawkins: is that for a single domain?
<fjh> pipelining - sounds like xproc for the web
Wonsuk: if an application is on the device
... Can a client access that. Native application
<bryan> Should there be any ability of the user to restrict Web Intents to only "well-known" intent verbs (types)?
jhawkins: should the WebIntents specification document how to handle native applications
<fjh> 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" ?
darobin: how does it work with Private Browsing
dsr: Re an earlier conversation
... What is the relationship between the requesting page and the providing page
jhawkins: same concerns for explicit intents
dsr: should a User Agent warn that an Intent is private / rare
<fjh> in this case intent is not standard so this is private agreement between client and service, how does user know
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 be direct relationship between the site requesting the intent and the site providing that intent
gbillock: will clients want a UA provided UI for intents
... As in the case of a file upload widget
Quiling_Pan: when I first read WebIntents
... It's a way for the...
... User Agent to understand the user's behaviors and do things in the future. If not, could it be done in the future
<bryan> Still looking for info on what an "explicit intent" is. Does anyone have a link?
Wonsuk: with WebRTC
... A Web application
... 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.
jhawkins: what's the integration point for other working groups
<fjh> http://www.vogella.de/articles/AndroidIntent/article.html#intents_explicit
darobin: do we need a REST equivalent to document the architectural style of Intents
<bryan> thanks
Deepanshu: can we come up with a document for intents and ensure interoperability
jhawkins: what would a payment intent look like?
<bryan> The vogella.de is about Android intents. Is the meaning the same for Web Intents?
Josh_Soref: what would an NFC intent look like?
<Deepanshu> Deepanshu: can we come up with a list of intents (verb) and ensure interoperability?
OliverD: is there a case for relaxing the same origin restriction
fjh: explicit intents??
jhawkins: 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?
fjh: are there any security concerns that we have not identified with web intents
gbillock: are there any spam/phishing risks
dsr: intents is about using services you've found
... What is the relationship between services and searching for an intent
... Or intent based searches
darobin: every email client I've ever tried is horrible
... I'd like to source different pieces from different providers
<bryan> (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?
<fjh> darobin: can composing applications using web intents to provide seamless UI, e.g. email
jhawkins: do we have use cases for providing persistent acceptance for services
... Say that a Site is linked to another by default
<jcdufourd> what about sharing an intent "session" between two or more devices ?
<bryan> 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: do we have a way for a user to save pipelines
fjh: what can we learn from previous work, like ws* etc?
bryan: outside a customized / managed browser, could IT restrict verbs and/or providers
darobin: android applications often do stupid things like asking for permission to do direct access instead of using the Android pick API
jhawkins: what are the holes that android intents hit, and can we avoid them
gbillock: is it too easy to get a "user initiated action" in browsers
fjh: for privacy, is it too easy to "give consent"
... do intents need to support auditing /forensics
<fjh> need to be clear that active consent is informed and suitable for privacy
jhawkins: how much UX is required to enable a Page to register an intent
... Currently we use. And information bar
... Is that too much/little
fjh: given flexibility of actions/implementation, can we change as we go and learn
Claes: assuming you have a page that wants to use several instances of an action + type
... And you want to take the same action for each
... How do you address that
<dsr> example being a number of sensors
aizu: how to specify a filter
... So a provider can refuse service for some requesting page
fjh: what are web intents not good for and when shouldn't they be used
darobin: what can we hide from providers, to avoid tracking
OliverD: should we require SSL
... How do we avoid MITM attacks
jhawkins: how much UI/UX requirements should be MUST
... 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
jhawkins: what are more use cases for the background disposition
Deepanshu: how do we educate users about intent registration so they can make an informed decision about accepting it
jhawkins: how closely is the Web permissions model
... Can we use its model for Intents registration
darobin: what would be an interesting use of Intents for the automotive industry
bryan: how does Intents work with html speech
fjh: what changes do we need to make to html5
Deepanshu: Given the current Intent registration proposal (info being registered) how do we educate users about intent registration enough so they can make a decision?
... Or can they be done elsewhere
[ Lunch ]
jhawkins: next steps?
fjh: suggest we group the questions, then once have groupings look at interest of various groups
<bryan> What are the accessibility aspects to be considered in Web Intents?
<bryan> ping
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
fjh: will the sources be available
dsr: yes, will put on wiki
jhawkins: stickies?
Deepanshu: not yet
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 probably in May
<darobin> http://w3c-test.org/dap/contacts/ -> Contacts API
gbillock: spec already updated
gbillock: use case is for example sharing metadata such as filename, create time in addition to file blog, hence array addition
... 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 aesthetically 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
gbillock: yes
bryan: I didn't see much detail
gbillock: yes, the specification is very geared to Browser developers
... We need to add stuff for Content developers
fjh: we stabilized a format for data
... Until Josh_Soref joined
... are we finding a card or an address book?
jhawkins: 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> 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> the data minimization is I think the responsibility of the Web Intent provider, not the browser in Web Intents
jhawkins: maybe for picking contact you can get more than one
<bryan> 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> ... i.e. Josh said what I did
Josh_Soref: (I said what Bryan wrote)
jhawkins: 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].
jhawkins: 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
jhawkins: 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> 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
gbillock: defining query language should be as a hint
<Zakim> bryan, 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, e.g. organization
jhawkins: schema.Org has noun definitions
darobin: does it have an image type?
jhawkins: yes
<fjh> http://schema.org/
jhawkins: 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
jhawkins: hypothetically, we mandate schema.org
... Drop mime type
... Schema.org specifies the data
<fjh> address information -> http://schema.org/PostalAddress
<bryan> would the schema.org nouns e.g. allow me to define an Intent based service through which I can pick a news service?
gbillock: not all binary types have formats in schema.org
<darobin> "text/uri-list;type=image/jpeg"
gbillock: When you ask for text/uri-list
<bryan> or pick a plumber?
gbillock: 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.
gbillock: the advantage is types are defined
At a known place
darobin: pictures, and people
... Encoding
jhawkins: 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
gbillock: 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?
gbillock: mime types don't evolve fast enough (?)
jhawkins: did android not suffer from this as they used mime types
<fjh> Is there any issue with referencing schema.org, questions about governance etc
gbillock: 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> 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.
Josh_Soref: webIDL is example of testing, limited to testing 2 choices against 2 implementations, e.g. 2 different actions etc
<bryan> other than that, the UI specific requirements would require specific tests
Josh_Soref: many browsers have automation support, can thus automate much of this
darobin: not sure about iframes and testing
... for registration testing might be an issue
designpush page http://designpush.pbworks.com/w/page/48061310/FrontPage
jhawkins: 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].
<darobin> close ACTION-515
<trackbot> ACTION-515 Write WebIntents demo using schema.org objects, with split type and encoding closed
jhawkins: Greg and I will look into splitting the type and encoding
<fjh> james to write WebIntents demo using schema.org objects, with split type and encoding
jhawkins: darobin, what would it take to move to the object literal format?
darobin: not much
... When you have 6, mostly optional arguments
jhawkins: ok
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
Josh_Soref: In the other, the editor makes a change and then people review the changes
[ break for 30 minutes ]
<fjh> fixed RESOLUTION to reflect correct date of approved minutes
<fjh> Date: 20 March 2012
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
jhawkins: Intents specifies not to do anything until the object is fully ready
... - window.event
... But, we can move to adding an event to indicate when an event is ready
... how do we handle too many providers?
<fjh> ACTION: james to send item to mail list related to blocking and WebIntents intent window item [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action07]
jhawkins: 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?
... - 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
jhawkins: 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 security UI issues.
darobin: <intent> tag
gbillock: advantage, explicit
... Doesn't work in head
... Explicit also provides for fallback / alternative content
<fjh> it can become a pattern to learn, hence meta tag ambiguity might not be a problem
jhawkins: we need a way to crawl / index
<fjh> james asks what about declarative registration
jhawkins: Imperative handles unregistering
<darobin> <link action="http://WebIntents.org/share" rel="intent" type="http://schema.org/Unicorn" encoding="text/vcard">
<darobin> or rather
<darobin> <link rel="intent" action="http://WebIntents.org/share" type="http://schema.org/Unicorn" encoding="text/vcard">
jhawkins: benefits to body, include no parsing changing needed, easier to do many things like fallback etc
Josh_Soref: head has no real benefits, space limitations on head etc
<Zakim> bryan, 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
jhawkins: 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
... waiting for 2 things - rph, rch proposal (done), privacy concern, planning to submit
... Mozilla has one engineer working on it and some people opposed
darobin: richt should have landed
<dsr> FPWD will accelerate work on implementation.
jhawkins: 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 case
gbillock: [ talks about onload ]
<fjh> conclusion of discussion is that current WebIntents draft is clear of lifecycle and needed actions
<fjh> james will send proposal regarding use of events which should be equivalents
Josh_Soref: Captive portals could clear the intent registration
jhawkins: Could we catch the 200 and not update the intent registration?
Josh_Soref: for 200 that's a failure we could show the user a new service
... the UA will keep track of failures and suggest the service is no longer available
jhawkins: Can a web intent be delivered to a native app?
... Yes but this is future work
darobin: there are two parts to this, having access to native apps
... and the browser providing access to local services like the addressbook
jhawkins: Lets add it to use cases
Josh_Soref: Modern browsers add an origin tag to files that are downloaded
... Intents could tag things with a browser origin
... when the app does the editing it does not see where it comes from but does see it is downloaded
jhawkins: is there a way to do pipelining
<fjh> not sure how this is obvious
Josh_Soref: it is an easy yes, but I want an easy fast way to do it
... I want to be able to save all the steps and not have user interaction for each stage
jhawkins: There are concerns about always wanting to give permission
Josh_Soref: the browser should prompt the user to save intent chains with a name
... that the user can then select later
<fjh> is this a use case topic?
jhawkins: are you saying that we see intent use in the middle of a chain and save it so that it does not need to be repeated?
gbillock: This sounds like something that could be handled through browser extensions
<darobin> [this is a collapsed pipeline]
Josh_Soref: [ Gives an example of a sequence of intents being used in sequence and the browser collapsing them into one operation ]
jhawkins: Intents require user interaction to initiate
... Move this to use cases
... Next question: how can intents handle streaming types
<darobin> darobin: 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> jhawkins: done
<darobin> gbillock: they'll either be cloneable or transferable, or both
jhawkins: if an intent service changes do I need to tell someone?
... if it answers to the same API but has different behavior
Josh_Soref: market correction will handle this
... Will there be an active ignore for intent registration
jhawkins: This is in Chrome
Josh_Soref: Should this be in the spec?
gbillock: Maybe as a should
bryan: we need to consider how the user is informed of changes by intent providers
... I do not think market correction is enough
... a web intent ad service provider may be chosen by a user because they protect privacy
... if they stop doing this the user should be informed
jhawkins: So what things do we need to tell the user about?
fjh: Does this need to be in the spec?
bryan: we are opening a new pathway to user data
<bryan> 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.
fjh: I agree we need to keep this in mind
jhawkins: Use of SSL e.g. for inline disposition
darobin: do we agree we need SSL for this?
Josh_Soref: we could decide that if we have inline it must have SSL
... but we do not need to decide if we need inline at this stage
jhawkins: what are the concerns with using non SSL in inline?
gbillock: How much notification does the user need about the SSL status?
... if we are not going to display this, we may want to mandate SSL
jhawkins: UX should not mandate this
<Cathy> Can bryan's question be addressed by having a mechanism to re-register an intent, where the intent parameters have not been changed?
gbillock: I think making a recommendation for this is sensible as it gets presented as if it is browser chrome
Josh_Soref: If the incentives are not right this will not be implemented correctly
... Most sites still don't use SSL
... we can improve the web by encouraging the right thing
... this might be a time where we can force people to do the right thing by mandating it
jhawkins: This ups the cost significantly
Josh_Soref: This is only for inline
... the other form is still simpler
jhawkins: At what benefit for the user
... ?
Josh_Soref: the user has a tendency to think that whatever is in that context is safe
jhawkins: I think further discussion may be needed
Josh_Soref: I travel a lot and things that were safe can be unsafe on untrusted networks
<darobin> ACTION: Josh to propose Security Considerations section on SSL for Intents spec [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action08]
<trackbot> Created ACTION-516 - Propose Security Considerations section on SSL for Intents spec [on Josh Soref - due 2012-03-27].
Cathy: Bryan was asking whether there is a way to notify the user
... when the behavior of the intent has changed
... I wonder if there is a need for a reregistration mechanism
... a way for the service page to announce that something has changed
... currently this is not handled
Josh_Soref: Automated phone systems often tell you they have changed their options
... this is not that helpful, it's usually just annoying
... if a site really wants to change its behavior it can do so at a new url
... 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
[ Deepanshu explains where we're going tonight ]
[ We depart at 6:15pm from this room ]
<darobin> in Room III on 2nd floor at 1815
<darobin> ok, good!
<darobin> richt: try to catch up with us rather than walk it on your own — you could possibly get lost :)
<darobin> http://dev.w3.org/2011/webrtc/editor/getusermedia.html
<darobin> http://www.w3.org/TR/capture-scenarios/
<darobin> http://www.w3.org/TR/html-media-capture/
<fjh> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html
<fjh> we will start with taking a look at MediaStream Capture Scenarios
<fjh> then getusermedia, then html media capture
[ Bryan projects the MediaStream Capture Scenarios ]
darobin: Scenario 1 is photo upload
bryan: I reviewed this document, and it's pretty good
... If we focus on the specific capabilities described in this document
... I think we can go forward pretty quickly
fjh: this document is for the joint WebRTC. + DAP Task Force
... The "Media Capture TF"
... WebRTC is working on streaming
... This document was initially created to focus on DAP scenarios
bryan: The design section (#5)
... We'll need to make some decisions
... Some of the items cover dependencies to HTML5
darobin: Using the issues in the document to drive discussion seems to be the way to go
bryan: there are levels of access that are granted
... Initially you can't see anything
richt: there's a proposal from Voxeo
... For capabilities
... Which is going to make fingerprinting too easy
<Wonsuk> Capabilities API proposal: http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/0041.html
fjh: there appears to be a concern of fingerprinting related to the capability document being discussed in the task force
... this is a concern
darobin: we have serious concerns about the capabilities document and its implications on privacy
<bryan> Device selection and capabilities discovery/setting are privacy-sensitive functions - as long as the user is in control of the initial access permission, I think those concerns are mitigated.
fjh: what is the source of requirements for the capabilities API and document
darobin: capabilities API should not be exposed to untrusted sources
... so the WebRTC starting point is where DAP was two years ago?
Josh_Soref: yes
richt: it's best to start from nothing and expose as little as possible, slowly adding
<fjh> discussing 5.1.2 Issues related to privacy
bryan: it's better to have the UA ask the user if it wants to expose cameras
... And once you do, then you can provide some information
<fjh> issue: capabilities API compatibility with web privacy and security, assuming untrusted, fingerprinting risk
<trackbot> Created ISSUE-125 - Capabilities API compatibility with web privacy and security, assuming untrusted, fingerprinting risk ; please complete additional details at http://www.w3.org/2009/dap/track/issues/125/edit .
bryan: If we recommend that there's a step by step process
richt: I think that's a given
... We have a build that has this, it's in Opera Mobile 12
... And in a labs desktop build
... The UI problem is understood by all browser vendors
... It's a hard problem
<richt> fyi: http://dev.opera.com/articles/view/getusermedia-access-camera-privacy-ui/
bryan: I read the API and scenarios document at the same time
... And thought about how we discussed pickers
fjh: let's look at the conference call scenario
[ fjh reads section 2.5 ]
fjh: it's talking about automatically selecting video based on who's speaking
Josh_Soref: this is quite doable, Zakim can already tell us who's making noise
... Selecting the video is a logical extension
fjh: she (scribe) does what Josh does, pausing / rewinding
... It would be interesting to analyze this from a privacy perspective
... This document attempts to outline the capabilities needed to implement this
<bryan> Most of this is app-specific and has no impact on the API AFAICT.
fjh: There's a whole bunch of stuff in this use case
bryan: obviously when she receives the streams, she could save / record / etc.
fjh: Harold sent an email to the list explaining that Streaming isn't so simple
... The capabilities document is not this document, but it isn't publicized outside the TF
[ Preview ]
bryan: I just reviewed the documents
... I haven't sent comments yet
<fjh> Thanks to the task force and Travis for a great job with the scenarios document
<fjh> the DAP WG should review and comment on the issues, preferably on the task force mailing list
[ Pre-Processing ]
richt: I have a demo
... This issue quick demo
... Nothing normative
[ getUserMedia ]
richt: all browsers are experimenting with UIs
<bryan> I have some comments I will send to the list. Overall I think the document is a useful overview of the capabilities/issues and if we focus on key capabilities the API can be very useful, without being initially too complex.
richt: Mozilla demonstrated their UI, and it was very similar to ours
<fjh> "hair check" - show still from camera in ok dialog, so you can decide on permission including this information in the decision
<Wonsuk> Webcam Toy demo: http://neave.com/webcam/html5/
richt: Although they included a "hair check" - a preview to see if your hair is out if place
<bryan> e.g. re Pre-processing (monitoring of the input signal for various purposes, e.g. audio end-pointing, volume leveling/AGC, face/gesture recognition) - this is key to many of the use cases and usability of apps. Initially it should include boolean options (capture auto-start/pause and AGC).
richt: The first visit to the page requests permission
... And we're making permissions persistent
... Per domain
<bryan> input level events (e.g. threshold passing) or some realtime-updated attribute (input signal level) are very useful as well but perhaps advanced capabilities that can be deferred.
richt: We're looking into domains that have user generated content
[ demo of live post-processing ]
darobin: capturing a video from canvas will give you camera quality from 5 years ago
... You want to use canvas as a view-finder
... And capture from the underlying stream
... We need something similar for audio
... There are two APIs proposals
<fjh> shows capture of video frame and post--processing on canvas, also ability to capture as photo
<fjh> richt: face recognition demo - recognize specific face and add mustache automatically
<dsr> I was thinking about platform support to find faces and extract video for them for use in conferencing apps.
<gbillock> * 9-something
<fjh> bryan and rich note that simple API appropriate, as JavaScript and current standards can be used for this work, hardware should evolve to enable faster JavaScript processing for face recognition, robin notes certain opencl hardware should enable better performance as well
darobin: The first visit to the page requests permission
... And we're making permissions persistent
... capturing a video from canvas will give you camera quality from 5 years ago
... You want to use canvas as a view-finder
... And capture from the underlying stream
... We need something similar for audio
... There are two API proposals
dsr: for the conferencing case
<bryan> Apps may need to know and set the image capture options, so the section on Capture method selection is important (e.g. determining if the camera/device can capture RAW format for HDR postprocessing, or only JPEG), and to set the options via MediaStreamOptions)
dsr: Facial recognition?
... Can you do that?
richt: we have a demo of putting a mustache on people
darobin: Mozilla had a demo, they cheated by looking at shirt color
... would you have been helped by Simd or OpenCL?
[ Scribe was disconnected ]
<bryan> The options described in "Format detection" are important to reach consensus on, to support that capability-awareness for apps.
[ Jing_Wu presents WoPhone OS - China Unicom ]
Jing_Wu: questions?
richt: how do you run your Web applications?
... Are web applications trusted?
... Do you install with trust?
Jing_Wu: I think we're going with the installed model
<darobin> http://www.w3.org/community/coremob/
darobin: The Core Mobile Platform CG is looking into which APIs should be supported first
fjh: thanks for presentation on WoPhone; questions regarding status of DAP specs should be discussed as part of the DAP F2F agenda, so that should help
... if you have any remaining questions please ask tomorrow during the F2F
... We have data on the most commonly installed applications for most platforms
... We're going to define a level 0 and a level 1
darobin: thanks
<darobin> darobin: in the CoreMob CG we will have level 0 which gives us a large majority of the most popular applications, and level 1 which gives us all of them
<darobin> ... you are all encouraged to join
[ Claes presenting ]
Claes: the client page sends postMessage commands
... And the service uses UPnP to talk to the light
<Daniel-Samsung> question: ack messages from the light ? answer is yes
richt: is the message from the client a well known format?
Claes: it's speaking JSON and the service converts that to UPnP
... Abstracting away the UPnP
... So you could speak to some non-UPnP thing
richt: Could I use this to talk to my TV?
Claes: yes
Cathy: can you do UPnP eventing?
Claes: yes
bryan: so do you have some native code?
Claes: yes
bryan: can you do it in pure javascript?
Claes: no
richt: it looks like this needs standardization
... And integration with the Intents specification
... We need a way to reach an address
<darobin> http://people.opera.com/richt/release/specs/discovery/Overview.html -> Opera's Discovery Proposal
richt: And then you could speak to it directly
bryan: could you do this with an internal web server?
Claes: of course, but we consider this more efficient
dsr: a generic mechanism allows access to Bluetooth, Zigbee, UPnP /ZeroConf
richt: why not allow low level access?
dsr: do you want access to packet sniffing?
richt: of course not
Josh_Soref: we decided yesterday that there would be a WebIntents compendium for UPnP
... We could have similar for Bluetooth and others
dsr: which forum for follow up?
richt: WebIntents
Wonsuk: tomorrow we'll talk about Tizen web API
fjh: can we talk about html media capture?
<Deepanshu> hints??
darobin: Mozilla has implemented their own thing
<fjh> dsr noted earlier that restricted API for multicast might be useful APIs
darobin: We noted that whomever implements first gets to pick names
<darobin> ACTION: Robin to kill Media Capture API [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action09]
<trackbot> Created ACTION-517 - Kill Media Capture API [on Robin Berjon - due 2012-03-28].
[ Bryan presents dzung tran's email ]
<bryan> Re Sensor API feedback to GeoLoc (http://lists.w3.org/Archives/Public/public-device-apis/2012Mar/0097.html)
<bryan> We need ability to integrate events from sensors to prevent event overload and processing overhead of doing this in Javascript.
<bryan> Some simple type of controls would be IMO essential for an effective sensor API.
fjh: part of this thread was impact on battery life and whether sensor is on it
... But this seems implementation dependent
bryan: for the part we give to the GeoLocation WG
... What's missing
<Zakim> Josh_Soref, you wanted to ask about QoI
bryan: If an implementer is firing events into the application, isn't that more expensive than filtering earlier
Josh_Soref: yes, we want browsers to filter earlier, but more work, simpler to pass what is from OS
... react to feedback as approach is often taken
... app asks for something, implemented, then discover getting too much information then ask for simpler API
... analogy to drown then ask for less, so point is to start with less in API, not more
... don't micromanage a firehose
richt: the android system lets you manage flow by application class
... Is sensors a wolf in sheep's clothing?
darobin: and are we losing sense of security
<richt> The Sensors API is simply a rebranding of Systems Information API without addressing the problems of that approach.
fjh: there was a request for generic API
<richt> i.e. losing focus on use cases for the individual sensors.
<fjh> that enabled extension to new as yet unidentified sensors
fjh: So you have an API for when you don't know how it will be used
<fjh> does understanding threat model depends on specifics or can it be generic to sensors
darobin: we should have a collection box for when people ask for a generic
bryan: on the one hand, postMessage is generic
... But we don't like sensors as generic
darobin: there's a difference between GeoLocation and temperature
Claes: discovering sensors using technology Intents, model makes sense to me
bryan: you'll have middle ware on the device
... Which will be used
... If we don't facilitate sensor access
... I'm good with not rehashing old ground
Josh_Soref: look how we simplified network info, likely to need to simplify sensors as well
bryan: agree, need prototyping
richt: need to see implementations
... Josh_Soref is right, we need to shred APIs and rebuild to address use cases instead of APIs requests
... We accept documents to CVS
... It's really hard to get rid of them
darobin: the point Josh_Soref made about network information
... Is that we aren't reviewing things
... When we do, the output is better, but doesn't look like the initial input
fjh: we need a CfC to obtain agreement to discontinue work on current Sensor API spec as-is, review different cases, refactoring use of WebIntents etc
richt: should something based on discovery be suggested?
Claes: yes, maybe based on Intents
bryan: once you get it, how do you talk to
<richt> you treat a generic sensor as a service.
<darobin> ACTION: Frederick to send a CfC about changing the design of Sensors [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action10]
<trackbot> Created ACTION-518 - Send a CfC about changing the design of Sensors [on Frederick Hirsch - due 2012-03-28].
<darobin> close ACTION-517
<trackbot> ACTION-517 Kill Media Capture API closed
<darobin> close ACTION-297
<trackbot> ACTION-297 Draft up TZDate closed
<darobin> close ACTION-397
<trackbot> ACTION-397 Coordinate with HTML WG chairs about Capture, include the HCG closed
<darobin> close ACTION-425
<trackbot> ACTION-425 Incorporate feedback for NetInfo, draft use cases and requirements section closed
<darobin> close ACTION-479
<trackbot> ACTION-479 Take FeatPerms to ScriptLib to see if this is something that devs would be interested in, taking caveats from implementers into account closed
<darobin> close ACTION-492
<trackbot> ACTION-492 Prod DavidA and Shane about feedback on Activities/Intents closed
<darobin> close ACTION-509
<trackbot> ACTION-509 Prepare gUM scenarios for publication closed
<fjh> ACTION-518: http://lists.w3.org/Archives/Public/public-device-apis/2012Mar/0136.html
<trackbot> ACTION-518 Send a CfC about changing the design of Sensors notes added
<fjh> ACTION-518 closed
<trackbot> ACTION-518 Send a CfC about changing the design of Sensors closed
Josh_Soref: my hope is that we deal with this via intents.
<bryan> I can agree in principle that to progress work on sensors that if the only way is to work on individual specs, we should do that at least.
<fjh> we do not want WG members to devote resources on work that might no progress or be implemented as is
Josh_Soref: for example a get temperature intent, and each individual sensor ends up with its own intent.
<bryan> I would recommend though that if we have consensus on the usefulness of discovering what sensors are accessible (e.g. via Web Intents), then that work should also proceed. Accessing the specific sensors then could be individual spec work.
bryan: for each sensor, how would you implement it as a service, as a XHR, or what?
dsr: it depends, you could use XHR, WebSockets, or whatever is appropriate.
Josh talks through an email with thermometer as an example of a web intent.
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0011.html - example B
^-- Josh's example for exposing temperature sensor via Intents.
This is an email from 21 Nov 2011.
Josh_Soref: This can be realized with a real sensor, or with a service exposed by a website.
OliverD: using web intents could result in exposing users to choices which aren't really important to them.
bryan: if we can use a consistent model for web intents for sensors, that would be fine.
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/author.html
Josh_Soref: I sent off 5 parts via email to introduce the concepts involved in web intents.
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0000.html
Josh_Soref: Some suggestions for likely common intents, e.g. save, send, print, share, call, chat. Some of these are similar.
... I can end up printing to a file, where the result is like a share.
Josh talks about the sensor examples, e.g. get temperature, get orientation.
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0012.html
Josh_Soref: We will need multiple deliverables, including a best practices note.
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0011.html
Josh_Soref: web apps shouldn't know how/where the data was obtained.
... We need a way for persistent user defined names.
Josh uses the term "hub" for assemblies of devices/services, e.g. a thermometer which knows where it is.
Josh_Soref: Users should be able to change the provider of a service without the application becoming aware of the change.
richt: RPC doesn't lend itself to hot swapping.
Josh_Soref: consider example of a keyboard, the app only needs the key stroke stream.
... swapping keyboards between keystrokes shouldn't affect the app.
... the user agent may register services as it finds them in the background, but apps only become aware when requesting a particular intent.
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0039.html
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0038.html
bryan: user invoked discovery example: I am in a hotel and walk up to a device.
... I may not have permission to use local discovery protocols directly, but instead could have access to a proxy discovery service.
Josh_Soref: user agents may record devices it sees advertisements broadcast over the networks it is connected to.
[ Josh attempts to open the Mac printing dialog to see if it shows any discovered printers visible via bonjour (zeroconf) ]
Josh_Soref: inspectors would be useful for developers working with intents.
richt: I love the idea of transparency, and think logging is really nice!
Josh_Soref: unaffiliated reputation providers would be valuable for services involving confidential data.
... print dialogs are an example of a design pattern that we should aim for with web intents.
... especially with the means to print to PDF as an alternative to printing to actual media.
gbillock: there are some sensors that don't fit the request/response pattern. Proximity is an example.
darobin: yes, proximity provides an event stream.
OliverD: still concerned with location example, where there are multiple location providers.
[ Josh talks about filters that indicate the location precision. ]
gbillock: there are application specific prompts for location.
... When people install a particular location provider, they can learn about the precision etc. at that time.
OliverD: that won't work for automatically registered providers.
Josh_Soref: I much prefer providers to offer a UI describing their service, e.g. a map with a circle indicating the precision for a location provider.
gbillock: showing a map can be helpful when the location is actually wrong!
jhawkins: Scalable extras for future use cases.
... may relate to Versioning.
<darobin> http://www.w3.org/wiki/WebIntents/ContactsAPI
gbillock: Like the idea of object literals that can be overloaded.
jhawkins: if you have separate extras in the future then you will have a different name.
... For the API itself when we need to make a change we add a version number to it.
darobin: we don't. we just add methods and properties.
jhawkins: let's look at permissions.
Josh_Soref: the fact that I trust foo.com for certain tasks it may not apply for others.
... fine to remember things I come across as I browse but I still want the choice when I actually need something.
jhawkins: Sounds like an addition to the registration API for 'Learn more...' about this service.
Josh_Soref: Yes. Would also be good if it also records when and where I discovered the service initially.
jhawkins: not opposed to 'Learn more'. It would be optional. It does add another attribute for registration but seems reasonable.
... "How do we give persistent permissions for the same action type on one page." (from sticky board in room)
Josh_Soref: Assuming I'm on a website that is operating a weather station. requires monitor temperature and get location.
... I want to be able to go to the site and have these things just work together so I can get to the information quicker.
jhawkins: two things. the first is remembering the preferences. the second is not requiring a user initiated action.
Josh_Soref: Looking for a way to make the whole process automated somehow.
... an easier case, we'd like to use intents to provide GeoLocation.
jhawkins: with GeoLocation there are obviously privacy concerns but in general I like the idea.
... are we thinking this requires changing to the API?
gbillock: might require a change to the semantics of the user gesture we have right now.
... Letting intents trigger without a user gesture is something we don't know how to do yet.
... Maybe if you get a verification page that could work instead of something up front but we would need to think about it more.
jhawkins: we should take an action to define an error that says "This was not user initiated".
... "how much UX is required for service registration?" (from sticky board in room)
... josh, you suggest "none".
Josh_Soref: right
... I have some ideas on this. The more you use something then these should appear in the services list with others hidden behind.
... so there are some heuristics to use here for service listing: when, where I discovered it, how often I've used it, when I last used it.
<dsr> how popular a service is, whether my friends use it etc.
<darobin> I've listed the Use Cases at http://www.w3.org/wiki/WebIntents/ExtraUseCases
<darobin> now we need people to fill them out :)
<richt> record action for james to specify the no info bar recommendation idea.
<richt> can't directly assign an action to james as he's not in the tracker system
jhawkins: "Should the user be able to restrict web intents to a list of well-known action types" (from sticky board in room)
... It's up to the user to choose what they're doing. We will have strings for the top actions. Might just confuse the user to give them an understanding of what the actions are.
... may also have some localization issues.
Josh_Soref: On localization, it may problematic if we get verbs registered in e.g. Chinese.
jhawkins: that's fine. that would probably be useful in a localized context.
... ...for localized actions.
gbillock: we have been suggesting the action strings be URLs.
... so it's just URL.
jhawkins: Sometimes this might make sense for non-English communities or actions that relate to a specific locale.
darobin: Generally we need a best practice not to mint new actions where existing actions already exist.
<darobin> "A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources." (from http://www.w3.org/TR/webarch/#URI-scheme)
jhawkins: right, darobin. that makes sense.
OliverD: This may not be an issue but the risk might be for a service to register hundreds of actions.
jhawkins: it could be an issue. a page registers for every intent action imaginable. we need to manage those cases.
... e.g. through social recommendations, feedback, reviews.
... off on a tangent. how far can we spread knowledge of sites. It's really about reputation.
... we might be heading towards needing this reputation to be queryable.
... back to the question at hand: "Should the user be able to restrict web intents to a list of well-known action types?"
... maybe it's not about the action but the services themselves?
bryan: I may want to turn off a whole action.
... there should be a way to disable certain types of actions you don't want to see. maybe I want to disable 'share'.
jhawkins: Isn't that a blacklist?
bryan: I want to disable a certain action. The opposite might be true. Disable all and enable some.
Josh_Soref: So if there's an annoying client I want to block them without them knowing about it.
jhawkins: I'm not opposed to adding intent identifiers to elements.
... but this is getting a little complicated.
... we could compromise that this only works on clickable things. onclick.
fjh: what's the objective here?
jhawkins: if the user can disable a certain action and nothing happens then the page is going to know it.
fjh: why can't we have a default action. let's take 'pay'. could I choose something that doesn't actually do anything i.e. a deadend stub?
... that is the default action that then doesn't actually do anything meaningful (in this case 'pay' for something).
jhawkins: we can't say anything on white/black-listing unless we have a solution for this question.
Josh_Soref: If a site wants to do something and the user doesn't want to do it then the site is being annoying.
... but there may be parts of the page that are useful.
<fjh> choice not to visit site or to leave, choice not to pick
jhawkins: we have a picker so you have another layer of choice. If you don't want to pay you don't choose a service and click a button. The choice remains with the user to actually trigger the default action.
... so the answer to the question is "no, because the user still has choice to trigger any service to fulfill the action".
^-- FYI: the question was "Should the user be able to restrict web intents to a list of well-known action types?"
jhawkins: let's take a look at 'Privacy' issues.
... "Informed consent usable for Privacy" (from sticky note on board)
fjh: Essentially the user needs to know what they're doing and why. So we need to be careful that there is enough information about what's going on when invoking an intent/service so users understand it.
gbillock: not trivial to get a user gesture e.g. pop-unders.
fjh: we should put a note in the spec around user gesture requirements and providing necessary context for decisions and permissions.
Josh_Soref: Even though we want fast-paths to action completion we don't want to make it trivial if I'm browsing a web site for the first time.
jhawkins: the UI won't necessarily be in the location where you initially tapped to invoke the picker.
Josh_Soref: I don't think that is sufficient but I'll comment more later.
jhawkins: "How will web intents work with Private Browsing - Registration phase"
... simple answer. no intents registration in private browsing mode.
Josh_Soref: I'd propose that we register in the context of the private browsing session but that's lost when leaving the private browsing session.
jhawkins: ok. works for me.
darobin: same principle for e.g. cookies
jhawkins: second part: "How will web intents work with Private Browsing - Invocation phase"
... actions are still available.
darobin: we could leak information via these action invocations.
... we could add a note to the spec "Implementers should take issues relating to private browsing into consideration when invoking intents so as to avoid identifying information leaking.."
jhawkins: next up "How should explicit intents work with private browsing"
darobin: same as normal.
jhawkins: "Should the UA warn when the intent action is rare"
Josh_Soref: A UA should consider doing that.
gbillock: If you haven't seen it before you get a 'speed bump'.
bryan: we could be hampering extensibility if we keep putting in road blocks.
jhawkins: I agree.
fjh: I say we keep it simple rather than introduce obstacles.
jhawkins: "What can we hide from providers". What is too much to give to providers?
Josh_Soref: In my outline I suggested that there should be some transparency/inspectors of data travelling to/from service providers.
jhawkins: giving a pseudo-sandbox to providers?
Josh_Soref: potentially.
... For example I don't want a site to know which provider I'm using.
... and vice versa.
darobin: we can limit the information transmitted e.g. no referer header.
gbillock: the referer for instantiating a service should be the intent action.
<fjh> +1 to no sharing referer header to provider, to avoid information leakage, a privacy concern
darobin: agree
jhawkins: agree
Josh_Soref: agree
<fjh> +1 to sharing intent action as referer
Josh_Soref: all above agreeing with gregb's proposal.
... can we ensure people can't introduce line feeds in to an action?
gbillock: good point. it must be properly escaped.
jhawkins: we'll make a note to explicitly address this point.
... "Inline disposition". General discussion. Should we do it?
fjh: inline disposition has a reason for being specd, it offers a provider the means to offer a usable page
Josh_Soref: Who requests the inline disposition - sites?
jhawkins: yes
... given form factor considerations you may not have inline dispositions. e.g. mobile phones.
... so you can request it but shouldn't be concerned if you don't get it. It's a preference only - a hint for the UA.
... the default is 'window' disposition.
... that's "I want a new context".
... we're more flexible on inline disposition
Josh_Soref: Is the intents dialog modal?
jhawkins: tab modal. z-indexed on top. you can still interact with the tab content.
gbillock: when we think about mandating inline, when service providers are going to support intents, they're going to use inline disposition most of the time. The user experience will be consistent when a user e.g. visits their bank site.
Josh_Soref: If certain providers do and others don't then we get different experiences.
Claes: We see use cases for inline disposition from our experimentation with web intents to date.
... It is easy to spoof but still would hope for more options - inline in picker, hidden(?). using SSL for all services may be necessary.
... we should do a security review and assess this last point.
<Zakim> darobin, you wanted to ask about inlined using iframe or something like that?
darobin: wonder if we can assign things directly to an iframe.
Josh_Soref: still potential for click-jacking against any embedded content.
gbillock: any anti-clickjacking mechanism could not be applied to that page.
jhawkins: how do you close an embedded service?
Josh_Soref: not easily.
jhawkins: concern would be on the security aspects of course.
<darobin> [I wonder if we could have always-on-top iframes to help with clickjacking issues]
jhawkins: not sure if we should even leave allowing inline disposition up to implementers.
Josh_Soref: we may want a MUST NOT statement in the spec around these points.
... Instead of offering embedded we're kind of offering hidden instead.
jhawkins: we started with this in the spec.
... we decided against it due to UX issues. We can't preclude it since we have use cases for hidden mode.
... we took it out for a.) UX issues b.) the assumption you should be able to display *something* to the user.
<richt> ACTION: Claes to add a proposal for hidden disposition. [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action11]
<trackbot> Created ACTION-519 - Add a proposal for hidden disposition. [on Claes Nilsson - due 2012-03-28].
jhawkins: "Will clients want UA provided UI for intents?"
... my feeling on this is no.
... seems a bit much.
Josh_Soref: Let's push this in to the future work category.
jhawkins: right.
... probably belongs in HTML5.
... "Saving pipelines". We talked about this yesterday.
Josh_Soref: assuming 'share' and 'save' have the same action url.
jhawkins: "Accessibility".
... A lot of work happening on this topic in other groups at W3C.
... it's a work in progress.
fjh: let's take a 15 minutes break.
[ Break ]
fjh: 1st question - why would something be hidden, don't we want the user to be in control? 2nd question: why would apps lie about the purpose of an intent?
jhawkins: issue - how can the verb space be managed for interoperability
... the lying issue was about pages misbehaving, we should not have to worry about that
fjh: on hiding the actions, this limits the user choice
jhawkins: if there is no need to display a UI, we don't have to force the page to provide a UI
Josh_Soref: the picker is always displayed
fjh: ok, understand
jhawkins: issue - what can we learn from previous groups
fjh: will take an action to look at WS* to see what might be relevant
jhawkins: issue - android intent holes to avoid
... will take an action to talk to Android team to see what might need to be considered
<fjh> ACTION: fjh to look at WS* to see what might be relevant [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action12]
<trackbot> Created ACTION-520 - Look at WS* to see what might be relevant [on Frederick Hirsch - due 2012-03-28].
jhawkins: issue - what is the interaction with other groups?
darobin: it means what does a group do when they want to create a Web Intents based API?
... outside W3C we don't need to worry
... we will write specs, try to do it right, and people will cut & paste
jhawkins: where will verbs be defined for UPnP?
darobin: Claes will have an AI to coordinate with UPnP forum on the mapping of intents to UPnP
<darobin> ACTION: Claes to coordinate with UPnP forum about extensions required for Intents [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action13]
<trackbot> Created ACTION-521 - Coordinate with UPnP forum about extensions required for Intents [on Claes Nilsson - due 2012-03-28].
jhawkins: issue - use cases for persistent permission, e.g. an app comes registered with another app
darobin: this fallbacks for intents
Josh_Soref: is it possible to have more than one suggestion?
jhawkins: would we say it's up to the UA to determine how much to display?
... issue - HTML5 impact
... this is the intent tag
... issue - how much UX/UI should be MUST?
... we decided nothing
... issue - what is the relationship between client and service pages?
... seems to be already answered in the discussion
... issue - how to educate users?
... we decided it was pointless
... issue - MITM attack
... maybe AI is for someone to attempt MITM to demo the risk
Josh_Soref: should be pretty easy
darobin: same as phishing
Josh_Soref: why phishing vs. MITM?
... the FB URL for sharing is HTTP - in a coffeehouse the DNS may be local
jhawkins: we could add a best practice on use of HTTPS
... what are spam/phishing risks?
darobin: nothing too much different from the rest of the web
Josh_Soref: assuming the provider trusts the user's data, do users know what they are +1'ing?
... it's a form of spam, for users to be unaware and have to be told what they are sharing
jhawkins: this could allow savvy users to point out bad pages
... someone had an AI for logging?
... issue - is there a case for relaxing same-origin?
Josh_Soref: my case is that while I authorized sharing, I did not auth other things
jhawkins: this is the same as the web permissions problem
... issues - auditing - Yes
... issue - service wants to be invoked by certain clients
gbillock: this comes up for regulatory cases e.g. banks
... something the server can implement
... could be used for fingerprinting
... don't want that
Josh_Soref: we don't want enable servers to whitelist clients
jhawkins: we could say it should be a SHOULD for some cases
[ applause ]
<anssik> http://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html
<anssik> http://www.w3.org/2009/dap/wiki/ImplementationStatus
anssik: latest is LC ended 20DEC2011 - working toward CR. Implementations exist for WebKit and mozilla
... WebKit landed a week ago, in FF 10 2 months ago. 2 major projects, also PhoneGAP
... all the open issues and comments have been closed
<bryan> fjh: acks
anssik: will organize a call with director to move it forward
<anssik> http://www.w3.org/2009/dap/wiki/FutureWork
anssik: some new features have been proposed - these need to be in the future work wiki
fjh: incl the email traffic this week
anssik: yes, those should be in the future work wiki
fjh: so all that commented should update the wiki
anssik: seems no more to discuss at the moment
<fjh> https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-battery-status-20111129/doc/
anssik: congratulate yourselves
[ applause ]
<fjh> disposition of comments is completed in LC-Tracker
anssik: smallest API ever
<fjh> disposition of LC comments -> https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-vibration-20120202/doc/
anssik: LC ended 1MAR2012. Spec is also going to CR. Implemented in WebKit and mozilla. WebKit a month ago, and mozilla in FF11 one week ago
... so this is a done deal, very tightly scoped. as with battery, prefer future work to be documented on the wiki page
... one issue has come up, in vibration we don't have a privacy section, IMO we have baked this into the API
<anssik> "If the device does not provide a vibration mechanism, or it is disabled, the user agent must silently ignore any invocations of the vibrate() method."
<fjh> http://www.w3.org/TR/2012/WD-vibration-20120202/
<anssik> "For example, an implementation might abort the algorithm because the user has set a preference indicating that pages at a given origin should never be able to vibrate the device, or an implementation might cap the total amount of time a page may cause the device to vibrate and reject requests in excess of this limit."
<anssik> "An implementation may abort the algorithm at this point."
anssik: other one important
... on purpose we are trying not to spec UI. I'm wondering if this guidance is needed for implementers to do the right thing?
darobin: a privacy section is not required, if we are satisfied we don't need a section
anssik: the notes should be enough. implementers will come up with innovative UIs. No privacy/security threat except battery consumption. Users will likely just navigate away.
... that was my only issue.
<anssik> http://dev.w3.org/2009/dap/vibration/Overview.html
<Zakim> darobin, you wanted to bring up testing
darobin: we don't have any tests for battery right now?
<darobin> ACTION: Robin to write tests for Battery [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action14]
<trackbot> Created ACTION-522 - Write tests for Battery [on Robin Berjon - due 2012-03-28].
anssik: no, WebKit contributors have been asked for tests, there may be something specific for WebKit
... it's on my todo list for battery
... have to have tests for CR
... and two interoperable implementations
... defer to chairs to handle CR transition
... will take an action for both specs
<fjh> ACTION: anssi to work on test cases for battery and vibration [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action15]
<trackbot> Created ACTION-523 - Work on test cases for battery and vibration [on Anssi Kostiainen - due 2012-03-28].
darobin: have some time to work on the test suites
anssik: could use this time to talk about other topics related to vibration
richt: don't see use cases - wondering why to expose vibration
bryan: games
<darobin> (and sex toys)
anssik: it's intentional, use case was for gaming
richt: re note in the spec about indefinite vibration - what is a decent amount of time for a vibration to end?
... 2nd thing is nothing about navigating away - this should cancel the pattern
anssik: in FF about:config, the default max is 10 sec
<anssik> in FF about:config, see dom.vibrator.max_vibrate_ms
<fjh> why isn't this decision of app?
anssik: may be more or less per the impl
... steps 5 and 7 tell what to do
... an exception is thrown
... not a decision of the app, better to have the UI control it - and configurable
... similar to storage limits
<fjh> got it, misunderstood what richt was saying
darobin: when will opera implement it?
<Zakim> darobin, you wanted to ask when Opera will implement
richt: unsure
<darobin> \o/
darobin: thanks to anssik for joining and doing all the work
<fjh> +1 thanking Anssi
anssik: re AOB, discussions on HTML Media Capture - can I help. we are stuck with the capture, right? Did we agree on a way forward?
darobin: we are waiting on the 1st implementer, to see how the hint is shaped
anssik: no agreement yet on the hint?
darobin: not yet
... on the media capture TF people think the declarative way is still useful
... isn't chrome implementing?
... does Chrome have documentation?
<anssik> http://code.google.com/chrome/mobile/docs/overview.html
gbillock: no idea
<Deepanshu> Is someone implementing HTML Media Capture?
anssik: need to know the details of the implementation
<scribe> ACTION: to gregb to find out what's up with Chrome [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action16]
<gbillock> Is there a URL I can go to test the media capture?
<darobin> http://lists.w3.org/Archives/Public/public-device-apis/2012Feb/0046.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Feb/0046.html
darobin: history lesson on DAP charter re system level APIs, unsafe, requiring permissions... did not get support in the broader web community, so we switched to browser only
<fjh> email request re system level APIs -> http://lists.w3.org/Archives/Public/public-device-apis/2012Feb/0047.html
darobin: in meantime we have things being developed, but other people are using web for the entire system. where and how to standardize the APIs comes up regularly
... e.g. APIs for Tizen and B2G
... we could do this in DAP or a new group e.g. SLAPI
<Zakim> fjh, you wanted to talk about agenda
Josh_Soref: 1st question geoloc, vibration, battery. not system level APIs?
darobin: no, they work in the browser security model
Josh_Soref: file writer, file system ?
darobin: they are getting close. using a picker approach is OK, but some apps need more system level access.
dom: well geoloc could be said to be borderline; its security model is a bit awkward for browsers IMO
darobin: we are seeing limits to the ability to expose system level APIs without a permissions model
richt: we have seen more progress since rechartering. had to work hard to set expectations. would not be good to upset that balance. recommend system level be in a new group (or not here)
... trusted/installed approach leads to poor designs
... would not mix that up with the browser approach
<Zakim> fjh, you wanted to suggest we review Sakari's email
bryan: btw, APIs are at https://developer.tizen.org/help/index.jsp?topic=%2Forg.tizen.help.web.api%2Findex.html
<gbillock> WRT my action item, I'm asking about http://dev.w3.org/2009/dap/camera/ ?
fjh: sakari's email describes issues leading to WAC/Tizen needing to develop non-standard APIs
... wondering if there is a need being missed
<richt> gbillock: I think the action was to ask about implementation of http://www.w3.org/TR/html-media-capture/
Wonsuk: Tizen has Bluetooth and NFC. some more APIs, but not sure they require standards
<fjh> what do we need beyond what we have in DAP, what is the issue here in concrete terms?
<richt> gbillock: this is why: http://davidbcalhoun.com/2011/android-3-0-honeycomb-is-first-to-implement-the-device-api
Wonsuk: B2G has more items e.g. call and control for wifi, browser APIs etc
... Tizen has a few items, but B2G more
fjh: maybe we have 90% of what is needed, and what is needed could work in a web way, and we could consider the reqs and may not need to spin off a new group
<Deepanshu> B2G wants some API, why don't they define themself?
<richt> gbillock. hmm that's the same link with a different name. didn't realize we published in two different normative locations.
fjh: maybe stack, unclear about Bluetooth... details are needed on what is not being met
<richt> ... actually, one is the editor's draft and the other is the latest working draft.
fjh: we didn't decide yet what is the right way
... tomorrow we will introduce the Tizen APIs and need to investigate the B2G project APIs
<fjh> I suggest that we need to understand (1) what cannot be done with DAP APIs currently being developed, and (2) whether a web approach might not work for what is needed - then we can understand what might be needed to be done at a system level, implies a charter for decision
fjh: AFAIK system level APIs like call and wifi, browser USB ...
<darobin> Mozilla's (partial) list for B2G: http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/5649fb1085144d13/34fe9feea3887140
Josh_Soref: DAP had browser vendors but they ran away. DAP got them back. We're hearing from a browser vendor or two thinking about doing what they ran away from.
... not sure how practical it will be - will it be portable? e.g. USB device paths
darobin: may issues, but they can be worked out
... e.g. no portability with the browser APIs
Josh_Soref: hoping intents will solve some problems
... can we ask that new ideas be considered here first?
darobin: no, such constraints won't work
... it can say there needs to be coordination
... there is an incentive for surfacing APIs to the browser, but some things can't be
<fjh> my point is that we should see if how much of this can be used with our browser approach, then see the gaps, then see if a charter is needed
<fjh> also suggest that writing the charter is not the work of this group
Josh_Soref: assuming DAP manages to get out a REC that supersedes other work... what happens?
richt: worried about intergroup conflicts
<fjh> it all depends on the real requirements as to what is needed
richt: would a reduced scope lead to conflict - there might be significant overlaps
Deepanshu: do we need system level APIs in the first place
bryan: we don't have them
darobin: we don't have portable APIs
Deepanshu: are we talking about installed natively running APIs?
Josh_Soref: yes, as in B2G they only have JS
Deepanshu: why does B2G need W3C to do this?
darobin: because they are a project not an SDO
... some of the parts can't be done in a genuine web context
B2G = Boot to Gecko https://wiki.mozilla.org/B2G
bryan: took a lot of stuff out of DAP since we could not get it to work in the browser
... had features we needed, could have some in the web with limited scope, but need them back on the table somewhere, market motivation
... need standardization to avoid fragment
<anssik> now that we're talking about system level APIs such as those spec'd by Tizen, B2G, and friends you may also want to consider Windows Runtime JS APIs: http://msdn.microsoft.com/en-us/library/windows/apps/br211377.aspx
<anssik> Microsoft is a member of the DAP WG, so they should be able to chime in and contribute if they see value in standardizing system level APIs
anssik: heads up MS is doing something similar in Windows 8 - if that work goes somewhere, we should get feedback from them
... adding one more player
darobin: hearing some level of interest, some consensus not to do it in DAP - next step may be to draft a charter
dsr: a charter develops by the W3C team with key stakeholders
... for this group, do we want to plan recharter for future work?
darobin: it would make sense to do both
Josh_Soref: we should also talk about crypto
... re chartering, AC input is also sought
dsr: e.g. if key stakeholders would not join, we may need to change the scope
<bryan> ACTION: robin to prepare charter for system level APIs [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action17]
<trackbot> Created ACTION-524 - Prepare charter for system level APIs [on Robin Berjon - due 2012-03-28].
darobin: extensions should be considered in this scope
... e.g. FF extensions have access via XPCOM to the whole system at least what is exposed to the user
... in laptop OS e.g. Chrome OS the extensions are how the app talks to the system
Josh_Soref: crypto WG will define a simple API - a good thing, e.g. validate/create a signature
... some groups want to HDMI type things for a secure channel to TVs
<fjh> Agenda plan for Thursday morning (1) feature permissions (2) Tizen review , after lunch (3) NFC
darobin: this is related to the HTML encrypted media proposal
<fjh> remaining to discuss apart from these items for tomorrow - interop/testing (talked some today), calendar, network information API
Josh_Soref: there is an ask to send content to secure elements
bryan: e.g. UICC
Josh_Soref: some asks to get content over HTTP with a signature and used on a page
... and pull into an HTTPS page without breaking the secure lock UI
bryan: a signature will not protect the content
Josh_Soref: the signature is attached and the content can be trusted
darobin: if there is anything to add to DAP charter re this, please propose on the list
Josh_Soref: assuming no more WGs will be created to address things like this
... concerned about too many WGs
richt: what about network services discovery
... suggest to put on the agenda
<fjh> http://www.w3.org/2009/dap/wiki/F2F_Agenda_20-22_March_2012%2C_Shenzhen%2C_China
[ Break ]
<fjh> I have updated the agenda for tomorrow
jhawkins: Client doesn't know the data format what you are sending. One solution is, in case of binary data, using URL format
<bryan> Web Intents type discussion settled on a URL approach for binary data rather than adding a type parameter
darobin: What only URL?
... what if it's a HTTP URL and not in same origin, then i can't read it. that sucks
<bryan> Are there length limitations on the size of binary data that can be transferred (I assume the blob URL is a reference to a blob in memory, not the actual data, as compared to a data: URL).
darobin: if it's always Blob URL, then I'm happy
jhawkins: this problem is there in case of token also
Josh_Soref: in case of thin client, we cannot force client to download/upload large data
darobin: we can still more around URL. but what happens in case of binary data
... for binary data is only Blob
jhawkins: yes
... still need to talk about, changing type to not necessary a MIME type
darobin: what you get back, it to be decided by intents..........
jhawkins: services would have to register for all type of images
darobin: ????
jhawkins: why MIME type?
Josh_Soref: pull up http://schema.org/
<bryan> If type is MIME, can we use a list of MIME types?
darobin: issue is..if you are editor of video type XYZ at it only support WebM?
jhawkins: we don't have to specify date as URL
darobin: ???
<bryan> What if the intent supports multiple MIME types?
darobin: we are not restricting to schema.org
Josh_Soref: if it doesn't understand image/muppet....it should be able to understand. The browser should be able to wrap it in an image object. We have to specify that
<gbillock> Do not want
darobin: intent is not solution for RCH
... concerned about the ability to do image/*
... how it is not solved by ????????????
... if you want to pick a content then you don't have MIME type for all these
jhawkins: but if, it's a media type............that will be handled as such.
<bryan> By string matching, do you mean direct matching, regexp, wild cards?
darobin: we can to string matching
gbillock: if it's a MIME type to use MIME type semantics
... if it is not we can use string matching
<bryan> If only one MIME type is supported by an intent, would I need two different SHARE intents for images, video clips, voice clips, etc.?
Josh_Soref: what language we are in js, HTML?
... intent can use all
... best practice is you are JS then js unicode escapes, if you are in HTML you should have entity encoded
darobin: we can say don't do %encoding
jhawkins: it URL or string....it's URL
<OliverD> ACTION: James to define how the Type field should be defined, forbidden characters; mime types or absolute strings [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action18]
<trackbot> Created ACTION-525 - Define how the Type field should be defined, forbidden characters; mime types or absolute strings [on James Salsman - due 2012-03-29].
<darobin> close ACTION-525
<trackbot> ACTION-525 Define how the Type field should be defined, forbidden characters; mime types or absolute strings closed
<bryan> Answers to the questions asked were: (1) there is no limit on content size when using blobs; (2) multiple content types can be supported by an intent (the matching algorithm must support matching in a separated list)
jhawkins: if string matching, if have to augment the definition of empty type
Josh_Soref: we want to make is */* include schema.org
darobin: either you are using MIME type
jhawkins: we are agreeing default should be */*
... default is */*. if empty it's also */*
darobin: anyone object to killing it?
<fjh> http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
fjh: let wait for some discussion
darobin: explains about current draft
... the model is broken
... usability feedback is not good
... the proposal is to drop it
... only people who need it is the notification people.
richt: we don't need this even for web notification
fjh: web notification also wants it to be dropped
<richt> for example, an alternative approach is allowing web notifications by default, making those notifications tab modal and allowing the user to then elevate these notifications to a system level on the displayed notification itself.
jhawkins: what do john, Laszlo says. Laszlo hasn't touched this draft in months. John will be happy with whatever web notification decides.
<Deepanshu> ACTION: darobin to properly end the life of the document [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action19]
<trackbot> Created ACTION-526 - Properly end the life of the document [on Robin Berjon - due 2012-03-29].
<Deepanshu> ACTION: fjh to send email to other WG li [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action20]
<trackbot> Created ACTION-527 - Send email to other WG li [on Frederick Hirsch - due 2012-03-29].
<fjh> web notifications thread -> http://lists.w3.org/Archives/Public/public-web-notification/2012Mar/0021.html
<fjh> http://lists.w3.org/Archives/Public/public-web-notification/2012Mar/0029.html
darobin: any other business on this
<richt> one of the best permission interfaces is the file picker. for the most part it's not even considered a permission dialog. It's permission based on a user-driven action (selecting a file in this case). That's something we aspire to in API design.
https://developer.tizen.org/documentation
Jungkee: Developer site is in beta stage
... providing HTML5 feature
... objective is bringing device functionalities to web
... priority API includes contact, calendar, messaging etc.
<darobin> http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts -> this addresses the TZDate issues
Jungkee: for Contact Tizen have addition function like save, update and delete
... B2G also have save and update
richt: what the execution environment trusted or un-trusted?
Jungkee: Tizen has both
darobin: packaging?
Jungkee: WAC packaging model
richt: you have proposal for version 2 NFC, Bluetooth?
darobin: packaging problem is not solved somewhere
... a new group can work on this
... no screen shots available
<darobin> https://wiki.mozilla.org/WebAPI -> B2G WebAPI
darobin: Mozilla are in DAP........they have been providing stuff to DAP
... these list of API may not be safe in browser environment
richt: if you are running in un-trusted env. then the APIs could be candidates for DAP and the untrusted web environment.
Jungkee: we will think about it
darobin: what devices?
Jungkee: dual CPU model, Intel is coming up with another hardware
darobin: who is contributing
Jungkee: Samsung, Intel
http://www.tizenassociation.org/
http://www.tizenassociation.org/index.php/tizen-association/board-of-directors
darobin: the fact they are using HTML5 probably makes this stuff relate to the work in the Core Platform CG.
... all API are namspaced under Tizen.***
... there is a demand of 64 bit version of SDK
<darobin> http://w3c-test.org/framework/
<darobin> http://w3c-test.org/framework/app/suite
<bryan> http://www.w3.org/wiki/Testing
<bryan> Demo tool which I'm working on, to characterize how well specs markup requirement assertions: http://bkaj.net/test/dap/assertions.html
darobin: <goes through how the W3C test suite / test harness works>
fjh: Can you retrofit a test suite here?
darobin: yes. when creating tests the test tool will pull out sections as test placeholders.
... when we have a convention for testable assertions then we'll support that implicitly in the W3C test tools.
bryan: the documentation of the framework is where?
<fjh> darobin: ask mike smith if interested in getting access...
<darobin> http://w3c-test.org/framework/docs/maintainer/
darobin: link pasted above is the documentation for preparing test cases.
... plan to document the user interface soon. Perhaps next week.
bryan: I put a couple of links in the chat. There's a Wiki to capture some of the testing approaches.
... http://www.w3.org/wiki/Testing
... trying to create a summary of what's currently done across the W3C
... hope to capture information as we go in this wiki.
... the other link I posted was to evaluate how well a spec is marked up with normative requirements and how easy it is to extract those assertions and auto-generate test frameworks.
darobin: a few things could come out of this discussion. will talk with bryan to see if we can integrate his stuff.
... if you want to start writing test cases then write to me and we can sort that out.
... another thing, the core mobile CG is going to be writing a lot of tests. Next week we're going to have 600 or so new tests.
... will be figuring out a way to import and approve submitted tests.
... also planning to work with Anssi on vibration API tests.
... hopefully we'll get some test review tools here.
bryan: one action item may be to come to consensus on what should be the markup approach. then someone to document that ala Marcos's document @ http://www.w3.org/TR/test-methodology/
... make updates to that document perhaps. I'm happy to work directly with the editors on that as required.
current spec: http://people.opera.com/richt/release/specs/discovery/Overview.html
richt: coming from a background of home networking stuff, and desire to maintain some flexibility, so we came up with the above proposal.
... It is discovery based upon existing protocols, e.g. UPnP and Zeroconf.
... It is at a different level from what we have in web intents. We just do discovery and expose service stubs.
... The stub could be an abstract URL. The URL is white listed as a result of user approval.
... You can then work with the URL, e.g. push things to it.
... We currently use a proxy, but that shouldn't be necessary if we get things right.
... CableLabs have a WebKit version and an Opera version is forthcoming.
... Some recent discussion with Mozilla.
... for web intents, you need a proxy to map from the service protocol to the web scripting message channel
gbillock: ....
richt: the user approval whitelists the service.
Claes: I've been looking at this for a while. You could use this within web intents or separately. See my slides from Tuesday.
richt: this isn't driven by actions as in web intents
[ Claes presents his solution from his slides ]
[ gap where robin takes over with minute taking while this computer was showing the slides ... ]
gbillock: the intent dispatcher could implement the white listing of networked services, although I am not sure of the details.
richt: we need to be careful to avoid shoe horning things in a poor fit
gbillock: yes, web intents isn't for everything
richt: we essentially take out the proxy so web app can use XHR etc. directly without need for CORS, the discovery is done in the background
Claes: would like richt's comments on Claes's proposal as in the slides
dsr: the message channel approach is agnostic to service protocol, and works nicely for Bluetooth, USB, bonjour, UPnP, Zigbee and so forth
richt: our approach is just focusing on http based services
gbillock: want to avoid exposing low level networking details in message channel
richt: UPnP is the tip of the iceberg for networked services, bonjour (zeroconf) is
... perhaps more flexible
gbillock: there couldn't be something on the other side of the message channel to do a translation to the service's protocol
richt: UPnP allows us to just use XHR
... it has to support CORS, that deprecates existing devices because they don't support CORS
Claes: how is that different from your solution?
richt: because when we accept a discovered device we whitelist it for x-origin access
Claes: we could add that to the Intents approach
... I need to look into the details
richt: so that's still a pending question
gbillock: yes. Mechanically I think you can have a browser-driven map, so hypothetically
... there could be a discover action which would create that CORS whitelist. In theory,
... if we could whitelist on service discovery we could work that into intents. I'm not
... if it would be difficult or easy, but it's worth looking into. Would be super-cool
[ OliverD nods ]
richt: would be super-cool, but feels like shoe-horning into Web Intents. We can put everything
... in there.
gbillock: yes, we were hoping to draw a line around WI
richt: right, and I don't see these two proposals as mutually exclusive, they have similar UI
... and can be used together
gbillock: and users are going to think of them as the same if they have the same UI, which is a win
richt: indeed
... so we essentially take out the proxy, we're going to need some browser logic to take these things
... out. Bypassing the proxy. WI and Discovery live together. If Discovery fails we can push to WI,
... but this is a simpler model. Opera supports this, we've proven that it's possible. Doesn't hurt
... performance, and exposes at the right level.
Claes: would be interesting to propose your API to be used with the thing I shows to see how it could fit in
darobin: the issue with the proxy, I would like to see this scale to things other than network discovery
... e.g. Bluetooth, USB, etc. I think that the MessageChannel approach has a lot of value for that.
richt: Yes MessageChannel is agnostic and good. Here, we've limited the scope to HTTP-based services to keep
... it simple. We're not trying to do something radical, mostly discovering and whitelisting. But
... of course we want to look at Bluetooth and friends.
... but it is just one possibility
dsr: we need to keep layers clean, and avoid web apps dealing with low level crud for specific service protocols, the web app code for a given intent should be independent of whether the service is zeroconf, UPnP, USB or Bluetooth
Josh_Soref: +1
richt: it is a question of ...
bryan: a proxy could map services into a clean XHR interface
... something has to implement the discovery of services and that acts as a proxy, you can't "register" everything
... when does white listing occur, when the user picks a service, right? [answer yes]
richt: ...
bryan: I am in my neighbor's house and turn on my phone, and a media player is visible via UPnP. What about access control when I am picking a service.
richt: the access control will be exposed when you try to use http to access the device.
bryan: that concerns me, we shouldn't show services for the user to pick if the user won't have access rights.
richt: that's good feedback
... we could add some wording to the spec to recommend checking the access before populating the list.
<richt> p.s. this exposes nothing to do with SOAP.
aizu: UPnP is based upon http protocol and SSDP. web app script needs to access device server.
... we should look at architecture level, integrating SSDP support into browser is not enough
richt: we have had SSDP support in opera browser for several years now.
... we might be exposing the wrong level by enabling web apps to talk UPnP http .
<richt> json was possible because XHR didn't tie the developer to a specific messaging format (at the time that was XML).
richt: also a new protocol wouldn't deal with legacy devices
gbillock: without whitelisting, you would need to update UPnP devices to add CORS headers
dsr: yes, I did that for my demo
aizu: legacy devices don't support CORS
<Zakim> josh, you wanted to explain that CORS is addressed by a one-off-whitelist by SSDP
darobin: normally hole punching is completely on the client side, so we can address legacy devices with the whitelisting mechanism proposed by richt
Josh_Soref: CORS is addressed by a one-off-whitelist by SSDP
Claes: richt suggests this is a proxy-less solution, but the web app client still needs to know the UPnP details for communicating via XHR with the service
... we see that integration with web intents will enable a decoupling on the low level details
richt: you either abstract behind web intents or afterwards (i.e. as in a web page script library)
Claes: do you (richt) name the web intents as a proxy?
<bryan> re access control, should the API support the functions described in UPnP-gw-DeviceProtection-v1-Service-20110224.pdf to ensure that the device if it includes access controls, they can be validated prior to the device being included in a picker? Or would that occur later in the process of accessing the device?
richt: you either have the web apps talking directly to the service over XHR in which case you need whitelisting mechanism or CORS, or you have a hidden gateway behind the web intents message channel.
... we should definitely look at whether we can solve this with web intents
OliverD: we should do that but it would be desirable to avoid slowing down solutions for UPnP
<Zakim> josh, you wanted to note that we're writing some WebIntents code right now for Location/Temperature demos
Josh_Soref: we're writing some WebIntents code right now for WebIntents code right now for Location/Temperature demos
gbillock: we have some demos coming up soon too.
richt: I can mint new URLs e.g. for temperatures, but need a solution for legacy devices.
Josh_Soref: there will be a set of common devices/services. For those we can expect a drop in proxy for them
... legacy devices probably have security problems, so proxies are actually a good thing
<richt> ACTION: richt to provide more use cases for Networked Service Discovery [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action21]
<trackbot> Created ACTION-528 - Provide more use cases. [on Richard Tibbett - due 2012-03-29].
dsr: not against richt's proposal, library developers could help to address abstraction layer, but we should in parallel work on enabling abstraction behind web intents
Claes: I can help with white list mechanism investigation
gbillock: I am investigating that too
<dsr> ACTION: Claes to work with greg and bryan on investigating white list/CORS for networked services [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action22]
<trackbot> Created ACTION-529 - Work with greg and bryan on investigating white list/CORS for networked services [on Claes Nilsson - due 2012-03-29].
darobin: if richt wants to publish, please dump it in hg or whatever
richt: yes, I want to publish it
fjh: There were some objections to the Sensor CfC, so we should review them, consider the issues and respond
<fjh> responses to cfcs
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Mar/0143.html
fjh: we got a lot of positive responses as well
... summarizes responses
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Mar/0149.html
<Zakim> fjh, you wanted to ask about sensors
darobin: we need to explain to wayne that web intents could return multiple sensors, I will email him how
<Zakim> josh, you wanted to note that GeoLoc + Network are two things that were handled independently and better than a generic system and to note that there was feedback from ArtB about
darobin: one person objecting, multiple people positive
Josh_Soref: no evidence that splitting things out is better (talking about splitting generic sensor spec into solutions for specific devices)
... we need to get back to jose to explain why he is mistaken on that point.
bryan: jose has a point in that they have implemented the sensor spec as is
... they (telefonica) are actively participating in a system level initiative, and we should listen to them in that perspective.
darobin: jose has said he is happy to drop discovery from sensor API
Josh_Soref: I have sent my reply to jose.
... he was quoting a section and ??? my reply ???
bryan: didn't you explain the privacy and security issues in detail?
Josh_Soref: I was probably too terse
darobin: I will follow up with more details.
<OliverD> ack
<Zakim> josh, you wanted to note that there was feedback from ArtB about lack of attendees from WebApps for the Intents discussions
Josh_Soref: I would like to ask the DAP chairs to politely get back to Art on lack of participating from web apps WG.
darobin: no. he just asked for a summary of the web intents discussion for the webapps WG list
... no only just for him
jhawkins: I will make sure he gets copied with the summary
... we break for lunch, one hour ...
dsr: We have a crumpled HTML5 t-shirt
... a beret
... and a w3c scarf
... at the previous demo, we also had a mug
... each item has an NFC tag hidden inside
... and we also have a checkout desk
... to give people a smoother experience in shopping
... the ability to check out quicker
... that's the basics
... but it's more for the services around it
... i have a phone
... let's go for the t-shirt
... because the previous demo was in Barcelona, it's all in EUR
[ Rings up t-shirt; chirp ]
[ 15EUR ]
dsr: we could get something else
... the beret
[ 12EUR ]
dsr: the basket total goes up [27EUR]
... you can check out
... and have the ability to buy or not
... i could be walking around the store with my phone hanging from my pocket
... there's the risk of someone taking my phone
... and buying stuff with it
... this demo was built in conjunction with
... WebInos
... Samsung
[ Demo falls over ]
dsr: you briefly saw a PIN entry dialog
... it wasn't authenticating to a wallet
... it was authenticating to a personal zone
... the dialog has an antiphishing feature
... it had a string and short graphic
... that you configure
... that was the demo
... but the value added services are what's really important
... why would people want to touch the items?
... You might want to find more information
... where were they produced?
... were they produced in an ethical way?
... how do you wash them?
... are there fibers for which you have allergies?
... for food products
... there's the fine print ingredient list
... and you could recognize allergens
... and a third party product
OliverD: in your demo
... how does it continue?
dsr: the pin authenticates to WebInos
... which then authorizes you to your wallet
... and this can decouple you from the payment system
... wallet providers have rules, like 200EUR/day
... value added services, provided by third parties
... either working with the store, or independently
... you could want an independent review of the product
... you have lots of questions
... even if you know the local language, the people who work in the store
... don't know the answers
... there are also services when you aren't in the store
... e.g. at the end of the month
... what have i bought for the month
... did i have alternatives
... were the items bad (nutritiously)
darobin: Questions?
OliverD: that was all using tag reading, i guess?
dsr: this demo was using the intent to load a web page
... one of the first things would be to verify the application was close to the tag
... NFC N-def specification allows a tag to have multiple records
... and each can specify information: a URI, + other stuff
... so you could have multiple things in parallel with the same tag
darobin: is there code you could show us?
dsr: the code behind this web demo was JS using cookies
... in this demo we had Node.js and a server
... you couple the browser to inject APIs
... either in a Sandbox context
... or you wrap a webview (a PhoneGAP) for a system context model
<darobin> http://www.w3.org/2009/dap/wiki/index.php?title=Near_field_communications_%28NFC%29
dsr: This may not be a complete list of the APIs
darobin: we don't have to do the entire NFC ecosystem
dsr: the first point is that
... we believe the DAP charter doesn't permit us to publish Drafts
darobin: we can put whatever we want in CVS
dsr: we need to decide on next steps for NFC
... I don't think Tran is on the line
[ DSR reads Use Cases ]
dsr: a lot of things deal with coupons
... in the US you get lots of coupons, e.g. in mailings and news papers
<richt> http://www.w3.org/2009/dap/wiki/Near_field_communications_(NFC)
<dsr> http://www.w3.org/2009/dap/wiki/Near_field_communications_(NFC)
http://www.w3.org/2009/dap/wiki/Near_field_communications_%28NFC%29#Bryan_Sullivan
bryan: use cases for Keys
... unlock the Door, unlock the minibar
... the second was NFC enabled exercise equipment
... you want to have your treadmill track your progress
... you put your phone on the treadmill
... when the workout is done, you touch your phone to your armband
... information is transferred
... it's mashed-up and you get a picture of your workout
... the third is a higher level of trust for e.g. foursquare
... if you use WiFi, you can cheat
... if you use NFC, your rewards based system can be more reliable
<Zakim> Josh_Soref, you wanted to talk about NFC as Intents
Josh_Soref: I hope we can hide some of these use cases behind intents
... such as using a barcode
... if it is just being used for an id for project, any input should be useable
... I think many problems fall into this category
dsr: These tags contain more than just id
OliverD: also in many cases we would not want to make it easy to supply bad information
... in a shop you would only want real ids to be supplied
Josh_Soref: for the payment case I guess it is a sealed environment that allows only one intent
... if I am just walking around then other inputs should work
dsr: currently stores use physical stickers
... so this is still an improvement
richt: for the intents stuff is app triggering part of it?
darobin: for the APIs I've seen so far you need the app already running
dsr: yes, for NFC not having the app running is essential
gbillock: for the way web intents is now, it uses a new context and will load a service if it is not running
... browser initiated intents are interesting
darobin: for intents you would want something like register protocol handler for registering global NFC handlers
Josh_Soref: if I walk around in an area with NFC and Bluetooth people can spam me locally
... with nearby tags and with Bluetooth and SMS
... we need to be aware of it and maybe not make it instant
<richt> +1 to darobin's suggestion on using rPH...or simply HTTP URL registration on certain triggers.
bryan: they would have to be very close for it to matter with NFC
<dsr> NFC range is typically within 3cm
bryan: if an app were to register to be woken for an event that's a user permission
<darobin> [I didn't suggest we would use rPH — simply that we need global registration. I'd hope the design is better than RPH :)]
richt: we use URLs to trigger apps, so we could just use those
dsr: a tag might have multiple fields so we need to mediate between the multiple ones that might be in range
darobin: Josh_Soref concern about interruption is more about UI design
... is not suitable for spec
<dsr> users may need some means to set their preferences for which intents take precedence
darobin: future steps? NFC is big, how much of it do we need?
dsr: a good question, and how much of it is good for dap?
... perhaps NFC and crypto can be left for other groups
... we can address a higher level API that fits well in our model
... this is a brainstorming session, I think we need more focused study
bryan: people in at&t doing this have asked for some usecases and what interest w3c has in this
richt: I think triggers is interesting
... reading the data from that trigger
... then maybe the write functionality could be split out?
OliverD: Sylvain has further expertise on this
... it would be a shame if the NFC payments were missed out
dsr: when it comes to payments, that could be out of scope
<richt> wrt writebacks, it's something we don't necessarily have a good UI story for yet.
dsr: w3c is looking at this at higher level
<richt> reading/obtaining data is easy. writebacks are more complicated to do as part of the user workflow.
<Zakim> Josh_Soref, you wanted to say that just because the user sometimes trusts the app to do something doesn't mean they always want to be interrupted
bryan: i heard earlier that
... an intent is fired by something outside the browser
... that intent would create a new window
... is the url that
... the app wanting to be woken up
jhawkins: we only have inline and window
... but we have a proposal to consider an existing disposition
... our concern was around interrupting existing sessions
... but that's a problem for the site/us
... we'll send a proposal
... to add an "existing" disposition
... which requires adding an Intent Event
... that was another reason for adding an Event
bryan: i also had another case
... for an app that wants to receive multiple Push Events
... if the same event comes in, it could be broadcast to multiple
jhawkins: so you'd use some local communication
richt: or you could specify a target when you register the intent?
http://www.w3.org/2009/dap/wiki/Near_field_communications_%28NFC%29#Dave_Raggett
dsr: mary visits sophie
[ she doesn't like WPS ]
dsr: so she uses an NFC tag to connect to a network
<richt> similar to the window.open target parameter.
jhawkins: maybe this has something to do with locality to the router?
... so tapping on the router gives you access to the guest network
dsr: your Access Point
... may be in an office
... or upstairs somewhere
Josh_Soref: or in a closet
dsr: but you may have NFC tags around the house
... with a static tag
... someone wrote the tag with a certain intent in mind
... when you do Peer-To-Peer
... touching one device to another
... one party has to switch the phone to a mode
darobin: you want to peer two phones together for a card exchange
... or a game
dsr: both phones act as controllers
... when you tap two phones together, something needs to emulate a tag
... which requires it switching to that mode
... or you can go to a peer-to-peer mode
darobin: OliverD's proposal,
... if you only do reading
... maybe we can use a broker over the network
dsr: the first use case was a read thing
OliverD: sophie had to do a tag write
dsr: the phone was put into another application
... opting into that mode
OliverD: running a native application?
... we were only talking about providing reading as an API
richt: if i wanted to do this from a web page
... do i need an interface?
... If we don't need a UI then we don't need a split
darobin: you need permission
dsr: it's like form upload
... i want to share my business card
<Zakim> Josh_Soref, you wanted to comment on dangerous writes
Josh_Soref: Sophie in this use case needs to be able to write to a tag
... for B2G and Tizen we only have web browsers
... Sophie needs this but may not be able to understand if the write is malicious
... I hope the user agent offers a way to preview the write in advance
... the spec should encourage this
... I think that's the key thing for informed consent
richt: I would say it is a reputation thing, a UI is not needed
Josh_Soref: I think it is key that the NFC write provider show the data that will be written
... so she can see if it is doing what it says
darobin: this is not something we need to solve now
... I think we should put this in the DAP charter and SLAPI
... we would need to recharter for this
... so it is a good time to add any other things we want
Josh_Soref: it doesn't matter too much if we have extra stuff in the charter
... we are not obligate to work on it
Wonsuk: We would like to add Bluetooth to the charter
<Jungkee> ACTION: Jungkee to gather use cases for Bluetooth [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action23]
<trackbot> Created ACTION-530 - Gather use cases for Bluetooth [on Jungkee Song - due 2012-03-29].
dsr: what about QR codes?
richt: we have a demo with getusermedia
<richt> QR reader in JS via getUserMedia: http://shinydemos.com/qr-code/
darobin: the advantage would be auto scanning
<dsr> ACTION: robin to draft DAP charter version 3 [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action24]
<trackbot> Created ACTION-531 - Draft DAP charter version 3 [on Robin Berjon - due 2012-03-29].
<dsr> ACTION: dsr to collect use cases for qrcodes in web context [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action25]
<trackbot> Created ACTION-532 - Collect use cases for qrcodes in web context [on Dave Raggett - due 2012-03-29].
<Jungkee> ACTION: Jungkee to gather use cases for Gallery API [recorded in http://www.w3.org/2012/03/20-dap-minutes.html#action26]
<trackbot> Created ACTION-533 - Gather use cases for Gallery API [on Jungkee Song - due 2012-03-29].
Wonsuk: we need to start gathering usecases for gallery APIs
darobin: I think we have some already?
Wonsuk: not in this pac
darobin: some is well suited, some needs lower level APIs
jhawkins: intents is only used for notification, it gives some way to use the device
... we are implementing an extension API for the gallery
... because we need it right now
darobin: perhaps you should join dap?
jhawkins: I am not opposed to that
darobin: anything else for rechartering
dsr: USB?
richt: we did look at it for getusermedia
... but that was a long time ago and has been deprecated from that
... we would need specific use cases to validate if this is useful
darobin: we don't need to decide the new charter right now
... but please send suggestions to the lists
... that concludes the NFC topic
... [ Thanks group ]
... I urge people who are interested in contacts, gallery etc to shape them on top of intents
... I would like to thank our hosts from Huawei for their excellent organization of this meeting
... [ Applause ]
[ Applause ]
<OliverD> trackbot, end meeting