AM1: IG interim report - Yosuke Funahashi

Scribe:

Bryan Sullivan

yosuke: purpose, structure, review summary

<jeff> Is there a link to the document?

<giuseppe> report link: http://www.w3.org/2011/webtv/wiki/Web_and_TV_Interest_Group_Report_201109#Home_Network_.5BGiuseppe_.28with_Francois.27_help.29.5D

<Fuhrhop> http://www.w3.org/2011/webtv/wiki/Web_and_TV_Interest_Group_Report_201109

yosuke: IG interim report draft overview

<giuseppe> or better: http://www.w3.org/2011/webtv/wiki/Web_and_TV_Interest_Group_Report_201109

yosuke: overview of executive summary
... activities planned in the IG, intro to the task forces, and rationale for two task forces

kaz: will the report be updated in this meeting?
... adding supplemental info, many items discussed in the workshops, and task forces have/will discuss many of the topics raised. some more task forces are expected to be created to address the remaining topics

hj: this report addresses work so far, and will be updated to reflect the final proposal. an updated report will be issued from time to time

jc: question, there is a list of TFs - what is Web and Broadcasting and Web and IPTV

yosuke: Web and Broadcasting TF is to address combination of broadcasting and Web. Broadcasters have a lot of content that is not part of the "one Web". The scope is how to integrate this content into the Web experience.

kaz: also how to get information via those two channels (IPTV and Broadcast)
... also accessibility TF will be discussed (not in the draft)

jeff: is the IG at the point of considering new TFs or looking at the broad overview still?

yosuke: still the broad overview

matt: more insight into the use cases is requested

<HJ> clarke clarified content protection/DRM is already in the scope of media pipeline TF

yosuke: re tagging in the report. the report is dynamic, and needs to change

kaz: my understanding is that we should fix the sept version and add items from this session

yosuke: we will need to update links to the details to keep them current

kaz: yes the TF reports will be linked

yosuke: is it OK to update the TOC for example

kaz: yes the TFs are still working so it should be OK to update the report

clarke: the pipeline TF doc will have a lot content tomorrow, suggest linking to tomorrow's version

giuseppe: the report is live, shows what's going on. we can snapshot and publish that at a URL. but the most important to capture the live status

russell: there was a term in the IG report re internal discussions. is the IG planning a regular conference? there has not been a general IG discussion as the TFs are focused on their work

kaz: the question is whether the document should just point to the latest version of the details

giuseppe: don't suggest additional phone conferences, instead make better use of mailing lists

kaz: we can discuss the need for additional conferences and TFs etc in the nect steps session

russell: saw the proposed IG calls as helping to handle new TF proposals and other high level aspects, rather than grinding through use cases etc

yosuke: will apply updates to the report based upon this meeting and will fix (finalize) the sept report

giuseppe: suggest to go thru the wrapup session and other notes and see what more TFs are suggested

philipe: yesterday we had two summaries, work of existing TFs and suggestions for new TFs. there are two that are ready to be presented

philipp: one is Social TV
... explain how TFs are created?

giuseppe: we have a mail list and workshops, with list discussions suggesting the TF. the first thing is a charter proposal for the TF, a call or two to clarify. the charter just needs to be lightweight, and if the scope is OK, it can be created and determine its detailed output. e.g. a requirements document or proposal for new WGs
... we have had two TFs and can use them as template for how to proceed. its a lightweight group

Social TV Task Force proposal

(link to slides anyone?)

pablo: Typical social experiences while watching TV
... social networking means many things
... Framework: a number of use cases can be considered, e.g. content selection and sharing - how to use socnet to get info from other people, e.g. recommendations
... second can be communication, directly between people watching programs, via audio or video
... last two are about facebook and twitter as examples to be integrated into the TV stream

mark: how much of this is something that W3C needs to standardize, as compared to an existing API defined by the socnet e.g. facebook

pablo: there is integration between the socnets, audio/video, a number or features

mark: it would be good to focus on browser integration, rather than the broader aspects. just the API focus would allow the TF to go much quicker

giuseppe: my question is why can't we do this today? its ok if the TF is a little fuzzy at the start - its an initial brainstorming process to clarify why it cant be done today, with technical level discussions following as needed

jeff: to be effective, we need stakeholders (e.g. facebook) at the table. maybe first we need to find the stakeholders and get their interest (the right level)
... it will help the impact of the TF

giuseppe: agree, we need to get more participants, but have some restrictions re meetings and members, but we should reach out to the other stakeholders

kaz: several W3C members are mentioned in the presentation

david: suggest to see how we can handle the recommendations with existing specs first. not sure we need to create new specs, but agree that we need to consider the use cases

phillip: show of hands?

jan: suggest to show the whole flow for a use case so we can analyze it further

mav: interested in knowing what the gaps are, dont know the cases as well, and need more info to determine the gaps

clarke: perceived gap may be sync of TV program and Web info. we have discussed tools e.g. in DLNA to enable integration e.g. TV tuning - though not in HTML its useful for integration

matth: if gaps can be enumerated by people, then we can consider them

jan: ericsson labs has looked at socnet integration into TV, linked in the TF results. the requirements we put in cover what we see as gaps

giuseppe: media annotation is also another missing item, e.g. with URLs

russell: within the home network TF we did not cover what a home network is re inter-home/network sharing, though peer-to-peer, we may need a bridge function which can span homes

phillip: the TF has not addressed that use case yet
... other candidates for TFs are in draft form, suggestions?

kaz: had some discussions, with recommendation that someone generate a draft charter - I intend to do so

giuseppe: the question is there something new for TV that is not already addressed by the accessibility group in W3C? should we ask for their input?

jeff: on discussions yesterday on Wev VTT accessibility, some complaints in the hallway re what we are doing with that. curious as to whether the TV broadcast industry has a forum in which the perspective of the industry can be clarified. The angst needs to be clarified.

david: we will need to discuss relationship with TTML and Web VTT, that they express the same semantics, and there is a machine translation, etc. The process of conversion into TTML and improvements of it etc, will be considered in the community group.
... non-W3C participants will be able to be engaged in the community group. we would like to discuss the work chain for captioning and info in general, we understand the interfaces

jeff: sounds like the conclusion is that the community group is the right place, it's open. Mark will help reach out to the non-W3C members of the industry.

phillip: on the list of TFs, can we get an explanation of the rest?

kaz: displays the IG draft report
... lists the proposed TFs
... Web and Broadcasting will be explained by yosuke

<HJ> http://www.w3.org/2011/webtv/wiki/F2F_Hollywood_2011 is agenda link

kaz: re the agenda we are in the new TF discussion part, the agenda has been updated.

yosuke: asks for clarification of the sessions before/after AM break

phillip: suggests continue TF discussions

new TF proposals - Disaster Prevention and Response Task Force (DPRTF)

yosuke: chairs prefer topic-based task forces, to help focus on industry-specific things. based upon the discussion yesterday, DPRTF may be a good candidate for a topic-based TF

<giuseppe> charter draft available here: http://www.w3.org/2011/webtv/wiki/(DRAFT)_Disaster_Prevention_and_ResponseTask_Force_(DPRTF)

yosuke: draft charter has been sent to the mail list. the mission of the TF is to deal with info on disasters (various types listed). this type situation offers the chance for broadcast to provide valuable info to TV users. But more and more people dont watch TV - how to address this gap?

jerry: this is a different topic than web and broadcasting?

yosuke: yes

<giuseppe> to clarify, since "web and broadcasting" was too generic, the idea is to start TFs more topic based

<giuseppe> this is one of them (candidate)

Kensaku Komatsu from NTT Communication: from the Japan quake, while a combination of Web and TV can provide helpful information. we think that radio services are also useful

david: question is how to get alerts out to the non-TV watching world?

bryan: Cell Broadcast is used in the US (or will be be)

<Alan> s /question is how/question is does W3C want to be at the center of the discussion of how/

karen: in the Technology and Policy domain, we have an government interest group where this discussion can be considered

john: (did not capture the point made)

clarke: we can consider TV clients for alert services for which users can opt-in to disaster notifications

giuseppe: we don't need conclusions, also recommendations how to leverage existing things is a possible outcome. an overview of existing alert systems can be provided, to help us understand what the gaps are. also agree this is a big thing larger than the Web, to do something in practice impacts a larger scope

sergey: interruption and forced display of alert content needs to be considered for the Web based TV experience

jerry: discussion in heading in the right direction - not to recreate alert systems, but the unique experience with the browser and how interruption/display works, impact to the application and user level etc need to be considered

phillip: will break for 30 minutes

AM2 - Topics from workshops and next steps

Scribe:

Jan Lindquist

<JanL> giuseppe to present

->http://lists.w3.org/Archives/Member/member-web-and-tv/2011Sep/att-0003/NextSteps.ppt Giuseppe's slides

->http://www.w3.org/2011/webtv/wiki/Web_and_TV_Interest_Group_Report_201109 Draft IG report updated based on the discussion

more discussion is needed for social tv

agreement that possibly a new TF for disaster prevention and response

charter shall be improved

<davidmays1> how about "improved disaster response"

title to be clarified

there will be a community group for discussion of captioning

clarke: isn't more than captioning

response is only captioning

mptf will work on adaptive streaming requirements

for metadata it was mentioned in the workshop

what is the next step?

what is already there, do we need something more

bob: can somebody expand what metadata covers?

giuseppe: how is metadata exposed from the broadcast

bob: metadata will be exposed as tracks

it is covered in the mptf discussions

giuseppe: there might be wider set of requirements

is there anything missing relating to captioning

clarke: descriptive text may be missing

mark: transport related captioning that are mapped to text tracks

giuseppe: content protection

will be discussed in mptf

bob: will define with other API's but there needs to be a wider discussions on harmonizing the parental rating

make content advisory should be exposed to the application

gius: shall we expand or identified after

there might not be time for concluding in the first draft of report

john: please clarify digital rights and content advisory

a clarification is being made between content protect

it should be client authorization as part of content protection

the protection is not only content but also service protection

is there work in parental control

clarke: reporting on information is important

mark: in NA the parental control information in carried inband

how is the information is pulled out from in-band delivery

<bryan> bryan: service protection is a good term to use to distinguish controlled access to a service from controlled access to the content (e.g. thru DRM). regardless of whether the content is protected or not, access to an application or service may require separate authorization. Service Protection is the term used for this for example in OMA BCAST.

question if outband should also be in the discussion

response is that in-band delivery of parental rating information

suggest to add consideration that there might be a device setting to be retrieved

one thing is how information is conveyed

and second ...

missed point

can API be associated to services supported by the device

<bryan> parental control is a specific application of policy and preferences. It would be good for example to protect the privacy of a child, if a policy whether some content could be used was expressed, without disclosure of the reason (age). This could also be due to cultural/religious reasons.

add content protection and policy management as main title

<kaz> harrison from sk telecom

parental control of pages

lg: start an application on a smart tv that might be child like

this would be a good discussion for the TF

gius: should this be an issue for the application or browser

there should be parental control of a web application

need to be careful with web experiences in relation to parental control

<bryan> +1 to David's comment - it is unclear whether Parental Control needs to / should be addressed specifically in this scope

parental control is not the same across regions

gius: we are not trying to define new parental control

should this information be exposed

the TF should discuss how parental advisories are exposed

mark: my required interest is how to surface information that is required by law

if people want to in addition use it for other content I am ok

there is broadcast regulations to expose this information

<bryan> +1 to the comment that media advisory/disclosure (e.g. rating) is more in scope for MPTF than use of user characteristics (e.g. age) to *execute* "parental control"

david: we just want something to display to the user

disclosing information on the content is essential. if you control the presentation is something that is regulated and does not need to be addressed here

there might be privacy issues with exposing this information

if the video stops presenting

there could be information indicating why like parental control reasons

jeff: w3c staff tries to facilitate but if something is not done correctly the staff is there to help address

what is conclusion, inband focus

not clear on general view

to be discussed further

extraction from PC needs to be further discussed

another area possibly to be discussed is profiling in w3c

what do people think

it has been done in the past like tv css profile

jeff: yes

it is in the charter of w3c

gius: is it possible

jeff: we provide profile dependent on the request

clarify profile

mark: there are two specific issues

1 issue is that tv vendors who talk about lifecycle of tv and are not willing to update their software as often

w3c has a lot of optional parts like css is optional

html or xhtml is optional

media tags are optional

there should be specifics for indicating what is to be supported

there is a need

specifiy what is required from the optional list

2nd point raised in previous workshops that there might be a need for smaller profiles

for equipement that is lower capacity

jeff: clarify yes to what you have said

<bryan> JanL: re profiling, may need to avoid simplfying this to the Web only, other things e.g. DRM may need to be considered, e.g. IETF, 3GPP, etc - and these profiles are likely to be done elsewhere

<bryan> JanL: some examples would be useful

<bryan> http://specs.wacapps.net/2.0/jun2011/core/web-standards.html

profile are easy to do and are done by other organizations

this was essential for providing info what vendors have to support

russel: suggest a 3rd option for quering mechanisms for feature support

metadata that can be exposed could be beneficial

gius: ability to query support

the markup lagnuage may be different

a convention for a good a tv set

avoid reinventing the wheel

matt: need to careful exposing capabilities to adapt itself and profiling

it makes it difficult to adjust to different capabilities

for application developers

gius: profiling is important but the device can support more

<bryan> JanL: Profiles can help you discover what is supported. How features are expressed is an area to consider as well. Mechanisms to define what additional features (beyond the profile) are supported may also be needed.

let this be further discussed on the mailing list

another topic is testing

there is a wg that is charted for this

philip: it will be ready in the next 2 weeks

gius: in the charter is says to cooperate with other groups

<yosuke> http://www.w3.org/2011/05/testing-ig-charter.html

what is scope?

it is a framework of test

most people will be interested in the IG

clarification that each spec has its test specs

the WG will be looking at improving APIs for testing

the IG will cooperate with other groups and test framework

mark: it would be useful to give an overview of test strategy in w3c

like what is tested and certification

phil: there is an extensive test set

there is a css test suite but no certification

mark: if there are other organizations that are interested in testing can use the recommended tools coming from the IG

jeff: there isn't a large staff in w3c but the intention is to give a framework to facilitate

testing by developers

on the cerfitication point there is at least one organization that is in the this room posted yesterday that we do certification

w3c is interested in discussion over certification efforts

mark: it would be useful for talking to other organizations are written down

if the browser vendor is willing to provide test suites that is great but if that is not working out then it is necessary to scope out if there is funding necessary to help with certification process

jeff: open for conversation

the IG charter states certification should be done in liaison and not part of w3c

clarification that the IG charter is that of the testing ig

russel: there was a concern in the workshop that other SDO's going off but is willing w3c to acknowledge the cert work by other groups

jeff: we are willing to cooperate, if community points at a group w3c is willing to look at it closer

dave: there are two categories

1, mpeg provides codecs

2. bluray integrates techn's

2nd category gives an end result across solution

w3c provides tools and other groups are more prepared for providing certification

russel: oipf, dlna will have their own cert

there will not be a unified standard

<bryan> JanL: answering Russell's comment (re IETF, DLNA, etc having their own certifications), its in their interest to ensure their certifications are compatible

mark: there is still a gap

which the profile addresses

the optionality may differ between groups

agree on the test cases

strategy

they will have incompatability pools

need one decision

w3c could create a profile for html5 which dlna and oipf can refer to

bob: even if w3c makes this kind of work others can still subset

it is up to dlna and oipf to coordinate feature set

gius: it can take a long time to define a profile

in w3c

profiling is evil

we have too much work and work with profiles

david: from service provider it would be great to have a full set support and not individual options

working with lowest common denominator

mark: there are too many options

profile achieves is to limit too much optionality

dave: web is a moving target which is a challenge to get profiling to work

russel: there are very real costs for all the options for a CE vendor to support all optionality

jerry: service provider perspective is that we provide a service does not work. that kind of service requires certification and that it will work e2e

we need to know that that work will work

there is a class of services that we need to know that work and are certified

we need to end

the discussion

this group needs to discuss with the new test IG once created

what is relation with other standard groups

philip: the liaison is done with many groups

<jeff__> W3C liaison relationships: http://www.w3.org/2001/11/StdLiaison

gius: it is important to have liaison dialog

another topic is that we may need a device API

do we need to create a WG like DAP

parental control was something mentioned as needed

bob: this api is related to service and it is hard to discuss on a generic abstract way as "device"

igarashi: we confuse what is tv

the api for tv services

recommend call it TV services

sergey: caution that in the context of multiscreen TV service may apply to other types of devices

devices that can perform rendering

jonson: delivery TV services that create additional requirements on device

device is specific data that is typically not exposed by browser

what are the device kind requirements that may be needed within html

what kind of device may be restircted by content provider

that go beyond what is in the application

gius: is there a unified way to control a feature

can be done in both layers

needs further discussion and more detailed use cases

last point if there anything that needs to be added in this list?

philip: best practices for this use cases

for mobile best practice it was very much appreciated

by developers

sergey: we have an implicit guide on a profile for the mobile

lg: explain how process of TF works

LUNCH

PM1: Home Network Task Force Requirements document - Giuseppe Pascale

Scribe:

Christian Fuhrhop

Summary of activities

Going through comments now

Document availebla on mailing list

Comments by Samsung, Russell will explain details

<Alan> s /availebla/available/

Phraseing: sharing vs. access - access is the preferred phrasing.

<kaz> [ The file Giuseppe is displaying is archived at: http://lists.w3.org/Archives/Public/public-web-and-tv/2011Sep/att-0076/01-part ]

<kaz> [ please refer to the above URI, if you have problem with seeing the text on the screen. ]

Russell: 'Native interface on device' not well defined

Guiseppe: It's the in-built GUI

Russell: Might propriatary might be a better phrasing?

Mark: But not all are proprietary - that would be too restrictive phrasing.

Matt: Introduction section is currently too restricted to media streaming issues.

Suggestion by Matt was to be copied to IRC, but he lost net access.

<MattH> """There is also interest in using web technologies to create applications that can control, or respond to, the playback of media content by other devices and communicate with other web applications within the home network. These capabilities will enable multiple devices to work together to create a unified experience involving a close coupling of television and web content.

<MattH> """

Definition of 'application' was changed from 'collectiion of documents' to 'computer software'.

Bryan: Original phrasing is more appropriate.

<bryan> the document model is more accurate than "computer software" for Web applications

Russell: Wikipedia uses 'computer software' in definition of application.

Current definition fits more 'web application' than application.

Mark: But basically in the context an application *is* a web application.

<MattH> (for the purposes of the minutes: the quote I suggested additional paragraph for 'introduction' section)

Staying with original text.

Russell: Are documents named entities?

Mark: Document is defined in HTML 5 spec.

Matt: In many cases an application is seen as a running application.

<bryan> the better wikipedia definition is at http://en.wikipedia.org/wiki/Web_application: i.e. "A web application is an application that is accessed over a network such as the Internet or an intranet. The term may also mean a computer software application that is hosted in a browser-controlled environment (e.g. a Java applet)[citation needed] or coded in a browser-supported language (such as JavaScript, combined with a browser-rendered markup language

<bryan> like HTML) and reliant on a common web browser to render the application executable."

Guiseppe: Comment on Home Networks was merged already into document.
... Item is used in various ways in document. Might be useful to reference as UPnP item in UPnP use cases to distinguish.

Same for media player and media renderer.

Defintion of item as being described as being implemented "using XML documents and XSD schemas" implies UPnP.

Guiseppe: Try some editorial changes offline to better express terms.

Bryan: 'media binary' to restrictive, prefer 'media file/stream/resources/assets'

Guiseppe: Media resources.

Definition of control point is missing. (UPnP Jargon)

Russell: 'Controller' might be better word.

AP to Russell: Define 'control point' or 'controller'

David Mays: EPG is not defined - might not be generally known.

Russell: Just expand acronym once in document.
... Under 'Service Discovery' is 'type of service' sufficiently well defined?

Guiseppe: Admittedly it's vague. Trying not to define/imply too much here.
... Type can have different mappings based on underlying protocol.

Russell: Just wanted some clarity of defintion, but we can keep it vague to avoid locking outselves in.
... Would prefer 'classes' instead of 'type', though.

<kaz> fyi, the minutes from ws day 1 are available at: http://www.w3.org/2011/09/19-webtvws-minutes.html

<kaz> day 2 are available at: http://www.w3.org/2011/09/20-webtvws-minutes.html

Just remove the qualifier 'type' and just 'search for services', which implies a certain type anyway.

Guiseppe: 'Type' probably was meant to mean protocol.
... but removing 'type' is fine by me as well.

Jean-Claude: Two 'types' used in this section - type of protocol and type of service - this might have caused confusion.

Bryan: If type is meant more generic and since type is an identifyer, just saying 'identify' might be enough.
... Type od discovered service is different from type of protocol of service.

Guiseppe: Application needs to know which type of protocol the service is using.

Russell: Are we saying the problem should be split?

Having discovery protocol, enumeration and than map that to some common set of renderers?

Joe: How many of these detail decisions need to be worked out in the working group?

Guiseppe: If we generally can't work things out directly, we should move on and leave it to the working group.

<MattH> suggested wording: "Nevertheless conforming specifications should provide a means for application search for specific services and to be able to determine the means by which it should communicate with that service."

Guiseppe: Suggestion above seems like a useful wording, copies it to document.

Jean-Claude: Application discovery implies service discovery, but also inplies service advertisement.

Russell: It might advertise itself as a device.

Leaving phrasing as is.

'Russell: Content Advertisement - not really a requirement - might just be a description with some separate update service.

Changed to Content Description

Jean-Claude: Question: content discovery is service discovery plus communication.

So is a separate content discovery really useful/needed?

Guiseppe: But it is so fundamental that it should be mentioned and not hidden in other use cases.
... If we remove content advertisement and replace it with content description, then content discovery is probably not needed.

And assume it is a service on a device.

Back to Content Description - replace 'expose content' with 'expose content through a service' to avoid ambiguity.

Guiseppe: Should we discuss it in the group later?

Russell: As far as I am concerned, with the current changes it's sufficient.

Another rephrasing 'expose content description to a service'

Generally accepted.

*COFFEE BREAK*

*BREAK FINISHED*

PM2: Home Network Task Force Requirements document (contd.) (Giuseppe Pascale)

Scribe:

Kaz Ashimura

Guiseppe: Which message we want to give to the working group that will take over our work?

<kaz> scribenick: kaz

giuseppe: comments from Mark Vickers?

mav: discovered gap during the workshop

<Fuhrhop> Mark: Vendors want to take our use cases, try that out and find whether there are gaps.

<Fuhrhop> Mark: Device discovery we have prototyped and written code and APIs were being proposed.

mav: a lot of use cases on gaps
... I'd like to focus
... service discovery we surely have gaps
... would like to say to WGs this is a gap
... I'd suggest two motivations
... use cases and missing capability

giuseppe: agree
... from editorial viewpoint
... use this session "categorization" for that purpose
... identifying three/four key requirements

jc: saying "key requirements", I'm not sure
... Mark said "gaps"

giuseppe: I mean "requirements and gaps"

jc: first part should identify gaps

giuseppe: the text says "the following requirements..."
... we can change the structure

igarashi: discovery is important as a topic
... but distinction between "high-level api" and "low-level api" is important
... we should clarify it
... "discovery" discussion also needs that distinction

giuseppe: do we still need "high-level APIs" ?

bob: low-level protocol enables high-level protocols

matt: what's the minimum requiremtns for the gaps?
... complex javascript would be complicated

mav: I think that this is maybe something browser vendors could verify
... Chris?

(Chris left)

mav: we have a lot of use cases for Home Networking
... we do know the biggest topic is "discovery"
... potentially other high-level APIs would be useful
... could be start as a library
... may be standardized

<bryan> e.g. see the options described in mail list item http://lists.w3.org/Archives/Public/public-web-and-tv/2011Sep/0099.html

mav: or the WG could start with low-level APIs

david: one of my colleagues says this way of approach would be problematic
... we tend to go for low-level APIs

mav: two things we're talking
... 1. process for taking
... 2. specific proposal for APIs
... would suggest we start with high-level javascript library
... those libraries could be build-in
... regarding David Singer point
... a Web page might require geolocation
... issue on tracking

bryan: put URI on IRC
... e.g. see the options described in mail list item http://lists.w3.org/Archives/Public/public-web-and-tv/2011Sep/0099.html
... you could obviously create a library on the top of low-level APIs
... but what does low-level API mean?
... ability for listning to a specific protocol?

giuseppe: my view
... proposal by Opera and CableLabs

(people.opera.com/...)

giuseppe: this is only about discovery

<ph> http://people.opera.com/richt/release/specs/discovery/Overview.html

giuseppe: user agent has access to discovery capability
... XMLHTTPRequest, and so on

bryan: it's kind of one-sided
... "4. Obtaining a newworked service"
... don't think high-level library is necessary

bob: this is what I gave a demo
... we want to implement this
... we have implemented
... has both zeroconf and upnp capabilities
... the reason why we are for this approach is
... security pieces is embeded in browser

giuseppe: the level of abstraction is not very left to applications
... minimum level is left to apps
... main part is for browser

igarashi: in terms of abstraction, we might want to see OSI layers

jan: it introducing "discovery"
... we'd need at least low-level APIs for discovery
... application to application communication
... advertizement
... not only discovery but also advertizement

giuseppe: service advertizement and service discovery

bryan: the use case of advertizement
... advertizement facilitate
... is discovery certivied, e.g., DLNA, UPnP?

giuseppe: protocol discussion is out of scope
... communication between applications distibuted to two devices

sergey: certification is for implementations

bryan: we launch 30-40 mobile devices
... can get DLNA certification?

giuseppe: that's problem between you and DLNA
... not problem with the spec itself

jan: don't think it's a issue for us as application developers

narm: there are enough DLNA guys here
... but not sure we can talk as DLNA

jeff: we have a situation here
... this group is requesting some discovery API

<bryan> the point is that a user of DLNA may not need to be certified, but a device that intends to support advertisement and provision of DLNA-specified services/protocols probably needs some degree of certification, and that impacts the process of device certification and launch

jeff: what I didn't understand is...
... APIs should be done in a standard way
... is the opinion as a person or as the rep of the company?

david: general question on discovery
... the way you hook-up devices
... finding content should be done in more standardized way
... distributed across home network

jeff: is there a way we get people, e.g., David or Chris

david: I may be wrong

jeff: we have whole industry
... I think it seems people are engaged

bob: discovery topic is a bug for HTML5
... we've been discussing
... one of the browser vendors responded this is not a stupid idea
... we're talking about security as well
... we actually have two browser vendors who support this idea
... we should have some verification

igarashi: would make some comments
... I have same concern as David's
... depends on what requirement is important
... we need to clarify what "we" want
... we've been discussing "high-level APIs" and "low-level APIs"
... don't oppose "high-level APIs" but need clarification
... would ask browser venders, etc., for opinion

mav: can make it concrete
... if we have a TV that has a Web browser
... and the browser is the only application environment
... we can deliver new IP stream
... and another case
... embedded app environment in set top boxes
... if you recorded your favorite TV programs
... the issue is if I now delivered the content using HTML5
... if we have only HTML5, we need to have a standardized way

david: show a Web page on Safari
... the user can easily go to App store, etc.
... build in browsers
... a service provider could use Bonjour
... some can use UPnP

mav: excactly an issue
... a set top box can list protocols available
... if I click on American idol show
... the box might say "you have same program last week"

jan: got mike :)
... example was excellent
... if we have a managed cable box
... managed by a cable operator
... I would categorized managed ways of discovery
... ownership and security
... if you take a browser over the top, would it provide discovery
... making different shake-hand
... we're managing discovery

russell: propagate requirements
... I'd like plug-in for JavaScript?

giuseppe: what do you mean?

russell: the one could be moved on any kind of browsers

clarke: we implemented low-level APIs using Java Applet

russell: I'm not saying about Java Applet, but JavaScript library

(hot discussion)

bryan: one comment
... not just TV but any kind of ubiquitous devices, e.g., mobile
... whatever environment could handle JavaScript
... devices could be a home gateway

giusepp: we did focus on service discovery and service exposure (or advertizement)
... do we agree on this?
... and how to describe?
... we could rephraze the section
... basic gaps we feel the existing mechanism doesn't cover
... how we really implement discovery and advertizement
... do we agree?

igarashi: basically ok
... core requirement and service discovery
... and would include application communication and service communication
... don't understand why you exclude them
... if we think XMLHTTPRequest is important, we should include it as well

mav: we should describe "the HNTF is following the following key gaps"

giusepp: we don't know there is a gap

igarashi: can live with that

jan: there is a gap
... XMLHTTPRequest, etc., are server-side
... not necessarilly client-side, but we should be able to consider server-side

igarashi: that might be a gap
... but we can consider WebSockets as well
... both sides are clients

jc: if you implement service advertizement, you implement eplosure, capability to receive actions
... and to reply
... HTTP daemon

jan: I'd see a use case

clarke: have implementation

giuseppe: would see resolution
... let's see "Next Steps" section
... heard some concerns from somebody in the group

mav: we have an opportunity during TPAC 2011
... to talk about with the other groups, e.g., HTML WG, Device APIs
... with a focus on the gaps

jerry: think the home network is more than device APIs
... close these gaps within home network environment
... need a group for HTML5 for home network

igarashi: SONY also express our preference to have a separate group
... we don't need to open a big umbrella like "Device APIs"
... this APIs could be discussed within the existing Device APIs WG

<Jerry> correction home networking not related to device api's

igarashi: but we should have a separate group

jeff: there has to be good discussion within the IG
... including Web browser vendors
... we called the AC Rep
... (looking at David Singer)

<dsinger> ...who looks away, waving his hands....

jeff: would like opinion from Chris on the topic list

igarashi: giuseppe, if DeviceAPI or another new group discuss this topic, how that group should treat with this?

giuseppe: we start from gaps

igarashi: the group also should start with gaps?

giuseppe: yes

jerry: my concern is we've identified gaps
... but not identified all the requirements yet
... if we hand these gaps to an independent group, would it be ok?

giuseppe: the group should include ourselves
... a WG should be a better place for detailed technical discussion
... out of time...

mav: could we rephraze and say "we have these gaps"?

giuseppe: we might want to have discussion by key participants

jan: I did scanned the text but not sure about communication of service

giuseppe: would encourage people to have offline discussion
... think we're done for today

clarke: and see you tomorrow for MPTF at 9am

giuseppe: tx