RFC 4435
A Framework for the Usage of Internet Media Guides (IMGs)
RFC 4435: A Framework for the Usage of Internet Media Guides (IMGs) 🎀
okay bestie, this one is a framework doc, which means it's about how a bunch of existing protocols could team up to deliver Internet Media Guides (IMGs) 📺✨ it's marked Informational (so it's giving "here's some useful info," not "you must do this") and it's dated April 2006 🌸
the authors are Y. Nomura (Fujitsu Labs.), R. Walsh, J-P. Luoma (Nokia), H. Asaeda (Keio University), and H. Schulzrinne (Columbia University) 🫶 the Network Working Group published it, and the Copyright (C) The Internet Society (2006) owns the copyright 💜
Status of This Memo ✨
so this memo gives info to the Internet community, it does not set an Internet standard of any kind 🙅♀️ and distribution is unlimited, so share away 💅
Copyright Notice 💜
Copyright (C) The Internet Society (2006). that's the legal bit, bestie 💖
Abstract 🦋
okay so this document lays out a framework for delivering IMGs 📡 an IMG is a structured collection of multimedia session descriptions written in the Session Description Protocol (SDP), SDPng, or some similar session description format 🎬 the doc walks through a generalized model for how IMG delivery could work, which existing protocols can already help, and what extra work still needs doing to build a proper IMG delivery infrastructure 🛠️🔥
Table of Contents 📚
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. New Terms ..................................................4
3. IMG Common Framework Model ......................................5
3.1. IMG Data Types .............................................5
3.1.1. Complete IMG Description ............................5
3.1.2. Delta IMG Description ...............................6
3.1.3. IMG Pointer .........................................6
3.2. IMG Entities ...............................................6
3.3. Operation Set for IMG Delivery .............................7
3.3.1. IMG ANNOUNCE ........................................7
3.3.2. IMG QUERY ...........................................8
3.3.3. IMG RESOLVE .........................................8
3.3.4. IMG SUBSCRIBE .......................................8
3.3.5. IMG NOTIFY ..........................................9
3.3.6. Binding between IMG Operations and Data Types .......9
3.4. Overview of Protocol Operations ...........................10
4. Deployment Scenarios for IMG Entities ..........................10
4.1. Intermediary Cases ........................................10
4.2. One-to-Many Unidirectional Multicast ......................12
4.3. One-to-One Bidirectional Unicast ..........................12
4.4. Combined Operations with Common Metadata ..................13
5. Applicability of Existing Protocols to the Proposed
Framework Model ................................................14
5.1. Existing Standard Fitting the IMG Framework Model .........14
5.2. IMG Mechanism Needs Which Are Not Met by Existing
Standards .................................................15
5.2.1. A Multicast Transport Protocol .....................16
5.2.2. Usage of Unicast Transport Protocols ...............16
5.2.3. IMG Envelope .......................................17
5.2.4. Metadata Data Model ................................18
6. Security Considerations ........................................18
7. Normative References ...........................................19
8. Informative References .........................................19
9. Acknowledgements ...............................................201. Introduction 🌈
okay so IMGs give you and deliver structured collections of multimedia descriptions written in SDP [2], SDPng [3], or other description formats 🎀 they're used to describe sets of multimedia services (think TV program schedules or content delivery schedules) and they can point to other networked resources too, including web pages 🌐 an IMG is basically an envelope for metadata formats and session descriptions that are defined somewhere else, and its whole vibe is making that info easier to structure, version, reference, distribute, and maintain (that means caching and updating) 💅
IMG metadata could reach a seriously huge audience 😭 that audience uses it to join some of the sessions described, and they might need to hear about changes to the IMG metadata too. so we need a framework that can distribute IMG metadata in different ways to meet different audiences' needs. for traditional broadcast-style stuff, multicast-based (push) distribution of IMG metadata needs to be supported 📡 and where no multicast is available, unicast-based push is required 🫶
this document defines a common framework model for IMG delivery mechanisms and how they get deployed in network entities 🧚 there are three fundamental components in the IMG framework model: data types, operation sets, and entities 💖 together they set a bunch of framework guidelines for efficient delivery and description of IMG metadata ✨ the data types give a generalized way to deliver and keep application-specific IMG metadata consistent, and the IMG operations cover broadcast, multicast distribution, event notification upon change, unicast-based push, and interactive retrievals that work similarly to web pages 🔥
since any Internet host can be a sender and receiver of IMG metadata, a host that's 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 [4] 📝
this document outlines how existing protocols can be used to build an IMG delivery infrastructure 🛠️ it aims to organize those existing protocols into a common model and show their capabilities and limitations from the viewpoint of IMG delivery functions 🦋
2. Terminology 💜
okay so 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] 🤓 that's the rulebook for how those words hit, bestie 📖
2.1. New Terms 🌸
these are the vocab words you'll see all over the doc, so let's get them down 📝
- 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 [4]. (it's supposed to be vague, iykyk 🙈)
- IMG Element: the smallest atomic element of metadata that can be transmitted separately by IMG operations and referenced individually from other IMG elements [4] 🧩
- IMG Metadata: a set of metadata made up of one or more IMG elements. IMG metadata describes the features of multimedia content that are 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 [4] 🎬
- 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 [4] 🚚
- IMG Sender: an IMG sender is a logical entity that sends IMG metadata to one or more IMG receivers [4] 📤
- IMG Receiver: an IMG receiver is a logical entity that receives IMG metadata from an IMG sender [4] 📥
- IMG Transceiver: an IMG transceiver combines an IMG receiver and sender. it may modify received IMG metadata or merge IMG metadata received from several different IMG senders [4] 🔄
- 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) [4] ⭐
- IMG Transport Protocol: a protocol that transports IMG metadata from an IMG sender to IMG receiver(s) [4] 🚀
- 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) [4] ⏳
- IMG Transfer: a transfer of IMG metadata from an IMG sender to IMG receiver(s) 💫
3. IMG Common Framework Model 🧚
okay so every IMG candidate case has two common things: it needs to describe the services, and it needs to deliver those descriptions 💅 sometimes the descriptions give multicast addresses, which makes them part of the transport configuration 📡 other times the descriptions are specific to the media application and might be meant for humans or machines to read 🤖 so the technologies get roughly sorted into three areas:
- Application-specific Metadata: data describing the content of services and media that is both specific to certain applications and generally human readable 📖
- Delivery Descriptions: the descriptions (metadata) that are essential to enable delivery (e.g., multicast). these include framing (headers) for application-specific metadata, the metadata element identification and structure, and fundamental session data 🧱
- Delivery Protocols: the methods and protocols for exchanging descriptions between senders and receivers. an IMG transport protocol does two jobs: carrying IMG metadata from an IMG sender to an IMG receiver, and controlling an IMG transport protocol. these functions aren't always separate, so some messages may combine control messages and metadata carriage to cut down on the amount of messaging 🔥
3.1. IMG Data Types 🎀
you need a data model to pin down the terminology and the relationships between sets, supersets, and subsets of metadata 🗺️ a precise data model is essential for implementing IMGs, but it's not within the scope of this framework and it needs its own separate spec 📑 for now, there are three IMG data types in general: Complete IMG Descriptions, Delta IMG Descriptions, and IMG Pointers 💖
3.1.1. Complete IMG Description 💜
a Complete IMG Description gives a self-contained set of metadata for one media object or service. in other words, it doesn't need extra info from any other IMG element 🦋 don't mix this up with "complete IMG metadata," which (even though it's vaguely defined here) is the whole IMG metadata database of an IMG sender, or of a related group of IMG senders (potentially the complete Internet IMG knowledge) 🌍 an IMG sender will usually only deliver subsets of metadata from its complete database in any particular IMG transport session 🧃
3.1.2. Delta IMG Description
okay so a Delta IMG Description only gives you part of a Complete IMG Description 🎀 It tells you what's different from an earlier version of the Complete one. 💅 This is super useful when you want to save network resources, like when data consistency is a big deal and the IMG elements keep changing in small, frequent ways ✨ Soooo this description isn't a full set of metadata on its own 😭 It only becomes complete once it's combined with other metadata that's already there or shows up later 🦋
3.1.3. IMG Pointer
an IMG Pointer is giving "where do I find this?" energy 🧚 It identifies or locates metadata. 🌸 You can use it to go grab Complete or Delta IMG Descriptions separately, or to do other IMG management stuff, like data expiry (and erasure) 🍓 It can reference IMG metadata elements inside the same IMG transport session and across different ones too 💜 And ngl, this pointer type doesn't include IMG metadata itself 🙈 (it can show up as a data field inside Complete or Delta IMG Descriptions, though) 🫶
3.2. IMG Entities
there are a few fundamental IMG entities, and each one is basically a capability for playing a certain role 👑 An Internet host doing IMG stuff can take on one or more of these roles, which get the full breakdown in Section 3.3 🌈
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
Figure 1 shows how these IMG entities relate to 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
3.3. Operation Set for IMG Delivery
a finite set of operations both meets the IMG requirements [4] and fits the roles of existing protocols 🎀 We're gonna crystallize these in the next few sections, so get ready 💖
3.3.1. IMG ANNOUNCE
when an IMG receiver is in unidirectional communications (think satellite, terrestrial radio, and wired multicast networks), it may not need to send any IMG message to an IMG sender before IMG metadata gets delivered 🌸 In that case, an IMG sender can start unsolicited distribution of IMG metadata, and it's the only entity that can keep that distribution going (this includes situations with multiple, cooperating IMG senders) 🧚 This is super useful when there are huge numbers of IMG receivers, or when the receivers don't have a guaranteed uplink to the IMG sender 😭 The IMG sender can also include authentication data in the ANNOUNCE operation, so IMG receivers can check whether the metadata is authentic 🔥 This operation can carry any of the IMG data types 💅
There's no restriction stopping IMG ANNOUNCE from being used in an asynchronous solicited way, where a separate operation (maybe out of band) lets IMG receivers subscribe or register to the IMG ANNOUNCE operation 🫶
3.3.2. IMG QUERY
if an IMG receiver needs to get IMG metadata, it can use an IMG QUERY operation and kick off a receiver-driven IMG transport session 👑 The IMG receiver expects a synchronous response to the follow-up request from the IMG sender 💖 This operation can be used when a bidirectional transport network is available between the IMG sender and receiver 🌈 Some IMG receivers may want to grab 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 the metadata it wants in some message in the operation 🎀 The extent is the number and grouping of metadata descriptions 🍓 And in some cases it may be doable to request an IMG sender's complete metadata collection 💜
3.3.3. IMG RESOLVE
an IMG sender synchronously responds and sends IMG metadata to an IMG QUERY that an IMG receiver has sent 🦋 This operation can be used when 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's available to the IMG sender, the IMG sender can resolve the query 🧚 Otherwise, it should indicate that it's not able to resolve the query 😭 The IMG sender may authenticate the IMG receiver during the QUERY operation to figure out whether that receiver is authorized to get the metadata 🙈 The sender can also include authentication data in the RESOLVE operation so IMG receivers can check the metadata's authenticity 🔥 This operation may carry any of the IMG data types 💅
3.3.4. IMG SUBSCRIBE
if an IMG receiver wants a heads-up when the IMG metadata it holds goes stale, it can use the IMG SUBSCRIBE operation ahead of time to request IMG NOTIFY messages from an IMG sender 💖
This operation may give the IMG sender specific details about which metadata or notification services the receiver is interested in, in case the IMG sender offers more than the simplest "all data" service 🌈 It also implicitly does the job of unsubscribing, letting an IMG sender know that an IMG receiver wants to stop getting certain (or all) notifications ✨ It's worth noting that unsubscription can also happen implicitly when a subscription expires (times out) before it gets renewed 🎀
Since the IMG receiver doesn't know when metadata will be updated and when the notify message will arrive, this operation doesn't 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 comes from an authorized IMG receiver 🦋
3.3.5. IMG NOTIFY
an IMG NOTIFY is used asynchronously in response to an earlier IMG SUBSCRIBE 🌸 It tells you that updated IMG metadata is available, or that part of the existing IMG metadata has gone stale 🧚 An IMG NOTIFY may be delivered more than once while an IMG SUBSCRIBE is active 😭 This operation may carry any of the IMG data types 🙈 The IMG sender can also include authentication data in the IMG NOTIFY operation so IMG receivers can check the authenticity of the messages 🔥
3.3.6. Binding between IMG Operations and Data Types
there's a need for a binding between the various IMG operations and IMG data types, so you can manage 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, and it MUST 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 💖 Uniqueness may only be needed within the domains where the metadata is used, but this has to enable globally unique identification to support Internet usage 🌈 Be careful that scope- and domain-specific identifiers don't leak outside their scope 👀 Using globally unique identifiers such as URLs avoids these problems ✨
The binding MUST provide versioning for the transferred IMG metadata so changes can be handled easily and stale data can be identified, and it MUST give temporal validity to the transferred IMG metadata 🎀 It MUST invalidate the IMG metadata by indicating an expiry time, and it MAY optionally provide a time (presumably in the future) from which 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, meaning no useful syntax should be excluded 🦋
3.4. Overview of Protocol Operations
Figure 2 gives an overview of how transport cases, IMG operations, and IMG data types relate to each other 🌸 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
4. Deployment Scenarios for IMG Entities ✨
this section covers some basic deployment scenarios for IMG entities, showing the common threads from protocols to use cases 🎀 For 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
4.1. Intermediary Cases ✨
Okay so some IMG metadata gets sent to a LOT of IMG receivers at once, like when public metadata goes out to everyone in a certain group 🫶 That metadata can go straight from one IMG sender to multiple IMG receivers (Figure 4), or it can get relayed through a set of IMG transceivers. Those transceivers receive it, maybe filter or change the content, and then forward it on 💅
+----------+ +----------+
| IMG | | IMG |
| Sender |---- ---->| Receiver |
+----------+ \ / +----------+
\ /
. \ +-----------+ / .
. -->|IMG |----- .
. -->|Transceiver| \ .
/ +-----------+ \
+----------+ / \ +----------+
| IMG | / ---->| IMG |
| Sender |---- | Receiver |
+----------+ +----------+
Figure 4: A Relay Network with an IMG TransceiverIMG senders and receivers are logical functions, so it's totally possible for some or all hosts in a system to do both jobs 🔥 That happens in many-to-many communications, or when 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, which is giving main character energy 👑
IMG metadata is used to find, obtain, manage, and play media content 🎀 It can also get modified during IMG transfer. For example, a server might use IMGs to retrieve media content over unicast and then make it available at scheduled times over multicast, so the metadata has to change to match ✨ IMG transceivers can add or delete information, or aggregate IMG metadata from different IMG senders. A rating service, for instance, might add its own content ratings or recommendations to existing metadata 🌸
Here's the tea 🍵 when you change (or aggregate) IMG metadata from one or more IMG senders, the original authenticity is lost. So it may be beneficial to sign fragments, which lets the intermediary 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 🧚
4.2. One-to-Many Unidirectional Multicast 📡
The one-to-many unidirectional multicast case involves many IMG receivers and one or more IMG senders that implement 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 ExampleNote, as defined in the IMG requirement REL-4 [4], an IMG transport protocol MUST support reliable message exchange 🚨 This includes the one-to-many unidirectional multicast case. The mechanism to provide this is beyond the scope of this document, so we're leaving that one for another day 🙈
4.3. One-to-One Bidirectional Unicast 🦋
In the one-to-one bidirectional unicast case, both query/resolve (Figure 6) and subscribe/notify (Figure 7) message exchange operations are feasible. Two-way vibes 💖
+----------+ +----------+
| IMG | | IMG |
| Resolver | | Querier |
+----------+ +----------+
| |
|<----------IMG QUERY -----------|
| |
|----------IMG RESOLVE---------->|
| |
Figure 6: Query/Resolve Sequence Example
+----------+ +------------+
| IMG | | IMG |
| Notifier | | Subscriber |
+----------+ +------------+
| |
|<---------IMG SUBSCRIBE---------|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
| |
Figure 7: Subscribe/Notify Sequence Example4.4. Combined Operations with Common Metadata 🌈
As shown in Figure 8, a common data model for multiple protocol operations lets a super diverse range of IMG senders and receivers provide consistent and interoperable sets of IMG metadata. It's basically everyone being on the same page, and honestly iconic 👑
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 Metadata5. Applicability of Existing Protocols to the Proposed Framework Model 🧠
5.1. Existing Standards Fitting the IMG Framework Model 💅
SDP: The SDP format [2] 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. Yes, SDP has extension points that let the format be extended, but there are limitations in how flexible that extension mechanism is. Also, SDP syntax cannot provide IMG Descriptions and IMG Pointers without significant overhead 😩 The information conveyed by SDP is expected to be just a small subset of IMG metadata, so using SDP for anything other than session parameters may not be reasonable.
SDPng [3]: 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 it allows extensions and integration with other description formats. Big upgrade energy ✨
MPEG-7: Descriptions based on the MPEG-7 standard [5] could provide application-specific metadata describing the properties of multimedia content, going beyond the parameters carried in SDP or SDPng descriptions. MPEG-7 provides a machine-readable format for representing content categories and attributes, which helps end-users or receiving software choose content for reception 🎬 Since MPEG-7 is based on XML, it is well suited to be combined with other XML-based formats such as SDPng 🫶
TV-Anytime: The TV-Anytime Forum [6] 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 it also has 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 [7] 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. 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 [4] in a unicast deployment 😭
Session Announcement Protocol (SAP): The announcement mechanism provided by SAP [8] 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 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. Yikes 💀
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. Because of these limitations, the use of SAP as an IMG transport protocol is not recommended 🙅♀️
SIP: The SIP-specific event mechanism described in RFC 3265 [9] 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 RFC 3265 currently does not consider multicast 🥲
Real Time Streaming Protocol (RTSP): The RTSP protocol [10] 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, so they 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 🎀
5.2. IMG Mechanism Needs Which Are Not Met by Existing Standards
okay so bestie, this is where we look at what's still missing 🧐💖 Based on the IMG requirements, the framework model, and the existing mechanisms we already covered in this doc, there are four big groups of work that are super obvious. They are: (a) a multicast- and unidirectional-capable announcement protocol 📣; (b) using existing unicast protocols so unicast subscribe and announce/notify actually works 📞; (c) a metadata envelope that's shared by all the application metadata syntaxes and doesn't depend on any one of them 📦; and (d) agreeing on basic metadata models so interop testing can happen 🧪. Each one gets its own little section below ✨
5.2.1. A Multicast Transport Protocol
SAP is currently the only open standard protocol that's suited to unidirectional/multicast delivery of IMG metadata 📡. As we discussed, it falls short of the IMG requirements in a bunch of ways, and since it wasn't designed to be extensible, we realize a new multicast transport protocol for announcements needs to be specified to meet IMG needs 😤 This protocol is going to be essential to IMG delivery for unidirectional and multicast deployments 💅
The Asynchronous Layered Coding (ALC) [11] protocol from the IETF Reliable Multicast Transport (RMT) working group is very interesting 🦋 It fulfills a lot of the requirements, it's extensible, and it can "plug-in" both FEC (Forward Error Correction, for reliability) and CC (Congestion Control) functional blocks 🧩 It's specifically designed for unidirectional multicast object transport. ALC isn't fully specified on its own, though. The RMT working group did have a fully specified protocol built on ALC called FLUTE (File Delivery over Unidirectional Transport) [12] 🌈 FLUTE seems to be the only fully specified transport and open specification a new IMG announcement protocol could be designed on, so we recommend that ALC and FLUTE be the starting points for this protocol's design 💖
Developing a new protocol from scratch, or trying to improve SAP, is also feasible 🛠️ BUT it would mean repeating a lot of the design processes and decisions the IETF already made 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 🔥
5.2.2. Usage of Unicast Transport Protocols
A thorough description of how to use existing unicast protocols is essential if IMGs are going to work in a unicast point-to-point environment 📞✨ Nobody has published that spec yet 😭 But several usable unicast transport protocols and specs can be harnessed for this, like SIP [13], SIP events [9], HTTP [7], and so on 🧚 In particular, both the 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 🌸
5.2.3. IMG Envelope
An IMG envelope is what provides the binding between IMG operations and data types 🎀 This binding can be realized by defining a common, minimal set of information needed to manage IMG metadata transfers, and then including that information with any set of IMG metadata delivered to IMG receivers 📬
Four options for delivering the IMG metadata transfer envelope are feasible 👑
- Embedding in a transport protocol header. This can be done with either header extensions of existing protocols, or with 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 😬
- A separate envelope object, which points to the IMG metadata 'object', delivered in-band with the metadata transport protocol session. This might complicate delivery, since 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 [14]) 🧵 This would also enable schemes that deliver envelope and metadata 'objects' by different media, also using more than a single transport protocol 🌈
- 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 🍓
- Embedding in the metadata itself. However, this requires a new field in many metadata syntaxes, and it would not be feasible if a useful syntax weren't 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's 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's assumed that the IMG Descriptions of the subset inherit the parameters of the superset 💜 So an IMG metadata transfer envelope carrying the IMG Descriptions of a superset may implicitly define 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 🫶
5.2.4. Metadata Data Model
A structured data model would allow reuse and extension of the set of metadata, and it may enable use of multiple syntaxes (SDP, MPEG-7, etc.) as part of the same body of IMG metadata 🧁
For IMGs to be successfully deployed 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 to the use of the IMG transfer envelope concept described above.
This document is a framework for the delivery of IMG metadata, so further discussion on defining data models for IMGs is beyond its scope 🙈 That's a whole other vibe, bestie 💅
6. Security Considerations
The IMG framework is developed from the IMG requirements document [4], so the selection of specific protocols and mechanisms 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 the specific protocols used 😳
Protocol instantiations that are used to provide IMG operations will have very different security considerations depending on their scope and purpose 🚨 There are still 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 of its modification history 🕵️♀️ This can prevent denial-of-service or hijacking attempts that give an IMG receiver incorrect information in or about the metadata, which would otherwise prevent successful access of the media or direct 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 result in unavoidable snooping opportunities for unauthorized nodes 🛡️
Unidirectional specifics: A difficulty 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 the 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 🚫💻
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] Kutscher, D., Ott, J., and C. Bormann, "Session description and capability negotiation", Work in Progress, October 2003.
[4] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H. Schulzrinne, "Requirements for Internet Media Guides", Work in Progress, December 2005.
[5] "Multimedia content description interface -- Part 1: Systems", ISO/IEC 15938-1, July 2002.
[6] 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.
[7] 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.
[8] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[10] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[11] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[12] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004.
[13] 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.
[14] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
9. Acknowledgements
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 🥰🎀
Authors' Addresses 🎀
okay bestie, here are the humans who wrote this, and they're literally from all over the world 🌏 five authors, across Japan, Finland, and the USA. so iconic 💜
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.eduFull Copyright Statement 💅
the legal bit, but make it cute 🧚 the copyright belongs to The Internet Society (2006). this doc is covered by the rights, licenses and restrictions in BCP 78, and apart from what's in there, the authors keep all their rights 🔒
the vibe is "as is," and the people who contributed, the orgs they represent, the Internet Society and the IETF all say no warranties, express or implied, no matter how much you ask nicely. that includes no promise that using the info won't infringe anyone's rights, and no implied warranties of merchantability or fitness for a particular purpose. the full disclaimer, verbatim:
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 🔥
okay so this part is about patents and other IP stuff. the IETF doesn't pick a side on whether any IP rights apply to the tech in this doc, or whether you can get a license to use it. it also hasn't done its own digging to find any rights 🤷♀️ if you want the rules for RFC docs, check out BCP 78 and BCP 79.
if someone has filed IPR disclosures with the IETF Secretariat, or promised to license their stuff, you can find those in the IETF online IPR repository at http://www.ietf.org/ipr. same goes if someone tried to get a general license or permission for implementers or users. 🫶
and the IETF is basically like "hey, if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard, please tell us." send that to ietf-ipr@ietf.org 📬 bestie, be a good citizen 💖
Acknowledgement 🫶
last but not least, the RFC Editor function is funded by the IETF Administrative Support Activity (IASA) 🌸 thank you to everyone keeping the lights on, you're literally the best 👑✨
📦 where this page comes from
- ietf: rfc4435 2006-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms