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
|
<pre>Network Working Group Y. Nomura
Request for Comments: 4435 Fujitsu Labs.
Category: Informational R. Walsh
J-P. Luoma
Nokia
H. Asaeda
Keio University
H. Schulzrinne
Columbia University
April 2006
<span class="h1">A Framework for the Usage of Internet Media Guides (IMGs)</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines a framework for the delivery of Internet Media
Guides (IMGs). An IMG is a structured collection of multimedia
session descriptions expressed using the Session Description Protocol
(SDP), SDPng, or some similar session description format. This
document describes a generalized model for IMG delivery mechanisms,
the use of existing protocols, and the need for additional work to
create an IMG delivery infrastructure.
<span class="grey">Nomura, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. New Terms ..................................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. IMG Common Framework Model ......................................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. IMG Data Types .............................................<a href="#page-5">5</a>
<a href="#section-3.1.1">3.1.1</a>. Complete IMG Description ............................<a href="#page-5">5</a>
<a href="#section-3.1.2">3.1.2</a>. Delta IMG Description ...............................<a href="#page-6">6</a>
<a href="#section-3.1.3">3.1.3</a>. IMG Pointer .........................................<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. IMG Entities ...............................................<a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. Operation Set for IMG Delivery .............................<a href="#page-7">7</a>
<a href="#section-3.3.1">3.3.1</a>. IMG ANNOUNCE ........................................<a href="#page-7">7</a>
<a href="#section-3.3.2">3.3.2</a>. IMG QUERY ...........................................<a href="#page-8">8</a>
<a href="#section-3.3.3">3.3.3</a>. IMG RESOLVE .........................................<a href="#page-8">8</a>
<a href="#section-3.3.4">3.3.4</a>. IMG SUBSCRIBE .......................................<a href="#page-8">8</a>
<a href="#section-3.3.5">3.3.5</a>. IMG NOTIFY ..........................................<a href="#page-9">9</a>
<a href="#section-3.3.6">3.3.6</a>. Binding between IMG Operations and Data Types .......<a href="#page-9">9</a>
<a href="#section-3.4">3.4</a>. Overview of Protocol Operations ...........................<a href="#page-10">10</a>
<a href="#section-4">4</a>. Deployment Scenarios for IMG Entities ..........................<a href="#page-10">10</a>
<a href="#section-4.1">4.1</a>. Intermediary Cases ........................................<a href="#page-10">10</a>
<a href="#section-4.2">4.2</a>. One-to-Many Unidirectional Multicast ......................<a href="#page-12">12</a>
<a href="#section-4.3">4.3</a>. One-to-One Bidirectional Unicast ..........................<a href="#page-12">12</a>
<a href="#section-4.4">4.4</a>. Combined Operations with Common Metadata ..................<a href="#page-13">13</a>
5. Applicability of Existing Protocols to the Proposed
Framework Model ................................................<a href="#page-14">14</a>
<a href="#section-5.1">5.1</a>. Existing Standard Fitting the IMG Framework Model .........<a href="#page-14">14</a>
5.2. IMG Mechanism Needs Which Are Not Met by Existing
Standards .................................................<a href="#page-15">15</a>
<a href="#section-5.2.1">5.2.1</a>. A Multicast Transport Protocol .....................<a href="#page-16">16</a>
<a href="#section-5.2.2">5.2.2</a>. Usage of Unicast Transport Protocols ...............<a href="#page-16">16</a>
<a href="#section-5.2.3">5.2.3</a>. IMG Envelope .......................................<a href="#page-17">17</a>
<a href="#section-5.2.4">5.2.4</a>. Metadata Data Model ................................<a href="#page-18">18</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-18">18</a>
<a href="#section-7">7</a>. Normative References ...........................................<a href="#page-19">19</a>
<a href="#section-8">8</a>. Informative References .........................................<a href="#page-19">19</a>
<a href="#section-9">9</a>. Acknowledgements ...............................................<a href="#page-20">20</a>
<span class="grey">Nomura, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Internet Media Guides (IMGs) provide and deliver structured
collections of multimedia descriptions expressed using SDP [<a href="#ref-2" title=""SDP: Session Description Protocol"">2</a>], SDPng
[<a href="#ref-3" title=""Session description and capability negotiation"">3</a>], or other description formats. They are used to describe sets of
multimedia services (e.g., television program schedules, content
delivery schedules) and refer to other networked resources including
web pages. IMGs provide an envelope for metadata formats and session
descriptions defined elsewhere with the aim of facilitating
structuring, versioning, referencing, distributing, and maintaining
(caching, updating) such information.
IMG metadata may be delivered to a potentially large audience, which
uses it to join a subset of the sessions described and which may need
to be notified of changes to the IMG metadata. Hence, a framework
for distributing IMG metadata in various different ways is needed to
accommodate the needs of different audiences: For traditional
broadcast-style scenarios, multicast-based (push) distribution of IMG
metadata needs to be supported. Where no multicast is available,
unicast-based push is required.
This document defines a common framework model for IMG delivery
mechanisms and their deployment in network entities. There are three
fundamental components in the IMG framework model: data types,
operation sets, and entities. These components specify a set of
framework guidelines for efficient delivery and description of IMG
metadata. The data types give generalized means to deliver and
manage the consistency of application-specific IMG metadata. IMG
operations cover broadcast, multicast distribution, event
notification upon change, unicast-based push, and interactive
retrievals similar to web pages.
Since we envision that any Internet host can be a sender and receiver
of IMG metadata, a host involved in IMG operations performs one or
more of the roles defined as the entities in the IMG framework model.
The requirements for IMG delivery mechanisms and descriptions can be
found in the IMG requirements document [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>].
This document outlines the use of existing protocols to create an IMG
delivery infrastructure. It aims to organize existing protocols into
a common model and show their capabilities and limitations from the
viewpoint of IMG delivery functions.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
<span class="grey">Nomura, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. New Terms</span>
Internet Media Guide (IMG): IMG is a generic term to describe the
formation, delivery, and use of IMG metadata. The definition of
the IMG is intentionally left imprecise [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>].
IMG Element: The smallest atomic element of metadata that can be
transmitted separately by IMG operations and referenced
individually from other IMG elements [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>].
IMG Metadata: A set of metadata consisting of one or more IMG
elements. IMG metadata describes the features of multimedia
content used to enable selection of and access to media sessions
containing content. For example, metadata may consist of a media
object's URI, title, airtime, bandwidth needed, file size, text
summary, genre, and access restrictions [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>].
IMG Description: A collection of IMG metadata with a data type
indicating a self-contained set or a subset of IMG metadata, or a
reference to IMG metadata.
IMG Delivery: The process of exchanging IMG metadata both in terms of
large-scale and atomic data transfers [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>].
IMG Sender: An IMG sender is a logical entity that sends IMG metadata
to one or more IMG receivers [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>].
IMG Receiver: An IMG receiver is a logical entity that receives IMG
metadata from an IMG sender [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>].
IMG Transceiver: An IMG transceiver combines an IMG receiver and
sender. It may modify received IMG metadata or merge IMG metadata
received from a several different IMG senders [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>].
IMG Operation: An atomic operation of an IMG transport protocol, used
between IMG sender(s) and IMG receiver(s) for the delivery of IMG
metadata and for the control of IMG sender(s)/receiver(s) [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>].
IMG Transport Protocol: A protocol that transports IMG metadata from
an IMG sender to IMG receiver(s) [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>].
IMG Transport Session: An association between an IMG sender and one
or more IMG receivers within the scope of an IMG transport
protocol. An IMG transport session involves a time-bound series
of IMG transport protocol interactions that provide delivery of
IMG metadata from the IMG sender to the IMG receiver(s) [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>].
<span class="grey">Nomura, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
IMG Transfer: A transfer of IMG metadata from an IMG sender to IMG
receiver(s).
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. IMG Common Framework Model</span>
Two common elements are found in all existing IMG candidate cases:
the need to describe the services and the need to deliver the
descriptions. In some cases, the descriptions provide multicast
addresses and thus are part of the transport configuration. In other
cases, descriptions are specific to the media application and may be
meant for either human or machine consumption. Thus, the
technologies can be roughly divided into three areas:
o Application-specific Metadata: data describing the content of
services and media which are both specific to certain
applications and generally human readable.
o Delivery Descriptions: the descriptions (metadata) that are
essential to enable (e.g., multicast) delivery. These include
framing (headers) for application-specific metadata, the
metadata element identification and structure, and fundamental
session data.
o Delivery Protocols: the methods and protocols to exchange
descriptions between the senders and the receivers. An IMG
transport protocol consists of two functions: carrying IMG
metadata from an IMG sender to an IMG receiver and controlling
an IMG transport protocol. These functions are not always
exclusive; therefore, some messages may combine control messages
and metadata carriage functions to reduce the amount of the
messaging.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. IMG Data Types</span>
A data model is needed to precisely define the terminology and
relationships between sets, supersets, and subsets of metadata. A
precise data model is essential for the implementation of IMGs,
although it is not within the scope of this framework and requires a
separate specification. However, there are three IMG data types in
general: Complete IMG Descriptions, Delta IMG Descriptions, and IMG
Pointers.
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Complete IMG Description</span>
A Complete IMG Description provides a self-contained set of metadata
for one media object or service, i.e., it does not need additional
information from any other IMG element. This is not to be confused
with "complete IMG metadata", which, although vaguely defined here,
<span class="grey">Nomura, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
represents the complete IMG metadata database of an IMG sender (or
related group of IMG senders -- potentially the complete Internet IMG
knowledge). An IMG sender will generally deliver only subsets of
metadata from its complete database in a particular IMG transport
session.
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Delta IMG Description</span>
A Delta IMG Description provides only part of a Complete IMG
Description, defining the difference from a previous version of the
Complete IMG Description. Delta IMG Descriptions may be used to
reduce network resource usage, for instance, when data consistency is
essential and small and frequent changes occur to IMG elements.
Thus, this description does not represent a complete set of metadata
until it is combined with other metadata that may already exist or
arrive in the future.
<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>. IMG Pointer</span>
An IMG Pointer identifies or locates metadata. This may be used to
separately obtain metadata (Complete or Delta IMG Descriptions) or
perform another IMG management function such as data expiry (and
erasure). The IMG Pointer may be used to reference IMG metadata
elements within the IMG transport session and across IMG transport
sessions. This pointer type does not include IMG metadata per se
(although it may also appear as a data field in Complete or Delta IMG
Descriptions).
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. IMG Entities</span>
There are several fundamental IMG entities that indicate the
capability to perform certain roles. An Internet host involved in
IMG operations may adopt one or more of these roles, which are
defined in more detail in <a href="#section-3.3">Section 3.3</a>.
IMG Announcer: sends IMG ANNOUNCE
IMG Listener: receives IMG ANNOUNCE
IMG Querier: sends IMG QUERY and receives IMG RESOLVE
IMG Resolver: receives IMG QUERY then sends IMG RESOLVE
IMG Subscriber: sends IMG SUBSCRIBE then receives IMG NOTIFY
IMG Notifier: receives IMG SUBSCRIBE then sends IMG NOTIFY
<span class="grey">Nomura, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
Figure 1 shows the relationship between IMG entities and the IMG
sender and receiver.
+--------------------------------------------------------+
| IMG Sender |
+------------------+------------------+------------------+
| IMG Announcer | IMG Notifier | IMG Resolver |
+------------------+------------------+------------------+
| ^ ^
message | | |
direction v v v
+------------------+------------------+------------------+
| IMG Listener | IMG Subscriber | IMG Querier |
+------------------+------------------+------------------+
| IMG Receiver |
+------------------+------------------+------------------+
Figure 1: Relationship between IMG Entities, Senders, and Receivers
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Operation Set for IMG Delivery</span>
A finite set of operations both meets the IMG requirements [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>] and
fits the roles of existing protocols. These are crystallized in the
next few sections.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. IMG ANNOUNCE</span>
When an IMG receiver participates in unidirectional communications
(e.g., over satellite, terrestrial radio, and wired multicast
networks), an IMG receiver may not need to send any IMG message to an
IMG sender prior to IMG metadata delivery. In this case, an IMG
sender can initiate unsolicited distribution for IMG metadata and an
IMG sender is the only entity that can maintain the distribution
(this includes scenarios with multiple and cooperative IMG senders).
This operation is useful when there are large numbers of IMG
receivers or the IMG receivers do not have a guaranteed uplink
connection to the IMG sender. The IMG sender may also include
authentication data in the ANNOUNCE operation so that IMG receivers
may check the authenticity of the metadata. This operation can carry
any of the IMG data types.
There is no restriction to prevent IMG ANNOUNCE from being used in an
asynchronous solicited manner, where a separate operation (possibly
out of band) enables IMG receivers to subscribe/register to the IMG
ANNOUNCE operation.
<span class="grey">Nomura, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. IMG QUERY</span>
If an IMG receiver needs to obtain IMG metadata, an IMG receiver can
use an IMG QUERY operation and initiate a receiver-driven IMG
transport session. The IMG receiver expects a synchronous response
to the subsequent request from the IMG sender. This operation can be
used where a bidirectional transport network is available between the
IMG sender and receiver. Some IMG receivers may want to obtain IMG
metadata when network connectivity is available or just to avoid
caching unsolicited IMG metadata. The IMG receiver must indicate the
extent and data type of metadata wanted in some message in the
operation. The extent indicates the number and grouping of metadata
descriptions. In some cases, it may be feasible to request an IMG
sender's complete metadata collection.
<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>. IMG RESOLVE</span>
An IMG sender synchronously responds, and sends IMG metadata, to an
IMG QUERY that has been sent by an IMG receiver. This operation can
be used where a bidirectional transport network is available between
the IMG sender and receiver. If the IMG QUERY specifies a subset of
IMG metadata (extent and data type) that is available to the IMG
sender, the IMG sender can resolve the query; otherwise, it should
indicate that it is not able to resolve the query. The IMG sender
may authenticate the IMG receiver during the QUERY operation to
determine if the IMG receiver is authorized to receive that metadata.
The sender may also include authentication data in the RESOLVE
operation so that IMG receivers may check the authenticity of the
metadata. This operation may carry any of the IMG data types.
<span class="h4"><a class="selflink" id="section-3.3.4" href="#section-3.3.4">3.3.4</a>. IMG SUBSCRIBE</span>
If an IMG receiver wants to be notified when the IMG metadata it
holds becomes stale, the IMG receiver can use the IMG SUBSCRIBE
operation in advance in order to solicit IMG NOTIFY messages from an
IMG sender.
This operation may provide the IMG sender with specific details of
which metadata or notification services it is interested in the case
where the IMG sender offers more than the simplest "all data"
service. This operation implicitly provides the functionality of
unsubscribing to inform an IMG sender that an IMG receiver wishes to
stop getting certain (or all) notifications. It should be noted that
unsubscription may be provided implicitly by the expiry (timeout) of
a subscription before it is renewed.
<span class="grey">Nomura, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
Since the IMG receiver does not know when metadata will be updated
and the notify message will arrive, this operation does not
synchronize with the notify messages. The IMG receiver may wait for
notify messages for a long time. The IMG sender may authenticate the
IMG receiver to check whether an IMG SUBSCRIBE operation is from an
authorized IMG receiver.
<span class="h4"><a class="selflink" id="section-3.3.5" href="#section-3.3.5">3.3.5</a>. IMG NOTIFY</span>
An IMG NOTIFY is used asynchronously in response to an earlier IMG
SUBSCRIBE. An IMG NOTIFY operation indicates that updated IMG
metadata is available or part of the existing IMG metadata is stale.
An IMG NOTIFY may be delivered more than once during the time an IMG
SUBSCRIBE is active. This operation may carry any of the IMG data
types. The IMG sender may also include authentication data in the
IMG NOTIFY operation so that IMG receivers may check the authenticity
of the messages.
<span class="h4"><a class="selflink" id="section-3.3.6" href="#section-3.3.6">3.3.6</a>. Binding between IMG Operations and Data Types</span>
There is a need to provide a binding between the various IMG
operations and IMG data types to allow management of each discrete
set of IMG metadata transferred using an IMG operation. This binding
must be independent of any particular metadata syntax used to
represent a set of IMG metadata, as well as be compatible with any
IMG transport protocol. The binding must uniquely identify the set
of IMG metadata delivered within an IMG transfer, regardless of the
metadata syntax used. The uniqueness may only be needed within the
domains the metadata is used, but this must enable globally unique
identification to support Internet usage. Care should be taken that
scope- and domain-specific identifiers do not leak outside the scope;
using globally unique identifiers such as URLs avoids these problems.
The binding must provide versioning to the transferred IMG metadata
so that changes can be easily handled and stale data identified, and
give temporal validity of the transferred IMG metadata. It must
invalidate the IMG metadata by indicating an expiry time, and may
optionally provide a time (presumably in the future) from when the
IMG metadata becomes valid. The temporal validity of a metadata
object may need to be updated later. Furthermore, the binding must
be independent of any specific metadata syntax used for the IMG
metadata, in the sense that no useful syntax should be excluded.
<span class="grey">Nomura, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Overview of Protocol Operations</span>
Figure 2 gives an overview of the relationship between transport
cases, IMG operations, and IMG data types. It is not a protocol
stack. Generalized multicast point-to-multipoint (P-to-M) and
unicast point-to-point (P-to-P) transports are shown.
+--------------------------------------------------+
IMG | |
Data Types | Complete Desc., Delta Desc., Pointer |
| |
+-------------------+----------------+-------------+
IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY |
Operations | | IMG NOTIFY | IMG RESOLVE |
+--------------+----+----------------+-------------+
IMG | | |
Transport | P-to-M | P-to-P |
| | |
+--------------+-----------------------------------+
Figure 2: IMG Transport, IMG Operations, and IMG Data Types
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Deployment Scenarios for IMG Entities</span>
This section provides some basic deployment scenarios for IMG
entities that illustrate common threads from protocols to use cases.
For the purposes of clarity, this document presents the simple
dataflow from an IMG sender to an IMG receiver, as shown in Figure 3.
+-------------+ +---------------+
| IMG Sender | | IMG Receiver |
| |--------------->| |
+-------------+ +---------------+
Figure 3: A Simple IMG Sender to IMG Receiver Relationship
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Intermediary Cases</span>
Some IMG metadata may be distributed to a large number of IMG
receivers, for example, when public metadata is distributed to all
IMG receivers of a certain group. This kind of IMG metadata may be
distributed from one IMG sender to multiple IMG receivers (Figure 4)
or may be relayed across a set of IMG transceivers that receive the
IMG metadata, possibly filter or modify its content, and then forward
it.
<span class="grey">Nomura, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
+----------+ +----------+
| IMG | | IMG |
| Sender |---- ---->| Receiver |
+----------+ \ / +----------+
\ /
. \ +-----------+ / .
. -->|IMG |----- .
. -->|Transceiver| \ .
/ +-----------+ \
+----------+ / \ +----------+
| IMG | / ---->| IMG |
| Sender |---- | Receiver |
+----------+ +----------+
Figure 4: A Relay Network with an IMG Transceiver
IMG senders and receivers are logical functions, and it is possible
for some or all hosts in a system to perform both roles, as, for
instance, in many-to-many communications or where a transceiver is
used to combine or aggregate IMG metadata for some IMG receivers. An
IMG receiver may be allowed to receive IMG metadata from any number
of IMG senders.
IMG metadata is used to find, obtain, manage, and play media content.
IMG metadata may be modified during IMG transfer. For example, a
server may use IMGs to retrieve media content via unicast and then
make it available at scheduled times via multicast, thus requiring a
change of the corresponding metadata. IMG transceivers may add or
delete information or aggregate IMG metadata from different IMG
senders. For example, a rating service may add its own content
ratings or recommendations to existing metadata. An implication of
changing (or aggregating) IMG metadata from one or more IMG senders
is that the original authenticity is lost. Thus, it may be
beneficial to sign fragments so that the intermediary can replace a
fragment without changing the authenticity of the remainder. For
example, smaller fragments may be appropriate for more volatile
parts, and larger ones may be appropriate for stable parts.
<span class="grey">Nomura, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. One-to-Many Unidirectional Multicast</span>
The one-to-many unidirectional multicast case implies many IMG
receivers and one or more IMG senders implementing IMG announcer and
IMG listener operations as shown in Figure 5.
Unidirectional +----------+
---------------> | IMG |
downlink | Listener |
------------->| 1 |
/ +----------+
+-----------+ / .
| IMG |-------- .
| Announcer | \ .
+-----------+ \ +----------+
------------->| IMG |
| Listener |
| # |
+----------+
Figure 5: IMG Unidirectional Multicast Distribution Example
Note, as defined in the IMG requirement REL-4 [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>], an IMG transport
protocol MUST support reliable message exchange. This includes the
one-to-many unidirectional multicast case; however, the mechanism to
provide this is beyond the scope of this document.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. One-to-One Bidirectional Unicast</span>
In the one-to-one bidirectional unicast case, both query/resolve
(Figure 6) and subscribe/notify (Figure 7) message exchange
operations are feasible.
+----------+ +----------+
| IMG | | IMG |
| Resolver | | Querier |
+----------+ +----------+
| |
|<----------IMG QUERY -----------|
| |
|----------IMG RESOLVE---------->|
| |
Figure 6: Query/Resolve Sequence Example
<span class="grey">Nomura, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
+----------+ +------------+
| IMG | | IMG |
| Notifier | | Subscriber |
+----------+ +------------+
| |
|<---------IMG SUBSCRIBE---------|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
| |
Figure 7: Subscribe/Notify Sequence Example
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Combined Operations with Common Metadata</span>
As shown in Figure 8, a common data model for multiple protocol
operations allows a diverse range of IMG senders and receivers to
provide consistent and interoperable sets of IMG metadata.
IMG Metadata IMG Senders IMG Receivers
+--------------+
+-----------+ ---->| IMG Listener |
| IMG | / +--------------+
/| Announcer |-----
+-------------+ / +-----------+ \ +--------------+
| IMG |-+ / ---->| IMG Listener |
| description | |-+ / | - - - - - - -|
| metadata 1 | | | / +-----------+ /--->| IMG Querier |
+-------------+ | | -----| IMG |<----/ +--------------+
+-------------+ | \ | Resolver |
+-------------+ \ +-----------+<----\ +--------------+
\ \--->| IMG Querier |
\ +-----------+ | - - - - - - -|
\| IMG |<--------->| IMG |
| Notifier | | Subscriber |
+-----------+ +--------------+
Figure 8: Combined System with Common Metadata
<span class="grey">Nomura, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Applicability of Existing Protocols to the Proposed Framework Model</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Existing Standards Fitting the IMG Framework Model</span>
SDP: The SDP format [<a href="#ref-2" title=""SDP: Session Description Protocol"">2</a>] could be used to describe session-level
parameters (e.g., scheduling, addressing, and the use of media
codecs) to be included in Complete IMG Descriptions. Although there
are extension points in SDP allowing the format to be extended, there
are limitations in the flexibility of this extension mechanism.
However, SDP syntax cannot provide IMG Descriptions and IMG Pointers
without significant overhead. It is expected that the information
conveyed by SDP is just a small subset of IMG metadata; thus, the use
of SDP for other than session parameters may not be reasonable.
SDPng [<a href="#ref-3" title=""Session description and capability negotiation"">3</a>]: Similar to SDP, this format could also be used for
representing session-level parameters of IMG metadata. Compared to
SDP, the XML-based format of SDPng should be much more flexible and
allow extensions and integration with other description formats.
MPEG-7: Descriptions based on the MPEG-7 standard [<a href="#ref-5" title=""Multimedia content description interface -- Part 1: Systems"">5</a>] could provide
application-specific metadata describing the properties of multimedia
content beyond parameters carried in SDP or SDPng descriptions.
MPEG-7 provides a machine-readable format of representing content
categories and attributes, helping end-users or receiving software in
choosing content for reception. MPEG-7 is based on XML, so it is
well suited to be combined with other XML-based formats such as
SDPng.
TV-Anytime: The TV-Anytime Forum [<a href="#ref-6" title=""Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("">6</a>] provides descriptions based on
XML schema for TV-specific program guides. TV-Anytime uses the
MPEG-7 User description profile to a limited extent, only for user
preferences and usage history, and also a TV-Anytime-specific data
model for other schema. These are optimized to describe broadcast
schedules, on-demand program guides and program events.
HTTP: The HTTP protocol [<a href="#ref-7" title=""Hypertext Transfer Protocol -- HTTP/1.1"">7</a>] can be used as a bidirectional unicast
IMG transport protocol. Being a request-reply-oriented protocol,
HTTP is well suited for implementing synchronous operations such as
QUERY, RESOLVE, and even SUBSCRIBE. However, HTTP does not provide
asynchronous operations such as ANNOUNCE and NOTIFY and to implement
asynchronous operations using HTTP, IMG receivers should poll the IMG
sender periodically. Thus, by itself, HTTP is not sufficient to
fulfill all of the IMG requirements [<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>] in a unicast deployment.
Session Announcement Protocol (SAP): The announcement mechanism
provided by SAP [<a href="#ref-8" title=""Session Announcement Protocol"">8</a>] provides unidirectional delivery of session
discovery information. Although SDP is the default payload format of
SAP, the use of a MIME type identifier for the payload allows
<span class="grey">Nomura, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
arbitrary payload formats to be used in SAP messages. Thus, SAP
could be used to implement the multicast and unicast IMG ANNOUNCE and
IMG NOTIFY operations.
However, SAP lacks scalable and efficient reliability, extensibility
for payload size, and congestion control, and only one description is
allowed per SAP message due to lack of payload segmentation.
In principle, SAP could be extended to get around its limitations.
However, the amount of changes needed in SAP to address all of the
above limitations would effectively result in a new protocol. Due to
these limitations, the use of SAP as an IMG transport protocol is not
recommended.
SIP: The SIP-specific event mechanism described in <a href="./rfc3265">RFC 3265</a> [<a href="#ref-9" title=""Session Initiation Protocol (SIP)-Specific Event Notification"">9</a>]
provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations
via a bidirectional unicast connection. However, there are
scalability problems with this approach, as <a href="./rfc3265">RFC 3265</a> currently does
not consider multicast.
Real Time Streaming Protocol (RTSP): The RTSP protocol [<a href="#ref-10" title=""Real Time Streaming Protocol (RTSP)"">10</a>] defines a
retrieval-and-update notification mechanism, named DESCRIBE and
ANNOUNCE, for the description of a presentation or media object in
order to initialize a streaming session. These methods are a subset
of the entire streaming control operations in RTSP; thus, these could
not be available for individual mechanisms. However, the DESCRIBE
method in RTSP could be used to instantiate IMG QUERY, IMG RESOLVE,
and IMG SUBSCRIBE, and the RTSP ANNOUNCE could be used to instantiate
an IMG NOTIFY for a streaming session controlled by RTSP.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. IMG Mechanism Needs Which Are Not Met by Existing Standards</span>
Several needs result from the IMG requirements, framework model, and
existing relevant mechanisms as already shown in this document. Four
specific groupings of work are readily apparent: (a) specification of
an adequate multicast- and unidirectional-capable announcement
protocol; (b) specification of the use of existing unicast protocols
to enable unicast subscribe and announcement/notification
functionality; (c) specification of the metadata envelope that is
common to, and independent of, the application metadata syntax(es)
used; and (d) agreement on basic metadata models to enable
interoperability testing of the above. The following sections
describe each of these.
<span class="grey">Nomura, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. A Multicast Transport Protocol</span>
SAP is currently the only open standard protocol suited to the
unidirectional/multicast delivery of IMG metadata. As discussed, it
fails to meet the IMG requirements in many ways and, since it is not
designed to be extensible, we recognize that a new multicast
transport protocol for announcements needs to be specified to meet
IMG needs. This protocol will be essential to IMG delivery for
unidirectional and multicast deployments.
The Asynchronous Layered Coding (ALC) [<a href="#ref-11" title=""Asynchronous Layered Coding (ALC) Protocol Instantiation"">11</a>] protocol from the IETF
Reliable Multicast Transport (RMT) working group is very interesting
as it fulfills many of the requirements, is extensible, and has the
ability to 'plug-in' both FEC (Forward Error Correction, for
reliability) and CC (Congestion Control) functional blocks. It is
specifically designed for unidirectional multicast object transport.
ALC is not fully specified, although the RMT working group had a
fully specified protocol using ALC called FLUTE (File Delivery over
Unidirectional Transport) [<a href="#ref-12" title=""FLUTE - File Delivery over Unidirectional Transport"">12</a>]. FLUTE seems to be the only fully
specified transport and open specification on which a new IMG
announcement protocol could be designed. Thus, we recommend that ALC
and FLUTE be the starting points for this protocol's design.
Developing a new protocol from scratch, or attempting to improve SAP,
is also feasible, although it would involve repeating many of the
design processes and decisions already made by the IETF for ALC. In
particular, any announcement protocol must feature sufficient
scalability, flexibility, and reliability to meet IMG needs. Also,
the IMG ANNOUNCE operation must be supported and IMG NOTIFY
capability could be investigated for both hybrid unicast-multicast
and unidirectional unicast systems.
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Usage of Unicast Transport Protocols</span>
A thorough description of the use of existing unicast protocols is
essential for the use of IMGs in a unicast point-to-point
environment. Such a specification has not been published, although
several usable unicast transport protocols and specifications can be
harnessed for this (SIP [<a href="#ref-13" title=""SIP: Session Initiation Protocol"">13</a>], SIP events [<a href="#ref-9" title=""Session Initiation Protocol (SIP)-Specific Event Notification"">9</a>], HTTP [<a href="#ref-7" title=""Hypertext Transfer Protocol -- HTTP/1.1"">7</a>], etc.). In
particular, both IMG SUBSCRIBE-NOTIFY and IMG QUERY-RESOLVE operation
pairs must be enabled. We anticipate that the IMG QUERY-RESOLVE
operation can be achieved using HTTP, although other transport
protocol options may be beneficial to consider too.
<span class="grey">Nomura, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>. IMG Envelope</span>
An IMG envelope provides the binding between IMG operations and data
types. Such a binding can be realized by defining a common minimal
set of information needed to manage IMG metadata transfers, and by
including this information with any set of IMG metadata delivered to
IMG receivers.
Four options for IMG metadata transfer envelope delivery are
feasible:
1. Embedding in a transport protocol header. This can be done
with either header extensions of existing protocols, or newly
defined header fields of a new (or new version of a) transport
protocol. However, multiple methods for the variety of
transport protocols would hinder interoperability and
transport protocol independence.
2. A separate envelope object, which points to the IMG metadata
'object', delivered in-band with the metadata transport
protocol session. This might complicate delivery as the
envelope and 'service' metadata objects would have to be
bound, e.g., by pairing some kind of transport object numbers
(analogous to port number pairs sometimes used for RTP and
RTCP [<a href="#ref-14" title=""RTP: A Transport Protocol for Real-Time Applications"">14</a>]). This would also enable schemes that deliver
envelope and metadata 'objects' by different media, also using
more than a single transport protocol.
3. A metadata wrapper that points to and/or embeds the service
metadata into its 'super-syntax'. For example, XML would
enable embedding generic text objects.
4. Embedding in the metadata itself. However, this requires a
new field in many metadata syntaxes and would not be feasible
if a useful syntax were not capable of extensibility in this
way. It also introduces a larger 'implementation
interpretation' variety, which would hinder interoperability.
Thus, this option is not recommended.
It is likely that more than one of these options will fulfill the
needs of IMGs, so the selection, and possibly optimization, is left
for subsequent specification and feedback from implementation
experience. Such a specification is essential for IMG delivery.
When there are superset/subset relations between IMG Descriptions, it
is assumed that the IMG Descriptions of the subset inherit the
parameters of the superset. Thus, an IMG metadata transfer envelope
carrying the IMG Descriptions of a superset may implicitly define
<span class="grey">Nomura, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
parameters of IMG Descriptions belonging to its subset. The
relations between IMG Descriptions may span from one envelope to
another according to a data model definition.
<span class="h4"><a class="selflink" id="section-5.2.4" href="#section-5.2.4">5.2.4</a>. Metadata Data Model</span>
A structured data model would allow reuse and extension of the set of
metadata and may enable use of multiple syntaxes (SDP, MPEG-7, etc.)
as part of the same body of IMG metadata.
For the successful deployment of IMGs in various environments,
further work may be needed to define metadata and data models for
application-specific requirements. Existing (and future) work on
these would need to be mapped to the IMG data types and use of the
IMG transfer envelope concept as described above.
This document is a framework for the delivery of IMG metadata and
thus further discussion on the definition data models for IMGs is
beyond its scope.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The IMG framework is developed from the IMG requirements document
[<a href="#ref-4" title=""Requirements for Internet Media Guides"">4</a>], and so the selection of specific protocols and mechanism for use
with the IMG framework must also take into account the security
considerations of the IMG requirements document. This framework
document does not mandate the use of specific protocols. However, an
IMG specification would inherit the security considerations of
specific protocols used.
Protocol instantiations that are used to provide IMG operations will
have very different security considerations depending on their scope
and purpose. However, there are several general issues that are
valuable to consider and, in some cases, provide technical solutions
for. These are described below.
Individual and group privacy: Customized IMG metadata may reveal
information about the habits and preferences of a user and may thus
deserve confidentiality protection, even if the original information
were public. Protecting this metadata against snooping requires the
same actions and measures as for other point-to-point and multicast
Internet communications. Naturally, the risk of snooping depends on
the amount of individual or group personalization the IMG metadata
contains.
IMG authenticity: In some cases, the IMG receiver needs to be assured
of the sender or origin of IMG metadata or its modification history.
This can prevent denial-of-service or hijacking attempts that give an
<span class="grey">Nomura, et al. Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
IMG receiver incorrect information in or about the metadata, thus
preventing successful access of the media or directing the IMG
receiver to the incorrect media possibly with tasteless material.
IMG receiver authorization: Some or all of any IMG sender's metadata
may be private or valuable enough to allow access to only certain IMG
receivers and thus make it worth authenticating users. Encrypting
the data is also a reasonable step, especially where group
communications methods results in unavoidable snooping opportunities
for unauthorized nodes.
Unidirectional specifics: A difficulty that is faced by
unidirectional delivery operations is that many protocols providing
application-level security are based on bidirectional communications.
The application of these security protocols in case of strictly
unidirectional links is not considered in the present document.
Malicious code: Currently, IMGs are not envisaged to deliver
executable code at any stage. However, as some IMG transport
protocols may be capable of delivering arbitrary files, it is
RECOMMENDED that the IMG operations do not have write access to the
system or any other critical areas.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Normative References</span>
[<a id="ref-1">1</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Informative References</span>
[<a id="ref-2">2</a>] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", <a href="./rfc2327">RFC 2327</a>, April 1998.
[<a id="ref-3">3</a>] Kutscher, D., Ott, J., and C. Bormann, "Session description and
capability negotiation", Work in Progress, October 2003.
[<a id="ref-4">4</a>] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H. Schulzrinne,
"Requirements for Internet Media Guides", Work in Progress,
December 2005.
[<a id="ref-5">5</a>] "Multimedia content description interface -- Part 1: Systems",
ISO/IEC 15938-1, July 2002.
[<a id="ref-6">6</a>] TV-Anytime Forum, "Broadcast and On-line Services: Search,
select, and rightful use of content on personal storage systems
("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102
822-2: System Description, V1.1.1, October 2003.
<span class="grey">Nomura, et al. Informational [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
[<a id="ref-7">7</a>] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.
[<a id="ref-8">8</a>] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", <a href="./rfc2974">RFC 2974</a>, October 2000.
[<a id="ref-9">9</a>] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", <a href="./rfc3265">RFC 3265</a>, June 2002.
[<a id="ref-10">10</a>] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", <a href="./rfc2326">RFC 2326</a>, April 1998.
[<a id="ref-11">11</a>] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", <a href="./rfc3450">RFC 3450</a>, December 2002.
[<a id="ref-12">12</a>] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport", <a href="./rfc3926">RFC 3926</a>,
October 2004.
[<a id="ref-13">13</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>, June 2002.
[<a id="ref-14">14</a>] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
<a href="./rfc3550">RFC 3550</a>, July 2003.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
The authors would like to thank Spencer Dawkins, Jean-Pierre Evain,
Ted Hardie, Petri Koskelainen, Joerg Ott, Colin Perkins, Toni Paila,
and Magnus Westerlund for their excellent ideas and input to this
document.
<span class="grey">Nomura, et al. Informational [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
Authors' Addresses
Yuji Nomura
Fujitsu Laboratories Ltd.
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588
Japan
EMail: nom@flab.fujitsu.co.jp
Rod Walsh
Nokia Research Center
P.O. Box 100, FIN-33721 Tampere
Finland
EMail: rod.walsh@nokia.com
Juha-Pekka Luoma
Nokia Research Center
P.O. Box 100, FIN-33721 Tampere
Finland
EMail: juha-pekka.luoma@nokia.com
Hitoshi Asaeda
Keio University
Graduate School of Media and Governance
5322 Endo, Fujisawa, 252-8520 Kanagawa,
Japan
EMail: asaeda@wide.ad.jp
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu
<span class="grey">Nomura, et al. Informational [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4435">RFC 4435</a> IMG Framework April 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Nomura, et al. Informational [Page 22]
</pre>
|
