W3C home > Mailing lists > Public > public-web-and-tv@w3.org > August 2011

Re: [HOME_NETWORK_TF] Minutes call 2011-08-16

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 17 Aug 2011 00:57:42 +0900
Message-ID: <4E4A9376.80603@w3.org>
To: Clarke Stevens <C.Stevens@CableLabs.com>
CC: public-web-and-tv@w3.org
Hi Clarke and all,

I put my comments to Clarke's concern about how to maintain
consistency of related specifications on the IRC at the end of the
call, and would like to mention it here again.

-----------------
Clarke's concern
-----------------
>  Clarke: How do you maintain consistency if work is carried on in
>  different groups?
>
>  Francois: @@W3C Process is meant to address this.
>
>  Giuseppe: yes, and too many deliverables or too broad a scope may
>  hamper the progress of a group.
>  ... for the Media Pipeline TF, it seems more focused on extensions
>  to the video tag, so HTML WG sounds the right place for discussions.
>
>  Francois: yes, but not necessarily, it could be done in a separate
>  WG.
>
[...]
>  <Clarke> My point was that if anyone is concerned about alignment
>  between working groups they should participate in both working
>  groups.

---------------
Kaz's comments
---------------
I put the following comments on the IRC at the bottom of the call:

1. We should not re-invent "wheels".  I mean we should not create a
    new WG for Home Network APIs if there are already WGs who work for
    similar topics, e.g., HTML, DAP and WebApps.

2. We have the Hypertext Coordination Group for inter-group
    coordination.  WG/IG Chairs attend its bi-weekly telephone
    conferences and discuss how to maintain consistency, etc.

3 If needed we could consider some meta mechanism to integrate several
   specifications consistently like SMIL, RDF and MMI.

Of course we could create a new WG to define a separate specification,
and it actually might be easier and better.  However, we should be very
careful our making decision.  As you know, it would be a bit confusing
if there are too many options like HTML5 video and SVG video...

Thanks,

Kazuyuki


On 08/17/2011 12:19 AM, Francois Daoust wrote:
> Hi,
>
> The minutes of today's TF call are available at:
> http://www.w3.org/2011/08/16-webtv-minutes.html
>
> ... and copied as raw text below.
>
> In really short:
> - Most issues closed.
> - People should look at use cases/requirements document and send comments on the mailing-list
> - People should take a stab at setting requirements priorities so that this can be discussed next week
>
> Thanks,
> Francois.
>
>
>
> -----
> Home Network TF (Web and TV IG) Teleconference
>
> 16 Aug 2011
>
> [2]Agenda
>
> [2] http://lists.w3.org/Archives/Public/public-web-and-tv/2011Aug/0093.html
>
> See also: [3]IRC log
>
> [3] http://www.w3.org/2011/08/16-webtv-irc
>
> Attendees
>
> Present
> Russell_Berkoff, Kazuyuki, MattH, francois, Clarke,
> David_Corvoysier, JanL, Tatsuya_Igarashi, Giuseppe, Bob_Lund,
> Richard_Bardini
>
> Regrets
> Chair
> Giuseppe
>
> Scribe
> francois
>
> Contents
>
> * [4]Topics
> 1. [5]Requirements document
> 2. [6]Propose text to expand ISSUE-26 and ISSUE-28 to address
> Jan's comment (ACTION-69)
> 3. [7]See if ISSUE-14 and ISSUE-30 can be merged (ACTION-66)
> 4. [8]Missing HNTF Deliverables
> 5. [9]Comment on Home Network Enabled User-Agent use cases
> * [10]Summary of Action Items
> _________________________________________________________
>
> Giuseppe: comment on the agenda?
>
> Requirements document
>
> <giuseppe>
> [11]http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requireme
> nts
>
> [11] http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements
>
> Giuseppe: I've done some work this week. Not completely done, but
> almost.
> ... merging use cases and extracting requirements.
> ... First of all, I'd like to summarize our plan for this document.
> ... First, finalize this by the end of this month.
> ... Then include the rest of the IG in the discussion to bring
> further comments.
> ... Then we'll bring this document to the IG F2F for final review,
> and then document ready can be published.
> ... I tried to structure the document with a requirements section.
> ... I tried to link the use cases with the requirements.
> ... I'd like to ask everyone to go through the list of requirements
> and check associations.
> ... Propose updates when you're concerned about something.
> ... What is really important is the requirements, the use cases
> could perhaps be marked as informative.
> ... They are very important to understand the requirements, but
> maybe this section could be marked as informative.
> ... Then there's a section on security.
> ... I welcome any comment on the document.
> ... The whole document needs to be approved in the end, even if we
> approved all use cases. Open issues need to be addressed if they
> exist.
>
> <MattH> +q
>
> Giuseppe: If disagreement, we'll add a section to highlight the lack
> of consensus within the group.
>
> <JanL> +q
>
> Narm: Any idea how to indicate the priorities?
>
> Giuseppe: good question. This needs to be reflected somehow in the
> document. I don't have a strong opinion.
> ... One way could be to identify requirements by number and add a
> mapping table with 3 priority levels.
> ... in a dedicated section.
>
> <narm_gadiraju> narm is the one who spoke
>
> Matt: Thanks, great job. I had a little look earlier. Looking at
> requirements Application communication. We might clarify that it is
> for direct communication and not for communication through
> intermediaries.
>
> Giuseppe: OK, I'd like to suggest you bring this comment to the
> mailing-list so that others can comment.
>
> Matt: Sure.
>
> Giuseppe: About use cases, people will have to check mapping to
> requirements.
>
> Jan: the doc includes links to the original issue and use cases.
> ... and copies the text to the original issue.
> ... Do you want us to update the initial text or do you plan to
> remove this "Original Proposal" link afterwards?
>
> Giuseppe: I plan to remove the links afterwards.
> ... Email discussions should be good to update text in use cases.
>
> francois: @@@on requirements that would better be addressed at
> "conforming specifications"
>
> Giuseppe: Got it, ok with the approach?
>
> Kaz: yes, useful to add, could perhaps be done in the working group
> that takes the requirements spec.
> ... Also mention the working group that is likely to take on the
> work.
> ... Francois comment is good but too advanced, I think.
> ... We don't really need that clarification for this requirements
> document.
>
> Giuseppe: It's an easy change to do, and I'm fine with it.
> ... Any other comment?
>
> [none heard]
>
> Propose text to expand ISSUE-26 and ISSUE-28 to address Jan's comment
> (ACTION-69)
>
> ACTION-69?
>
> <trackbot> ACTION-69 -- Russell Berkoff to propose text to expand
> ISSUE-26 and ISSUE-28 to address Jan's comment -- due 2011-08-16 --
> OPEN
>
> <trackbot> [12]http://www.w3.org/2011/webtv/track/actions/69
>
> [12] http://www.w3.org/2011/webtv/track/actions/69
>
> Jan: it looks perfect. Very good addition.
> ... Question is what do I do with the initial text?
>
> Giuseppe: I'll deal with it. So we can close the issues and I'll
> merge the text Russell proposed in the Requirements document.
>
> <scribe> ACTION: Giuseppe to update text of ISSUE-26 and ISSUE-28
> based with text proposed by Russell in ACTION-69 [recorded in
> [13]http://www.w3.org/2011/08/16-webtv-minutes.html#action01]
>
> <trackbot> Created ACTION-71 - Update text of ISSUE-26 and ISSUE-28
> based with text proposed by Russell in ACTION-69 [on Giuseppe
> Pascale - due 2011-08-23].
>
> close ACTION-69
>
> <trackbot> ACTION-69 Propose text to expand ISSUE-26 and ISSUE-28 to
> address Jan's comment closed
>
> close ISSUE-26
>
> <trackbot> ISSUE-26 Home Network Enabled User Agent - Network Media
> Player closed
>
> close ISSUE-28
>
> <trackbot> ISSUE-28 Home Network Enabled User-Agent - Network Media
> Controller closed
>
> See if ISSUE-14 and ISSUE-30 can be merged (ACTION-66)
>
> action-66?
>
> <trackbot> ACTION-66 -- Russell Berkoff to see if ISSUE-14 and
> ISSUE-30 can be merged -- due 2011-08-09 -- OPEN
>
> <trackbot> [14]http://www.w3.org/2011/webtv/track/actions/66
>
> [14] http://www.w3.org/2011/webtv/track/actions/66
>
> Russell: ISSUE-14 is on services not necessarily connected to a
> target in my view.
> ... whereas ISSUE-30 is really about support of devices and then
> services as a means to change the state of the device.
> ... I tried to give examples of differences in my email.
>
> Giuseppe: My impression from the description of ISSUE-14 is that
> it's not particularly either stateless or stateful, so I would think
> your use case is included here.
>
> Russell: ISSUE-14 does not have a strong notion of discovering a
> device, rather a notion of discovering a service.
> ... whereas ISSUE-30 is more bound to a device, and then discovery
> of services on that device.
>
> Giuseppe: I would be fine to keep ISSUE-30 in as a way to clarify
> what use cases we're trying to cover, even though I think it's
> pretty generic.
> ... It will probably generate the same requirements though.
>
> Bob: I agree with you Giuseppe. The distinction between discovering
> devices and discovering services on devices would generate the same
> requirements.
>
> Giuseppe: I would like to improve the use case that is in. Could you
> perhaps suggest a better wording of use case 1?
> ... Wait, I was not looking at the right issue.
> ... I believe the action was mis-recorded, it's ISSUE-4, not
> ISSUE-14.
> ... So U1 in the requirements document.
> ... We can probably extend the use case a little bit, could you look
> into it?
>
> Russell: OK, I'll have a look.
>
> Giuseppe: Conclusion is to look at U1 for ISSUE-4 and propose text
> if it's not enough.
> ... We'll close action and issue next week.
>
> Missing HNTF Deliverables
>
> <giuseppe>
> [15]http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Charter#D
> eliverables
>
> [15] http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Charter#Deliverables
>
> Giuseppe: One is gap. That's covered with use cases and requirements
> document.
> ... Another item is to categorize all the use cases/requirements.
> ... I'd be happy to hear your opinions on this.
> ... If they are equally important, we can skip this categorisation
> phase.
> ... Looking at the different options we have in the charter. [going
> through the list].
> ... I need input from the group here.
> ... i.e. shoot for option 6, with liaisons to some groups perhaps.
>
> Matt: We already know that DAP is to take device discovery. [lots of
> echo]. I would suggest that's a main chunk of what we're trying to
> achieve, so moving to there sounds good.
>
> Giuseppe: Right, that's exactly the kind of input I'm looking for,
> so we can propose recommendations to W3C Director.
> ... It seems a good idea to start with the DAP group since it's
> already listed in the new charter, and then check from there what
> needs to be defined on top of that later on.
>
> Clarke: In order for the result of the work to be consistent, it may
> make sense to put all our requirements into one working group.
>
> Giuseppe: I'm not sure if it's the best thing to do.
> ... If requirements on Media Pipeline TF impact on the video,
> perhaps the HTML WG is better for that.
> ... But some of our requirements, we may suggest to have another WG
> handle them.
>
> Clarke: How do you maintain consistency if work is carried on in
> different groups?
>
> <Clarke> That was Clarke talking, not Bob
>
> <Clarke> thanks
>
> Francois: @@W3C Process is meant to address this.
>
> Giuseppe: yes, and too many deliverables or too broad a scope may
> hamper the progress of a group.
> ... for the Media Pipeline TF, it seems more focused on extensions
> to the video tag, so HTML WG sounds the right place for discussions.
>
> Francois: yes, but not necessarily, it could be done in a separate
> WG.
>
> [scribe missed last exchange]
>
> <Clarke> My point was that if anyone is concerned about alignment
> between working groups they should participate in both working
> groups.
>
> Giuseppe: On the WG part, I would propose to give the document as it
> is to DAP, as it seems to be matching their charter.
> ... When it comes to categorize use cases/requirements, I would say
> it falls in the category "new requirements for a WG", so basically
> we're good.
> ... That's my proposal.
> ... Feel free to comment. The priority discussion is still open.
>
> Bob: I have a suggestion on priorities. Set of requirements that
> represent the minimal amount of work you'd need to do to enable
> scenarios.
> ... That would create a mandatory set of requirements, and a
> "larger" set of requirements, leading to an easy distinction.
>
> Giuseppe: yes, sounds like a good approach.
> ... Some of the requirements may require more investigation, such as
> migration scenarios for instance, others may be easier to do. I'm
> fine with your distinction.
>
> Clarke: we could ask someone to volunteer to take a first stab.
> ... s/someone/a few people/
> ... to have something to start from and see if adjustment is needed.
>
> Giuseppe: Yes, I'd like to ask people here to categorize the
> requirements, so we can review that next week.
> ... Fine with everybody?
>
> [nodding "heard"]
>
> Kaz: Question about relationship with RFC2119.
> ... First priority is MUST statements, right?
>
> Giuseppe: I was more thinking about a time schedule rather than
> MUST/SHOULD.
> ... We need base functionality to enable basic home networking
> scenarios, then more to build on top of it.
>
> Kaz: Yes, it could be done later, fine to proceed with priority in
> the TF.
>
> Giuseppe: I think these are two different things, actually, so I
> would proceed with priorities even in the final report.
>
> Giuseppe: Please send me (or to the mailing-list) a list of which
> requirements should be in which category, and I'll make a summary
> next week for discussion.
>
> Comment on Home Network Enabled User-Agent use cases
>
> <giuseppe>
> [16]http://lists.w3.org/Archives/Public/public-web-and-tv/2011Aug/00
> 85.html
>
> [16] http://lists.w3.org/Archives/Public/public-web-and-tv/2011Aug/0085.html
>
> [Giuseppe and Russell about status of email exchanges]
>
> <giuseppe> "Provide a mean for applications to control some of the
> parameters that may be needed to be expose to support
> well-established home network protocols. A more detailed analysis is
> needed to identify such parameters and a way to specify them in a
> transport agnostic way"
>
> Giuseppe: we need to identify requirements, we cannot be too vague.
> My suggestion would be to look at precise requirements so that a WG
> can action these requirements.
> ... We could phrase as "we've identified a gap here on transport
> headers, and the WG should look into these"
>
> Russell: It's a fairly broad topic, so simple requirements might
> help.
>
> Giuseppe: It wasn't clear to me what the sentence covered.
>
> Russell: It used to say DLNA, but there was a request to remove
> mentions of DLNA.
>
> Giuseppe: but the use case is not about DLNA.
> ... I'm not suggesting to change the meaning, merely to clarify the
> requirement.
>
> Russell: The point of the response was that the headers provide info
> for the user-agent, the application and playback engine.
>
> Giuseppe: Again, I'm not suggesting to change the meaning, but to
> clarify and point the WG to that saying it needs to be addressed.
> ... Probably easier if you reply on the actual text.
> ... Same for the other two points.
> ... Let's conclude on the mailing-list.
>
> Russell: How do people in the TF feel about compatibility forward or
> backward?
>
> Jan: Could you provide examples?
>
> Russell: Dealing with older user-agents, for instance.
>
> Jan: sounds like a core architectural design point.
>
> <Clarke> I think that was Jan, not Clarke
>
> Giuseppe: I don't think it's part of a spec, more a point for the
> community to check how they can support the feature in old browsers.
>
> Russell: If people feel this way, ok to dropping.
>
> [scribe missed precise comments because of echo]
>
> Giuseppe: ok, running out of time, closing call now. Have a good
> day!
>
> [Call adjourned]
>
> <kaz> [ btw, some clarification for Clarke's concern: 1. we should
> not invent "wheels" again, 2. we have Hypertext Coordination Group
> formed by WG/IG Chairs for inter-group coordination, 3 if needed we
> could consider some meta mechanism like SMIL, RDF and MMI to
> integrate several specifications consistently ]
>
> Summary of Action Items
>
> [NEW] ACTION: Giuseppe to update text of ISSUE-26 and ISSUE-28 based
> with text proposed by Russell in ACTION-69 [recorded in
> [17]http://www.w3.org/2011/08/16-webtv-minutes.html#action01]
>
> [End of minutes]
>
>

-- 
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: +81 466 49 1170
Received on Tuesday, 16 August 2011 15:57:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 16 August 2011 15:57:24 GMT