Re: E-E: Re: URL: Comments on TV URI reqs I-D

Warner,

The proposed requirement that a TV URI must be resolvable under access
conditions of "Internet", "in home/local storage", and "other (future)
networks" does seem to me to be out of scope. Perhaps it is because I do not
understand what you intend by these terms. Let us discuss.

I believe a TV URI scheme should apply to all TV broadcast resources,
including ATSC, DVB, NTSC, and PAL broadcasts. It is a desirable objective
for a TV URI scheme to be applicable also to future broadcast protocols which
may be defined as technology advances, such as protocols based on MPEG-4 or
MPEG-7, but it not wise to make that a current requirement. There is no way
to guarantee that a TV URI scheme defined now will be applicable to all
future broadcast protocols, in the same way that there is no guarantee that
the current http: URI scheme will be applicable to all future versions of
HTTP and IP protocols. However, I believe the approach I outlined in my
message to the WWW-TV interest group on Nov 11 is sufficiently flexible that
it is extremely likely to meet this objective.

I do NOT believe a TV URI scheme should apply to resources on Internet
servers. There are existing URI schemes which handle such resources -- ftp,
http, nntp, wais, etc. To try to include Internet resources within a TV URI
scheme would be redundant and presumptuous.  Again, it is a desirable
objective for a TV URI scheme to be "compatible" with the various Internet
URI schemes, particularly http, in the sense that if copies of a resource are
available on both an Internet server and in a TV broadcast, then the same URI
can be used to refer to both copies. Again, I believe the approach I outlined
in my message of Nov 11 makes it possible to meet this objective in many
situations.

I do NOT believe a TV URI scheme should apply to resources which have been
recorded and stored on local storage. (I am NOT talking about caching.
Presumably we all agree that caching should be transparent, so that whatever
URI refers to an original resource should also refer to a cached copy, when
the URI is resolved in the context of the cache manager. It is up to the
cache manager to assure that. It has nothing to do with URI schemes. I am
talking about a situation where a viewer has recorded something and
consciously saved it in local storage.) There is already a well-known "file:"
URI scheme for local disk storage. We don't need to reinvent it. Presumably
some group whose primary focus is home networks will soon develop a URI
scheme for home networks. We don't need to take on that huge task.

It is certainly a desirable objective that internal references within a
broadcast stream should be still valid when the stream is recorded and played
back. It's not clear whether this can be guaranteed in all circumstances. As
you presumably know, if you move a collection of interlinked pages from a
remote web server to local storage, the internal references may or may not
still be valid. It depends on how the author has handled certain things. I
believe the approach I outlined in my message of Nov 11 would meet this
objective, as long as the entire transport stream was recorded intact, rather
than just recording the content stream(s) of interest.

I do not believe a TV URI scheme should apply to "other (future) networks"
(which I interpreted to include all types of networks, not just TV broadcast
networks). This is clearly far outside the scope.

I'm sorry you interpreted my examples as ridiculing the requirement. The
point is that the requirement as written does in fact include video tapes
stored on bookshelves and resources on networks such as DECnet, IPX/SPX,
FireWire, etc. If this was not your intent, then a much clearer statement of
the requirement is needed.

The main goal I was referring to is: "A new URL scheme is needed to address
content that is broadcast in a TV channel."

The way to get interoperability between Internet and TV broadcast
environments is to ensure that if a system has access to both the Internet
and to TV broadcasts, then it should be able to access Internet resources
which are referenced in TV broadcasts, and it should be able to access TV
broadcast resources which are referenced on Internet sites. We already know
that any system connected to the Internet can access an Internet resource
referenced by a valid Internet URI for that resource, regardless of where it
obtained the URI. We don't need to reinvent that. Our task is to make sure
that any system connected to a TV broadcast can access a TV broadcast
resource referenced by a valid TV URI for that resource, regardless of where
it obtained the URI. Period.

I am happy to comment on the DAVIC URI scheme.

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.

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. Local affililiate stations
of national broadcast chains (FOX, ABC, etc.) will often take the national
feed, demultiplex it, substitute some local programming and/or local ads, and
remultiplex the stream for broadcast. Cable companies will demultiplex
terrestrial broadcasts, combine them, and remultiplex them before
transmitting them over their cables, to take advantage of the fact that they
have twice as much digital bandwidth in a single analog channel as the
terrestrial broadcasters do.

Can you clarify this issue for me?

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.

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

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

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

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.

I am looking forward to hearing your views on these issues. I hope we can
come to a consensus soon.


Warner ten Kate wrote:

> Gomer Thomas wrote:
> >
> > I worry that we will come up with an excellent scheme which meets all
> > needs for DTV, but objections will be raised that it does not meet this
> > requirement,
>
> So, maybe it is not that excellent :) It might be excellent
> with respect to the requirements you are concerned about.
>
> > because it does not properly allow identification of
> > resources recorded on a video tape and stored on a bookshelf, or
> > resources on IPX/SPX or SNA or DECnet networks, or resources on a
> > proprietary back channel network used by some cable operator.
>
> Please, don't ridicule the requirement. It gives me the impression
> you didn't get its meaning and purpose. If the requirement is not
> clear we should discuss that and try to better formulate it.
>
> If I understand you correctly and trying to formulate your argument
> against the requirement, it is that you find the requirement outside
> our scope. Correct?
>
> I argue it is inside our scope, but meeting it does not have
> the first priority.
>
> Maybe we didn't define our scope that precisely, and we all
> assume our own vision is the correct one. So, let's check that.
>
> First, I don't think the scope of this TV-Web IG coincides
> with that of ATSC's. I say this, because I feel some people
> seem to adhere that opinion. Before I create a confusion on this:
> I am not stating ATSC is excluded, or something. ATSC is one of
> the core members of environments we are discussing.
>
> > We cannot afford to get bogged down for
> > months or years trying to figure out how to cope also with all kinds of
> > other environments which are only tangentially related to the main
> > goal.
> >
>
> What main goal are you referring to? ATSC's ?
>
> >From our TV-Web home page: "A new URL scheme is needed to address
> content that is broadcast in a TV channel."
>
> The (8th) requirement we are discussing states from which position
> that content should be addressable. From ATSC perspective it
> sufficies to only access within ATSC. But in that case, I would say
> that ATSC can define any scheme, including non-URI conformant ones,
> and I fail to see what interest the TV-Web IG should have in that case.
>
> The reason of this TV-Web IG is to get interoperability between
> Web and TV environments. When you want such interoperability,
> this 8th requirement pops up.
>
> Storing TV Broadcast content after transmission is not something
> I find tangentially related. The Internet is neither. After all,
> I thought that was the reason to instantiate this Interest Group.
> It is also a driving reason why we are thinking of using URI in
> TV Broadcast at all.
>
> --
>
> I said before and I like to repeat
>
> > > the foremost reason to use URIs in TV Broadcast is to obtain
> > > interoperability across networks.
>
> So, I consider the 8th requirement a number one requirement, not
> something to mention at the end of the document. The most important
> environments to observe are
> - TV Broadcast
> - local storage
> - Internet
>
> In the section defining TV Broadcast I collected digital and analog
> networks together, by naming some systems (in my revision of the draft
> I will look to make that more explicit).
>
> Those TV systems (PAL, NTSC, MPEG) are also used on recording
> devices; so to me it seems pretty usuful to keep our URI scheme
> working, after recording.
>
> Note that the requirement states that the URI should be resolvable,
> not that it should resolve into the same resource or resource location.
>
> --
>
> When I said:
>
> > > I think the requirement stays, but I agree we should solve for
> > > the TV Broadcast first.
>
> I meant that it is fine to look at the broadcast channel first,
> but when we have a solution there, we should go back to this
> (8th) requirement and see how it fits in. If it doesn't fit we have
> to see what the options are. One could be that we leave that
> drawback in the designed URI, that is, based on good arguments
> explaining why it is hard or impractical to redesign the URI.
> (the requirement uses the wording 'should', not 'must' - as promised
> I will explain that wording in the next version; 'should' means
> something like 'not absolutely required').
>
> However, I severely disagree to drop the requirement, just to make
> live easier (for this moment). I agree to pay less attention
> to the requirement at this stage of design exploration.
>
> --
>
> A possible scenario could be that we specify a URN scheme,
> which, in case of broadcast access, resolves into the URI
> we are going to specify first.
>
> --
>
> >
> > We have an urgent need to get a URI scheme standardized which meets the
> > needs of DTV broadcasting.
>
> I know of only one scheme existing, which is the DAVIC URI scheme.
> DAVIC also specifies a DVB specific scheme, which conforms
> to that generic scheme. As said before, the scheme is in use.
> To me that implies it meets some group's needs of DTV broadcasting.
>
> Can you comment on the DAVIC scheme:
> - how it satisfies your needs, you are referring to above.
> - where you are forced to deviate from the DVB URL
>   for use in an ATSC environment.
>
> Warner.



--
Gomer Thomas
LGERCA, Inc.
40 Washington Road
Princeton Junction, NJ 08550
phone: 609-716-3513
fax: 609-716-3503

Received on Tuesday, 24 November 1998 11:29:33 UTC