1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
= Outgoing Messages =
When messages are sent by a mail client, imip-agent employs an outgoing
message rule in the MTA to provide a handler to inspect any calendar-related
content and to update its records.
{{{#!graphviz
//format=svg
//transform=notugly
digraph outgoing {
node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Outgoing messages"];
edge [tooltip="Outgoing messages"];
rankdir=LR;
mail [label="Outgoing mail",shape=folder,style=filled,fillcolor=cyan];
subgraph {
rank=same;
outgoingrouter [label="Outgoing router"];
}
subgraph {
rank=same;
outgoinghandler [label="Outgoing handler",style=filled,fillcolor=gold];
scheduling [label="Scheduling",shape=ellipse,style=filled,fillcolor=gold];
freebusy [label="Free/busy",shape=folder,style=filled,fillcolor=gold];
manager [label="imip-manager",style=filled,fillcolor=gold];
}
client [label="Mail clients"];
client -> mail;
mail -> outgoingrouter -> outgoinghandler -> scheduling -> freebusy -> manager;
}
}}}
The management interface does not use this outgoing message rule because it
sends messages from the general calendar address (for example,
`calendar@example.com`), and there is no trivial way of deducing the identity
of the real sender. Instead, the manager explicitly sends suitably-modified
messages to the address of the user operating the interface to achieve the
same effect as the outgoing message rule, as well as to notify any mail
clients that would normally be managing calendar events on behalf of the user.
{{{#!graphviz
//format=svg
//transform=notugly
digraph manager_outgoing {
node [shape=box,fontsize="13.0",fontname="Helvetica",tooltip="Outgoing messages from the manager"];
edge [tooltip="Outgoing messages from the manager"];
rankdir=LR;
mail [label="Outgoing mail",shape=folder,style=filled,fillcolor=cyan];
subgraph {
rank=same;
personrouter [label="Person router"];
}
subgraph {
rank=same;
personhandler [label="Person handler",style=filled,fillcolor=gold];
scheduling [label="Scheduling",shape=ellipse,style=filled,fillcolor=gold];
freebusy [label="Free/busy",shape=folder,style=filled,fillcolor=gold];
manager [label="imip-manager",style=filled,fillcolor=gold];
}
webserver [label="Web server\n(Apache, ...)",tooltip="Web server"];
browser [label="Web browsers"];
browser -> webserver -> manager -> mail -> personrouter ->
personhandler -> scheduling -> freebusy -> manager;
}
}}}
== Events ==
{{{#!table
'''Method''' || '''Effect on Objects''' || '''Effect on Free/Busy'''
|| '''Effect on Request Queue'''
==
`CANCEL`
|| Remove selected attendees or an entire event
|| Remove record if entire event is cancelled
||<rowspan="4"> Remove any queue entry
==
`PUBLISH`
||<rowspan="2"> Add or update object, removing specific recurrences of
.. recurring events
||<rowspan="2"> Add record for the event, removing records for specific
.. recurrences of an event
==
`REQUEST`
==
`REPLY`
|| Merge attendee participation information
|| Update records for the event, preserving specific recurrence records when
.. changing a recurring event
}}}
The effect of the outgoing handler is to ensure that the user's free/busy
status reflects the consequences of their stated attendance of events, and for
the object records to reflect the most recent state of each event.
== Other Object Types ==
Other object types are not handled. Free/busy information, if exchanged, is
not obtained by the handler to replace its own records.
|
