in 1.2: two bullet points for client and server --> remove servient

Re: TTWG charter

Invitation for review must be issued during each major standards-track document transition, including FPWD and CR, and should be issued when major changes occur in a specification.

Doesn't this duplicate process from the W3C Process document?

Privacy is a major concern for end users as the IoT greatly increases the amount of personal information that can be collected by service providers. We need to address privacy in some way, but how?

One idea is to state that this is an areas for study by the Interest Group and that this is expected to lead to new standardisation track work items.

Related ideas include metadata defining links to privacy policies, the role of stick policies, the need to track provenance to ensure that the data owner's privacy preferences are respected when data is combined from multiple owners, the relationship to authentication and access control, and likewise to trust assertions in general.

Re: TTWG charter

Add

• A W3C Recommendation for a new version of TTML Profiles for Internet Media Subtitles and Captions (IMSC).

to Deliverables.

in 1.1.: formulate a new bullet point for life cycle;

The document frames REST as a transport protocol and suggest to define abstract messaging on top of REST. REST is a transfer protocol and already embodies a well developed simple and reusable message layer.

WoT must accommodate REST as a transfer protocol and interact with the hypermedia controls provided by underlying REST transfer systems. That there will be systems that already know how to interact using the full REST distributed state machine. WoT should not be a replacement or alternative to REST architecture, but an augmentation that enables consistent interaction across many systems at web scale.

I'd like to work on the updated Pointer Events / Touch Events charter here on Github, in the open.

1.2: more explanation on independent of programming languages and API to react on life cycle;

We do not modify protocols

@plehegar see if https://github.com/w3c/charter-drafts/blob/gh-pages/draft-states.md meets your and team contacts' needs

@caribouW3 I refer to the tool we discussed to help team contacts in identifying the Reference Draft.

Re: TTWG charter

As needed, the Group will also coordinate with the HTML Accessibility Task Force and the HTML Working Group to contribute how to interoperably implement described video with the Open Web Platform.

Shouldn't this be under Coordination -> W3C Groups

Hi there,
The About section points to a Process Document section which in the 2015 version is numbered "5.2" (no longer "6.2".)

The draft PtrEvents WG charter says:

[[
This Working Group will reconcile the relationship and best features between these technologies.
]]

The use of "will" here implies the group will be expected to get both the TE and PE communities to agree on a single standard and, unfortunately, that doesn't seem possible, especially since both Apple and Yandex again voiced their disdain for PEs during WebApps 2015-Oct-25 meeting http://www.w3.org/2015/10/26-webapps-minutes.html#item04.

We need to decide whether to use the document licence or the software licence for our deliverables. Can be different licences depending on which document, but it's cleaner to just use the same one throughout.

1.3: seek for collaboration to define binding

In scope 1.1:
instead “abstraction layer on top” phrase support inter-platform standard. i.e. interoparability by providing technical standards which can be deployed and used as interplatform standards

Re: TTWG charter

Under

1. Publish a Recommendation for a new Timed Text Markup Language (TTML) 2 specification. In the process of producing this new revision, the Group WILL:

add:

f. Take into account features added to IMSC1

Proposals for the TTWG charter

*** 2. Deliverables ***

change:
A W3C Recommendation for TTML Text and Image Profiles for Internet Media Subtitles and Captions.
to:
A W3C Recommendation for TTML Text and Image Profiles for Internet Media Subtitles and Captions (IMSC1)

Add following:
A W3C Recommendation for a second version of TTML Text and Image Profiles for Internet Media Subtitles and Captions (IMSC2)

3.3 External Groups
shouldn't we add the Association of Radio Industries and Businesses (ARIB) which specified ARIB-TTML based on TTML ?

3.1 and 3.2
what is the difference of constraints for the TTWG between section 3.1 "W3C Groups" and 3.2 "Liaisons with W3C Groups"
Should clarify.

RE: TTWG charter

For each subgroup to be successful, it is expected to have 5 or more active participants for its duration.

What happens if it is not "successful" per this metric?

This repo seems like a good idea. Is there a template one could use to draft a charter, or other monkey-see monkey-do resources that can be pointed to.

Thanks

A comment raised during the call for review for the renewal of the Second Screen Working Group: in section 2, "at the time of charter approval" is better expressed as "at the time of the call for participation" because it is the formal notice of approval and initiation.

See comment in (member-only link):
https://lists.w3.org/Archives/Member/w3c-archive/2016Oct/0434.html

Part of the mission in the TTWG charter should be to improve interoperability between the HTML5 spec and the TTML specs. This should be done by defining how TTML can be used as "caption" or "subtitles" format for HTML5 text tracks. This requires the colloboration with other group (e.g. the Web Platform Working Group).

charter says : "Invitation for review must be issued during each major standards-track document transition, including FPWD and CR, and should be issued when major changes occur in a specification."

Isn't the "wide review be demonstrated for entering CR, which means during the last Working Draft version before CR ?
Should clarify.

2.1 of the charter says "including streams". This is already a very specific solution for an at the moment undefined/unmentioned problem. The problem I see is the support for time series. While streams can be a solution for that, most IoT protocols do not have support for this. Furthermore, we currently have no current practices for streaming, and hence no evaluation of its feasibility.

Proposal: replace "including streams" with "time series" in the charter.

Include an introduction section, not only scope at the beginning

In 3.1: put intrest group here and talk about the role

The figure in section 1, showing an architecture of proxies and scripts, does not seem to be an appropriate summary of the document. It seems to create an architectural context that is misleading with respect to the problems that we are solving.

Additionally, it seems to imply some architecture constraints that aren't discussed in depth and are not broadly agreed upon. Have we all agreed to implement chains of proxies? What does this architectural constraint induce in the way of desirable properties, and how do we know it doesn't introduce undesirable properties?

For analysis of architectural styles, constraints, and induced properties, I would follow an approach as laid out in chapter 4 of R. Fielding's dissertation, "Defining the web Architecture: Problems and Insights" at:
http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm

Overall, I would recommend paying more attention to FIelding and adopting a similar approach to architecture analysis and design.

Re: TTWG charter

The Working Group is expected to demonstrate at least two interoperable implementations of every available new feature in the recommendations.

interoperable is open to interpretation, e.g. are two presentation processors "interoperable" even if they do not talk to each other? It should be sufficient for the implementations to demonstrate compatibility with the specification.

Re: TTWG charter

Should the following be added to External Groups?

• ARIB (Japan) [ARIB uses TTML in its specifications]
• APEX (in-flight entertainment, http://apex.aero/) [APEX has expressed interest in using TTML in its specifications]

We won't be allowed to ignore privacy.

Privacy is a major concern for end users as the IoT greatly increases the amount of personal information that can be collected by service providers. We need to address privacy in some way, but how? One idea is to state that this is an area for study by the Interest Group and that this is expected to lead to new standardisation track work items.

Privacy is potentially complicated to address. The simplest approach is to define ways for the metadata to link to privacy policies. More complex approaches allow for declaring privacy preferences, and sti.k policies that accompany the data. This involves challenges around provenance, e.g. when a service combines data from different owners. Related challenges include authentication, access control and trust assertions in general.

I recommend we make privacy in scope for the working group, but avoid defining the work item and leave this for the IG and WG to clarify.

A comment raised during the call for review for the renewal of the Second Screen Working Group: in section 4, "half of a day" is ambiguous because it could mean 12 hours. Suggestion is to use "half a working day".

See comment in (member-only link):
https://lists.w3.org/Archives/Member/w3c-archive/2016Oct/0434.html

Picture which illustrates the use of TD, Bindings to Protocols and Scripting APIs

In the template, there is a section called Charter History, but with a note that this section is solely for charter extensions. However, it is at least customary to include a link to the previous charter, when rechartered rather than just extended.

I suggest fixing this by making the history section apply to both rechartering and extension (so it would not be included in a brand new charter). Add a todo paragraph saying "keep one of these". Keep the existing history table, as one option, and add a paragraph with a link to the previous charter, as a second option.

*Section 1 Scope: *

• I interpret the figure, which is an example, so that “Thing” in server A exposes a client API making it possible for the script in server A to interact with the Thing in server B. The Thing in server B exposes a server API that makes it possible for the script in server B to expose the resources (sensor and actuator) of this server to other servers and to web browsers. Correct? If so I am suggesting, for clarification reasons, that “client API” and “server API” is added to the figure. The reason is that “Thing” in the figure have different meanings for server A and for server B. In server A “Thing” exposes a client API and in server B “Thing” exposes a server API. So it must be clear in the figure whether “Thing” means a proxy for a thing in another server/device or if Thing represents a server exposing a thing server API.
• I do not understand the statement under the figure:
  “The proxy on server A could be set up by a script on that server, or by a script on server B.”
  I would instead think that the proxy, i.e. the Thing on server A, is created either as an output of a discovery API provided in server A or by reading a Thing Description from server B.

*Section 1.2 Scripting APIs: *
I assume that the APIs standardized are applicable both for User Agents/Browsers as well as for web server applications such as node.js. As W3C traditionally has specified APIs for User Agents this may have to be clarified in the charter. In addition, it may be good to clarify that the scope covers support for a client role interacting with a Thing as well as support for a server role, exposing a Thing.

Above may be obvious for us in the WoT IG but it may not be obvious for anyone outside of the IG.

*Section 1.3 Bindings to Common Protocols: *
Maybe we could be more tangible here, give some example and clarify what we think should be standardized. I assume that what we want is to define how certain items in the TD is mapped on certain protocols. So, for example, define how an action in the TD is mapped to CoAP POST, an event is mapped to the responses of a CoAP Observe request (or reception of a POST from the other Thing), etc. How far should we go? Only RESTFul protocols or include pub-sub and message oriented protocols such as XMPP and websockets as well?

*Section 1.4 Out of Scope: *
I assume that it should be “URI mappings for non-RESTful protocols”, not “URI mappings for non-resourceful protocols”

1.1: drop third bullet

What should the Web of Things WG charter say in respect to coordination with external organizations? Is it okay for this coordination to be driven by the Web of Things Interest Group?

The current template reads, in the Meeting Schedule line of the header, "no more than 3 per year". I suggest changing it to "usually no more than 3 per year" to allow ad-hoc extra meetings if the WG needs them.

RE: TTWG charter

Change

The Group will publish a version of IMSC that is compatible with TTML 2 [...]

to

The Group will develop and publish a new version of IMSC that is compatible with TTML 2 [...]

Hi there,

There are still a few rogue Process 2005 links throughout. It may be on purpose, or not.
If not, please, s|2005/10/Process-20051014|2015/Process-20150901|

I see from the description here that the charter template is good for WGs and CGs.
However in the CGs documentation, we suggest people refer and use the recommended charter template.

They're not the same. Can we choose one and update our various documentations? #kthx!

In the Web of Things IG we have focused on technical issues that effect IoT platforms, but not web browsers. Can we clarify this to avoid misunderstandings on the behalf of people working on browsers?

For instance, we have so far avoided discussion on APIs for sensors and actuators leaving these to the corresponding platforms to define. For security APIs, it may not be so clear.

https://w3c.github.io/charter-drafts/webassembly.html

We discussed the Web Assembly WG charter draft internally at Google, and believe the current charter length of 3 years to be too long. In general, we would like to see charters that enable re-evaluation of the WG's deliverables at about the same cadence as spec publication, to allow for expanding scope over time, and for work to move between groups more easily.

We recommend a charter length of either 18 months or 2 years as a more reasonable duration.

@flagxor @sideshowbarker

https://www.w3.org/2006/02/charter-style.css

.todo
{
background-color:yellow;
}

and /charter-drafts/charter-template.html

.todo {
color: red;
}

make for difficult and uncomfortable reading. The yellow is too bright and the contrast ratio is only 3.97:1. (for more info: Perspectives, Easy Checks, WCAG)

I suggest something more like:

color: #900
background-color:#FFC

is easier on sensitive eyes and contrast ratio of 8.7:1.

This issue is intended to introduce open questions for discussion in respect to the draft charter for the Web of Things Interest Group. This will replace the old charter which expired on 31 March 2016. We've asked the W3C Management Committee for a short term extension to the old charter to cover the time needed to draft a new charter, reach consensus and drive it through the Advisory Committee review process.

Here are some initial points to seed discussion. Please add further points.

• Do we want to update the introduction to reflect the current positioning of the Web of Things as a suite of inter-platform standards? For instance, explaining the analogy behind the statement that the Web of Things is to the IoT what the Internet Protocol is to networking.
• The introduction should set out short, medium and long term priorities for the Interest Group.
• We agree to see through the work items started under the first charter.
• We allow for new work items to be introduced that fit within the charter scope.
• The Interest Group will collaborate with industry alliances and standards development organisations to achieve its goals.
• This collaboration will include joint studies, practical demonstrations that show the technical feasibility of approaches to enabling interoperability across platforms, open source projects, open meetings and so forth.
• The Interest Group will develop materials to assist in outreach in respect to the its goals, and will drive that outreach through a variety of channels.
• The Interest Group will study the challenge of interoperability testing, along with work on test suites and test frameworks
• The goals include building a common understanding around discovery, provisioning, security, resilience, privacy, trust and other requirements for open markets of services.
• The Interest Group will seek to identify work items where there is sufficient maturity and consensus to transfer to the standards track in one or more W3C Working Groups.
• The Interest Group will collaborate with other W3C groups where relevant to its goals.
• The Interest Group will consider initiating new work items at the request of other W3C groups, when these requests fall within the charter scope, and are consistent with Interest Group's priorities.
• How long should we ask for the charter duration? My feeling is that 12 months is too short, and a longer period would be helpful, as otherwise we will be back working on updating the charter in 10 months time. We could perhaps ask for a 24 month charter duration.

A) wot thing; scenarios were we can use it (3 examples)
B) scenarios: iot platform, discovery, it is not n+1
the interaction of things wether it is in the cloud, GW or even field device

shorten without explicit (technical) reference (Oliver) in 1.1. second bullet

Security summary in the introduction to explain why it is split in the setions

We've gotten feedback that teleconferences are hard to make globally inclusive because of timezones and language barriers. In addition, more groups are finding github issues and mailing lists more effective for discussion and issue resolution. Groups are free to schedule teleconferences taking these issues into account, but let's remove them from the charter template default.

• Formulate them refering the scope
• Give date of first public working draft
• Take out here use case&requirements and forward to IG