\documentclass[11pt]{article}
\usepackage{times}
\usepackage{graphics}
\usepackage{ifthen}
\usepackage{i-d}
%\usepackage{rfc}
\usepackage{html}
\usepackage{txtpsfig}
\usepackage{tight}
\usepackage[dvips]{changebar}

\title{Protocol Requirements for Internet Program Guides}
\author{Nomura/Schulzrinne}
\shorttitle{pguide}
\filename{draft-nomura-mmusic-pguide-requirements-00}
\wg{}
\expires{July 2002}
\address{Fujitsu/Columbia U.}
\pubdate{\today}
\input{../defs}
 
\begin{document}
\maketitle
\begin{abstract}
This memo specifies requirements for protocol for accessing and updating
program guide information for media-on-demand and multicast
applications.
\end{abstract}    

\section{Introduction}

A program guide describes one or more multimedia items, available either
for download, streaming or multicast distribution.  There may also be
meta-guides, i.e., program guides that describe other program guides. 
Program guides allow users to initiate streaming media sessions,
schedule delivery of downloadable or multicast content or listen to live
multicast sessions.

Protocols are needed to transmit and update such program guides, as well
as let users know if a program guide has changed.  The same host can
serve and produce program guide information.

This draft classifies the features and use cases of the program guide
and shows requirements and describes some possible solutions.

\section{Terminology}

The key words {\MUST}, {\MUSTNOT}, {\REQUIRED}, {\SHALL}, {\SHALLNOT}, 
{\SHOULD}, {\SHOULDNOT}, {\RECOMMENDED},  {\MAY}, and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 \cite{rfc2119}.

\section{Overview}

\subsection{Definition of Program Guide}

A program guide is a set of meta-data describing the features of
multimedia content.  For example, meta-data may consist of the URI,
title, air time, bandwidth needed, file size, text summary, genre, and
access restrictions. 

\subsection{Features of a Program Guide}

Program guide data may be updated as time elapses because content
described in the guide may be changed.  For example, the airtime of an
event such as a concert or sports event may change, possibly affecting
the air time of subsequent programs. 

Also, content may be made available only temporarily, e.g., via
multicast, based on popularity. If a particular program proves to be
popular, additional sessions might be added. Similarly, a program may be
made available for download from a different set of servers.

\subsection{Devices Using the Program Guide}

We assume that any Internet host can be a source of content and thus
meta data.  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 meta data, including bandwidth-constrained
mobile devices.  Thus, we envision that program guides 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 PVR (Personal Video Recorder).

\section{Use Case Models of The Program Guide}

Typical use case models of the program guide are following four 
models divided into using ways (automatically, manually) and 
obtaining time of content (real time and time shift). Table 1 shows 
these models and typical examples. 

\begin{table}[htpb]
\begin{tabular}{lll}
   & Manually & Automatically\\
\hline
Real Time  &  (1) TV    &  (3) Live conference broadcasting\\
Time Shift &  (2) VCR   &  (4) Preference-based recording\\
\end{tabular}
\end{table}

(1) Television model:  A human user manually uses the program guide,
specifies the content and watches it in real time.  If the airtime is
changed suddenly and the sender of the program guide notifies the user,
the user can follow the preferred content manually. 

(2) VCR model:  A human user manually uses the program guide, specifies
content to be stored.  The user watches it by time-shift.  If the
airtime is changed suddenly and the sender of the program guide notifies
the user, the user can manually specify the preferred content again. 

(3) Live conference broadcasting model: A device uses the program 
guide automatically, specifies content and shows it to users 
when it is available. If the availability is changed suddenly 
and the sender of the program guide notifies the device of the change,
the device can follow this change automatically. 

(4) Preference-based recording model:  A device uses the program guide
to store content automatically according to a user's direction such as a
preference and configuration.  If the availability is changed suddenly
and the sender of the program guide notifies the device, the device can
follow this change automatically. 

\section{Requirements}

\subsection{On-demand Retrieval}

Since the program guide may contain a large amount of data, the client
needs to be able to access the guide when convenient (e.g., when
sufficient network bandwidth is available to the user).  Thus, the
protocol must support request-response operation.

\subsection{Customized Program Guide}

User may require a subset of the program guide according to their
preference (type of content, media format, appropriate age group, etc.)
and configuration.

\subsection{Different Kinds of Devices}

The protocol is designed to be sufficiently simple so as to be 
implemented on the small devices such as a cellular phone and PDA.

\subsection{Many Kinds of Multimedia Content}

Program guides may describe a variety of media formats, not just (say)
MPEG-derived formats. Program guides may describe other program guides.
Program guides should be able to describe parts of multimedia streams,
e.g., a news story within a news magazine.

\subsection{Program Guide as Web}

Program guides should allow for a web structure, i.e., where a program
guide may refer to other guides or actual meta data. Just like the web,
links (with meta data about the linked-to entity) and content should be
able to appear in the same program guide.

\subsection{Change Notification}

Since program guides can change at any time, receivers of program guides
should be notified of such changes, without necessarily re-sending the
whole program guide. Depending on the size of the guide, the interested
party may want to defer retrieving the actual information. The change
notification should be addressed to a logical user, not a host, since
users may change devices.

As an example, consider a storage device requires the up-to-date video
file from an IP-reachable video camera but the camera is connected only
sporadically.  When the camera is connected on the network and has a new
video object, the storage device must be notified of its availability
immediately.

\subsection{Reliable Message Exchange}

This protocol requires a reliable message exchange.

\subsection{Multiple Sources}

Users should be able to obtain program guides from any number of
sources, i.e., there is no (single) root node in the tree.

\section{Protocol Components}

Protocols for program guide access can be divided into three components:

\begin{description}
\item[Program guide request:] A user can obtain a program guide listing
one or more multimedia resources, selecting an appropriate subset.

\item[Notification request:] A user can subscribe to change
notifications for meta-data elements of interest, or new program guide
elements matching a profile.

\item[Update notification:] When the program guide owner detects a
change in the program guide which has been subscribed to by a receiver,
the owner sends a notification message to the receiver.  The receiver
replies with an acknowledgement.  This message may be forwarded to a
suitable device.

\end{description}

\section{Related Protocols}

SDPng \cite{draft-ietf-mmusic-sdpng} can describe meta-data for content
by using XML.  Since SDPng addresses multiparty multimedia conferences,
it is necessary to extend the XML schema in order to describe general
multimedia content.

MPEG-7 \cite{isoN4509} can describe meta-data of content by using XML. 
It defines an XML schema for general multimedia content and has a
program guide structure.

SAP \cite{rfc2974} distributes session descriptions via multicast.  It
does not support fine-grained meta data selection and update
notifications, as it always sends the whole meta data.  Given the lack
of a wide-area multicast infrastructure, it is likely only deployable
within a local area network.

SIP \cite{draft-ietf-sip-rfc2543bis} and SIP-specific event notification
\cite{draft-ietf-sip-events} can be used to notify subscribers of the
update of the program guide. Since program guides are likely to be
referencable by URLs, \cite{draft-wu-sipping-webshare} describes a means
to notify users of changes in those URLs.

HTTP or SOAP can be used to request a program guide. SOAP could be used
to define queries.

\section{Open Issues}

The content and format for a meta program guide remain to be determined.

The consumer should be able to select parts of a program guide.  If an
XML-based format is used, this appears to be a special case of an XML
query operation (http://www.w3.org/XML/Query).

Unlike for presence, where likely only the last state is of interest,
update notifications for disconnected users may need to be queued.

\section{Security Considerations}

TBD 

\bibliographystyle{ieeetr}
\bibliography{string,iso,rfc,i-d}

\section{Author's Addresses}

\begin{flushleft}
Yuji Nomura\\
Fujitsu Laboratories Ltd.\\
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588\\
Japan\\
Email:  nom@flab.fujitsu.co.jp 
\end{flushleft}

\begin{flushleft}
Henning Schulzrinne\\
Dept. of Computer Science\\
Columbia University\\
1214 Amsterdam Avenue\\
New York, NY 10027\\ 
USA\\ 
Email:  schulzrinne@cs.columbia.edu 
\end{flushleft}
\input{copyright}
\end{document}
