Message-Id: <3659567C.44D579BD@natlab.research.philips.com> Date: Mon, 23 Nov 1998 13:35:08 +0100 From: Warner ten Kate <email@example.com> To: Gomer Thomas <firstname.lastname@example.org> Cc: www-tv <email@example.com>, End-to-end <firstname.lastname@example.org> 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.