RE: Reigistry for tv:URI's
"Deventer, M.O. \(Oskar\) van" <oskar.vandeventer@tno.nl> Wed, 04 October 2006 11:50 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV5GX-0008Ne-FZ; Wed, 04 Oct 2006 07:50:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV5GW-0008NZ-L5 for discuss@apps.ietf.org; Wed, 04 Oct 2006 07:50:20 -0400
Received: from mail123.messagelabs.com ([85.158.136.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GV5GU-0006wH-P0 for discuss@apps.ietf.org; Wed, 04 Oct 2006 07:50:20 -0400
X-VirusChecked: Checked
X-Env-Sender: oskar.vandeventer@tno.nl
X-Msg-Ref: server-3.tower-123.messagelabs.com!1159962462!15738874!1
X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,-
X-Originating-IP: [134.221.2.2]
Received: (qmail 4099 invoked from network); 4 Oct 2006 11:47:42 -0000
Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-3.tower-123.messagelabs.com with SMTP; 4 Oct 2006 11:47:42 -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 k94BlbB25871; Wed, 4 Oct 2006 13:47:42 +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); Wed, 4 Oct 2006 13:47:29 +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: RE: Reigistry for tv:URI's
Date: Wed, 04 Oct 2006 13:47:29 +0200
Message-ID: <42F3BE57026C6E49B09E267EEF639D5601246765@ms-dt01thalia.tsn.tno.nl>
In-Reply-To: <6446AF746F4BCFA373EA1B89@p3.JCK.COM>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Reigistry for tv:URI's
Thread-Index: Acbm2yQ1L4FhhZ78RjCtrtBeOivRzAAzwhVA
From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@tno.nl>
To: "Klensin, John" <john-ietf@jck.com>
X-OriginalArrivalTime: 04 Oct 2006 11:47:29.0669 (UTC) FILETIME=[DEE5B350:01C6E7AA]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb
Cc: discuss@apps.ietf.org, "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
John, > Just so you have your facts straight > ... ICANN ... IANA ... IAB ... e164.arpa Thank you for these facts. What I want to achieve is that the new registry will be accredited. Like e164.arpa is the "golden tree" of user ENUM, the registry should become the "golden registry" for tv:URIs. Do you have a suggestion how we could achieve this? > large volume of information, with additions being > made on a very frequent basis What is the reason of your worry? Verisign handled about 5000 new .com registrations yesterday. In contrast, how many new television broadcasts have been introduced in the USA yesterday? And how many stations have changed call sign yesterday? One perhaps? Or were there no changes at all yesterday? > If a station changes ownership but not call > signs, do URIs remain stable? > ...mechanisms to keep the registry up to date? ... > If programming belongs to a producer, how is that > reflected in the system? > stable enough to be useful? > ...how would you propose to enforce that? These are all valid questions, which we will work out in more detail in an internet draft. -As tv:URIs identify television broadcasts, a change of ownership is irrelevant to the tv:URI. If there is anyone who wants to have the ownership info changed in the registration record, then he can request that and the registry will make the change. -The whole idea of "nomination" is that if nobody asks for changes, no changes are made. If I were a service provider of advanced television presence and messaging services, I would regularly check if there are new TV channels that my customers are watching, and make an effort to keep the registry up to date, at least for the TV channels in my area. > why a "guess the URI" mechanism with central, > infrastructure, administration makes sense. At the discuss@apps.ietf.org mailing list some consensus seemed to arise that without a central registry it would not be possible to have an effective use of tv:URIs. The initial RFC (RFC2838) indeed proposed a "guess the URI" mechanism, but enough examples have been given illustrating that this would always lead to ambiguity. The proposal of having a central registry is not to go into a "guess the URI" mode, but to have a database for looking up the "proper" tv:URI. Of course once such a central database (a.k.a. registry) exists, search machines may be employed for finding a particular tv:URI. The use of the tv:URI, however, should not be dependent on the use of search machines. It is highly preferable that it be possible for humans to type in a television broadcast identifier (after having searched the tv:URI in the registry, or by reading it from advertisements or otherwise). > via ITU, probably the Radio Sector ITU-R is about frequencies and call signs of terrestrial radio/TV broadcasts (i.e. making use of through-the-air radio waves). It is not about cable TV, nor satellite TV, nor IPTV, nor webTV. tv:URIs are about television broadcasts, independent of the transmission technologies used, see RFC2838. > trademark and control issues One of the tasks of the tv:URI registry is to handle trademark issues. This is exactly the same as with DNS registry's. Oskar van Deventer & Iko Keesmaat -----Original Message----- From: John C Klensin [mailto:john-ietf@jck.com] Sent: dinsdag 3 oktober 2006 12:59 To: Deventer, M.O. (Oskar) van; discuss@apps.ietf.org Cc: Keesmaat, N.W. (Iko); Zigmond, Dan Subject: Re: Reigistry for tv:URI's --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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html
- RE: Reigistry for tv:URI's Keesmaat, N.W. (Iko)
- RE: Reigistry for tv:URI's Deventer, M.O. (Oskar) van
- Re: Reigistry for tv:URI's Lisa Dusseault
- Reigistry for tv:URI's Deventer, M.O. (Oskar) van
- Re: Reigistry for tv:URI's Eliot Lear
- Re: Reigistry for tv:URI's Mark Baker
- RE: Reigistry for tv:URI's Deventer, M.O. (Oskar) van
- Re: Reigistry for tv:URI's John C Klensin
- RE: Reigistry for tv:URI's John C Klensin
- RE: Reigistry for tv:URI's Keesmaat, N.W. (Iko)
- Re: Reigistry for tv:URI's Keith Moore
- RE: Reigistry for tv:URI's Keesmaat, N.W. (Iko)
- Re: Reigistry for tv:URI's Keith Moore
- RE: Reigistry for tv:URI's Keesmaat, N.W. (Iko)
- Re: Reigistry for tv:URI's Clive D.W. Feather
- Re: Reigistry for tv:URI's Keith Moore
- RE: Reigistry for tv:URI's Keesmaat, N.W. (Iko)
- ETSI TISPAN interest in tv:URI Deventer, M.O. (Oskar) van
- RE: ETSI TISPAN interest in tv:URI Deventer, M.O. (Oskar) van