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

Gomer Thomas wrote:
> 
> (1) The words "must" and "should" are being used with slightly
> different meanings. We should state explicitly what those
> meanings are.

Agree. will do.
There is an RFC specifying that.


> 
> (2) We should number the requirements for easy reference, rather
> than just have a bullet list.

OK. will do.


> 
> (3) The second requirement refers to "components" and "fragments"
> of a program. We need to define what those terms mean. 

Agree. will correct.
(we indeed have a confusion here.)


> (4) In the fourth requirement we need to specify what kind of
> time granularity is intended. 

Agree. I was thinking on that too.


> (5) We need to clarify the seventh requirement, on interpreting a
> URI "from any of the following locations". The DASE end-to-end
> team was more or less uniformly confused about just what that
> meant. Part of the problem may be that the term "TV broadcast
> network" seems to have a different meaning in North America than
> in Europe. Here it is usually interpreted to mean something like
> NBC or PBS, consisting of a central organization and a number of
> local affiliate stations. In Europe I gather it is usually
> interpreted to mean the entire collection of terrestrial DVB
> broadcasters, or the entire feed from a particular cable or
> satellite operator. I recommend at least giving an example,
> perhaps using wording something like that in my original draft
> requirements.

Good point. 
Altough I recognize the US interpretation, I didn't realize.
Your EU interpretation is OK.


> 
> (6) Concerning the eighth requirement: As I indicated in an
> earlier email message, I think we should restrict ourselves to a
> TV (or DTV) URI scheme which references resources in TV (or DTV)
> broadcasts. There are already other URI schemes for referencing
> resources in the Internet and in local storage. Referencing
> resources in a home network or in future networks is likely to
> turn into a can of worms, and there is no real reason why that
> should be within the scope of a TV URI scheme.

I think the requirement stays, but I agree we should solve for 
the TV Broadcast first. I like to maintain the requirement as 
the foremost reason to use URIs in TV Broadcast is to obtain 
interoperability across networks.

What URI scheme referencing to local storage are you thinking of?
"file:" or others?
I am not sure whether the file: URL will be useful for use
on local storage devices like VCRs, storing a DTV transport 
stream. Maybe we need a requirement here ?


> 
> To the extent there is concern with identifying a specific
> resource within an MPEG-2 transport stream when the transport
> stream has been recorded on a local storage system, I think the
> appropriate URI would be something like file://x.y.z?<dtv uri>,
> where file://x.y.z gets you to the file on the storage system
> which contains the transport stream. This is much the same
> approach you would have to take if you took a collection of files
> from a web server, packaged them up into a ZIP file, and stored
> the ZIP file in a storage system.

This suggests there is no problem in meeting the requirement.
Another reason


> (7) We need to clarify the "interoperate" statement in the tenth
> requirement. 

OK. will try to improve.


Thanks,
I'll come back when I have corrected with these comments,
and others as they may appear on the list.
(This may take some days due to other obligations.)


Warner.

Received on Wednesday, 18 November 1998 12:29:00 UTC