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.

Received on Monday, 23 November 1998 07:35:25 UTC