[MMUSIC] TVA comments on the framework and requirements

Evain Jean-Pierre <evain@ebu.ch> Tue, 27 January 2004 14:11 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05610 for <mmusic-archive@odin.ietf.org>; Tue, 27 Jan 2004 09:11:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTvS-0001TS-JB for mmusic-archive@odin.ietf.org; Tue, 27 Jan 2004 09:10:47 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0REAkj1005660 for mmusic-archive@odin.ietf.org; Tue, 27 Jan 2004 09:10:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTvS-0001TD-Ez for mmusic-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 09:10:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05577 for <mmusic-web-archive@ietf.org>; Tue, 27 Jan 2004 09:10:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTvQ-0003n0-00 for mmusic-web-archive@ietf.org; Tue, 27 Jan 2004 09:10:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTuV-0003kW-00 for mmusic-web-archive@ietf.org; Tue, 27 Jan 2004 09:09:49 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlTtl-0003hz-00 for mmusic-web-archive@ietf.org; Tue, 27 Jan 2004 09:09:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTtk-0001Kl-Br; Tue, 27 Jan 2004 09:09:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTtU-0001KH-GY for mmusic@optimus.ietf.org; Tue, 27 Jan 2004 09:08:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05514 for <mmusic@ietf.org>; Tue, 27 Jan 2004 09:08:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTtS-0003h5-00 for mmusic@ietf.org; Tue, 27 Jan 2004 09:08:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTsW-0003eX-00 for mmusic@ietf.org; Tue, 27 Jan 2004 09:07:46 -0500
Received: from mailgate2.ebu.ch ([194.158.3.44]) by ietf-mx with esmtp (Exim 4.12) id 1AlTrb-0003ZU-00 for mmusic@ietf.org; Tue, 27 Jan 2004 09:06:47 -0500
Received: from gnvasmile.ebu.ch (unverified [10.73.222.210]) by mailgate2.ebu.ch (Content Technologies SMTPRS 4.3.10) with ESMTP id <T676446879ac29e032c480@mailgate2.ebu.ch> for <mmusic@ietf.org>; Tue, 27 Jan 2004 15:06:15 +0100
Received: by gnvasmile.ebu.ch with Internet Mail Service (5.5.2653.19) id <D38XJK4Z>; Tue, 27 Jan 2004 15:06:02 +0100
Message-ID: <ADC0C83B38D8D511B8430008C70D300345C39B@gnvasmile.ebu.ch>
From: Evain Jean-Pierre <evain@ebu.ch>
To: mmusic@ietf.org
Date: Tue, 27 Jan 2004 15:06:01 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E4DE.B2109650"
Subject: [MMUSIC] TVA comments on the framework and requirements
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,EXCUSE_16,HTML_MESSAGE autolearn=no version=2.60

0/ Summary
TV-Anytime has reviewed draft-ietf-mmusic-img-framework-02.txt
and draft-ietf-mmusic-img-req-02.txt and would like to suggest the
following...

The IMG framework and requirements are fully in line with TVA objectives and
we have only a very limited number of suggestions for amendment of the
texts.

TVA looks forward ensuring compatibility of the IMG mechanisms with our
applications.
Furthermore, TVA would like to share experience with IMG and contribute to
the IMG data model, service discover and service exploitation mechanisms.


1/ Clarification of the role of TV-Anytime
We would like to start by clarifying the relationship between TV-Anytime and
MPEG-7.  The description made in Section 5.1 does not seem to be accurate
and the assumption made that TV-Anytime is as a whole based on MPEG7 is not
correct.  Most of the TV-Anytime schemas are based on a data model specific
to TV-Anytime.  TV-Anytime schemas have been optimised to describe broadcast
schedules, on-demand programme guides and programme events.  TV-Anytime only
uses the MPEG-7's User description profile for user preferences and usage
history. 


2/ References to TVA specifications
Furthermore, the references to TV-Anytime specifications should be completed
as follows using the ETSI references:

Generic specification name:
ETSI-TS 102 822; Broadcast and On-line services: Search, select, and
rightful use of content on personal storage systems
Identification of specification parts and sub-parts:
ETSI-TS 102 822-1: Phase 1 Benchmark Features
ETSI-TS 102 822-2: System Description
ETSI-TS 102 822-3/1: Metadata Schemas
ETSI-TS 102 822-3/2: Metadata System Aspects (Fragmentation, indexing,
encoding)
ETSI-TS 102 822-4: Content Referencing
ETSI-TS 102 822-6/1: Metadata Services over a Bidirectional Network -
Service and transport
ETSI-TS 102 822-6/1: Metadata Services over a Bidirectional Network -
Service Discovery
ETSI TS 102 822-7: Bidirectional Metadata Delivery Protection


3/ TV-Anytime is totally in line with the IMG framework in terms of
services, applications and entities.  Furthermore, TV-Anytime has already
explored some of the delivery and transport issues addressed by IMG.


4/ The domain of application of TVA Phase 1 is unidirectional broadcast
assisted by bi-directional access to ancillary metadata services.  The TVA
specification covers the description of broadcast and on-demand schedules or
events.  Furthermore, TVA has developed a "content referencing" scheme and
"resolving" mechanisms that provide enhanced flexibility in the management
of schedules and associated content.  The type of Phase 1 content is
primarily video, audio and ancillary services (Teletext, subtitles,
design-for-all features...).  TVA Phase 2 is currently addressing media
packages that will encompass all sorts of data for different media delivery.
It is therefore expected that TVA will cover a very wide range of
applications and content and we would like to ensure that IMG allows to TVA
data being accessed, transported and delivered using multicast or unicast
delivery.


5/ As suggested in the IMG framework, the data model defined by TV-Anytime
has been designed to allow an efficient delivery, versioning and updating of
our data.  This structure (fragmentation, indexing, encoding, etc) is
defined in our metadata specification ETSI TS102822-3/2.   The TVA data
model is fully compatible with the notions of IMG descriptions, Delta IMG
descriptions and IMG pointer identified in the IMG framework. The use of the
TVA model is not restricted and IMG is welcome to adopting it depending on
the level of granularity targeted for the IMG data types and data models
(see IMG needs in Sections 3.1 and 5.3.4).  The experience of TV-Anytime is
that the data model must be sufficiently explicit to further specify the
metadata service mechanisms (see ETSI TS102822-6/1/2).


6/ Service discovery over bi-directional networks, commands and protocols
can be found in ETSI TS102822-6.  The TVA specification make use of existing
IETF mechanisms.  TVA would certainly welcome feedback from IMG experts on
the solutions proposed in these documents. We look forward to collaborating
with IMG to maintain / enhance compatibility. Furthermore, TVA defines
service discovery mechanisms initiated by a client request for metadata
services but there is no reason why TVA could not take benefit from
permanent connection or access e.g. multicast to "pushed" data. In TVA,
service discovery is made using UDDI or WSDL and WS-Inspection.  Once a
metadata service has been "discovered", the domain of operation is the
metadata service domain.


7/ Security is addressed in ETSI TS102822-7. TV-Anytime has specified basic
security mechanisms for the exchange of metadata over bi-driectional
networks based on IETF TLS (Transport Layer Security).


8/ TVA supports the IMG requirements with the exception of one or two minor
request for clarification to be reported hereafter.  More importantly,  the
concurrence of the IMG framework and requirements with what TVA has done
(Phase 1 plus Phase 2 covering a wide range of application and content
types) encourages us in more collaboration with IMG in particular
contributing to draft-luoma-mmusic-img-metadata-03 with our data model.


9/ Suggestions on the content orientated use cases in IMG requirements
TVA Phase 1 definitely covers 4.2.2 TV and radio programme delivery, 4.2.3
media coverage of a live event and  4.2.4 distance learning. One could
certainly add more use cases such as "Trailer booking and recording", "Use
of segmented content for content updates, content replacement for e.g.
targeted advertising, and virtual programmes", "Discovery and access to
related programmes", etc.
TVA Phase 2 will enrich these cases by the use of media packages
encompassing more content formats than audio, video and related ancillary
data.


10/ Review of the IMG requirements and comments
REQ GEN-1: The TVA data model is compliant with the IMG framework and
associated requirements.  SP003 defines self-contained common document
structure being considered as a candidate for IMG metadata format. It has a
single top-level element that encloses all other TV-Anytime metadata.  TVA
can be transported efficiently by fragmenting descriptions and sequential
delivery of description tables clearly identified by their version for
updating, replacement or deletion.

REQ GEN-2: TVA anytime Phase 1 covers a wide range of applications as
mentioned above.  Phase 2 will further enlarge the scope of application of
TVA data.  IMG SHOULD support these.

REQ GEN-3: SP003 defines the identifier that specifies the name of the
publisher of the description. This offers the base for some mechanisms to
solve issues related to simultaneous access to multiple IMG senders.  

REQ GEN-4: SP006 ensures the modularity of query/response operations
relevant to IMG Operations.

REQ DEL-1: The TVA metadata model allows flexible update.

REQ DEL-2: SP003 defines identification scheme to identify particular
version of a metadata fragment.  TVA anytime data fragmentation takes into
account the need for efficient delivery and management of update in
combination with BiM encoding.

REQ DEL-3: The TVA data model has been designed to deliver data to large
audiences
REQ DEL-4: SP006 has allows to expand metadata descriptions based on the TVA
versioning and notification schemes.  The TVA approach described in
TS102822-6 is based on service discovery initiated by a client but could
also take benefit of permanent, although possibly intermittent, connections.
The fragmentation and indexing of TVA data allows small quantities of
reliably connected carouselled data being transmitted including over
intermittent connections.  Descriptions are reconstructed after reception
once the system has been signalled that all description elements have been
received.

REQ DEL-5: See REQ DEL-4

REQ DEL-6: TV-Anytime queries are currently client initiated.  The problem
of time limited validity of pushed data remains to be addressed (TVA Phase
2).

REQ DEL-7: Sender driven aspects will be addressed in TVA Phase 2 for
compliance with IMG requirements.

REQ CUS-1: SP006 defines schemes for submission of user-centric metadata to
metadata service providers and retrieval of customised data. Sender-driven
uni/multicast delivery of customized metadata descriptions will be addressed
in TVA Phase 2 for compliance with IMG requirements.

REQ REL-1: SP003 defines an identification scheme to identify and manage a
particular version of a metadata fragment, which can be a complete
description or a description subset.

REQ REL-2: SP006 can manage versions and updates in client initiated
transactions. Sender-driven uni/multicast delivery will be addressed in TVA
Phase 2 for compliance with IMG requirements.

REQ REL-3: SP006 uses http as a base for bi-directional metadata retrieval.

REQ DES-1: This issue is particularly sensitive in the case of simultaneous
access to multiple IMG senders.  This is being addressed in TVA Phase 2.
However, TVA believes that the metadata provided by different sources is
under the responsability of one authority that manages versions of this
data.

REQ DES-2: Absolutely necessary and TVA is ready to help in order to ensure
that this apply to all TVA's domains of application.

REQ DES-3: TVA would like to suggest a clarification of this requirements
with the need expressed in the IMG framework document for an IMG minimum
data model.

REQ DES-4: SP003 defines self-contained common document structure that  has
a single top-level element that encloses all or part of TV-Anytime metadata.
The different metadata tables can be transmitted in separate fragments.

REQ DES-5: Agreed.  In the case of TV-Anytime, the envelope must contain all
the parameters essential to the management of TVA Main and associated
fragments.

REQ DES-6: TV-Anytime should be one of the identifiable metadata formats.

REQ DES-7: no comment

REQ DES-8: TVA fully supports versioning and updates.

As concerns the requirements security mentioned in Section 6, TVA only
defines very generic scheme for establishing secure authentication channel
between metadata sender and receiver (TS 102822-7). 



**********************************************************************
 This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************