RFC 4473
Requirements for Internet Media Guides (IMGs)
Requirements for Internet Media Guides (IMGs) 🎀
okay bestie, let's get into RFC 4473 💅 It's an Informational doc, so it's giving "here's some useful info" and not "this is an official standard" 🤓 It's from the Network Working Group, dated May 2006 📅 The authors are Y. Nomura (Fujitsu Labs), R. Walsh, J-P. Luoma (Nokia), J. Ott (Helsinki University of Technology), and H. Schulzrinne (Columbia University) 🫶 The header doesn't have an Obsoletes or Updates line, so it doesn't list anything it replaces or changes 🧚
Status of This Memo
this memo is giving info for the whole Internet community ✨ it does not specify an Internet standard of any kind, and distribution of it is unlimited 🌈
Copyright Notice
Copyright (C) The Internet Society (2006) 💜
Abstract
this memo lays out requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications 🎬 these requirements are meant to guide how IMG protocols get chosen and built, so they can deliver things efficiently and at scale 🚀
Table of Contents
1. Introduction ....................................................3
1.1. Background and Motivation ..................................3
1.2. Scope of This Document .....................................4
2. Terminology .....................................................5
2.1. New Terms ..................................................5
3. Problem Statement ...............................................6
4. Use Cases Requiring IMGs ........................................7
4.1. Connectivity-based Use Cases ...............................7
4.1.1. IP Datacast to a Wireless Receiver ..................7
4.1.2. Regular Fixed Dial-up Internet Connection ...........8
4.1.3. Broadband Always-on Fixed Internet Connection .......9
4.2. Content-orientated Use Cases ...............................9
4.2.1. TV and Radio Program Delivery .......................9
4.2.2. Media Coverage of a Live Event .....................10
4.2.3. Distance Learning ..................................10
4.2.4. Multiplayer Gaming .................................10
4.2.5. File Distribution ..................................11
4.2.6. Coming-release and Pre-released Content ............11
5. Requirements ...................................................11
5.1. General Requirements ......................................11
5.1.1. Independence of IMG Operations from IMG Metadata ...11
5.1.2. Multiple IMG Senders ...............................12
5.1.3. Modularity .........................................12
5.2. Delivery Properties .......................................12
5.2.1. Scalability ........................................13
5.2.2. Support for Intermittent Connectivity ..............13
5.2.3. Congestion Control .................................13
5.2.4. Sender- and Receiver-Driven Delivery ...............13
5.3. Customized IMGs ...........................................14
5.4. Reliability ...............................................15
5.4.1. Managing Consistency ...............................15
5.4.2. Reliable Message Exchange ..........................16
5.5. IMG Descriptions ..........................................16
6. Security Considerations ........................................17
6.1. IMG Authentication and Integrity ..........................18
6.2. Privacy ...................................................19
6.3. Access Control for IMGs ...................................19
6.4. Denial-of-Service (DOS) Attacks ...........................20
6.5. Replay Attacks ............................................20
7. Normative References ...........................................21
8. Informative References .........................................21
9. Acknowledgements ...............................................221. Introduction ✨
1.1. Background and Motivation
okay so for about ten years, multicast-based (multimedia) conferences 📡 (including IETF working group sessions) and broadcasts of lectures, seminars, concerts, and other events have been happening on the Internet, specifically on the MBONE 🎶 schedules, descriptions, transport addresses, codecs, and their parameters for these multimedia sessions were described with the Session Description Protocol (SDP) [2], which was a rudimentary (but back then pretty much good enough) way to do it 🧃 the descriptions got passed around with the Session Announcement Protocol (SAP) [3] and session directory tools like SD [4] or SDR [5], and they also ended up on web pages, in email, and so on 💌
now interest has grown in expanding, or really generalizing, where these session descriptions can be used 🌸 descriptions are getting more detailed in terms of metadata, more generic about the kinds of media sessions they cover, and might also support transports other than IP (like legacy TV channel addresses) 📺 this lines up nicely with the increased work of the DVB (Digital Video Broadcasting) [6] Organization on IP-based communications over satellite, cable, and terrestrial radio networks, and on treating IP as the basis for TV broadcasts and other services too 🛰️ these program and content descriptions are called Internet Media Guides (IMGs), and you can think of them as a generalization of Electronic Program Guides (EPGs) and multimedia session descriptions 🧚
an Internet Media Guide (IMG) is a structured collection of multimedia session descriptions written in SDP, SDPng [7], or some similar session description format 💖 it's used to describe a set of multimedia services (for example, TV program schedules or content delivery schedules), but it can also point to other networked resources, including web pages 🌐 IMGs act as the envelope for metadata formats and session descriptions defined somewhere else, with the goal of making it easier to structure, version, reference, distribute, and maintain (cache and update) that information 📦
IMG metadata can reach a potentially large audience, and those people use it to join a subset of the sessions described, and they may need to be told when the information changes 👑 so we need a framework that can distribute IMG metadata in lots of different ways to fit different audiences. for traditional broadcast-style scenarios, multicast-based (push) distribution of IMG metadata needs to be supported 📣 where there's no multicast available, unicast-based push is required too 🫶
IMG metadata may also need to be retrieved interactively, kind of like web pages (for example, after rebooting a system, or when a user is browsing after network connectivity has come back) 🔄 and IMG metadata may get updated over time because the content it describes can change. for example, the airtime of a concert or sports event might shift, which could affect the airtime of whatever media comes after it ⏰ this can be handled by polling the IMG sender, and also by asynchronous change notifications 🔔
any Internet host can be a sender of content, and so an IMG sender too 💅 some content sources and sinks are only connected to the Internet sporadically 📶 a single human user might also use many different devices to access metadata, so we picture IMG metadata being sent and received by things like cellular phones, Personal Digital Assistants (PDAs), personal computers, streaming video servers, set-top boxes, video cameras, and Digital Video Recorders (DVRs) 📱 the data should be able to travel across arbitrary types of link layers, including bandwidth-constrained mobile networks 🚐 that said, we generally expect IMG senders to be well-connected hosts 🌟
finally, with lots of potential senders and receivers, different types of networks, and presumably plenty of service providers, IMG metadata may need to be combined, split, filtered, augmented, modified, and so on, on its way from the sender(s) to the receiver(s) 🎀 the goal is to give the ultimate user a suitable selection of multimedia services based on her preferences, subscriptions, location, and context (for example, her devices and access networks) 💜
1.2. Scope of This Document
this document defines requirements that Internet Media Guide mechanisms must satisfy in order to deliver IMG metadata to a potentially large audience ✨ since IMGs can describe many kinds of multimedia content, IMG methods are generally applicable to several scenarios 🦋
it gives the problem statement and talks about existing mechanisms in this area 🔍 then it explains several use case scenarios for IMGs, including how IMG metadata and IMG delivery mechanisms contribute to each one 🍓 after that, it lays out general requirements that don't depend on any transport layer mechanism or application, such as delivery properties, reliability, and IMG descriptions 💖
this document reflects investigation work on delivery mechanisms for IMGs, and it generalizes work on session announcement and initiation protocols, especially in the MMUSIC working group (SAP, SIP [8], SDP) 🌈
2. Terminology 💅
okay this part is the key words bit, and these ones are super important 🔥 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 RFC 2119 [1] 🫶
2.1. New Terms 📚
Okay bestie, time for the vocab 🧚 First up is Internet Media Guide (IMG), which is a generic umbrella term for the formation, delivery, and use of IMG metadata. The definition of IMG is intentionally left imprecise 🙈 (on purpose, not a typo!)
IMG Element: The smallest atomic piece of metadata that can be transmitted separately by IMG operations and referenced individually from other IMG elements. 🍓
IMG Metadata: A set of metadata made up of one or more IMG elements. IMG metadata describes the features of multimedia content, and it's what lets you select and access the media sessions that contain that content. For example, metadata may consist of the URI, title, airtime, bandwidth needed, file size, text summary, genre, and access restrictions. 🎀
IMG Delivery: The process of exchanging IMG metadata through both large-scale and atomic data transfers. 🚚
IMG Sender: An IMG sender is a logical entity that sends IMG metadata to one or more IMG receivers. 📤
IMG Receiver: An IMG receiver is a logical entity that receives IMG metadata from an IMG sender. 📥
IMG Transceiver: An IMG transceiver combines an IMG receiver and sender in one. It may modify received IMG metadata, or merge IMG metadata received from several different IMG senders. It's giving multitasker 💅
IMG Operation: An atomic operation of an IMG transport protocol, used between IMG sender(s) and IMG receiver(s) for delivering IMG metadata and for controlling the IMG sender(s)/receiver(s). ⚙️
IMG Transport Protocol: A protocol that transports IMG metadata from an IMG sender to IMG receiver(s). 🦋
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 is a time-bound series of IMG transport protocol interactions that deliver IMG metadata from the IMG sender to the IMG receiver(s). It has a clear beginning and end, so it's giving time-limited drama ⏳
3. Problem Statement 🧩
Okay so, as we list out the requirements for IMGs, it's going to become super clear that existing protocols don't fully cover them 😭 The "Framework for the Usage of Internet Media Guides" [9] goes way deeper into these issues if you want the full tea.
The MMUSIC working group has been investigating content, media, and service information delivery mechanisms and protocols for ages. They've produced the Session Announcement Protocol (SAP), the Session Description Protocol (SDP), and the Session Initiation Protocol (SIP). SDP can describe multimedia sessions (content in a wider sense) using limited descriptive information meant for humans, plus transport and scheduling info, and the codecs and addresses needed to set up media sessions. SIP and SAP are the protocols that distribute those session descriptions. 🎶
Here's the catch though: we see no standard solution for a scalable IMG delivery mechanism that works across lots of receivers while keeping IMG metadata consistent between an IMG sender and IMG receiver, for both bi-directional and unidirectional transport. With services getting more dynamic and complex, the content descriptions need updating more and more. 📈
HTTP [10] is a well-known information retrieval protocol. It uses bi-directional transport and is widely used to deliver web-based content descriptions to many hosts. Still, it has well-recognized scalability limits in terms of the number of HTTP clients, because it relies on polling to keep information consistent between server and client. 🙃
SAP [3] is an announcement protocol that distributes session descriptions via multicast. It doesn't support prioritization or fine-grained metadata selection and update notifications. It places restrictions on metadata payload size and always sends the whole metadata. It also needs a wide-area multicast infrastructure to be deployable beyond a local area network. 🌐
SIP [8] and SIP-specific event notifications [11] can be used to notify subscribers about updates to IMG metadata for bi-directional transport. However, you'd need to define an event package for IMGs first 📦
We also see no standard solution for flexible content descriptions that support a whole bunch of application-specific metadata and associated data models, each with a different amount of detail and different target audiences. 🎭
SDP [2] has a text-encoded syntax for specifying multimedia sessions for announcements and invitations. It's mainly meant for describing client capability requirements and letting clients select applications. SDP is extensible, but it has limits, like structured extensibility and the ability to reference properties of one multimedia session from the description of another session. 🤏
These can mostly be fixed by the XML-based SDPng [7], which is meant for both two-way negotiation and unidirectional delivery, or by similar content description mechanisms. SDPng targets multiparty multimedia conferences, though, so the XML schema would need to be extended to describe general multimedia content. 🛠️
4. Use Cases Requiring IMGs 🌈
4.1. Connectivity-based Use Cases
4.1.1. IP Datacast to a Wireless Receiver 📡
IP Datacast is the delivery of IP-based services over broadcast radio, so Internet content delivery is unidirectional in this case. Still, being able to give rich media one-to-many services to these receivers can be a huge win ✨
There are two main classes of receiver in this use case: fixed mains-powered and mobile battery-powered. Both are affected by radio phenomena, so robust, or error-resilient, delivery really matters. Carouselled metadata transfer (cyclically repeated with a fixed bandwidth) gives a base level of robustness for an IP datacast-based announcement system. The carousel design should also let battery-powered receivers go to sleep for a while, which stretches their time between charges 🔋 Inserting Forward Error Correction (FEC) data into metadata announcements improves error resilience, and reordering (interleaving) data blocks makes things even more tolerant to burst errors. 🧃
To help receivers specify the metadata they actually want, unidirectional delivery may be spread across several logical channels. That way a receiver only needs to access the channels it cares about, which cuts down on the time, storage, and CPU needed to process the IP data. Hierarchical channels are also a thing: receivers can subscribe to a (possibly well-known) root multicast channel/group, then progressively access only the extra channels they need, based on metadata in parent channels. 🌳
Some receivers may have multiple access interfaces, which adds bi-directional communication. That opens up a multitude of options, and the big one is that it enables NACK-based reliability and the individual retrieval of missed or not-multicast sets of metadata 🙌
So the essential IMG features in this case are these: robust unidirectional delivery (with optional levels of reliability, including "plug-in FEC" supported by a transport layer protocol). That implies easily identifiable segmentation of delivery data, which makes FEC, carousel, interleaving, and other schemes possible. Next, effective identification of metadata sets (ideally unique) so multicast and unicast retrieval work efficiently across multiple access systems, no matter which parts of the metadata or application-specific extensions are in use. And finally, prioritization of metadata, which can be done by spreading it across channels and allocating or distributing bandwidth to match. 👑
Furthermore, some cases need IMG metadata authentication, plus group security/encryption and the supporting security message exchanges (carried out of band from the IMG multicast sessions). Security is not optional bestie 🔐
4.1.2. Regular Fixed Dial-up Internet Connection ☎️
Dial-up connections tend to be pretty slow (<56 kbps in any case), so large data transfers are less feasible, especially during an active application session like a file transfer described by IMG metadata. They can also be intermittent, especially when a user is paying for connected time or connecting through a less reliable exchange. 😩 That's why locally stored IMG metadata is favored over web-based browsing, especially where parts of the metadata change infrequently. 💾
There may be no service provider preference between unicast and multicast transport for small and medium numbers of users. That's because the last-mile dial-up connection limits per-user congestion anyway, and a user may prefer the more reliable option (unicast, unless reliable multicast is provided). 🤷♀️
4.1.3. Broadband Always-on Fixed Internet Connection 🏠
Typically, bandwidth isn't much of a problem for a broadband user, so unicast transport (such as query-response methods) may be the norm for a PC user 💻 If a system were only used in this context, with content providers, ISPs, and users having no other requirements, then web-based browsing could be equally suitable. However, broadband users sharing a local area network, especially a wireless one, may get more out of local storage features than online browsing, particularly if their Internet access is intermittent. 📶
Some broadband services, like live media broadcasting, benefit from multicast transport for streaming media because of scalability 📺 When multicast transport is already available, it's convenient for a sender and receiver to retrieve IMG metadata over multicast transport too. Broadband users may even be forced to retrieve IMG metadata over multicast if backbone operators require it to keep system-wide bandwidth usage feasible. 🥲
4.2. Content-orientated Use Cases 🎬
IMGs can support a very wide range of use cases for content and media delivery. The next few sections just scratch the surface, giving you a feel for the scope and type of IMG usage. Many more examples may be relevant, such as those detailed in [12]. IMGs also have several unique features that set them apart from related areas like Service Location Protocol (SLP) based service location discovery, Lightweight Directory Access Protocol (LDAP) based indexing services, and search engines such as Google. Features unique to IMGs include the following: 💖
- IMG metadata is generally time-related
- There are timeliness requirements in the delivery of IMG metadata
- IMG metadata may be updated as time elapses or when an event arises
4.2.1. TV and Radio Program Delivery 📺
Okay so a sender of audio/video streaming content can use IMG metadata to describe the scheduling and other properties of audio/video sessions, and the events inside them, like individual TV and radio programs and the segments within those programs 💖. The metadata could look a lot like the TV listings in a newspaper, or an Electronic Program Guide on digital TV receivers 🍓.
Programs can be picked manually by the end-user, or automatically based on content descriptions and the user's preferences ✨. The content can be shown in real time or recorded for later 🎀. Schedules can shift, and when one program moves, the programs after it might move too 😭. IMG metadata can tell receivers about those changes, so users get prompted or recording times get adjusted 🦋.
4.2.2. Media Coverage of a Live Event 🎸
Covering a live event like a rock concert or a sports game is basically a special case of regular TV/radio programming 🏟️. Schedules can change unexpectedly, or the event might not have a schedule to begin with (think breaking news) 🚨. Alongside the audio/video streams, you might also send text about the event, like player stats during a football match 📊. Different media can travel over different transport modes, or even different access technologies. For example, a unidirectional datacast transport could carry the audio/video streams while an interactive cellular connection carries the text 📡. IMG metadata should enable terminals to discover the availability of different media used to cover a live event 🔥.
4.2.3. Distance Learning 🎓
IMG metadata could describe compound sessions or services that offer several alternative ways for participants to interact 🧠. Combining one-to-many media streaming, unicast messaging, and downloading of presentation material could be really useful for distance learning 📚.
4.2.4. Multiplayer Gaming 🎮
Multiplayer games are an example of real-time multiparty communication sessions that could be advertised using IMGs 👾. A gaming session could be advertised by a dedicated server, or by the terminals of individual users 🕹️. A user could use IMGs to find active multiplayer gaming sessions, or to advertise their interest in joining one 🙌.
4.2.5. File Distribution 📁
IMGs support communicating file delivery session properties, which enables scheduled delivery or synchronization of files between a number of hosts 🗂️. Any application can then use the received IMG metadata, even outside the scope of IMGs, for example to download a software update 💿. IMG metadata can describe each file in a file delivery session, helping users or receiving software pick out individual files to receive 🎯.
For example, when a content provider wants to distribute a large amount of data in file format to thousands of clients, the provider can use IMG metadata to schedule the delivery effectively 💅.
Since IMG metadata can describe time-related data for each receiver, the content provider can schedule a delivery time for each receiver ⏰. This can save network bandwidth and the delivery capacity of senders 💜. On top of that, IMG metadata can be used for consistency checking, and so synchronize a set of files between a sender host and a receiver host when those files change as time elapses 🔁.
4.2.6. Coming-release and Pre-released Content 🎬
IMG metadata can describe content before the details of its final release are known 👀. A user might be into coming content, like a new movie or software title where some parts of the description are already known, and subscribe to an information service that tells them when that metadata changes 🔔. So when the coming release, or pre-releases like movie trailers or software demos, become available, the IMG metadata changes and the user gets notified 🍿. For example, a user could see an announcement for a movie coming out in the next few months, then set their terminal to receive and record any trailers or promo material as it drops 🎟️.
5. Requirements 📋
5.1. General Requirements ✅
5.1.1. Independence of IMG Operations from IMG Metadata 💅
Here's the vibe: the transport doesn't care what the metadata looks like, so you can carry lots of different metadata formats 🧩.
REQ GEN-1: Carrying different kinds of IMG metadata format and different IMG metadata formats in the IMG message body MUST be allowed.
REQ GEN-2: Delivery mechanisms SHOULD support many different applications' specific metadata formats to keep the system interoperable with existing applications.
This gives you flexibility to pick or design an IMG transport protocol that fits each scenario 🦋.
5.1.2. Multiple IMG Senders 📡
REQ GEN-3: IMG receivers MUST be allowed to communicate with any number of IMG senders simultaneously.
Yes, this can mean getting redundant IMG metadata describing the same items 🙃. But it also means the receiver can reach more IMG metadata than any single IMG sender could offer 💖. This also gives the IMG transport protocols flexibility, and it doesn't rule out a mechanism for sorting out inconsistency caused by multiple IMG senders ✨. This document assumes that a typical IMG environment has many more IMG receivers than IMG senders, and that IMG senders stay continually connected for the whole time they're of interest (rather than connecting now and then) 🌸.
5.1.3. Modularity 🧩
REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of several IMG operations.
This is for extending functionality, like using several protocols, or just one, to cover all the operations you need 🔥. Applications can choose the operation set that fits their purpose 🫶.
5.2. Delivery Properties 🚚
This section lays out general performance requirements, built on the idea that the range of IMG usage shall be important. Heads up though: requirements for delivery properties can vary by usage scenario, so some limited-use implementations care less about certain requirements 🤷♀️.
For example, a multicast transport can clearly deliver more scalably than a unicast transport. That doesn't mean scalability requirements rule out unicast, though. Scalability stays important for the protocols no matter which transport mechanism they use 🌈.
5.2.1. Scalability 📈
REQ DEL-1: The IMG system MUST be scalable to large numbers of messages, so as to allow design and use of delivery mechanisms that will not fail in delivering up-to-date information under huge numbers of transactions and massive quantities of IMG metadata.
REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from sending unnecessary IMG metadata that have been stored or deleted in IMG receivers.
REQ DEL-3: The protocol MUST be scalable to very large audience sizes requiring IMG delivery.
5.2.2. Support for Intermittent Connectivity 🔋
REQ DEL-4: The system MUST enable IMG receivers with intermittent access to network resources (connectivity) to receive and adequately maintain sufficient IMG metadata.
Intermittent access saves power, because you don't have to keep links powered up while they're just sitting there idle 😴. Periodic bursts of notifies or a fast-cycling update carousel let hosts wake up for short moments and still stay up to date ⚡. This is handy for IMG receivers with sporadic connections to the fixed Internet, but it's critical in the battery-powered wireless Internet 🔋💀.
Intermittent connectivity means immediate distribution of changes is out of the question, so managing data consistency should focus on timely delivery of data ⏳.
5.2.3. Congestion Control 🚦
REQ DEL-5: Internet-friendly congestion control MUST be provided for use on the public Internet.
REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when an IMG metadata item has lifetime information and its lifetime is over. This cuts down on the need for update notifications from the IMG sender to the IMG receiver just to invalidate the item, and it may help reduce load 🙌.
5.2.4. Sender- and Receiver-Driven Delivery 🔀
REQ DEL-7: The system MUST be flexible in choosing sender-driven, receiver-driven, or both delivery schemes.
Sender-driven delivery gets high scalability without any interaction between the IMG sender and receiver 🚀. Receiver-driven delivery, on the other hand, gives IMG receivers on-demand delivery 🙋♀️. Since an IMG sender's complete IMG metadata can be a seriously huge amount of data, the IMG receiver needs to access the guide when it's convenient, like when there's enough network bandwidth available to them 📶.
5.3. Customized IMGs 🎀
REQ CUS-1: The system MUST allow delivery of customized IMG metadata.
Receivers might only want a subset of all the IMG metadata, based on their preferences (type of content, media description, appropriate age group, and so on) and configuration 💜. The IMG receiver might send its preferences inside the IMG operations that specify user-specific IMG metadata to be delivered 🍓. Those preferences could be filtering rules. When the IMG sender gets these messages, it might reply with messages carrying just the subset of IMG metadata that matches the receiver's preferences 🎯.
This can cut down how much IMG metadata gets sent from the IMG sender to the IMG receiver, which saves resources on IMG entities and networks 🌿. It's usually useful in unicast cases, and also helpful in multicast cases where an IMG sender sends the same IMG metadata to interested IMG receivers at the same time 📣.
When the IMG sender doesn't provide customized IMG metadata, in both multicast and unicast cases, the IMG receiver could take in everything transmitted on the channels it has joined 📻. But it can then filter the IMG metadata by its own preferences to get the customized set, and drop unwanted metadata right after reception 🗑️.
Customizing metadata might be done by changing the IMG descriptions sent and IMG receivers and/or by changing the delivery properties (channels used) 🔧.
Heads up, bestie: customization and scalability are only somewhat exclusive 🫣. Systems where an IMG receiver asks an IMG sender for customization through request-based signaling will generally be less scalable to massive IMG receiver populations than systems without this return signaling technique. So customization, like any feature that affects scalability, should be carefully designed for the intended application, and a one-size-fits-all solution for customization may not be possible for meeting the scalability requirements of every application and deployment case 💀💅.
5.4. Reliability 🛡️
5.4.1. Managing Consistency 💖
okay so IMG metadata is literally always changing, bestie 🙈 new content drops, the old IMG metadata sitting in the IMG receiver stops being available, and the parameters of the existing IMG metadata get tweaked. it's a whole thing ngl.
REQ REL-1: The system MUST manage IMG metadata consistency.
There are two ways this can go. The IMG sender can just make updates available (unsynchronized), or the IMG sender and receiver can talk to each other to keep their copies of the IMG metadata synchronized. 🔥
In the unsynchronized model, the IMG sender does not know whether a particular IMG receiver has an up-to-date copy of the IMG metadata. (it's giving "hope it's fine" energy 💀)
In the synchronized model, updating a cached copy of the IMG metadata is necessary to control consistency when the IMG sender or receiver could not communicate for a while. In this case, the IMG sender or receiver may need to confirm its consistency by IMG operations.
REQ REL-2: Since IMG metadata can change at any time, IMG receivers SHOULD be notified of such changes.
Fulfilling this requirement needs to be compatible with the scalability requirements for the number of IMG receivers and the consistency of metadata.
Depending on the size of the IMG metadata, the interested party may want to defer retrieving the actual information. The change notification should be addressed to a logical user (or user group), rather than a host, since users may change devices. 📱 people switch devices constantly, so notify the person, not the box.
Note that depending on the deployment environment and application specifics, the level of acceptable inconsistency varies. Thus, this document does not define inconsistency as specific time and state differences between IMG metadata stored in an IMG sender and IMG metadata stored in an IMG receiver. 🫶 no fixed definition here, the vibe is "it depends."
In general, the consistency of metadata for content and media is more important immediately prior to and during the media's session(s). Hosts that forward (or otherwise resend) metadata may not tolerate inconsistencies because delivering out-of-date data is both misleading and bandwidth inefficient. 💅 stale data is misleading AND wastes bandwidth, so absolutely not.
5.4.2. Reliable Message Exchange 🦋
REQ REL-4: An IMG transport protocol MUST support reliable message exchange.
The extent to which this could result in 100% error-free delivery to 100% of IMG receivers is a statistical characteristic of the protocols used. How much reliable IMG delivery mechanisms get used is expected to depend on how reliable the underlying networks are and, flipping it around, how many errors they introduce. ✨ Note that some deployments of IMG transport protocols may not aim to provide perfect reception to all IMG receivers in all possible cases.
5.5. IMG Descriptions 🌈
REQ DES-1: IMG metadata MUST be interoperable over any IMG transport protocol, such that an application receiving the same metadata over any one (or more) of several network connections and/or IMG transport protocols will interpret the metadata in exactly the same way. (This also relates to the 'Independence of IMG Operations from IMG Metadata' requirements.)
REQ DES-2: IMG delivery MUST enable the carriage of any format of application-specific metadata.
So the system can describe loads of different kinds of multimedia content, without needing one single homogeneous metadata syntax for everything (which would be infeasible anyway 💀). This is essential for environments using IMG systems to support many kinds of multimedia content and to achieve wide applicability. 🎀
REQ DES-3: Whereas specific applications relying on IMGs will need to select one or more specific application-specific metadata formats (standard, syntax, etc.), the IMG system MUST be independent of this (it may be aware, but it will operate in the same way for all).
So we need a metadata transfer envelope format that's uniform across all the different application-specific IMG metadata formats. The envelope would reference (point to) or carry (as payload) some application-specific metadata, and it would support the maintenance of that metadata, which may also serve the metadata relationships determined by the data model(s) used. The envelope would not need to be aware of the data model(s) in use. 🧚
REQ DES-4: IMG metadata MUST be structured to enable fragmentation for efficient delivery.
This is meant to make sure an IMG sender with more than a trivial knowledge of metadata can deliver only part of its (and the global) complete IMG metadata knowledge. (For instance, a trivial quantity of knowledge could be a single SDP description.) In general, how this fragmentation gets resolved will depend a lot on the optimal delivery of a deployment, although some metadata syntaxes will inherently affect the sensible lower limit for a single element/fragment. 🍓
REQ DES-5: A metadata transfer envelope MUST be defined to include essential parameters.
Examples of essential parameters are the ones that allow the metadata in question to be uniquely identified and updated by new versions of the same metadata. 🔑
REQ DES-6: It SHALL be possible to deduce the metadata format via the metadata transfer envelope.
REQ DES-7: IMG senders SHALL use a metadata transfer envelope for each IMG metadata transfer.
So it'll even be possible to describe relationships between syntactically dissimilar application-specific formats within the same body of IMG metadata knowledge. (For instance, a data model could be instantiated using both SDP and SDPng.) the mix-and-match is iconic 👑
REQ DES-8: IMG metadata SHOULD support the description of differences between an updated version and an old version of IMG metadata when the IMG delivery mechanism carries updated IMG metadata and those differences are considerably little (e.g., by providing a 'delta' of the two versions; this also relates the delivery property requirements for congestion control in Section 5.2.3).
6. Security Considerations 🔐
okay bestie, this part is SERIOUS 😭 Internet Media Guides are used to convey information about multimedia resources from one or more IMG senders across one or more intermediaries to one or more IMG receivers. IMG metadata may be pushed to the IMG receivers or interactively retrieved by them. IMGs provide metadata as well as scheduling and rendezvous information about multimedia resources, and so on, and requests for IMG metadata may contain information about the requesting users.
The information contained in IMG metadata as well as the operations related to IMGs should be secured to avoid forged information, misdirected users, and spoofed IMG senders, for example, and to protect user privacy. 🚨
The remainder of this section addresses the security requirements for IMGs.
6.1. IMG Authentication and Integrity 🛡️
IMG metadata and its parts need to be protected against unauthorized alteration/addition/deletion on the way. Their originator needs to be authenticated.
REQ AUT-1: It MUST be possible to authenticate the originator of a set of IMG metadata.
REQ AUT-2: It MUST be possible to authenticate the originator of a subpart of IMG metadata (e.g., a delta or a subset of the information).
REQ AUT-3: It MUST be possible to validate the integrity of IMG metadata.
REQ AUT-4: It MUST be possible to validate the integrity of a subpart of IMG metadata (e.g., a delta or a subset of the information).
REQ AUT-5: It MUST be possible to separate or combine individually authenticated pieces of IMG metadata (e.g., in an IMG transceiver) without invalidating the authentication.
REQ AUT-6: It MUST be possible to validate the integrity of an individually authenticated piece of IMG metadata even after this piece has been separated from other pieces of IMG metadata and combined with other pieces to form new IMG metadata.
REQ AUT-7: It MUST be possible to authenticate the originator of an IMG operation.
REQ AUT-8: It MUST be possible to validate the integrity of any contents of an IMG operation (e.g., the subscription or inquiry information).
6.2. Privacy 🙈
Customized IMG metadata and IMG metadata delivered by notification to individual users may reveal information about the habits and preferences of a user and may thus deserve confidentiality protection, even though the information itself is public. 👀 a whole vibe-profile of someone, honestly.
REQ PRI-1: It MUST be possible to keep user requests to subscribe to or retrieve certain (parts of) IMG metadata confidential.
REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG metadata, or pointers to IMG metadata delivered to individual users or groups of users confidential.
REQ PRI-3: It SHOULD be possible to ensure this confidentiality end-to-end, that is, to prevent intermediaries (such as IMG transceivers) from accessing the contained information.
6.3. Access Control for IMGs 🔑
Some IMG metadata may be freely available, while access to other IMG metadata may be restricted to closed user groups (e.g., paying subscribers). Also, different parts of IMG metadata may be protected at different levels. For example, metadata describing a media session may be freely accessible, while rendezvous information to actually access the media session may require authorization. 🎟️
REQ ACC-1: It MUST be possible to authorize user access to IMG metadata.
REQ ACC-2: It MUST be possible to authorize access of users to pieces of IMG metadata (delta information, subparts, pointers).
REQ ACC-3: It MUST be possible to require different authorization for different parts of the same IMG metadata.
REQ ACC-4: It MUST be possible to access selected IMG metadata anonymously.
REQ ACC-5: It MUST be possible for an IMG receiver to choose not to receive (parts of) IMG metadata in order to avoid being identified by the IMG sender.
REQ ACC-6: It SHOULD be possible for an IMG transceiver to select suitable authorization methods that are compatible between both IMG senders and IMG receivers it interacts with.
REQ ACC-7: It MAY be possible for IMG senders to require certain authorization that cannot be modified by intermediaries.
6.4. Denial-of-Service (DOS) Attacks 🚫
Retrieving or distributing IMG metadata may require state in the IMG senders, transceivers, and/or receivers for the respective IMG transport sessions. Attackers may create large numbers of sessions with any of the above IMG entities to disrupt regular operation. 😤 the villain arc is real.
REQ DOS-1: IMG operations SHOULD be authenticated.
REQ DOS-2: It SHOULD be possible to avoid DoS attacks that build up session state in IMG entities to exhaust their resources.
REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust resources of IMG entities by flooding them with IMG metadata.
As an example, two potential solutions that may be considered are running an IMG entity in stateless mode or identification and discarding of malicious packets by an IMG entity. 🧹
6.5. Replay Attacks 🔁
okay so IMG metadata that an IMG sender or an IMG transceiver shares can get updated, get deleted, or just go stale over time for other reasons too. 🙈 Replaying old metadata needs to be stopped, bestie. no cap 💅
and it's not only the payload at risk. replay attacks can also target IMG operations themselves, so replaying operations needs to be stopped as well. 😭
REQ REP-1: IMG metadata MUST be protected against partial or full replacement of newer ("current") versions by older ones. 🔒✨
in a system with multiple senders, it might not be realistic to stop some senders from delivering older versions of metadata than others 🥺 because their data can be a little inconsistent with each other. so replay attacks and inconsistent data mean an IMG receiver has to check that the IMG metadata is valid and reliable, using some security mechanism (for example authorization, authentication, or integrity). 🫶
REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on the IMG operations. 🛡️💖
the level of threat from replay attacks varies a LOT depending on how big the system is and how well defined or open it is. 👑 so mitigating replay attacks can lead to different solutions for different systems, and that's separate from the basic delivery method and the metadata definitions. a system with multiple senders is the most challenging scenario for handling replay attacks, literally the boss level 🎮💀. as one example, bundling the metadata with a security mechanism is one potential solution. 🧚
7. Normative References 📚
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.8. Informative References 🌸
[2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[3] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[4] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/
[5] Session Directory Tool, http://www-
mice.cs.ucl.ac.uk/multimedia/software/sdr/
[6] Digital Video Broadcasting Project, http://www.dvb.org/
[7] Kutscher, D., Ott, J., and C. Bormann, "Session description and
capability negotiation", Work in Progress, February 2005.
[8] 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.
[9] Nomura, Y., Walsh, R., Luoma, J-P., Asaeda, H., and H.
Schulzrinne, "Framework for the Usage of Internet Media Guides
(IMG)", RFC 4435, April 2006.
[10] 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.
[11] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[12] Quinn, B. and K. Almeroth, "IP Multicast Applications:
Challenges and Solutions", RFC 3170, September 2001.9. Acknowledgements 🫶
the authors want to thank Hitoshi Asaeda, Gonzalo Camarillo, Jean-Pierre Evain, Dirk Kutscher, Petri Koskelainen, Colin Perkins, Toni Paila, and Magnus Westerlund for their excellent comments and ideas on this work. 💜✨
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
Joerg Ott
Helsinki University of Technology
Networking Laboratory
PO Box 3000
FIN-02015 TKK
Finland
EMail: jo@netlab.tkk.fi
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.eduFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2006).
this document is subject to the rights, licenses and restrictions contained in BCP 78, 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 on 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 on whether any license under those rights might or might not be available. it also doesn't say it has made any independent effort to identify any such rights. 🤷♀️ info on how rights work for RFC documents is in BCP 78 and BCP 79.
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr. 📂
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 required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org. 💖
Acknowledgement 🌈
funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🎀⭐
📦 where this page comes from
- ietf: rfc4473 2006-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms