- From: Francois Daoust <fd@w3.org>
- Date: Thu, 18 Aug 2011 16:44:28 +0200
- To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Hi, Here's a first stab at setting priorities for requirements. I'm more or less trying to follow a absolutely-needed/not-absolutely pattern here. Please take that as input with no string attached. Feel free to discard it entirely in particular. I don't pretend I've thought thoroughly about it, it's meant to trigger comments, not to provide answers ;) (FWIW, I'll be away next two weeks in any case) Priority meanings: P1: higher priority P2: lower priority The Requirements below are listed in the order of the requirements document: Service Discovery Content Discovery Content Players Discovery P1. I don't think we can move forward without addressing these requirements. Content Advertisement Services Advertisement P2. I haven't given it much thoughts. It sounds advertisement could be done at a later stage. I note the DAP working group has a couple of deliverables that could match those requirements though. Media Identification P2 as I think we can proceed without it. I note that sounds orthogonal to service discovery and could perhaps be done in parallel. Control of content players Playback of content Playback of live content 3 Box model Time-synchronization P1. These requirements seem core to enabling home networking scenarios. Accurate time-synchronization P2. "Accurate" carries "complex" somehow. It's useful, but can probably be done at a later stage. Application communication P2. I don't think it's vital as a first step. Content Protection P1. Graceful fallback is always good. Push migration Pull migration P2. The use cases are more advanced. Application trust level Access to home network services Prevent leaking of information P1. As in "no way to move forward without addressing security issues" HTH, Francois.
Received on Thursday, 18 August 2011 14:44:52 UTC