Skip to main content

Requirements for Internet Media Guides (IMGs)
RFC 4473

Revision differences

Document history

Date Rev. By Action
2017-05-16
08 (System) Changed document authors from "Henning Schulzrinne, Rod Walsh, Yuji Nomura, Joerg Ott" to "Henning Schulzrinne, Rod Walsh, Yuji Nomura, Joerg Ott, Juha-Pekka Luoma"
2015-10-14
08 (System) Notify list changed from jo@acm.org, csp@csperkins.org to csp@csperkins.org
2006-06-06
08 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2006-06-06
08 Amy Vezza [Note]: 'RFC 4473' added by Amy Vezza
2006-05-31
08 (System) RFC published
2006-02-21
08 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-01-12
08 Amy Vezza IESG state changed to Approved-announcement sent
2006-01-12
08 Amy Vezza IESG has approved the document
2006-01-12
08 Amy Vezza Closed "Approve" ballot
2006-01-09
08 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2005-12-20
08 (System) New version available: draft-ietf-mmusic-img-req-08.txt
2005-01-21
08 (System) Removed from agenda for telechat - 2005-01-20
2005-01-20
08 Amy Vezza State Changes to IESG Evaluation::AD Followup from Waiting for Writeup by Amy Vezza
2005-01-20
08 Michelle Cotton IANA Comments: We understand this document to have NO IANA Actions.
2005-01-20
08 Harald Alvestrand
Gen-ART review from: Spencer Dawkins
Date: 18 januari 2005

I reviewed this specification for Harald as a General Area Review Team
assignment.

This specification is …
Gen-ART review from: Spencer Dawkins
Date: 18 januari 2005

I reviewed this specification for Harald as a General Area Review Team
assignment.

This specification is roughly on the right track for Informational
RFC, but seems to carve out a very ambitious scope (scaling to large
numbers of receivers while providing notifications when an IMG has
changed and requiring support for reliable transfers of IMGs) - I
believe it would be a better document if some environments were NOT
supported...

Spencer

1 Introduction

1.1 Background and Motivation

  channel addresses). This peers well with the DVB Organization's

This acronym should be expanded, and there should be a reference, too.

  Furthermore, any Internet host can be a sender of content and thus an
  IMG sender. Some of the content sources and sinks may only be
  connected to the Internet sporadically. Also, a single human user may
  use many different devices to access metadata. Thus, we envision that
  IMG metadata can be sent and received by, among others, by cellular
  phones, PDA (Personal Digital Assistant), personal computer,
  streaming video server, set-top box, video camera, and DVR (Digital
  Video Recorder) and that they be carried across arbitrary types of
  link layers, including bandwidth-constrained mobile networks.
  However, generally we expect IMG Senders to be well-connected hosts.

The above paragraph seems self-contradictory (can IMG senders be
intermittently connected?)

3 Problem Statement

  These are mostly overcome by the XML-based SDPng, which is intended

this sentence should include a reference to [6], right?

4 Use Cases Requiring IMGs

4.1 Connectivity-based Use Cases

4.1.1 IP Datacast to a Wireless Receiver

  There are two main classes of receiver in this use case: fixed
  mains-powered; and mobile battery-powered. Both of these are affected

"mains-powered" may be technically correct, but seems awkward here.

  by radio phenomena and so robust, or error-resilient, delivery is
  important. Carouselled metadata transfer provides a base level of

I don't understand what "carouselled" means in this paragraph (it's
used more than once).

  robustness for an IP datacast based announcement system, although the
  design of carouselled transfer should enable battery-powered
  receivers to go through periods of sleep to extend their operational
  time between charges. Insertion of Forward Error Correction (FEC)
  data into metadata announcements improves error resilience, and
  reordering (interleaving) data blocks further increases tolerance to
  burst errors.

  In some cases the receiver may be multi-access, such that it is
  capable of bi-directional communications. This enables a multitude of

I don't think "multi-access" usually has this meaning.

  Thus, essential IMG features in this case include: robust
  unidirectional delivery (with optional levels of reliability
  including "plug-in FEC") which implies easily identifiable

I'm confused because of references to "FEC" in what seems obviously an
application-layer protocol.

  segmentation of delivery data to enable FEC, carousel, interleaving
  and other schemes possible; effective identification of metadata sets
  (probably uniquely) to enable more efficient use of multicast and
  unicast retrieval over multiple access systems regardless of the
  parts of metadata and application specific extensions in use;
  prioritization of metadata, which can (for instance) be achieved by
  spreading it between channels and allocating/distributing bandwidth
  accordingly.


4.1.3 Broadband Always-on Fixed Internet Connection

  Broadband enables rich media services, which are increasingly
  bandwidth hungry. Thus backbone operators may prefer multicast
  communications to reduce overall congestion, if they have the
  equipment and configuration to support this.

This seems conjectural!

5.3 Customized IMGs

  REQ CUS-1: The system MUST allow delivery of customized IMG metadata.

  The IMG receiver may require a subset of all the IMG metadata
  available according to their preferences (type of content, media
  description, appropriate age group, etc.) and configuration.

  The IMG receiver might send its preferences in the IMG operations
  which can specify user specific IMG metadata to be delivered. These
  preferences could consist of filtering rules. When receiving these
  messages, the IMG sender might respond appropriate messages carrying

"respond with appropriate"?

  a subset of IMG metadata which matches the IMG receiver's
  preferences.

5.4.1 Managing Consistency


  REQ REL-2: Since IMG metadata can change at any time, IMG receivers
  SHOULD be notified of such changes.

This seems inconsistent given discussion about scalability to large
numbers of receivers.

5.4.2 Reliable Message Exchange

  REQ REL-4: An IMG transport protocol MUST support reliable message
  exchange.

But the next paragraph seems to relax this MUST?

  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. Usage of reliable IMG delivery mechanisms is expected
  to depend on the extent to which underlying networks provide
  reliability and, conversely, introduce errors. Note, some deployments
  of IMG transport protocols may not aim to provide perfect reception
  to all IMG receivers in all possible cases.

6.3 Access Control for IMGs
  REQ ACC-6: It SHOULD be possible for IMG transceiver to impose
  different authorization requirements.

??? "different" in what sense?

  REQ ACC-7: It MAY be possible for IMG senders to require certain
  authorization that cannot be overridden by intermediaries.

??? I'm not sure what "overridden" means - provided? forged?

6.4 Denial-of-Service attacks

  REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up
  session state in IMG entities to exhaust their resources.

This should probably be "avoid DoS attacks", as in the next
requirement, not "prevent".

6.5 Replay Attacks

  REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on
  the IMG operations.

  The level of threat from replay attacks varies very much depending on
  system scale and how well defined or open it is. Thus mitigating
  relay attacks may lead to different solutions for different systems,

The previous sentence should be "mitigating rePlay attacks", shouldn't it?
2005-01-20
08 Harald Alvestrand
[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

He has a number of comments (copied to document log), but none that I see as warranting blocking …
[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

He has a number of comments (copied to document log), but none that I see as warranting blocking the document for that reason alone.
2005-01-20
08 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2005-01-20
08 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-01-19
08 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-01-19
08 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-01-18
08 Ted Hardie
[Ballot comment]
I'm concerned that the potential roles of intermediaries are under-specified here.
In the introduction, the document says:

  Finally, with many potential senders …
[Ballot comment]
I'm concerned that the potential roles of intermediaries are under-specified here.
In the introduction, the document says:

  Finally, with many potential senders and receivers, different types
  of networks, and presumably numerous service providers, IMG metadata
  may need to be combined, split, filtered, augmented, modified, etc.,
  on their way from the sender(s) to the receiver(s) to provide the
  ultimate user with a suitable selection of multimedia services
  according to her preferences, subscriptions, location, context (e.g.
  devices, access networks), etc.

The Security Considerations section does have some mention of
the role of intermediaries, e.g.

  REQ AUT-5: It MUST be possible to separate or combine individually
  authenticated pieces of IMG metadata (e.g. in an IMG transceiver)

but the general mechanisms by which the receiver, sender, and intermediaries
interact does not seem to have generated sufficient requirements to ensure
that later protocol work will succeed.

I've had a short side discussion with Jon on this, and I agree that this could
be specified in a separate document, if that's the way the WG wants to tackle
things.
2005-01-18
08 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie
2005-01-18
08 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-01-18
(System) Posted related IPR disclosure: Ted Hardie's statement about possible IPR claimed in draft-ietf-mmusic-img-req-07.txt belonging to Pendakur, Ramesh ;  et al.
2005-01-17
08 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-01-13
08 Jon Peterson Placed on agenda for telechat - 2005-01-20 by Jon Peterson
2005-01-13
08 Jon Peterson [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson
2005-01-13
08 Jon Peterson Ballot has been issued by Jon Peterson
2005-01-13
08 Jon Peterson Created "Approve" ballot
2004-12-15
08 (System) State has been changed to Waiting for Writeup from In Last Call by system
2004-12-01
08 Amy Vezza Last call sent
2004-12-01
08 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2004-12-01
08 Jon Peterson State Changes to Last Call Requested from AD Evaluation by Jon Peterson
2004-12-01
08 Jon Peterson Last Call was requested by Jon Peterson
2004-12-01
08 (System) Ballot writeup text was added
2004-12-01
08 (System) Last call text was added
2004-12-01
08 (System) Ballot approval text was added
2004-11-05
08 Jon Peterson State Changes to AD Evaluation from Publication Requested by Jon Peterson
2004-08-03
08 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2004-06-22
07 (System) New version available: draft-ietf-mmusic-img-req-07.txt
2004-06-04
06 (System) New version available: draft-ietf-mmusic-img-req-06.txt
2004-06-04
05 (System) New version available: draft-ietf-mmusic-img-req-05.txt
2004-04-13
04 (System) New version available: draft-ietf-mmusic-img-req-04.txt
2004-02-17
03 (System) New version available: draft-ietf-mmusic-img-req-03.txt
2003-12-23
02 (System) New version available: draft-ietf-mmusic-img-req-02.txt
2003-12-04
01 (System) New version available: draft-ietf-mmusic-img-req-01.txt
2003-09-11
00 (System) New version available: draft-ietf-mmusic-img-req-00.txt