This Charter was ratified by group consensus on 2021-06-23. To submit feedback, please use the Github Repo Issues list.
The mission of the Multicast web community group is to enable multicast IP transport for web traffic to efficiently solve scalability problems in networking and web operations.
In general, topics related to secure transport using multicast IP and the application-layer signaling to support it are in scope.
The CLA is applicable (as described in the process section) to any work contributing to normative specifications. This includes in-scope work such as:
Other work that's in-scope but where the CLA is not expected to directly apply includes activities like:
Work on open standards is preferred, but many existing uses of multicast have proprietary implementations, and some of these may be possible to operate on top of some web APIs as they become available.
Existing proprietary transport protocols MAY be evaluated and tracked for their performance characteristics and potential to address scalability problems, as long as their usage is consistent with the appropriate security considerations. For example, evaluating performance characteristics of a proprietary implementation of a video player built on top of a multicast-enabled WebTransport API would not be out of scope for this group--it would be a case study of an example usage of a multicast WebTransport API.
Although such case studies may inform the analysis of use cases within the group, examination of such protocols does not imply that the proprietary implementation is subject to the CLA.
Proprietary implementations SHOULD NOT be individually evangelized by this group, but lists and reviews that include information about proprietary implementations without unduly highlighting specific vendors MAY be included during evangelization of multicast APIs in general.
The definition of network protocols for multicast transport or routing is out of scope for this group. In general, it is expected that protocol definition will be handled in the IETF. (Note however that liaison statements to appropriate IETF groups or evaluations of how such protocols impact performance or otherwise impact web use cases would be in scope.)
The initial priority will focus on a proposal to extend WebTransport with a multicast receive capability.
(Suggested starting point for incubation: early Multicast Receive API proposal and implementation.)
This is a low-level API that can be used to incubate the later stages by experimenting with transport protocols implemented inside web apps.
Later work will aim to extend other W3C specifications that may be able to get improved performance by embedding interoperable open standards for multicast transport into various delivery APIs. Specifications under consideration for this phase will include:
The group may produce other Community Group Reports within the scope of this charter but that are not Specifications, for instance:
In general, other documents related to in-scope multicast work are welcome. If there are individuals who will commit to being editors for a document, the group should agree to accept it as a work item.
The group MAY produce test suites to support the Specifications. Any test suites produced by this group will be made available under the same license as WPT.
Progress on any usage of multicast for web traffic will rely on progress on some IETF specifications, and group members will be encouraged to perform IETF reviews for these. The list of these specifications is maintained in the github repo at consensus-dependency-specs.md, to be updated as incubation proceeds according to group consensus.
Progress on the specifications in phase 2 will depend on interoperable open implementations of specifications for multicast-based transport protocols, and the group will need to consider the suitability of these protocols for addressing the specific use cases covered by the target APIs, and to evaluate what updates might be necessary to meet the requirements of the web security model. Several such candidate protocols exist, and the list of protocols recommended for consideration is maintained in the github repo under consensus-transport-protocols.md, to be updated as incubation proceeds according to group consensus.
It's expected that implementations of the receive side of these protocols on top of a secure WebTransport API can aid the success of these evaluation efforts, which is a key motivator for the phased approach outlined here.
The Multicast Web Community Group will also liaise with the following W3C Working groups:
The Multicast Web Community Group will also liaise with W3C Interest and Community groups with interests affected by multicast, including:
The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.
As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization's legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual's first request to make a contribution to a group Deliverable. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.
The W3C Code of Ethics and Professional Conduct applies to participation in this group.
The group will not publish Specifications on topics other than those listed under Specifications above. See below for how to modify the charter.
Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA).
Specifications created in the Community Group must use the W3C Software and Document License. All other documents produced by the group should use that License where possible.
Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular document. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.
All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.
The group will conduct all of its technical work in public. If the group uses GitHub, all technical work will occur in its GitHub repositories (and not in mailing list discussions). This is to ensure contributions can be tracked through a software tool.
Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group's public mailing list, or to a GitHub issue if the group uses GitHub.
This group will seek to make decisions where there is consensus. Groups are free to decide how to make decisions (e.g. Participants who have earned Committer status for a history of useful contributions assess consensus, or the Chair assesses consensus, or where consensus isn't clear there is a Call for Consensus [CfC] to allow multi-day online feedback for a proposed course of action). It is expected that participants can earn Committer status through a history of valuable contributions as is common in open source projects. After discussion and due consideration of different opinions, a decision should be publicly recorded (where GitHub is used as the resolution of an Issue).
If substantial disagreement remains (e.g. the group is divided) and the group needs to decide an Issue in order to continue to make progress, the Committers will choose an alternative that had substantial support (with a vote of Committers if necessary). Individuals who disagree with the choice are strongly encouraged to take ownership of their objection by taking ownership of an alternative fork. This is explicitly allowed (and preferred to blocking progress) with a goal of letting implementation experience inform which spec is ultimately chosen by the group to move ahead with.
Any decisions reached at any meeting are tentative and should be recorded in a GitHub Issue for groups that use GitHub and otherwise on the group's public mail list. Any group participant may object to a decision reached at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to the decision process.
It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer.
Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer. However, if 5 participants, no two from the same organisation, call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).
Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.