Re: AW: URL: Background and Requirements

Simon Gibbs wrote:
> 
> Little work has been done on URLs for home networking, but
> there a number of proposals for "broadcast URLs". See attached.
> 
> Simon
> 

I also tried to summarize existing TV URL schemes. I checked 
with your overview and that posted earlier by Petr Peterka.
I incorporated those which I thought were relevant.
<http://lists.w3.org/Archives/Public/www-tv/1998OctDec/0009.html>
<http://lists.w3.org/Archives/Public/www-tv/1998OctDec/0091.html>

Below I summarize and discuss them.

Warner.

--

I think the following communities have specified or 
are specifying something:

- DAVIC
- DVB
- ATSC
- WebTV, ATVEF
- DAVIC TV-Anytime
- MPEG4

I think the DAVIC scheme is the only one in this area which has 
been approved by an open, international standardization body.

I think the above communities specified the URL schemes as 
given below. Please, correct, improve, and comment. I would 
like if we manage to shrink this list, rather than extend it.


+++++++++++++
   DAVIC    :
+++++++++++++

 DAVIC specifies a general format and a numerical format [DAVIC-URL].

 The general format specifies a syntax, which is
 
(1)   <protocol>://<service>[/<dir1>/.../<dirN>/<file>]
 
 <protocol> identifies that it concerns a broadcast service.
 <service> identifies a particular service in the broadcast 
 network. A popular name for service would be TV-channel, 
 e.g. "BBC 1". 
 <dirX> to <file> identify a resource in the service. This 
 is an optional part of the URL.

 The numerical format specifies a resource in a DVB compliant 
 network. It is specified as
 
(2)   dvb://<original_network_id>.<transport_stream_id>[.<service_id>
            [.<component_tag>][;<event_id>]][/<...>]
 
 <original_network_id>, <transport_stream_id>, and <service_id> 
 are defined in the DVB-SI specification. They identify a 
 service in a DVB/DAVIC broadcast network globally uniquely.
 <event_id> is also defined in DVB-SI and identifies an event 
 within a service. A popular name for an event would be 
 program, e.g. "8 o'clock news".
 The <component_tag> is also defined in DVB-SI and is part 
 of the so-called stream_identifier_descriptor(). That 
 descriptor is contained in the MPEG-2 PSI Program Map Table 
 (PMT) and enables the tagging of the elementary streams 
 listed in the PMT.

 The optional <...> allow for a more detailed specifier. For 
 example, if the service contains a data carousel, the last 
 part of the URL may contain the file name. DAVIC doesn't 
 specify this entity (as far as I know).


+++++++++++
   DVB    :
+++++++++++

 No URL activity (to my knowledge). 
 Very likely to adopt the DAVIC URL.


+++++++++++
   ATSC   :
+++++++++++

 In ATSC an activity is going on the specify an URL. There 
 is no (frozen) specification existing.
 
 From the document provided by Petr Peterka [ATSC-URL], I 
 distall an URL scheme which is similar to the DAVIC URL 
 semantically, but incompatible to the DAVIC URL syntactically. 
 It seems to me that this scheme can be aligned with the DAVIC 
 specification.

 Provided I understood the document correclty the URL is 
 specified as
 
(3)  
dtv:[<netID>]/<TSID>[/<svcID>[/<part>[/<eventID][;<filepath>/<...>]]]
 
 <netID> specifies the network. In (the general) case that 
 all Transport Streams arrive through the same network, the 
 <netID> may be omitted. 
 <TSID> specifies the  MPEG-2 Transport Stream ID, which is 
 unique within a network. netID maps to the DVB-SI network_id 
 [not original_network_id]. 
 <svcID> specifies the MPEG-2 program_number [which has the 
 same value as the service_id in DVB-SI].
 
 <part> specifies a component (audio, video, data) out of the 
 service. It maps to the component_tag, but is broader in its 
 usages.
 <eventID> maps to the DVB-SI event_id.
 <filepath> specifies a file in the DSM-CC carousel.
 
 From Simon Gibb's message, he omits the <...> part in the 
 dtv-URL. In addition, he mentions
 
(4)   atsc:<sourceID>[/part[/eventID][;filepath]]]
 
 <sourcID> stems from a so-called Virtual Channel Table (VCT). 
 I understand that as being a look-up table providing tuning 
 and demultiplexing information, i.e. sourceID can be seen as 
 an alias to <netID>/<TSID>/<svcID> (in DTV) or 
 <original_network_id>.<transport_stream_id>.<service_id> (in DAVIC).
 
 Both proposals omit the double slash after the colon. Was 
 there a particular reason to do so? It turns these URLs 
 non-compliant to the DAVIC specification.
 
 RFC 2396, sec. 3, discusses this topic, as does the guidelines 
 draft, <draft-ietf-urlreg-guide-03.txt>, sec.2.1.1.
 The draft states that the use of the double slash implies 
 conformance with the hierachical structure specified in 
 RFC 2396, including that the first entity to follow the 
 double slash is a naming authority.
 RFC 2396, sec. 3.2., states that a naming authority is 
 typically an Internet server or a scheme-specific registry 
 of naming authorities.
 
 I understand this, that the double slash as used in the 
 DAVIC URL is perfectly conformant to these documents. It 
 is also in line with our requirements.



+++++++++++++++++++
   WebTV, ATVEF   :
+++++++++++++++++++

 Dan Zigmond's Internet-Draft [WTV-URL]. The scheme is designed 
 for use in analog-TV environments. The scheme is
 
(5)   tv:<broadcast>
 
 <broadcast> specifies a service (in DVB-SI sense). 
 
 If a double slash is added after the colon, this scheme 
 complies to the general DAVIC syntax.
 
 The URL proposed by ATVEF uses the same scheme [ATVEF-TV-URL].


++++++++++++
   ATVEF   :
++++++++++++

 ATVEF also specifies a so-called UHTTP (Unidirectional HTTP; 
 transmitting only response messages, not the requests) 
 [ATVEF-UHTTP-URL]. The scheme is
 
(6)   uhttp://<namespace-id>[/<resource-path>]
 
 <namespace-id> specifies a unique identifier similar as the 
 NID in a URN is doing [URN-SYNTAX]. It identifies the 
 namespace within which the resources are located and serves 
 as the root of that namespace. <resource-path> names a 
 specific resource in that namespace and follows the generic 
 relative URL syntax. This path component can be used alone 
 as a relative URL, where the base URL is implied through 
 other means.
 
 As far as I understand this scheme, I interpret it as not 
 compatible with the DAVIC scheme. It mixes URN and URL 
 approaches: the namespace-id adheres the URN approach, 
 where a level of indirection is introduced (the name is 
 to be resolved into a location, in this case the root of 
 a namespace), while the resource-path follows the (relative) 
 URL scheme locating a path to a resource.
 
 The scheme would be DAVIC conformant when the <namespace-id> 
 locates a service rather than names it. This all aside from 
 the fact that the uhttp protocol is a proprietary transport 
 protocol.
 
 The use of URN indirection is useful, especially when 
 satisfying requirements like those that resource retrieval 
 should be independent of the 'host' (e.g., transmission 
 channel or local storage). However, the URN needs always 
 to be resolvable into a URL. 


+++++++++++++++++++++++
   DAVIC-TV-Anytime   :
+++++++++++++++++++++++

 This is work in progress.
 A level of indirection is introduced, following the URN 
 approach. The content, rather than its location is identified. 
 A naming service is required to resolve the content's name 
 into its location. This provides the flexibility to be 
 independent from network or storage delivery (and retrieval).
 
 A so-called UPI (Unique Program Identifier) is being proposed:
 
(7)   UPI:<content-provider>:<content-provider-defined-string>
 
 <content-provider> specifies the content provider (e.g. 
 "BBC"). The content provider is expected to provide the 
 naming service for resolving the UPI into a location address.
 <content-provider-defined-string> is a scheme specified by 
 that content provider.
 
 Prefixing the UPI with "urn:" will turn the UPI in a 
 conformant URN, where "UPI" will be associated with the 
 so-called Namespace Identifier (NID) and the remainder 
 from <content-provider> onwards maps with the so-called 
 Namespace Specific String (NSS) [URN-SYNTAX]. 
 I guess the UPI needs registration with IANA to enable 
 resolution of such URNs with a generic RDS (which is the 
 URN naming service) [RDS].


++++++++++++
   MPEG4   :
++++++++++++

 Simon Gibbs brought this one up [DMIF-URL].
 I understood this is also work in progress, and the draft 
 is not stable at all. At least, the scheme described in 
 [DMIF-URL] is obsolete. That's why I am not repeating the 
 scheme here. I hope this understanding on the status is 
 correct.



[DAVIC-URL]
  Digital Audio Visual Council, 
  Specification 1.3, part 9, 1997.

[ATSC-URL]
  ATSC T3/S8, Doc. 252, Feb, 1998.

[WTV-URL]
  draft-zigmond-tv-url-00.txt, D. Zigmond, 
  "URL for TV Broadcasts", 
  <http://www.ics.uci.edu/pub/ietf/uri/draft-zigmond-tv-url-00.txt>, 
  June 1997 (expired).

[ATVEF-TV-URL]
  ATVEF Sepcification, Draft version 1.0r1, section 3, 
  <http://www.atvef.com/atvef_spec/TVE-public.htm#(3)>, 1998.

[ATVEF-UHTTP-URL]
  ATVEF Sepcification, Draft version 1.0r1, section 10, 
  <http://www.atvef.com/atvef_spec/TVE-public.htm#(10)>, 1998.

[URN-SYNTAX]
  RFC 2141, R. Moats, 
  "URN syntax", May 1997.

[RDS]
  RFC 2168, R. Daniel and M. Mealling, 
  "Locating the URN Resolver", June 1997.

[DMF-URL]
  MPEG-4, part 6, 
  "Delivery Multimedia Integration Framework (DMIF)"
  WD 1.0 (July 1997).


-END-

Received on Tuesday, 10 November 1998 09:17:58 UTC