Since some users of the calendar system may not have a calendar program or a mail program that understands calendar data, a Web-based interface is provided that allows such users to inspect incoming calendar data, consult a schedule that has been prepared through the work of the agent programs, and to create events to be shared with others.
The management interface is deployed according to the Web server integration guide and, if enabled, will be advertised in messages sent by imip-agent to users receiving calendar-related messages, with links being provided like this (subject to the configuration):
https://webserver.example.com/imip-manager/eventid
Upon following such a link, users should be asked to log in. They should then be presented with the details of an event received via e-mail.
The root resource of the management interface shows a simple calendar view for the logged-in user. The following elements are displayed:
Adding scheduling participants, specifying their e-mail address, results in a new schedule column being added for each new participant in the calendar. When creating an event, all scheduling participants are automatically added as attendees.
The calendar is divided into days, and these are divided into periods depending on the nature of any events that feature in the calendar. Days for which no events are recorded are hidden by default; such days can be shown if desired.
Whole days can be chosen by selecting day headings in the calendar. Similarly, individual periods can be chosen either by selecting period headings along the side of the calendar or by selecting cells in the calendar. Upon selecting periods, controls will appear for the creation of a new event, and if all periods are deselected, such controls will disappear.
Events appear in the calendar as filled regions, and their labels correspond to the summary information defined for each event. These labels link to the event details unless a request has updated the event: in which case, the request label will link to the updated event details.
Requests/invitations appear alongside events in a separate column in the calendar, and their label links to the details of the request (and thus updated event). Such items disappear from the calendar once processed by the user.
Each user's profile details are presented in a table mostly corresponding to the system's preferences, with the most significant settings given first. Many users will probably only want to change their participation in the calendar system, their name, language or time zone, at least if the defaults chosen for deployment are reasonable.
The settings names correspond to the preferences as follows:
| Label | Setting |
| Participate in the calendar system | participating |
| Your common name | CN |
| Language | LANG |
| Time zone/regime | TZID |
| How to present incoming calendar messages | incoming |
| Share free/busy information | freebusy_sharing |
| Bundle free/busy details with messages | freebusy_bundling |
| Publish free/busy details via the Web | freebusy_publishing |
| Deliver details of received free/busy messages | freebusy_messages |
| How to respond to messages adding events | add_method_response |
| How to handle event refresh requests | event_refreshing |
| Recognise whom as a new organiser of an event? | organiser_replacement |
The event view consists of the following elements:
In addition, some other elements may appear in the event view:
Changes can be made to events in both the organiser and attendee roles. As organiser, any changes will incorporated into the event, and the new version will be sent to attendees on choosing to update the event. As attendee, changes are incorporated into counter-proposals that are sent back to the organiser for approval or rejection.
Only organisers can edit the core details of an event. They may add and remove attendees, and they may also add and remove periods associated with the event.
The removal of existing attendees will not cause such attendees to be instantly deleted from the event details. Instead, such attendees will initially be marked as removed and, after editing is complete, have cancellation messages sent to them informing them that their attendance is no longer required.
Attendees themselves can suggest other attendees by adding them, and they may also remove those suggested attendees. However, they may not remove existing attendees.
Attendees can also redefine event periods, but these modifications will merely be sent back to the organiser for review. Any acceptance of such changes will occur if the organiser chooses to send out a revised version of the event featuring those changes. Otherwise, an explicit message declining such changes may be received.