Internet Engineering Task Force
Internet Draft Nomura/Schulzrinne
Fujitsu/Columbia U.
draft-nomura-cdi-mmusic-mupdate-00.txt
June 24, 2002
Expires: November 2002
SIP Event Notification for Metadata Update Protocol
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document specifies an update notification protocol for metadata
using SIP event notification. This protocol improves metadata
coherency and efficiency between content providers and receivers by
up-to-date notifications when metadata changes. This protocol can
also be applied to several systems such as a streaming video
distribution system and a web content ditsribution system.
1 Introduction
Metadata can describe content features and its structures of
multimedia content and web pages. Metadata is a principal element for
content providers or receivers to manage and distribute multimedia
and web content [1]. It allows users to initiate streaming media
sessions, schedule delivery of downloadable or multicast content or
Nomura/Schulzrinne [Page 1]
Internet Draft mupdate June 24, 2002
listen to live multicast sessions [2].
Since content and its structure described by metadata changes as time
elapses, a content receiver needs to be notified of changes in order
to avoid stale state of metadata and content.
This document defines an update notification protocol for metadata
using SIP Event Notification framework [3]. It satisfies the
requirements for multimedia and web content management such as an
update notification, session keep-alive, status confirmation and
authentication of subscriber. In addition, using SIP framework,
extensiblity and flexiblity is provided.
This document also gives a guideline for metadata description and
update information formats used in the protocol. The guideline
includes candidate description formats and delta description methods.
2 Terminology
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 [4].
Notifier: A notifier is a user agent which generates NOTIFY requests
and receives SUBSCRIBE requests.
Subscriber: A subscriber is a user agent which receives NOTIFY
requests from notifiers and generates SUBSCRIBE requests.
Session: An identical metadata state between a notifier and a
subscriber.
Delta: Differences between the latest metadata state and the previous
state of metadata.
3 Overview of the content distribution system
Elements of the System: This protocol is used in a content
distribution system consists of at least two hosts, one is
a content server and the other is a content client.
Target Content: All content such as a multimedia streaming data,
multimedia file, and Web content consists web pages.
Three Transport Model: A content distribution system has three
transports, (1) content transport, (2) metadata transport
and (3) update notification (UN) transport.
Nomura/Schulzrinne [Page 2]
Internet Draft mupdate June 24, 2002
Content Server Content Client
content |-------content data------>| Content Transport
| |
metadata |---------Request--------->| Metadata Transport
|<--------Response---------| (e.g. HTTP)
| |
metadata or |<------notification-------| Update Notification
delta |-------Acknowledge------->| Transport
This protocol is used by Update Notification Transport but it can be
used in Metadata Transport if required.
1. Content Transport
This transport is used to transmit content in the system.
Any existing transport mechanism can be applied. The
transport is specified in metadata transmitted by Metadata
Transport. This document does not require particular
content transport.
2. Metadata Transport
This transport is used to transmit metadata or delta
information in the system. Any existing transport mechanism
can be applied but the simplest transport is HTTP. The
transport is specified and selected in UN transmitted by UN
transport. This document assumes that Metadata transport
does not provide Update Notification Transport.
3. Update Notification Transport
This transport is used to transmit update notifications
from a content server to a content client. When
Request/Response protocol like HTTP is used in Metadata
Transport and the system requires up-to-date content
distribution, this transport is necessary.
The problem of using HTTP for the metadata transport is an
inefficient refresh mechanism by polling. The freshness of
metadata has to be improved to send HTTP requests
frequently but the frequent requests increase the load on
the host receiving the unnecessary requests. The detail of
this problem has been introduced in RUP requirements [5].
The update notification like this protocol and RUP
activities aims to solve this problem.
Nomura/Schulzrinne [Page 3]
Internet Draft mupdate June 24, 2002
4 Overview of SIP Event Notification
4.1 Basic Protocol Operations
SIP [6] is a text-based request/response protocol. A SIP request
consists of a request-line, header field and message body like HTTP.
A SIP response also consists of a status-line, header field and body.
SIP Event has the same feature as SIP but SIP Event needs only two
messages, SUBSCRIBE and NOTIFY, to notify an event to subscribers.
Since the protocol intends to do this, it does not require SIP
messages to establish a session.
The following diagram shows basic protocol operations in SIP Event.
Protocol details are shown in section 5.
Subscriber Notifier
|-----SUBSCRIBE---->| Request state subscription
|<-------200--------| Acknowledge subscription
|<------NOTIFY----- | Return current state information
|--------200------->|
|<------NOTIFY----- | Return current state information
|--------200------->|
There are several reasons to use SIP Event for metadata update
notification.
4.2 Features of SIP Event Notification
1. Simple: SIP Event consists of just two messages to satisfy
RUP requirement and Program guide requirement.
2. Standard: Since SIP Event is used by many applications in
IMPP [7] and call services, there are a lot of
implementations based on it as a standard specification.
SIP Event is carefully designed to make it secure.
3. Extensible: SIP Event can take advantage of SIP functions
and services such as a proxy and so on.
4. Independent of transport protocols: SIP runs on top of
several different transport protocols. Therefore, it is
possible to use various transports such as UDP, TCP and
multicast.
Nomura/Schulzrinne [Page 4]
Internet Draft mupdate June 24, 2002
5 Protocol Details
5.1 Initialize
First of all, a subscriber of metadata MUST send a SUBSCRIBE request
to a notifier in order to prepare to receive a subsequent update
notification from the notifier.
The SUBSCRIBE request includes identity information in its headers
defined by SIP Events framework. As defined in SIP, To, From, Call-
ID, Event and Contact header can be used to identify a session
between a subscriber and notifier. Each parameter in the headers
depends on the implementations.
In this phase, the SUBSCRIBE request MAY contain a body indicating
what metadata status will be subscribed.
The name of this package is "metadataupdate". This header also
appears in NOTIFY requests.
If the SUBSCRIBE request is not related to existing sessions and the
notifier can authenticate the request successfully, the notifier
sends a 200 (OK) response to the subscriber. If the notifier can't
authenticate or accept the request, the notifier sends a 4xx response
and does not send a NOTIFY request.
A notifier MUST authenticate all subscription requests. This
authentication can be done using any of the mechanisms defined in SIP
and SIP Events.
After sending the SUBSCRIBE response, the notifier sends a NOTIFY
request immediately to the same subscriber. The request contains an
URI indicating a metadata location or metadata. Metadata indicated by
URI or contained in the body MUST describe the latest full state when
the NOTIFY request is sent. "Content-Type:" header in the NOTIFY
request MUST indicate a data type of the body.
The body in NOTIFY request MUST contains a version number and a
timestamp. The version number increases by exactly one for each
NOTIFY message as defined in SIP Event. The time stamp indicates
latest modified time of metadata status.
When the subscriber receives the request, the subscriber tries to
obtain metadata specified in the body. If the subscriber gets it
successfully, it sends 200 (OK) response to the notifier. If not, the
subscriber sends 4xx response.
5.2 Update Notification
Nomura/Schulzrinne [Page 5]
Internet Draft mupdate June 24, 2002
When metadata changes and it affects an existing subscription,
notifier sends a NOTIFY request on a session related to the metadata
status. The request body SHOULD contain metadata delta location or
metadata delta. The format of metadata delta is discussed in section
6.
When the subscriber receives the request, the subscriber tries to
obtain delta information specified in the body. If the subscriber
successfully gets it and updates metadata, it sends 200 (OK) response
to the notifier. If not, the subscriber sends 4xx response.
5.3 Session Keep Alive
At any time before a subscription expires, the subscriber may send a
SUBSCRIBE request to the notifier. The notifier sends a SUBSCRIBE
response and a NOTIFY request with delta information to communicate
up-to-date metadata status.
If the subscriber receives the NOTIFY message which includes the same
timestamp as the previous NOTIFY message, the subscriber does not
have to obtain delta information. In this case, a notifier sends it
just for a confirmation of the metadata status as an immediate
response for a SUBSCRIBE request.
If the timestamp is updated, the subscriber MUST obtain new delta in
the same way as receiving an update notification.
This mechanism can be applicable not only to refresh the timer but
also to confirm the current metadata status.
5.4 Polling metadata status
If a subscriber does not want to receive an update notification, a
subscriber may poll metadata status to send a SUBSCRIBE with an
"Expires" of 0.
5.5 Confirming the status of Subscribers
If a notifier needs to confirm the current status of a subscriber
which subscribes metadata status, it may send NOTIFY request
including a body which indicates a current delta information and wait
a NOTIFY response from the subscriber. When the notifier receives the
response with 200 (OK), the notifier confirms that the subscriber's
status is up-to-date. If not, the notifier can decide that the
subscriber has stale metadata.
5.6 Timer Expiration
Nomura/Schulzrinne [Page 6]
Internet Draft mupdate June 24, 2002
Expiration time depends on the system. If the system requires short
duration to guarantee metadata coherency, it should be a small value.
In some system, a connection between a subscriber and notifier is not
persistent but sporadic. In this case, subscriber may require the
long expiration time such as 1 day or 1 week.
If a subscriber receives NOTIFY request on the session which already
has been terminated because the timer has expired, the subscriber
SHOULD try to subscribe it again.
5.7 Invalid update notification
If a subscriber receives invalid NOTIFY message such as a
discontinuous version number or CSeq, the subscriber SHOULD close the
session and restart the session from Initialize step. As a result,
the subscriber can obtain latest full metadata states.
6 Descriptions of Metadata and Update information
6.1 Candidate Metadata Description
MPEG-7 [8] can describe metadata of content by using XML. It defines
XML schema representing general multimedia content and structure of
content group.
WCIP [9] provides a description format of a data structure for web
content group in order to achieve cache coherency between an origin
web notifier and a surrogate.
These two approaches are very similar in terms of describing a
structure of content group.
If metadata appears in a body of SIP Event, a data type MUST be
specified in Content-Type in header field.
6.2 Metadata based Invalidation
Metadata can describe availability information for content. If a
subscriber recognizes that the availability has been invalid, the
subscriber can invalidate content spontaneously without being
notified by a NOTIFY request from the notifier.
Availability information in metadata can contribute to reduce NOTIFY
messages indicating the invalidation operation. In this case, update
notifications are just used to substitute invalid metadata for
updated metadata. Removing content due to updating metadata may be
required on a system provides a content coherency between two hosts.
Nomura/Schulzrinne [Page 7]
Internet Draft mupdate June 24, 2002
6.3 Delta Description
Separate description between metadata and delta is RECOMMENDED.
Metadata may describe delta information between two metadata.
However, describing delta information using metadata makes metadata
description complex and less extensible.
Let's assume that one text notation in metadata should be substituted
another text and metadata described by XML. In terms of a general
tree structure such a XML, to identify child node information
requires all of parent node information to which child node belongs
because child node itself does not have identity information.
In this case, delta information must contain all of parent node
information in a document from a root node to a leaf node in order to
describe the only one text to be substituted.
Since metadata schema should provide identity information for every
child nodes in order to describe delta information, it results that
metadata schema becomes complex and difficult to extensible.
To avoid the problem, it is useful to keep metadata from delta
information and introduce differencing algorithm and description such
as the UNIX "diff" command described in delta encoding in HTTP [10].
Even though additional "diff" mechanism is required, this function is
enough simple and make metadata schema simple and extensible.
7 Example Message Flow
Subscriber Notifier
| F1 SUBSCRIBE |
|------------------>|
| F2 200 OK |
|<------------------|
| F3 NOTIFY |
|<------------------|
| F4 200 OK |
|------------------>|
| |
| |<-- Update metadata
| |
| F5 NOTIFY |
|<------------------|
| F6 200 OK |
|------------------>|
Nomura/Schulzrinne [Page 8]
Internet Draft mupdate June 24, 2002
F1 SUBSCRIBE subscriber.com->notifier.com
SUBSCRIBE sip:metadata@notifier.com SIP/2.0
Via: SIP/2.0/TCP host1.subscriber.com;branch=z9hG4bKnashds7
To: <sip:metadata@notifier.com>
From: <sip:metadata@subscriber.com>;tag=xfg9
Call-ID: 7070@host1.subscriber.com
CSeq: 15024 SUBSCRIBE
Max-Forwards: 70
Event: metadataupdate
Contact: <sip:metadata@host.subscriber.com>
Expires: 300
Content-Length: 0
F2 200 OK notifier.com->subscriber.com
SIP/2.0 200 OK
Via: SIP/2.0/TCP host1.subscriber.com;branch=z9hG4bKnashds7
;received=192.0.2.2
To: <sip:metadata@notifier.com>;tag=ffd2
From: <sip:metadata@subscriber.com>;tag=xfg9
Call-ID: 7070@host1.subscriber.com
CSeq: 15024 SUBSCRIBE
Event: metadataupdate
Expires: 300
Contact: <sip:metadata@host2.notifier.com>
Content-Length: 0
F3 NOTIFY notifier.com-> subscriber.com
NOTIFY metadata@host.subscriber.com SIP/2.0
Via: SIP/2.0/TCP host2.notifier.com;branch=z9hG4bKna998sk
From: <sip:metadata@notifier.com>;tag=ffd2
To: <sip:metadata@subscriber.com>;tag=xfg9
Call-ID: 7070@host1.subscriber.com
Event: metadataupdate
Subscription-State: active;expires=599
Max-Forwards: 70
CSeq: 3487 NOTIFY
Content-Type: text/xml
Content-Length: ...
Version: 1
Last-Modified: Mon, 24 Jun 2002 08:03:55 GMT
Metadata-URI: http://metadata.notifier.com/program1/02080355.xml
F4 200 OK subscriber.com-> notifier.com
Nomura/Schulzrinne [Page 9]
Internet Draft mupdate June 24, 2002
SIP/2.0 200 OK
Via: SIP/2.0/TCP host2.notifier.com;branch=z9hG4bKna998sk
;received=192.0.2.2
From: <sip:metadata@subscriber.com>;tag=ffd2
To: <sip:metadata@notifier.com>;tag=xfg9
Call-ID: 7070@host1.subscriber.com
CSeq: 3487 NOTIFY
F5 NOTIFY notifier.com -> subscriber.com
NOTIFY sip:metadata@host.subscriber.com SIP/2.0
Via: SIP/2.0/TCP host2.notifier.com;branch=z9hG4bKna998sl
From: <sip: metadata@notifier.com>;tag=ffd2
To: <sip:metadata@subscriber.com>;tag=xfg9
Call-ID: 7070@host1.subscriber.com
CSeq: 3488 NOTIFY
Event: metadataupdate
Subscription-State: active;expires=543
Max-Forwards: 70
Content-Type: text/plain
Content-Length: ...
Version: 2
Last-Modified: Mon, 24 Jun 2002 09:19:31 GMT
Delta-URI: http://delta.notifier.com/program1/02091931.txt
F6 200 OK subscriber.com-> notifier.com
SIP/2.0 200 OK
Via: SIP/2.0/UDP notifier.example.com;branch=z9hG4bKna998sl
;received=192.0.2.2
From: <sip:metadata@subscriber.com>;tag=ffd2
To: <sip:metadata@notifier.com>;tag=xfg9
Call-ID: 7070@host1.subscriber.com
CSeq: 3488 NOTIFY
Content-Length: 0
8 Security Considerations
TBD
9 Bibliography
[1] L. Amini et al., "Distribution requirements for content
internetworking," Internet Draft, Internet Engineering Task Force,
Feb. 2002. Work in progress.
Nomura/Schulzrinne [Page 10]
Internet Draft mupdate June 24, 2002
[2] Y. Nomura and H. Schulzrinne, "Protocol requirements for internet
program guides," Internet Draft, Internet Engineering Task Force,
Feb. 2002. Work in progress.
[3] A. Roach, "SIP-specific event notification," Internet Draft,
Internet Engineering Task Force, Mar. 2002. Work in progress.
[4] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[5] I. Cooper, D. Li, M. Dahlin, and M. Hamilton, "Requirements for a
resource update protocol," Internet Draft, Internet Engineering Task
Force, Mar. 2002. Work in progress.
[6] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress.
[7] J. Rosenberg, "Session initiation protocol (SIP) extensions for
presence," Internet Draft, Internet Engineering Task Force, May 2002.
Work in progress.
[8] ISO (International Organization for Standardization), "Overview
of the MPEG-7 standard," ISO Standard ISO/IEC JTC1/SC29/WG11 N4509,
International Organization for Standardization, Geneva, Switzerland,
Dec. 2001.
[9] D. Li, P. Cao, and M. Dahlin, "WCIP: Web cache invalidation
protocol," Internet Draft, Internet Engineering Task Force, Mar.
2001. Work in progress.
[10] J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland,
A. van Hoff, and D. Hellerstein, "Delta encoding in HTTP," RFC 3229,
Internet Engineering Task Force, Jan. 2002.
10 Author's Addresses
Yuji Nomura
Fujitsu Laboratories Ltd.
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588
Japan
Email: nom@flab.fujitsu.co.jp
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
Nomura/Schulzrinne [Page 11]
Internet Draft mupdate June 24, 2002
USA
Email: schulzrinne@cs.columbia.edu
Nomura/Schulzrinne [Page 12]