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 [1]", 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.

Received on Tuesday, 15 December 1998 07:37:17 UTC