Re: Reigistry for tv:URI's

John C Klensin <john-ietf@jck.com> Tue, 03 October 2006 10:59 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhza-00008A-Rs; Tue, 03 Oct 2006 06:59:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhzZ-000085-9t for discuss@apps.ietf.org; Tue, 03 Oct 2006 06:59:17 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUhzX-0000NZ-OK for discuss@apps.ietf.org; Tue, 03 Oct 2006 06:59:17 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GUhzU-000Mex-Sa; Tue, 03 Oct 2006 06:59:13 -0400
Date: Tue, 03 Oct 2006 06:59:11 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Deventer, M.O. \\(Oskar\\) van" <oskar.vandeventer@tno.nl>, discuss@apps.ietf.org
Subject: Re: Reigistry for tv:URI's
Message-ID: <6446AF746F4BCFA373EA1B89@p3.JCK.COM>
X-Mailer: Mulberry/4.0.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: "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


--On Monday, 02 October, 2006 14:03 +0200 "Deventer, M.O.
\\(Oskar\\) van" <oskar.vandeventer@tno.nl> wrote:

> All,
> 
> In the tv:URI discussions on this mailing list, the creation
> of a registry was gently suggested by several people. I am now
> starting to believe this is the only way to really cut down
> ambiguity. So I would like to focus the discussion on the
> creation of such a registry.
>...
 
> Ad 2) The responsibility of the registry would reside with
> ICANN. ICANN would delegate the technical work to a third
> party. An example of such a delegation is User ENUM, for which
> ICANN has delegated the e164.arpa root to RIPE.

Just so you have your facts straight on starting, ICANN
(actually the IANA) made that delegation when instructed to by
the IAB, which  has management control of the ARPA TLD.  ICANN
was not involved in the choice of where it was delegated.

ICANN does occasionally create and registries on its own.  If
you want such a registry, you should be discussing it with
ICANN, not here.   But e164.arpa is not an example of an
ICANN-created or managed registry.

> Ad 3) The registry will contain a list of unique tv:URI's, to
>...

> Ad 4) Any person or organization can "nominate" a TV broadcast
> for registration. This person or organization should provide
> evidence that the TV broadcast exists and that it has not been
> previously registered. The registry will subsequently assign a
> tv:URI to the broadcast following the RFC2838 guidelines.

I think you are going to have tremendous difficulty keeping such
a registry active and useful.  I see at least two important
problems in that regard.  

First, a per-broadcast registry could, in principle, contain a
large volume of information, with additions being made on a very
frequent basis.  Using it as an example, additions to e164.arpa
occur on a frequency of weeks or months and we know that there
can be a maximum of only a few hundred entries, ever.  If you
are really talking about registering broadcasts, that may
entries could accumulate in much less than an hour.  Even if you
intend to register broadcasters or stations, the number is huge.

These broadcasters, call signs, and hence, usually, station
names and station-related URLs are subject to a significant
number of governmental regulations, as well as ownership issues
for both stations (broadcasters) and broadcasts that differ from
country to country.  If a station changes ownership but not call
signs, do URIs remain stable?  If a station retains management
and programming but changes call signs, do URI's remain stable?
If a station reorganizes its web presence, what are the
incentives and mechanisms to keep the registry up to date?  If
programming belongs to, and is made available from, a producer
or network, rather than linked to a station, how is that
reflected in the system?  And so on.  In addition, given any of
the above changes, how would you expect to keep a URI that is
nominated/registered by the public (someone with no affiliation
to the broadcaster or content producer) stable enough to be
useful?  Does the registrant take on any formal obligation to
manage the link and keep it up to date and how would you propose
to enforce that?

Two constructive observations and suggestions: 

(1) What has been missing from your discussions so far is why a
"guess the URI" mechanism with central, infrastructure,
administration makes sense.  When I think of all the different
ways I might want to find a broadcaster or broadcast, I start
thinking about directories and search engines.  But, if those
are the entry points, the form of the URI they uncover is
largely irrelevant.   And, if directories or search engines or
databases of some sort are the answer, then you are discussing a
business opportunity, not something that is appropriately or
usefully within IETF's domain.

(2) If there is a need for the infrastructure to support a URI
with more or less elaborate structure and semantics, it may
actually be useful discussion to initiate via ITU, probably the
Radio Sector rather than the Telecommunications Standards one.
They have the necessary connections with the call-sign machinery
and regulators to have a serious discussion about what would be
necessary to create a stable identifier and to persuade the
relevant actors to pay attention.

Going down that path would also eliminate the trademark and
control issues pointed out by others.

    john