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
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
|
Internet Engineering Task Force (IETF) A. Niemi
Request for Comments: 5839 Nokia
Category: Standards Track D. Willis, Ed.
ISSN: 2070-1721 Softarmor Systems
May 2010
An Extension to Session Initiation Protocol (SIP) Events
for Conditional Event Notification
Abstract
The Session Initiation Protocol (SIP) events framework enables
receiving asynchronous notification of various events from other SIP
user agents. This framework defines the procedures for creating,
refreshing, and terminating subscriptions, as well as fetching and
periodic polling of resource state. These procedures provide no
tools to avoid replaying event notifications that have already been
received by a user agent. This memo defines an extension to SIP
events that allows the subscriber to condition the subscription
request to whether the state has changed since the previous
notification was received. When such a condition is true, either the
body of a resulting event notification or the entire notification
message is suppressed.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5839.
Niemi & Willis Standards Track [Page 1]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Niemi & Willis Standards Track [Page 2]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivations and Background . . . . . . . . . . . . . . . . . . 5
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Problem Description . . . . . . . . . . . . . . . . . . . 5
2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10
5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 12
5.1. Detecting Support for Conditional Notification . . . . . . 13
5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13
5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14
5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15
5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 17
5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 18
5.7. Terminating a Subscription . . . . . . . . . . . . . . . . 18
5.8. Handling Transient Errors . . . . . . . . . . . . . . . . 19
6. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 20
6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20
6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 21
6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21
6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 22
7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22
7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22
7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 22
7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. 204 (No Notification) Response Code . . . . . . . . . . . 23
8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Niemi & Willis Standards Track [Page 3]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
1. Introduction
The Session Initiation Protocol (SIP) events framework provides an
extensible facility for requesting notification of certain events
from other SIP user agents. This framework includes procedures for
creating, refreshing, and terminating subscriptions, as well as the
possibility to fetch or periodically poll the event resource.
Several instantiations of this framework, called event packages have
been defined, e.g., for presence [RFC3856], message waiting
indications [RFC3842], and registrations [RFC3680].
By default, every SUBSCRIBE request generates a NOTIFY request
containing the latest event state. Typically, a SUBSCRIBE request is
issued by the subscriber whenever it needs a subscription to be
installed, periodically refreshed, or terminated. Once the
subscription has been installed, the majority of the NOTIFYs
generated by the subscription refreshes are superfluous; the
subscriber usually is in possession of the event state already,
except in the unlikely case where a state change exactly coincides
with the periodic subscription refresh. In most cases, the final
event state generated upon terminating the subscription similarly
contains resource state that the subscriber already has.
Fetching or polling of resource state behaves in a similarly
suboptimal way in cases where the state has not changed since the
previous poll occurred. In general, the problem lies with the
inability to persist state across a SUBSCRIBE request.
This memo defines an extension to optimize the SIP events framework.
This extension allows a notifier to tag notifications (called entity-
tags hereafter) and the subscriber to condition its subsequent
SUBSCRIBE requests for actual changes since a notification carrying
that entity-tag was issued. The solution is similar to conditional
requests defined in the Hypertext Transfer Protocol (HTTP) [RFC2616],
and follows the mechanism already defined for the PUBLISH [RFC3903]
method for issuing conditional event publications.
This memo is structured as follows. Section 2 explains the
background, motivations, and requirements for the work; Section 3
gives a general overview of the mechanism; Section 4 explains the
underlying model for resources and entities as they apply to
conditional notification; Section 5 defines the subscriber behavior;
Section 6 defines the notifier behavior; Section 7 includes the
protocol element definitions; Section 8 includes the IANA
considerations; and Section 9 includes the security considerations.
Niemi & Willis Standards Track [Page 4]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
1.1. Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant
implementations.
1.2. Terminology
In addition to the terminology introduced in [RFC3261], [RFC3265],
and [RFC3903], this specification uses these additional terms to
describe the objects of conditional notification:
resource
An object identified by a URI whose resource state can be accessed
using the SIP Event Notification framework. There is a single
authoritative notifier responsible for communicating the resource
state.
entity
The representation of resource state. An entity consists of the
state data carried in the body of a NOTIFY message, as well as
related meta-data in the message header. There may be many
versions of an entity, one current and the others stale. Each
version of an entity is identified by an entity-tag, which is
guaranteed to be unique across all versions of all entities for a
resource and event package.
2. Motivations and Background
2.1. Overview
A SUBSCRIBE request creates a subscription with a finite lifetime.
This lifetime is negotiated using the Expires header field, and
unless the subscription is refreshed by the subscriber before the
expiration is met, the subscription is terminated. The frequency of
these subscription refreshes depends on the event package, and
typically ranges from minutes to hours.
2.2. Problem Description
The SIP events framework does not include different protocol methods
for initiating and terminating of subscriptions, subscription
refreshes, and fetches inside and outside of the SIP dialog. The
SUBSCRIBE method is overloaded to perform all of these functions.
The difference between a fetch that does not create a (lasting)
subscription and a SUBSCRIBE that creates one is in the Expires
Niemi & Willis Standards Track [Page 5]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE only
generates a single NOTIFY, after which the subscription immediately
terminates. Lasting subscriptions typically have relatively short
expiry periods, requiring periodic sending of new SUBSCRIBE requests
in order to refresh the subscription.
Each new SUBSCRIBE request generates a NOTIFY request containing the
latest resource state. Even if the state has not changed, it is sent
again in response to each poll or subscription refresh. This is very
similar to the HTTP [RFC2616] problem of repeated GET operations on a
resource. HTTP solves the problem using conditional requests. The
server versions each entity with an entity-tag that identifies a
specific instance of that entity. Clients making GET requests can
then include the entity-tag for the version of the entity that they
believe to be current in an "If-None-Match" header field. The server
can compare this entity-tag to the entity it believes to be current
and suppress resending the entity in the response if the server
believes the client's version matches. In other words, the server
doesn't resend information that the client has already received.
The SIP PUBLISH [RFC3903] method uses a similar mechanism, where a
refresh of a publication is done by reference to its assigned entity-
tag, instead of retransmitting the event state each time the
publication expiration is extended.
2.3. Requirements
As a summary, here is the required functionality to solve the
presented issues:
REQ1: It must be possible to suppress the NOTIFY request (or at a
minimum, the event body therein) if the subscriber is already
in possession of (or has previously received and discarded)
the latest event state of the resource.
REQ2: This mechanism must apply to initial subscriptions in which
the subscriber is attempting to resume an earlier
subscription that has been paused.
REQ3: This mechanism must apply to refreshing a subscription.
REQ4: This mechanism must apply to terminating a subscription
(i.e., an unsubscribe).
REQ5: This mechanism must apply to fetching or polling of resource
state.
Niemi & Willis Standards Track [Page 6]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
3. Overview of Operation
Whenever a subscriber initiates a subscription, it issues a SUBSCRIBE
request. The SUBSCRIBE request is sent, routed, and processed by the
notifier normally, i.e., according to the Session Initiation Protocol
[RFC3261] and SIP-Specific Event Notification [RFC3265].
If the notifier receiving the SUBSCRIBE request supports conditional
subscriptions, it generates an entity-tag for the current entity, and
includes it in a SIP-ETag header field of the NOTIFY request. The
entity-tag is unique across all versions of all entities for a
resource and event package. See Section 4 for more on this.
Entity-tags are independent of subscriptions. This allows
notifications generated to a fetch or a poll to have valid entity-
tags even across subsequent fetches or polls.
The subscriber will store the entity-tag received in the notification
along with the resource state. It can then later use this entity-tag
to make a SUBSCRIBE contain a condition in the form of a "Suppress-
If-Match" header field. Unlike the "If-Match" condition in a PUBLISH
[RFC3903] request, which applies to whether the PUBLISH succeeds or
returns an error, this condition applies to the stream of
notifications that are sent after the SUBSCRIBE request has been
processed.
The Suppress-If-Match header field contains the last entity-tag seen
by the subscriber. This condition, if true, instructs the notifier
to suppress either the body of a subsequent notification, or the
entire notification.
The condition is evaluated by matching the value of the header field
against the entity-tag of the entity that would normally be sent in
the associated NOTIFY message. There is also a wildcard entity-tag
with a special value of "*" that always matches.
Niemi & Willis Standards Track [Page 7]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 3600
<-------- (2) 200 (or 202)
<-------- (3) NOTIFY
Subscription-State: active
SIP-ETag: ffee2
(4) 200 -------->
... time passes ...
(5) SUBSCRIBE --------> \ if "ffee2"
Suppress-If-Match: ffee2 | matches
Expires: 3600 | local
| entity-tag
|
<-------- (6) 204 / then
... time passes and resource state (entity) changes...
<-------- (7) NOTIFY
Subscription-State: active
SIP-ETag: ca89a
(8) 200 -------->
... time passes ...
(9) SUBSCRIBE --------> \ if "ca89"
Suppress-If-Match: ca89a | matches
Expires: 0 | local
| entity-tag
|
<-------- (10) 204 / then
Figure 1: Example Message Flow
Figure 1 describes a typical message flow for conditional
notification:
(1) The subscriber initiates a subscription by sending a SUBSCRIBE
request for a resource.
Niemi & Willis Standards Track [Page 8]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
(2) After proper authentication and authorization, the notifier
accepts the subscription.
(3) The notifier then immediately sends the initial event
notification, including a unique entity-tag in a SIP-ETag
header field.
(4) The subscriber accepts the notification and stores the entity-
tag value along with the resource state.
(5) Later, the subscriber refreshes the subscription, and includes
an entity-tag in a Suppress-If-Match header field.
(6) The notifier evaluates the condition by matching its local
entity-tag value for the resource against the value of the
Suppress-If-Match header field. If the condition evaluates to
true, the notifier informs the subscriber that the notification
will not be sent.
(7) At some point, the state of the resource changes, e.g., the
presence status of a user changes from online to busy. This
triggers an event notification with a new value in the SIP-ETag
header field.
(8) The subscriber accepts the notification and stores the new
entity-tag along with the resource state.
(9) After a while, the subscriber decides to terminate the
subscription. It adds a condition for Suppress-If-Match, and
includes the entity-tag it received in the previous NOTIFY.
(10) The notifier evaluates the condition by matching its entity-tag
for the resource against the value of the Suppress-If-Match
header field. If the condition evaluates to true, the notifier
informs the subscriber that no notification will be sent. This
concludes the subscription.
The benefit of using conditional notification in this example is in
the reduction of the number of NOTIFY requests the subscriber can
expect to receive. Each event notification that the subscriber has
already seen is suppressed by the notifier. This example illustrates
only one use case for the mechanism; the same principles can be used
to optimize the flow of messages related to other event notification
use cases.
Niemi & Willis Standards Track [Page 9]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
4. Resource Model for Entity-Tags
The key to understanding how conditional notification works is
understanding the underlying resource model of event notification.
In general, this model is similar to the resource model of HTTP with
some key differences. This section explains in detail the model as
it applies to SIP events. Figure 2 illustrates the model.
+-----+
............ | |
. . | URI |
. Represen . | |
. tation . +-----+
. . |*
............ |
. |
. V
. +----------+ +---------+
composition | |* | Event |
+------<>| Resource |----------->| Package |<----.
| | | | | |
| +----------+ +----.----+ |
| /_\ |
|* | classification
+--------+ | |
| | .----------------.------' |
| Entity | | | |
| | | | |*
+--------+ +----------+ +------------+ +----------+
^ | | | | | |
| | Presence | | Conference | | Template |
| | | | | | |
|1..* +----------+ +------------+ +----.-----+
+---------+ /_\
| | |
| Version | |
| | +---------+
+---------+ | Watcher |
|1 | Info |
| | |
V +---------+
+---------+
| Entity- |
| Tag |
| |
+---------+
Figure 2: Resource Model Diagram
Niemi & Willis Standards Track [Page 10]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
For a given event package, there is a single authoritative agent
responsible for zero or more resources. That is, even for a
distributed agent, the resource state is uniform across all
instances. The resource itself can be a list of resources [RFC4662].
Conditional notification for list subscriptions is addressed in
Section 6.5.
A resource is identified by zero or more URIs, which can be SIP URIs,
pres URIs [RFC3859], or similar. Subscribers use this URI to
subscribe to the resource for certain types of events, identified by
the event package.
With a successful subscription, a subscriber receives event
notifications that communicate the resource state and the changes
thereto. Each event notification carries a representation of the
current resource state. This representation is influenced by many
factors, e.g., authorization and filtering rules, and the event
composition rules of the notifier.
This representation is realized in an "entity". Each resource may be
associated with zero or more entities. For example, there may be
multiple subscribers to the presence information of a single user (a
resource), and each subscriber may have a different filtered view of
that resource, producing one entity per subscriber. However, each
entity is associated with one and only one resource; there is no
"compositing" of resources at the entity level. Resources may
themselves be made up of information from other resources (be
"composite resources"), but this does not change the one-resource-
per-entity rule.
An entity consists of the data carried in the body of a NOTIFY
message and related meta-data in the message header. Whenever the
data in the body or any of the meta-data changes, the notifier MUST
produce a new entity-tag. This meta-data MUST include, but is not
limited to the following SIP header fields defined in the Session
Initiation Protocol [RFC3261] and SIP Specific Event Notification
[RFC3265]:
1. Content-Disposition
2. Content-Encoding
3. Content-Language
4. Content-Length
5. Content-Type
Niemi & Willis Standards Track [Page 11]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
6. Event
Note that the Subscription-State is explicitly not part of the
entity. In the future, event packages may define additional fields
that implementations need to consider as part of the entity.
An entity has one or more versions of which only one is current and
all others stale. Each version has an entity-tag, which uniquely
identifies it across all versions of all entities pertaining to a
single resource and event package.
Note that two entity-tags for different resources being equal does
not indicate identical entities. In other words, if an entity-tag
received for a subscription to a first resource matches an entity-tag
received for a subscription to a second resource, the subscriber
cannot assume that the two entity values are equal.
With partial event notification, the NOTIFY message only carries the
delta state, or the set of changes to the previous version of the
entity. In that case, implementations MUST consider the full event
state as the version of the entity to which the entity-tag in the
NOTIFY message applies.
The conditional notification mechanism is independent of the way in
which subscriptions are installed. In other words, the mechanism
supports implicit subscriptions, such as those associated with the
REFER method [RFC3515].
It is possible that the same resource is in some shape or form
accessible through another mechanism in addition to SIP Event
Notification, e.g., HTTP or the SIP PUBLISH method. In general,
implementations MUST NOT expect the entity-tags to be shared between
the mechanisms, unless event packages or specific applications of SIP
events explicitly define such dependencies.
5. Subscriber Behavior
This section augments the subscriber behavior defined in RFC 3265
[RFC3265]. It first discusses general issues related to indicating
support for the mechanism (Section 5.1) and creating conditions in
SUBSCRIBE requests (Section 5.2). Next, it describes subscriber
behavior for receiving NOTIFY requests (Section 5.3), and specific
client workflows for polling resource state (Section 5.4), resuming a
subscription (Section 5.5), refreshing a subscription (Section 5.6),
and terminating a subscription (Section 5.7). Finally, handling of
transient errors is discussed (Section 5.8).
Niemi & Willis Standards Track [Page 12]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
5.1. Detecting Support for Conditional Notification
The mechanism defined in this memo is backwards compatible with SIP
events [RFC3265] in that a notifier supporting this mechanism will
insert a SIP entity-tag in its NOTIFY requests, and a subscriber that
understands this mechanism will know how to use it in creating a
conditional request.
Unaware subscribers will simply ignore the entity-tag, make requests
without conditions, and receive the default treatment from the
notifier. Unaware notifiers will simply ignore the conditional
header fields and continue normal operation.
5.2. Generating SUBSCRIBE Requests
When creating a conditional SUBSCRIBE request, the subscriber MUST
include a single conditional header field including an entity-tag in
the request. The condition is evaluated by comparing the entity-tag
of the subscribed resource with the entity-tag carried in the
conditional header field. If they match, the condition evaluates to
true.
Unlike the condition introduced for the SIP PUBLISH [RFC3903] method,
these conditions do not apply to the SUBSCRIBE request itself, but to
the resulting NOTIFY requests. When true, the condition drives the
notifier to change its behavior with regard to sending the
notifications after the SUBSCRIBE.
This specification defines a new header field called Suppress-If-
Match. This header field introduces a condition to the SUBSCRIBE
request. If true, it instructs the notifier either to omit the body
of the resulting NOTIFY message (if the SUBSCRIBE is not sent within
an existing dialog) or to suppress (i.e., block) the NOTIFY request
that would otherwise be triggered by the SUBSCRIBE (for an
established dialog). In the latter case, the SUBSCRIBE message will
be answered with a 204 (No Notification) response. As long as the
condition remains true, it also instructs the notifier either to
suppress any subsequent NOTIFY request or, if there are reportable
changes in the NOTIFY header, e.g., the Subscription-State has
changed, to suppress the body of any subsequent NOTIFY request.
If the condition is false, the notifier follows its default behavior.
If the subscriber receives a 204 (No Notification) response to an in-
dialog SUBSCRIBE, the subscriber MUST consider the event state and
the subscription state unchanged.
Niemi & Willis Standards Track [Page 13]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
The value of the Suppress-If-Match header field is an entity-tag,
which is an opaque token that the subscriber simply copies (byte-
wise) from a previously received NOTIFY request. Inclusion of an
entity-tag in a Suppress-If-Match header field of a SUBSCRIBE request
indicates that the client has a copy of, or is capable of recreating
a copy of, the entity associated with that entity-tag.
Example:
Suppress-If-Match: b4cf7
The header field can also be wildcarded using the special "*" entity-
tag value. Such a condition always evaluates to true regardless of
the value of the current entity-tag for the resource.
Example:
Suppress-If-Match: *
Such a wildcard condition effectively quenches a subscription; the
only notifications received are those reporting changes to the
subscription state and those in response to a SUBSCRIBE message sent
outside of an existing dialog. In both cases, the notifications will
not contain a body.
A subscription with a wildcard Suppress-If-Match condition is
useful in scenarios where the subscriber wants to temporarily put
a subscription in dormant mode. For example, a host may want to
conserve bandwidth and power when it detects from screen or input
device inactivity that the user isn't actively monitoring the
presence statuses of contacts.
5.3. Receiving NOTIFY Requests
When a subscriber receives a NOTIFY request that contains a SIP-ETag
header field, it MUST store the entity-tag if it wishes to make use
of the conditional notification mechanism. The subscriber MUST be
prepared to receive a NOTIFY with any entity-tag value, including a
value that matches any previous value that the subscriber might have
seen.
The subscriber MUST NOT infer any meaning from the value of an
entity-tag; specifically, the subscriber MUST NOT assume identical
entities (i.e., event state) for NOTIFYs with identical entity-tag
values when those NOTIFYs result from subscription to different
resources.
Niemi & Willis Standards Track [Page 14]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
Note that there are valid cases for which identical entity-tag
values on different resources may occur. For example, it is
possible to generate entity-tag values using a one-way hash
function, resulting in the possibility that two different
resources having the same entity-value will also have the same
entity-tag. Clients however MUST NOT assume that this is the
case, as the algorithm for the generation of entity-tags is
notifier-dependent and not negotiated with the subscriber.
Consequently, the subscriber cannot differentiate between two
entity-tags that have the same value because they are similar
hashes of identical entities, or because two notifiers happen to
have used the same sequential number as an entity-tag. Entity
tags are only required to be unique for a given resource, not
globally unique.
5.4. Polling or Fetching Resource State
Polling with conditional notification allows a user agent to
efficiently poll resource state. This is accomplished using the
Suppress-If-Match condition:
Niemi & Willis Standards Track [Page 15]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 0
<-------- (2) 202
<-------- (3) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 17539
(4) 200 -------->
... poll interval elapses ...
(5) SUBSCRIBE -------->
Suppress-If-Match: f2e45
Expires: 0
<-------- (6) 202
<-------- (7) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 0
(8) 200 -------->
Figure 3: Polling Resource State
(1) The subscriber polls for resource state by sending a SUBSCRIBE
with zero expiry (expires immediately).
(2) The notifier accepts the SUBSCRIBE with a 202 (Accepted)
response.
(3) The notifier then immediately sends a first (and last) NOTIFY
request with the current resource state and the current entity-
tag in the SIP-ETag header field.
(4) The subscriber accepts the notification with a 200 (OK)
response.
(5) After some arbitrary poll interval, the subscriber sends another
SUBSCRIBE with a Suppress-If-Match header field that includes
the entity-tag received in the previous NOTIFY.
Niemi & Willis Standards Track [Page 16]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
(6) The notifier accepts the SUBSCRIBE with a 202 (Accepted)
response. (202 would be used to indicate that the subscription
request was understood without also indicating that it was
authorized, as per Section 3.1.6.1 of SIP-Specific Event
Notification [RFC3265].)
(7) Since the resource state has not changed since the previous poll
occurred, the notifier sends a NOTIFY message with no body. It
also mirrors the current entity-tag of the resource in the SIP-
ETag header field.
(8) The subscriber accepts the notification with a 200 (OK)
response.
5.5. Resuming a Subscription
Resuming a subscription means the ability to continue an earlier
subscription that either closed abruptly or was explicitly
terminated. When resuming, the subscription is established without
transmitting the resource state. This is accomplished with
conditional notification and the Suppress-If-Match header field:
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 3600
<-------- (2) 202
<-------- (3) NOTIFY
Subscription-State: active
SIP-ETag: ega23
Content-Length: 0
(4) 200 -------->
Figure 4: Resuming a Subscription
(1) The subscriber attempts to resume an earlier subscription by
including a Suppress-If-Match header field with the entity-tag
it last received.
(2) The notifier accepts the subscription after proper
authentication and authorization, by sending a 202 (Accepted)
response.
Niemi & Willis Standards Track [Page 17]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
(3) Since the condition is true, the notifier then immediately sends
an initial NOTIFY request that has no body. It also mirrors the
current entity-tag of the resource in the SIP-ETag header field.
(4) The subscriber accepts the NOTIFY and sends a 200 (OK) response.
Had the entity-tag not been valid any longer, the condition would
have evaluated to false, and the NOTIFY would have had a body
containing the latest resource state.
5.6. Refreshing a Subscription
To refresh a subscription using conditional notification, the
subscriber creates a subscription refresh before the subscription
expires, and uses the Suppress-If-Match header field:
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: aba91
Expires: 3600
<-------- (2) 204
Expires: 3600
Figure 5: Refreshing a Subscription
(1) Before the subscription expires, the subscriber sends a
SUBSCRIBE request that includes the Suppress-If-Match header
field with the latest entity-tag it has seen.
(2) If the condition evaluates to true, the notifier sends a 204 (No
Notification) response and sends no NOTIFY request. The Expires
header field of the 204 (No Notification) response indicates the
new expiry time.
5.7. Terminating a Subscription
To terminate a subscription using conditional notification, the
subscriber creates a SUBSCRIBE request with a Suppress-If-Match
condition:
Niemi & Willis Standards Track [Page 18]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 0
<-------- (2) 204
Figure 6: Terminating a Subscription
(1) The subscriber decides to terminate the subscription and sends a
SUBSCRIBE request with the Suppress-If-Match condition with the
entity-tag it has last seen.
(2) If the condition evaluates to true, the notifier sends a 204 (No
Notification) response, which concludes the subscription, and
the subscriber can clear all state related to the subscription.
5.8. Handling Transient Errors
This section is non-normative.
In some deployments, there may be Back-to-Back User Agent (B2BUA)
devices that track SIP dialogs such as subscription dialogs. These
devices may be unaware of the conditional notification mechanism.
It is possible that some B2BUA devices may treat a NOTIFY with
suppressed body as an error, or may expect all SUBSCRIBE messages to
have an associated NOTIFY message.
In general, there is very little that an endpoint can do to recover
from such transient errors. The most that can be done is to try to
detect such errors, and define a fallback behavior.
If subscribers encounter transient errors in conditional
notification, they should disable the feature and fall back to normal
subscription behavior.
Niemi & Willis Standards Track [Page 19]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
6. Notifier Behavior
This section augments the notifier behavior as specified in RFC 3265
[RFC3265].
6.1. Generating Entity-tags
An entity-tag is a token carried in the SIP-ETag header field, and it
is opaque to the client. The notifier is free to decide on any means
for generating the entity-tag. It can have any value, except for
"*". For example, one possible method is to implement the entity-tag
as a simple counter, incrementing it by one for each generated
notification per resource.
A notifier MUST generate entity-tags for event notifications of all
resources for which it is responsible. The entity-tag MUST be unique
across all versions of all entities for each state of a resource as
reported by a given event package. Otherwise said, for any
subscription or sequence of subscriptions to a specific resource
using a singular event package, each entity-tag produced MUST map to
one and only one presentation of resource state (entity). Two
identical entities for a specific resource might or might not have
identical entity-tags; this decision is left to the notifier.
An entity-tag is considered valid for as long as the entity exists.
An entity becomes stale when its version is no longer the current
one. The notifier MUST remember (or be able to recalculate) the
entity-tag of an entity as long as the version of the entity is
current. The notifier MAY remember the entity-tag longer than this,
e.g., for implementing journaled state differentials (Section 6.4).
The entity-tag values used in publications are not necessarily shared
with the entity-tag values used in subscriptions. This is because
there may not always be a one-to-one mapping between a publication
and a notification of state change; there may be several sources to
the event composition process, and a publication into a resource may
not affect the resulting entity.
6.2. Suppressing NOTIFY Bodies
When a condition in a SUBSCRIBE request for suppressing notifications
is true (i.e., the local entity-tag for the resource state and the
entity-tag in a Suppress-If-Match header field are byte-wise
identical) but there are reportable changes in the NOTIFY header
(e.g., the Subscription-State has changed), the notifier MUST
suppress the body of the NOTIFY request. That is, the resulting
NOTIFY contains no Content-Type header field, the Content-Length is
set to zero, and no payload is attached to the message.
Niemi & Willis Standards Track [Page 20]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
Additionally, when a condition in a SUBSCRIBE request for suppressing
notifications is true and the SUBSCRIBE message is not sent within an
established dialog, the notifier MUST send a NOTIFY request with a
suppressed entity body.
Suppressing the entity body of a NOTIFY does not change the current
entity-tag of the resource. Hence, the NOTIFY MUST contain a SIP-
ETag header field that contains the unchanged entity-tag of the
resource state.
A Suppress-If-Match header field that includes an entity-tag with the
value of "*" MUST always evaluate to true.
6.3. Suppressing NOTIFY Requests
When a condition in a SUBSCRIBE request to suppress notifications is
true (i.e., the local entity-tag of the resource and the entity-tag
in a Suppress-If-Match header field match), and the SUBSCRIBE is sent
within an established dialog, then the notifier MUST suppress the
resulting NOTIFY request, and generate a 204 (No Notification)
response. As long as the condition remains true, and there are no
reportable changes in the NOTIFY header, all subsequent NOTIFY
requests MUST also be suppressed.
Notifiers MUST NOT suppress a NOTIFY unless the corresponding
SUBSCRIBE message was sent in an established dialog.
A successful conditional SUBSCRIBE request MUST extend the
subscription expiry time.
Suppressing the entire NOTIFY has no effect on the entity-tag of the
resource. In other words, it remains unchanged.
A Suppress-If-Match header field that includes an entity-tag with the
value of "*" MUST always evaluate to true.
6.4. State Differentials
Some event packages support a scheme where notifications contain
state differentials, or state deltas [RFC3265], instead of complete
resource state.
Further extensions could define means for notifiers to keep track of
the state changes of a resource, e.g., storing the changes in a
journal. If a condition fails, the notifier would then send a state
differential in the NOTIFY rather than the full state of the event
resource. This is only possible if the event package and the
subscriber both support a payload format that has this capability.
Niemi & Willis Standards Track [Page 21]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
When state differentials are sent, the SIP-ETag header field MUST
contain an entity-tag that corresponds to the full resource state.
6.5. List Subscriptions
The Event Notification Extension for Resource Lists [RFC4662] defines
a mechanism for subscribing to a homogeneous list of resources using
the SIP events framework.
A list subscription delivers event notifications that contain both
Resource List Meta-Information (RLMI) documents as well as the
resource state of the individual resources on the list.
Implementations MUST consider the full resource state of a resource
list including RLMI and the entity-header as the entity to which the
entity-tag applies.
7. Protocol Element Definitions
This section describes the protocol extensions required for
conditional notification.
7.1. 204 (No Notification) Response Code
The 204 (No Notification) response code indicates that the request
was successful, but the notification associated with the request will
not be sent. It is valid only in response to a SUBSCRIBE message
sent within an established dialog.
The response code is added to the "Success" production rule in the
SIP [RFC3261] message grammar.
7.2. Suppress-If-Match Header Field
The Suppress-If-Match header field is added to the definition of the
"message-header" rule in the SIP [RFC3261] grammar. Its use is
described in Sections 5, 6.3, and 6.2.
This header field is allowed to appear in any request, but its
behavior is only defined for the SUBSCRIBE request.
7.3. Grammar
This section defines the formal syntax for extensions described in
this memo in Augmented BNF (ABNF) [RFC5234]. The rules defined here
augment and reference the syntax defined in RFC 3261 [RFC3261] and
RFC 3903 [RFC3903].
Niemi & Willis Standards Track [Page 22]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
Success =/ "204" ; No Notification
; Success is defined in RFC 3261.
message-header =/ Suppress-If-Match
; message-header is defined in RFC 3261.
Suppress-If-Match = "Suppress-If-Match" HCOLON ( entity-tag / "*" )
; entity-tag is defined in RFC 3903.
8. IANA Considerations
This document registers a new response code and a new header field
name.
8.1. 204 (No Notification) Response Code
This document registers a new response code. This response code is
defined by the following information, which has been added to the
methods and response-codes sub-registry available from
http://www.iana.org.
This information has been added under "Successful 2xx" category.
+---------------------+-----------+
| Response Code | Reference |
+---------------------+-----------+
| 204 No Notification | [RFC5839] |
+---------------------+-----------+
8.2. Suppress-If-Match Header Field
This document registers a new SIP header field called Suppress-If-
Match. This header field is defined by the following information,
which has been added to the header fields sub-registry available from
http://www.iana.org.
+-------------------+---------+-----------+
| Header Name | Compact | Reference |
+-------------------+---------+-----------+
| Suppress-If-Match | | [RFC5839] |
+-------------------+---------+-----------+
Niemi & Willis Standards Track [Page 23]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
9. Security Considerations
The security considerations for SIP event notification are
extensively discussed in RFC 3265 [RFC3265]. This specification
introduces an optimization to SIP event notification, which in itself
does not alter the security properties of the protocol.
10. Acknowledgments
The following people have contributed corrections and suggestions to
this document: Adam Roach, Sean Olson, Johnny Vrancken, Pekka Pessi,
Eva Leppanen, Krisztian Kiss, Peili Xu, Avshalom Houri, David
Viamonte, Jonathan Rosenberg, Qian Sun, Dale Worley, Tolga Asveren,
Brian Stucker, Eric Rescorla, Arun Arunachalam, and the SIP and
SIMPLE working groups.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
Niemi & Willis Standards Track [Page 24]
^L
RFC 5839 Entity-Tags for SIP Events May 2010
[RFC3842] Mahy, R., "A Message Summary and Message Waiting
Indication Event Package for the Session Initiation
Protocol (SIP)", RFC 3842, August 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)",
RFC 3859, August 2004.
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006.
Authors' Addresses
Aki Niemi
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Dean Willis (editor)
Softarmor Systems
3100 Independence Pkwy #311-164
Plano, TX 75075
USA
Phone: +1 214 504 1987
EMail: dean.willis@softarmor.com
Niemi & Willis Standards Track [Page 25]
^L
|