Contents |
Multicast Context Channels
A context provides channels, which are used to provide semantic separation of events and messages. For example a person entity's context may have a channel for members of his family to deliver messages only to them.
In order to implement channels, a "#channel" suffix is appended to the _context uniform. The security check in the receiving entity (the context member) MUST only check the context uniform for membership validity, that means it must strip off the channel suffix. Thus, the original context is allowed to distribute its members in new channels anytime. The receiver MUST accept this behaviour as it is advantageous for both context and member.
Concept
- A context can have several distribution channels defined by the context. In the case of a chatroom, a channel can, for example, be a space where only the web inspection notices show up. In the case of a person, a channel can be the family-only peer group.
- From a routing standpoint however each channel serves as an independent technical address that allows for multicast. Each channel spawns its own multicast tree.
Interface
...
The following may be outdated or outright wrong. It has been discontinued in favor of Spec:Context, but..
The Hierarchy of Context Subscription States
The following specifies a hierarchy from starting to know each other, subscribing things to in-depth optimization of channel choice.
Subscriber Requesting Entry
These are possible ways to request entry to a context, remember to send a _tag along for security.
_request_context_enter
Manual one-time request to enter a multicast context.
_request_context_enter_automatic
Auto-join function, probably deprecated in many cases. This is currently implemented as /subscribe in psyced, but should be renamed or discontinued.
_request_context_enter_subscribe
Request to subscribe a context permanently, be it a newscaster, a chatroom or a friend's presence and mood announcements.
If sending to a entity that is permanently subscribed fails several times, it gets moved from the multicasttable to a "subscribed but down"-List and stays there until the connection is to the server is back.
_notice_context_leave
If the sender wants to ensure that the operation will take place, it may send a _notice_context_leave rather than a _request_context_leave which MUST be treated accordingly even by intermediate routing entities. This SHOULD only be used in case of context misbehaviour and may therefore be recorded for administrative purposes.
NOTE: then again because of the sync requirements of IRC we had to switch to this approach in psyced instead of gentle requests.
Context Modifying Channels
As described in Channels a context may create new subchannels of itself at any time, which only contain a subset of the members of the context as a whole. This is a top-down distribution model within a framework that has already been authenticated by a bottom-up approach, thus it is safe from SPIM.
_notice_context_enter_channel & _notice_context_leave_channel
By sending additional channel entry and leave notices a context can set up a subset of itself as an extra channel. Both unicast and multicast along an existing channel may be useful to this.
_notice_context_clone_channel
Not sure if something like this is necessary, but it would permit to announce a clone of a channel by multicasting on an existing channel. After that the member list can be modified by removing members rather than adding them.
Member Requesting Channel Membership
Although the context is in power to define who is in a channel, it MAY as well do as the members wish. It may also want to leave it to the owner of the context to do such modifications (especially when it comes to putting people into roster groups).
_request_context_enter_channel & _request_context_leave_channel
The members can explicitely request access to a channel using the usual methods. The context MAY feel free to reject such entry requests while a _request_context_leave_channel SHOULD always be acknowledged.
_notice_context_leave_channel
Members can also enforce removal from a multicast channel, which MUST be taken in consideration on router level, so the context cannot force a member to receive a channel. The member may end up not receiving any content although formally subscribed to the context as a whole. So again we have a little bottom-up control tool here. This SHOULD only be used in case of context misbehaviour and may therefore be recorded for administrative purposes.
Sending and Receiving Content
Using conference control the context may specify which channels may be muted to certain members. When a member submits content, be it a manual message, an automated notice or a presence update, the context may find it appropriate to redirect the submission to a different channel within the context. This may even imply a change in channel membership. Consider the following example:
- a person has joined a sports newscast channel
- a spectacular news item is multicast
- person feels the urge to comment on it
- context denies publication on the newscast channel (quietly?)
- instead context issues an _enter to the sports talk channel
- then publishes the person's submission to that channel