RE: EXT_TIME: a new HE for timing information in LCT

Hello Vincent and the rest of RMT WG,

Analyzing the current 3GPP, DVB and OMA specifications making use of
ALC/LCT, I found that the change you proposed does not break anything.
That is, the following specifications do not make use of either SCT or
ERT.

DVB Document A099, "IP Datacast over DVB-H: Electronic Service Guide
(ESG)"
 *
http://www.dvb-h-online.org/PDF/a099.tm3348r2.cbms1199r14.IPDC_ESG.pdf

DVB Document A101, "IP Datacast over DVB-H: Content Delivery Protocols
(CDP)"
 *
http://www.dvb-h-online.org/PDF/a101.tm3350r3.cbms1167r12.IPDC_Content_D
elivery_Protocols.pdf

Open Mobile Alliance, "Service Guide for Mobile Broadcast Services -
Draft Version 1.0"
 *
http://member.openmobilealliance.org/ftp/public_documents/bac/BCAST/Perm
anent_documents/OMA-TS-BCAST_Service-Guide-V1_0_0-20060106-D.zip

Open Mobile Alliance, "File Distribution and Stream Distribution - Draft
Version 1.0"
 *
http://member.openmobilealliance.org/ftp/public_documents/bac/BCAST/Perm
anent_documents/OMA-TS-BCAST-Distribution-V1_0_0-20060106-D.zip


The only specification I found using SCT and ERT is:

3GPP TS 26.346 V6.3.0 (2005-12), "3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects; Multimedia
Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 6)"
 * http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26346-630.zip

In that spec:
 - The use of ERT is truly optional for both FLUTE client and FLUTE
server.
 - The use of SCT is optional for FLUTE server but mandatory for FLUTE
client.

However, the proposed change (i.e. EXT_TIME) does not remove the
LCT-inherent capability to signal SCT. It just does it in more generic
way. Therefore, I think it is just a matter of a very simple spec
maintenance issue to update the 3GPP spec TS 26.346 to refer to EXT_TIME
carrying SCT rather than using SCT field.

I very much support Vincent's initiative to generalize the time-related
signaling in LCT header. To me, this simplifies the design as well as
makes LCT more flexible and extensible.


Regards,
 Toni
 

>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On 
>Behalf Of ext Vincent Roca
>Sent: 31 January, 2006 17:18
>To: [email protected]
>Subject: [Rmt] EXT_TIME: a new HE for timing information in LCT
>
>Dear Mark et al.
>
>Here is the follow-up of a discussion we had in December on 
>the possibility of defining a new header extension for LCT to 
>carry several kinds of timing information.
>Cheers,
>
>    Vincent / Toni / Rod
>
>