Home Networking Task Force -- 23 Aug 2011

Requirement document review

->http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements

giuseppe: review requirements document
a ... what do you think about just having use cases and requirements in requirements document and removing other sections?

Pending comments on Home Network Enabled User-Agent use cases

-> http://lists.w3.org/Archives/Public/public-web-and-tv/2011Aug/0085.html

Kaz, I'm acting as scribe, but I'm not sure I'm doing it right. You may want to check that things are getting recorded.

giuseppe: Do people agree with the change I proposed about the header?

russell: I'm okay with dropping the backwards compatibility requirement

Russell_Berkoff: we may want to continue to work on item number 1 (requirement that headers can issue commands, working information for UA, etc.)
... requirements should explicitly cover the three cases

Kaz, I knew I was forgetting something. Thanks

giuseppe: I'm concerned that the header issue may restrict application to a particular protocol.

Russell_Berkoff: why don't we split the difference and just identify the broad categories?

<mav> I'm not able to dial in. Keeps saying the conference is full.

giuseppe: look at the text I provided and make comments.

Russell_Berkoff: examples may clarify what the requirements should be
... so you will merge and make my requirements informative?

giuseppe: yes

Additional section about Related Works

-> http://lists.w3.org/Archives/Public/public-web-and-tv/2011Aug/0101.html Opera, CableLabs

-> http://lists.w3.org/Archives/Public/public-web-and-tv/2011Aug/0112.html BBC

giuseppe: next, additional section about related work
... just informative part for work members have done that helped generate use cases
... Do people agree with including this secion?
... referring to section in requirements document mentioning work from BBC, Opera, CableLabs

Russell_Berkoff: I'd like to add a submission to that section

<MattH> +q

giuseppe: You can mention material that is related to use cases (e.g. prototypes, previous work, etc.)

MattH: I think it sounds like an excellent idea to also include a reference to CEA 2014 with an explanation about why it is useful
... I'd also like to see some additional text about the CableLabs submission
... it should highlight thinks people would like to know.

Russell_Berkoff: I will include some additional text about CEA 2014

<giuseppe> ack

Narm: what is the reason for including this section?

giuseppe: It is just informative. It is good to provide the reader about related work people have been doing. It shows real prototyping work. It's just informative. No recommendation.
... having links to things we have to pay for or that are proprietary is not useful, but other things can be included. We should try not to let the section get too big.
... I will include submissions that have already been proposed. People can start proposing other items.

MattH: The particular work of this task force is a direct link that would enable communication on the home network. This is not a cloud-based service.

Bob: I agree. My comment was more focussed on being more specific on application to application on accessing a home networked service. You can see my suggested text.

giuseppe: I'm concerned about the term "client." It seems too vague.
... Maybe we can clarify using "services" and "devices"

MattH: Maybe use "application" instead of "client"

Bob: That's fine

<scribe> ACTION: giuseppe to replace "client" with "application" [recorded in http://www.w3.org/2011/08/23-webtv-minutes.html#action01]

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

Prioritization

giuseppe: next on the agenda is about priority of requirements
... Francois, and Matt and Bob have commented
... Mark V. suggested rating based on the value of "enabling" use cases

Russell_Berkoff: what are the relative advantages of this exercise?
... maybe working groups should determine importance of requirements

giuseppe: It is more feedback from the participants. Important requirements may help to make decisions so implementations can begin
... it doesn't limit the specification, but gives some guidance for the specification
... some use requirements enable many use cases. They may be more urgent
... it may be useful for the working committee
... Bob, do you want to go through your requirements?

Bob: Yes
... my first comment is on application trust level
... I think this is a second level priority. We've discussed low and high-level APIs and we decided that low-level were more important. This requirement implies a certain level of API in the user agent.

giuseppe: One option could indicate security requirements as high-priority

<MattH> +q

giuseppe: this will drive the solution. If a particular solution can't meet the requirement, then it points to a different solution.

Bob: By definition it's in scope if we make it a requirement.

<mav> i just joined (finally)

giuseppe: even with a low-level API you can have the discussion

Bob: it's not obvious to me that that is true
... without providing some generic JavaScript level trust infrastructure

giuseppe: we could remove security from a discussion of priority and just say separately that security is required.

Bob: can we put some language in the requirment and maybe the scope of that is dependent upon the architecture
... removing security from the priority discussion is fine

giuseppe: content protection

Bob: I don't think the API generated by this group will address that

<igarashi> would u spealk loundly? Russel.

Bob: maybe make it clear that the implementation must support DRM
... I think the requirement is out of scope.

giuseppe: I'm fine with removing it from scope

I think it's out of scope

I think "compatibility" with DRM systems is okay but more specifics are out of scope

giuseppe: take a look at the actual text and make suggestions to change or drop. I'm okay with dropping it.

narm_gadiraju: I think we can drop it

Russell_Berkoff: in CEA 2014 it just identifies DRM so the player can know what to do

Bob: I can provide some suggested text

<narm_gadiraju> I said we should not drop it but consider changing to include identification of DRMs

Russell_Berkoff: I will submit some text also

giuseppe: we will try to propose by next week since it's supposed to be our last call
... next is media identification

<narm_gadiraju> can the speaker, please speak up

Bob: my comment is that the API may determine the level that content indentificatio is relevant

<giuseppe> kaz, is priobably also "giuseppe" (I accidentaly attached it to me)

MattH: Do we need to split the discussion on requirements based on low or high-level APIs?

Bob: Whether they will ultimately be covered by an implementation is dependent on the API level

giuseppe: This may be a more generic requirement. Maybe it should be handled outside the priority discussion.
... maybe we consider it like security.

MattH: that makes sense

Russell_Berkoff: one thing not covered in requirements is any notion of home-to-home or groups of homes.
... not commonly discussed. UPnP says something about it in RemoteAccess:2. This may become more important.
... May want more discussion on this on reflector

giueseppe: I would rather say we have talked about it, but never really discussed it in detail. It may be a "phase 2" discussion.

Russell_Berkoff: maybe reference to future work

giuseppe: Just a metion would be too vague. I prefer to keep the document clear and address items the working group can work on.

MattH: maybe make a note to the task force to take this topic up later

Russell_Berkoff: some mention of it would be okay.

giuseppe: we can discuss it later

Bob: maybe there are several things like this that we want to consider in the future. Maybe a section of the report to document this.

giuseppe: that may be a good solution

- DRAFT -

Home Networking Task Force

23 Aug 2011

Attendees

Contents

Requirement document review

Pending comments on Home Network Enabled User-Agent use cases

Additional section about Related Works

Prioritization

Summary of Action Items

Scribe.perl diagnostic output