SV_MEETING_TITLE -- 11 Apr 2013

<gmandyam> Mounir: WebIntents dependency on two-way messaging between to open webpages results in UI problems.

<gmandyam> jungkee: I think Sysapps should work with DAP/WebApps to come up with use cases, and similar property names, with respect to Contacts.

<JonathanJ1> Scribe: gmandyam

<JonathanJ1> ScribeNick: gmandyam

Suresh: From a W3C perspective, we don't want to have two different API's for the same functionality. DAP specs are not frozen, so we can collaborate between the two groups and not confuse developers.

eduardo: (Presenting SysApps Contacts API) The basis of this draft is the FF OS Contacts API.
... (Presenting SysApps Contacts API) ContactsManager has the following methods: find(), clear(), save(contact), remove(contact). There is also an oncontactschange event handler.

<mounir> mounir: (to summarize) SysApps should rely on Web Intents or a similar mechanism to happen but we do not know if this is going to be exactly the same. Web Intents have been stopped for UI issues and those UI problems do not all apply in the current usage of Web Activity (apps + mobile). While meeting Google, we found some solutions but those issues being UI related, we need to experiment. This is why it is taking so long. The main problems are related to t[CUT]

Zoltan: There is an assumption that there is only one address book in the system. Why this limitation?

eduardo: We don't have a requirement to deal with multiple address books.

<JonathanJ1> http://contacts-manager-api.sysapps.org/

<JonathanJ1> http://www.w3.org/TR/2012/WD-contacts-api-20120712/

<scribe> ScribeNick: gmandyam

zoltan: Remove the constraint of a system address book and this could make the API more flexible.
... Implementation can keep track of origins.

eduardo: What do you think of dsr's suggestion of a partial I/F?

zoltan: We still need appropriate notifications when contacts change.

chris: How about a 'service ID' field in the contact?

zoltan: The contacts manager will now be managing all the stores.

thinker: I am concerned about properly identifying the origin of contacts derived from multiple sources. Will a 'service ID' be sufficient? Do the different contact sources provide consistent fields?

zoltan: I believe the API is sufficient with an origin field, but a partial I/F could be necessary for prioritizing contact stores, discovery of available contact stores.

<scribe> ScribeNick: gmandyam

Josh_Soref: I wonder about the usefulness of this API. As Chris stated, it is expected that only one privileged app will be managing contacts through this API. I believe all apps who require contacts info can speak directly to the contacts manager app.

zoltan: That could be done via a Web Intents mechanism.

Sakari: How does this work with a hybrid implementation of Contacts API (part native, part web layer) like Tizen?
... How does a native contacts manager get integrated into such a mechanism?

<mounir> mounir: (scribing what I said earlier): we should be careful in allowing any implementation to extend an API by using a magic string like serviceID. If tomorrow we have an implementation that allows you to use Facebook APIs by using serviceId='facebook', you might require everyone to implement this. It would be added to the Web Platform. We could imagine content that uses the same interfaces but not any implementation to plug anything in the Web Platform.

Josh_Soref: If a Web Intents feature becomes popular, then all web apps should be expected to use it.

<mounir> mounir: (scribing what I said earlier): I would like to see applications like Twitter or Facebook that would provide an address book and applications could access it, a way or another - which would need to be defined.

<zkis> @mounir: you don't standardize the serviceId's, so you don't mandate implementing magic strings

<zkis> the value of serviceId is implementation specific

Sakari: We have a problem in that we have a native access to a contacts DB, and we need to provide a non-native (web way) to access this DB in absence of a privileged contacts manager app.

Josh_Soref; You will need to implement a privileged contacts manager app.

<zkis> it is unique in the device, but not globally unique

Sakari: Contacts API is how we solve the problem.

Josh_Soref: I don't see the use case for having multiple contacts applications managing a single store.
... I don't believe specific implementation issues should drive the API requirement.

Chris: It may not be just management of the store - it could also be synching.

Josh_Soref: Do you really want multiple apps doing simultaneous synching? It would be better to have a single app handling synching on behalf of all other apps.

<gmandyam_> Josh_Soref: Every native system has a way of a single app providing notifications to subscirbing apps. We would have to define an API for broadcasting 'mutations'.

<gmandyam_> Mounir: We (Mozilla) want this API, and Tizen (Intel) wants this API (Contacts API).

<Zakim> anssik, you wanted to note that DAP hashed out the same issues two years ago

<anssik> AK: The same discussion happened in the DAP working group two year ago. You (esp. the editors) may want to take a look at the now obsoleted version of the Contacts API and Contacts Writer API from DAP for inspiration, use cases, security and privacy considerations etc.

<anssik> http://www.w3.org/TR/2011/WD-contacts-api-20110616/

<anssik> https://dvcs.w3.org/hg/dap/raw-file/default/contacts/Writer.html

<anssik> AK: The DAP proposal used a concept of 'categories' -- think them as tags/labels associated with each Contact object.

<mounir> ScribeNick: dsr

SC: there was a concern that the web would be forced to implement the contact API, but that isn't the case.
... we have common use cases to manage contacts in multiple places, and a service id would be valuable for distinguishing the source of the contact.

<Zakim> mounir, you wanted to ask what the hybrid mode changes exactly

ML: asks Chris to explain how the Tizen hybrid implementation effects the API.

<jplyle> ML: DO native applications access contacts through an API too? Chris: yes.

CD: we need to make contacts consistent, I want to change the remove method to use an id instead of contact to match other APIs

<chris> https://github.com/sysapps/contacts-manager-api/issues/9

AK: Cordova have implemented the DAP contacts API and wonder if you have any developer feedback to share with us, and has this resulted in any changes?

<anssik> http://docs.phonegap.com/en/edge/cordova_contacts_contacts.md.html

FM: It is based upon the DAP spec from 2 years ago. Not much feedback, some problems on deletion and changing category labels. The common usage is querying.

AK: do you expose contacts from Facebook or twitter through this API?

FM: I would need to go back and check.

EF: continuing with the review of the spec, looking at section 8 (ContactField)

CM: I sent an email on the list and don't think we reached an agreement. I would like to change the type field which currently holds both the marker for a preferred address and type of contact address based upon VCard.

<jplyle> ML: DAP was using a boolean.

It would be better to split them, and I am in favour of a boolean.

<mounir> type: ["home", "pref"]

<mounir> value: "foobar"

ZK: technically, the field is a set of tags.

<jplyle> Josh: How do you have a PREF=home and a PREF=work in the current system? Where is PREF? Chris: VCard does not restrict it.

SC: the use case for PREF is to simplify dialing for the user by avoiding having to pick from a set of addresses.

<jplyle> ML: Should we copy what DAP is doing for this? It makes things simpler to understand. Boolean for Pref. Two entries: one for voice, one for text. The application can merge entries.

[ Discussion centers on moving PREF into separate boolean attribute.

<jplyle> EF: I'm fine with moving PREF to a separate attribute. ] Differences in versions of vCard - not the only change. PREF has been added to a number of additional fields.

ML: we should look at how this was handled in DAP.

<wonsuk> I add alignmenet issue with DAP WG to GH

<wonsuk> https://github.com/sysapps/contacts-manager-api/issues/10

EF: most of the implementations are not VCard 3, but instead VCard 2.1

<anssik> for pref support by platform, search "pref" at: http://docs.phonegap.com/en/edge/cordova_contacts_contacts.md.html

<chris> https://github.com/sysapps/contacts-manager-api/issues/11

FM: On Android, always false as PREF is not supported. Windows phone would have it.

ML: most people these days have more than one phone number, so PREF is valuable?

<jplyle> JS: What happens when I try to set PREF to true on Android?

Answer no effect.

<jplyle> JS: Assuming that you decided not to support PREF, would you do it such that when you tried to write to PREF you could find out that it didn't do anything?

<jplyle> JS: An event should be fired? Listening for the absence of an event is hard :)

You could listen for the contact changed event...

ML: lets open an issue on splitting PREF off to a boolean and keeping type as an array

<jplyle> CD: Only one element in the array must be marked as PREF

SC: does the contact manager enforce that there is only one address marked as preferred.

answer yes [but it's underspecified how that happens, and if you discover that it happened ]

<jplyle> ZK: It is not possible to unmerge merged contacts. Type field would help?

<jplyle> ML: Doubt the spec will allow this.

ZK: what if the user is allowed to put whatever he likes?

<Zakim> mounir, you wanted to ask why we want to follow vcard so much

Josh: can the user put home and work together into the type field?

<jplyle> Add an example to show that you can select both home and work

ML: yes, that would be fine.

<jplyle> ML: Why was following vCard so important?

ML: why is VCard compatibility so important?

Chris: a lot of work on standardization has already been done, and we believe that compatibility is important for merging.

<jplyle> ML: Could imagine a tool to transform objects TO vCard?

ML: this draft follows Vcard for naming, even when it is not needed [except for the Name field which is 'fn' in vCard].

<jplyle> ML: vCard was tried to be followed even when unnecessary? Even though suggested by Mozilla.

Chris: adr for address is very confusing for example.

<jplyle> ML: Should be able to export to vCard, but following the API exactly is a bad idea. "Because vCard is doing it" is a bad idea

ML: the rationale is when you want to import and export contacts.
... so long as you can map correctly between this and VCard, that is sufficient.

<jplyle> JS: Is there a round-tripping requirement from vCard to internal back to vCard?

Josh: is there a requirement for round tripping without loss?

Suresh: loss will be inevitable in some cases.

ML: I don't believe we have a requirement for lossless round tripping

<jplyle> EF: In some cases, if we don't follow the same name, import and export wont work/ Birthday is straightforward, but 'name' is harder - Pick/vCard/Other APIs have different semantics.

EF: I compared the Mozilla definition and VCard and had quite a bit of trouble

<timeless> Josh_Soref: +1

ML: we should have a requirement for how the fields map to VCard.

Marcos: we could do this as an informative spec

Suresh: yes, we could have this as a table in an appendix

<jplyle> In who's interest is it to follow vCard? JS: No user will actually use it.

Josh: 99% of people haven't read the VCard spec and won't want to

ML: can we state that we are trying support import and export to VCard, but not lossless roundtripping.

Suresh: there will be compatibility but not 100%

<chris> https://github.com/sysapps/contacts-manager-api/issues/12

<Zakim> Josh_Soref, you wanted to say "because tantek demands it"

<Zakim> anssik, you wanted to ask if vCard export via this API is an UC we want to support, if not, we can simplify

AK: do we want to support a use case for vCard export?

Marcos: do we want to make import/export to vCard part of the API?

ML: no.

EF: I am fine with the change of PREF to a boolean, but want to also allow it in type for now.

Chris: you also don't support type for those fields

<jplyle> Chris: I've never seen a carrier follow it.

<jplyle> ML: FirefoxOS Will because Telefonica asked for it.

<timeless> Suresh: how do you find it out?

EF: customers want to find out what the carrier is for a given number

<timeless> chris: you often cannot

<timeless> scribe: timeless

marcos: that's ok

chris: this you won't be able to export to vCard

mounir: you wanted to have `origin` in vCard

gmandyam: there are extension fields in vCard for Twitter

chris: there's so reason to export the origin

mounir: you have a valid point that you can't export this (carrier)

chris: i'm sure there's some UC

eduardo: for an operator, it's important

chris: there will be a UI

marcos: i see a lot of people very concerned
... in Portugal
... I can see them importing this data themselves
... caring if it's on Vodafone or Telefonica

mounir: in Brazil
... a lot of users have more than one plan
... and depending on the people, they'd call on different phones
... or multisim
... using specific sim

chris: you can already store this in the `type` field

mounir: storing that in the type
... is losing the real information
... you have no idea it's a carrier
... you have to know that the second item in the array is a carrier
... it could be a blob/picture
... i would listen to the fact, that this could actually be saved
... but you can't have the info in all contacts application
... if you have two contacts applications, they should both share

Josh_Soref: US calling plans also discriminate by carrier
... but in NAm, people change carrier randomly -- why not have the carriers provide an API to look up carrier by phone number? -- this exists in NAm [partially for number portability], and i believe there's DNS like system that operators use for this anyway]

lgombos: i'm assuming a lot of solutions assume you're connected to the network

Josh_Soref: i'm concerned that the information will be stale

gmandyam: is any application allowed to set this value, or only privileged?

chris: we don't have per-field permissions

gmandyam: is the intention that any app with write permissions to have this

mounir: you can do way more nasty stuff
... you could remove, change the number, replace it w/ a fee-number
... there's no mention of permissions for the api

gmandyam: there's a permission model for this in the runtime security spec

Suresh: on the carrier field
... it's sort of almost tying it to a service
... without that, it's almost useless
... i don't think systems have this built in
... does it fit into the 80-20?

chris: the user could enter the value in the phonebook

<anssik> [I added a suggestion to vCard import/export issue : "To clarify, we should mention in the spec that a vCard import/export API is out of scope as parsing and serializing can be efficiently done in JavaScript, and libraries are readily available." added to https://github.com/sysapps/contacts-manager-api/issues/12 ]

<dka> http://www.gsma.com/technicalprojects/pathfinder/pathfinder-services/number-portability-discovery-service

dcheng3: there's 411.com

<chris> https://github.com/sysapps/contacts-manager-api/issues/13

Marcos: it's weird having an object that extends a field
... can it be merged back in

chris: Carrier isn't specific to ContactField
... it's specific to the ...

Marcos: can we merge this stuff together
... every time you add something, you add it to the Window object
... you have this `contact thing`

Suresh: putting it in the type field makes sense

mounir: more general issue of not polluting the window scope w/ objects

<chris> https://github.com/sysapps/contacts-manager-api/issues/14

Suresh: where does this fit in the 80-20 rule?
... or is it a corner case

anssik: can you provide a couple of UCs that are the most valuable

eduardo: the main UC is user knowing the carrier of a contact
... because it affects carrier billing for connections

Suresh: but if you aren't relying on a service
... and it's just me relying on the user, i could put it in the note field

eduardo: but that's not standard, if there's a standard, you can build a UI around it

anssik: can you expand on the charging

eduardo: it depends on the region and operator
... many charging plans are linked to the carrier of the callee
... a plan w/ unlimited minutes to users on the user's carrier
... but a pay-per-minute for other plans

anssik: is this sufficient?

Josh_Soref: does the user know which plan they're on?

chaals: in lots of the world where this is an issue, users do know which plan they're on

anssik: is the real question "how expensive is this"?

mounir: we don't have that

anssik: i'm wondering if charging is the UC

mounir: calling Orange is 2x calling Vodafone

chris: isn't the question
... are you going to have several phone numbers for the same contact

chaals: yes

eduardo: but they have multiple sims

chaals: the api for charging info doesn't exist
... you have 4 sim cards
... you have so many minutes by next tuesday

dcheng3: I'm asking people at our company

eduardo: "MoviStar" is the Telefonica brand
... the billing plan is 100 pages

lgombos: i understand the UC
... i'm not sure it's the right abstraction

mounir: i want to move on

lgombos: i disagree

<eduardo> http://contacts-manager-api.sysapps.org/#idl-def-ContactAddress

eduardo: type includes pref [same issue as before]

chris: wouldn't it be useful to have GPS coords for the address

gmandyam: no
... GeoLoc v2 had a reverse api
... and they shelved it
... because there was no demand

mounir: if you're not online?

gmandyam: developers can do it themselves

chris: not a big deal

mounir: seems like a good UC to me
... i don't see how you have GPS application working

chaals: device can know where it is
... but not have a network connection

chris: offline routing is rare

mounir: it exists in the car

gmandyam: i understand what you're saying

<mounir> ContactProperties interface

eduardo: most are dom strings
... things requiring Type are ContactField
... tel is ContactTelField [this is the Carrier object]
... the others are ContactAddress
... birthday, anniversary are dates

Josh_Soref: what about date of death?
... I have to go to their gravesite
... or not want to write on their facebook wall
... or go to synagogue

chris: on naming
... name i agree
... (except fn)
... but `adr` for address
... and `org` for organization
... `bday` for birthday
... `adr` isn't readable
... vCard isn't meant to be developer facing
... it's a serialization format

eduardo: for things related to name except fn, we should
... stick to vCard

chris: it's a serialization format

<mounir> Interesting doc regarding internalionazitaion naming: http://www.w3.org/International/questions/qa-personal-names.en

<thinker> https://wiki.mozilla.org/WebAPI/AppDefinedTeleophony#Contacts_API

<gmandyam> gmandyam: Last year the Geolocation WG rejected adding reverse geocoding (mapping of lat/lon to address) in the API due to lack of developer demand. Having geocoding (mapping of address to lat/lon) in the Contacts API would seem to also lack developer demand.

<chris> a+

thinker: we have we don't include Facebook/Skype in this interface

chris: `impp`

mounir: impp can be type `twitter`, value {twitter-handle}

thinker: we know how to handle a phone number or sip
... but a new service, we don't know how to handle that
... i think we should add an activity name in the contact field
... so we could later call skype to handle it

chris: you could do an intent call
... pass the impp and the system would resolve it

mounir: if you add info that will know how to call it
... the user unlikely knows more about the system
... the user is writing that stuff
... if you write an activity name, the user would have to know that

thinker: you add a new friend in skype
... you want to add that in your contacts
... when you add the friend in skype
... skype would ask the contacts application to add this

chris: you can use impp

thinker: but how does the contacts know how to call the impp

mounir: i believe this is an orthogonal problem
... how to call
... is outside this api's scope

chris: (i agree, [ the Intent or similar api can handle this w/ the impp field ])

Suresh: if you look at Address, there's an object
... but for name, it's flat
... if you take the 5 or six attributes
... either you make everything flat of everything objects
... whereas the others are objects
... for name, you don't need the five flat things
... for Sex/GenderIdentity, do we really need this?

chris: +1
... what are the values for GenderIdentity

mounir: i see the UC of this

chris: that's 80%
... San Francisco

Josh_Soref: what's the UC for having this in the address book

chris: what's the UC for having this in the address book

mounir: good example of trying to check what vCard did, and why

<chris> https://github.com/sysapps/contacts-manager-api/issues/17

mounir: i'm pretty sure for naming they did good a job

[ scribe coughs ]

Suresh: the gender might be unknown

<chris> https://github.com/sysapps/contacts-manager-api/issues/18

Suresh: you have a friend, he's a man, but would prefer to be something else

sicking: i don't think anyone in this room has an answer

mounir: some people might have different values
... but i don't know a UC for using it

eduardo: it's a corner case
... for the majority of people, it's not important

Josh_Soref: why is it a domstring and not an enum?

mounir: good point
... we should check more what it means
... if sex is biological, then there aren't that many

<Zakim> mounir, you wanted to ask what anniversary is

mounir: but for gender identity, i don't know how many there might be

<wonsuk> ?q

Josh_Soref: for men, they need to remember this to send flowers to their wife

chris: for address, nickname, they should use plural form
... when they're arrays

Josh_Soref: +1

Suresh: for pick contact, we tried to use plural
... to be very clear

gmandyam: back to impp
... we're rejecting all extension fields?
... because there are im-service-specific extension fields for vCard
... that are widely used
... that could be used instead of impp

mounir: as long as impp can cover the UC, i don't see why

<Suresh> Strongly recommend looking into Pick Contacts for the naming of attributes

chris: vCard supports extensions, and some are widely used

mounir: as long as you can import/export

gmandyam: some are used widely

chris: they are used widely, i agree

Josh_Soref: sex has "U" ....

<chris> https://github.com/sysapps/contacts-manager-api/issues/20

<anssik> AK: extensions to the schema were discussed in DAP too, please refer to the links I provided earlier

mounir: clearly a case where we shouldn't follow vCard, it was saving bytes

chris: it should be readable strings

eduardo: whether something is readonly or not

<chris> https://github.com/sysapps/contacts-manager-api/issues/21

Josh_Soref: are there places in the world where `readonly` is spelled as such?

Suresh: can you collapse contact and contact properties

<jplyle> Regarding gender/sex fields, this has been discussed with relation to vcard4 here: http://www.ietf.org/mail-archive/web/vcarddav/current/msg01784.html

mounir: this was done to construct an object

<lgombos> Josh_Soref - see HTMLInputElement.idl: [Reflect] attribute boolean readOnly

<anssik> http://www.w3.org/TR/html5/forms.html#attr-input-readonly

<mounir> Contacts Interface

sicking: that doesn't actually do what you want

Marcosc: it's worse than that

mounir: what's the UC for readOnly
... say i have google contacts
... and i'm taking them and want to leave google

chris: the serviceid
... since the spec says it's a system address book
... originally this was for SIM contacts

mounir: i think we should drop it unless there's a UC

<chris> https://github.com/sysapps/contacts-manager-api/issues/22

chris: why isn't the ID nullable?

eduardo: you get an id...

chris: why isn't the ID from when you call save()

eduardo: id is created when you create the contact

chris: but it isn't saved yet

Marcosc: the algorithm it isn't defined in the spec

chris: there's an algorithm
... there was a need to have it
... and we wanted to export as vCard
... and we needed to have a unique-id
... but we don't have vCard
... what about lastUpdated
... is it when it's created or when it's saved

mounir: it could be modification time

chris: we want to know the last time it was saved
... not the last time it was updated
... name is one thing, as long as it's clear
... does it need to be Nullable?

mounir: if it should be creation time

chris: if you want creation date
... then we want another field for saved time

[ goes around in circles until mounir gets it ]

Marcosc: algorithm doesn't define when `id` is calculated

chris: when you call the constructor, those fields should be null
... and we should define a default value

Marcosc: i can't find the steps for when you call the constructor
... there should be an algorithm to

chris: please file this one, i'm filing the other

mounir: ContactRequest becomes DOMFuture

<chris> https://github.com/sysapps/contacts-manager-api/issues/24

<mounir> ContactsChangeEvent Interface

eduardo: three arrays: added, modified, removed

Josh_Soref: how does anyone know that this is an id (without reading the spec)?

chris: did that change?
... i thought the two others were full contact objects
... since usually the application wants to retrieve them
... to update the ui
... and i don't think we even have fetch by id

mounir: good reason to pass a contact object is that for removed, there's no way to get it back

sicking: that should be obligation of application to retain

mounir: ...

sicking: we don't want to construct all these objects when we're deleting a lot of them
... i agree that it's more work for the implementation

mounir: you'd need to store all contacts in the application, to use this

sicking: what's the UC?

Marcosc: accidental delete - undo?

mounir: if you want to be notified that something has been removed
... either pass the full contact, or a `things changed`

chris: another app might remove contacts
... and you might want to update your ui
... and you want to stop showing it
... but for added/modified, you want to use the objects

sicking: we should have fetch-by-id
... if the implementation has to do a lot of work
... we could make added/removed domfutures
... but that's not friendly

chris: with your current model
... each application will have to fetch the objects

sicking: is it separate events for added/removed?

chris: if you have several listeners, then the perf is worse

sicking: knowing when we have extra work/when we're saving work

chris: you're never just interested in the id
... either you don't care, or you want the contact

sicking: i'm not entirely convinced

mounir: why do we have this in batches?

chris: because the backend might do batches

mounir: it isn't very common

eduardo: the database can change for synchronization

chris: synchronization can change for a lot of events

mounir: it's clear you save 5 events when you do a sync

chris: for sync it is
... we had issues w/ native sync
... where the web app gets hundreds of events and freezes for a while

mounir: i wonder if modify should happen
... you can listen to contact change on the manager
... you get event for every change
... you might just want only adds
... or modifying specific contacts
... we should at least have modify events on contacts

chris: there are some UCs where you want it on global

mounir: but contact should be useful
... 2 issues
... split this into 3 events
... add, modify, remove
... still a batch, but 3 events

<chris> https://github.com/sysapps/contacts-manager-api/issues/25

sicking: what's the advantage of splitting?

mounir: you can choose not to listen for add or for modify or remove
... withdrawn
... add modify event to contact interface

eduardo: do we need constructor?

chris: common in specs

Marcosc: consistency in the platform

chris: implementation of api might be in js

Marcosc: is sequence right there?

chris: in dictionaries, you can't use arrays

Infrastructure

<chaals> [actually, having to have a github account to work on a W3C project is pretty annoying IMHO. Different tastes I guess]

Josh_Soref: if ArtB were to ask what's your work mode
... what would you say?
... you're inconsistent

<chaals> ack

<chaals> [working with github links in an organisation (say, a typical W3C member) *isn't* convenient nor is it helpful]

<Marcosc> MC: if you have meta issues about infrastructure, please use: https://github.com/sysapps/sysapps/issues

<dsr> I will work with Marcos to add links from the working group home page to the sysapps repositories and some guidelines covering the things Marcos was saying to the wiki

<JonathanJ1> +1 chaals

<Zakim> chaals, you wanted to point out that W3C's persistence policy is pretty valuable, so having a new domain seems like a bad precedent. (and to show mounir how not to forget what you

<gmandyam> Please see: http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/0030.html. The Media Capture TF is maintaining both WD's and living specs on dev.w3.org. This is in contrast to Sysapps approach which keeps the living doc on Github.

<gmandyam> It would be nice to commonalize approaches to document archival across W3C WG's.

<Zakim> dsr, you wanted to mention W3C Team plans for keeping backed up copies

<gmandyam> It should be entered into the minutes: Marcos has stated that Google search rankings will usually place the W3C archive ahead of the Github version.

<dsr> We are discussing plans for backing up working group github respositories on the W3C systems

<gmandyam> It should be entered into the minutes: Chaals has countered that Google is not the most popular search engine in all parts of the world, and we can't count on search rankings preventing developer confusion as to official copies of the spec.

<gmandyam> It should be entered into the minutes: Marcos has suggested that the W3C take over the living document archival issue, and Chaals countered that this would come with a cost.

[ There is no scribe for any of this, and it's an interesting discussion ]

Josh_Soref: two amusing cases
... 1. Nokia bought Symbian and open sourced it using Mercurial on opensymbian.org
... eventually they closed it down

<gmandyam> Josh, mention the QT example too

Josh_Soref: and i doubt you can find most of the repositories at anything close to the latest versions
... 2. KDE suffered massive dataloss of all of their Git managed (and heavily mirrored) repositories
... -> http://itnews2day.wordpress.com/2013/03/25/kde-almost-lost-all-1500-of-their-git-repositories/
... As a result of the incident, the KDE developers had nearly lost the contents of the 1500 Git-repository project.
... It all started with the damage to the contents Ext4 file system on the primary Git-server after a failed virtual machine is restarted after the updates are applied to one server project.
... An error occurred and the file system was the integrity of the primary Git-repository, the contents of which were destroyed and many data repositories lost.
... The situation began to resemble a disaster, when administrators began to restore data from a backup. The fact that the backup practices a mirror Git-repository.
... Fingering mirror administrators was terrified – mirroring managed system automatically synchronize the erroneous data on all secondary servers, content repositories, which have also fallen into disrepair or been removed.

<gmandyam> Respec versioning on Github should be accounted for as well.

Josh_Soref: [there was a happy ending, because they lucked out, there was one mirror server that failed to mirror the dataloss, so they recovered, but that was dumb luck]

<jplyle> ZK: "it was very painful to use Anolis"

<jplyle> MC: Doesn't mind either way - happy to use ReSpec or Anolis

<jplyle> Anssik: in ReSpec you can use a noLegacyStyle config flag to to get rid of some of the unnecessary boilerplate

<chaals> [Marcos: Different editors choose different tools based on what they are comfortable with]

<jplyle> MC: This is an editing issue

<jplyle> FM: This whole discussion is similar to a discussion that was had when joining Apache. Apache's infrastructure is considered 'blessed' but want to maintain a link to GitHub to expand developer reach. Defining general guidelines - canonical specs exist somewhere - etc, would be valuable.

<jplyle> MC: ML and I generated some rules.

<jplyle> FM: There's probably a middle ground. Not much happening on Github right now, but in the future it may be very popular

<jplyle> Josh: Sending patches to Cordova can be frustrating

<jplyle> Subject: testing

Testing [in seven minutes]

<jplyle> DSR: Introduce the topic.

<mounir> ScribeNick: jplyle

DSR: I have started a wiki page - approaches to testing
... Tobie Langel is on assignment to help with testing efforts. This is ramping up.
... Don't want to block waiting for Tobie. There's some info on tools on the wiki page
... What about pages that are not automatable? Some things are very hard to test - do we want them in the spec? What do we do? Need to think about early?
... Please add to the page if you know of good tools that aren't listed

MC: Lots of testing and QA experience in the group
... Robin has already written "using test harness"
... Does Mozilla use the Test Harness?

ML: We use that for some W3C imported tests but not extensively.

MC: IVL Harness for generating tests from IDL also good. The annoying stuff - is it readonly? - will happen for free. 40% coverage in one click.
... Testing algorithms is still manual.

DSR: Don't make reviewing the bottleneck

<anssik> [an example of a spec with noLegacyStyle flag set: https://dvcs.w3.org/hg/dap/raw-file/default/battery/Overview.src.html -- notice no Attributes and Methods sections below the IDL blocks]

MC: For algorithmic tests, need to link assertions to tests. Need to create a bug or implementation report.
... Need to present the report to the director of W3C at some point

ML: Lots of APIs are highly linked to hardware - this might be hard to test with testharness
... Use VMs and Marionette -fakes receiving SMS, etc
... Hard to do something equivalent on the browser

MC: Need to show the test results once, but can't be repeated

JS: W3C make a Web Socket server available for testing. All the testharness doesn't need to live in the browser

MC: The W3C isn't going to provide an SMS gateway, so it doesn't translate?
... Goal is just to get to Rec, not further yet

JS: My goal is to make sure crappy APIs aren't created

MC: The goal of the WG is to get to Rec quickly!

<anssik> https://developer.mozilla.org/en-US/docs/Marionette

MC: Any questions - ask MC or ML. We can help guide you.

DSR: Page is just a draft, please edit.

<filmaj> timeless: http://www.highcharts.com/demo/pie-gradient

Discussion of Geolocation

ML: Proposal for a new phase 2 item

GM: Brief history - geolocation API. W3C introduced it in 2008.
... Implementations appeared ... big with the three major web runtime engines
... Geolocation WG is responsible.
... Group has not improved specifications. Recently shelved changes to the specification
... Most changes in this proposal were proposed last year, but not acted upon.
... Feeling that the group has gone dormant
... is venue shopping!
... Is the current API meeting the charter for SysApps?
... Proposal: prior to w3c work, most mobile apps had much richer location access. Pre-smartphone - BREW Iposdet, J2ME JSR-179
... Originally got involved in this through BONDI, these two were the influences. Subsumed by Geolocation, these examples ignored.
... Qualcomm SnapDragon SDK provides Java APIs
... Don't have similar counterparts for Windows 8 / iOS
... Geofencing and indoor location

<anssik> scribeNick: anssik

GM: a geo-fence is a virtual perimeter for a real-world geographic area

[ questions re use cases ]

DKA: if devices move outside a specified area, you'll get an alert
... think kids' devices, "kids tracker"

JS: these are better UCs

DKA: there are scary UCs too
... e.g. you and your friend will get an alert if you move within a same area

GM: you can do this with existing API
... see geoloc ML for some history

[ GM showing a slide with some hardware specifics ]

GM: running on a hardware is more power-efficient
... able to increase the polling frequency
... using hardware
... from Firefox OS experience, we had problems getting this right

DSR: question that was not audible?

MT: what is the developer-facing interface?

<dsr> I asked whether the modem-based geofencing was limited to circles or also supported richer boundary descriptions e.g. polygons.

[ GM walks through the current Geolocation API ]

GM: setting the accuracy is unspecified
... or limited

[ GM showing the IDL ]

GM: currently you define position options, high accuracy
... cached position

[ GM showing a slide on proposed modifications to the API ]

<wonsuk> http://lists.w3.org/Archives/Public/public-sysapps/2013Apr/0104.html

<Github> [13runtime] 15jplyle opened pull request #52: Change 'trusted applications' to 'privileged applications'. (06gh-pages...06remove-trust-terminology) 02http://git.io/QjauxQ

[GM showing code examples]

GM: thinks indoor location is ubiquitous on smart phone hardware
... when the developer enabled the high accuracy flag, the indoor location feature is invoked by the implementation if supported
... also introducing additional building information

[ GM showing proposal details, an "enhanced" Position interface ]

[ GM wraps up the presentation ]

GM: common API across web apps, packaged apps
... current API cannot bridge native and web apps
... privacy model is different, and SysApps could take up extensions to the Geolocation API for installed apps
... recommendation: take this extension up as a Phase 2 deliverable

ZK: are the threat models listed somewhere?

Josh_Soref: can do the same already with the current API
... only difference this is more power-efficient

GM: I know Chrome supports Device Orientation

JS: we need a special security model for this
... nice feature set, wrong working group
... the current security model should work
... perhaps use system messages
... continue work in Geolocation WG

<jplyle> +1 for not needing a new security/privacy model for this proposal, therefore SysApps is probably the wrong group.

<jplyle> Jonas: We're not doing everything regarding apps - we're not doing IndexDB, for example. We don't need to cover everything that might need a different security model.

GM: last year we tried to make Web Workers stay alive even if the browser is closed, to work with this proposal and geo-fencing
... use cases

mounir: you can do this in JavaScript

JS: that proves we do not need a new security model

<jplyle> ML: Your API may use some APIs that SysApps is specifying, but this API doesn't need SysApps necessarily. The fact that you *can* do this inefficiently in JavaScript is proof that you don't need a new security model.

GM: the goal is to make sure web apps have the same set of functionality than native apps

mounir: this particular feature (system messages) is within the scope of SysApps

<jplyle> GM: Does not expect a resolution on this. Can concerns be reproduced?

<jplyle> Jonas: Ok.

<jplyle> DA: Sympathetic to the geofencing usecase

<jplyle> DA: Waking up the application and doing an action when breaching a geofence boundary is handy

<jplyle> DA: Uses this all the time, e.g., Starbucks usecase

<jplyle> DA: Really good example of bridging the gap between native and web app developers.

<jplyle> DA: Having a tab constantly open to constantly call geolocation doesn't allow anyone to achieve the Geofencing usecase.

<jplyle> DA: This should be *considered*. Should not be in the initial scope, but should not be rejected out of hand.

<jplyle> DA: was involved in Geolocation working group initially - many privacy issues came up originally, will happen again.

<jplyle> GM: Assuming Sys Apps has a level of privilege.

<jplyle> DA: Geolocation is a target for privacy activists. Both good comments and a lot of controversy

<jplyle> GM: Has been negative on the Geolocation API, but only in the context of meeting native app functionality levels.

<jplyle> GM: The trust model has its own set of challenges.

<jplyle> ML: The real feature is having something running in the background. A way for my phone to let me know about things... that problem we can solve in SysApps, but not the specific Geolocation issue.

chaals: I'd like to see more Geolocation
... Geolocation API is a web-facing API
... should be done by web people
... was first planned for WebApps WG
... but was moved into its own group for certain reasons
... you can join the Geolocation WG and do this work there
... don't think SysApps would be rechartered to accommodate this work, instead of doing the work in the existing Geolocation WG

ZK: belongs here as much as Telephony, Messaging (e.g. SMS)

mounir: you can send an SMS in JavaScript, interacting with a SMS gateway that provides an HTTP API

GM: Geolocation does not have active charter currently

<mounir> s/mounir: you can send SMS in /Josh_Soref: you can send SMS in/

<Zakim> mounir, you wanted to say that location to address feature should be proposed separatedly

Marcosc: working groups are formed by people who want to work together, no magic

mounir: services such as Google Maps provide much of this functionality already

GM: floor number is something that cannot be provided currently

DSR: which companies would like to see this work happen?
... secondly, where to make this happen?
... question re closing the gap with native is not specific to this WG
... this group just has a different trust model

GM: AFAIK the manifest should not declare permissions to features that are already exposed to the web platform

Marcosc: right

<chaals> [Yandex provides reverse geocoding for various places in the world - http://api.yandex.com/maps/doc/geocoder/desc/concepts/input_params.xml (terms of use: http://legal.yandex.com/maps_api/ …)

<jplyle> JPL: The fact that the group is supporting existing Web APIs does not mean there cannot be a different set of security controls applied. E.g., giving Geolocation its own permission in a manifest. This might be reasonable in a SysApps context even though it is not necessary in a browser context.

GM: summary, I would like to 1) hear if these changes to the API have support; 2) find out the right WG for this work

<JonathanJ1> http://lists.w3.org/Archives/Public/public-sysapps/2013Apr/0104.html

<mounir> RESOLUTION: no traction for this proposal in the group for the moment.

<JonathanJ1> http://lists.w3.org/Archives/Public/public-sysapps/2013Apr/0064.html

Seamless Mobility API for web apps

[ presentation by Sunghan Kim, Jonghong Jeon / ETRI ]

SK: purpose, mobility management of handover tech to enable web apps
... current status: no API available
... UC1: mobile web app with vertical handover

[ SK showing a figure ]

SK: MxN mixed-network client UC
... 3G WWAN, Wi-Fi, WiMAX, GPS mentioned
... VCC, SIP, IMS for call continuity, 3G WWAN <-> Wi-Fi
... dependencies: mobile service environment, mobility mgmt standard tech

[ SK showing an overview of the mobile service environment ]

ZK: question about how the handover is handled

SK: inside one provider's network

GM: could you contrast what you are asking here?
... this has been presented in OMA?

Marcosc: we have offline events API already
... there are privacy issues
... how would this interact with what we have for the Web currently
... are you planning to expose network information to the Web
... if so, what's the use case?
... or is this more about having more reliable online/offline event

SK: there are many restrictions currently on the Web

<gmandyam_> What is being asked for here may be addressed by the OMA OpenCMAPI initiative. AT&T (Bryan Sullivan) has a proposal for web bindings on OpenCMAPI. CM = Connection Manager.

SK: dependencies cont'd, relevant mobility mgmt standards

[ SK showing a slide with SDOs listed ]

SK: open considerations: a) is mobility API necessary for web apps? b) is this API a proper item for SysApps WG?

ZK: what is a mobility API

[ SK described the API ]

ZK: shouldn't this be abstracted away from web apps?

GM: there was a W3C headlights activity how to expose info on the air interface
... presented by Brian Sullivan of AT&T

ZK: concern: IP connectivity
... IP address overlaps
... could be fixed by providers properly configuring their network

<gmandyam_> I will send a follow-up email to the SysApps WG pointing them to the Headlight Activity from the last TPAC

Mounir: overlaps with the Network Interface API of Phase 2
... question what is the difference with that work and this proposal

<Zakim> dsr, you wanted to ask about differences between mobility API and the chartered network interface API

ZK: voice call continuity

GM: QoS such as radio state

<JonathanJ1> OMA OpenCM API Enabler 1.0 - http://technical.openmobilealliance.org/Technical/release_program/OpenCMAPI_v1_0.aspx

GM: we do not expose that information currently

Mounir: could you describe what is needed on top of the Network Interface API?

GM: get more state information about the radio status
... such as are you in the middle of a handover, idling
... QoS related to a call

ZK: summarizing, we can extract some requirements for our other APIs
... currently support domain selection in Telephony API
... could alter the design of that API
... esp. re future-proofing the API
... I took an action to re-open the conference call in Telephony, look at the presented UCs
... I still do not know what this Mobility API is about

<mounir> RESOLUTION: use those UC to design the Network Information API (phase 2) and the Telephony API (phase 1)

Marcosc: exposing more granular network state information

Wonsuk: we need more detailed UCs
... this is a bit vague currently

GM: one thing you did not cover is fast dormancy mode
... can say keep the networking session on even if the apps are not using the network currently

Phase 2 items

mounir: good to get Phase 1 in a good shape before moving to Phase 2

JS: runtime spec will need quite a bit of work

mounir: people are welcome to collect use cases for Phase 2 deliverables already now

[ ??? introducing the Security Elements API ]

???: SIM toolkit needs to be addressed as part of the Security Elements API

ZK: should be part of telephony services

<jplyle> [blatant advert] For more information about secure elements from web applications, consider attending or submitting to the Workshop on Web Applications and Secure Hardware (WASH) in London, June 20th. http://wash2013.wordpress.com/ - might be a source of use cases.

mounir: need to nail down scoping
... wondering if anyone is interested in accessing SIM contacts, messages via a Web API

???: exposing NFC

mounir: for NFC, there's a separate working group for that

DSR: where does the NFC fit in the terms of the permission model

JS: depends totally on what the API does

DSR: other groups can add declaration to the manifest?

JS: yes

<jplyle> JS/ML: Other APIs from other groups can add themselves to the manifest permission list

GM: this functionality is not available to a typical developer

mounir: I'd like to go through all the currently proposed Phase 2 deliverables

ZK: proposals 1) multimedia resource policy 2) telephony services, e.g. an API for SIM TK 3) secure elements

GM: these would require rechartering

ZK: what is the bottleneck for not working on Phase 2 right away?

mounir: manpower

<zkis> @anssik correction: what is the bottleneck for including more items to Phase 2?

[ mounir walking through deliverables Bluetooth API, Browser API ... ]

scribe: Firefox OS has a Browser API
... as does Chrome

<zkis> @mounir: the assumption is that new people will do many of the Phase 2 items

scribe: Idle API, get a notification when the user is idle
... Media Storage API, Network Interface API

Claes: q re Media Storage API
... think that sharing media between devices should not be part of the spec
... example: I have a media file and want to send it to another device

http://www.w3.org/wiki/System_Applications_WG:_Media_Storage_API

for capturing use cases for Phase 2 deliverables, use the wiki: http://www.w3.org/wiki/System_Applications#Phase_2

feedback to the OMA on WID279 - DANE 1.0

<JonathanJ1> http://lists.w3.org/Archives/Public/public-sysapps/2013Mar/0161.html

DSR: looking at the feedback provided, proposes to pass that to OMA

spoussa: what's the benefit?

Josh_Soref: the main benefit is to let OMA know they should not do work that overlaps with this group in the Web domain

DSR: what's the group's standing on this?
... we need consensus on the response

eduardo: could we refer to the charter that this overlaps with SysApps Phase 2 deliverable?

<gmandyam_> DAP liaison response: http://lists.w3.org/Archives/Public/public-device-apis/2013Mar/0012.html

<mounir> RESOLUTION: refer to the charter that this overlaps with SysApps Phase 2 deliverable

TF between WebApps and SysApps

mounir: could get feedback from the larger standards community on parts that are relevant to traditional web apps
... such as manifest part from runtime
... Jonas to present the plan at the WebApps f2f two weeks from now
... any concerns?

JS: Runtime and Security Model spec would go into the Task Force
... the high-level goal is to leverage web platform for building apps, so it is important to get feedback from browser vendors that participate in WebApps
... but are not part of SysApps

chaals: this sounds like a good step
... basically the runtime is already in the WebApps charter

Suresh: how about SysApps-DAP alignment?
... more collaboration between the groups would be beneficial
... like joint meetings

<mounir> RESOLUTION: try to improve the collaboration with DAP, maybe by having a joint F2F or same-location F2F

<mounir> RESOLUTION: propose to create a TF to the WebApps F2F for the runtime work

Next f2f planning

Next F2F schedule

Wonsuk: the next TPAC in China in November
... we probably need one f2f meeting in between

<JonathanJ1> I'd like to offer to F2F meeting in Seoul - http://www.w3.org/wiki/System_Applications#Face_to_Face_Meeting (July or September)

DSR: f2f helps keep the group going

- DRAFT -

SV_MEETING_TITLE

11 Apr 2013

Attendees

Contents