See also: IRC log
<trackbot> Date: 17 March 2010
<dom> scribenick: LauraA
maxf: 2 lists of issues
... no much changed since first plublic draft
... 2 issues: one related to thresholds
other about maaping to DCO
<dom> Sys Info API
scribe: difficulties mapping to DCO (Delivery Content Ontology)
bryan: aligning to DCO is a good thing, making sure we are not fragmenting further within W3C
... not complete with what I wanted to contribute with regards to DCO
maxf: open to modify set of properties
... do we really want codex (?) as properties?, do we want camera properties? etc
... open to people's views on this
... we can just follow the DCO but it's missing fundamental properties
bryan: DCO is a work in development itself
<dom> [I note that SysInfo (probably through ReSpec links to an old version of the DCO spec (2008 instead of 2009)
<dom> ]
bryan: UWA is trying to bring it to last call
... defining set of properties and defining access to those properties are different questions
maxf: encourage people to have a look at the set of properties and check if there's something missing
... there is a table at the end of the doc, in the appendices
<dom> [I've updated the ref to DCO in ReSpec]
<dom> Sys Info API
bryan: will help max fill out this table
<dom> ACTION: Bryan to provide input on DCO mapping for SysInfo [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action01]
<trackbot> Created ACTION-116 - Provide input on DCO mapping for SysInfo [on Bryan Sullivan - due 2010-03-24].
Wonsuk: benefit of mapping to DCO
maxf: DCO is a W3C spec, makes sense to make them compatible
... just mapping properties between sys info and DCO is simple, what is difficult is to make them work, dealing with numeral properties:
... how do you access several batteries? givevn that DCO doesn't define multiplicity
... 3rd issue: threshold
... problem is if you have CPU and have a watch object, if you specify a threshold it's obcious that is applies to that
but in the case of Network, how do you know what the threshold applies to?
scribe: several properties: download BW and upload BW, which one does the threshold apply to?
... because of minimisation (privacy), you could change your get function to pass not only the property name but also the attribute name
... not decided which solution is best
<RuthVazquez> I am!
dom: when you have two dynamic values, you need to specify to which value the threshold applies
Claes: problem with extensability
darobin: not necessarily, that's an implementation question
bsulliva: basic problem is: how do I watch a specific property?
maxf: what I suggest the either you specify a threshold and a target, or just specify the target and not the threshold
dom: you need to highlight which of the properties are "watchable"
maxf: that's correct
<dom> ACTION: maxf to update sysinfo with the addition of watch/threshold targets (and watchable attributes) [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action02]
<trackbot> Created ACTION-117 - Update sysinfo with the addition of watch/threshold targets (and watchable attributes) [on Max Froumentin - due 2010-03-24].
maxf: happy to go through the document and issues
... 1st issue: reuse DCO's base URI when applicable?
dom: UWA is currently out of charter
bsulliva: go forward and define a set of properties within DAP that make sense and let UWA take care of them
maxf: 2nd issue: related to threshold, already solved
<dom> Raised issues on SysInfo in Tracker
maxf: 3rd issue:section 4.9 Audio and Video Codecs: Those properties could be replaced by an array of DOMString in VideoCodec. The reason they are currently defined as a separate property is that we may add specific fields later. But is that ever going to be necessary?
<dom> ACTION: maxf to get rid of the empty interfaces and replace them with the generic SystemProperty in SysInfo [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action03]
<trackbot> Created ACTION-118 - Get rid of the empty interfaces and replace them with the generic SystemProperty in SysInfo [on Max Froumentin - due 2010-03-24].
maxf: 4th issue, 4.11 Output Devices section: Do we need information about active devices, e.g. in order to be able to see which screen is currently being in use, or to control which set of speakers should be activated? If so how do we specify it? Through an "active" flag on each device (hard to watch), or through a pointer (e.g. currentDisplay in OutputDevices) which would mean only one device is active at a time, which might not always be correct in cases like
bsulliva: question is how to you model the state of things
... first thing to check is if it is Supported, is it Present and then is it Available
maxf: question is how in practice to you put them in an interface, do you need an Active array, Available array etc?
... I will take an action to write up both alternatives on how to define availability so that the group can make a decision
<dom> ACTION: maxf to write up both alternatives on how to define availability of multiple properties (e.g. Network, output devices) in SysIno [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action04]
<trackbot> Created ACTION-119 - Write up both alternatives on how to define availability of multiple properties (e.g. Network, output devices) in SysIno [on Max Froumentin - due 2010-03-24].
maxf: 6th issue, section 4.11, constants defining device orientation: Are we being short-sighted in only listing four orientations? Would it make sense to have it be an angle, except that in most cases it would only change in 90° increments?
drogersuk: there can be plenty of cases where you want to rotate more than 90°
... don't mind having constants, my concern is that we wouldn't be able to set the angle to 31° for example, you are preventing an implementation there
bsulliva: let's take the use case where we have an accelerometer API
... do we want to change the screen orientation or the widget orientation?
... we want to control the presentation of the widget
<dom> ISSUE-59?
<trackbot> ISSUE-59 -- SysInfo: make minFrequency and maxFrequency optional -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/59
<dom> ISSUE-60?
<trackbot> ISSUE-60 -- orientation, acceleration compass in System Information -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/60
<dom> ISSUE-64?
<trackbot> ISSUE-64 -- "Generic" sensors may permit discovering sensitive information -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/64
<dom> ISSUE-76?
<trackbot> ISSUE-76 -- Available/Preferred Networks in sysinfo -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/76
<dom> close ISSUE-59
<trackbot> ISSUE-59 SysInfo: make minFrequency and maxFrequency optional closed
<dom> ISSUE-59: overtaken by more recent edits
<trackbot> ISSUE-59 SysInfo: make minFrequency and maxFrequency optional notes added
<dom> close ISSUE-60
<trackbot> ISSUE-60 orientation, acceleration compass in System Information closed
<dom> ISSUE-60: overtaken by events
<trackbot> ISSUE-60 orientation, acceleration compass in System Information notes added
<bsulliva> Link to DPE spec: http://www.openmobilealliance.org/Technical/release_program/dpe_V1_0.aspx, where "Table 6 14: Policy Types and Parameters" includes the set of "watch" method options I suggest we align with the SysInfo API
<dom> (I'm linking maxf's ACTION-115 on warning re fingerprinting to tlr's ISSUE-64 on generic sensors leaking sensitive info)
<dom> Capture API editors draft
ilkka: pretty simple API in general
... only one recent update
... commited the new version on Monday night
... there are 3 interfaces for capturing images, video and audio
... 3 attributes describe which are the supported formats
... success CB and error CB for the 3 interfaces
AnsiiK: in the first draft we had 3 methods for image, video and audio capturing
... we can make it just one method call
darobin: we should do whatever is simplest for us to define
AnsiiK: just thought of another way of doing this, having a common capture method and just pass the media data object as part of the options
darobin: proposal A is shorter
AnsiiK: that is what is currently in the spec
... do we have consensus?
<richt> Is it worth/possible allowing both of these patterns (JS method overloading): captureImage(success, error, options) AND captureImage(success, options)
<richt> ...and captureImage(success) and captureImage(success, error) ???
ilkka: in the latest update added text to describe access the camera, section 5. Capture Input selection
... section 5.1 is informative an explains what is already possible today, as a hint to implementors
AnssiK: "explain
... "explain an example"
darobin: this image/example should go in the spec
AnssiK: 5.2 is a third option to use File picker
... Robin is the originator of this idea
ilkka: (section 5.2) viewFinder interface that inherits from file
(Robin goes through the example in section 5.2)
ingmar: the input element at the beginning of the example is not needed
darobin: dom has already removed it
AnssiK: are we happy that we have these 3 cases (native interface, file picker and viewfiner interface) in one API?
darobin: yes, that's ok
dom: we don't want to enforce it, we want to show different ways of doing it
<dom> -> http://www.mediawiki.org/wiki/Mobile_browser_testing/iPhone#Unsupported_Technologies.5B7.5D "Safari on iPhone does not support <input type="file"> elements; these events get disabled by Safari."
richt: would it be possible to have a media data file object?
darobin: we should inherit from File
... we might want to change the name to ViewFinder
<dom> dom: not sure if we should inherit from File, or create a MediaData object out of a the blob
<dom> robin: let's go with inheritance and log an issue on the spec:
<dom> s/sepc/spec/
http://demos.hacks.mozilla.org/openweb/FileAPI/
richt: this relates to other APIs as well
AnssiK: section 3.1.2: it can be useful to programmaticaly control the length of the video, for example
richt: are error CB nullable?
darobin: error CBs should be nullable
fhirsch: It may be worth having one separate doc with reqs for all APIs
... move the reqs of the individual docs into the currently existing reqs doc
<dom> PROPOSED RESOLUTION: Requirements and use cases are migrated back from individual APIs to the APIs requirement document
darobin: editors of individual API specs should do this
RESOLUTION: Requirements and use cases are migrated back from individual APIs to the APIs requirement document
ingmar: regarding the ViewFinder case, do we need another entrance point for the case when the user does not want to click everytime he wants to use the camera?
darobin: we might want to look at what BONDI does
... "additional entry points for trusted environments"
richt: overloading, is there a better way to describe overloading other than what is currently done?
darobin: we could put everything in the options
<dom> (this relates to ISSUE-55)
richt: I like that
<dom> ISSUE-55?
<trackbot> ISSUE-55 -- Should we use object literals in place of positional parameters and if so when? -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/55
darobin: this makes overloading simpler, despite being more verbose to write
dom: this is a nice thing to define, but it diverts from the Geo API
darobin: this would work fine with REST
... proposal: we put it in the spec and see how people react
<dom> ISSUE-55: sounds like object literals would be fairly nice in terms of specification, but would bring differences with the existing APIs (e.g. geolocation)
<trackbot> ISSUE-55 Should we use object literals in place of positional parameters and if so when? notes added
<dom> ACTION: Robin to check with Geolocation WG re choice of object literals vs positional parameters in geo API [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action05]
<trackbot> Created ACTION-120 - Check with Geolocation WG re choice of object literals vs positional parameters in geo API [on Robin Berjon - due 2010-03-24].
<darobin> ACTION: Robin to do send out a CfC for Capture as soon as the updates are done [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action06]
<trackbot> Created ACTION-121 - Do send out a CfC for Capture as soon as the updates are done [on Robin Berjon - due 2010-03-24].
<jmorris> is there an audio connection into the room?
<darobin> agenda updates:
<darobin> session 2-7 is now FileWriter
<darobin> session 3-5 is now Gallery, and F2F
<darobin> RuthVazquez, jmorris: we're setting up Skype
<RuthVazquez> ok, thanx
<fjh> by default contacts returns single contact object unless mulitple option set
<fjh> this is a change in line with minimization
<dom> ScribeNick: aguillou
<dom> Scribe: Aurelien
<scribe> TOPIC : Contact API (R. Tibbett)
List of the issues leveraged on Contact API
Section 4.2 - find() method
Specified as a DOM String array in the fileds
<dom> Contacts API editors draft
An example is available in section "create a new contact".
Do we want to move on in an Object "style" instead of an classical DOMString array ?
if we just want to know only the ZIP code, how does it works ?
fields mapping need to be done to check the values specified in parameters
richt: methods are following the REST style way to define functions (getters and setters)
darobin: Can we pass a object as a value in parameter and then updated in the functions ?
richt: 2nd issue - data format to use in the attributes
<RuthVazquez> ups, yes Susana is Ruth... at least I'm muted
richt: Portable Context for ex. is compatible with vCard
<RuthVazquez> I just though Zakim was asking again, I don't know my handle
<alissa> I'm on the call
richt: we chould think about a portable format concerning the contact attributes
dom: we could have a minimum mandatory subset of attributes
richt: we need to be aligned with the vCard format
... may be a subset of vCard is enough for the Contact attributes ...
<alissa> I will see the vcard people at IETF next week -- is there anything useful to ask them? Perhaps if others have profiled vcard before and how the subsetting worked out?
Annsik: ... using such vCard subset will be easier for data mapping and portability
<alissa> ok
<alissa> can't hear bryan
bsulliva: the address book of the SIMcard is based on vCard (3GPP)
<alissa> ok, thanks aguillou
richt: 3rd Issue - Phishing against an API ?
<richt> richt: phishing against error codes
darobin: ... it's not really an issue....
richt: 4th Issue - Sedtion 6. Note - Pattern Matching in contact list
fjh: Is it equivalent to a regular expression ?
<jmorris> So this means that if I ONLY want to share "Robert" I could not avoid also sharing "Roberta" ?
<darobin> we have a use case: http://xkcd.com/208/
Richt: Isit partial matching or whole word matching ?
<dom> jmorris, you could avoid sharing by not selecting it in the intermediary screen presented by the UA
<fjh> can match string in middle of name without regular expressions
<jmorris> thanks
<darobin> s/chose/choose/
bsulliva: how easy is it to use such filter feature ?
<fjh> topic of internationalization can be an issue, e.g. in korea searching only by consonant
dom: text search is complicated in term of implementation.
<darobin> ACTION: Robin to talk to I18N about text search in Contacts — can we do it right (simply), or do we leave it to be implementation-dependent [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action07]
<trackbot> Created ACTION-122 - Talk to I18N about text search in Contacts — can we do it right (simply), or do we leave it to be implementation-dependent [on Robin Berjon - due 2010-03-24].
dom: we should pass a string to the UA and then get the results back
... do we need to specify that it's a substring matching ?
... we should be explicit about the search behavior (substring matching or not).
<richt> richt: do we need to be specific on the encoding for i18n: e.g. input/output must be UTF8 encoded.
<dom> dom: we probably don't need to say anything about this
<richt> darobin: we don't need to be specific. JS uses UTF16 internally.
darobin: string transcoding in JS
richt: service ID attribute in 4.2
... default behavior in the serviceID is not specified ?
bsulliva: contacts could be on the SIM card or on Google, what's the default behaviour ?
dom: not sure we have enough use cases where we use the Service ID parameter
richt: in Facebook, your contacts are represented from an URI
... ServiceID is useful when we need to address to several Contacts lists (SIM card, FaceBook, Google, etc.)
bsulliva: we need to specify more clearly the use cases (device, SIM, network). And then, we can check if it's a good solution
dom: adressing these use cases are quiet complex.
darobin: ... may we can put the use cases in a separate doc.
... merge all your address books from Web providers and your SIM card
<fjh> discussion of address book api allowing functionality like merge etc
bsulliva: if we say it works only for device and SIM cards, it's quiet simple.
richt: ... but if we include Web providers, it starts to complicated
bsulliva: how those API use of specifi address book ?
<darobin> ACTION: Bryan to make a concrete proposal how Contacts could support use of specific address books [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action08]
<trackbot> Created ACTION-123 - Make a concrete proposal how Contacts could support use of specific address books [on Bryan Sullivan - due 2010-03-24].
dom: we need to have a better idea of the costs of supporting these features (network, SIM, etc.)
bsulliva: we need more description of the use cases
richt: Security and Privacy Issues
... discussions concerning the UIs.
<darobin> ACTION: richard to create a mockup of the contacts UI for contact picker, based on previous mailing list discussion of use cases [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action09]
<trackbot> Created ACTION-124 - Create a mockup of the contacts UI for contact picker, based on previous mailing list discussion of use cases [on Richard Tibbett - due 2010-03-24].
richt: ...other questions about the Contact API ?
darobin: ... when the changes will be done ?
richt: around end of April...
... it will takes couple of weeks.
dom: we chould add REST considerations
<darobin> ACTION: Richard to fold in Contacts changes (and when done ping Robin to start a CfC) [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action10]
<trackbot> Created ACTION-125 - Fold in Contacts changes (and when done ping Robin to start a CfC) [on Richard Tibbett - due 2010-03-24].
<darobin> action-125
<darobin> action-125?
<trackbot> ACTION-125 -- Richard Tibbett to fold in Contacts changes (and when done ping Robin to start a CfC) -- due 2010-03-24 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/125
dom: what the plan for the last call in June ?
darobin: we need to have 3-4 specs for the last call.
<jmorris> can you briefly summarize the expected agenda for the afternoon?
<darobin> FileWriter API editors draft
darobin: TOPIC - File API Writer
<jmorris> thanks
darobin: a lot of discussions around the File Writer API
... Section 2.1 - File Writer API JS example
... Do we keep the Automatic Line ending issue ?
bsulliva: does the platform caould modify the CR ?
darobin: it's a kind of encoding issue,
... there's a Sync. version of the File Writer API
... Section 7 is completely wrong.
... the use of the "input" element will prompt a doanload dialog.
... We need to create another method, instead of using the "input" method
<dom> PROPOSED RESOLUTION: Replace <input type="saveas"> by a JavaScript method such as navigator.saveFile()
<dom> ACTION: Robin to modify FileWriter to add the saveFile() method [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action11]
<trackbot> Created ACTION-126 - Modify FileWriter to add the saveFile() method [on Robin Berjon - due 2010-03-24].
ilkka: how we know the end of the file if we don't have a Read access ?
RESOLUTION: Replace <input type="saveas"> by a JavaScript method such as navigator.saveFile()
darobin: ... we could do that with the Seek method
ilkka: we need to check that (use of the length attribute) in the File Writer API
RESOLUTION: We publish FileWRiter as FPWD once new fileWriter entry point is added
<dom> PROPOSED RESOLUTION: split privacy out of policy-reqs into its own document
<dom> PROPOSED RESOLUTION: split privacy out of policy-reqs into its own document and publish privacy-reqs soon
<dom> jmorris, any feedback on the proposed resolution above?
RESOLUTION: split privacy out of policy-reqs into its own document and publish privacy-reqs soon
<dom> ACTION: Frederick to prepare privacy-reqs out of policy-reqs for a call for consensus for FPWD [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action12]
<trackbot> Created ACTION-127 - Prepare privacy-reqs out of policy-reqs for a call for consensus for FPWD [on Frederick Hirsch - due 2010-03-24].
darobin: TOPIC - Calendar API
Usage of the Lunar Calendar System in Korea
<dom> Lunar Calendar in Wikipedia
<dom> Input on Lunar Calendar system for device APIs
Kangchan: we can use several calendar systems: solar and lunar for ex.
<darobin> -> an implementation of a converter http://cpansearch.perl.org/src/AERO/Date-Korean-0.0.2/lib/Date/Korean.pm
Kangchan: Examples of Lunar / Solar Calendar UIs implemented on mobile devices
wonsuk: In korea, we can have the 2 calendar systems on a single calendar.
Kangchan: http://calendar.naver.com/
... Use Case 1 - a Web Application would like to access the device calendar
... Use Case 2 - a user would like to change a calendar appointment
<darobin> ACTION: Robin to contact I18N about other potential calendaring issues [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action13]
<trackbot> Created ACTION-128 - Contact I18N about other potential calendaring issues [on Robin Berjon - due 2010-03-24].
<fjh> is this really different than time zones, in an abstract sense?
Kangchan: ...Use Case 5 - A web application would like to sync. with Web Portal
<dom> Calendar API Editors draft
Kangchan: Lunar Calendar System is not used for ex. in the pictures taken by the cameras
... Proposal to support Lunar Calendar System to DAP
... an attribute is added to the interface CalendarEventProperties {... lunisolar; 0=solar(default); 1=lunar}
dom: we might have interroperability problems between calendars....
<dom> dom: export to icalendar might become problematic with lunar-solar calendars
<dom> "iCalendar's calendar is also not compatible with some non-Gregorian
<dom> Gregorian
<dom> Gregorian might refer to:*Named for Pope Gregory I:**Gregorian chant**Brotherhood of Saint Gregory*Gregorian reform *Named for Pope Gregory XIII**Gregorian calendar**Gregorian University, Rome...
<dom> calendars such as the lunar calendars
<dom> Lunar calendar
<dom> A lunar calendar is a calendar that is based on cycles of the moon phase. The only widely used purely lunar calendar is the Islamic calendar or Hijri calendar, whose year always consists of 12 lunar months...
<dom> used in Israel
<dom> Israel
<dom> Israel officially the State of Israel , is a developed state in Western Asia located on the eastern shore of the Mediterranean Sea. It borders Lebanon in the north, Syria in the northeast, Jordan in the east, and Egypt on the southwest, and contains geographically diverse features within its...
<dom> or Saudi Arabia
<dom> Saudi Arabia
<dom> Saudi Arabia , is an Arab country and the largest country of the Arabian Peninsula. It is bordered by Jordan on the northwest, Iraq on the north and northeast, Kuwait, Qatar, Bahrain, and the United Arab Emirates on the east, Oman on the southeast, and Yemen on the south...
<dom> . Although there exist one-to-one mappings between Gregorian and many other calendar scales, the lack of defined CALSCALE values for those calendars and limitations in various date fields can make native support impossible. For example the Hebrew calendar
<dom> Hebrew calendar
<dom> The Hebrew calendar or Jewish calendar is a lunisolar calendar used by Jews, and in recent decades, by a growing number of Christians...
<dom> year may contain either 12 or 13 months, and the Japanese
<dom> Japanese era name
<dom> The Japanese era calendar scheme is a common calendar scheme used in Japan, which identifies a year by the combination of the and the year number within the era...
<dom> Emperor-based calendar scale contains many eras."
<dom> http://www.absoluteastronomy.com/topics/ICalendar
<dom> ISSUE: Can we support lunasolar calendars in the calendar API?
<trackbot> Created ISSUE-80 - Can we support lunasolar calendars in the calendar API? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/80/edit .
richt: iCalendar / vCard must support Lunar calendar via conversion to Solar... need to check that
darobin: we need to store a flag somewhere in the iCalendar to know if it's a lunar / solar calendar
richt: do we need to maintain this lunar / solar information ?
darobin: ...or we can use a specfic convertion method lunar<->solar... not sure it will work.
... we need to check with the I18N WG if there're works already done around Lunar / Solar calendar conversions
AnssiK: and what for the Maya Calendar ?...
richt: TOPIC Calendar API
... which date format to use ?
... we can use JS specific date format
darobin: we must use a Date object.
... HTML 5 uses a Date object.
<dom> ECMAscript 5 spec
darobin: .... we should do the same as HTML 5.
<dom> [Date object defined page 165]
<darobin> ACTION: richard to figure out how to specify TimeZonedDate [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action14]
<trackbot> Created ACTION-129 - Figure out how to specify TimeZonedDate [on Richard Tibbett - due 2010-03-24].
<darobin> ISSUE: 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?
<trackbot> Created 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? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/81/edit .
richt: we can use for ex. a getDate() method on the Date object in order to retrieve the local time.
... a proposal is to use a subset of iCalendar in the events, but is it enough ?
dom: we should be iCalendar compatible.
<AnssiK> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0016.html
<AnssiK> discussion on how to pass in times for calendar events above
richt: ex. of use of calendar events: Weekly, Monthly, etc.
... http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0130.html
... we need to be sure that developers will use Calendar Events in the right way.
... the challenge in the Calendar API is to keep it simple as possible...
<dom> PROPOSED RESOLUTION: Calendar API FPWD is delayed until recurrence is better handled
RESOLUTION: Calendar API FPWD is delayed until recurrence is better handled
<dom> s/<dom> RESOLUTION/<aguillou> RESOLUTION/
richt: there're still some issues in the calendar API that need to be discussed (iCalendar, Calendar events)
... Calendar Events mangement with the Time zones...
AnnsiK: do we need to use UTC time, floating time, time zones ?
richt: the local time is linked to a specific time zone,
<fjhn> ACTION: richt to propose changes to calendar specification to address privacy minimization [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action15]
<trackbot> Created ACTION-130 - Propose changes to calendar specification to address privacy minimization [on Richard Tibbett - due 2010-03-24].
darobin: F2F location talks
darobin: we need to decide on when and where we will meet for the F2F
... we could meet in Sept. instead of July. Invitation from ETRI to meet in Korea.
... ... last week of June should probably work.
... June 14-16: Helsinki / St Petersburg
... Nov wk 1 : TPAC Lyon
... Feb-Mar 2011 : Korea
... June 2011 - St Petersburg
June 14-16 : OMTP London ?
<dom> ACTION: Dom to set up poll for next F2F around mid June (14-18) or first week of July, in either Helskinki, London, Seoul, Madrid [recorded in http://www.w3.org/2010/03/17-dap-minutes.html#action16]
<trackbot> Created ACTION-131 - Set up poll for next F2F around mid June (14-18) or first week of July, in either Helskinki, London, Seoul, Madrid [on Dominique Hazaël-Massieux - due 2010-03-24].
<darobin> RESOLUTION: DAP will meet at TPAC
<ilkka> dinner: http://maps.google.com/maps?f=d&source=s_d&saddr=Italsk%C3%A1&daddr=Na+boji%C5%A1ti+12,+120+00+Praha+2,+Praha,+Czech+Republic+(Hostinec+U+Kalicha)&hl=en&geocode=Fbs2_AIdoVbcAA%3BFW0P_AIdlCfcAC
<dom> http://www.ukalicha.cz/shop/index.php?lang=EN
<dom> http://www.gastroinfo.cz/pivodum/
<ilkka> yes, foget my link