Message-ID: <3651B308.B83CB8ED@lgerca.com> Date: Tue, 17 Nov 1998 12:31:52 -0500 From: Gomer Thomas <firstname.lastname@example.org> To: www-tv <email@example.com>, End-to-end <firstname.lastname@example.org> Subject: URL: Comments on TV URI reqs I-D Warner, Some clarifications/modifications which I think are needed to the Internet-Draft on TV URI scheme requirements: (1) The words "must" and "should" are being used with slightly different meanings. We should state explicitly what those meanings are. (2) We should number the requirements for easy reference, rather than just have a bullet list. (3) The second requirement refers to "components" and "fragments" of a program. We need to define what those terms mean. In my original draft I used the word "component" to refer essentially to an elementary stream in a DTV broadcast. It could also be used to refer to the video track, audio track, or "extended data track" (VBI line 21 encoded data) in an NTSC broadcast, I suppose. I'm not sure what you mean by "fragments". Is that a time segment of an event? -- for example an ad segment, or the first quarter of a basketball game? If that is what you mean, then the statement that fragments are outside the scope will be somewhat controversial. In particular, some members of DASE think that one should be able to reference a commercial within an event, since advertisers may in some circumstances want to publicize and point to the appearance of an ad -- for example, the famous Apple Computer ad during the SuperBowl a few years ago. My initial reaction was serious skepticism about the utility and feasibility of doing this. However, on thinking it over, I can see some value in it, and maybe it not very difficult. See my comments in (4) below. (4) In the fourth requirement we need to specify what kind of time granularity is intended. In my mind there are three possible levels of granularity: (A) event, (B) fragment (as described above), and (C) tiny, where "tiny" refers to the precise time(s) at which a resource such as an MPEG-2 frame or a JPEG file or an HTML page is being broadcast. We certainly want a TV URI to support time granularity at the event level -- although in an ATSC context at least we may need to add the event_id to the channel information in the VCT so that it is possible to determine what event is currently showing without relying on the EITs being kept 100% up to date in the face of schedule shifts, etc. I believe "fragments" should be handled by "URI References" as described in section 4 of RFC 2396. I.e., they are not within the scope of the URI proper, but they are accommodated by the overall "URI reference" syntax. In the case of a TV URI, the fragment syntax should support the use of either a byte offset (as would be appropriate when the URI references an HTML page) or a time offset (as would be appropriate when the URI references an event). By allowing the time offset to be either a number or a symbol, as is done with byte offsets, any arbitrary segment can be referenced, even if the precise time offset is not known (as would be the case with an ad in a sports contest, or the half-time show in a football game). All that is needed is a way to insert a segment name into the broadcast stream, for example by defining a new optional Segment Name descriptor to go in the inner descriptor loop of the VCT (in an ATSC context). This descriptor would appear only during the segment. We should definitely make it clear that "tiny" is outside the scope of the URI. (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. (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. 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?
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. To the extent there is concern with runtime resolution of references between components of an MPEG-2 transport stream which has been stored on a local file system, the file system is no longer relevant once the stream starts playing. What you now have is a transport stream coming into a receiver. It looks like a broadcast, although possibly with a considerable time shift, and typically coming from a different physical channel than the one it originally came from. This is somewhat comparable to taking the entire file system from one web server and moving it to another web server. Whether the cross links still work or not depends on whether the authors consistently used relative URIs. It turns out that the URI translation mechanism I proposed last week probably does deal with this situation correctly, as long as the entire transport stream has been recorded, but I don't think this should be a requirement. To the extent there is concern with a situation where there are cross links between a live broadcast and a stored event, or between two stored events, or between a web server and a stored event, there is no magic. If one moves a bunch of files from one web server to another, this will "break" references to these files from other files on the web server which have not been moved. The URI translation mechanism I proposed last week probably does deal with this situation correctly when the stored stream/s is/are played into a DTV receiver, but I don't think this should be a requirement. (7) We need to clarify the "interoperate" statement in the tenth requirement. I gather the intent is that typically a receiver should be able to interpret an http: URI as a tv: URI and correctly access the resource if the resource is in fact available in the broadcast streams coming to that receiver. If that is the intent, we need to say so more clearly. (8) There is a minor typo in the Acknowledgements section. The word "heighly" should be "highly". -- Gomer Thomas LGERCA, Inc. 40 Washington Road Princeton Junction, NJ 08550 phone: 609-716-3513 fax: 609-716-3503