Re: submission

   > 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 ? 

These documents (and, in particular, the first one) are written in the
form of Internet-Drafts.  In this forum, people who see documents that
appear to be Internet-Drafts have a very reasonable expectation that
the documents actually be Internet-Drafts (in this case, as an
individual submission).  I was simply cautioning people that (1) I was
aware of their expectations and (2) that they are not met in this case.

   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.).

Will do.

	...
   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>]]

From your words, can I assume that you no longer make this incorrect
assumption?

   [http://lists.w3.org/Archives/Public/www-tv/1998OctDec/0170.html]

   I still propose that scheme for consideration by the list.

...and you are welcome to do so.  I assume that this forum welcomes
all useful suggestions.

   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.

The main problem that I am addressing is to define a scheme such that
an application running in a "tv set-like box" can identify all of its
resources.  This is the heart of what the work at ATSC is about.

I expect that if we can address this reasonably-hard-but-by-no-means-
impossible problem in a satisfactory manner, the "simple" cases of
other needs will also be met in an adequate manner.  This expectation
is an assumption and not a statement of fact.

   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.

We only need to define multiple schemes if we introduce
transport-level specific information into the UR*s.  This is something
that I propose avoiding.

In particular, I consider it a criterion that one be able to create a
commercial -- with all URL bindings -- and tranmit that application
over ATSC, DVB, etc. without having to change UR* references (you
will, of course, have to update the transport-specific information
that binds the UR*s to the actual data in the transport, but that
updating does not change the actual UR*s).

I believe that this criterion is implicit in the agreed-upon
requirements document.


   That's why I think in your proposal the first field "btv" should 
   be "<btv>", having instantiations "atsc", "dvb", "tv", "dsmcc".

You are welcome to create a different proposal which has the
characteristics that you like, but please do not confuse ours.  This
is NOT how ours works: the propsed literal strings is "btv:".  The
single scheme outlined in the proposal meets all requirements.  A
particular receiver may, of course, implement whatever other schemes
it likes. However, no other schemes are required in order to achieve
the goal.

   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.

Again, please do not spread confusion about our proposal.  In the
specification, it clearly states that the numeric form is not allowed.

We chose the DNS as the source of the globally-unique naming authority
because it is the only one that meets a reasonable set of critiera for
that authority:

- it already exists and is in use
- it can scale to the ultimate millions to tens of millions of creators
- people know how to use it
- fees are relatively inexpensive
- identifiers can be freely traded
- you can use fake names/aliases (important to hide commercials)
- existing authoring tools know how to use it.

   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
OK

   - a URN is a URI
OK

   - a URN identifies a resource by a unique and persistent name
OK -- this is a key aspect of our propasal

   - 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.)

Well, this is somewhat of a twist from RFC 2396.  In any event, since
our approach is based on the concept of a tagged architecture /
content addressable memory, it just happens that the URI string
also serves as a URN scheme.  This is admittedly an unusal case.

   - Given a URN you need a naming service to get the URL(s) for 
     retrieving the resource.
This requirement does not appear anywhere in RFC 2396 that I can find.
We claim to meet the requirements as set forth in 2396.

   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.
Again, there is no such implication.

   When operating within the DVB environment there is no need for 
   this indirection and applications can use (and will use) the 

We are assuming that the scheme must cross transports.  Thus, the key
assumption here is false.

   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.

People are smart: they can think of something.

   So, I think we also need URL schemes. The URL points directly 
   to the content, or better the content's address.

Again, any scheme that has transport-specific information fails
to meet the requirements.


   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.

Since your scheme does not meet the stated requirements, it may
not serve as the best of starting platforms.

   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.

The specification does not: the details of the UR* to address bindings
are carried differently in each transport.  Assuming that we agree on
the overall approach, a set of people will develop the set of
per-transport bindings documents.  We have included an example such
document for ATSC.

This structure mirrors the definition of IP: the core RFCs don't
mention any tranport information and, in fact, IP is carried
differently over Ethernet than it is over SLIP.  To actually build an
IP implementation, you have to read the IP-level RFCs as well as the
RFCs that define how to carry it on the transports that you're
building for.

   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.

If this will help people understand, we can do this.

   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

By "you" do you mean the "TV anytime" people?  I'm confused.

   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).

This is interesting, but it appears off-topic.  What are you getting
at?  Are you asking what we're doing, telling us what someone else is
doing, or a combination?  I'm confused.

   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?

We have a single, unified identifer space.

   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.

We don't make any statements regarding hierarchy.  Content creators
are free to assign identifiers in a hierarchical manner (and we expect
that they will), but that is opaque to the scheme itself.

   --

   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.

If you look at the ATSC instantiation, you can reference time
indirectly by attaching the descriptor to the Event Information Table
entry.

   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.

Gomer is free to correct me, but I believe that he abandoned this
approach because it does not meet the requirements.

   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).

A channel is a persistent resource in the same fashion a a river is,
and I'm sure you will get quite an argument if you go to Paris and
claim that the Seine can't have a name because the water changes...

In this context, a resource is whatever an application has a need to
name.  We list some in the specification, but they can certainly
include multiplexes, channels, events (in a variety of combinations),
applications, and data.

   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.

You have it backwards.  The name is the top level.  This name can be
bound to an event_id, from which it can determine the temporal
information.

   --

   A final question concerns the <query> field in your proposal.
   Can you elaborate on that?

We permit it. As with any <query>, what you can put there is a private
matter between the client and server (but everyone can assume RFC 2396
syntax).  Since you can name applications, it is perfectly reasonable
to send them queries.  Someone might want to define query semantics
for other resources, but we're not getting into that area.

   - What is the semantics when considered your scheme as 
     a URN (= unique, persistent name) ?

See above.

   - How would the query be used in case of accessing a broadcast 
     transport stream (the "host" cannot process the query) ?

See above.

   In conclusion, I think we need a URN scheme in addition to URL 
	...

Commentary: no response required.

Craig

Received on Tuesday, 15 December 1998 10:25:06 UTC