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

["Evain Jean-Pierre" <[e-mail]>]

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

	-----Original Message-----
	From: [e-mail] [mailto:[e-mail]] 
	Sent: vendredi, 6. février 2004 15:25
	To: Evain Jean-Pierre
	Cc: [e-mail]
	Subject: RE: [MMUSIC] TVA comments on the framework and requirements
	
	
	Hi Jean-Pierre (et al.)
	 
	 
	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.
	 
	 
	-----Original Message-----
	From: ext Evain Jean-Pierre [mailto:[e-mail]]
	Sent: Wednesday, February 04, 2004 5:16 PM
	To: Evain Jean-Pierre; Walsh Rod (Nokia-NRC/Tampere);
[e-mail]
	Subject: RE: [MMUSIC] TVA comments on the framework and requirements
	
	
	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: [e-mail] [mailto:[e-mail]]
On Behalf Of Evain Jean-Pierre
		Sent: vendredi, 30. janvier 2004 18:32
		To: [e-mail]; [e-mail]
		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: [e-mail]
[mailto:[e-mail]] 
			Sent: mercredi, 28. janvier 2004 15:18
			To: Evain Jean-Pierre; [e-mail]
			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.
	
	
**********************************************************************
	
	



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

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