AW: URL: Background & Reqs (ASCII)

I think you both did excellent work
I agree with the background and the requirements.
So what is the actual presentation engine in DTV ?
Does anybody know ?
I would say: "Any future DTV presentation engine should have XML-compliant parsing functionality" .

Henning Timcke
Ideen Werft22 GmbH
Managing Director

Your win-win computing company (TM)
Thought global, swiss made. (TM)

http://www.werft22.com

Werft22fax +41 56 210 91 34

Henning Timcke  can be reached globally by Werft22fon +41 56 210 91 32
 

-----Ursprüngliche Nachricht-----
Von:	Craig A. Finseth [SMTP:fin@finseth.com]
Gesendet am:	Donnerstag, 29. Oktober 1998 21:08
An:	gomer@lgerca.com
Cc:	www-tv@w3.org
Betreff:	Re: URL: Background & Reqs (ASCII)

I think that you did an excellent job of summarizing the overall issues.

I do have a couple of refinements to points that you made.

	...
   To complicate things further, when a program is picked up by a
   cable or satellite operator and rebroadcast, nearly every single
   one of the identifiers for the program may be changed -- RF
   frequency, ts_id, program_number, major-minor channel number,
   source_id, packet ids, possibly even association tags. Proably
   the channel name will stay the same.

It is also possible that the data transmission will be shifted in time
relative to program content.  In other words, some systems may _rely_
on presend/caching rather than real time transmission.

	...
   The ATSC Data Broadcast Specification (from T3/S13 subcommittee)
   specifies a number of different protocols for including data in
   an MPEG-2 broadcast stream:
       - DSM-CC bounded data carousels
       - DSM-CC unbounded data carousels
       - streaming data in PES packets
       - IP or other protocol datagrams encapsulated in PES or TS
   packets
       - piped data in TS packets
	...

Also, many systems currently in use are non-ATSC or DVB.  It is
desirable for new designs to be usable on the range of existing
systems.  Thus, too-heavy reliance on selected protocol stacks is not
good.

	...
   All this leads to the following requirements for URL schemes for
   DTV environments:
       - URLs must actually be URLs, not just URIs. Given a URL, it
   must be possible for a receiver to actually locate the resource,
   or conclude that it is not reachable. (Note that locating the
   resource may require intermediate steps, analogous to a DNS
   lookup on the Internet. ATSC T3/S8 document 253, URL Mapping,
   submitted 26 Feb, 1998, by General Instrument, is a step in this
   direction, but does not quite solve the problem.)
Agreed.

       - It must be possible for the resource referenced by a URL to
   be an entire program/event, or just a single component of a
   program/event.
Agreed.

       - It must be possible for a URL to contain an identification
   of the date(s) and time(s) when the resource is available, either
   through an explicit time designation, or through an event
   designation.
This items gets complex when pre-loading is involved.

       - The set of URL schemes for DTV should include audio/video
   streams and all of the data broadcast protocols endorsed by the
   ATSC Data Broadcast Specification.
Agreed.

       - A URL must be meaningful when interpreted from any of the
   following locations relative to the resource being referenced:
	   * From within the same elementary stream
	   * From within the same program
	   * From within the same transport stream
	   * From within a different transport stream received by
   the same receiver
	   * From an arbitrary location in the Internet
Agreed, with a caveat on the last ones that they device have access
to the transport stream.

   The correct interpretation of this requirement is that a DTV
   receiver should be able to obtain an HTML page from any of the
   listed locations, and if the resource referenced by a DTV URL in
   that page is available to that receiver in the broadcast streams
   it can receive, it should be able to find the resource.

I would also like to add one other requirement:

	- A URL must be invariant with respect to the normal range of
	transport stream transformations.

Craig A. Finseth                        craig@finseth.com
USSB                                    cfinseth@ussb.com (coming)
3415 University Ave, Suite 201          +1 651 659 7162
St Paul MN 55114                        +1 651 646 8896 fax
USA                                     http://www.ussb.com
A ship is safe in a harbor, but that's not what a ship is for--Adm Grace Hopper

Received on Friday, 30 October 1998 12:53:45 UTC