Reigistry for tv:URI's

"Deventer, M.O. \(Oskar\) van" <oskar.vandeventer@tno.nl> Mon, 02 October 2006 12:04 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMWm-0003no-6B; Mon, 02 Oct 2006 08:04:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMWk-0003iR-Bm for discuss@apps.ietf.org; Mon, 02 Oct 2006 08:04:06 -0400
Received: from mail92.messagelabs.com ([194.106.220.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUMWb-0001XZ-T3 for discuss@apps.ietf.org; Mon, 02 Oct 2006 08:04:06 -0400
X-VirusChecked: Checked
X-Env-Sender: oskar.vandeventer@tno.nl
X-Msg-Ref: server-7.tower-92.messagelabs.com!1159790623!18492658!1
X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,-
X-Originating-IP: [134.221.2.2]
Received: (qmail 13237 invoked from network); 2 Oct 2006 12:03:43 -0000
Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-7.tower-92.messagelabs.com with SMTP; 2 Oct 2006 12:03:43 -0000
Received: from ms-dt01vs01.tsn.tno.nl (cl-dt01castor.tno.nl [134.221.225.7]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id k92C3fB23463; Mon, 2 Oct 2006 14:03:41 +0200 (MEST)
Received: from ms-dt01thalia.tsn.tno.nl ([134.221.225.157]) by ms-dt01vs01.tsn.tno.nl with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 14:03:40 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: Reigistry for tv:URI's
Date: Mon, 02 Oct 2006 14:03:40 +0200
Message-ID: <42F3BE57026C6E49B09E267EEF639D5601246747@ms-dt01thalia.tsn.tno.nl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Reigistry for tv:URI's
Thread-Index: AcbmGsw2uMfRjXEIR7uyReVHorInAg==
From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@tno.nl>
To: discuss@apps.ietf.org
X-OriginalArrivalTime: 02 Oct 2006 12:03:40.0706 (UTC) FILETIME=[CCDAB020:01C6E61A]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Cc: "Keesmaat, N.W. (Iko)" <iko.keesmaat@tno.nl>, "Zigmond, Dan" <djz@google.com>
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

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.

This also means that I am withdrawing my suggestions to modify the
tv:URI syntax, or making links between tv:URI's and the "official"
webpage of a TV channel. So for the scope of the registry discussion,
we'll be talking about tv:URI's that refer purely to TV channels and
that are pure DNS-style identifiers, as described in RFC2838

I think the following questions are relevant:
1) Do we need a registry and why?
2) How should such a registry be organized?
3) What type of information should be registered?
4) How are registrations created, read, updated, and deleted (CRUD)?
5) What is the relationship with existing registries?
     -... in particular with the DNS registry.

Here are my provisional answers for your review.

Ad 1) Yes, we do need a registry. This is the only way to really cut
down ambiguity in referring to TV channels.

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.

Ad 3) The registry will contain a list of unique tv:URI's, to each entry
information is associated on the TV broadcast that it identifies, like
broadcaster, language(s), geographic reach and other. The registry will
serve two purposes.
-Identification: learning which TV broadcast is identified by a specific
tv:URI.
-Search: finding the tv:URI of a specific TV broadcast.

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.

Ad 5) The relationship with the DNS registry will be as described in
RFC2838. That is, DNS-style domain name syntax is used to identify a
broadcast. Further then this syntactic relation we do not foresee any
relation with the DNS. Note that this implies - as already stated in
RFC2838 - that it is not the intention that tv:URI's are resolved
through the DNS.

Please let me know your reactions on these thoughts.

Best regards,

Oskar van Deventer & Iko Keesmaat

--------------------------------
dr.ir. M. Oskar van Deventer
TNO Information and Communication Technology
P.O. box 5050
2600 GB  Delft
Netherlands
+31 651 914 918
oskar.vandeventer@tno.nl
--------------------------------
Connecting to a TNO colleague? Call +31 15 285 75 75

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html