Message-Id: <36528BBB.B4C50EC3@natlab.research.philips.com> Date: Wed, 18 Nov 1998 09:56:27 +0100 From: Warner ten Kate <firstname.lastname@example.org> To: email@example.com Cc: firstname.lastname@example.org, email@example.com Subject: Re: I-D submission "Requirements on TV Broadcast URIs" Craig A. Finseth wrote: > > ... > o The URI scheme must be compatible with solutions already adopted > in standardisation bodies such as ATSC, DVB, and DAVIC. > ... > > I see no reason to include this point. None of the ATSC, DVB, or > DAVIC proposed schemes meet the other requirements. Thus, requiring > compatability with something that does not meet the requirements is > confusing at best. If we have contradicting requirements, we need to balance somehow. I don't agree the solution is by just kicking out a requirement. You could argue to remove requiring compatibility with the ATSC URI scheme, because it is a not yet approved scheme. On the contrary, my impression is that DASE and our efforts are pretty aligned, such that we can expect the same URI scheme will get defined. Is this correct ? It would mean that this requirement gets fulfilled in this respect. The purpose of this requirement is to acknowledge that there are other bodies also defining URI schemes. Somehow, we need to align. Ignoring is not the way achieving that. It seems people are not aware that the DAVIC URI scheme is something existing and approved. The scheme is being implemented in the world. I don't think we can simply ignore that, at least when trying to get something uniform and standardized. > > o The URI scheme should support relative referencing such that > a TV-program with all its associated resources can be referenced > against a common base, which is the TV Broadcast URI of that > aggregate. > > I would put this in the category of "nice, but if it doesn't work out, > not a big deal." The use of "should" should imply that. I will insert some text stating that. > > 5. Exceptions in TV Broadcast URIs > > TV Broadcast differs from the conventional Internet in several ways. > The TV Broadcast URI scheme is affected by that in the following aspects: > > o The host is not necessarily a server identifyable through an > identifiable corrected. thanks. > IP-address. For instance, the 'host' is a transport stream. > Well, the "host" is the _source_ of a transport stream... This is about modeling. I like to make clear that the usual Internet model of hosts, routers and subnets doesn't apply perfectly to the TV Broadcast environment. Correct me if I am wrong, but I understand a host as a machine hosting the server or client transport application. The part after the double slash in the URI refers the naming authority. In usual Internet that is (mostly) the server host. In broadcast, the client does not interact with the machine at the uplink side, but interacts with the data as made available in the broadcast transport stream. In our proposals, we are thinking of using the Transport Stream ID to identify our resources. When the broadcast client starts a truly interactive session, i.e. the content he requests gets scheduled and transmitted because of that request, then we return to the Internet model where the naming authority will be a machine again. I think this is a fundamental difference in the model and I like to make that explicit. I think my wording does do that, by associating 'host' with 'transport'. If you have a better wording, please suggest. Btw. In case of multicast, one connects to a multicast address. Which machine is the host of that address ? > ... > > Craig Warner.