AM1: Media Pipeline Task Force (Clarke)

ISSUE-40 (Content Protection)

Scribe:

Giuseppe

content protection

clarke: [read the issue description]
... what needs to be standardized?
... we tried to make such a list

bob: the idea is that today we can use object element to play protected content

but this does not allow to take advatnage of the media element

scribe: we would like to make sure the media element can do whatever is needed to play protected content

dsinger: I don't understand what's the problem
... there is no restriction for the video element to only play unprotected content

bob: that is partially tru but there are a couple of limitations

one is you can only make use of the protection mechanisms embeddede into the user agent

another limitation: there is no way for web content to pass any parameters to the ua to control content protection

also there are not defined error messages that notify about issues for content protections

e.g. you cannot play this becuase you don't have enough rights

dsinger: are you asking fro a pluggable DRM?

this is behind the scope of html

mark: the idea is to have a video that can be extended for drm or for other reasons (e.g. additional codecs)

what we are trying to do is to move what we are able to to with <object> with <video> (for media content)

so we don't need to use <object> anymore

and we can make use of all the featurs of <video> like multitracks, captions etc

we have two ways to work with protected content

1) you can only play what the UA support

this could work but is still a burden to support multiple DRM/UAs

for content providers

dsinger: we didn't agree on codecs, will be much harder for drm (impossible?)
... I think is really hard

mv: we are aware of this problem but we should give it a try and be ambitious

mark watson (mw): we should do a step at time

scribe: we should start with an API to talk with the platform

and than discuss about a need for a plugin infrastructure

clarke: how can we do this? is there a consensus ?

bob: I hear is difficult but not that is not needed

jon: there are some things that are less contentions, more obvious

is this a priority list?

clarke: no

jon: thn maybe we should focus on the issues where we are more in agreement

and highlight them

because if we go into TPAC with too many requirement and not agreed we may not be able to influence the html wg

jan: agree, we should focus on our main goals

dsinger: maybe we haven't formulated the problem well and we should highlight more specificly what is missing

since te simple claim "you cannot play protected content" is not true

but of course there are pieces missing, and we should focus on these pieces

mw: we should probably remove the plugin part rather than just downprioritize

I'm not sure if we all agree what we mean for UA

and which part are part of the UA and which one are not

<dcorvoysier> I completely agree with mark just said

clarke: I still think is a goal

mw: I don't think it is

Ted: we seems to be in the same situation as before

there are some key gaps and some additional requirements

maybe we should really show why what we have today is not working for you

mav: I agree there are priorities

but from a content person PoV if we could have a standard way to access the same information via the <video> element, even on different platforms

mw: I think we should not specify <object> <embed> is too detailed

we should discus on a higher level

and consider how do you do it as a second step in the discussion

jan: this list is what we need to standardize

<object> do not require anything to be standardized

so we should probably remove it from the list

dcorvoysier: which platform you have in mind?

for embedded you cannot install plugins

clarke: I think we need to rephrase it, maybe there is confusion
... point 3: common API to pass parameters to the drm system (on the platform)

provide events

jan: I would like to add more like being able to list drm supported

and I would like to show some api work we have done in OIPF

clarke: maybe we can do it later

mw: I think point 3 is the key point

and shows what is missing

i.e. that you can now play protected content but not in a generic way

you need to write specific code fro specific protection system

clarke: point 4

provide common interface for authentication

mw: what is missing here?

bob: we have heard during the workshop that you want to identify the user to be able to know if the user can play content

mw: I think you can do it already with existing technologies

for application and user

for device authentication maybe there is something missing

but that is a different discussion

jan: agree

jon: maybe if we step away from requirements

and we focus on scenarios and show what we cannot do today would be more effective

maybe show some examples

is also important to distinguish between authentication and autorization

mw: there is an identity in the browser ws

around tpac

that could be the right venue to discuss this

in this environment we need to understand what is identity in this contest and what we need this identity for

in many usecases knowing the type of device is enough

bryan: this is a multilayer thing

I agree we need to understand the objective here

need to clarify what we want to achieve

not only describing what we would like to have but also for what we need it for

jan: would like to have an action for use to describe this scenarios and maybe aim for the workshop that mw was talking about to discuss these scenarios

ted: we have login mechanisms in our services

we are doing it without any additional technology

so if we ask extra features we really need to be clear what is the problem we are asking to be solved

<bryan> re multilayer, there is identity (various), authenticity of the identity, authorization of service to the identity (e.g. user) and in context with other identities (e.g. device)

clarke: ok move on point 4

s(point 4/point 5

scribe: how the server knows which level of protection the UA support?

is the UA string enough?

bryan: no, is definitively not enough

mw: if you don't know if you can trust the device

you cannot rely on the header

and if you instead already indetified the device and know that you can trust it

than you already know what you need to know

<bryan> UA is not granular enough. User Agent Profile (UAProf, defined in the OMA) based upon CC/PP, does provide detailed info but is static and any customization of the device post-manufacture requires dynamic info of its current capabilities. In OMA we have defined the Device Profile Evolution (DPE) enabler to provide this dynamic capabilties info.

<Russell_Berkoff> CC/PP == http://www.w3.org/Mobile/CCPP/ ??

jan: presenting OIPF API for drm support

mw: what kind of information these APIs conveys?

jan: it depends on the DRM systems, this is just a channel for the application to talk to the drm

<bryan> Yes

jon: so this do not replace the communicatin between the drm agent on the platform and the server

mw: I think we should aim for a different approach instead

use a similar mechanism but use the drm agent on the platform only to pass information from the application to the server

mw: if we allow the application to be responsible to manage the communication to the server would be more flexible

otherwise we need to include that loginc in different drm component

bryan: I think we should not start with an API but more describe which information we want to tunnel

which one is the flow, we should describe it

how the application forward information to the server

mw: I described it in berlin

jan: so we complement each other

jon: re tunneling messages

this is what silverlight does today

but is not a pulic spec of course

I think is good to try to visualize what we need, we should try to capture the requirements we need the html to consider

so if we want ask for this kind of tunneling to be supported we should say that

jan: showing one more slide about device identity

[discussing limitation of the presented approach]

clarke: so is important to identify the device?

jan: is for the server to identify the device and generate a key for that platform

bob: drm systems have their own way to identify devices, don't they?

how does this work with these different identity mechanisms?

mw: I think we need to stay away from the "unique" identifier

it just needs to be consitent

how to you guarantee the device id sent by the app can be trusted?

do you rely on the drm system on the platform?

jan: yes

mw: so I'm not sure this is sufficient

would be useful to have a capability to identify the device independently from the drm

jan: by identifying the drm systems you will know the requirement on the platform

becuase drm systems have specifi requirements for devices

jon: there are needs for device identification in some use cases that proceed any dialog with the drm system on the platform

so there is use for a device identification separated by the drm

at least it should be logically separated

in some cases may be implemented on top of the drm

but this is just one way to implement it

so the specification should provide a way to identify the device but not bind it to a specific way to do it

bob: I think mw and jon are talking of 2 different pieces of information

[scribe missed jon comment]

bryan: if you have got an embedded solution, this could work, but is you can customize the device you have the riskj that the capabilities may change

if you are using capabilities to decide if you can trust that device

mw: it depends which information you are looking at, there could be some features that are "hard" to change and could be used for this purpose

clarke: there seems to be consensus that we can drop itme 2 and 4 and include the key points for these items in item 1 and 3

russell: what about protecting personal content?

clarke: ok thanks we will consider that
... coffee brake nowm than adaptive streaming

AM2: Media Pipeline Task Force (Clarke) - Continued

Scribe:

Kaz

Wrapping up Content Protection discussion

clarke: before going into adaptive streaming, can we get agreement?

-> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Delivery_in_distribution_windows ISSUE-40

clarke: so that we can bring them to TPAC
... the first is provide Web content with common interace to content protection

jan: point number 2...
... level of protection the DRM system provide
... I'd suggest number 2 should also be moved down

bob: just providing information

jan: might need more work on use cases

<scribe> ACTION: clarke to modify the text on what needs to be standardized item 2 [recorded in http://www.w3.org/2011/09/22-webtv-minutes.html#action01]

<trackbot> Created ACTION-79 - Modify the text on what needs to be standardized item 2 [on Clarke Stevens - due 2011-09-29].

igarashi: number 1 of item 1
... how to pass parameter
... DRM license acquisition assumed?

clarke: nothing is assumed

Duncan: a few more words are needed

markW: good to have target smaller

igarashi: passing DRM informaiton or something
... it's more generic
... 1.1 provide a way to...

clarke: others?

mav: maybe good to provide concrete code as example?
... could do over emais?

clarke: good suggestion

mav: jan?

jan: will do

clarke: any objection on the updated "what needs to be standardized"?

all: agree

Adaptive streaming

ISSUE-34?

<trackbot> ISSUE-34 -- Adaptive Bit Rate Delivery -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/34

-> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Adaptive_Bit_Rate_Delivery ISSUE-34 description

clarke: (explain the requirement)
... want to identify gaps
... what needs to be standardized?

jan: my suggestion is adding one more bullet on "statistics"

clarke: number of dropped packets, etc.?

david: why doesn't this work today?
... you can tell
... meaning whole the list

markW: very limitted practical things need to be added

clarke: David's point is whether thre is there efficient support on formant or not
... MIME type, etc.

bob: that's not enough?

david: why it isn't enough?

bob: how you might rephraze?

mav: just take 2 off the lisgt

clarke: can do that

(clarke removed number 2 "The video element...")

(there are remaining three items)

mav: you can have number 1 works
... what's the question?
... assume different MIME types

markW: as long as the notation allows MIME types
... UA should be able to make decision

mav: would suggest we delete number 1

(some more discussion)

clarke: don't hear anybody definitely need this

igarashi: btw, why did we remove number 2?

(it was "The video element needs to support playback of adaptive bit rate formats. ")

clarke: it is captured by the other items

igarashi: independent from specific format
... not related with this discussion

markW: we should state there is a model which people are interested
... low media data is sent by media element

igarashi: during the workshop, we still had discussion on DASH profile for HTML5
... is that still in scope?

clarke: maybe number 2 capture that
... clarify what format you are talking about

(that is now "The video element interface must support specification of adaptive bit rate parameters, e.g. maximum bit rate to be used for playback. ")

igarashi: my question is that in Berlin we had some discussion on RF version of DASH
... DASH profile for HTML5
... do we have one specific streaming format? or should allow more than one formats?

clareke: think we have that
... let me write down

igarashi: maybe I was misunderstanding number 2

giuseppe: the question we should answer is
... there is additional information on type

clarke: my question is those might be implemented
... additional parameters?
... or just use MIME type and look at manifest file?
... igarashi?

igarashi: don't think manifest file is a format
... we should explicitly specify file formats

clarke: couple of questions
... do we want to support multiple formats?
... want to include MIME type? parameters separately?
... what do we want to support?

igarashi: how to specify type for adaptive streaming?
... multiple MIME types could be included
... content-type can't be used for identification

markW: you could specify whole bunch of MIME types
... the criteria should be
... because of the failure UA can't play some format

david: to work with is UA
... DOM will be rewritten

clarke: seeing the consensus number is not a requirement

david: it is a requirement, but already supported

clarek: (removes number 1 as well)

(now we have just two items)

david: why do you want to limit?

davidmays: different publication of content

markW: generate them on the fly
... you might want to provide some limitation
... internet connection is one of the causes

jan: one comment
... one thing I was wondering was about minimum
... the user might want to have some specific video quality
... it would make sense to have minimum level bit rate as well

clarke: should rephraze this

david: choice of multiple languages for caption

markW: always have different tracks
... that's a different question from this topic

mav: is there any existing today?
... my understanding is HTML WG is shipping
... exisiting widely deployed platform
... flash documentation, etc., as well

clarke: maybe ok to keep this
... add example and reference

markW: there are various adaptive bit rate algorithms

clarke: trade off about supporting multiple formats
... any other discussion?

Duncan: overriding algorithms

jan: the third one missing is statistics
... do you have actual use cases?

markW: has been a lot of discussion
... having all of usual media handling
... there is already requirements for adaptive streaming for JavaScript

Duncan: subscribers may want to tweet

jan: the statistics could be very critical based on the algorithms

clarke: might want to extend the point two for statistics

jan: could be kept as a separate bullet

russell: bit rate parameter, etc.

markW: video element does provide buffering capability

clarke: any other comments?

<giuseppe> mozilla guys have done some work on statistics

<giuseppe> https://bugzilla.mozilla.org/show_bug.cgi?id=580531

<giuseppe> are we suggesting we should extend it?

clarke: will add statistics point as the third item here. any objections?

all: agree

<giuseppe> http://people.mozilla.org/~cpearce/paint-stats-demo.html

clarke: do we want to request for minimum rate?

markW: HTML WG could agree with minimum codec

igarashi: should avoid diversity of implementations
... was there any discussion on adaptive streaming during the workshop?

clareke: moderate the session (Session 5 / Content Format and Codecs: DASH and Codec standards)

-> http://www.w3.org/2011/09/20-webtvws-minutes.html#item02 workshop minutes

david: regarding point 2, it's not uniq to adaptive streaming

markW: error reporting is an important one

clarke: other items around adaptive streaming?

all: none

Viewport (ISSUE-37)

issue-37?

<trackbot> ISSUE-37 -- View-Port support for Video Window -- closed

<trackbot> http://www.w3.org/2011/webtv/track/issues/37

-> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/ViewPort-Support ISSUE-37 description

clarke: issue by Duncan
... (explain the description)
... what can be done today?

duncan: on a CE device, resource might be limited
... smaller device could have a picture in picture
... resource problem and styling problem

<Russell_Berkoff> we are talking about the video element showing part of a full-video stream???

markW: are you talking about a scenario with a lot of small pictures?
... you want to show subsets of a video

duncan: yes

david: video fragment URI could be used

jc: you should be very clear about the size and offset

markW: box layout property for video

davidC: you want to zoom video?
... think you can do it using canvas

duncan: hardware acceleration problem with using canvas

markW: you need to address them
... you've got to come with some rationale
... ultemately, those manipulation might happen, but requires for support of graphic cards
... canvas API doesn't imply access to streaming video

clarke: maybe we need to refine this requirement
... wording and justification

duncan: will do

<scribe> ACTION: duncan to modify ISSUE-37 [recorded in http://www.w3.org/2011/09/22-webtv-minutes.html#action02]

<trackbot> Created ACTION-80 - Modify ISSUE-37 [on Duncan Rowden - due 2011-09-29].

bryan: show running examples

clarke: from motivation standpoint, it's upto the changes that can be done

markW: good way is show people this is what we can

clarke: rationale on requesting changes

Stereo video

issue-49?

<trackbot> ISSUE-49 -- Stereo video support -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/49

-> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Stereo_Video_support ISSUE-49 description

russell: (explains)
... 2D, 3D format
... what needs to be standardized
... video elemnt for 3D
... full screen mode

clarke: first question is anything preventing video element from showing 3D?

russell: no
... this is switching

clarke: discussion

david: CSS issue?
... don't think any issue for this group
... what do you do with 3D?
... captioning for 3D?

clarke: anything related to screen size?
... separate requirement

russell: automatically switch to 3D
... could be a styling attribute, e.g., CSS
... ideally automatic selection
... assuming this is all encoded in a video stream

markW: may be the case

(some more discussion)

clarke: there a few more to talk about

<JanL> For further details on the OIPF implementation on the DRM API refer to this link, section 7.6 "Content Service Protection API" http://www.oipf.tv/live/oipf/docs/Release2/V2.1/OIPF-T1-R2-Specification-Volume-5-Declarative-Application-Environment-v2_1-2011-06-21.pdf

PM1: Media Pipeline Task Force (Clarke) - Continued

Scribe:

Christian

Group photo will be taken soon.

I.e. now.

Photo taken, back to work...

Continuation of previous session.

Clarke: Wrapping up 3D discussion before moving on.

No new issues coming up.

Next: Issue 18

http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/VideoTagSupportMpeg2-ts

Jan: Have been in discussion with Bob and mailing list.

Couple of slides to present.

Bug 13358 Update

Two addtional bugs to create will be mentioned later

Would like additional information if any non-selected tracks have been modified.

Clarifycation about which events are reported is needed

<scribe> New bugs:

Issue 18 New Bug 1: Usage of constants are inconsistent for audio track

should use disabled (as for text track) instead of off.

Issue 18 New Bug 2: Video track can't be disabled.

Text tracks can be disabled, audio tracks can be muted, but video tracks can not be disabled.

Only possible to hide video and keep audio playing, but that leaves open whether resources are released.

<dsinger> there is 'hidden', 'display:none' (CSS) and the use of an audio tag to disable any video aspects

<dsinger> we need to explore what the meaning and consequences are of the three approaches

<davidmays1> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Client_Ad_Insertion

<bryan> test

<kaz> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Media_Synchronous_Web_Content

MarkV: Why should be Caption and Subtitles in different metadata schemes and everything else be thrown together.

David: Usually you design web experience incorporated in the media, so you know what your metadata is.

MarkV: But a company like Comcast might not know what an other company like HBO attaches to a stream.

So you don't want to lose the information what each metadata track means.

Eric: Standards says metadata especially for scripting access, the rest for the user agent.

Hence special 'generic' role of metadata as opposed to other tracks.

MarkW: Subtitles and captions are universal concepts, other things are more specific to broadcast TV.

MarkV: None of these are specific to broadcast - true for on-demand video as well.

Such as 'movie extras' (essentially like DVD bonus material).

Eric: Touch of backstory - if we put this in, we need clarification, who needs a mapping?

Clarke: Next issue: 36

http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions//Parental_Controls

Parental Controls (ISSUE-36)

Jan: Is that for metadata or the video stream?
... We have two levels of parental control, application and lower.

Clarke: Description refers to an event about something that was already denied.

Jan: Some countries have regulation that content must be blocked on low level.

We might need to clarify the use case.

Systems might be forced to enforce parental control and all you get is an event.

Other systems might allow applications/user agent to deal with it.

Bryan: Even the fact that an error occured might give information "There's a child here."

Guiseppe: But if the application just throws an error, it's hard to give user helpful information.

MarkV: You might be blocked for non-payment, geographical reasons or whatever.

Informing the user on the reasons is good.

MarkW: The element blocking the playing should alert the user, not relying on a web application to perform the job.

Guiseppe: Might work well on a desktop browser, but might not be a good way on an embedded browser.

Might be no way to give information through the browser.

MarkW: But some component must implement parental guidance settings - should also be responsible

for display of parental guidance messages.

Clarke: Second item - inform web content of media content's rating.

Jan: Might be same event, but one blocks, the other one informs.

Clarke: Any more discussion on second item?

-non-

Clarke: Last topic - TV Services

TV Services and media transport mapping use case (ISSUE-39)

http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/TV_services_transport_mapping

Clarke: Most will be handled on conference call, this is mainly an overview.

Intend to do is to fill the boxes (in issue wiki) and find what already exists and what gaps remain.

Not much to do about it now.

But are any items missing?

Yes - EPG information from SI (current, next program)

David: Devise ways to include VTT and TTML in MP4 and DASH - volunteers needed.

MarkV: Happy to help.

Clarke: Any other comments on issue 39?

-none forthcoming-

Clarke: Timed Text (Issue 33) nothing that needs to be added.
... Most of content delivery isses were covered in DASH discussions.

Issue 42,43 and 51.

Clarke: Is there a motivation to adopt DASH as adaptive streaming format or do we want to be more agnostic?

John: Should be format agnostic, but it should work with DASH, due to its importance in the market.

But there are other adaptive streaming processes, so keep interfaces that are common and leave the

rest to a lower layer.

Clarke: Are there preferences within the room on how the information should be conveyed?

Should we define MIME types for the different formats?

John: I would assume the ideal outcome would be that the API is designed such that it is transparent

what type of adaptive streaming is used.

Some information on when to change bandwidth might not become available to the application.

If the underlying technologies are so different that they require different handling in the API (which does not

seem likely at the moment), then the issue might be different.

David: Might be an issue for a vertical specification for a specific industry segment, not that much for W3C.

Jan: W3c provides the mechanism, other bodies (like OIPF) might use that then for a vertical integration.

Clarke: Covered the planned issues.

20 minutes left - do we need to cover use cases we haven't considered yet?

Jan: How about SVG discussion?

Support for video tag in SVG (Issue 18, item 6)

Video tag has got a lot of work for HTML, not that much for SVG, for consistency there should be more work on that.

Clarke: Are you suggestiong they should be tracked together or that SVG refernces HTML video tag.

Jan: No preference, but they should provide the same capabilities.

Guiseppe: Might be an issue for TPAC: SVG vs HTML video

'vs' as in comparision, not as conflict.

Kaz: We could talk about that at TPAC session.

David: Alternative would be profile of SVG without video.

Just scaling vectors, no images, videos, fonts...

David C: How to deal with video coming from a tuner.

Clarke: There are 'undefined' streams in the spec that can be live broadcast from a tuner.

Clark: Is that sufficient ot are you talking about the control layer.

David C: Just access to stream would be sufficient at first.

Clarke: Any additional comments on that?

-none-

Clark: Other items?

-none-

Clarke: So we end the meeting 15 minutes early.
... So we restart next session 15 minutes early

Reconvene at 15:45.

PM2: IG planning / Wrapping up (Yosuke)

Scribe:

Bryan

Wrap-up

yosuke: new task forces
... Pablo will take care of Social TV

Yosuke will take care of Disaster Prevention...

scribe: David will take care of Captioning
... Adaptive Streaming is already being addressed by MPTF
... Metadata is also being addressed by MPTF
... MPTF result on Parental Control may include new TF
... re Testing, the new IG can provide a place for the discussions

mv: re certification, understand test and test frameworks is scope of W3C, certification is outside W3C
... there is a middle, certification organizations may want to use the tests
... somebody who has expertise may use the tests

bryan: this is in the charter of the IG

guiseppe: we need some input to that group

mv: can initiate a connection from cert organizations

giuseppe: the IG is the right place to do it, will be finalized soon

<graham> Maybe this discussion should include the profile TF discussion as well..

yosuke: re existing standards for IPTV, no TF is needed
... re API access to low-level functions, more discussion is needed on the list
... re Best Practices, this will also be further discussed on the list
... this list will be included in the IG report

giuseppe: HNTF report
... final deadline for the Req document is TPAC
... next step is to bring a complete proposal to DAP for those interested, until a new group is determined to be needed
... if we turn out with two groups doing the same thing, this needs to be discussed at TPAC
... what we do in the HNTF, once the doc is published, we can close the TF and reactivate later as needed

russell: unclear how decision was made to start with DAP - two members already recommended a new group

giuseppe: we need to first have that discussion, to see if it is diverging from what the DAP is doing, and it is already in the DAP charter, so we need to first have the discussion at least
... work needs to for now start in DAP, and become DAP members if wanting to participate in that work
... there are organizational approaches to ensure people not interested in current DAP work are not distracted by it
... if no objection, that is the plan

clarke: wrapup - MPTF is following in the footsteps of HNTF and will present to TPAC
... progress toward reqs will be nailed down in the next 6 weeks and the proposals will then be presented to the WGs
... we need to get on the agenda for groups, e.g. HTML and other groups - any questions?

<graham> no discussion on profiling?

Iraj: how work items get started in the other WGs, do they need time for that, what is the process?

kaz: procedure is to go to the groups and consider how the work fits into their charters, and update as needed

markw: if there is something to HTML group, members need to go there to argue for the items

Iraj: what is the process for new features?

kaz: HTML WG is working on how to start the next work, W3C is considering this also

clarke: we have a lot of momentum and interested parties, we need to go to the groups and work on the standards, but may need to form TFs in the group to address the items, or something else - but we need to maintain the momentum
... we don't have to wait for things to be standarized to be implemented. we can work to consensus and with the browser vendors to get them implemented

MarkW: it's actually better to implement then standardize - companies should go ahead and experiment

clarke: Cable Labs is proceeding to develop implementations and submitting them

yosuke: Topic: other expected joint meetings during TPAC

kaz: results of the questionnaire on joint meetings
... Device APIs, HTML WG, SVG, WAI Protocols & Formats, Multimodal were the highest number of responses, in high to low order

JanL: what are we determining with the quesitonnaire?

giuseppe: to know what joint meetings to have
... we need to arrange this ahead of time

JanL: DAP and HTML WG makes sense

kaz: TPAC registration is open, members need to register

<kensaku> http://www.w3.org/2002/09/wbs/35125/TPAC2011/

Igarashi: add one to MMI recommendation for joint meeting

kaz: TP day is on Wed, it will be an unconference day, and can be discussed now based upon member proposals
... members are welcome to make proposals

giuseppe: SVG and HTML video could be another topic to add
... Oct 1 deadline for suggestions

clarke: it would help to know who is responsible for arranging meetings

giuseppe: working to setup the meeting with DAP

clarke: will work to setup the HTML WG meeting

kaz: I will contact all of the proposed groups

yosuke: closing remarks
... discussed a wide variety of topics in two task forces, with lively discussions (listed topics)
... consensus has been reached on important issues, and what we should do for TPAC
... continue discussion on list
... thanks to all who attended and supported, and to Comcast for hosting

(much applause)