Message-Id: <367657CD.2F462B90@natlab.research.philips.com> Date: Tue, 15 Dec 1998 13:36:29 +0100 From: Warner ten Kate <email@example.com> To: firstname.lastname@example.org Cc: email@example.com Subject: Re: submission Craig A. Finseth wrote: > > The following two documents are the individual submissions of Gomer > Thomas and myself to the W3C process. > > While written in Internet-Draft form, they have not yet been submitted > to the Internet-Draft registratar (that process is happening in > parallel). What do you mean "is happening in parallel" ? Are those also individual submissions ? I assume in that case the text around "tvweb" references will be corrected (like "This is work in progress by the W3C TV-Web Interest Group ", etc.). > > The documents have also been submitted to the ATSC T3/S17 DASE working > group. I appreciate your efforts to move forward and get at a useful solution. Still, I think we need some work to do. Below I'll comment on the general UR* scheme you propose. -- I think it would have been better when the introduction and example sections had been skipped. Let's concentrate on the scheme itself. Once having agreement on that we can start writing a document like this. I therefore restrict my comments to the main part. Also, the part on parsing the UR* I leave out of discussion. -- On first reading I understood your "general scheme" in the same sense as my "general scheme" I proposed earlier to the list: <protocol>://<service>[;<time-period>][/<dir1>/.../<dirN>/[<file>]] [http://lists.w3.org/Archives/Public/www-tv/1998OctDec/0170.html] I still propose that scheme for consideration by the list. You propose the scheme btv://<authority><path>?<query> My meaning of "general scheme" is: A framework to which all URL instantiations must conform. The scheme itself is not an instantiation. Your meaning (if I am correct) of "general scheme": A UR* instantiation working in all environments (ATSC, DVB, analog, Internet). It is both a URN and a URL. This latter aspect (both URN and URL) is probably a source of misunderstanding. From the earlier discussion with you (and Gomer) whether we are defining URLs or URIs I understood ATSC had an urgent need to specify URLs. So, I thought we were focussing on that problem. -- As ATSC and DVB use (slightly) different transmission "protocols", I don't expect we will be able to define one URL which will work in both environments, irrespective whether that URL can also be considered a URN. And actually, I think DSM-CC transported content induces the need for another URL (access-scheme), not to mention plain old analog transmission. That's why I think in your proposal the first field "btv" should be "<btv>", having instantiations "atsc", "dvb", "tv", "dsmcc". The second field (after the double slash //) refers the "host" at which the resource is located. That can be a name or a direct address. As in conventional URLs it can be a domain name or an IP-address. -- You claim your scheme works for all environments and is both a URN and a URL. Let's verify we share the same picture here, before further discussing the proposal. Do we understand the same by URI, URL and URN (and which of course, should be the understanding as defined by the IETF URI WGs)? My understanding: - a URL is a URI - a URN is a URI - a URN identifies a resource by a unique and persistent name - a URL identifies a resource by its location (actually, it defines a location, which implies the resource's identification). The ultimate form of location information is the address. (So, the content may change while the URL stays unaltered.) - Given a URN you need a naming service to get the URL(s) for retrieving the resource. I do agree (and actually have been proposing to the list) that we need a URN scheme in order to have a URI which allows world-wide and access-scheme independent identification of (TV Broadcast) content. That indeed implies we need to specify a naming service to obtain location information for retrieving the content. When operating within the DVB environment there is no need for this indirection and applications can use (and will use) the URL scheme as existing. Note, that DVB is already in operation and it is hard chance that at this stage a naming service, like the tables you propose, can be added mandatory to the system. So, I think we also need URL schemes. The URL points directly to the content, or better the content's address. -- What I tried to accomplish with my general scheme, is to specify the largest common denominator to which all URL schemes must (and can) conform. Hopefully this will ease interoperation when content is exchanged across networks (eg, possible hierarchy can stay unaltered). Knowing how the DVB instantiation looks like, I was hoping you would be able to expand this general scheme further encompassing ATSC access. -- It is not yet clear to me how the URL looks like in your proposed scheme, I mean how your scheme contains the address information. It is maybe helpful when you split your scheme in a URN view and a URL view, such that it gets more explicit how both views are combined into one syntax. -- Wrt. URN definition, I like to mention that there is an activity in DAVIC working on the same issue (called "TV anytime"). We need to bring both proposals together. For one, I think you propose the use of the "dtv:" string as NID. As far as I am up to date, in TV Anytime the NSS is proposed to be: <broadcaster>:<number> <broadcaster> specifies the broadcaster who owns (and archives !) the content, the <number> is maintained by the broadcaster (and probably maps to his archive system). I understood there is considerable interest from broadcasters to this scheme. Somehow, you propose the NSS to be //<authority>/<path>?<query> It is not clear to me how things fit together. //<authority> could map with <broadcaster> above, but the colon versus slash is more difficult (as the URN scheme uses the colon as namespace separator). Further, we need to provide more explanation on the naming service. The URN group is working on RDS. How does that fit with the tables you propose? Another issue considers the hierarchy. I know there has been considerable discussion on this at the URN mailing list. Hierarchy doesn't seem something easy when talking URNs. -- One thing I am puzzling about in your approach is that time-related information is missing, see requirement 4. Referencing a channel is not sufficient; it must be possible to reference a program in that channel (not only "BBC" but also "BBC 8 o'clock news"). This resource hierarchy in temporal direction is orthogonal to the path hierarchy in content direction (show me the audio or the video, etc.) and therefore we cannot use the common hierarchy of the <path> part of the URL scheme. Gomer has proposed earlier an approach where the "host" domain name gets extended with a subdomain mapping to the event_id: Event.Service.Transport where Event, Service, and Transport may be dotted themselves. A table is needed to separate the semantic fields (hope I got this right, Gomer). Although this is doable, and aside from the induced need for a table to parse the string on dot delimiting, I think it is better to have an explicit syntax means to distinguish Event from the remainder, ie. to have another delimiter than the dot. Also, Event associates with a temporal dimension, while Service and Transport associate with the transport mechanism. Consider the following view: A URN is a persistent resource name. So, the program is the highest level of naming: a channel is not persistent in the sense that each time a client visits the resource a different piece of content is returned (although URL related and therefore not completely a propoer comparison, visiting a directory at a server returns the directory listing or the index file, but always the same content). I agree that adding temporal information to a URN is contradicting the persistency characteristic. So, we need something else to *name* the program (after recording the same name must be applicable). However, when locating the content it is quite useful to provide the temporal information on availability of the content. This temporally availability is a predominant characteristic of TV Broadcast. It implies that information like event_id needs to be part of the URL string. -- A final question concerns the <query> field in your proposal. Can you elaborate on that? - What is the semantics when considered your scheme as a URN (= unique, persistent name) ? - How would the query be used in case of accessing a broadcast transport stream (the "host" cannot process the query) ? -- In conclusion, I think we need a URN scheme in addition to URL schemes. I don't see how both could be unified; maybe I understand when you show that more explicitly in your proposal. Recall that DVB is not likely to adopt the naming service to its system. In addition, I don't think it is without reason that at IETF URNs and URLs get separate attention. I agree, it is a pitty that a URL like "dvb://...." would not work in an ATSC environment, but similarly "http://bbc.com/jamesbond.mpg" doesn't carry location information to watch "diamonds or whatever", it is likely intended to go to (locate) the bbc web site and fetch a file jamesbond.mpg. We are dealing with different access protocols. I think URL is phase 1, the URN is phase 2. The URNs are persistent and resolve into URLs. The URL may support both names and addresses in the <service> field part. -- Things I have omitted in my proposal but need be addressed are - more detail in semantics (to be done through discussions) - specification of the character set - based on RFC 2396 - reserved characters - case sensitive - name string versus (hex) numeral form - parsing scheme of the URL (conform RFC 2396) - relative TV Broadcast URL scheme - some examples Warner.