Login       -       Change Password       -       Recent Changes       -       Search:

InterStream Overview

InterStream FAQ

Working Groups


Technology and Standards

WiKi Help

edit SideBar


ISTP & Ordinary URLs

The Media Grid will have the ability to unicast and multicast stream ordinary URLs through the grid from ordinary URL-based streams to the default portal. This section describes the syntax used to enable that operation by either a user of the default portal, or as referenced from a website URL. If a specific URL or website does not conform with InterStream's anti-piracy policy, those URLs may be blacklisted from the grid.

ISTP URL Syntax Translation and Compatibility

The syntax for ISTP must be compatible and extend the existing URL conventions. Therefore, it must observe the existing syntax of URLs while allowing it to be extended to support existing "off media grid" streaming objects as well as rich media objects that are registered within the grid. A review of the basic URL syntax rules follows.

RFC 1738 (now obsoleted and consolidated under RFC 3986) represents the following as a Common Internet Scheme Syntax:

   While the syntax for the rest of the URL may vary depending on the
   particular scheme selected, URL schemes that involve the direct use
   of an IP-based protocol to a specified host on the Internet use a
   common syntax for the scheme-specific data:


   Some or all of the parts "<user>:<password>@", ":<password>",
   ":<port>", and "/<url-path>" may be excluded.  The scheme specific
   data start with a double slash "//" to indicate that it complies with
   the common Internet scheme syntax. The different components obey the
   following rules:

        An optional user name. Some schemes (e.g., ftp) allow the
        specification of a user name.

        An optional password. If present, it follows the user
        name separated from it by a colon.

   The user name (and password), if present, are followed by a
   commercial at-sign "@". Within the user and password field, any ":",
   "@", or "/" must be encoded.

   Note that an empty user name or password is different than no user
   name or password; there is no way to specify a password without
   specifying a user name. E.g., <URL:ftp://@host.com/> has an empty
   user name and no password, <URL:ftp://host.com/> has no user name,
   while <URL:ftp://foo:@host.com/> has a user name of "foo" and an
   empty password.

        The fully qualified domain name of a network host, or its IP
        address as a set of four decimal digit groups separated by
        ".". Fully qualified domain names take the form as described
        in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
        [5]: a sequence of domain labels separated by ".", each domain
        label starting and ending with an alphanumerical character and
        possibly also containing "-" characters. The rightmost domain
        label will never start with a digit, though, which
        syntactically distinguishes all domain names from the IP

        The port number to connect to. Most schemes designate
        protocols that have a default port number. Another port number
        may optionally be supplied, in decimal, separated from the
        host by a colon. If the port is omitted, the colon is as well.

        The rest of the locator consists of data specific to the
        scheme, and is known as the "url-path". It supplies the
        details of how the specified resource can be accessed. Note
        that the "/" between the host (or port) and the url-path is
        NOT part of the url-path.

   The url-path syntax depends on the scheme being used, as does the
   manner in which it is interpreted.

Note: The following is a proposed syntax; Parameter passing of special characters have not been checked across all browsers which InterStream intends to support.

Extending RFC 1738

By extending RFC 1738 to support ISTP, it would be natural to follow the same syntax rules. ISTP has two forms: one for off Media Grid content referenced by a URL to be streamed by the grid; The other for natively referenced Handle Prefixes and Suffixes that is contained within the grid. ISTP determines from the first parameter as to whether to interprete and locate the content either on or off the grid. These two methods are defined as either:




Specifically, ISTP has the following form when being used to transfer an existing "off grid" referenced content via the URL into or through the Media Grid:


A required protocol name used for streaming content from the location the URL specifies, through the media grid. The transfer protocol can be one of mms, rtp, http, or https. The media grid may be extended in the future to support other streaming protocols. The http, https, rtp and mms transfer protocols become special "prefixes" (see below), and thus will not be recognized as portal prefixes by ISTP.

All other parameters remain consistent with RFC 1738. URLs which are interpreted by ISTP to be streamed through the media grid will be first located by the location resolution system. Ideally, the media grid's location resolution system will find the optimal Media Grid Elements to stream the URL's content through to maximize the quality of experience for the end user.

For "on grid" rich media objects, ISTP interprets a Handle prefix and suffix in either numeric or mnemonic form. Since the Handle System does not specify a mnemonic form for prefixes and suffixes, the Media Grid implementor will be responsible for creating and managing a registry to translate from the mnemonics into the prefix or suffix values. Therefore, Handle System objects will be interpreted by ISTP as follows:


An optional parameter as specified by the Handle System. The handle-prefix can use the numeric identifier as specified in RFC 3650. If the handle-prefix is specified in mnemonic form, the location resolution system will translate from the mnemonic form into a canonical handle system prefix which can be interpreted directly by the Global Handle Registry. If the handle-prefix only has numeric characters, then it will be assumed to be a canonical handle. Otherwise, it will be treated as a mnemonic. The handle-prefix can also be used to specify an ISTP Portal if the handle-suffix is omitted. If the handle-prefix is entirely omitted, or the handle prefix resolves to an unrecognized canonical or mnemonic name, then the ISTP-enabled browser or client will be redirected to a Default Portal. A handle-prefix which is "http", "https", "rtp" or "mms" will be interpreted to be a transfer-protocol as outlined above. These prefixes are reserved for use as transfer-protocol prefixes. Other prefixes may be reserved-prefexes (defined below) for other specific lexicographic conventions (-- see Default Portal). In addition, if the domain name is not recognized or the URL is unresolved by the location resolution process, then the browser will be redirected to a Default Portal (see Default Portals & Unrecognized Names, below).
An optional parameter speficying a local service for the handle prefix. The selector specifies a local service that is specific to a given prefix. The URL to feed the media grid will be called with a "?=selector" appended to the it for the HTML page feed. If the portal and selector define an ISTP stream, then media grid's content must be originated from an element from within the grid. Examples of selectors include "weather:Reno", where weather specifies the weather portal, while Reno specifies the city Reno for which the weather portal should tailor its content.
An optional parameter specified by the Handle System. The suffix can also be interpreted, like the prefix, as a mnemonic. The media grid's location resolution system is responsible for translating the suffix into a canonical form which can be be interpreted by the Global Handle Registry. Similarly to the handle-prefix, the handle-suffix will be treated as a canonical Handle if the character string is entirely numeric, otherwise it will be treated as a mnemonic suffix. If the handle-suffix is omitted, then the handle-prefix will be interpreted as an ISTP Portal.

Reserved Prefixes

In addition to the transfer-protocol prefixes, the "adult" and "InterStream" will be reserved for InterStream Industry Association licensing to vertical market segments and as useful defaults. InterStream may opt to reserve other prefixes for additional market segments and defaults in the future. InterStream will maintain a list of reserved-prefixes, defined below. Like domain names, reserved-prefixes are case insensitive.

Default Portals and Unrecognized Domain Names, URLs or Prefixes

A reserved-prefix is either "adult", "interstream", "istp", "http", "https", "rtp", or "mms". All prefixes are case insensitive. Additional prefixes may be reserved in the future by the InterStream Association. For a candidate list of reserved prefixes, please contact Prefixes@InterStream.com.

If the browser is redirected to a default portal, the type of default portal will be determined by whether any subset of the character string after istp:// matches an explicit-phrase, defined below. If it does match, then the browser will be redirected to the "Default Adult Portal". Otherwise, the browser will be redirected to the "Default Mainstream Portal". The default portal url-path will have a string, "?handle=unrecognized", appended to the end of the URL when resolution occurs if the domain, URL, or prefix is unrecognized. Implicitly, the default portal url-path assumes that the user intended to be redirected to one of the default portals if either "adult" or "InterStream" is used as a prefix.

An explicit-phrase is defined by InterStream's explicit phrase list. For more information, please contact: Prefixes@InterStream.com for details about this list.

Other Potential Prefix Usage Conventions

In addition to explicit phrases, prefixes may be reserved or aliased. Reserved prefixes may be used by the InterStream Assocaition to define additional default portals for specific market segements. Currently, InterStream envisions the following potential vertical industry segments:

  • Distance Learning
  • Gaming
  • On-Line Casinos
  • Government
  • Philanthropy
  • Education

Prefixes may be aliased so that multiple mnenominc terms resolve to the same numeric Handle Prefix. This may useful for webmasters and others wishing to transition to ISTP from URL and domain name based conventions.


The following examples may help clarify how ISTP can transition usage from lower performance RFC 1738 type "off grid" URLs into higher performance Handles on the Media Grid.

Since now prefix or suffix are specified, the client or browser will be redirected to the default portal. This portal may be an ordinary HTML-based page that can be natively interpreted by the browser or a hyper-linked video site.
foo represents mnemonic prefix. As such, the client will display the "foo" portal which may be either ordinary HTML-based content or a hyperlinked video site.
foo and bar represent mnemonic prefixes, and suffixes, respectively. Therefore, ISTP will resolve to a InterStream Media Grid Object. As outlined, this may be a hyper-linked video object or HTML-type page that is interpreted directly by the browser.
http specifies the protocol to be used for transfering the content from the regular URL as specified by foo.com/bar.video-type. HTTP will be used to transfer the video as specified by the file bar.video-type from the domain name foo.com. Optimally, the media grid will perform a high speed transfer from the URL into the grid if sufficient media grid points of presence are available and the URL can be transparently accessed.
https specified that SSL or TLS (if enabled on foo.com) will be used to transfer the URL into the media grid over port 88080. The media grid object foo.com will be registered into the media grid for fast access to future users. The object available on the grid which may represent an HTML-type page or of some other type as specified by the domain foo.com's default index file.
Edit - History - Print - Recent Changes - Search
Page last modified on April 20, 2010, at 07:10 AM PST