Re: Update of RFC 2838, tv: URI

Ted Hardie <hardie@qualcomm.com> Sun, 20 August 2006 22:26 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEvkK-00019l-Vk; Sun, 20 Aug 2006 18:26:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEvkK-00019g-Dn for discuss@apps.ietf.org; Sun, 20 Aug 2006 18:26:20 -0400
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEvkI-0002CO-2G for discuss@apps.ietf.org; Sun, 20 Aug 2006 18:26:20 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7KMQGsM012357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 20 Aug 2006 15:26:16 -0700
Received: from [10.0.1.2] (vpn-10-50-16-2.qualcomm.com [10.50.16.2]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7KMQ9tA006530; Sun, 20 Aug 2006 15:26:15 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06230902c10e9022b24a@[10.0.1.2]>
In-Reply-To: <44E82E18.6030605@gmx.de>
References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E82E18.6030605@gmx.de>
Date: Sun, 20 Aug 2006 15:26:08 -0700
To: Julian Reschke <julian.reschke@gmx.de>, "Deventer, M.O. (Oskar) van" <oskar.vandeventer@tno.nl>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: Update of RFC 2838, tv: URI
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: discuss@apps.ietf.org, "Zigmond, Dan" <djz@google.com>, "Keesmaat, N.W. (Iko)" <iko.keesmaat@tno.nl>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

At 11:40 AM +0200 8/20/06, Julian Reschke wrote:
>Hi,
>
>first of all, I was surprised to hear that there a "tv" URI scheme. Turns out, it hasn't been published through the IESG, and the URI scheme hasn't been registered through IANA.


Actually, this looks like a bug in the IANA registry. The TV uri scheme is
described in RFC 2838, as the original poster notes.  That means it should
be (at the very least) be in the registry as provisional. Have the proponents
of changing it talked to the original authors to see if it is still in use according
to the original spec?  I believe Liberate made set-top boxes, for example,
which may still be in use and are pretty tough to upgrade.

The salient bit for this discussion seems to come from section 3.2 of 2838;
especially this text:

  In some cases, networks have multiple broadcast streams that need to
   be distinguished.  This is also handled in DNS style:

          tv:east.hbo.com     HBO East
          tv:west.hbo.com     HBO West

   It is important to note that these DNS-style identifiers need not
   match real hostnames; they should not be resolved to IP addresses
   using DNS.  Thus, using the terms as defined in RFC 2396, the "tv:"
   scheme is a Uniform Resource Identifier and not a Uniform Resource
   Locator.

   In order to support these identifiers in a "tv:" URI, a receiver must
   implement a means to map known identifiers to frequencies. The nature
   of this map and the way in which it is used are currently browser-
   and device-specific and are beyond the scope of this document. In
   this way, the "tv:" scheme is somewhat analogous to the "news:" and
   "file:" schemes in [1]: it merely names a television broadcast signal
   but assumes that the local browser has some means for actually
   retrieving that signal on the local device.  A variety of software
   systems currently provide device-specific mappings from such
   identifiers to specific channel numbers or directly to frequencies.
   These systems can be incorporated into television sets or set-top
   boxes to facilitate the interpretation of television URIs by the
   client device.

That is, the original registrants presumed that you would be able to
mint dns-style identifiers for the mapping.  Sounds like this does
not satisfy the needs that have now been expressed.

I note as well that we already have a second URI scheme (CRID,
described in RFC 4078) that tackles the same space.  Is there any
hope of using it instead?  Or are we looking at a third, with possible
deprecation of a the first?
			regards,
				Ted Hardie