Re: E-E: Re: URL: Comments on TV URI reqs I-D
From: Warner ten Kate (tenkate@natlab.research.philips.com)
Date: Mon, Nov 23 1998
Message-Id: <3659567C.44D579BD@natlab.research.philips.com>
Date: Mon, 23 Nov 1998 13:35:08 +0100
From: Warner ten Kate <tenkate@natlab.research.philips.com>
To: Gomer Thomas <gomer@lgerca.com>
Cc: www-tv <www-tv@w3.org>, End-to-end <e-e@toocan.philabs.research.philips.com>
Subject: Re: E-E: Re: URL: Comments on TV URI reqs I-D
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.