Device APIs Working Group Teleconference

03 Nov 2011


See also: IRC log


Adrian_Bateman, Alex_Russell, Anders_Isberg, Anssi_Kostiainen, Ashok_Malhotra, Balaji_NV, Bryan_Sullivan, Cathy_Chan, Christophe_Eyrignoux, Cullen_Jennings, Daniel_Appelquist, David_Yushin_Kim(obs), Dominique_Hazael-Massieux, Ernesto_Jimenez, Frederick_Hirsch, Henry_Thomson, Ilkka_Oksanen, Ingmar_Kliche, Jari_Alvinen, Jean-Francois_Moy, Jean_Claude_Dufourd, Jim_Steele, Jonas_Sicking, Jonathan_Jeon, Jongyoul_Park, Jose_Cantera, Josh_Soref, Justin_Lebar, Kangchan_Lee, Kepeng_Li, Kihong_Kwon, Laszlo_Gombos, Linuz_S_Lee, Marco_Marengo, Marcos_Caceres, Mounir_Lamouri, Nick_Doty, Niklas_Widell, Noah_Mendelsohn, Peter_Linss, Philip_Gladstone, Rich_Tibbett, Robin_Berjon, Sakari_Poussa, Shunan_Fan, Soonbo_Han, Soonho_Lee, SungOk_You, Suresh_Chitturi, Travis_Leithead, jerome_giraud, mahalingam_mani, Virginie_Galindo, Olivier_Thereaux, Matt_Hammond, Youngsun_Ryu, Dave_Raggett, Clarke_Stevens, Kaz_Ashimura, Bob_Lund, aizu, Giuseppe_Pascale, Art_Barstow, Richard_Bardini, Jan_Lindquist, Tatsuya_Igarashi, Mark_Vickers, Rigo_Wenning
Frederick_Hirsch, Robin_Berjon
bryan, Josh_Soref, Travis_MSFT, karen, dom, olivier


<trackbot> Date: 03 November 2011

<dom> Chair: Frederick_Hirsch, Robin_Berjon

<scribe> Scribe: bryan, Josh_Soref, Travis_MSFT, karen, dom, olivier

[ fjh introduces the DAP wiki working mode, etc. ]

<fjh> http://www.w3.org/2009/dap/wiki/ApiCheckList

shunan: shunan fan, Huawei terminal company

spoussa: Sakari Poussa, Intel

Agenda review

Review of the minutes

RESOLUTION: Minutes from 26 October 2011 are approved, http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/att-0076/minutes-2011-10-26.html

Battery API

AnssiK: Battery API intro
... expect that folks have looked at the draft, it's pretty stable and nearing last call stage

jcantera: main concern is no way to specify event rate

<AnssiK> http://www.w3.org/mid/4EB03375.3070702@lamouri.fr

AnssiK: Jonas Sicking (Mozilla) wants to leave that up to the implementation

darobin: seems fine

jcantera: What does that mean to the app, does it need to filter the events?

AnssiK: The app can measure the delta

<jcantera> My concern is the event rate at which receive battery events

AnssiK: Firing events too often don't help as they may not be true changes
... Developers will need to handle various firing speeds

bryan: Don't we have the ability to threshold?

AnssiK: no

<Cathy> http://dev.w3.org/2009/dap/system-info/battery-status.html

bryan: Dropping threshold events is an issue

AnssiK: This was based upon implementer feedback (Mozilla)

dom: The original spec was 1% change events... if we have platforms that don't send events consistently that won't be helpful to developers
... http://lists.w3.org/Archives/Public/public-device-status/

Travis_MSFT: Firing events too often could be counter-productive to saving battery...

bryan: I will join the task force and review the comments on the list, to see how we can restore the threshold events if possible

lgombos: What about the use case on scaling back work when the battery is getting low?

AnssiK: It's in the use cases in the spec

lgombos: We need to consider both browser implementer concerns and web page author concerns

jcantera: The monitoring of the battery will impact the battery, if it depends upon handling continual events

AnssiK: We all agree that we don't want to impact the battery by the use of the API
... thresholds were not hard coded as in the future we don't know how they might apply or not

spoussa: The time units in the specs might be difficult to get in some platforms. That is, it might be very hard to get time value.

AnssiK: The spec is designed to use defaults for charging time

spoussa: It's hard to estimate charging/discharging time on different platforms
... the example in the spec won't work with The defaults

darobin: We got feedback that complex examples are helpful

ingmar: How is app initialization done?

darobin: mounir has been working on the battery status in Mozilla

AnssiK: One concern raised about the semantic events being dropped
... If the web code gets too many events as a result
... Our consensus was that would not be an issue if implemented correctly

mounir: We don't have the critical, etc., info from the battery
... It would be the same if the web page measured the level against some expected value

dom: Another approach is to set a delta threshold

mounir: Sending a lot of events does not seem to be bad

<AnssiK> I'll rework the example to check also against level if dischargingTime is not available

mounir: About too many events, an email was sent to the list:
... http://lists.w3.org/Archives/Public/public-device-status/2011Nov/0000.html

darobin: If the underlying system provides too many events, the user agent would be expected to block the events

dom: We may be missing a valuable thing for implementations, as the high/low/critical values may be useful to the implementation as a way to optimize its battery monitoring also

darobin: With 1% thresholds (implementation approach) we are talking 80 events

dom: Note that optional threshold parameter would have value and low cost, avoid issues that developer might not recognize
... if the developer does not know the battery level before doing resource-intensive DOM actions, it can impact the battery even more

<dom> (note that I wasn't talking about "high/low/critical" events, but having a parameter to define the threshold (set for dischargingTime, or level) from which to send the events)

AnssiK: on the list, it was stated that we don't know how the battery backends behave, so it's good to leave it to the implementation

mounir: If we have native extension listening to battery events, the platform is also optimizing the rate of events

[ Conversation to confirm we're switching from Battery to Vibration to help jlebar ]

[ Conclusion: Vibration @10:45am Pacific ]

spoussa: Additional comment to adding the level... there are backends that are already optimizable

AnssiK: The platform should already optimize it without webapp help

fjh: Sounds like this is a potentially useful optimization

Josh_Soref: The system can determine when to send events based upon whether the apps need them - when do they care

darobin: Wakeup is important

Josh_Soref: Preventing the need to wake up just to handle the events, needs a different approach

dom: An optional threshold setting would allow the host to optimize events

richt: The platform would still need to listen to the underlying events
... If those optimizations were wide-spread, it would be fine but it depends upon that

dom: In many cases being able to request less events would be an optimization

richt: The design of the API to include a sync 'level' attribute prevents threshold really bringing any significant optimizations to imps

AnssiK: We still have the sync interface which allows the app to get fewer events
... the app can poll the sync interface

ernesto_jimenez: We could have seven apps polling, want to avoid drain from executing JavaScript

darobin: Even if the underlying interface needs to poll the platform continually for the sync API, it does not need to deliver the events to JavaScript

jcdufourd: Could use the constructor approach to prevent the sync API from being used when not needed
... How about a field for the author to indicate whether he will use the sync part?

richt: The current API was not designed for optimization
... I'm not convinced by adding threshold optimizations based on the current design

darobin: We need to have a proposal for the options and this will be the last major change so we can move on to other things

<dom> ACTION: Sakari to draft a proposal for a threshold parameter for Battery events [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action01]

<trackbot> Created ACTION-459 - Draft a proposal for a threshold parameter for Battery events [on Sakari Poussa - due 2011-11-10].

Vibration API

[ darobin opens the floor to jokes ]

darobin: jlebar, welcome back, thanks for joining us
... Two weeks ago, AnssiK took what Mozilla implemented and drafted a specification out of it

AnssiK: Mozilla has been working on an implementation known as WebVibrator


AnssiK: I took the liberty of naming it Vibration
... I'd like to hear your opinion of what I've written

jlebar: thanks.

AnssiK: The API is simple, it lets you ask the device to vibrate for a certain period of time
... it doesn't support intensity, which was proposed by Huawei
... the main use cases are games
... and it's limited to the active web content/task

darobin: I'd like to make sure everyone agrees that this is very simple for a version 1
... if there's interest in a more complex version, we can do a vibrator 2
... we have a normative dependency to page visibility
... I think that's actually in LC

AnssiK: I'd like to reuse much of it
... if page visibility is progressing on REC, then we can rely on it
... I think Mozilla is depending on mozHidden
... we public the FPWD after we get confirmation from jlebar to confirm it's ok
... and then we can bike shed about naming

<Zakim> dsr, you wanted to request a repeat count as an optional parameter as per Android's vibrator API

dsr: I've been doing an implementation for Android
... and there's a need for a repeat count for a pattern

AnssiK: What's the UC?

dsr: It's to avoid repeating yourself
... Wouldn't it be easier to do it in the API?

darobin: I think on iOS you can only just vibrate

ernesto_jimenez: At least the PhoneGap iOS only vibrates

AnssiK: I'm not opposed, I just need UCs

jlebar: I agree: I'm in favor of a compact API surface.

jcantera: What you're suggesting wouldn't work
... dsr is suggesting vibration slots

richt: I'll mention my point now while it's relevant: I'd prefer a vibrateend event, so I can perform a JavaScript loop of the vibrate behavior as many times as I like (rather than specifying an optional repeat parameter)
... and repeating the slots as many times as you want
... basically the Array

AnssiK: My point is that it's a convenience

bryan: I don't see the repeat count as more than an optimization, a convenience
... JavaScript has a way to do stuff natively to Arrays

richt: ... I could also then trigger some action on vibration end.

darobin: jcantera is talking about vibration patterns

bryan: It's easy to create a pattern that has a certain length and repeat it at will until an event causes the app to cancel it

darobin: If you want to repeat it, you'd need to when it's going to end
... If you want to start it again

<Zakim> bryan, you wanted to note the API as defined looks to have the essential features, but I'm not sure about the disabling when in background

bryan: To me, a repeat option is an optimization
... it's a convenience
... my pattern itself can repeat

AnssiK: I don't see it as a big issue

bryan: The API as defined looks to have the essential features, but I'm not sure about the disabling when in background
... I think there are use cases when my page is in the background
... and it wants to notify

AnssiK: Out Of Scope
... that should be covered by the Notification API

<dsr> Android's vibrate API has a method that takes a pattern just as in the current draft spec, and a further parameter that is a repeat count. This is a convenience for developers.

AnssiK: It could be by Heating Up
... At least some devices do that

[ Laughter ]

darobin: WebNotification
... If you have a tab/page in the background
... you use WebNotification, and it will use the user's preferred way of being notified
... it might heat up in your pocket,
... or it might vibrate, or make sound, or show something on screen

bryan: So notification API gives me a way to vibrate in the background?

Josh_Soref: The notification API lets you trigger a notice, if the user chooses that it be a vibration, then you're triggering a vibration

[ Time Check ]

bryan: I don't think my UC benefits from WebNotification
... my web app wants to control how it interacts with the user

darobin: if you have a UC not covered by WebNotification or Vibration, then please send feedback to the list
... I wanted to ask jlebar (on the call)
... in terms of functionality, are you happy with what you have in the API?
... or are you looking to add things?

jlebar: This isn't a notification API
... The ability to turn vibration on
... and turn it on with a given pattern is all we need

AnssiK: What about intensity?

jlebar: I do think it's interesting
... but I don't know how we do that
... I don't know enough about devices
... to speak to that
... we'd have to survey devices

AnssiK: Makes sense to me

jcantera: On Android, you don't have a way to control intensity by default
... but with a given device, you may be able to use Immersion to control it
... maybe we can provide optional parameters to do it
... intensity, style, whatever
... provide some extensibility for it

AnssiK: I suggest jcantera send a proposal to the list
... it would be helpful for someone to survey the native APIs

jcantera: I think the API can be opened to such a feature

dom: This could be a v2 feature

AnssiK: We need to be very careful about scope
... We have lots of haptic feedback mechanisms out there

jcantera: Having an optional parameter in the method

dom: Then you need to define how that works

darobin: You need to define how things are interpreted, ignored, etc.

fjh: dsr was asking about a repeat parameter
... usability for authors is important
... even if it's just syntactic sugar
... I think we can do a FPWD w/o things being perfect
... We can publish regardless

darobin: We can say that the implementation just multiplies the array

<Zakim> Josh_Soref, you wanted to talk about different haptics and constraints

Josh_Soref: At Nokia we had to look at haptics and we had to worry about buffers
... bandwidth of buffer might be another reason for repeat count

sicking: While repeat pattern makes things easier
... it does mean an extra parameter that we have to care about
... it makes it a bit harder for extending later
... I would like to see a solution for intensity
... is intensity support in devices common?
... for advanced gaming systems you have a lot of that

darobin: For AGS, you have multiple devices
... clearly a v2 feature

<Zakim> adrianba, you wanted to talk about stop

adrianba: Given that you can dispatch this pattern
... What if you want to stop it?

darobin: I think if you call vibrate, it interrupts the previous pattern

dom: (or vibrate(-1) ?)
... calling vibrate(null) will stop
... we could add a close method
... but we're moving to navigator
... so we need to be careful about not canceling navigator

Kepeng: Understanding of the Vibration API
... is to invoke the device to vibrate
... do we have a way to ask if the device is vibrating?

AnssiK: We don't support that
... I proposed events for starts/stops
... but we didn't have a UC for it

fjh: we need use cases if We need this

darobin: If you have a UC for it, please send it to the list

Kepeng: ok

richt: I like Kepeng 's idea
... I'd like to know when my vibration ends
... so I can know I can do my next action
... but there's a need for a timeout
... and I get some latency/jag

darobin: Agree, send UC to list
... Objections to a FPWD?

[ none ]

<fjh> ACTION: fjh to send cfc for FPWD for vibration [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action02]

<trackbot> Created ACTION-460 - Send cfc for FPWD for vibration [on Frederick Hirsch - due 2011-11-10].

darobin: Implementers, please send us feedback
... now would be nice
... jlebar, if you've had the time, it would be good to get feedback

jlebar: Offhand it looks mostly good

darobin: Any other implementers looking at it?

richt: I'd like to see a path from a v1 to a v2 in the spec

bryan: On thinking about the possible use cases for background vibration, I think there are perhaps some corner use cases but no central ones, and the possible unwanted side-effects (e.g. conflicts between multiple background pages) would need to be considered - so for now I don't plan to submit any use cases for that
... like supporting multiple targets

darobin: Thanks jlebar for joining us

<jlebar> Bye, everyone. I'll send mail to the list soon.

Media Capture

darobin: Media Capture, there are two drafts
... the one thing we're missing for Media Capture
... is for someone to tell us which attributes they want
... right now, it's bikeshedding
... first implementer to suggest hints, it'll probably be adopted
... [this is <input> style]
... the second case is programmatic input
... the proposal is to have a joint list between WebRTC and DAP
... concerns of a joint work with WebRTC?

dom: Until recently, DAP had adopted the Media Capture API
... getUserMedia()
... and there was something similar in WebRTC
... the proposal was to make this a joint proposal, to replace the existing work

jcantera: Does getUserMedia() give a preview?
... but you need a way to capture

<dom> [the existing DAP Media Capture API http://dev.w3.org/2009/dap/camera/Overview-API.html ]

darobin: No specific concerns to the Task Force, I'll set it up

Travis_MSFT: Travis (Microsoft), I joined this group recently
... I've been in WebApps since 2006
... I've been working on Web pages/ the IE team, Trident, 7, 8, 9, 10
... My primary interest in the short term is Media Capture
... I recognize there's a lot of prior history here
... Putting that behind me
... I'm a proponent for the TF
... It's a way to get our point of view from the Local MC perspective
... and trying to merge that with the remote point of view from WebRTC
... in Feb of this year, the Speech team at MS sent feedback

<AnssiK> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0015.html

Travis_MSFT: They expressed concern of enumerating device characteristics of the Camera
... Those things are conspicuously absent from the WebRTC proposal
... With getUserMedia(), we now have a way to put user consent
... which was lacking before

<bryan> privacy concerns due to the use of this info for fingerprinting or otherwise?

Travis_MSFT: We can hide things behind that layer
... direct access to the Stream rather than brokering

darobin: Quite a lot of agreement on that

Travis_MSFT: At the same time, the recent Streams proposal [http://html5labs.interoperabilitybridges.com/streamsapi/] is another potential vehicle for previewing a capture device--it's lightweight and works for the basic scenario of hooking a capture device up to a VIDEO tag. We should think about the benefit that a Stream might provide both in terms of recordings as well as preview. Of course, the use
... of MediaStream will certainly be necessary if the local capture scenario transitions into an RTC scenario.

<bryan> http://html5labs.interoperabilitybridges.com/streamsapi/

Travis_MSFT: Consuming Streams instead of Fixed Blobs could be useful
... either for getting or previewing

[ a couple of people have looked at the Streams proposal ]

adrianba: The WebApps group agreed to adopt it as a deliverable

AnssiK: Is WebRTC discussing using it?

[ Maybe ]

Travis_MSFT: The other thing from the speech people
... was the concept of endpointing
... when I open my phone
... and perform a search
... when I click here [point on screen],
... it's listening to me, and it knows when I stop talking.
... It can make value judgments about when to capture data
... very useful for speech recognition
... I don't have a solution, but we have an interest.
... If we consider MediaStream as the starting point
... there are scenario conflicts that are interesting that I'd like to bring up

<dom> WebRTC Editors draft

Travis_MSFT: a MediaStream represents a continuous source of Video and/or Audio
... there's a series of tracks
... (that's in flux)

<dom> WebRTC Media Stream

Travis_MSFT: and it's possible to turn them on or off
... I couldn't come up with a UC for turning off Audio when I'm just recording Audio
... I'd just stop recording Audio in that case
... it just seems strange

<bryan> How does the stream API proposal relate to what is referenced from the File API as the "Stream API" -- http://www.WhatWG.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html

Travis_MSFT: As jcantera mentioned,
... devices tend to have an optional mode they switch to take a picture
... the WebRTC proposal is missing a way to switch into that mode

darobin: and it prevents a way to get good pictures
... because the time cost results in downgrading your camera by 5 years

dom: and it has privacy concerns

Travis_MSFT: Our local proposal needs to have a way to "take a picture", switching to higher resolution mode for video camera.
... There's a concept of whether a stream is Mutable/immutable
... as to whether tracks can be dynamically added/removed from a Stream
... which this group should provide feedback.
... When you start recording from the camera, you merge audio+video
... and having to split that up requires a lot more work.
... Three more things:
... The spec says you Record
... taking things from the Stream and start to save it to memory/disk.
... The API today provides the ability to create overlapped recordings.
... I don't know if that's intentional, or just fallout
... I'm not sure it makes a lot of sense
... for end users to create multiple recordings, and start and stop them.
... The API might benefit from refactoring

darobin: I don't know of a professional camera that allows that

Travis_MSFT: I attended WebRTC as an observer on Tuesday.
... Everyone was in agreement that having a way to stop a recording was crucial
... you start a recording, and get a blob back
... and it just keeps going, for hours....
... There's a lot of small capabilities we might add: volume control
... image stabilization, video effects, brightness, saturation
... things you might see in camera settings.
... I have a design philosophy, build something for the common scenarios, and make them easy
... but for other things, push them out to v2
... but keep them in mind
... I'm suggesting to consider more, and then make a smart selection of a subset
... and push the others out of scope into v2

darobin: We might support 0 in the first version

Travis_MSFT: Also viable

darobin: It seems orthogonal to capturing stuff

<Zakim> fjh, you wanted to mention consent item

fjh: One question and one comment.
... On privacy:
... I looked at the EU opinion on privacy
... and have an email concerning consent on the mailing list
... consent needs to be informed.
... I'm not sure information about what's going to happen
... is presented.
... The other, is privacy implications to metadata.
... I'm not sure you have an opinion on it.
... I think you're saying none of it provides any

darobin: In terms of things,
... the API won't expose metadata,
... but the device might embed EXIF
... which might disclose your geolocation

richt: Our objectives...
... specifically local media capture.
... You've talked about local UCs
... not excessively redoing.
... WebRTC has stuff:
... there is the ability to copy to canvas,
... you can detect silence w/ audio APIs.
... I want to recapture those UCs because they got lost in WebRTC

<fjh> privacy and consent, correct link -> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/att-0091/dap-privacy-wp187.pdf

<Josh_Soref> ACTION: Travis to submit UCs [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action03]

<trackbot> Created ACTION-461 - Submit UCs [on Travis Leithead - due 2011-11-10].


<trackbot> ACTION-461 -- Travis Leithead to submit UCs -- due 2011-11-10 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/461

<Josh_Soref> ACTION: richt to submit UCs [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action04]

<trackbot> Created ACTION-462 - Submit UCs [on Richard Tibbett - due 2011-11-10].

bryan: The Stream API was discussed in WebApps in the context of File API.
... There's a reference coming from WhatWG
... the goal is to ensure
... we apply them consistently in as many places as possible:
... writing, reading, pushing, etc.
... Is that a goal?

Travis_MSFT: I share richt 's view that we should reuse things from the platform

<fjh> thanks to Travis_MSFT for comments and work on this

darobin: I think we can make progress!
... you didn't talk about html Media Capture

Travis_MSFT: it's come up internally
... in terms of UCs
... personally
... there is sufficient room on the web for declarative (not requiring scripts) and imperative (programmatic)
... and I don't think they have to be mutually exclusive

darobin: One thing that would be useful is
... finalizing that hint
... again, first suggestion will probably ship

sicking: Our current approach
... first step is deciding on a UI
... for declarative
... once we get our UX people
... we'll figure out attributes in order to support those UCs.
... A constraint: if we need a dramatically different page UI,
... then we'll need a way to do things which lets pages opt in
... because that would otherwise break page layout

darobin: Any early drafts?

sicking: Not really

Travis_MSFT: I thought through this a bit
... when you want to capture only audio
... it seems entirely different from video
... and it seems fairly hard w/o a hint

richt: Android stock browser has a declarative approach
... and things get passed off to the native control
... which controls resolution, quality, etc.
... a user choice

darobin: Which is good, right?

[ Yes ]

richt: I agree, we do a design, and see if there are any hints
... sicking is right, we get the UI right, and then decide on parameters

darobin: we won't be working on HTML MC before We get UI feedback

<Zakim> dom, you wanted to talk about next steps w.r.t. WebRTC TF

dom: We talked about getUserMedia()
... We're interested in a Joint TF
... that has logistic consequences
... a new TF to join, a new mailing list
... WebRTC hasn't agree to it yet
... darobin and I were at WebRTC where it was discussed, but not approved

<Josh_Soref> ACTION: darobin to draft a joint TF proposal with WebRTC [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action05]

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

dom: one thing we'll need to do is provide resources, such as an editor

adrianba: we found Travis_MSFT

fjh: what's next?

<Josh_Soref> ACTION: berjon to draft a joint TF proposal with WebRTC [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action06]

<trackbot> Created ACTION-463 - Draft a joint TF proposal with WebRTC [on Robin Berjon - due 2011-11-10].

dom: We'll need the right API to get-web-user-media nicely for WebRTC to build on

darobin: since they're coming from the network point of view
... they don't care much
... but we'll need to provide something, otherwise our UC might be painful

Travis_MSFT: I have thoughts

richt: they're also on a fast schedule

darobin: I think everyone's happy about that

dom: Travis_MSFT, you'll be on calls?

fjh: our calls are 10a Eastern

dom: but TF might be different

fjh: back at 1pm
... talking about sensors
... we'll skip network info

darobin: we'll move network info to tomorrow morning?
... in the second session

[ Lunch ]

[Round of introductions]

Sensor API

<dom> Sensors API editors draft

jcantera: I will be presenting the Sensors API.
... current draft is 2 months old.
... we've been creating a prototype to demonstrate the feasibility of the current specification

<bryan> The link, http://dev.w3.org/2009/dap/sensors.html -- for "Latest editor's draft:" is incorrect

jcantera: I will be presenting the results of the prototype. Later I will present the conclusions that represent the current issues.

darobin: you have demos?

jcantera: yes. Will show them
... First, establish a connection to a sensor.
... Then you start watching the sensor (having provided the options, such as interval)
... Then you get info via an event handler.
... There's also a way to determine what sensors are available.
... list the sensors.
... The prototype is on Android. Using SDK and NDK to get access to the sensors
... NDK to be able to interact with the sensors in C++.

<fjh> http://developer.android.com/sdk/ndk/index.html

jcantera: They also use a web browser component.
... From the web view, a JavaScript->Java conversion takes place, then a Java->C++ to get to the sensors themselves.
... Sensor metadata is partially implemented.
... [presenting the demo]

<fjh> logical sensors provide a view on other real sensors, e.g. linearAcceleration ignores gravity

<dom> [Sensor.name and Sensor.vendor create fingerprint issues]

jcantera: units appear to be different even among different Android devices.
... not sure if they are using different units.

[ applause! ]

jcantera: any requests or anything else you'd like to see?

richt: This appears to look like the System Information API?

dom: There is some overlap, though it's not exactly the same. I share some of your concerns.
... one of the concerns with system API is using a vocabulary-based approach and an API that relies on that vocabulary.

richt: system API had too many features...
... but its design paradigms are valid.
... With the sensors API, some of the richness is now lost in this version

Marcos: I have a similar question: If I have multiple sensors (like in my car and out), how do I determine that.
... How much feedback are you looking for?

darobin: all feedback.

Marcos: can you just say "new Sensor" and then get the options?
... I'm a little worried that this is tied too much to mobile devices...
... Can we make this more of a general use API. Specifically looking at Magnetic fields interface...

<richt> this definitely relates to the "web of things" concept.

Marcos: Seems to duplicate what other WG's are doing (orientation)

<richt> i.e. a sensor is a thing (a service).

jcantera: One of the open issues is to rename the interfaces to avoid confusion.

Marcos: Can you capture all 100,000 sensor types? What is the scope of this specification?

jcantera: We've been discussing this. Like discovery of sensors that are not on the local device

Marcos: Like sensors composed of other sensors?

dom: Every year a new device comes to market with a new sensor

jcantera: If there is some kind of logical sensor--an aggregate of the physical sensors, you could deal with it that way.
... the API is flexible enough to be extensible.

<Zakim> Josh_Soref, you wanted to ask what will you do with the data on average?

fjh: I believe Marcos is saying it should be a generic API that can handle future sensors.

Josh_Soref: What do you expect to be able to do with the sensors?
... Discovery of the sensors independently may not have sufficient value and could lead to privacy concerns
... Also, no two devices have the same level of accuracy. On the web it's nice to have an API that's slightly less capable, but can be used on the Web.
... When the high-precision device is available in a limited set of devices, then it's not as useful on the web.
... Example, Geolocation has a precision. Noted, that precision might not be to the inch. Geolocation specification has a generic location.

<dom> [sensors.list() would at the very least minimization, by which you could get a list of sensors per type]

Josh_Soref: A game might be able to say it supports only specific devices w/sensors, but that's exclusionary rather than inclusive on the Web.

nvbalaji: having a generic sensors API--we should be careful.
... privacy requirements are different.
... if trying to do a generic service, we should be careful about privacy.
... where everything can be discovered and used in the same way.

Marcos: that's orthogonal to the privacy problem.

fjh: getting a little confused.
... Is this an attempt to be a generic sensor interface that can handle many things; I also think Marcos was suggesting this.

<nvbalaji> Privacy sensor may have different privacy requirement compared to Location sensor

fjh: but if this is so generic we might not be able to handle the plethora of devices.
... didn't really understand Josh_Soref's comments
... I understand that precision matters.

Josh_Soref: the raw orientation scares me.
... I don't see any use cases for that other than having-or-not that sensor.

Marcos: vendor attribute -- I have concerns about that as well.,

<dom> a big +1 on not duplicating deviceorientation

<Josh_Soref> +1

<dom> and another +1 re: exposing vendor

Marcos: Vendor identification should not be exposed because it risks that an app can be built around just that vendor.

<fjh> vendor issue for fingerprinting

jcantera: It doesn't invalidate the API

Marcos: Just because the data is there, doesn't mean it must be exposed.

Josh_Soref: isn't this already resolved?

fjh: Yes, resolved.

Marcos: Android has this exposed. I wonder why they added it. What was there use case?

<richt> lgombos: do we have vendor interest in implementing this?

<dom> [or maybe they added it because they could; that's what it sounds like we would be doing as well]

bryan: Be careful to avoid not standardizing a device just because it might be disenfranchised.
... For use cases, in a lot of cases, you want to personalize your experience (see augmented reality, games, etc.)
... yes, don't dup functionality exposed elsewhere.
... Web platform will suffer if this data is exposed elsewhere (but not on the web).

AlexR: Alex Russell (Google)
... Two contentions points:
... gradients of potential specificity is related to the data type itself.
... In input type=file we don't ask for the type, we let the user determine.
... Rather than a specific API, this seems more like markup
... Should this be an API? With Web Intents, there may be a way for service description/discovery that is parallel to other systems in the platform.

darobin: Interacting with the data-type is useful. Not sure about translating into markup.

AlexR: Markup provides a way to describe default user-interaction in UA's that don't support it.

<richt> agree that this could be reduced to the problem of providing data in Web Intents / Discovery

AlexR: since markup is not specific by default, it's a good starting point.

Marcos: agree generally.
... We want to get at the data directly and poll it.
... We have a permission model, but often we want to get beyond that to the data and not have the permission model get in the way.

AlexR: We have an eventing model -- it's tuned for use on the markup/DOM

darobin: One issue with markup is that fallback with input type=location is a text field.
... not a great way of entering data.

Josh_Soref: But not too bad. I'd rather paste into one text field.

AlexR: Form serialization algorithm determines how to serialize the data without causing developers to do extra work.

darobin: If you get arbitrary values instead of what you expect, it's not useful to the developer.

AlexR: Having a fallback doesn't mean that we hang everything off a single value property.

darobin: Yes, but you end up doing just as much work by the developer.

JimS: Jim Steel (sensor platforms)
... Want to give my vendor perspective.
... Sensors are tuned per the device.

<fjh> AlexR notes JavaScript on the wire is slow and punitive

JimS: Developer would like to know what the sensors confidence degree is.

darobin: Speaking to the Intents point...
... Will happen in a joint TF between us and Web Apps.
... jcantera, provided a great demo earlier.
... before moving on with "should we do this with Intents", I'd like to see an example case.
... Can you provide such an example?

<fjh> Much thanks to jcantera, for demo and work on this

<Travis_MSFT> ACTION: berjon to follow up with Alex Russell on getting an example of sensors on Intents. [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action07]

<trackbot> Created ACTION-464 - Follow up with Alex Russell on getting an example of sensors on Intents. [on Robin Berjon - due 2011-11-10].

jcantera: If web developers don't get the data, they'll turn to other sources.

<fjh> ISSUE: is low level data necessary for all sensor APIs, which ones have use cases and which not

<trackbot> Created ISSUE-122 - Is low level data necessary for all sensor APIs, which ones have use cases and which not ; please complete additional details at http://www.w3.org/2009/dap/track/issues/122/edit .

darobin: Intents does sound like a potential contender

<AnssiK> there's a typo in the Sensor API example, s/session/sensorConnection/ should fix it

Josh_Soref: Orientation was the one I noted that was so specific.

<Travis_MSFT> ACTION: jcantera to present use cases for the Sensors API [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action08]

<trackbot> Created ACTION-465 - Present use cases for the Sensors API [on jcantera, Manuel Cantera Fonseca - due 2011-11-10].

<Anders> Here is the link to Web Intents demo that Claes posted to the mailing list http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0009.html

<fjh> ACTION-465: specifically use cases for need for raw lower level data, e.g. orientation

<trackbot> ACTION-465 Present use cases for the Sensors API notes added

Josh_Soref: If there's a requirement to get precision to 10 digits, and you write code that gets to 10 of the 10 digits, but my device only supports 6 digits, then my code might break.

darobin: sounds like folks that design websites to 1280 width and expecting it to work...

Josh_Soref: I can still use a device as long as it doesn't refuse to work without the same precision as specified.

darobin: There's certainly a "don't be stupid" mentality that should be noted.
... Great job on the demo. This is a process that moves things forward.
... There are lots of folks in the room that work on stuff like a Web OS... Would love their perspective.

sicking: I like the approach of having a low-level API. This proposal is good. I don't know enough about the other work, though it sounds like there's a lot of overlap.
... I see good use cases for proximity sensors.
... Ambient light sensors--not sure. Might want the OS to handle that.

<Josh_Soref> +1

darobin: Might be done with a media query instead.

sicking: sounds like a good idea.
... I like the idea of exposing this as an element, but don't know what it would look like.
... proximity is a simple one that should just be exposed. Might just have two values -- proximate or not.
... current spec is way more than what is likely needed.
... interesting to experiment with this.

<dom> [Android is supposed to give you 0 or 1 for proximity; yet my Nexus reports "9" - go figure]

sicking: The UA might have trouble providing a notification for the use of such sensors.

<fjh> privacy is certainly a concern with raw generic sensor API

dom: One point is that a security model is necessary depending on the type of sensor.
... proximity... may not need security.
... but some others may.
... back to the question of whether a generic API is useful, or if specific APIs are needed.

Josh_Soref: (light probably does need a security model)
... there are things one can do w/ ambient
... if there's a light flashing outside, it could be deciphered

sicking: I like the idea of putting this in an extension and seeing what happens.

dsr: Are native apps using this kind of sensor data and if so what for? If there are some compelling use cases there we should take a look.

npdoty: generic sensor API would likely affect fingerprinting in addition to revealing potentially sensitive sensor data

richt: Sensors are kind of like services. How to connect to the sensor, get data from it... Security lies in the process of establishing a connection.

bryan, the ambient sensors and proximity are unlikely to have any privacy considerations as the information will be so random and constantly changing, that it would have very little value for fingerprinting

npdoty: bryan, I mean that just knowing which combination of sensors is available on the device will enable fingerprinting

darobin: Anyone else have an opinion?

richt: So I wonder if we can reduce the security problem to one of 'connecting' to sensors and reducing the transmission problem to one of transmitting some data: json or otherwise.
... which is why the Web Intents / Discovery angle is interesting here.

npdoty: and native apps (like Color) have used otherwise 'random' ambient sensor values to determine whether one device is near another, which has substantial privacy concerns

bryan: acceleration and orientation are similar... I see very little privacy concern with these as they will also be largely random across a number of users

dom: There is interest in implementations, so that's positive progress.

<dom> Accelerometer Sensor Sample from Microsoft Windows 8 Metro app

<dom> Proximity Sample from MS Windows 8 Metro

bryan: w.r.t. privacy

<bryan> the probability that one user has an app that can access another user's sensors without opt-in

bryan: I can't see how you can get something which is so random across users
... would someone trick someone into installing an app?
... we need to focus on static attributes

dom: sensors are privacy risks much beyond fingerprinting
... gps are sensors
... you can payload a computer sitting next to it
... some sensors like proximity, you have less than others

Travis_MSFT: Link to information about Windows 8 Sensors access through JavaScript (API): http://msdn.microsoft.com/en-us/library/windows/apps/windows.devices.sensors(v=VS.85).aspx

bryan: Still don't see significant privacy concerns

dom: key point is that depending on the sensor, there's different privacy concerns.

<Zakim> fjh, you wanted to ask about agenda and webintents

fjh: I agree with dom, but I think this is a bit premature given where we are. Some things may yet change.
... Thanks jcantera, for all your work in the demo.

<npdoty> I could go off the q and move fingerprinting discussion to email if chairs would prefer

npdoty: working for team on privacy
... Can't address the concern about not caring about privacy :)
... my point on privacy: For a generic API, just "knowing" what is available is a risk
... Plugins and Fonts have this problem, and introducing a new generic API for sensors will have a privacy concerns.

sicking: when we implemented Joystick
... we don't expose Joystick to the web page

<bryan> we have to be able to adapt to the device capabilities by knowing them, unless we are to require only one set of device capabilities on all devices

sicking: until the user uses the Joystick

<darobin> https://wiki.mozilla.org/JoystickAPI

bryan: sicking do you think we shouldn't support feature detection?

sicking: didn't say that.

<fjh> example from sicking is that you can know there is joystick but don't now brand and other details

sicking: We're adding joysticks, but are trying to do so without exposing a fingerprinting risk.

dom: two things: detecting the joysticks, and its characteristics

sicking: It does put some limitations on the web developers.
... could be done slightly better. But we should do things that are good.

bryan: I'd like to know whether the device supports front/back camera

sicking: the UA exposes that to the User, but the page doesn't know what the buttons are.
... buttons being the front/back

darobin: wrapping up on sensors discussion?

fjh: jcantera, did you have a follow-up action?
... you took an action to get details on use cases for why we need a lower-level API

jcantera: There's a slightly old draft. We have new feedback from implementations, etc., and need to update the draft.
... including info from the mailing list.
... those are the next steps.

darobin: such as doing a plugin for experimentation.
... we also have the feedback from Web Intents.
... lots of next steps :)

dom: schedule?

<fjh> ACTION: jcantera to update Sensor's API based on feedback, implementation, etc. [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action09]

<trackbot> Created ACTION-466 - Update Sensor's API based on feedback, implementation etc [on Jose Manuel Cantera Fonseca - due 2011-11-10].

darobin: I don't think we've looked deeply enough at Web Intents.

richt: If we use Intents, do we have to define the interface?

darobin: yes you still need to know how to get the data.

richt: Intents allow us to make sensors more decentralized. You don't need to define all the formats, etc. up front.

fjh: We wanted implementer feedback...so, what's the timeframe for this?

sicking: I don't have a specific time. Development can take awhile.
... I think proximity and ambient light should be exposed.
... exposed via an API tailored to the experience.

<fjh> ACTION: dom to make proposal for proximity and ambient [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action10]

<trackbot> Created ACTION-467 - make proposal for proximity and ambient [on Dominique Hazaël-Massieux - due 2011-11-10].

<dom> (I think proximity would be better served by a simple "proximity" event)

dsr: For ambient light, seems like a styling feature. Could be defined by CSS in media queries.

<fjh> ACTION-467: ambient light

<trackbot> ACTION-467 make proposal for proximity and ambient notes added

Marcos: Controls other actuators in the OS (dim the display, keyboard backlight)

dom: you could consider that keyboard backlight would be controlled by CSS in that case.

darobin: Thanks again jcantera.

<fjh> Again thanks jcantera

jcantera: Referring to discovery, the list sensors method opens the door to discovery if the implementation decides to.
... Regarding extensibility, I feel that it is extensible.

dom: many of these things are still being explored.

Messaging API

darobin: Using SMS, etc., to send messages. It's been significantly redesigned many times over.
... Meh.

<dom> "meh-tality"

darobin: Some folks are starting to implement as it relates to Web OS.
... Interested to know what implementers designs are looking like.

sicking: WebSMS prototype is almost done.
... It's for SMS-only (not generic)

<sicking> https://wiki.mozilla.org/WebAPI/WebSMS

sicking: This is an API that requires additional permissions. We wouldn't be comfortable simply saying "x page wants to send SMS".
... haven't proposed it anywhere yet.

<fjh> sicking notes security model not known yet, hence not deployed

darobin: in other places, security model parallels "mailto:"

<dom> [WebSMS still has SMSManager::send() though]

sicking: Now thinking of using sms: -based links (may needs a spec for that)
... enum messages, delete messages, basic search, functionality
... May never expose this to web pages.

darobin: my view of the security model might be...
... some apps run in browser-context and can get some extra privileges, though sites may not get that privilege.

sicking: Would be nice to have folks install their own SMS apps.

<dom> [FWIW, WebSMS looks closer to what we moved away from due to security concerns]

sicking: one security model is that the browser has a trust relationship with certain web stores.
... stores may need to be EV certified.
... problem with text message, is there's easy money to be made.
... large incentive which influences the security model.
... may also have an override for users, but behind non-accessible UI to prevent accidental use.

darobin: History: started with a powerful API, but trimmed due to security. Ended up with "sms:"

<fjh> see http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/#threats for premium rate abuse "abuse case"

darobin: Current design allows you to add Blobs to an SMS.

fjh: In our policy use doc. We have documented abuse cases.

<dom> Premium Rate Abuse in Policy Req documents

richt: what's the use case for letting a web app manage my text messages?

<npdoty> there is an SMS URI scheme IETF draft (apologies if this is already well-known to the group) http://tools.ietf.org/html/draft-wilde-sms-uri-20

richt: URL based SMS: has the option of giving the control back to the user.
... not convinced that management of SMS is necessary.
... Opera is not very interested at this stage.

darobin: Often we're asked if we only do Web API or if we do APIs for other contexts.
... usually we say "Web APIs"

sicking: We're not convinced that this should be a web API either.
... use case is that at least one app will need to manage SMS. Since we're building on Web Platform, we needed it.

<Josh_Soref> [ http://en.wikipedia.org/wiki/Wholesale_Applications_Community - WAC ]

bryan: We have implemented trust models, etc., and have done a lot of work in this space; it's all been unraveled. Now, we could live with sms:
... now we have devices who's OS is a web platform. If there can be pre-arranged trust relationships, we should go ahead and define what that should look like, or we accept fragmentation in the marketplace.

dom: charter is clear that we focus on Web APIs.
... an API that can be implemented in a current web browser.

spoussa: in the Tizen project, we defined a lot of APIs around messaging.
... hopefully we can come out and publish those soon.

Josh_Soref: but W3C will not be interested in that (since they're not Web APIs)

dom: we're talking about DAP (not W3C in general)

darobin: trying to do Web OS and Web APIs at the same time is problematic. So we stay strictly Web API-based.
... If there's sufficient interest, talk to someone at W3C to start a group...
... It sounds like we're keeping Web Messaging "on the shelf"

richt: I don't think the web messaging (sms) belongs on the ubiquitous Web.

<richt> I see a place for WebSMS, but it's not on the ubiquitous web.

sicking: At Mozilla, we've worked on Web Intents, where the first use case is messaging (e.g., sharing)

<dom> very good point that our messaging API would probably be completely overtaken by Web Intents/Activities

sicking: user can choose which message channel they want to use, but to base that on Web Intents.

darobin: makes sense to look at use cases.
... Anything you can submit/send

<dom> ACTION: Robin to look as Mozilla Labs Sharing experimentation re Messaging API [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action11]

<trackbot> Created ACTION-468 - Look as Mozilla Labs Sharing experimentation re Messaging API [on Robin Berjon - due 2011-11-10].

<Josh_Soref> http://mozillalabs.com/blog/2011/10/firefox-share-alpha-%E2%80%94-the-next-step-for-fast-sharing-in-firefox/

Suresh: regarding security model problems: have we documented the concerns so that we can try to work with/around them?

dom: we have one example in the policy document.

<fjh> see policy requirements draft on abuse cases

<fjh> http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/#premium-rate-abus

richt: another concern is to put the sms technology into the web (we should do something more generic, not tied to the specific technology)

<dsr> The Share Intent is documented at http://webintents.org/share

nwidell: mailto:++ is this something that we're also dropping, or is it solved by Web Intents.

darobin: It might be solved by Web Intents
... haven't heard lots of feedback desiring this...

<Zakim> dom, you wanted to remind we have an existing API without sms management

dom: if there is convergence on dropping web messaging in favor of Web Intents, are there any objections?

darobin: Any objections to updating the spec to indicate that it's not in progress?

jcantera: I object. You are sending the message that it's not useful work. It's dangerous to say that.

<richt> darobin, this must be done.

jcantera: you are sending that message (no pun)
... I think SMS is a useful approach

dom: if you are saying we should document all good approaches...

darobin: we have lots of drafts out there, it leads to confusion.
... other people pick up on our drafts. We want to clarify that "this spec" is not something that DAP is pursuing.
... we put a note in the spec. We can finesse the wording. When we stop working on something, we need to be clear that we're not following that path.

<dom> [FWIW, I think the current Messaging API wouldn't actually address most of jcantera's use cases]

darobin: let's find the wording that is acceptable.

<Zakim> bryan, you wanted to ask how does Web Intents allow me to send an MMS?

bryan: Looks like a lot of stuff in our charter could merge together... How will Web Intents subsume this stuff?
... I'd love to have an answer to this.
... I'd suggest that we hold our decision on the messaging spec.

<darobin> ACTION: Robin to make a CfC for shelving Messaging [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action12]

<trackbot> Created ACTION-469 - Make a CfC for shelving Messaging [on Robin Berjon - due 2011-11-10].

[Short Break]

fjh: we should start again

DAP Architectural Issues

fjh: we've invited members of TAG

noah: Noah Mendelson, TAG Chair

ashok: Ashok Malhotra, Oracle

ht: Henry Thomson, U of Edinburg

plinss: Peter Lins, HP

[ fjh presents: http://www.w3.org/2009/dap/wiki/images/3/38/Dap-architecture-status.pdf ]

[ Slide "Approach" ]

fjh: we talked about using WebIDL and binding to HTTP

[ Slide inputs re:Arch ]

fjh: Calendar could be Calendar on Web instead of on Device
... we want to avoid having two definitions
... we could make WebIDL produce JavaScript bindings
... we decided in Prague that we wanted to explore this
... and then we forgot about it

[ It came up again in Paris ]

[ Slide "Next Steps" ]

fjh: things like Contacts says it could be local or remote in spec
... but I'm not sure it says enough
... should we seriously consider an http-webidl binding
... then there's Discovery (new to the WG, after Recharter)
... Security and Privacy are a bit different
... are we ok w/ doing what we're doing - JavaScript w/ WebIDL
... we don't want to rework
... can we get an approach that satisfies other requirements
... I have a separate topic on Privacy, for later
... for now, do we need to do something specific for resources on the web
... if so, how?

[ End of Slides ]

ashok: where are you on timeline?

darobin: we're not very advanced
... we have some minimal research
... it was contentious and we found a way of not committing
... if someone comes with something either way, it would sway the balance
... initial feedback was ReSTful
... it initially surfaced that unless you constrained WebIDL
... it quickly becomes JSON RPC
... http based, but not ReST

noah: I wonder if you're overconstraining the answers
... assuming that the right thing is the IDL
... and focus more on wire
... because it tends to lead you to SOAP like
... JavaScript is capable of very fine grained
... I wonder if the right thing is to say "some things are ReST"
... and documented in "WADL"
... and some things are JavaScript
... "course grained streaming operations"
... you could imagine a JavaScript based API to the camera that let you pull bits out if you want to
... whereas with ReST you'll want a streaming thing
... it feels like a Calendar based API
... in ReST, something would stream back
... saying you'll start with JavaScript based
... you'll get something different

fjh: what about URIs
... and what about data minimization

darobin: there's a conflict between minimization and ReST
... but there's a problem involving URIs giving different output

noah: if you're going after someone's calendar through an HTTP link
... you don't want to do 10 GETs
... maybe you create a more complicated HTTP URI

plinss: if you ignore that now
... you'll design things that will never work with ReST

noah: my prejudice will be
... there are certain tangible benefits of URIs
... and accessing via ReST
... - if you have a Camera on a machine
... and you can access it remotely
... When you name things with URIs that support http
... you can access it transparently
... there are times when our little devices want to act as servers
... if you're a semantic web person
... the very fact that you can name it with URIs is useful
... saying this <URI> is broken
... there are pieces you can access with URIs that you can't with JavaScript

fjh: sicking thoughts?

sicking: if you access with a URI, what's the security model?

darobin: there's important background
... initially this was tied to WebIntroducer
... which is a way of introducing a service to another

<fjh> http://www.w3.org/2009/dap/wiki/images/3/38/Dap-architecture-status.pdf

darobin: and what you get is an http endpoint
... which is opaque
... the user was asked to provide a relationship
... and you get a version which opaquely describes the thing the user chose
... WebIntroducer faded and is replaced by WebIntents
... this change makes http things less attractive for us

Marcos: you're talking about WebIntents like it's a sure thing

darobin: it indeed isn't
... but the way things are headed, Mozilla Activities don't give you a URI either
... it seems like Mozilla's list is moving away from user mediation
... and closer toward web workers
... with things thrown over the wall

noah: in general, identification should be orthogonal to Access Control
... that not everyone should be able to get at my plane reservation
... isn't a reason for it not to be on the web
... don't put credential granters / privacy violations into the url itself
... but do have Access Controls so that the wrong people can't access the content of a URI

<dom> Linking and access control in the WWW Architecture Document

noah: saying we need Access Control isn't a reason not to use URIs

sicking: I see the point of Access Control
... that you can't send a URI to your vendor because they can't access it

noah: putting credentials into a URI (like Google Docs) is controversial
... but even if they're separate
... maybe I identify myself as "noah"
... it doesn't mean I shouldn't be able to have someone send me the URI to their camera
... and I access it with my identity and see their "snow-fall"

fjh: Battery is moving along
... and there's no reason for it to be ReSTful
... similarly, vibrator doesn't need to be ReSTful

noah: I remember 30 years ago that Printer vendors looked puzzled when asked about Web Servers on them
... and today I can talk to an average printer over HTTP

fjh: so, "it could be handy to ask it over the web?"

noah: I'm saying weigh the costs,
... and consider possible uses/benefits
... and maybe if there's some benefit, maybe it should be done

<richt> I'm in complete agreement with Noah, btw.

fjh: what if we said "ReST is v2?"

Marcos: it has to be based on Use Cases
... noah's example is great
... the Gemalto people are running servers on Smart Cards

<richt> well, I say "complete agreement". I think I'm in agreement but I missed some of the conversation.

Marcos: there are really cool things you can do w/ ReST

noah: and I think there are cases where it's a really stupid idea
... like access to the screen buffer or CPU with GET/POST

bryan: questions re:Arch on web

<bryan> Are device-local resources to be considered equal in terms of value to cloud-based resources? Is there a difference in trust for the user? Do I trust a cloud-based service any more than I trust the device in my hands, or the Web server via which I accessed the app that wants to access the information on the device in my hands?

bryan: if I went to a web page, do I trust it less than I trust something in the cloud?

<bryan> If we were to use REST for access to device-local resources, is there any difference to accessing remote resources? If I have a URI to a camera (local or remote), how does the browser ensure the camera owner authorizes the use of that camera?

bryan: that determines whether or not we consider the device to be part of the web

<fjh> Note - issue with REST interface for DAP APIs might be minimization

ht: if you think that a device is implicitly on the web
... - each of these things is a little web server
... changes the balance of power
... in a way that I don't think you want to go to right now
... the benefits that noah was talking about
... arises if the device is addressable
... for the foreseeable future, they won't be addressable

<DKA> +.5 to ht

ht: that you want to have access from any server on the web to any device on the web
... given the scale of the task in front of you
... I think you'd be entirely justified to say Device APIs are for the Device
... plinss 's right, if you do this, then in a few cases it'll be awkward later at best

noah: I asked you to think about it, and you did

dsr: in many cases, JavaScript makes sense
... sometimes ReSTful APIs make sense
... but it involves looking at UCs

fjh: I'm concerned, W3C is talking about going `fast`

plinss: I like bryan 's point about trust
... there are States where if you get pulled over for a Traffic Stop
... the police have the right to plug something into your device
... I'd like the device to be able to not trust that
... I accept there's a pragmatic approach
... maybe not making the battery available
... think about "were I to access this over http, what would my access pattern be?"
... such that you could design an API to insert to support that
... maybe the local code doesn't change
... you don't have to write that with the mechanism today
... but you're taken care of later by using that bit in a Constructor

<bryan> If my device has an access point it has exposed, e.g. for a service as envisioned by Web and TV IG, or a camera, should a local app be given less permission than a remote app, or are they equal given user permission for them to access the local resource?

bryan: Discovery of devices in the home...

<fjh> peter gave example of abuse case of local data, having law enforcement obtain information from device when that isn't appropriate because it is local

bryan: if a user has given permission, why shouldn't an app be able to access the resource?

sicking: trust issues
... even if we do v1 in JavaScript
... and v2 which is http based
... even if we knew we were going ReSTful

<ht> +1 to bryan -- architecting and installing the necessary security/authentication story for arbitrary devices on the web is not straightforward -- but presumably web-of-things has this in view. . .

sicking: I don't know I'd want web developers to fire 10 http calls just to communicate with Contacts
... sure we could wrap jQuery around that
... but we'd want to make sure one wraps the other
... one more understandable and simple

<Zakim> fjh, you wanted to ask about TAG review

plinss: you could design the ReSTful, and design the JavaScript, and not implement one
... you could get it wrong

noah: you could run into a risk where the two aren't equivalent and if you use both...
... in retrospect, we like controlling printers from browsers
... sometimes remotely
... if you can get 60% done w/ JavaScript
... then people will forget the rest
... that's the bigger risk, but I don't know how to quantify
... it seems like for most of this, you're committed to JavaScript
... maybe for some you should survey things and see if some of them where there are UCs for ReST
... and if some seem useful now/real soon

fjh: my sense is that the rough consensus of the Working Group is that we should stick w/ JavaScript APIs

<richt> TAG: Opera is looking in to the HTTP approach to local devices. You might want to look at: http://people.opera.com/richt/release/specs/discovery/Overview.html

fjh: UCs that would help us
... maybe the tag could help us
... by reviewing one of our specs
... I think maybe Contacts is the one
... but I'm so concerned about minimization

noah: is Contacts private to a device?

darobin: when Mozilla Labs
... did it, it could also expose arbitrary remote contacts

noah: look at Email
... hypothetically in Gmail, there is a URI for each email

<dsr> [HTTP isn't a good fit when the service needs to send asynchronous messages to the client]

noah: imagine the URI was portable from my device to my phone

Josh_Soref: Gmail doesn't do that, it has a different URI or different device styles

noah: maybe things have a URI, and maybe it can be resolved locally

<dom> dsr, Server Sent Events make asynchronous messages fairly easy via HTTP

noah: maybe you're replicating your Picasa/Flickr photos
... I'd like them to have the same URIs on Phone and Flickr
... except when you want to reference the replica
... you may say that integrating address books with too much history
... that it's too hard to wrap

richt: We, Opera, have been working on Device APIs for a long time
... the URL is the killer feature of the web
... and accessing stuff via http
... not just ReST
... accessing data
... we're interested in that approach
... it's local, but it's on the web as well

fjh: this is a Discovery protocol
... but it doesn't address minimization, or contacts

richt: it's up to the service/services that provide them
... everything's addressable with http

<bryan> addressable via URI does not equate to only accessible via HTTP

<npdoty> like X-Archived-At email headers?

fjh: maybe we should move on?

Josh_Soref: contact merging, integration of local and non-local should be transparent to user
... JavaScript API we have does not prevent that
... npdoty mentioned X-Archived-At email headers, we need that
... need something like UUID but not UUIDs
... merged URLs don't work
... W3 mailing list system is smart about URLs for cross-posted messages, allowing selection
... URL for picture might be picture1
... need really long URLs for local pictures to make unique on the web
... also bad for privacy since this means URL is disclosing information

or a form of fingerprinting

Josh_Soref: bad URLs can be a problem

<bryan> I think Josh_Soref is questioning universal object addressability via URI

[ fjh's email said: Also linked to DAP agenda at http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011,_Santa_Clara_(TPAC) ]

dom: maybe we prefer focusing on JavaScript for basic operations
... I don't see value taking a resolution on this

<fjh> proposed RESOLUTION: WG consensus to continue JavaScript approach to existing APIs

richt: the proposal we have is a JavaScript api
... it may provide this function, it may swallow the other APIs eventually
... there's no harm in doing both approaches

fjh: I think we need a decision so we don't go around in circles

ht: a double negative solution
... we decide:
... we will not hold up a row in this table for lack of a ReSTful api

noah: a proposal
... imagine we go down the road of doing JavaScript APIs
... not really ReSTful

<fjh> proposed RESOLUTION: will not stop current work for lack of a RESTful API for that API

noah: but where we need to identify something,
... we try to provide a URI for it
... it may always be localhost today
... but down the road, when we want to use a non local thing

<fjh> proposed RESOLUTION: will not stop work on a current JavaScript API for lack of a RESTful API for that API,

noah: we can change the host

<dom> (the actual resolution we could make would be to remove "REST-ful compatibility" from our APIchecklist but it was already removed in May http://www.w3.org/2009/dap/wiki/ApiCheckList )

noah: and then it can be used in ReSTful

<darobin> ISSUE-118?

<trackbot> ISSUE-118 -- How would feature discovery work for REST APIs -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/118

<darobin> proposed RESOLUTION: close ISSUE-118

<richt> Feature Discovery for REST APIs sounds like SOAP :(

Josh_Soref: there's a risk with constant URIs being abbreviated and misunderstood by developers
... such that in the future when they're not changed, they fall apart


<dom> close ISSUE-118

<trackbot> ISSUE-118 How would feature discovery work for REST APIs closed

RESOLUTION: will not stop work on a current JavaScript API for lack of a RESTful API for that API

<darobin> close ACTION-442

<trackbot> ACTION-442 Produce a REST binding example for Contacts (client, server, protocol) closed


fjh: this group has done two things
... . one is minimization
... the other is implicit consent
... there's work in the EU on privacy

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0091.html

fjh: executive summary
... consent is not just "I said share these 3 contacts is consent"
... it has to be informed consent
... you have to know what's going to happen to that information
... for what purpose
... how long will it be retained, how will it be used?
... the other aspect
... is it isn't within the API scope to define what third parties will do with that information
... we have a system for privacy
... it isn't a giblet
... EU says you don't need to click on ok

<richt> I wouldn't conflate this stuff together.

fjh: concerns:
... active consent is optional

<richt> I mean API authorization and fjh's description of consent.

fjh: we're leaving it up to the web page to provide what's needed
... - I don't know if it would be viable if it isn't

richt: API auth isn't the same as consent
... it's other stuff on the web site

fjh: we've been telling people we build in privacy by design
... by having users take actions
... which is insufficient according to EU opinion

dom: this is a systemic approach
... but for consent to be informed
... is not this group's problem
... it's the problem of the site
... I don't think that affects how we design the API

<richt> +1 dom.

dom: we have consent
... but I don't know that we need it for EU

<ernesto_jimenez> +1

fjh: do we need consent UI to be mandatory?

dom: it's optional because UI is in a much larger framework than what we as a WG can usefully document

fjh: it's a can of worms, maybe we need to update Best Practices

npdoty: some experience from the GeoLocation case
... I don't know if everyone was present
... we agreed it would be good for End Users of GeoLocation to have informed consent
... there was a large debate whether the protocol should enable informed consent
... the controversial decision we made
... was to leave it out
... but put in a requirement on web sites
... to use existing html
... UC Berkeley did a survey, and no one did it
... you might think about the implications

<dom> Privacy Issues of the W3C Geolocation API

npdoty: there might be ways for the browser to facilitate communication
... perhaps the browser could force web sites to do things

<fjh> ACTION: fjh to update web application privacy best practices related to active consent [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action13]

<trackbot> Created ACTION-470 - Update web application privacy best practices related to active consent [on Frederick Hirsch - due 2011-11-10].

ernesto_jimenez: the fact that web sites "inform the user"
... by adding a field to the user
... doesn't mean they'll fill it in properly
... providing another field will probably restrict what the UA can do
... because it will probably have to show that

npdoty: In GeoLocation, putting this in would enable web sites to lie
... there's no guarantee that it would be useful

<richt> websites will lie :)

npdoty: but it could be a convenient way to provide info to users

<Zakim> dsr, you wanted to note that this may be beyond the API itself, e.g. the browser may be able to provide a button to view the site's privacy policy

ernesto_jimenez: someone will argue that the Browser telling the User what the User Agent said, that the user will be more likely to trust the Web Site because they trust what they user says

dsr: in some cases it can be the responsibility of the browser to provide e.g. a link to a privacy policy
... it might not require changing the api

<bryan> The browser chrome needs to provide a means for users to easily see the types of personal data that the website can access. This is analogous to what is provided by native app managers (though not in the direct context of the app running, as usually the case).

bryan: if the browser had a "what this page can do"
... just like native app managers
... users can back away, or uninstall
... in our studies, "users don't care"
... providing prompts doesn't enhance the user experience

<dsr> [I worked on something like that with a Firefox extension - Privacy Dashboard http://code.w3.org/privacy-dashboard ]

fjh: we punted on rulesets
... which enabled users to say what they expected w.r.t. privacy server side
... I think dsr is right

<dom> Privacy Rulesets Proposal

fjh: it seems like we could provide access to a Privacy URI
... it's not the best thing

dom: is that at the API level?
... or is it just a link for privacy?

fjh: maybe not
... but is there anything for privacy by design we could push for
... beyond what is in our scope

<npdoty> our paper on Privacy Issues of the W3C Geolocation API: http://escholarship.org/uc/item/0rp834wf

noah: do you specify at that level?
... you could have things which don't have e.g. buttons

fjh: we could suggest "provide a means to convey a URI for privacy notice"

<Zakim> Josh_Soref, you wanted to note that browsers are improving this by making Content Alerts

Josh_Soref: users trust browsers more than web pages
... alerts were anchored to browser, looked as if from browser
... now switching so they look like part of the page
... so browsers can show material from page without confusion

noah: the fact that Users actually trust the Browser is interesting

ernesto_jimenez: the concern that we need to do Privacy by Design
... that the browser must get consent
... but then the browser should inform the user

fjh: Privacy by Design is Privacy by Default

ernesto_jimenez: but Privacy/Security is for each one of us
... the UA asks for information
... and it has to account for that

npdoty: that's an excellent point
... the work out of this group has been excellent
... informed consent is an indication of dialog between the site and the user
... if a UA might want to make a privacy preserving implementation
... they might want to have this extra field
... defining it in the API or otherwise standardizing this communication protocol
... that's why I want to discuss it at the API level

ernesto_jimenez: if UA vendors ask for this
... we could add it
... but in these cases, trying explain what a page will do with info is tricky

nwidell: we did some testing w/ normal users for getUserMedia()
... what we found was that people trusted the web site
... and they didn't understand
... they trusted the web site
... because it's a brand they interacted the most
... your user in the street doesn't understand the bit about UAs
... no matter how much we try to build sophisticated chrome around this
... it might not solve the problem, because users might not see these things

[ time check ]

<richt> ernesto_jimenez, websites will lie and if anyone wants to do UI/UX research we're happy to read it :)

<nwidell> We know that web sites will lie, but it is hard to communicate that to users

[ Summary - our "implicit consent" mechanism is consistent with "active consent" but requires web applications to provide notice, the WG may consider whether conveying notice should be done by more than relying on a web page to include that information ]


<darobin> http://www.w3.org/2011/04/webrtc/wiki/File:Webrtc_privacy.pdf

darobin: I was in the WebRTC WG
... and it seemed like they didn't know what we'd done in the area

<dom> we have actually documented some of it in http://www.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/ afaik

richt: we've had this principle which has informed our design
... Opera and Mozilla did hundreds of hours of work and reached the same conclusion/design

darobin: it would have been simpler if we had a 2 page document we could point to
... since you [WebRTC] aren't the last WG who will need to work in this space
... some of this is in our Wiki in the API checklist

fluffy: Cullen Jennings, Cisco

<npdoty> higher level principles and examples would both be great

fluffy: something like that would help

darobin: (a) documenting it (b) removing confusion that it isn't done

dom: ... we also have http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/
... - the privacy document

<npdoty> I would note that the Privacy and Security Interest Groups would be very interested, for example

darobin: but having a note on security principles for API design

<Josh_Soref> ACTION: berjon to look into a document for Security Principles for API Design [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action14]

<trackbot> Created ACTION-471 - Look into a document for Security Principles for API Design [on Robin Berjon - due 2011-11-11].

npdoty: that would be awesome


Schedule for Friday

darobin: Discovery API

<fjh> ACTION: fjh to update policy requirements for security requirements [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action15]

<trackbot> Created ACTION-472 - Update policy requirements for security requirements [on Frederick Hirsch - due 2011-11-11].

[ Adjourned ]

<darobin> ACTION: Robin to coordinate with fjh on the production of a "General Security Principles in Web APIs Design" Note [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action16]

<trackbot> Created ACTION-473 - Coordinate with fjh on the production of a "General Security Principles in Web APIs Design" Note [on Robin Berjon - due 2011-11-11].

<fjh> trackbot, start telecon

<trackbot> Meeting: Device APIs Working Group Teleconference

<trackbot> Date: 04 November 2011

<fjh> Chair: Robin_Berjon, Frederick_Hirsch


[Introductions of attendees]

fjh: Please join the IRC channel

dom: when you start speaking, please restate your name before speaking

[teleconference bridge may be set up if someone tries to dial in]

[About 60 people in the room]


darobin: we will begin with a short presentation on discovery

<fjh> Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011%2C_Santa_Clara_(TPAC)

darobin: then a few demos
... so people can get a feel for how discovery works
... then look at potential solutions
... look at Web Intents
... approaches we want to discuss

Networked Service Discovery and Messaging Demo

Presented by Giuseppe Pascale, Opera

Giuseppe: Web and TV IG has been looking at use cases for home network discovery

<fluffy> http://people.opera.com/giuseppep/hntf

<dom> Networked Service Discovery and Messaging, Giuseppe Pascale

Giuseppe: We started from simple question; looking at what all devices in home have in common
... they all run a browser
... they are connected to the home network
... Look at other facts, numbers
... A lot of people surf the internet while watching TV

<richt> 59% of Americans browse the web on different devices while they are watching TV * Nielsen Research http://blog.nielsen.com/nielsenwire/online_mobile/three-screen-report-q409/

Giuseppe describes scenarios of ways people can interact with devices

Giuseppe: So are we there yet? Can we do this today? Answer is almost
... Each of these use cases require three steps
... Discovery, authorization and third step is communication
... then devices start to communicate
... If we look at three steps
... Download is nothing to be done
... But looking at Discovery, it's not something you can do today in a Web Application
... What we will enable is to allow services to be aware of services and allow them to advertise themselves
... Being able to support this is important
... people could immediately use own devices
... We did not see major gaps with communications
... we looked at the protocols in major use in the home network
... and we believe they are implementable on top of existing web standards
... Use cases where you just want the devices to communicate
... The only real problem using this technology is constraint to same IP
... cannot communicate with normal Web messaging; may want to relax this restriction
... So these were the main conclusions our group made
... So CableLabs and Opera we looked at these use cases
... What we found is that the gaps are small
... We all want application to do the get of services
... Application doesn't need to know; just ask for some kind of service
... Gets a pointer, a URL, and communicate using normal Web stuff
... Only new thing is navigator.getNetworkServices
... That is what led to this conclusion
... Then we created a task force to look into these use cases; and we published a report
... There are more use cases described there; references to existing standards
... We would really like to discuss these use cases and decide which is the right approach
... We are open to discussion
... thank you

[Zakim bridge to start]

Marcos: It was not clear to me
... a bunch of people like to watch TV while surfing Internet
... Is that the same experience?
... Am I on tablet, laptop?
... where is content coming from
... How does Web content meet ?

Giuseppe: TV content is not different from web content
... So far we are experiencing content on one screen; can I distribute to different screens?
... Can we distribute social onto other screens?

Marcos: So to render content on both devices

Giuseppe: have complementary content on two screens, reuse what is already available

fluffy: I have a question about the security model
... Most implementations of UPNP assume the local network is safe
... doesn't require credentials on the local network
... does this model mean that any random web site can access local network resources?

Giuseppe: in the Opera proposal, this is taken care via the user agent
... the UA asks whether you want to allow a given web app to access your local services
... before that point, no communication is possible
... But FWIW, this is already possible today via Android applications

fluffy: what about security, e.g. UPnP makes certain assumptions

Marcos: the threat model is a bit different there
... an Android application doesn't have as much power as something on the open Web

nvbalaji: How about the TV? Does the TV get a chance to authorize the mobile device?
... like some kind of peering?

Giuseppe: the examples I showed are based on UPnP
... we're reusing that infrastructure

<richt> @dom, my response: There's a decision that needs to be made at connection time. The user needs to decide if they trust the web site to access this X resource. Brokered by the UA.

Marcos: you don't have a choice

jcdufourd: UPnP is one of the protocols that Opera is implementing as an example
... we don't want to lock ourselves with UPnP
... in the various protocols, there are occasions for security / authentication

@@@: @@@

Giuseppe: as shown in the slides, this allows browser to connect your devices
... using more secure way
... but that's protocol dependent
... We are enabling security with two devices

jcdufourd: there is a communication protocol
... in between request for discovery and answer...

Giuseppe: the application can only ask for a type and get them
... there is user agent
... everything is hidden; you cannot info about your home network

Marcos: that is ideal; that isn't being exposed

Giuseppe: define some type of devices
... and the user agent says yeah, you have one
... this is device available at this URL
... user has authorized it
... how this is shown by user agent in way user understands is a big question

sicking: sounds like you are getting this to work on existing hardware

jcdufourd: Giuseppe's example was only an example, mention of UPnP did not imply we want to use UPnP in the end, just a discovery protocol, and for security, we are just saying that there is a step in between discovery request and response where a security policy is applied
... are you looking at different security scenarios?

Giuseppe: enabling something not tied to any protocol if you establish a channel
... user agent may say not allow to communicate with any device
... this is one approach
... if people are concerned they can say no

sicking: where we can enable for security models

Giuseppe: underlying protocol; we recommend two
... if there is third or fourth it should be transparent
... new service; how to discover it; have a menu
... so doesn't have to be discovered in traditional way

richt: Abstraction of that process
... where innovation happens
... keep innovation; a high priority

darobin: BBC wrote a protocol...

<dom> Networked Service Discovery and Messaging proposal from Opera and CableLabs

olivier: We looked at a lot of use cases; many have been mentioned
... many users in the home
... We don't necessarily want the kid's PC to control the TV
... we built a prototype that does discovery, pairing, control, reading info
... done centralized on set-top box

<dom> [one thing that seems to be protocol specific is the identification of the "type" of services that is to be discovered]

olivier: What I hear proposed is interesting...have every device be a first class citizen

Marcos: about new protocols
... would be great if Web and TV could look into that
... what is the common model to be used
... then could be abstracted if something new is needed
... to follow up
... Like Web and TV group to answer how much
... what these protocols provide
... UPnP spec is huge and inaccessible
... DLNA is claiming how many billions of devices

Clarke: DLNA references UPnP.

<olivier> the Universal Control API (BBC)

Marcos: have a human accessible list to see what we can do; control volume, etc.
... What would be needed if a new protocol is needed?

Giuseppe: Two things
... this was completion of our group
... per the charter
... This group will have to answer

Marcos: So we will have to work together to answer it
... discover something, but now I cannot do anything with it

Giuseppe: we also discussed high vs. low level
... do you want to abstract in high level

Marcos: don't want to go there; too early

darobin: queue is closed

Marcos, bryan, and darobin

Marcos: we have to look at the licenses around these technologies and the implications

darobin: I think they are pretty bad

Marcos: we don't know

<bryan> If I understand one goal expressed, it would be to facilitate both existing and new devices through an API abstraction which is tied to neither. That seems like a good goal for the initial API. Is that considered a high-level or low-level API?

darobin: UPnP is RAND-Z; DLNA

Giuseppe: spec does not mention any

bryan: if I understand one goal

<Zakim> darobin, you wanted to talk about use case diversity

bryan: it would be to facilitate new devices that are tied to neither
... a good goal

darobin: a comment on presentation and discussion
... what I find notable
... this is a generic discovery API
... have you guys looked at...
... other things that people like me who don't have a TV would be interested in
... I could not watch two screens at once since I don't have a TV

richt: Good point
... look at services; what is local
... is this something we are going to do

darobin: if only controlling TVs

Giuseppe: if you watch content
... vs. not have a TV
... could watch content on your PC

darobin: Why would I have it on ten devices? I have a PC
... just saying it's important to look at other devices
... If I can access an extended network
... something about no assumption; and is it possible

Clarke: today it is possible

darobin: hands around the room

<dsr> There are many more devices of interest than TVs, cars, remote sensors, home healthcare, home security, heating and lighting, it is very open ended.

BobLund: this is not limited to multiple screens
... can access multiple devices
... UPnP can talk to your thermometer

JanL: prototype surrounding discovery
... allows you to discover content, formats
... see what is most compatible with your device
... example of not TV based
... there is other potential regarding that
... in homes

jcdufourd: the use case we brought was multiscreen
... TV was one example that spoke to most people
... one important thing was to have use cases where things move around dynamically after start of various switches

sicking: a non-device we would like to talk to
... people's home routers
... that scares me if Web pages can open up a dialogue on users browsers

Giuseppe: user agent...

sicking: If all I need is...

Jean-Francois: We were talking about TV screens
... seems to bother you
... you can imagine listening to a podcast, go to car
... and transfers to car; continuous journey
... over different locations and devices

darobin: second screen
... let's go to demos

<richt> Any native application on any device can already pwn your router if it wants to.

Clarke: this discovery protocol...is a single API
... assumption is device discovered in some fashion, connected electronically
... way you communicate is up to user agent

<dom> richt, true, but native apps needs to be installed in the first place; you can't fall upon them just by clicking a random obscure link

Clarke: could speak an IP based protocol, USB, Bluetooth
... have to write some code to do that discovery
... that is only question
... no assumption
... turns out I work for company interested in TV; why my assumptions are based on that

Cable Labs Discovery Implementation Demo

[Clarke Stevens to demo]

<bryan> re the point about risk of routers with UPNP interfaces being taken over by a single browser ACTION: it's not possible in most routers to take control via a simple button from a browser on the network - most routers have some sort of admin login enforced, but I agree that it would be bad if that security was diminished in any way by this

Clarke: I have UPnP servers; mini DLNA
... demonstrates two protocols
... I am currently using two
... bringing up a regular web page
... the way I implemented it
... and how Opera has done in browser code itself is user agent is a Java applet
... web page is typical; HTML, CSS, JavaScript
... two things in applet; get network services
... three parameters
... type of service to find
... showing UPnP service
... passes URN that identified that service

<dom> CableLabs Discovery API Implementation as a Java applet (Member-only archive)

Clarke: other is MTDAP [?]
... everything else is on the network; only discovering those types of services
... also implemented in the applet
... XHR that does cross-origin stuff
... to security question, this authorizes browser to get the applet
... I've got a Java consol here to see what is happening
... now applet has started
... start UPnP Discovery and it starts discovery process to find devices

<richt> FYI, we will make 'Start UPnP Discovery' and 'Start mDNS Discovery' as a background process in the UA...like we do with Opera Unite with zero performance interruption.

Clarke: Once it's discovered, this asks to find two devices
... on the network
... a check box here
... So far the web page knows nothing about devices; all in the user agent
... If I don't check it still doesn't know
... have to check and say ok
... Now it knows about those devices
... communication is nothing new
... using XHR, Web Sockets
... whatever protocol you are using
... Calls are identical
... Looking for adapt server, calling different code within Java applet
... call it again and it recognizes that something has been discovered
... showing three services here
... just to show communications
... let me browse down tree
... generating SOAP
... come back again
... pop up same services it found before; uncheck one
... now communication with that service is disabled
... web page could store that
... no communication allowed between that
... that's it


<Clarke> Here is the URL where you can get the CableLabs demo: http://lists.w3.org/Archives/Member/w3c-archive/2011Oct/0400.html

Giuseppe: quick comment
... communication part can be used with off the shelf products already

darobin: that's a security problem

Giuseppe: widget is allowed to communicate

Marcos: I still think that you guys are doing
... approaching in a weird way

darobin: the architecture?

Webinos Discovery Demo

dsr: Dave Raggett, W3C

<bryan> I wonder how the owner of the devices that are discoverable can be a part in this process. Is it assumed that any access controls are included here, except on the discovering user's case?

dsr: I'm going to show you another way of discovery
... Webinos is discovering apps across devices
... BMW is one of the participants
... this is an Android phone
... top part of display shows incoming requests
... advertises the IP address
... running UPnP and local web server
... bottom is screen preview
... I'll show you API is a second
... it's discovered the phone
... this is where Zeroconf/UPnP take different approaches
... and the naming may matter to users

darobin: this could be solved
... elsewhere

dsr: hopefully the users will give better names to their devices as they see them
... jumping backwards
... I developed a plugin that exposes EVERYTHING
... it's a nightmare

[ dsr demos a thing listing everything ]

dsr: SSDP is common and Zeroconf
... exposing everything makes fingerprinting trivial

[ dsr shows a dialog ]

dsr: this dialog shows what's available
... and it shows who's showing the dialog

<bryan> that brings up the essence of my note above: is it assumed that the users of all the accessible devices are responsible for the access to their devices?

dsr: I don't know that it's enough for informed consent

[ dsr: darobin look at the picture ]

dsr: you've discovered a ReSTful service for an unrestful picture

[ picture of darobin squirming ]

dsr: user's and end user's perspective are critical

bryan: do we assume that things out in cloud is out of scope?

dsr: I think AC is out of scope
... a lot of people out here are advertising themselves
... and they might not be totally aware that they're doing that
... but it's a separate issue

Clarke: I'll post a url on IRC for our app

Demos wrapup

darobin: thanks all for the demos
... it's nice for something concrete
... I'd like to get into the arch issues that several people have been talking about
... one of the things I've heard a lot of concern about
... is that you can list services

<bryan> link to dsr's demo?

<richt> FYI, some mockups of the UA UI for security/authorization:

<richt> http://people.opera.com/richt/release/specs/discovery/tpac2011_servicediscovery_ui_1.png

<richt> http://people.opera.com/richt/release/specs/discovery/tpac2011_servicediscovery_ui_2.png

darobin: yes it's user mediated
... but is that something you want to tell an app if you can avoid it?
... say you want to print something
... either "list me all the printers", I "show you the list of printers"

<fjh> does minimization apply to discovery

darobin: then you print something
... alternatively, you could say "I want to print something"

jcdufourd: avoid "user mediated" to say "mediated"

darobin: we have a rule that you have to drink if you say "policy"
... is it more useful/more secure to get a list of services to the application
... or to have the app say "I want to do X to Y" and never let it know what it's talking to

Giuseppe: there could be cases when you need to talk to it

darobin: so you get a Worker

Giuseppe: some systems never want to be exposed

darobin: yeah, that's what I'm aiming at

bryan: that brings up the Roles of the Users in this Equation
... user has to make a decision about whether it's good for things to see stuff
... there's also a decision about knowing if things should be seen of remote devices
... there's an assumption of single owner on a home network
... that falls apart in the coffee shop
... we need to think about roles of users involved in making things accessible

Marcos: your example of the printer was a good one
... when you go to print from a web page
... you just press apple-p/cmd-p
... you get an Intent to Print
... I never need to expose the API of the printer to the web page
... I'm able to print
... I think that's a good model
... if this functionality is explored, I'd like to see that explored
... I'd like to see where it breaks down

<bryan> We need to think about the roles of the users accessing devices (the user may want to limit their browser to access only certain devices, whether or not they own/trust the devices), and the role of the owner of those other devices. These roles are very different in the home vs. a public space.

Clarke: I think that breaks down at the first step
... because the point is to let the web page have that interface
... if you have a TV or something

Marcos: give me a more concrete use case
... say I have Facebook and I want to have something on the screen
... or I go to Facebook, and I want to play radio somewhere
... let's cover the 90% UCs

dsr: there are many different UCs for accessing services
... the number of services, some will be defined by us, some by others

Giuseppe: we were thinking about looking at Web Intents

darobin: I heard something interesting
... I heard simple use cases and I heard Intents
... it could be very much interesting to see code
... about how simple UCs
... that Marcos was talking about
... could be done with Intents
... this is a debate that happens for a lot of APIs
... do you do low level or high level

<bryan> +1 to quick production of code examples that illustrate how discovery and Intents help here.

darobin: low better for innovation, high better for security
... there's no set rule
... it would be useful for moving forward
... to see a simple high level Intents api
... and a discovery api

Clarke: my url has 3 examples + source code

Giuseppe: how do we move forward?
... it would be useful to have the discussion in the sample place/group

<Zakim> dsr, you wanted to mention connection to social networks as a means for describing sharing preferences

dsr: we spoke about AC a while back
... it involved stuff in your own home
... there's stuff for social networks
... and what do you share with your friends
... how do users think about their services and control how they're used

fjh: we have different proposals about Discovery
... one from Opera
... one from Webinos
... should we talk about other fundamental differences in approaches

<bryan> +1 to dsr's comment - Intents as I understand it is about use cases outside the home - in the cloud

fjh: I'm not sure I understand what Arch issues are significant that we might not have been discussed
... dsr mentioned Naming
... another was timing for Discovery

<dom> (I don't think Intents are particularly limited to cloud-based services)

fjh: impact on Battery
... not sure what from Webinos that we're missing/forgetting
... we should identify Issues

darobin: given Time Constraints

<bryan> underscores the need to understand what Intents and Discovery *are* really about

darobin: Capture as Issues in Tracker

fjh: get a handle on key bits

Giuseppe: we did some in the Comparison doc

darobin: I'd like to close the queue

[ the queue was closed ]

<dsr> I will post my example as shown

sicking: you said most of what I was going to say

<richt> FYI, use cases are being collected on the W3C DAP Wiki at: http://www.w3.org/2009/dap/wiki/ServiceDiscoveryUseCases

sicking: the problem with low level APIs, is they're great, but the security model depends heavily on the api

<Clarke> The Opera/CableLabs proposed specification has already been posted to DAP. You can answer a lot of architecture questions by referring to the specification.

sicking: if anyone could take a picture with just that incomprehensible dialog
... would be scary

<fjh> ISSUE: Low level discovery API security and privacy issues

<trackbot> Created ISSUE-123 - Low level discovery API security and privacy issues ; please complete additional details at http://www.w3.org/2009/dap/track/issues/123/edit .

sicking: I might want to allow something in Mozilla, but with a different security model

dsr: we could argue about high/low level
... the security/usability bit needs to be discussed at length

adrianba: Adrian Bateman, Microsoft
... 1. in many platforms, e.g. Windows
... we have APIs in the platform that do Discovery with different protocols
... this proposal abstracts protocols is a good thing
... requiring certain protocols in the API spec, which this does, we think is a bad thing
... 2. the level of details exposed
... is too detailed
... we tell you "which of these TVs do you want to talk to"
... not "which services do you want to talk to"
... 3. we don't generally make individual protocols available
... requiring pages to be able to speak individual protocols seem like a problem

Giuseppe: exposing an AV service
... the UA has all the info
... it won't show AV service
... the info isn't shown to the page, but to the user

adrianba: we don't know what you're looking for
... the API asks me to ask for services
... I don't know what you really want
... I don't know how to aggregate it

Clarke: you could make that specific to your application
... we're implementing everything in JS
... to make the API very generic
... you could offer only "show on screen"
... you could show "do you want to connect to your TV?"
... I think that's an implementation detail

jcdufourd: one thing not in the two proposals
... discovery is started by JS API call
... one choice is to have discovery as a background process in the UA
... and not started by the call

richt: that's not what our proposal is

jcdufourd: the demos showed that

dsr: it's not the case

richt: in Opera Unite, we do background discovery
... it has 0 penalty
... on performance
... we like it

darobin: where do we move this forward?
... is it the consensus of Web IG that it happen in the same place as Web Intents

Giuseppe: we haven't discussed this in the IG

darobin: we had a joint session w/ WebApps on Monday
... the agreement w/ WebApps is a joint TF on Intents w/ DAP

<ArtB> Here are the minutes from WebApps' minutes re Web Intents: http://www.w3.org/2011/10/31-WebApps-minutes.html#item06

darobin: that's scheduled for the next session
... there would be a separate mailing list where Intents would be discussed/developed
... I don't know to what degree discovery could be done there
... I'm sort of happy with whatever makes people happy
... it would be useful for you guys to come to the next session
... better for you to represent yourself, than have me proxy you
... after the break, 10 mins on NetInfo and then Intents

ArtB: talking about technical details or just work split?

darobin: getting approval from the group
... it could be 30s
... it could take 2 hours and a half
... back at 10:50a
... tentatively Intents at 11am sharp

<ArtB> Title: DAPI WG f2f Meeting

<ArtB> Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011,_Santa_Clara_%28TPAC%29

<ArtB> Meeting: DAPI WG f2f Meeting

Network Information API

<dom> The Network Information API editors draft

darobin: information exposed about user's network situation is not sufficient
... might be on the WiFi network but that WiFi could be using 3g (via tethering)
... some people have expressed interest in talking about this
... Mozilla, Microsoft

sicking: first thing is checking whether you have connectivity at all
... you probably want to know whether you are connected, and know whether you are on Edge (very slow)
... some concerns about finger printing too

adrianba: Web platform sensitive to network in two ways
... JavaScript API to learn whether you are on a metered network
... we think it is difficult because it's usually another part of the platform making that kind of decision
... e.g. we may want the video element to make a decision based on available bandwidth
... may need apps to coordinate based on the network available

<Zakim> Josh_Soref, you wanted to talk about how apps might want to make a decision and will make the wrong one based on the answer they get to the unrelated question they ask

Josh_Soref: apps might want to make a decision and will make the wrong one based on the answer they get to the unrelated question they ask
... if you have multiple network paths, the app might make a bad decision
... XHR can be used to know whether you have network connectivity
... try!
... the only way to know whether you have connectivity and sufficient bandwidth is to try
... if you try and make a decision based on some theoretical network topology you are likely to make the wrong decision

adrianba: +1

fluffy: one thing you can't find by measuring is what you will be billed

<Zakim> Josh_Soref, you wanted to respond that no one has that info

adrianba: question is how much is the UA's responsibility, how much is the app's

Josh_Soref: [missed]

bryan: there are network APIs in development

Josh_Soref: Nothing knows costs, Nokia+RIM experience shows that a SIM in a given country doesn't have any relation to cost

dom: the GSMA is working on this as part of their work on network APIs (e.g. OneAPI)

lgombos: Just the act of trying costs money

[ Birds chirping in background ]

lgombos: it is possible that the network knows those characteristics, but the browser does not know them yet

[ The chirps turn out to maybe be squeaky wheels on a cart ]

darobin: anyone interested in working on a proposal around this

[ Marcos investigates carts ]

sicking: I might be interested

adrianba: expresses interest too

Josh_Soref: me too

<dom> ACTION: Adrian to make a proposal for Network Information API [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action17]

<trackbot> Created ACTION-474 - Make a proposal for Network Information API [on Adrian Bateman - due 2011-11-11].

<Josh_Soref> ACTION: soref to propose a new Network Info [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action18]

<trackbot> Created ACTION-475 - Propose a new Network Info [on Josh Soref - due 2011-11-11].

<Josh_Soref> ACTION: berjon to ACTION: sicking to propose a new Network Info [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action19]

<trackbot> Created ACTION-476 - ACTION: sicking to propose a new Network Info [on Robin Berjon - due 2011-11-11].

Web Intents coordination

darobin: the idea is to get agreement on the joint work
... objection to working with WebApps on Web Intents?

[ darobin references unorganizations from Wednesday ]

richt: clarify what it exactly means?
... where does the editing get done?

darobin: the document lives in /TR
... and it lives in /hg for which we're happy to use mercurial. If the editors prefer to use CVS, they should be dragged away and shot
... IPR-wise, the document would be covered by the union of the two groups
... no details yet on the operational side

ArtB: no change to DAP charter, but would require a change to the WebApps charter

darobin: might be technically covered by DAP first

[ might be => is ]

richt: is this the model for Device APIs going forward

darobin: whenever it makes sense to use something, we'll use it

sicking: can I request to have a separate mailing-list

darobin: that's operational. Hold that thought

bryan: no objection. We need to understand what we consider device api, what we consider network API etc

dom: the answer is 42, I'm afraid

bryan: people still have questions about "what is a device API"

dom: answering the question won't change the shape of the work
... I don't think we can usefully define what is a device API and what's not
... the only useful answer is what is currently a deliverable in what group charter

adrianba: joint deliverables should be avoided in general
... there are times when some people can't participate in some WGs
... when such situations arise, a joint Deliverable is probably the least worst solution

Josh_Soref: rather than, say, creating yet another group

jcdufourd: problem is we don't exactly know what Web Intents are

dom: Does anyone want to introduce?

Marcos: go to http://webintents.org

Introducing Web Intents

[ Josh_Soref takes a run at introducing Web Intents]

Josh_Soref: the general idea is - a page wants to do something, e.g. share
... the UA will get a list of things that could do sharing
... if the user chooses to share, the UA would open a new window and send the data that the user wants to share
... you can share, call, print... many different possible verbs

Marcos: list of default Intents - Discover, Share, Edit, View, Pick, Subscribe, Save

darobin: fairly similar to HTTP verbs
... example of sending e-mail from a page in Android

<Anders> WebIntents, try the demo posted by Claes Nilsson http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0009.html

jcdufourd: this looks like a web service directory or broker

darobin: it is, but we don't have that

jcdufourd: but do we need a standard for it

Marcos: we need services to register themselves with the broker

jcdufourd: you could implement that today, offer the service

[ Josh_Soref demonstrates how Intents "tosses" the data ]

<dom> Josh_Soref: not without knowing the service provider beforehand

Josh_Soref: not directly talking to the service

jcdufourd: but why do we need a standard

darobin: we've already decided to have a standard, it's in the charter

nvbalaji: the browser is becoming a broker, so web pages can register themselves
... can any site register itself?

Josh_Soref: that's one way. Someone could maintain a list

dom: there are many ways to register
... in band, out of band

ArtB: [tongue in cheek] I conclude you are not going to do it and WebApps will do it

Josh_Soref: important point is that if we don't do it, WebApps will

dsr: when it comes to joint deliverable, important to agree on scope
... can we reach an agreement on set of use cases

darobin: would have liked this discussion to happen on the list

dsr: relationship between this and generic registration and discovery. Need to clarify

darobin: yes

<Zakim> dsr, you wanted to ask if this is essentially service registration. an invocation?

JanL: question on the security aspect

bryan: Is part of the reason for DAP's interest that we expect device-local resources to use Web Intents to register themselves as potential providers?

darobin: yes

nvbalaji: would we expect DAP APIs to be required to use WebIntents

darobin: having reached the end of queue, asking again - any objection to joint work

RESOLUTION: DAP will do joint work with WebApps on web intents

darobin: opening operational topics

sicking: a few people would rather not subscribe to the DAP (or WebApps) ML
... but would have a lot to contribute

<dom> +1

sicking: request a separate mailing-list

darobin: Any objection to calling it Intents?

sicking: don't know

<nvbalaji> Does it mean that interest web intent implies Device APIs must be defined in terms of intents?

<dom> (public-noname@w3.org ?)

sicking: think it's a terrible name but trying to stay away from naming discussions

[show of hands for strong support]

RESOLUTION: there will be a separate mailing-list for web-intents joint work

[ The show of hands is quite strong ]

darobin: should the task force have telcons? think it should be the TF's decision
... ditto for mercurial, etc
... anyone would like to step in as chair for the TF?
... any other operational concerns?

dom: question of when WebApps gets rechartered with it
... and when we start

darobin: I assume ASAP

<richt> +1

Igarashi: wonder if the scope would include discovery of services and resources in the home network
... as we discussed in previous session

<richt> +1 and I'd _like_ to solve local device discovery with Web Intents.

<richt> ...but I'm entirely unconvinced.

mav: Mark Vickers, Comcast
... too soon to say that the two efforts should result in the same API, but there are clear similarities

<dom> +1 on mav

mav: hoping they at least be consistently addressed, early on
... strong similarities with the use cases mentioned in home networking discussion earlier, sharing photo, etc

darobin: first discussion on Web Intents could take scenarios and see how they map

<dom> +1 to robin

darobin: see if Intents match, complement Discovery

mav: could result in chartering issues for WebApps if the two need to be merged

richt: I'd _like_ to solve local device discovery with Web Intents. We tried but ran in to numerous issues and absolutely needed to remove some of the abstraction from that model. Would like to re-evaluate those use cases in the Web Intents discussion.

<olivier> ACTION: Robin to draft TF charter for Intents [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action20]

<trackbot> Created ACTION-477 - Draft TF charter for Intents [on Robin Berjon - due 2011-11-11].

<olivier> ACTION: Robin to wirk with ArtB, agree on mailing-list name (public-Intents?) [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action21]

<trackbot> Created ACTION-478 - Work with ArtB, agree on mailing-list name (public-Intents?) [on Robin Berjon - due 2011-11-11].

dom: any feedback on using Web Intents as potential replacement for messaging API

fjh: do you want to draft a proposal?


darobin: people working on F1 best for that?

nvbalaji: is the browser responsible for the UI for local messaging?

sicking: not necessarily

dom: the browser can hand off UI to the native app

darobin: Intent can be anything
... same for printing
... you can do cloud printing
... you could do printing to a local device
... if you're doing it locally, you have to support local printing
... that's already the case if the browser already supports this
... if it doesn't, it can send the Intents elsewhere

nvbalaji: if someone wants to expose local services, it has to be through the browser

dom: one way to expose them is to use a local native app
... you need to have something to send the data to the native app
... but the browser doesn't have to do the UI
... or underlying protocol

darobin: one thing not discussed
... I'd expect UAs to allow for Extensions to expose Intent services
... so you might not need to modify the browser itself to expose local services
... you would probably use its extensibility platform to do that
... at least, if that's what I'd do as a browser vendor

dom: other feedback?

<bryan> Is the concept for using Web Intents for messaging that all interaction with a messaging client would use XHR / REST to a local or remote device resource (depending upon which provider was selected by the user)? Or for a "local provider" would the browser be able to optimize the interaction by calling a native service API directly (e.g. a messaging API)? Would we expect that the user experience in both cases is equal, and the Web developer tasks to

<bryan> use these implementations equivalent?

bryan: understanding concept of using Intents to replace Messaging API

<darobin> http://mozillalabs.com/messaging/2010/11/10/f1/ -> Mozilla Labs: F1

dom: up to the browser
... will there really be no difference in Perf/Security?

<dsr> In principle, the browser could also load intent "drivers" for remote services over WiFi and Bluetooth, or even USB and NFC.

<darobin> http://f1.mozillamessaging.com/ -> official Mozilla F1 site, for Sharing/Messaging

bryan: say I want to create a draft message
... how would that work?
... is that sent to the cloud/device?
... I understand how that works in JS

richt: my understanding of Intents
... you choose an intent, get a service
... the UA broker opens a tabbed window displaying the service's page
... this concept of communicating over HTTP w/ UPnP
... is not in the protocol

dom: I think the browser could have a UPnP implementation for that

richt: the browser has to speak that language

dom: if you require this, you lose the ability to bring more

Josh_Soref: of course an extension could add them

dom: Intents is a Framework for adding solutions
... but we'd still need an API for that UC
... for drafting, for sending
... at the end of the day, it's up to the User to select the UE
... turning the Messaging API into the Intent based approach
... still requires deciding how to do it in that Framework
... how do I discover and attach?

darobin: the idea is not "We Have Intents, We're Done"

<dsr> [I am looking into ways to treat service/Intent drivers dynamically as a market for services, and look forward to providing demos]

darobin: each Intent still needs to define how a given API works

dom: we have WSDL for that >:)

[ darobin threatens to throw a full bottle @dom, we only tossed empty bottles earlier ]

darobin: it's reasonably easy to define that api

bryan: we still need a messaging API spec
... is it possible to be done in JS?

dom: you could have a wrapper that could do that

bryan: developed outside of W3 from that?

nvbalaji: Messaging/Intents
... for local messages
... will the browser actually do that?
... will a plugin have to do that?
... will the browser do that?

dom: I think browsers will have to do that
... just as they respond to mailto:

nvbalaji: is that mandatory in the spec?

<bryan> To me, the result of the discussion is that we still need a messaging API spec, even if we use Web Intents to facilitate discovery, attachment, security.

dom: it's as normative as having a separate JS api
... browsers would have to implement it if it were separate
... same as if browsers bridge to local for Intents for Messaging

nvbalaji: is it mandated that browsers do this?

Josh_Soref: there is this thing called window.print in DOM0
... and have a lot of devices with no ability to print

<bryan> An open question is whether Web Intents prevents the exposure of APIs using JavaScript, or the W3C's ability/opportunity to develop JavaScript-based APIs.

Josh_Soref: or send e-mail
... some browsers don't have such capabilities out of the box
... but could be extended
... as a framework, this says "you can ask for X"
... implementation quality will determine whether the user can print/message

[time check]

sicking: re: bryan 's concern about messaging over Intents
... we just need to ensure we can handle the UCs
... it's unanswered, but we can ensure it will be supported
... there will need a defined API on top of Intents

bryan: maybe that URI is abstracted by the browser

dom: there will not be URIs for services
... communication is via postMessage
... you get something back
... is how you get things back
... no visible HTTP interactions
... in the background there may be, but you don't experience them

<nvbalaji> It looks to me "messaging API with Web Intent" means dropping the messaging spec entirely :-)

darobin: lunch until 1pm

[ Adjourned ]

[ We're about ready to start ]

Feature Permissions

<fjh> http://dev.w3.org/2009/dap/perms/FeaturePermissions.html

lgombos: Laszlo Gombos, Nokia
... originally in Web Notifications
... later on it was discussed that it would be useful outside of the scope of that API
... so it came to DAP
... and Web Notifications has a dependency on this Spec
... it's somewhat controversial
... we're interested in getting the issues on the table
... there's a WebKit implementation

sicking: is it shipping?

lgombos: yes
... I think it's in Chrome
... Nokia shipped it as well

<darobin> http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html -> Playground for Feature Permissions

lgombos: I think it's vendor prefixed

fjh: I think darobin did an experiment a while ago of using a registry for features
... we talked about using a registry, reusing infrastructure

darobin: there's a registry for XPointer
... I registered the DAP-XPointer scheme
... the same infrastructure could be used
... the infrastructure is there

lgombos: atm, what we know is Web Notification
... if that's the only feature for this api
... then maybe it doesn't make sense to have this spec

darobin: if it's the only case, then this approach, is the wrong way

fjh: one could ask if there's a need to have a means for permissions that's interoperable

sicking: to derail the discussion
... or I'll yield to implementers

lgombos: for Nokia, we're interested in Web Notification, and we have a dependency

sicking: here's the take from Mozilla/people talking about it
... most people at Mozilla (there are disagreements at Mozilla)
... my understanding that the goal of this spec

<dom> Permissions For Web Applications, Robert O'Callahan

sicking: is to allow the page to bundle a bunch of requests together
... to reduce the number of requests the user sees
... that's an antigoal for us
... we don't want to let people group together a lot of requests (camera, location, ...)
... there's research that says people don't read dialogs
... but there is research that says people do read the button
... having a very big button will cause users to not read the button

lgombos: I think the functionality you describe would be a natural fit
... a the moment you only can request one thing at a time
... is that when we display UI for something

sicking: another thing that's a goal for us
... at the site when something is going to use it
... for instance, when you install an App on Android
... you get asked for permissions for lots of things
... but you have no way of making a determination
... of why does e.g. a Game need access to Contacts
... maybe the Game wants to play w/ contacts
... and maybe you could add a description to the request
... but when you want to install, you're so excited
... you really want to play
... and sharing the game with others
... is something the user can make a decision on later

fjh: the idea was to ask for permission up front
... to avoid user involvement

sicking: that's an antigoal for us
... we don't want an app to say "I want to play the game, but I don't want to give access to contacts"
... it's better application design
... the way to encourage that is through more user choice
... in general, we're worried about applications asking for a bunch of things up front
... and if you don't say yes for everything, they'll say "you don't get to play"
... we can't prevent it completely, but the more we do to prevent it, the better

bryan: this API is about an app asking for permission

<bryan> We need to provide a way for users to know about what features are used by an app, and to select permission level for each. Most users would never be expected to use such controls, but the exposure of them is likely to be a mandated (e.g. regulatory) requirement. These permissions do not need to involve prompts, but do need to be representable in some UI that is provided by a trusted entity (e.g. the Web user agent).

lgombos: also query permission

<bryan> The reasons why an app wants to use an API, and how it intends to use/share data that it obtains from it, are things which we defined a way to express using W3C POWDER, and can be associated with the app through the HTML link element.

lgombos: on their mailing list
... something like .allowed / .enabled /

<AnssiK> Feature Permissions Playground demo on how to handle multiple permissions up-front: http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html

<dom> navigator.geolocation.enabled feature request

<dsr> [Note that WebAppSec WG are working on content security policies (CSP) where the browser is instructed to *remove* permissions. In the current session we are talking about *adding* permissions, so we should probably coordinate with WebAppSec]

AnssiK: at one F2F, I was asked to write a demo for this
... so you can say sensor implements permissions
... you can play with it
... and see if it feels right
... most of the time it doesn't feel right
... sometimes, it might be ok

<dom> [CSP removes permissions on cross-site operations, AFAIK, not on API usage directly]

AnssiK: if the UA asks up front "can I save 10mb of data"

darobin: am I hearing this might not be a model for all permissions
... but it might be useful for a subset of things?

AnssiK: yes, it's not a silver bullet
... in this group, we don't have many APIs that might work
... especially sensitive-user-detail-exposing APIs it'd be out of scope
... maybe Storage+Notifications
... but I don't like Notification Bars
... they don't feel right to me
... but it's the best we have

lgombos: the Notification UC is valuable
... perhaps your Gmail tab
... in your Gmail case, you want to be notified in your native environment
... that's where the action happens
... you're trying to get attention of the user
... perhaps it's only the notification API
... the challenge with Storage, it's a good example

<bryan> Link to the workshop where we presented the POWDER approach to app intent disclosures: http://www.w3.org/2011/track-privacy/ and our paper http://www.w3.org/2011/track-privacy/papers/ATT.pdf

lgombos: by the time you ask, maybe we have 10 mb
... but maybe someone else starts using it?

richt: I think it makes a lot more sense to access something
... and get permission at time of use

<richt> http://developers.facebook.com/docs/reference/oldjavascript/FB.Connect.showPermissionDialog/

richt: I want to point to Facebook
... specifically, Facebook Connect

Marcos: how many times have you read it?
... do you remember any of the things you've been given?

richt: I want to point out the precedent

darobin: Android does that as well

Josh_Soref: Sun's Java did that years ago -- they stopped!

sicking: there's interesting research
... it doesn't all say that it's terrible
... the research says what parts work and what doesn't work
... out of Berkeley

<Zakim> adrianba, you wanted to talk about testing

adrianba: I agree w/ a lot of what sicking said
... I want to pass on feedback we've heard
... a lot of developers don't want the explosion in the test matrix
... of testing their apps in different combinations of permissions

<Zakim> dsr, you wanted to relate this to the privacy and informed consent issue

<dom> Android Permissions Demystified , from UC Berkeley

dsr: when it comes to asking permissions of users
... I understand about usability research
... and respect that

<dom> Adrienne Porter Felt home page (one of the co-authors of said paper)

dsr: there's a more general issue of how web sites inform the users about what they do
... beyond the current point
... there's the issue of informed consent

sicking: a way for a site to indicate what features in say a manifest
... we have the open web apps proposal
... maybe submitted to W3C

darobin: I don't think so

bryan: I don't either

sicking: the idea is it's a manifest format
... for installation process for a web app

<dsr> Dave: very much respect the usability research on asking users for permissions, and we also need to factor in the need for informed consent - this is hard, but we have to address this.

sicking: when it's installed, doesn't give you much permissions
... we've talked about giving some permissions, but nothing actually sensitive

<dom> "we find that about one-third of [940 Android applications] are overprivileged. We investigate

<dom> the causes of overprivilege and find evidence that developers

<dom> are trying to follow least privilege but sometimes fail due to insufficient API documentation." -- http://www.cs.berkeley.edu/~afelt/Android_permissions.pdf

<dom> Widget Access Request Policy

<darobin> https://apps.mozillalabs.com/ -> Open Web Applications

sicking: we've talked about putting into that manifest a list of things that this app requests
... we've talked about putting in about whether it comes from a trusted source
... e.g. Amazon
... and letting Amazon say I trust this app to do these things
... so a page can express high privilege things

Josh_Soref: support Mozilla perspective, asking permissions upfront a disaster
... reminds me of Java approach
... Android installing app, or PlayBook, also doesn't work.
... BlackBerry says upfront but can continue without granting permissions

<dsr> [A further consideration is whether users are in a position to make an informed decision about trusting a site, sometimes people will prefer to delegate that to others they feel are in a position to provide effective advice. We need to consider the potential role of trust delegation.]

Josh_Soref: being able to use the app without granting permissions upfront is valuable
... do not want Java model of "try and die"

<dom> Nokia process to sign applications

Josh_Soref: goal is to always let app go on, maybe a picture won't be shown and there be a blank space, but better to continue

<dom> navigator.geolocation.enabled feature request

Josh_Soref: use of a non-blocking field is valuable, can see and/or change value, see context
... IRCCloud I use, it has notices
... give permission to enable pop up by system from inline notice
... give permission through action so no need for permissions

<dom> [a blog post of mine arguing for <input type="location"> back in 2008 http://www.w3.org/blog/MWITeam/2008/01/29/making_html_location_aware ]

Josh_Soref: lying also asks as an alternative to permissions

<bryan> Just because we have not found an effective UI for user informed consent, is no reason to either abandon effort to obtain informed consent (ignore the UI), or severely limit the Web in terms of the types of contextual data etc that can be used by apps. We have to solve the UI problem, and provide at least some user control, however ineffectual current models for that UI are or seem to be.

<bryan> On the point Josh_Soref made re exceptions, I disagree because exceptions (of a "not supported" or "security violation" type) allow the app developer to take fallback approaches in the catch handler. Taking the notice example, it would be important for an app to know that a notice was not given because the user decided to turn off notices, as that would give the app the ability to use another approach.

[ bryan makes a case for giving the app choice about fallback ]

fjh: to adrianba
... on testing permissions

adrianba: if my app asks for webcam, location, storage
... you're going to need to test the fallbacks anyway, right?
... there are 8 different combinations of yes/no for each combination

fjh: but at some point you're going to need to test if you don't get the camera

dom: if you have camera-storage-location yes/no
... then you have only two cases to test

fjh: so a batch is "simpler"

darobin: a lot of this hinges on how people write the code
... if you ask up front, the application takes a different path early, maybe a totally different app
... if you test in the flow, the logic of the individual case can be tested

adrianba: I started by saying that I agree with what sicking said
... but I was sharing feedback I was given

fjh: I don't see how we get express agreement
... you can't say action = consent

Josh_Soref: to expand on the location thing, I've had a lot of time think it through
... one could imagine that <input type=location> would be visualized via a map
... the browser could offer various level of granularity
... and update the map as you pick a place
... the browser could then offer to make the update to the map automatically
... the user then reacts based on the value she perceives

fjh: if that map provider sells my info, then consent needs to take into account notice about that, at the time of consent
... what to do when user has denied permission

sicking: several things
... we can do as Josh_Soref suggested, provide false data
... in general, we do things async
... so throwing isn't a risk
... we can never provide an answer
... which has the use of sites graying out until you answer
... it's a technical discussion on individual specs
... I do hear that,
... on adrianba 's concern on test matrix size
... but I'd like to allow UAs to be able to try
... if the alternatives are "allow all/none"
... or pick and choose
... I think the User would rather pick/choose
... on consent, it's not something we've talked about

<bryan> Re the comment on async APIs and exceptions, async APIs can include an error callback so even if exceptions are not returned, errors (e.g. security) can be provided to the app.

sicking: if we take the string from the page and show it in chrome UI
... users might think we're enforcing what the page claims
... at that point, we're risking the user only consenting to that
... if we formulate it so that the user understands what we claim to be doing

<dom> [FYI, Mozilla currently doesn't request permissions to show notifications IIRC https://developer.mozilla.org/en/DOM/Displaying_notifications ]

sicking: then that's better that the site is breaking the site's promise

<Zakim> richt, you wanted to talk about how we can enable trust decisions to be triggered within a web page. (RE: pop-out web notifications)

richt: I like Josh_Soref 's idea of escalating permissions
... you get the functionality, and you get something better

<bryan> Informing the user that data is intended to be used locally or sent to a server is specifically the intent of what we proposed with POWDER. The notice represents a contract with the user that can be tested.

richt: and we looked into that for getUserMedia()
... we allowed the video element to display data
... but we tainted the canvas
... and you had buttons to allow full access later
... you got a Head/Hair check
... the problem is ClickJacking
... but based on what Josh_Soref was saying
... the most intuitive cases
... being able to make trusted escalation permissions
... from in web pages
... we took a concept from DOM
... we wanted to tie a click event to a user's click
... if that event is synthesized, it won't work
... but for a trusted click, it works

fjh: you're not talking about trust between parties

richt: this is about escalating permissions from within a web page
... that's impossible w/ Click Jacking
... but we looked into it earlier on
... I just wondered whether we could solve some of those problems

fjh: is there an example?

richt: you have click events on specific objects
... if the user actually clicks it

Josh_Soref: use the file dialog

<dom> API Invocation via DOM Events in Contacts API

richt: the file dialog is the result of clicking on the UA styled element
... it's inserted into the Page
... and the User clicks on it
... then we can show that the user wanted to do this
... that would be really cool
... this is Escalation
... we could have popups in the page
... for popups, you may not need anything
... just mentioned that we have looked at it

<Zakim> dsr, you wanted to note that mechanisms to prevent clickjacking are being considered in WebAppSec that might help

richt: it's cool, but difficult

dsr: WebAppSec is looking at how to limit click jacking
... like limiting areas within the screen

<dom> [https://mail.mozilla.org/pipermail/WebAppSec/2010-August/000003.html talks about protection from clickjacking from third parties]

fjh: so, about this spec
... what are we going to do?

sicking: if it's just going to be used by notifications
... then I'd ask if it makes sense

dom: there's the aspect of asking about querying permissions
... I think that's less controversial

sicking: I think there's some controversy about that
... I don't know enough about it
... one place we do put up a prompt is for AppCache
... I know it's a model that isn't really working well
... and developers have been asking for things to make it easier to work with that prompt
... like "will that prompt show up if I try"
... another is "please forget that I had permission"
... I don't know if it makes sense in a generic API

dom: that could be defined out of bounds

<rigo> I think you should just record decisions/permissions and let the lawyers figure out what it means in their respective context/region

sicking: I don't know if it's better for the APIs to be together or spread across for querying/forgetting

Josh_Soref: Querying came up in GeoLocation this week (see dom's pointer) and I think it's an indication of a bad design

sicking: you can easily limit the API so that it only puts up a prompt during a click action
... we talked about only allowing file picker during a click
... we want ways of communicating to a page what will happen when an action is taken
... we can't design APIs perfectly to avoid certain dialogs

darobin: on queries
... datapoints relating to querying
... in the jQuery breakout on Wednesday
... one thing that surfaced very strongly
... is a desire to do feature detection

rigo: to define consent is difficult, as it's contextual e.g. by locality
... you can record the evidence that is later looked at to determine if there was consent
... so you could reduce to the technical decision where to record and how to save it for later

richt: we looked at where and how to record, so you could look back at what the API was doing, and for the %.001 of people who would do that, it would be useful
... and provide more transparency

fjh: what do we do next...? Dom had some good suggestions, and we need to do something now that we have talked about it
... anything we can do?

lgombos: one option is to continue to discuss, or to make a decision now re whether the generic API is something to pursue

dom: my take is Web Notifications gives an example, but is not a completely reusable way to do this. Rather propose including this in the design of the UI for each API.

fjh: is that there is another way to do notifications the way out of this?

sicking: have not figured out the way to do this for desktop yet

fjh: sounds like we are not ready to make a decision

sicking: mobile is likely different, as the whole screen is the page

dom: you get notifications in the bar at the top etc

bryan: we will end up with a continually shifting set of approaches if we drop this now

Josh_Soref: UIs are evolving, faster now, and having something specified may not be the answer - letting the UIs evolve may lead to a better solution

darobin: there is a difference between not addressing this API and not addressing security issues

<darobin> http://dl.dropbox.com/u/444684/notifications.html -> a demo of notifications that works in current Chrome and Firefox Mobile

dom: we've heard that querying permissions may be less controversial, but asking for permissions is something that browsers may not be ready to adopt

lgombos: we need more feedback from content providers

<fjh> dom notes adoption of requesting permissions in a bundle not clear

<fjh> we need more implementer feedback here

darobin: could we take this to the JQuery dev group etc and get their feedback, would that be useful

sicking: we are in research on this, the current thinking can be shared, but we don't know the UI that will result

<fjh> if this is a research topic is it premature for standardization?

fjh: we are looking for additional feedback

dom: robin's suggestion is good enough for that

<darobin> ACTION: Robin to take FeatPerms to ScriptLib to see if this is something that devs would be interested in, taking caveats from implementers into account [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action22]

lgombos: propose to provide the feedback from the discussion we just had to the notifications group

<trackbot> Created ACTION-479 - Take FeatPerms to ScriptLib to see if this is something that devs would be interested in, taking caveats from implementers into account [on Robin Berjon - due 2011-11-11].

<fjh> ACTION: laszlo to provide summary and request feedback from notification wg on feature permissions [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action23]

<trackbot> Created ACTION-480 - Provide summary and request feedback from notification wg on feature permissions [on Laszlo Gombos - due 2011-11-11].

dom: anyone interested in pursuing querying permissions?

<fjh> fluffy notes we should not confuse lying with errors, need to lie clearly

fluffy: there should be a discussion about the "lying" response or other such things, as they have cons
... or pros

lgombos: as editor happy to make changes as needed

dom: we are not ready to make changes
... need some look into how this has been done on other platforms

fjh: will look into that


<dom> ACTION: fjh to work with laszlo on looking at options for querying permissions across APIs, providing fake data, etc [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action24]

<trackbot> Created ACTION-481 - Work with laszlo on looking at options for querying permissions across APIs, providing fake data, etc [on Frederick Hirsch - due 2011-11-11].

<dom> Contacts API Editors draft

Josh_Soref: displays current contacts draft
... moved into DAP mercurial project

<darobin> https://wiki.mozilla.org/WebAPI/ContactsAPI -> Mozilla's Contacts work

<Josh_Soref> http://bitbucket.org/Josh_Soref/dap has my repo

Josh_Soref: showing version being edited
... looking at diffs

[ Can we wrap the diff on the screen? ]

<nvbalaji> Contacts is an excellent candidate for Intents

Josh_Soref: may have questions on the starting point for the edits
... attribute ContactName was removed, changing complicated objects into flat strings

<henri> Do we care (at all) about contacts? In the "cloud" era, there will be many online services that do this and anyone can write a web app that connects to them already. Just curious.

fluffy: Web RTC was assuming the ability to lookup a phone number, email address, IM address and then display the user's name. If you drop the fields does that make it easier to do phishing attacks?

Josh_Soref: the need to use all the dots to link the names of things in the object tree is wasteful

darobin: it's better for interop with VCard 4 to have a flatter set of attributes

fluffy: removing the type?
... how will you do IM schemes?

Josh_Soref: embedding a URI scheme into it etc have not been fully though out

bryan: you are taking away the ability to know family, business, groups, etc...? not a good idea

Josh_Soref: the freeform type doesn't help where the content is represented differently in different locales

+1 to richt

dom: you are dropping a feature vs. fixing it per bryan's comments

[ Josh_Soref displays Mozilla contacts API docs ]


fluffy: the suggestion for the problem is to create an enumerated list rather than dropping the field

fjh: we had extensive discussions about POCO etc, some are just cleanup other to features and not sure about the rationale

Josh_Soref: one approach is to drop it and take Mozilla's proposal

darobin: we build on POCO and in VCard 4 the data model has moved toward flatter structures which map better to this

dom: a proposal to change some of the design decisions need to be made so we can address each

nvbalaji: wondering why the API approach when Web Intents is being considered now

Josh_Soref: came late to this

darobin: as currently specified it is mostly about what does a contact look like, so most of the API would not change even with Web Intents

<dom> [I think we should probably highlight that point as an ISSUE in the document]

dom: suggest to add note re this may change with Web Intents

<Josh_Soref> ACTION: soref Contacts find() may be replaced with Intents [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action25]

<trackbot> Created ACTION-482 - Contacts find() may be replaced with Intents [on Josh Soref - due 2011-11-11].

<Zakim> fjh, you wanted to ask about interop

<Josh_Soref> ACTION: soref to send proposal to list for how Contacts will move forward [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action26]

<trackbot> Created ACTION-483 - Send proposal to list for how Contacts will move forward [on Josh Soref - due 2011-11-11].

fjh: assume an action to send a proposal to the list so we can find it - any additional key points?

Josh_Soref: some examples will go away
... address fields etc will flatten. things on the web will allow parsing the fields

bryan: I'd like to see a proposal
... individual fields are important
... not sure I trust ability to parse text fields reliably
... just wow. We need to review the things one by one

spoussa: about find, have a question. what is the spec status, should we address this now...

<darobin> [so quickly, off the top of my head, getting a contact from Intents would look like: navigator.startActivity(new Intent("pick", "text/vcard"))]

<fjh> we need to remember minimization in any change we make

<fluffy> Might be interesting to people …. vCard 4 spec is at http://tools.ietf.org/html/rfc6350 and XML representation of vCards are defined in http://tools.ietf.org/html/rfc6351

<darobin> [where "pick" is a generic action that would work for pick people, or dates, or files, or whatever can be shown as a list from which something is selected]

spoussa: based upon find, it defines the set you want, and the search filter is applied to that

<darobin> [and where "text/vcard" is a string that I made up that states the kind of stuff that one wants to pick]

Josh_Soref: user's can do anything with the number of fields that are in the spec
... have a proposal that might be sent...

spoussa: PhoneGap's implementation of this has gotten complaints of being broken

Josh_Soref: when you are searching, you want to find something that looks like something else. The user can fix the find filter when something unexpected is displayed.
... would like re different types of sections, display the whole card and allow to select the section that is to be returned.
... mostly the need to specify search fields goes away

dom: the current API gives the fields the app is interested in, and the user can choose

spoussa: the summary is something needs to be done for the find

[ Break until 3:35pm ]

<Josh_Soref> ACTION: spoussa to ask Phonegap users to send feedback on find() [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action27]

<trackbot> Created ACTION-485 - Ask Phonegap users to send feedback on find() [on Sakari Poussa - due 2011-11-11].

Josh_Soref: I will send some UI comments/ideas to the list when I have something I can share

Next F2F

dom: TPAC next year, Lyon, FR, dates announced?

<dom> next TPAC will be Oct29-Nov 2

<dom> in Lyon, France

fjh: we have a lot of European members
... March would be ...

<darobin> http://www.w3.org/mid/4E67BCFD.8070804@w3.org -> TPAC 2012 announcement

darobin: dates last year...

dom: Last year was Mar 15

fjh: where are we doing this?
... who could host?

dom: we tend to have between 30 and 40 participants at F2F

fjh: Seoul was 15

darobin: at lot of people canceled because of Fukushima

fluffy: IETF is Mar 25-30 in Paris

fjh: Not the week after (Easter and stuff)

jcdufourd: We could handle 40 easily unless it's during exams

darobin: we generally have one @ TPAC, and two intermediate
... since we're meeting in US now, and will meet in France
... it would be good to have one of these meetings in Asia
... I don't know if any of our Asian members would be interested in hosting

[ LG could host in Seoul ]

[ Huawei could host in China ]

[ probably in Shenzhen ]

[ Opera, possibly Oslo ]

darobin: preferably not March

dom: Next F2F roughly in March, seem reasonable?
... not the last week in March / avoid IETF meeting

fjh: June/July ?

<Josh_Soref> ACTION: dom to do a WBS for the next F2F for mid March [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action28]

<trackbot> Created ACTION-484 - Do a WBS for the next F2F for mid March [on Dominique Hazaël-Massieux - due 2011-11-11].

dom: to host a F2F, we need:
... seats, tables,
... no NDAs
... WiFi
... Breaks

darobin: there's a strict rule: we can't hold a meeting if we're required to sign a Strict NDA at a meeting


dom: There's a Web Testing IG
... and Browser Testing and Tools Working Group

<fjh> http://www.w3.org/2011/08/browser-testing-charter.html

<fjh> Testing interest group

<fjh> http://www.w3.org/2011/05/testing-ig-charter.html

AnssiK: I think the Mozilla Web API will arrange for testing for Battery

dom: there's a question about how to test battery for Hardware

AnssiK: they're looking at Qemu for Android

dom: Hardware testing is out of scope, right?

AnssiK: yes

<dom> ACTION: Dom to build test cases for battery [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action29]

<trackbot> Created ACTION-486 - Build test cases for battery [on Dominique Hazaël-Massieux - due 2011-11-11].

lgombos: testing, the problem is similar to GeoLocation

dom: I think what they've done is integrate positions into the tests

<AnssiK> testing hardware interaction on Mozilla dev-webapi: http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/dae263e27197f9a0#

dom: like "tell the position provider to say you're @X moving to Y"
... Testing IG is building a Generic Framework that most of WGs are expected to use

darobin: there's a harness and a bunch of other things


<darobin> http://www.w3.org/2009/dap/track/issues/open -> DAP Issues


<trackbot> ISSUE-81 -- How to represent dates? ES has Date but with no TZ information; using strings is less than ideal; do we have to create a Web Dates specification? -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/81


<trackbot> ISSUE-81 -- How to represent dates? ES has Date but with no TZ information; using strings is less than ideal; do we have to create a Web Dates specification? -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/81


<trackbot> ISSUE-87 -- Degree of ruleset transmission with API calls, how often, which -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/87

darobin: 81 is still pending

Josh_Soref: do we want to stop doing rulesets?

fjh: I'll leave it open


<trackbot> ISSUE-89 -- Clarify how rulesets interact with pre-existing relationships -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/89

fjh: let's close them, we can reopen them if we change our minds

close ISSUE-87

<trackbot> ISSUE-87 Degree of ruleset transmission with API calls, how often, which closed

close ISSUE-88

<trackbot> ISSUE-88 User interaction for ruleset confirmation when multiple APIs are used to provide functionality, usability etc closed

ISSUE-87: group isn't pursuing this at this time

<trackbot> ISSUE-87 Degree of ruleset transmission with API calls, how often, which notes added

close ISSUE-87

<trackbot> ISSUE-87 Degree of ruleset transmission with API calls, how often, which closed

ISSUE-88: group isn't pursuing this at this time

<trackbot> ISSUE-88 User interaction for ruleset confirmation when multiple APIs are used to provide functionality, usability etc notes added

close ISSUE-88

<trackbot> ISSUE-88 User interaction for ruleset confirmation when multiple APIs are used to provide functionality, usability etc closed

ISSUE-89: group isn't pursuing this at this time

<trackbot> ISSUE-89 Clarify how rulesets interact with pre-existing relationships notes added

close ISSUE-89

<trackbot> ISSUE-89 Clarify how rulesets interact with pre-existing relationships closed

ISSUE-89: group isn't pursuing this at this time

<trackbot> ISSUE-89 Clarify how rulesets interact with pre-existing relationships notes added

ISSUE-95: group isn't pursuing this at this time

<trackbot> ISSUE-95 Different regulatory environments and relationship to privacy and rulesets notes added

close ISSUE-95

<trackbot> ISSUE-95 Different regulatory environments and relationship to privacy and rulesets closed


<trackbot> ISSUE-105 -- Should the capture hint in HTML Media Capture be specified through a MIME parameter? -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/105

ISSUE-105: waiting for implementers

<trackbot> ISSUE-105 Should the capture hint in HTML Media Capture be specified through a MIME parameter? notes added


<trackbot> ISSUE-109 -- We need solid use cases for Feat Perms if it's going to fly -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/109

ISSUE-113: we resolved this by changing the design

<trackbot> ISSUE-113 AddEventListener in Battery Status has side effects notes added

ISSUE-114: we resolved this by changing the design

<trackbot> ISSUE-114 Battery spec should note relative ordering of battery low versus battery critical in terms of criticality notes added

ISSUE-115: we resolved this by changing the design

<trackbot> ISSUE-115 Do you get the batterylow event when you're charging and cross that boundary? notes added

close ISSUE-113

<trackbot> ISSUE-113 AddEventListener in Battery Status has side effects closed

close ISSUE-114

<trackbot> ISSUE-114 Battery spec should note relative ordering of battery low versus battery critical in terms of criticality closed

close ISSUE-115

<trackbot> ISSUE-115 Do you get the batterylow event when you're charging and cross that boundary? closed

darobin: the other issues are still relevant



<trackbot> ACTION-315 -- Dominique Hazaël-Massieux to look into pop-up windows in Permissions draft -- due 2011-05-11 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/315

<dom> [context of permissions for pop-up is http://lists.w3.org/Archives/Public/public-device-apis/2010Dec/att-0039/minutes-2010-12-15.html#item03 ]

close ACTION-340

<trackbot> ACTION-340 Look at how we're doing privacy by design closed

close ACTION-359

<trackbot> ACTION-359 Split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo closed

Josh_Soref: oops, ACTION-360 has an ACTION-444 for me to follow up

<darobin> ACTION: Robin to issue a CfC to shelve SysInfo [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action30]

<trackbot> Created ACTION-487 - Issue a CfC to shelve SysInfo [on Robin Berjon - due 2011-11-11].

ACTION-364: characterization of the open web

close ACTION-364

<trackbot> ACTION-364 Get the COW started notes added

<trackbot> ACTION-364 Get the COW started closed

close ACTION-368

<trackbot> ACTION-368 Collect and summarize current use cases for Gallery API and includes a draft doc closed

close ACTION-370

<trackbot> ACTION-370 Dive more deeply into Web Intents/Web Activities in view of integration closed

ACTION-374: group isn't pursuing this at this time

<trackbot> ACTION-374 Complete Privacy Rulesets with binding considerations notes added

close ACTION-374

<trackbot> ACTION-374 Complete Privacy Rulesets with binding considerations closed

close ACTION-413

<trackbot> ACTION-413 Contact Claudio Caldato from MS and discuss media capture closed

ACTION-413: Travis has an action to come back with UCs

<trackbot> ACTION-413 Contact Claudio Caldato from MS and discuss media capture notes added

AnssiK: can we close http://www.w3.org/2009/dap/track/actions/414 given that Microsoft is now looking at Media Capture?

close ACTION-414

<trackbot> ACTION-414 Write up an overview of the media capture landscape, with ideas of how to move forward closed

ACTION-414: AnssiK is happy to close since MS has interest

<trackbot> ACTION-414 Write up an overview of the media capture landscape, with ideas of how to move forward notes added

close ACTION-423

<trackbot> ACTION-423 Draft the use cases and requirements section for Battery closed

ACTION-423: we have UCs

<trackbot> ACTION-423 Draft the use cases and requirements section for Battery notes added

ACTION-424: might want to apply to Intents UCs

<trackbot> ACTION-424 Draft the use cases and requirements for Messaging, perhaps even take over Messaging editing notes added

ACTION-425: We expect input from adrianba, sicking, Josh_Soref

<trackbot> ACTION-425 Incorporate feedback for NetInfo, draft use cases and requirements section notes added

close ACTION-426

<trackbot> ACTION-426 Draft the proposed design of getting rid of battery{low,critical} and adding a field that indicates state=ok/low/critical closed

ACTION-425: see ACTION-475 ACTION-476 ACTION-474

<trackbot> ACTION-425 Incorporate feedback for NetInfo, draft use cases and requirements section notes added

ACTION-426: drafted, but change dthe design

<trackbot> ACTION-426 Draft the proposed design of getting rid of battery{low,critical} and adding a field that indicates state=ok/low/critical notes added

close ACTION-428

<trackbot> ACTION-428 Make a proposal for a common Address interface for Geo/Contacts that keeps Contacts aligned with PoCo, provides a base class, shows how Geo could derive on its side closed

ACTION-428: Neither group was interested in alignment

<trackbot> ACTION-428 Make a proposal for a common Address interface for Geo/Contacts that keeps Contacts aligned with PoCo, provides a base class, shows how Geo could derive on its side notes added

close ACTION-431

<trackbot> ACTION-431 Review Messaging for publication closed

ACTION-431: that was done

<trackbot> ACTION-431 Review Messaging for publication notes added

close ACTION-433

<trackbot> ACTION-433 Reply to Anne about his Permissions questions closed

ACTION-433: lgombos: I spoke to anne and there's a new action from today

<trackbot> ACTION-433 Reply to Anne about his Permissions questions notes added

close ACTION-434

<trackbot> ACTION-434 Investigate if DAP could use the XPointer registration code for feature registration closed

close ACTION-450

<trackbot> ACTION-450 Get his CVS working; or migrate specs he might patch to Mercurial closed

close ACTION-452

<trackbot> ACTION-452 Work with Josh on a proposal for Contacts names closed

ACTION-450: Contacts was migrated to Mercurial

<trackbot> ACTION-450 Get his CVS working; or migrate specs he might patch to Mercurial notes added

close ACTION-455

<trackbot> ACTION-455 Reply to ArtB about Web Intents closed

ACTION-452: this was done

<trackbot> ACTION-452 Work with Josh on a proposal for Contacts names notes added

close ACTION-460

<trackbot> ACTION-460 Send cfc for FPWD for vibration closed

close ACTION-456

<trackbot> ACTION-456 Write to the list to explain UA mediation in selecting sensors closed

ACTION-456: this can probably be resolved by Intents, but I can explain this to the list

<trackbot> ACTION-456 Write to the list to explain UA mediation in selecting sensors notes added

Next Steps

darobin: do your action items

fjh: no meeting next week

darobin: we already cancel the week after a F2F

[ heads up, clocks are changing in the US this Sunday early morning, in case you're still here then ]

darobin: please spend some time looking at Intents
... thanks to the editors and people who provide feedback
... and to scribes

[ Applause ]

darobin: Please pay attention to the announcements about the creation of new mailing lists
... because things will be moving to them shortly
... thanks for coming
... see you on the phone
... see you in March in person

[ Applause ]

Summary of Action Items

[NEW] ACTION: Adrian to make a proposal for Network Information API [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action17]
[NEW] ACTION: berjon to ACTION: sicking to propose a new Network Info [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action19]
[NEW] ACTION: berjon to draft a joint TF proposal with WebRTC [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action06]
[NEW] ACTION: berjon to follow up with Alex Russell on getting an example of sensors on Intents. [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action07]
[NEW] ACTION: berjon to look into a document for Security Principles for API Design [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action14]
[NEW] ACTION: darobin to draft a joint TF proposal with WebRTC [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action05]
[NEW] ACTION: dom to make proposal for proximity and ambient [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action10]
[NEW] ACTION: Dom to build test cases for battery [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action29]
[NEW] ACTION: dom to do a WBS for the next F2F for mid March [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action28]
[NEW] ACTION: fjh to send cfc for FPWD for vibration [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action02]
[NEW] ACTION: fjh to update policy requirements for security requirements [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action15]
[NEW] ACTION: fjh to update web application privacy best practices related to active consent [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action13]
[NEW] ACTION: fjh to work with laszlo on looking at options for querying permissions across APIs, providing fake data, etc [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action24]
[NEW] ACTION: jcantera to present use cases for the Sensors API [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action08]
[NEW] ACTION: jcantera to update Sensor's API based on feedback, implementation, etc. [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action09]
[NEW] ACTION: laszlo to provide summary and request feedback from notification wg on feature permissions [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action23]
[NEW] ACTION: richt to submit UCs [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action04]
[NEW] ACTION: Robin to coordinate with fjh on the production of a "General Security Principles in Web APIs Design" Note [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action16]
[NEW] ACTION: Robin to draft TF charter for Intents [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action20]
[NEW] ACTION: Robin to issue a CfC to shelve SysInfo [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action30]
[NEW] ACTION: Robin to look as Mozilla Labs Sharing experimentation re Messaging API [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action11]
[NEW] ACTION: Robin to make a CfC for shelving Messaging [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action12]
[NEW] ACTION: Robin to take FeatPerms to ScriptLib to see if this is something that devs would be interested in, taking caveats from implementers into account [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action22]
[NEW] ACTION: Robin to wirk with ArtB, agree on mailing-list name (public-Intents?) [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action21]
[NEW] ACTION: Sakari to draft a proposal for a threshold parameter for Battery events [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action01]
[NEW] ACTION: soref Contacts find() may be replaced with Intents [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action25]
[NEW] ACTION: soref to propose a new Network Info [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action18]
[NEW] ACTION: soref to send proposal to list for how Contacts will move forward [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action26]
[NEW] ACTION: spoussa to ask Phonegap users to send feedback on find() [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action27]
[NEW] ACTION: Travis to submit UCs [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action03]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $