Re: submission

From: Craig A. Finseth (fin@finseth.com)
Date: Fri, Dec 18 1998


Date: Fri, 18 Dec 1998 17:11:36 -0600 (CST)
Message-Id: <199812182311.RAA23755@isis.visi.com>
From: "Craig A. Finseth" <fin@finseth.com>
To: tenkate@natlab.research.philips.com
Cc: www-tv@w3.org
Subject: Re: submission

This message is to follow up your request from several days ago to
provide an analysis of how the proposed scheme meets the URI, URL, and
URN requirements.  It's a first cut document and undoubtedly can be
improved.

Craig
------------------------------------------------------------
		  URI Scheme Viewed as URI, URL, URN

This document briefly analyzes the URI scheme proposed in [1] and [2]
in terms of the separate views as a URI, a URL, and a URN.


AS A URI (Uniform Resource Identifier)

To be a URI, a scheme must meet the requirements as spelled out in RFC
2396.  They are:

Uniformity: The proposed scheme identifies a wide variety of resources
in a highly uniform manner.  This manner is one that isolates the
identification of the resources from the mechanism used to access
them. It can be readily extended to handle new or additional resource
types in a smooth fashion.  It is also uniform syntactically, in that
it conforms to the syntax specified in RFC 2396.

Resource: The content identified by the proposed scheme fully meets
the requirements of being a resource as specified in RFC 2396.  The
characteristic that all of the identified resources have in common is
also the unifying force behind the creation of the scheme: all
resources identified by this scheme are supplied over one or more TV
broadcasts.

Identifier: Again, the proposed scheme is an identifier by the
definition supplied in RFC 2396.


AS A URL (Uniform Resource Locator)

The proposed scheme also meets the requirements (as specified in RFC
2396) for being a URL, albeit in a trivial way.  The scheme assumes
that each transport carries the information required to map each URL
to the associated data, much as a file system maps a name to the
actual storage holding the bytes of the file.  The URI (viewed as a
URL) is mapped by a transport-specific mechanism to the correct bytes.

Admittedly, the proposed scheme only meets the URL requirements in a
trivial way.  However, the key point is that no other URL scheme is
required in order to fully use the proposed scheme.


AS A URN (Uniform Resource Name)

Finally, the proposed scheme meets the requirements (as specified in
RFC 2396) for being a URN.  For proper operation, URIs must remain
globally unique: once a URI is assigned to a purpose (e.g,. to
designate a particular background GIF or to designate a channel), it
can be used for no other purpose.  The authority that assigns the URIs
is in full control of what properties are to be preserved in this
assignment.  Further, the assigning authority is assumed to retain the
memory of what URIs have been used and for what purposes, thus
satisfying the requirement that URNs remain persistant.



[1] Finseth, C,. Thomas, G., "Specifications for a TV Broadcast URI
	Scheme", Internet-Draft ???????????-00.txt

[2] Finseth, C,. Thomas, G., "An Example Instantiation of the TV
	Broadcast URI Scheme for ATSC", Internet-Draft ???????????-00.txt

	...from RFC 2396...
1.1 Overview of URI

   URI are characterized by the following definitions:

      Uniform
         Uniformity provides several benefits: it allows different types
         of resource identifiers to be used in the same context, even
         when the mechanisms used to access those resources may differ;
         it allows uniform semantic interpretation of common syntactic
         conventions across different types of resource identifiers; it
         allows introduction of new types of resource identifiers
         without interfering with the way that existing identifiers are
         used; and, it allows the identifiers to be reused in many
         different contexts, thus permitting new applications or
         protocols to leverage a pre-existing, large, and widely-used
         set of resource identifiers.

      Resource
         A resource can be anything that has identity.  Familiar
         examples include an electronic document, an image, a service
         (e.g., "today's weather report for Los Angeles"), and a
         collection of other resources.  Not all resources are network
         "retrievable"; e.g., human beings, corporations, and bound
         books in a library can also be considered resources.

         The resource is the conceptual mapping to an entity or set of
         entities, not necessarily the entity which corresponds to that
         mapping at any particular instance in time.  Thus, a resource
         can remain constant even when its content---the entities to
         which it currently corresponds---changes over time, provided
         that the conceptual mapping is not changed in the process.

      Identifier
         An identifier is an object that can act as a reference to
         something that has identity.  In the case of URI, the object is
         a sequence of characters with a restricted syntax.

   Having identified a resource, a system may perform a variety of
   operations on the resource, as might be characterized by such words
   as `access', `update', `replace', or `find attributes'.

1.2. URI, URL, and URN

   A URI can be further classified as a locator, a name, or both.  The
   term "Uniform Resource Locator" (URL) refers to the subset of URI
   that identify resources via a representation of their primary access
   mechanism (e.g., their network "location"), rather than identifying
   the resource by name or by some other attribute(s) of that resource.
   The term "Uniform Resource Name" (URN) refers to the subset of URI
   that are required to remain globally unique and persistent even when
   the resource ceases to exist or becomes unavailable.

   The URI scheme (Section 3.1) defines the namespace of the URI, and
   thus may further restrict the syntax and semantics of identifiers
   using that scheme.  This specification defines those elements of the
   URI syntax that are either required of all URI schemes or are common
   to many URI schemes.  It thus defines the syntax and semantics that
   are needed to implement a scheme-independent parsing mechanism for
   URI references, such that the scheme-dependent handling of a URI can
   be postponed until the scheme-dependent semantics are needed.  We use
   the term URL below when describing syntax or semantics that only
   apply to locators.

   Although many URL schemes are named after protocols, this does not
   imply that the only way to access the URL's resource is via the named
   protocol.  Gateways, proxies, caches, and name resolution services
   might be used to access some resources, independent of the protocol
   of their origin, and the resolution of some URL may require the use
   of more than one protocol (e.g., both DNS and HTTP are typically used
   to access an "http" URL's resource when it can't be found in a local
   cache).

   A URN differs from a URL in that it's primary purpose is persistent
   labeling of a resource with an identifier.  That identifier is drawn
   from one of a set of defined namespaces, each of which has its own
   set name structure and assignment procedures.  The "urn" scheme has
   been reserved to establish the requirements for a standardized URN
   namespace, as defined in "URN Syntax" [RFC2141] and its related
   specifications.

   Most of the examples in this specification demonstrate URL, since
   they allow the most varied use of the syntax and often have a
   hierarchical namespace.  A parser of the URI syntax is capable of
   parsing both URL and URN references as a generic URI; once the scheme
   is determined, the scheme-specific parsing can be performed on the
   generic URI components.  In other words, the URI syntax is a superset
   of the syntax of all URI schemes.