-----Original Message-----
From: mmusic-admin <at> ietf.org [mailto:mmusic-admin <at> ietf.org] On Behalf Of Evain Jean-Pierre
Sent: vendredi, 30. janvier 2004 18:32
To: Rod.Walsh <at> nokia.com; mmusic <at> ietf.org
Subject: RE: [MMUSIC] TVA comments on the framework and requirements

Hello Rod,

 

as announced earlier...

 

General:  Only one question on the metadata model.  I have seen a first draft from Oomu.  Isn't it within MMUSIC? If not, can you tell me more?

 

Requirements:

 

R2: Trailer booking for instance is not based on the use of a schedule.  It should be possible e.g. to book the recording of a piece of content from a trailer proposed on the website.  Full content would be recorded when ready for streaming (e.g. Unicast following this client request).  The same schemes as for broadactsing should apply to multicast.  I'll try to provide you with some text next week.

 

R5: seems to respond to the point at this stage

 

Framework:

 

F1: okay

 

F2:

I don't see why you shouldn't list them all.  Each of them is relevant ot my comments and to the IMG requirements and frameowkr at one moment or another.  What woul be the problem with a more comprehensive list of 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

F3:

Thanks, it is not Oomu but Luoma (sorry).  Where will the work on the metadata model continue?

 

F5

I'll seek advice within TVA from the colleague who proposed this particular comment.

 

Regards,

 

Jean-Pierre

 

-----Original Message-----
From: Rod.Walsh <at> nokia.com [mailto:Rod.Walsh <at> nokia.com]
Sent: mercredi, 28. janvier 2004 15:18
To: Evain Jean-Pierre; mmusic <at> ietf.org
Subject: RE: [MMUSIC] TVA comments on the framework and requirements

Hi All

 

Here is my summary (paraphrasing) of the TVA input which relates (only) to document review and request for changes (with suggested text).

 

Jean-Pierre, can you validate this and check that the proposed changes are suitable?

 

General:

 

G1. Both documents are in great shape and cover TVA ideas, use cases & objectives very well

 

G2. TVA would like to ensure that their system fits into the IMG framework. TVA wish to work with us to develop and exchange ideas to do this - i.e. specify the protocols for delivery (service discovery/announcement) possibly in MMUSIC, as well as data models (which would be outside of MMUSIC charter)

 

 

Requirements:

 

R1. Several TVA solutions meet several of the requirements

 

No changes needed

 

R2. 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.

 

Indeed there are many use cases beyond those given in this document. I propose that no changes are made, however if your experience is that certain TVA use cases have a strong impact (which is different from the existing IMG use cases) on metadata delivery (rather than the metadata itself), I would be keen to add just these. Are there such use cases? Does this sound OK?

 

R3. REQ DEL-3: The TVA data model has been designed to deliver data to large audiences <However, TVA does not currently specify IP delivery with massive scalability (such as one-to-very-many multicast) and so this is an open requirement for TVA too>

 

No changes needed

 

R4. 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) <and so this is an open requirement for TVA too>

 

No changes needed

 

R5. 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-3: Whereas specific applications relying on IMGs will need to
   select one or more specific application-specific metadata formats
   (standard, syntax, etc.), the IMG system MUST be independent of this
   (it may be aware, but it will operate in the same way for all).

   Thus, a transfer envelope format, that is uniform across all
   different application-specific IMG metadata formats, is needed. The
   payload of this transfer envelope would be some application-specific
   metadata.

-- change to ->

 

    REQ DES-3: Whereas specific applications relying on IMGs will need to
   select one or more specific application-specific metadata formats
   (standard, syntax, etc.), the IMG system MUST be independent of this
   (it may be aware, but it will operate in the same way for all).

   Thus, a transfer envelope format, that is uniform across all
   different application-specific IMG metadata formats, is needed. The
   payload of this transfer envelope would be some application-specific
   metadata, and the envelope would support the maintenance of the

   application-specific metadata including the metadata relationships

   determined by the data model(s) used. The transfer envelope would

   not need to be aware of the data model(s) in use.

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

   REQ DES-6: It SHALL be possible to deduce the metadata format from
   the transfer envelope.
In a sense, all metadata formats will be identifiable. The solution would need to allow "a metadata application" to recognise a data field as "recognised from this list or not recognised". The delivery itself must be independent of metadata format.

 

No changes needed.

 

R7. 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).

 

No changes needed.

 

 

Framework:

 

F1. The role of TVA needs clarification §5.1, which maybe achieved by:

 

   MPEG-7 [6] is a collection of XML-based description tools for general
   multimedia content including structured multimedia sessions. TV-
   Anytime Forum [7] provides descriptions based on MPEG-7 for TV
   specific program guides. These are likely to be limited to describe
   pictures, music and movies, thus it may be necessary to extend these
   descriptions in order to define a variety of documents, game
   programs, binary files, live events and so on.

-- change to ->

 

   MPEG-7 [6] is a collection of XML-based description tools for general
   multimedia content including structured multimedia sessions.

  

   The TV-Anytime Forum [7] provides descriptions based on XML schema 

   for TV-specific program guides. TV-Anytime uses the MPEG-7 User

   description profile to a limited extent (for user preferences and

   usage history) and also a TV-Anytime-specific data model for other

   schema - which are optimised to describe broadcast schedules,

   on-demand programme guides and programme events.

 

Also, it the following is noted although not necessary to paste into the framework:

 

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.

 

 

F2. A more specific referencing of TVA [7] is desirable, which may be achieved by:

 

   [7] T.-A. Forum, "Metadata specification S-3," TV-Anytime Forum
   Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June 2002.

 

-- change to ->

 

   [7] TV-Anytime Forum, "Broadcast and On-line Services: Search,

   select, and rightful use of content on personal storage systems

   ("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102

   822-2: System Description, V1.1.1, October 2003.

F3. The complete, delta and pointer data types are supported by TVA metadata

 

(Note, since the framework does not recommend that MMUSIC works on the data model, I will leave related responses to a later email - it seems that the information data model submission from Luoma and the TVA data models should work well together and transport of TVA metadata over IMG delivery protocols is a natural fit)

 

No changes needed

 

F4. TVA has not specified a unidirectional transport mechanism for TVA metadata so agrees with the proposal that an IP-based solution is developed (not SAP)

 

No changes needed

 

F5. TVA has developed some solutions for point-to-point unicast metadata delivery with HTTP, TLS, .... These will be interesting to scoping the needed work for point-to-point IMG delivery (what can be reused) and also subsequent point-to-point protocol work.

 

Open issue: we could describe and determine limitations and reuse of these in §5. (Proposed text is welcome!)

 

 

Next instalment in a few days!

 

Cheers, Rod.

 

**********************************************************************
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.

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