Re: E-E: Re: URL: Comments on TV URI req

Gomer,

I have been following this discussion for a while and now I noticed
that perhaps I should get involved in this.
I have been quite deeply involved in DVB and DAVIC work for the
past few years and I am also one of the original proposers of the DAVIC URL.

I agree with most of the points that Gomer wrote in the beginning of
his message. In my opinion, a URI format that can be used for pointing
to broadcast services should be defined, but we should not try to invent a
meta-URL that covers all the possible protocols including the internet.

>I am happy to comment on the DAVIC URI scheme.

Thanks. Comments are very welcome.

>First, let me ask you a question about DVB/DAVIC, which I have been 
puzzling
>over for some time: As far as I can tell, there is an assumption built into
>the DVB SI protocol and the DAVIC URI scheme that the multiplexing of
>programs into a transport stream is more or less permanent. I.e., during 
the
>broadcast process the transport streams are never demultiplexed, the 
programs
>rearranged, and then new transport stream multiplexes created from them. I
>infer this from the fact that the original network ID and the transport
>stream ID seem to uniquely identify a transport stream. If transport 
streams
>were demultiplexed and remultiplexed, then it would not be clear which
>original network ID or transport stream ID to associate with each of the
>remultiplexed transport streams, since they could contain programs from
>multiple original transport streams, possibly from different original
>networks.

No, there definitely is no assumption built into DVB SI or the DAVIC
URI scheme that services would not get remultiplexed.
On the contrary, DVB SI (and consequently the DAVIC URI) is
specifically designed to cope with remultiplexing and in a way
where the identifiers still remain the same even when remultiplexed.
Namely there is an essential difference in DVB SI between
the _original_ network id and the network id of the current network.
The _original_ network id identifies the original source of the service
and thus these identifiers remain the same regarless of how many
networks the service passes through.

>If this is true, then I am puzzled that the European broadcasters are able 
to
>live with this restriction. In North America such demultiplexing and
>remultiplexing will take place on a regular basis. ...

No, the European broadcasters do not need to live with this type
of a restriction - they just have desinged a system that works even
when this happens.

>The DAVIC scheme appears to have some good points, but I have a number of
>reservations about it:
>
>(1) It is based on numerical identifiers, rather than logical identifiers.
>This makes it extremely difficult for humans to use. (It is common these 
days
>to see magazine ads containing references like "http://www.xyz.com", but
>never references like "http://143.56.98.173".) In particular, it will make 
it
>difficult for TV broadcast content authors to insert hyperlinks based on
>DAVIC URIs.

This is true - however it is only because there is no globally unique naming 

system (yet).

Also, I believe that we need to have both URLs that are probably
system specific and contain system specific identifiers and there
is a separate need for something URN-like that is based on names
that get resolved into URLs in some way.

Referring back to my explanation about the DVB SI,
usually the authors actually know the numeric identifiers because
they remain constant in the DVB system in spite of possible remultiplexing.

>(2) The DAVIC URI uses the program_number as part of the identifier. I 
assume
>that this will typically not be known at the time content is authored.
>Therefore it will be very difficult for TV broadcast content authors to
>insert valid hyperlinks based on DAVIC URIs.

Same as the previous point. Actually in the DVB system that authors
can usually know it.

>(3) If my understanding above about the restriction on
>demultiplexing/remultiplexing in DVB is not correct, then it is not clear
>that the DAVIC URI provides a valid identifier. The same original network 
ID
>and transport stream ID combination could refer to multiple different
>transport streams with totally different contents. Moreover, the
>program_number will be subject to change at the remultiplexing stage, so 
any
>URIs embedded in contents would have to be adjusted then.

As explained before, this problem does not exist in the DVB system.

>(4) The DAVIC URI scheme uses hexadecimal representations for numbers, with
>no leading "0x". This may complicate interoperation of the DAVIC URI scheme
>with any scheme based on logical addresses, since it will not be easy to
>differentiate direct addresses from logical addresses. (In the Internet URI
>schemes a host can be identified by either a domain name or an IP address,
>and it is easy to tell which is which. The DAVIC scheme apparently allows
>direct addresses such as ace.de.) This is probably not too serious, since 
the
>protocol portion of the URI can always be used to make the distinction, but
>it may at times be a nuisance.

The idea is that the protocol part makes that differnce. Also, I think that
the same issue actually exists with IPv6 addresses since they are
written in hexadecimal form also.

>As you probably know, I suggested in my message of Nov 11 that a TV URI
>scheme be based on logical names, with a translation to direct address
>parameters at the receiver, based on translation information contained in 
the
>broadcast streams. In a DVB context, the tv: URI could be translated to a
>dvb: URI. In an ATSC context, the DASE end-to-end team is leaning toward a
>conclusion that we do not need an atsc: direct address URI scheme, since 
the
>direct address parameters are so unstable during the flow from content
>producer to TV receiver that such a scheme would inherently not meet the
>objectives of a URI scheme. Instead, a tv: URI would just be translated to 
a
>direct address data structure in the TV receiver (and we will probably 
define
>such a data structure in the DASE APIs). It's not clear to me whether ntsc:
>and/or pal: direct address URI schemes make sense or not. It is clear that
>logical addresses can be translated to NTSC direct address parameters at 
the
>receiver, just as for ATSC, using translation information embedded in line 
21
>of the VBI. I suspect that the same is true for PAL -- although I am not 
very
>familiar with the PAL broadcast world.

Exactly. I agree that in the www-tv work, we should define a generic
URN-like URI that is based on some kind of names. This can be
then resolved via some mechanism to possibly system specific
URLs.

Regards,
Kimmo Loytana

Received on Wednesday, 25 November 1998 03:32:33 UTC