RE: [MMUSIC] TVA comments on the framework and requirements

Rod.Walsh@nokia.com Wed, 28 January 2004 12:58 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28984 for <mmusic-archive@odin.ietf.org>; Wed, 28 Jan 2004 07:58:59 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpH5-0003bA-7A for mmusic-archive@odin.ietf.org; Wed, 28 Jan 2004 07:58:31 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SCwVPk013831 for mmusic-archive@odin.ietf.org; Wed, 28 Jan 2004 07:58:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpH5-0003b0-1V for mmusic-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 07:58:31 -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 HAA28981 for <mmusic-web-archive@ietf.org>; Wed, 28 Jan 2004 07:58:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlpH4-00062P-00 for mmusic-web-archive@ietf.org; Wed, 28 Jan 2004 07:58:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlpGB-0005yP-00 for mmusic-web-archive@ietf.org; Wed, 28 Jan 2004 07:57:39 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlpFe-0005tj-00 for mmusic-web-archive@ietf.org; Wed, 28 Jan 2004 07:57:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpFd-0003Qc-87; Wed, 28 Jan 2004 07:57:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpFA-0003QM-Rc for mmusic@optimus.ietf.org; Wed, 28 Jan 2004 07:56:32 -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 HAA28934 for <mmusic@ietf.org>; Wed, 28 Jan 2004 07:56:31 -0500 (EST)
From: Rod.Walsh@nokia.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlpF9-0005sO-00 for mmusic@ietf.org; Wed, 28 Jan 2004 07:56:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlpEC-0005no-00 for mmusic@ietf.org; Wed, 28 Jan 2004 07:55:34 -0500
Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AlpDR-0005ja-00 for mmusic@ietf.org; Wed, 28 Jan 2004 07:54:45 -0500
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0SCshV02617 for <mmusic@ietf.org>; Wed, 28 Jan 2004 14:54:43 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6769625232ac158f25637@esvir05nok.ntc.nokia.com>; Wed, 28 Jan 2004 14:54:42 +0200
Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 14:54:22 +0200
Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe021.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 14:54:21 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E59D.D922CD0C"
Subject: RE: [MMUSIC] TVA comments on the framework and requirements
Date: Wed, 28 Jan 2004 14:54:21 +0200
Message-ID: <D0299AFF29E01E478321564030AD69090BE4BB@trebe003.europe.nokia.com>
Thread-Topic: [MMUSIC] TVA comments on the framework and requirements
Thread-Index: AcPk3z5pC0rrsf+3TuGi1u+MJ+NLEQAq51Dw
To: evain@ebu.ch
Cc: mmusic@ietf.org
X-OriginalArrivalTime: 28 Jan 2004 12:54:21.0322 (UTC) FILETIME=[D9345EA0:01C3E59D]
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.4 required=5.0 tests=AWL,EXCUSE_16, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60

Hi Jean-Pierre
 
Thank you for your extensive input. We are very pleased that TV-Anytime finds the IMG work to be in great shape for TVA use, and also to have such a good breadth of comments on the applicability of IMGs and TVA to one another.
 
To make my life easier in responding and discussing this information I will make more than one email reply covering different aspects. Here's an idea of the kind of aspects I'm thinking about:
* TVA review of IMG requirements and framework IDs and changes to these documents
* Separating TVA-IMG objectives to those which fit MMUSIC scope, and those which belong to other standards WGs
* The delivery protocol needs of TVA with IMG: existing solutions and new work needed (and where to do it)
* The metadata needs of TVA with IMG: existing solutions and new work needed (and where to do it)
* The conformance of TVA Phase 1 (and the up-and-coming Phase 2) to the IMG requirements & framework
* The applicability of TVA technology for reuse in IMG solutions
 
In the meantime, anyone else's ideas are more than welcome.
 
Cheers,
Rod Walsh
 
 
-----Original Message-----
From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of ext Evain Jean-Pierre
Sent: Tuesday, January 27, 2004 4:06 PM
To: mmusic@ietf.org
Subject: [MMUSIC] TVA comments on the framework and requirements



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.

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