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

From: "Evain Jean-Pierre" <[email-masked]>
Date: Wed, 4 Feb 2004 16:16:28 +0100

HI Rod,
 
Any view on my latest comments?
 
Can you please tell me where the metadata model from Luoma is going to be
discussed if its not in MMUSIC?
 
Jean-Pierre

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On Behalf
Of Evain Jean-Pierre
	Sent: vendredi, 30. janvier 2004 18:32
	To: [email-masked]; [email-masked]
	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: [email-masked] [mailto:[email-masked]] 
		Sent: mercredi, 28. janvier 2004 15:18
		To: Evain Jean-Pierre; [email-masked]
		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.

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

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

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

---

From: [email-masked]
Date: Fri, 6 Feb 2004 17:17:35 +0200

Hi Jean-Pierre (et al.)
 
<note, this is a "previous email thread deleted" version of the initial reponse since the original exceeded 50K and is currently waiting moderator approval>
 
Sorry for the delay, and thank for your patience.
 
On the data model, the purpose of sharing the data model in MMUSIC is to ensure that this side of the discussion is included in the IMG Framework considerations, even though MMUSIC will only charter IMG delivery protocol work (not "application-specific metadata"). My opinion is that DVB-CMBS and OMA are the prime options for baseline date model standardisation (although there's a strong "crystal-ball" element to this prediction as neither have the final solution at this juncture in time). It is reasonable to exchange ideas and information and develop the data model openly, but it is necessary to understand the the MMUSIC chairs have made it absolutely clear that this is the wrong standards WG to standardise it.
 
(I'm "announcing" this in MMUSIC so those interested are aware that there will be non-IETF - and possibly non-all-access - related work and thus can get involved or ask to be kept up-to-date off-line from MMUSIC)

On the IMG FW & reqs feedback:
 
Everything's looking good with the extra comments:
 
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 broadcasting should apply to multicast.  I'll try to provide you with some text next week.
 
So you mean that an IMG metadata could describe the trailer booking service where details of how to book are described by the IMG metadata? The IMG system would not be used to do the booking (although possibly to subscribe to a notification or wait for an announcement indicating that the booking service is now available). Do you feel that the the inclusion of this use cases (in the framework) would have a significant impact on the conclusion of the framework or the IMG metadata delivery protocols? I guess your text next week should clarify this.
 
The primary use cases described for IMGs are multicast/multiparty session enablers, so although unicast services could easily be described too, this is not the primary objective of IMG/MMUSIC work.
 
F2: I don't see why you shouldn't list them all.  Each of them is relevant to my comments and to the IMG requirements and framework at one moment or another.  What would be the problem with a more comprehensive list of references?
 
I have never seen an IETF document with such a reference format (it's much more ETSI style). It's much more usual to provide the "boot-strap" reference so that the full documented list can be found. (Technically, only a single reference to the TVA body of work is needed from the document body text as we do not discuss exact particulars of each of the documents). To give an example, for FLUTE [], we could easily give a set of related references, but these would easily be found by first finding the FLUTE specification and then following the subsequent references.
 
e.g.
FLUTE ref option 1:
   [14] T. Paila, "FLUTE - file delivery over unidirectional transport,"
   Internet Draft draft-ietf-rmt-flute-07, Internet Engineering Task
   Force, Dec. 2003.  Work in progress.
 
FLUTE ref option 2:
   [14] <FLUTE - File Delivery over Unidirectional Transport, draft-ietf-rmt-flute-07.txt>
   [??] <RFC 3450 Asynchronous Layered Coding (ALC) Protocol Instantiation> 
   [??] <RFC 3451 Layered Coding Transport (LCT) Building Block> 
   [??] <RFC 3452 Forward Error Correction (FEC) Building Block> 
   [??] <RFC 3453 The Use of Forward Error Correction (FEC) in Reliable Multicast> 
   [??] <Compact Forward Error Correction (FEC) Schemes, draft-ietf-rmt-bb-fec-supp-compact-01.txt>
where the <> implies expanding these out to be formal reference style
 
My opinion is to go with the single concise TVA document reference as it reads easily to IETF-eyes and the remainder of documents are easily found from this. Does this make sense?

BTW, DVB-GBS begin work on IP transport week 11 (the week after IETF-59), if interested I'd be more than happy to discuss these issues there also (assuming you will not be in South Korea).
 
Cheers, Rod.

---

From: [email-masked]
Date: Fri, 6 Feb 2004 17:29:27 +0200

Hi Jean-Pierre
 
I understand the use case. It is definitely a good idea. The "TV and Radio Program Delivery" use case covers this to some extent and the framework clearly enables this. 
 
Do you feel the use cases needs adding to the requirements document? 
 
Cheers, Rod.
 
-----Original Message-----
From: ext Evain Jean-Pierre [mailto:[email-masked]]
Sent: Friday, February 06, 2004 5:20 PM
To: Walsh Rod (Nokia-NRC/Tampere)
Cc: [email-masked]
Subject: RE: [MMUSIC] TVA comments on the framework and requirements

Rod,
 
First of all, thank-you for the clarification on the data model issue.  I'll be happy to join any off-line work on this subject.  Please let me know...
 
As concerns the draft documents:
 
- R2: I think that you partly answered your own question...
 
"Trailer advertising and booking allow to notify or publicise an isolated  (unicast or multicast) event. The IMG system should allow an IMG client to subscribe to a service listing such notifications, but also allow for annoucements being pushed to IMG clients.  Although the resolving and acquisition protocols shall probably be equivalent to those used for schedules, data delivery and updating might require the management of smaller fragments/units of information."
 
- F2: Now I understand what you were trying to do with referencing the "system" part 2 of the TVA specification.  I agree, it is probably the main hook to the other parts of the specification.
 
I'll probably be attending GBS in Finland.  What's going on in South Korea?
 
Best regards,
 
Jean-Pierre

---

From: "Evain Jean-Pierre" <[email-masked]>
Date: Fri, 6 Feb 2004 16:33:08 +0100

Rod,
 
If you believe that there is common understanding that this is covered...  I
will not make it a point of principle of having it in.
 
Cheers, JP

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] 
	Sent: vendredi, 6. février 2004 16:29
	To: Evain Jean-Pierre
	Cc: [email-masked]
	Subject: RE: [MMUSIC] TVA comments on the framework and requirements

	Hi Jean-Pierre
	 
	I understand the use case. It is definitely a good idea. The "TV and
Radio Program Delivery" use case covers this to some extent and the
framework clearly enables this. 

	Cheers, Rod.
	 
	-----Original Message-----
	From: ext Evain Jean-Pierre [mailto:[email-masked]]
	Sent: Friday, February 06, 2004 5:20 PM
	To: Walsh Rod (Nokia-NRC/Tampere)
	Cc: [email-masked]
	Subject: RE: [MMUSIC] TVA comments on the framework and requirements

	Rod,
	 
	First of all, thank-you for the clarification on the data model
issue.  I'll be happy to join any off-line work on this subject.  Please let
me know...

	 
	"Trailer advertising and booking allow to notify or publicise an
isolated  (unicast or multicast) event. The IMG system should allow an IMG
client to subscribe to a service listing such notifications, but also allow
for annoucements being pushed to IMG clients.  Although the resolving and
acquisition protocols shall probably be equivalent to those used for
schedules, data delivery and updating might require the management of
smaller fragments/units of information."
	 
	- F2: Now I understand what you were trying to do with referencing
the "system" part 2 of the TVA specification.  I agree, it is probably the
main hook to the other parts of the specification.
	 
	I'll probably be attending GBS in Finland.  What's going on in South
Korea?
	 
	Best regards,
	 
	Jean-Pierre

**********************************************************************
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.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************

---

From: "Evain Jean-Pierre" <[email-masked]>
Date: Fri, 6 Feb 2004 16:20:23 +0100

Rod,
 
First of all, thank-you for the clarification on the data model issue.  I'll
be happy to join any off-line work on this subject.  Please let me know...

 
"Trailer advertising and booking allow to notify or publicise an isolated
(unicast or multicast) event. The IMG system should allow an IMG client to
subscribe to a service listing such notifications, but also allow for
annoucements being pushed to IMG clients.  Although the resolving and
acquisition protocols shall probably be equivalent to those used for
schedules, data delivery and updating might require the management of
smaller fragments/units of information."
 
- F2: Now I understand what you were trying to do with referencing the
"system" part 2 of the TVA specification.  I agree, it is probably the main
hook to the other parts of the specification.

Best regards,
 
Jean-Pierre

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] 
	Sent: vendredi, 6. février 2004 15:25
	To: Evain Jean-Pierre
	Cc: [email-masked]
	Subject: RE: [MMUSIC] TVA comments on the framework and requirements

	Hi Jean-Pierre (et al.)

	On the data model, the purpose of sharing the data model in MMUSIC
is to ensure that this side of the discussion is included in the IMG
Framework considerations, even though MMUSIC will only charter IMG delivery
protocol work (not "application-specific metadata"). My opinion is that
DVB-CMBS and OMA are the prime options for baseline date model
standardisation (although there's a strong "crystal-ball" element to this
prediction as neither have the final solution at this juncture in time). It
is reasonable to exchange ideas and information and develop the data model
openly, but it is necessary to understand the the MMUSIC chairs have made it
absolutely clear that this is the wrong standards WG to standardise it.
	 
	(I'm "announcing" this in MMUSIC so those interested are aware that
there will be non-IETF - and possibly non-all-access - related work and thus
can get involved or ask to be kept up-to-date off-line from MMUSIC)

request).  The same schemes as for broadcasting should apply to multicast.
	 
	So you mean that an IMG metadata could describe the trailer booking
service where details of how to book are described by the IMG metadata? The
IMG system would not be used to do the booking (although possibly to
subscribe to a notification or wait for an announcement indicating that the
booking service is now available). Do you feel that the the inclusion of
this use cases (in the framework) would have a significant impact on the
conclusion of the framework or the IMG metadata delivery protocols? I guess
your text next week should clarify this.
	 
	The primary use cases described for IMGs are multicast/multiparty
session enablers, so although unicast services could easily be described
too, this is not the primary objective of IMG/MMUSIC work.

	F2: I don't see why you shouldn't list them all.  Each of them is
relevant to my comments and to the IMG requirements and framework at one
moment or another.  What would be the problem with a more comprehensive list
of references?
	 
	I have never seen an IETF document with such a reference format
(it's much more ETSI style). It's much more usual to provide the
"boot-strap" reference so that the full documented list can be found.
(Technically, only a single reference to the TVA body of work is needed from
the document body text as we do not discuss exact particulars of each of the
documents). To give an example, for FLUTE [], we could easily give a set of
related references, but these would easily be found by first finding the
FLUTE specification and then following the subsequent references.
	 
	e.g.
	FLUTE ref option 1:
	   [14] T. Paila, "FLUTE - file delivery over unidirectional
transport,"
	   Internet Draft draft-ietf-rmt-flute-07, Internet Engineering Task
	   Force, Dec. 2003.  Work in progress.
	 
	FLUTE ref option 2:
	
	   [14] <FLUTE - File Delivery over Unidirectional Transport,
draft-ietf-rmt-flute-07.txt>

	   [??] <RFC 3450 Asynchronous Layered Coding (ALC) Protocol
Instantiation> 
	   [??] <RFC 3451 Layered Coding Transport (LCT) Building Block> 
	   [??] <RFC 3452 Forward Error Correction (FEC) Building Block> 
	
	   [??] <RFC 3453 The Use of Forward Error Correction (FEC) in
Reliable Multicast> 
	   [??] <Compact Forward Error Correction (FEC) Schemes,
draft-ietf-rmt-bb-fec-supp-compact-01.txt>
	where the <> implies expanding these out to be formal reference
style
	 
	My opinion is to go with the single concise TVA document reference
as it reads easily to IETF-eyes and the remainder of documents are easily
found from this. Does this make sense?

	BTW, DVB-GBS begin work on IP transport week 11 (the week after
IETF-59), if interested I'd be more than happy to discuss these issues there
also (assuming you will not be in South Korea).
	 
	Cheers, Rod.

	-----Original Message-----
	From: ext Evain Jean-Pierre [mailto:[email-masked]]
	Sent: Wednesday, February 04, 2004 5:16 PM
	To: Evain Jean-Pierre; Walsh Rod (Nokia-NRC/Tampere);
[email-masked]

	HI Rod,

	Can you please tell me where the metadata model from Luoma is going
to be discussed if its not in MMUSIC?
	 
	Jean-Pierre

		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]]
On Behalf Of Evain Jean-Pierre
		Sent: vendredi, 30. janvier 2004 18:32
		To: [email-masked]; [email-masked]
		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.

		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: [email-masked]
[mailto:[email-masked]] 
			Sent: mercredi, 28. janvier 2004 15:18
			To: Evain Jean-Pierre; [email-masked]
			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

			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!)

			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.

---

From: [email-masked]
Date: Fri, 6 Feb 2004 16:25:28 +0200

Hi Jean-Pierre (et al.)

 

 

 

e.g.
FLUTE ref option 1:
 
FLUTE ref option 2:

 
Cheers, Rod.

-----Original Message-----
From: ext Evain Jean-Pierre [mailto:[email-masked]]
Sent: Wednesday, February 04, 2004 5:16 PM
To: Evain Jean-Pierre; Walsh Rod (Nokia-NRC/Tampere); [email-masked]
Subject: RE: [MMUSIC] TVA comments on the framework and requirements

HI Rod,

Can you please tell me where the metadata model from Luoma is going to be discussed if its not in MMUSIC?
 
Jean-Pierre

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Evain Jean-Pierre
Sent: vendredi, 30. janvier 2004 18:32
To: [email-masked]; [email-masked]
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.

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: [email-masked] [mailto:[email-masked]] 
Sent: mercredi, 28. janvier 2004 15:18
To: Evain Jean-Pierre; [email-masked]
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:

No changes needed

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!)

Cheers, Rod.