From discuss-bounces@apps.ietf.org Mon Oct 02 08:05:15 2006 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, 2 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" To: 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\)" , "Zigmond, Dan" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org All, In=20the=20tv:URI=20discussions=20on=20this=20mailing=20list,=20the=20crea= tion=20of=20a registry=20was=20gently=20suggested=20by=20several=20people.=20I=20am=20no= w=20starting=20to believe=20this=20is=20the=20only=20way=20to=20really=20cut=20down=20ambigu= ity.=20So=20I=20would like=20to=20focus=20the=20discussion=20on=20the=20creation=20of=20such=20a= =20registry. This=20also=20means=20that=20I=20am=20withdrawing=20my=20suggestions=20to=20= modify=20the tv:URI=20syntax,=20or=20making=20links=20between=20tv:URI's=20and=20the=20= "official" webpage=20of=20a=20TV=20channel.=20So=20for=20the=20scope=20of=20the=20reg= istry=20discussion, we'll=20be=20talking=20about=20tv:URI's=20that=20refer=20purely=20to=20TV=20= channels=20and that=20are=20pure=20DNS-style=20identifiers,=20as=20described=20in=20RFC28= 38 I=20think=20the=20following=20questions=20are=20relevant: 1)=20Do=20we=20need=20a=20registry=20and=20why? 2)=20How=20should=20such=20a=20registry=20be=20organized? 3)=20What=20type=20of=20information=20should=20be=20registered? 4)=20How=20are=20registrations=20created,=20read,=20updated,=20and=20delet= ed=20(CRUD)? 5)=20What=20is=20the=20relationship=20with=20existing=20registries? =20=20=20=20=20-...=20in=20particular=20with=20the=20DNS=20registry. Here=20are=20my=20provisional=20answers=20for=20your=20review. Ad=201)=20Yes,=20we=20do=20need=20a=20registry.=20This=20is=20the=20only=20= way=20to=20really=20cut down=20ambiguity=20in=20referring=20to=20TV=20channels. Ad=202)=20The=20responsibility=20of=20the=20registry=20would=20reside=20wi= th=20ICANN.=20ICANN would=20delegate=20the=20technical=20work=20to=20a=20third=20party.=20An=20= example=20of=20such=20a delegation=20is=20User=20ENUM,=20for=20which=20ICANN=20has=20delegated=20t= he=20e164.arpa root=20to=20RIPE. Ad=203)=20The=20registry=20will=20contain=20a=20list=20of=20unique=20tv:UR= I's,=20to=20each=20entry information=20is=20associated=20on=20the=20TV=20broadcast=20that=20it=20id= entifies,=20like broadcaster,=20language(s),=20geographic=20reach=20and=20other.=20The=20re= gistry=20will serve=20two=20purposes. -Identification:=20learning=20which=20TV=20broadcast=20is=20identified=20b= y=20a=20specific tv:URI. -Search:=20finding=20the=20tv:URI=20of=20a=20specific=20TV=20broadcast. Ad=204)=20Any=20person=20or=20organization=20can=20"nominate"=20a=20TV=20b= roadcast=20for registration.=20This=20person=20or=20organization=20should=20provide=20evi= dence=20that the=20TV=20broadcast=20exists=20and=20that=20it=20has=20not=20been=20previ= ously=20registered. The=20registry=20will=20subsequently=20assign=20a=20tv:URI=20to=20the=20br= oadcast following=20the=20RFC2838=20guidelines. Ad=205)=20The=20relationship=20with=20the=20DNS=20registry=20will=20be=20a= s=20described=20in RFC2838.=20That=20is,=20DNS-style=20domain=20name=20syntax=20is=20used=20t= o=20identify=20a broadcast.=20Further=20then=20this=20syntactic=20relation=20we=20do=20not=20= foresee=20any relation=20with=20the=20DNS.=20Note=20that=20this=20implies=20-=20as=20alr= eady=20stated=20in RFC2838=20-=20that=20it=20is=20not=20the=20intention=20that=20tv:URI's=20a= re=20resolved through=20the=20DNS. Please=20let=20me=20know=20your=20reactions=20on=20these=20thoughts. Best=20regards, Oskar=20van=20Deventer=20&=20Iko=20Keesmaat -------------------------------- dr.ir.=20M.=20Oskar=20van=20Deventer TNO=20Information=20and=20Communication=20Technology P.O.=20box=205050 2600=20GB=20=20Delft Netherlands +31=20651=20914=20918 oskar.vandeventer@tno.nl -------------------------------- Connecting=20to=20a=20TNO=20colleague?=20Call=20+31=2015=20285=2075=2075 This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html From discuss-bounces@apps.ietf.org Mon Oct 02 10:15:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOYX-0006MC-9p; Mon, 02 Oct 2006 10:14:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOYV-0006M1-P4 for discuss@apps.ietf.org; Mon, 02 Oct 2006 10:14:03 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOYU-0007K0-Cj for discuss@apps.ietf.org; Mon, 02 Oct 2006 10:14:03 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 02 Oct 2006 07:14:02 -0700 X-IronPort-AV: i="4.09,244,1157353200"; d="scan'208"; a="327305713:sNHT55453760" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92EE1eg015515; Mon, 2 Oct 2006 07:14:01 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k92EE1ql002573; Mon, 2 Oct 2006 07:14:01 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4612.cisco.com [10.61.82.3]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k92E2xjc020239; Mon, 2 Oct 2006 07:02:59 -0700 Message-ID: <45211EA6.3000107@cisco.com> Date: Mon, 02 Oct 2006 16:13:58 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "Deventer, M.O. \(Oskar\) van" Subject: Re: Reigistry for tv:URI's References: <42F3BE57026C6E49B09E267EEF639D5601246747@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D5601246747@ms-dt01thalia.tsn.tno.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-3.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3598; t=1159798441; x=1160662441; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20Reigistry=20for=20tv=3AURI's; X=v=3Dcisco.com=3B=20h=3DYZOaM91+LayXNE3QdvYA/ypSDi4=3D; b=sc1iV2p1omjA663QTCDofLE6yrKg6rCdz7htIactmKv8dKaxMcJ3UtYwEY6EC4WFTQVpseQA Xjgt4XqVVjIRB5rJJWSLUZuY/U2D44P0XqBVVQnCuT+a4TvC9gYcVn34; X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: discuss@apps.ietf.org, "Zigmond, Dan" , "Keesmaat, N.W. \(Iko\)" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Dear Mr. Deventer, I read your message and while I haven't thought much about the problem space, I do know that there is a tremendous amount of information in national databases already. For instance, you can access engineering data such as frequency reach via the FCC CDBS database. Similar information seems to be available via OFCOM in the UK, and I presume it will be available in many other countries. Is this something you will take advantage of? Eliot Deventer, M.O. (Oskar) van 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. > > 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 > > From discuss-bounces@apps.ietf.org Mon Oct 02 16:04:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUU0g-0000bM-HP; Mon, 02 Oct 2006 16:03:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUU0f-0000WZ-CI for discuss@apps.ietf.org; Mon, 02 Oct 2006 16:03:29 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUU0e-0008Fz-2k for discuss@apps.ietf.org; Mon, 02 Oct 2006 16:03:29 -0400 Received: by ug-out-1314.google.com with SMTP id k3so569764ugf for ; Mon, 02 Oct 2006 13:03:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=KlLRryyyXOK7SwTvTgHAp6mPefZyEZVvbuj1EWV4cMhlOhBcRsVhX6VXrXwuSwLdyS1GfjEjsFwP2rOXgqIITCn8DQK+2oG6SDCyVJWVMTJuzWqPAGuG2ikJs/PKZ28I7POoimpUKM1yEC7XtohNqz3CfW/7dxPYhvGurFPusH8= Received: by 10.78.203.15 with SMTP id a15mr1671763hug; Mon, 02 Oct 2006 13:03:26 -0700 (PDT) Received: by 10.78.168.14 with HTTP; Mon, 2 Oct 2006 13:03:25 -0700 (PDT) Message-ID: Date: Mon, 2 Oct 2006 16:03:25 -0400 From: "Mark Baker" To: "Deventer, M.O. (Oskar) van" Subject: Re: Reigistry for tv:URI's In-Reply-To: <42F3BE57026C6E49B09E267EEF639D5601246747@ms-dt01thalia.tsn.tno.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <42F3BE57026C6E49B09E267EEF639D5601246747@ms-dt01thalia.tsn.tno.nl> X-Google-Sender-Auth: 3082a28e81f0a94c X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: discuss@apps.ietf.org, "Zigmond, Dan" , "Keesmaat, N.W. \(Iko\)" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Some questions ... On 10/2/06, Deventer, M.O. (Oskar) van wrote: > 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. So would there be any relationship between, say, "tv:nbc.com" and General Electric (the current owner, per the DNS)? If yes, do you intend to reuse the association already maintained by the DNS/ICANN, or do you intend to create a new registry to make this association? If not, don't you think General Electric might express concern about not owning the set of tv URIs using the nbc.com name? You also mentioned that anybody would be able to register a tv URI. Again, don't you think GE (or Disney or ...) would balk at that? > Note that this implies - as already stated in > RFC2838 - that it is not the intention that tv:URI's are resolved > through the DNS. It sounds like you're leaving the door open to resolvable URIs which is good, but what would you recommend for those that want them? And a meta question; would this discussion not be more appropriate for the URI list (uri@w3.org)? Cheers, Mark. From discuss-bounces@apps.ietf.org Tue Oct 03 05:01:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUg8k-0007Fb-KR; Tue, 03 Oct 2006 05:00:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUg8j-00078Q-1s for discuss@apps.ietf.org; Tue, 03 Oct 2006 05:00:37 -0400 Received: from mail91.messagelabs.com ([194.106.220.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUg8h-0002x2-Fu for discuss@apps.ietf.org; Tue, 03 Oct 2006 05:00:37 -0400 X-VirusChecked: Checked X-Env-Sender: oskar.vandeventer@tno.nl X-Msg-Ref: server-9.tower-91.messagelabs.com!1159866033!16141004!1 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 24104 invoked from network); 3 Oct 2006 09:00:33 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-9.tower-91.messagelabs.com with SMTP; 3 Oct 2006 09:00:33 -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 k9390XB14093; Tue, 3 Oct 2006 11:00:33 +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); Tue, 3 Oct 2006 11:00:32 +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: Tue, 3 Oct 2006 11:00:32 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D5601246756@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D5601246751@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reigistry for tv:URI's Thread-Index: AcbmLwBDUDFuefTeQkWyNiIUXotslQAAAtzQACbIglA= From: "Deventer, M.O. \(Oskar\) van" To: , "Lear, Eliot" X-OriginalArrivalTime: 03 Oct 2006 09:00:32.0907 (UTC) FILETIME=[62075DB0:01C6E6CA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: "Keesmaat, N.W. \(Iko\)" , "Zigmond, Dan" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org =20 Dear=20Eliot, >=20FCC=20CDBS=20database=20... >=20...=20available=20via=20OFCOM=20... >=20Is=20this=20something=20you=20will=20take=20advantage=20of? What=20we=20would=20like=20to=20have=20is=20a=20registry=20that=20associat= es=20identifying information=20with=20tv:URIs.=20As=20such,=20information=20from=20the=20da= tabases=20that you=20mentioned=20could=20be=20useful: 1)=20When=20registring=20a=20TV=20broadcast,=20there=20should=20be=20proof= =20that=20the=20TV broadcast=20exists.=20Info=20in=20the=20FCC=20database=20could=20serve=20a= s=20such=20a=20proof.=20 2)=20Moreover,=20the=20tv:URI=20registration=20could=20include=20a=20refer= ence=20to=20that info=20in=20the=20FCC=20(or=20OFCOM)=20databases. Note=20that=20we=20also=20want=20to=20include=20TV=20broadcasts=20that=20a= re=20not=20associated to=20terrestrial=20frequencies,=20e.g.=20cable=20TV,=20satellite=20TV=20an= d=20IPTV. Oskar -----Original=20Message----- From:=20Eliot=20Lear=20[mailto:lear@cisco.com]=20 Sent:=20maandag=202=20oktober=202006=2016:14 To:=20Deventer,=20M.O.=20(Oskar)=20van Cc:=20discuss@apps.ietf.org;=20Keesmaat,=20N.W.=20(Iko);=20Zigmond,=20Dan Subject:=20Re:=20Reigistry=20for=20tv:URI's Dear=20Mr.=20Deventer, I=20read=20your=20message=20and=20while=20I=20haven't=20thought=20much=20a= bout=20the=20problem space,=20I=20do=20know=20that=20there=20is=20a=20tremendous=20amount=20of=20= information=20in national=20databases=20already.=20=20For=20instance,=20you=20can=20access=20= engineering data=20such=20as=20frequency=20reach=20via=20the=20FCC=20CDBS=20database.=20= =20Similar information=20seems=20to=20be=20available=20via=20OFCOM=20in=20the=20UK,=20= and=20I=20presume=20it will=20be=20available=20in=20many=20other=20countries.=20=20Is=20this=20so= mething=20you=20will take=20advantage=20of? Eliot Deventer,=20M.O.=20(Oskar)=20van=20wrote: >=20All, > >=20In=20the=20tv:URI=20discussions=20on=20this=20mailing=20list,=20the=20= creation=20of=20a >=20registry=20was=20gently=20suggested=20by=20several=20people.=20I=20am=20= now=20starting=20to >=20believe=20this=20is=20the=20only=20way=20to=20really=20cut=20down=20am= biguity.=20So=20I=20would >=20like=20to=20focus=20the=20discussion=20on=20the=20creation=20of=20such= =20a=20registry. > >=20This=20also=20means=20that=20I=20am=20withdrawing=20my=20suggestions=20= to=20modify=20the >=20tv:URI=20syntax,=20or=20making=20links=20between=20tv:URI's=20and=20th= e=20"official" >=20webpage=20of=20a=20TV=20channel.=20So=20for=20the=20scope=20of=20the=20= registry=20discussion, >=20we'll=20be=20talking=20about=20tv:URI's=20that=20refer=20purely=20to=20= TV=20channels=20and >=20that=20are=20pure=20DNS-style=20identifiers,=20as=20described=20in=20R= FC2838 > >=20I=20think=20the=20following=20questions=20are=20relevant: >=201)=20Do=20we=20need=20a=20registry=20and=20why? >=202)=20How=20should=20such=20a=20registry=20be=20organized? >=203)=20What=20type=20of=20information=20should=20be=20registered? >=204)=20How=20are=20registrations=20created,=20read,=20updated,=20and=20d= eleted=20(CRUD)? >=205)=20What=20is=20the=20relationship=20with=20existing=20registries? >=20=20=20=20=20=20-...=20in=20particular=20with=20the=20DNS=20registry. > >=20Here=20are=20my=20provisional=20answers=20for=20your=20review. > >=20Ad=201)=20Yes,=20we=20do=20need=20a=20registry.=20This=20is=20the=20on= ly=20way=20to=20really=20cut >=20down=20ambiguity=20in=20referring=20to=20TV=20channels. > >=20Ad=202)=20The=20responsibility=20of=20the=20registry=20would=20reside=20= with=20ICANN. ICANN >=20would=20delegate=20the=20technical=20work=20to=20a=20third=20party.=20= An=20example=20of=20such a >=20delegation=20is=20User=20ENUM,=20for=20which=20ICANN=20has=20delegated= =20the=20e164.arpa >=20root=20to=20RIPE. > >=20Ad=203)=20The=20registry=20will=20contain=20a=20list=20of=20unique=20t= v:URI's,=20to=20each entry >=20information=20is=20associated=20on=20the=20TV=20broadcast=20that=20it=20= identifies,=20like >=20broadcaster,=20language(s),=20geographic=20reach=20and=20other.=20The=20= registry will >=20serve=20two=20purposes. >=20-Identification:=20learning=20which=20TV=20broadcast=20is=20identified= =20by=20a specific >=20tv:URI. >=20-Search:=20finding=20the=20tv:URI=20of=20a=20specific=20TV=20broadcast= . > >=20Ad=204)=20Any=20person=20or=20organization=20can=20"nominate"=20a=20TV= =20broadcast=20for >=20registration.=20This=20person=20or=20organization=20should=20provide=20= evidence=20that >=20the=20TV=20broadcast=20exists=20and=20that=20it=20has=20not=20been=20p= reviously registered. >=20The=20registry=20will=20subsequently=20assign=20a=20tv:URI=20to=20the=20= broadcast >=20following=20the=20RFC2838=20guidelines. > >=20Ad=205)=20The=20relationship=20with=20the=20DNS=20registry=20will=20be= =20as=20described=20in >=20RFC2838.=20That=20is,=20DNS-style=20domain=20name=20syntax=20is=20used= =20to=20identify=20a >=20broadcast.=20Further=20then=20this=20syntactic=20relation=20we=20do=20= not=20foresee=20any >=20relation=20with=20the=20DNS.=20Note=20that=20this=20implies=20-=20as=20= already=20stated=20in >=20RFC2838=20-=20that=20it=20is=20not=20the=20intention=20that=20tv:URI's= =20are=20resolved >=20through=20the=20DNS. > >=20Please=20let=20me=20know=20your=20reactions=20on=20these=20thoughts. > >=20Best=20regards, > >=20Oskar=20van=20Deventer=20&=20Iko=20Keesmaat > >=20-------------------------------- >=20dr.ir.=20M.=20Oskar=20van=20Deventer >=20TNO=20Information=20and=20Communication=20Technology >=20P.O.=20box=205050 >=202600=20GB=20=20Delft >=20Netherlands >=20+31=20651=20914=20918 >=20oskar.vandeventer@tno.nl >=20-------------------------------- >=20Connecting=20to=20a=20TNO=20colleague?=20Call=20+31=2015=20285=2075=20= 75 > >=20This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISC= LAIMER=20at http://www.tno.nl/disclaimer/email.html > >=20=20=20 This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html From discuss-bounces@apps.ietf.org Tue Oct 03 07:00:13 2006 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 To: "Deventer, M.O. \\(Oskar\\) van" , 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" , "Keesmaat, N.W. \\\(Iko\\\)" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Monday, 02 October, 2006 14:03 +0200 "Deventer, M.O. \\(Oskar\\) van" 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 From discuss-bounces@apps.ietf.org Tue Oct 03 11:43:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmPf-0001Wf-RK; Tue, 03 Oct 2006 11:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUi6c-0005Eq-UN for discuss@apps.ietf.org; Tue, 03 Oct 2006 07:06:34 -0400 Received: from mail139.messagelabs.com ([85.158.137.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUi6Y-0001Sc-8x for discuss@apps.ietf.org; Tue, 03 Oct 2006 07:06:34 -0400 X-VirusChecked: Checked X-Env-Sender: iko.keesmaat@tno.nl X-Msg-Ref: server-10.tower-139.messagelabs.com!1159873584!5046011!1 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 14635 invoked from network); 3 Oct 2006 11:06:24 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-10.tower-139.messagelabs.com with SMTP; 3 Oct 2006 11:06:24 -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 k93B6NB02271; Tue, 3 Oct 2006 13:06:23 +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); Tue, 3 Oct 2006 13:06:23 +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: Tue, 3 Oct 2006 13:06:22 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56D38E10@ms-dt01thalia.tsn.tno.nl> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reigistry for tv:URI's Thread-Index: AcbmXdp+TQ21bRasR52GRo88UEyetgAbPCiw From: "Keesmaat, N.W. \(Iko\)" To: "Mark Baker" X-OriginalArrivalTime: 03 Oct 2006 11:06:23.0071 (UTC) FILETIME=[F646F6F0:01C6E6DB] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 X-Mailman-Approved-At: Tue, 03 Oct 2006 11:42:30 -0400 Cc: discuss@apps.ietf.org, "Zigmond, Dan" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Mark, I=20tried=20looking=20up=20the=20owner=20of=20nbc.com=20(using=20various=20= web-based=20whois service),=20but=20I=20could=20not=20find=20details.=20The=20website=20www.= nbc.com=20points at=20the=20NBC=20TV=20channel/broadcast.=20=20I=20suspect=20that=20GE=20ow= ns=20NBC? In=20our=20view=20the=20tv:URI=20should=20identify=20a=20TV=20broadcast.=20= Looking=20at=20the=20TV=20broadcast=20known=20in=20the=20USA=20as=20NBC=20= (via=20the=20website http://www.nbc.com),=20then=20we=20can=20see=20that=20it=20has=20four=20di= fferent schedules:=20E=20(Eastern),=20C=20(Central),=20M=20(Mountain),=20and=20P=20= (Pacific). These=20four=20TV=20broadcasts=20can=20be=20seen=20as=20four=20different=20= ones,=20so=20we=20may need=20the=20following=20tv:URIs: *=20eastern.nbc.com *=20central.nbc.com *=20mountain.nbc.com *=20pacific.nbc.com On=20the=20other=20hand=20according=20to=20the=20website=20of=20the=20comp= any=20'owning'=20NBC, NBC=20Universal,=20there=20are=2010=20TV=20stations=20transmitting=20NBC:=20= WNBC=20(NBC4=20New York),=20KNBC=20(NBC4=20Los=20Angeles),=20WMAQ=20(NBC5=20Chicago),=20etc.=20= So=20we=20may=20also need=20the=20following=20tv:URIs: *=20wnbc.nbc.com *=20knbc.nbc.com *=20wmaq.nbc.com etc. The=20tv:URI=20registry=20that=20we=20need=20here=20will=20contain=20the=20= list=20of=20available tv:URIs,=20i.e.=20eastern.nbc.com,=20wnbc.nbc.com,=20etc.=20and=20to=20eac= h=20tv:URI=20in the=20list=20information=20is=20associated=20identifying=20the=20TV=20broa= dcast.=20 For=20instance: tv:eastern.nbc.com=20=3D>=20"The=20eastern=20schedule=20of=20the=20NBC=20T= V=20broadcast=20in the=20USA,=20website=20reference=20http://www.nbc.com" tv:wnbc.nbc.com=20=3D>=20"The=20TV=20broadcast=20transmitted=20by=20the=20= TV=20station=20WNBC (NBC4=20New=20York)=20of=20NBC=20Universal,=20website=20reference http://www.nbcuni.com/About_NBC_Universal/Company_Overview/overview02.sh tml" Regarding=20the=20involvement=20of=20the=20company=20NBC=20or=20the=20comp= any=20GE=20in=20the tv:URIs=20mentioned=20above: *=20if=20they=20get=20involved=20in=20specifying=20the=20information=20ass= ociated=20to=20the tv:URIs=20mentioned,=20they=20are=20very=20welcome.=20 *=20if=20they=20do=20not=20want=20to=20get=20involved=20in=20specifying=20= the=20information associated=20to=20the=20tv:URIs=20mentioned,=20fine=20as=20well. They=20do=20not=20have=20to=20get=20involved,=20but=20they=20are=20sure=20= welcome. The=20main=20relation=20with=20the=20DNS=20domain=20name=20nbc.com=20is=20= by=20'human' association.=20Someone=20wanting=20to=20have=20information=20about tv:eastern.nbc.com,=20might=20have=20a=20look=20at=20a=20website=20http://= www.nbc.com=20as mentioned=20in=20the=20tv:URI=20registry.=20Looking=20up=20the=20domain=20= nbc.com=20(via whois)=20would=20perhaps=20be=20less=20successful=20for=20explaining=20wha= t tv:eastern.nbc.com=20points=20at. So=20actually=20there=20is=20in=20our=20view=20no=20hard=20relationship=20= between=20tv:URIs and=20domain=20names. About=20the=20resolvability=20of=20tv:URIs=20we=20have=20a=20future=20hope= =20that=20they=20might become=20resolvable=20by=20automatic=20means.=20But=20in=20the=20mean=20ti= me=20we=20are=20quite happy=20at=20getting=20the=20list=20of=20available=20tv:URIs=20and=20some=20= identifying information.=20At=20configuration=20of=20a=20TV=20application,=20the=20tv:= URI=20can=20then be=20configured=20by=20human=20intervention=20after=20a=20lookup=20in=20th= e=20tv:URI registry.=20Note=20that=20a=20similar=20situation=20already=20exists=20in=20= Europe=20in=20case of=20the=20use=20of=20Showview=20(see=20http://www.showview.com):=20each=20= buyer=20of=20a video/hard=20disk=20recorder=20with=20Showview=20needs=20to=20configure=20= the=20mapping=20of Showview=20channels=20onto=20actual=20TV=20channels. Making=20the=20resovability=20dependent=20on=20the=20DNS=20system=20is=20n= ot=20our=20intention as=20this=20would=20*force*=20each=20tv:URI=20resolving=20to=20be=20depend= ent=20on=20the cooperation=20of=20the=20domain=20name=20owner=20of=20the=20(super)domain=20= in=20the=20tv:URI. Iko=20Keesmaat=20(and=20Oskar=20van=20Deventer). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Iko=20Keesmaat TNO=20Information=20and=20Communication=20Technology The=20Netherlands E-mail:=20iko.keesmaat@tno.nl -----Original=20Message----- From:=20mbaker@gmail.com=20[mailto:mbaker@gmail.com]=20On=20Behalf=20Of=20= Mark=20Baker Sent:=20maandag=202=20oktober=202006=2022:03 To:=20Deventer,=20M.O.=20(Oskar)=20van Cc:=20discuss@apps.ietf.org;=20Keesmaat,=20N.W.=20(Iko);=20Zigmond,=20Dan Subject:=20Re:=20Reigistry=20for=20tv:URI's Some=20questions=20... On=2010/2/06,=20Deventer,=20M.O.=20(Oskar)=20van=20=20wrote: >=20Ad=205)=20The=20relationship=20with=20the=20DNS=20registry=20will=20be= =20as=20described=20in >=20RFC2838.=20That=20is,=20DNS-style=20domain=20name=20syntax=20is=20used= =20to=20identify=20a >=20broadcast.=20Further=20then=20this=20syntactic=20relation=20we=20do=20= not=20foresee=20any >=20relation=20with=20the=20DNS. So=20would=20there=20be=20any=20relationship=20between,=20say,=20"tv:nbc.c= om"=20and General=20Electric=20(the=20current=20owner,=20per=20the=20DNS)?=20=20If=20= yes,=20do=20you intend=20to=20reuse=20the=20association=20already=20maintained=20by=20the=20= DNS/ICANN, or=20do=20you=20intend=20to=20create=20a=20new=20registry=20to=20make=20th= is=20association? If=20not,=20don't=20you=20think=20General=20Electric=20might=20express=20c= oncern=20about not=20owning=20the=20set=20of=20tv=20URIs=20using=20the=20nbc.com=20name? You=20also=20mentioned=20that=20anybody=20would=20be=20able=20to=20registe= r=20a=20tv=20URI. Again,=20don't=20you=20think=20GE=20(or=20Disney=20or=20...)=20would=20bal= k=20at=20that? >=20Note=20that=20this=20implies=20-=20as=20already=20stated=20in >=20RFC2838=20-=20that=20it=20is=20not=20the=20intention=20that=20tv:URI's= =20are=20resolved >=20through=20the=20DNS. It=20sounds=20like=20you're=20leaving=20the=20door=20open=20to=20resolvabl= e=20URIs=20which is=20good,=20but=20what=20would=20you=20recommend=20for=20those=20that=20w= ant=20them? And=20a=20meta=20question;=20would=20this=20discussion=20not=20be=20more=20= appropriate=20for the=20URI=20list=20(uri@w3.org)? Cheers, Mark. This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html From discuss-bounces@apps.ietf.org Tue Oct 03 12:14:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmu1-0007Mj-HP; Tue, 03 Oct 2006 12:13:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmu0-0007MI-KA for discuss@apps.ietf.org; Tue, 03 Oct 2006 12:13:52 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmtz-0007dd-6J for discuss@apps.ietf.org; Tue, 03 Oct 2006 12:13:52 -0400 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5F555142284; Tue, 3 Oct 2006 09:13:42 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18743-09; Tue, 3 Oct 2006 09:13:41 -0700 (PDT) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CA61114226E; Tue, 3 Oct 2006 09:13:40 -0700 (PDT) In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56D38E10@ms-dt01thalia.tsn.tno.nl> References: <42F3BE57026C6E49B09E267EEF639D56D38E10@ms-dt01thalia.tsn.tno.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-30--951292511 Message-Id: <881C4925-8842-4F6E-9D6A-3D6C65343F38@osafoundation.org> From: Lisa Dusseault Subject: Re: Reigistry for tv:URI's Date: Tue, 3 Oct 2006 09:13:37 -0700 To: "Keesmaat, N.W. (Iko)" X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Mark Baker , "Zigmond, Dan" , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-30--951292511 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Resolvability might be a local matter in the meantime. A device could have a configuration list of available channels containing their tv:URIs and their frequencies or other information on how to access. Then when that device receives a tv: URI it is perfectly capable of turning on the right channel. To schedule recordings or publicize showings, this could all be quite useful. Lisa On Oct 3, 2006, at 4:06 AM, Keesmaat, N.W. (Iko) wrote: > About the resolvability of tv:URIs we have a future hope that they > might > become resolvable by automatic means. But in the mean time we are > quite > happy at getting the list of available tv:URIs and some identifying > information. At configuration of a TV application, the tv:URI can then > be configured by human intervention after a lookup in the tv:URI > registry. Note that a similar situation already exists in Europe in > case > of the use of Showview (see http://www.showview.com): each buyer of a > video/hard disk recorder with Showview needs to configure the > mapping of > Showview channels onto actual TV channels. --Apple-Mail-30--951292511 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Resolvability might be a local = matter in the meantime.=A0 A device could have a configuration list of = available channels containing their tv:URIs and their frequencies or = other information on how to access.=A0 =A0Then when that device receives = a tv: URI it is perfectly capable of turning on the right channel.=A0 To = schedule recordings or publicize showings, this could all be quite = useful.

Lisa

On = Oct 3, 2006, at 4:06 AM, Keesmaat, N.W. (Iko) wrote:

About the resolvability of = tv:URIs we have a future hope that they might

become resolvable by = automatic means. But in the mean time we are quite

happy at getting the list of = available tv:URIs and some identifying

information. At configuration of a TV = application, the tv:URI can then

be configured by human intervention after a lookup in = the tv:URI

registry. = Note that a similar situation already exists in Europe in = case

of the = use of Showview (see http://www.showview.com): each = buyer of a

video/hard disk recorder with Showview needs to configure the = mapping of

Showview = channels onto actual TV channels.

=

= --Apple-Mail-30--951292511-- From discuss-bounces@apps.ietf.org Wed Oct 04 07:51:02 2006 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, 4 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" To: "Klensin, John" 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" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John, >=20Just=20so=20you=20have=20your=20facts=20straight >=20...=20ICANN=20...=20IANA=20...=20IAB=20...=20e164.arpa Thank=20you=20for=20these=20facts. What=20I=20want=20to=20achieve=20is=20that=20the=20new=20registry=20will=20= be=20accredited.=20Like e164.arpa=20is=20the=20"golden=20tree"=20of=20user=20ENUM,=20the=20registr= y=20should=20become the=20"golden=20registry"=20for=20tv:URIs.=20Do=20you=20have=20a=20suggest= ion=20how=20we=20could achieve=20this? >=20large=20volume=20of=20information,=20with=20additions=20being=20 >=20made=20on=20a=20very=20frequent=20basis What=20is=20the=20reason=20of=20your=20worry?=20Verisign=20handled=20about= =205000=20new=20.com registrations=20yesterday.=20In=20contrast,=20how=20many=20new=20televisio= n=20broadcasts have=20been=20introduced=20in=20the=20USA=20yesterday?=20And=20how=20many=20= stations=20have changed=20call=20sign=20yesterday?=20One=20perhaps?=20Or=20were=20there=20= no=20changes=20at all=20yesterday? >=20If=20a=20station=20changes=20ownership=20but=20not=20call >=20signs,=20do=20URIs=20remain=20stable?=20=20 >=20...mechanisms=20to=20keep=20the=20registry=20up=20to=20date?=20... >=20If=20programming=20belongs=20to=20a=20producer,=20how=20is=20that >=20reflected=20in=20the=20system? >=20stable=20enough=20to=20be=20useful? >=20...how=20would=20you=20propose=20to=20enforce=20that? These=20are=20all=20valid=20questions,=20which=20we=20will=20work=20out=20= in=20more=20detail=20in an=20internet=20draft. -As=20tv:URIs=20identify=20television=20broadcasts,=20a=20change=20of=20ow= nership=20is irrelevant=20to=20the=20tv:URI.=20If=20there=20is=20anyone=20who=20wants=20= to=20have=20the ownership=20info=20changed=20in=20the=20registration=20record,=20then=20he= =20can=20request that=20and=20the=20registry=20will=20make=20the=20change. -The=20whole=20idea=20of=20"nomination"=20is=20that=20if=20nobody=20asks=20= for=20changes,=20no changes=20are=20made.=20If=20I=20were=20a=20service=20provider=20of=20adva= nced=20television presence=20and=20messaging=20services,=20I=20would=20regularly=20check=20i= f=20there=20are new=20TV=20channels=20that=20my=20customers=20are=20watching,=20and=20make= =20an=20effort=20to keep=20the=20registry=20up=20to=20date,=20at=20least=20for=20the=20TV=20ch= annels=20in=20my=20area. >=20why=20a=20"guess=20the=20URI"=20mechanism=20with=20central,=20 >=20infrastructure,=20administration=20makes=20sense.=20=20 At=20the=20discuss@apps.ietf.org=20mailing=20list=20some=20consensus=20see= med=20to=20arise that=20without=20a=20central=20registry=20it=20would=20not=20be=20possible= =20to=20have=20an effective=20use=20of=20tv:URIs.=20The=20initial=20RFC=20(RFC2838)=20indeed= =20proposed=20a "guess=20the=20URI"=20mechanism,=20but=20enough=20examples=20have=20been=20= given illustrating=20that=20this=20would=20always=20lead=20to=20ambiguity.=20The= =20proposal=20of having=20a=20central=20registry=20is=20not=20to=20go=20into=20a=20"guess=20= the=20URI"=20mode,=20but to=20have=20a=20database=20for=20looking=20up=20the=20"proper"=20tv:URI.=20= Of=20course=20once such=20a=20central=20database=20(a.k.a.=20registry)=20exists,=20search=20m= achines=20may=20be employed=20for=20finding=20a=20particular=20tv:URI.=20The=20use=20of=20the= =20tv:URI, however,=20should=20not=20be=20dependent=20on=20the=20use=20of=20search=20= machines.=20It=20is highly=20preferable=20that=20it=20be=20possible=20for=20humans=20to=20type= =20in=20a=20television broadcast=20identifier=20(after=20having=20searched=20the=20tv:URI=20in=20= the=20registry, or=20by=20reading=20it=20from=20advertisements=20or=20otherwise). >=20via=20ITU,=20probably=20the=20Radio=20Sector ITU-R=20is=20about=20frequencies=20and=20call=20signs=20of=20terrestrial=20= radio/TV broadcasts=20(i.e.=20making=20use=20of=20through-the-air=20radio=20waves).= =20It=20is=20not about=20cable=20TV,=20nor=20satellite=20TV,=20nor=20IPTV,=20nor=20webTV.=20= tv:URIs=20are=20about television=20broadcasts,=20independent=20of=20the=20transmission=20technol= ogies used,=20see=20RFC2838. >=20trademark=20and=20control=20issues One=20of=20the=20tasks=20of=20the=20tv:URI=20registry=20is=20to=20handle=20= trademark=20issues. This=20is=20exactly=20the=20same=20as=20with=20DNS=20registry's.=20 Oskar=20van=20Deventer=20&=20Iko=20Keesmaat=20 -----Original=20Message----- From:=20John=20C=20Klensin=20[mailto:john-ietf@jck.com]=20 Sent:=20dinsdag=203=20oktober=202006=2012:59 To:=20Deventer,=20M.O.=20(Oskar)=20van;=20discuss@apps.ietf.org Cc:=20Keesmaat,=20N.W.=20(Iko);=20Zigmond,=20Dan Subject:=20Re:=20Reigistry=20for=20tv:URI's --On=20Monday,=2002=20October,=202006=2014:03=20+0200=20"Deventer,=20M.O. \\(Oskar\\)=20van"=20=20wrote: >=20All, >=20 >=20In=20the=20tv:URI=20discussions=20on=20this=20mailing=20list,=20the=20= creation >=20of=20a=20registry=20was=20gently=20suggested=20by=20several=20people.=20= I=20am=20now >=20starting=20to=20believe=20this=20is=20the=20only=20way=20to=20really=20= cut=20down >=20ambiguity.=20So=20I=20would=20like=20to=20focus=20the=20discussion=20o= n=20the >=20creation=20of=20such=20a=20registry. >... =20 >=20Ad=202)=20The=20responsibility=20of=20the=20registry=20would=20reside=20= with >=20ICANN.=20ICANN=20would=20delegate=20the=20technical=20work=20to=20a=20= third >=20party.=20An=20example=20of=20such=20a=20delegation=20is=20User=20ENUM,= =20for=20which >=20ICANN=20has=20delegated=20the=20e164.arpa=20root=20to=20RIPE. Just=20so=20you=20have=20your=20facts=20straight=20on=20starting,=20ICANN (actually=20the=20IANA)=20made=20that=20delegation=20when=20instructed=20t= o=20by the=20IAB,=20which=20=20has=20management=20control=20of=20the=20ARPA=20TLD= .=20=20ICANN was=20not=20involved=20in=20the=20choice=20of=20where=20it=20was=20delegat= ed. ICANN=20does=20occasionally=20create=20and=20registries=20on=20its=20own.=20= =20If you=20want=20such=20a=20registry,=20you=20should=20be=20discussing=20it=20= with ICANN,=20not=20here.=20=20=20But=20e164.arpa=20is=20not=20an=20example=20o= f=20an ICANN-created=20or=20managed=20registry. >=20Ad=203)=20The=20registry=20will=20contain=20a=20list=20of=20unique=20t= v:URI's,=20to >... >=20Ad=204)=20Any=20person=20or=20organization=20can=20"nominate"=20a=20TV= =20broadcast >=20for=20registration.=20This=20person=20or=20organization=20should=20pro= vide >=20evidence=20that=20the=20TV=20broadcast=20exists=20and=20that=20it=20ha= s=20not=20been >=20previously=20registered.=20The=20registry=20will=20subsequently=20assi= gn=20a >=20tv:URI=20to=20the=20broadcast=20following=20the=20RFC2838=20guidelines= . I=20think=20you=20are=20going=20to=20have=20tremendous=20difficulty=20keep= ing=20such a=20registry=20active=20and=20useful.=20=20I=20see=20at=20least=20two=20im= portant problems=20in=20that=20regard.=20=20 First,=20a=20per-broadcast=20registry=20could,=20in=20principle,=20contain= =20a large=20volume=20of=20information,=20with=20additions=20being=20made=20on=20= a=20very frequent=20basis.=20=20Using=20it=20as=20an=20example,=20additions=20to=20= e164.arpa occur=20on=20a=20frequency=20of=20weeks=20or=20months=20and=20we=20know=20= that=20there can=20be=20a=20maximum=20of=20only=20a=20few=20hundred=20entries,=20ever.=20= =20If=20you are=20really=20talking=20about=20registering=20broadcasts,=20that=20may entries=20could=20accumulate=20in=20much=20less=20than=20an=20hour.=20=20E= ven=20if=20you intend=20to=20register=20broadcasters=20or=20stations,=20the=20number=20is= =20huge. These=20broadcasters,=20call=20signs,=20and=20hence,=20usually,=20station names=20and=20station-related=20URLs=20are=20subject=20to=20a=20significan= t number=20of=20governmental=20regulations,=20as=20well=20as=20ownership=20i= ssues for=20both=20stations=20(broadcasters)=20and=20broadcasts=20that=20differ=20= from country=20to=20country.=20=20If=20a=20station=20changes=20ownership=20but=20= not=20call signs,=20do=20URIs=20remain=20stable?=20=20If=20a=20station=20retains=20ma= nagement and=20programming=20but=20changes=20call=20signs,=20do=20URI's=20remain=20= stable? If=20a=20station=20reorganizes=20its=20web=20presence,=20what=20are=20the incentives=20and=20mechanisms=20to=20keep=20the=20registry=20up=20to=20dat= e?=20=20If programming=20belongs=20to,=20and=20is=20made=20available=20from,=20a=20pr= oducer or=20network,=20rather=20than=20linked=20to=20a=20station,=20how=20is=20th= at reflected=20in=20the=20system?=20=20And=20so=20on.=20=20In=20addition,=20g= iven=20any=20of the=20above=20changes,=20how=20would=20you=20expect=20to=20keep=20a=20URI=20= that=20is nominated/registered=20by=20the=20public=20(someone=20with=20no=20affiliat= ion to=20the=20broadcaster=20or=20content=20producer)=20stable=20enough=20to=20= be useful?=20=20Does=20the=20registrant=20take=20on=20any=20formal=20obligati= on=20to manage=20the=20link=20and=20keep=20it=20up=20to=20date=20and=20how=20would= =20you=20propose to=20enforce=20that? Two=20constructive=20observations=20and=20suggestions:=20 (1)=20What=20has=20been=20missing=20from=20your=20discussions=20so=20far=20= is=20why=20a "guess=20the=20URI"=20mechanism=20with=20central,=20infrastructure, administration=20makes=20sense.=20=20When=20I=20think=20of=20all=20the=20d= ifferent ways=20I=20might=20want=20to=20find=20a=20broadcaster=20or=20broadcast,=20= I=20start thinking=20about=20directories=20and=20search=20engines.=20=20But,=20if=20= those are=20the=20entry=20points,=20the=20form=20of=20the=20URI=20they=20uncover= =20is largely=20irrelevant.=20=20=20And,=20if=20directories=20or=20search=20engi= nes=20or databases=20of=20some=20sort=20are=20the=20answer,=20then=20you=20are=20di= scussing=20a business=20opportunity,=20not=20something=20that=20is=20appropriately=20or= usefully=20within=20IETF's=20domain. (2)=20If=20there=20is=20a=20need=20for=20the=20infrastructure=20to=20suppo= rt=20a=20URI with=20more=20or=20less=20elaborate=20structure=20and=20semantics,=20it=20= may actually=20be=20useful=20discussion=20to=20initiate=20via=20ITU,=20probabl= y=20the Radio=20Sector=20rather=20than=20the=20Telecommunications=20Standards=20on= e. They=20have=20the=20necessary=20connections=20with=20the=20call-sign=20mac= hinery and=20regulators=20to=20have=20a=20serious=20discussion=20about=20what=20w= ould=20be necessary=20to=20create=20a=20stable=20identifier=20and=20to=20persuade=20= the relevant=20actors=20to=20pay=20attention. Going=20down=20that=20path=20would=20also=20eliminate=20the=20trademark=20= and control=20issues=20pointed=20out=20by=20others. =20=20=20=20john This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html From discuss-bounces@apps.ietf.org Wed Oct 04 08:11:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV5aM-00063y-AL; Wed, 04 Oct 2006 08:10:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV5aK-00062m-FA for discuss@apps.ietf.org; Wed, 04 Oct 2006 08:10:48 -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 1GV5aJ-0001yi-RZ for discuss@apps.ietf.org; Wed, 04 Oct 2006 08:10:48 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1GV5aI-0006rR-Kh; Wed, 04 Oct 2006 08:10:47 -0400 Date: Wed, 04 Oct 2006 08:10:44 -0400 From: John C Klensin To: "Deventer, M.O. \\(Oskar\\) van" Subject: RE: Reigistry for tv:URI's Message-ID: <66FA2098CEF87D56B693C2FB@[192.168.1.218]> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D5601246765@ms-dt01thalia.tsn.tno.nl> References: <42F3BE57026C6E49B09E267EEF639D5601246765@ms-dt01thalia.tsn.tno.nl> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: discuss@apps.ietf.org, "Zigmond, Dan" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Wednesday, October 04, 2006 13:47 +0200 "Deventer, M.O. \\(Oskar\\) van" wrote: >... > 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? No. e164.arpa depends on two things that may seem invisible. One is management of the registry (to the extent needed) by IAB, not IANA or some other structure. IANA has no, or substantially no, experience managing registries of this type. The second is that RIPE-NCC is authorized to charge cost-recovery fees if needed to support the registry... and the registry is, as I mentioned, small and of low volatility. >> 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? Verisign maintains a very large and expensive infrastructure to add that many registrations. They have an elaborate system of registrars for dealing with end users, most of which charge fees or are otherwise in business to make a profit. When there are conflicts about names, there are ICANN-imposed policies about mechanisms for resolving them. I don't see any of that in your proposal. And, if a URI is to potentially point to a particular broadcast and not to "a series" (whatever that means when one gets down to precise definitions) then the answer to "how many" is in the thousands or more. >> 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. But, if a change of ownership leads to a change of domain name (which it often does), then, unless the URIs are not dependent on those domain names, they immediately become invalid or, worse, subject to errors as domain names are transferred or otherwise reused. > -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. Then perhaps one wants to create a URN tree of service providers and let them take care of the broadcast URI records. >> 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). I am not convinced, but will wait to see a _very_ specific proposal. >> 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. Yes, but you are moving into a newer space. Or consider ITU-T, since a few of their SGs seem to be willing to claim authority over anything transmitted electronically. >> 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. Actually, DNS registries, especially the generic ones, have elaborate rules to avoid getting embroiled in those controversies. See above, or have a look at ICANN's web site and their discussions about "dispute resolution". john From discuss-bounces@apps.ietf.org Wed Oct 04 16:14:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVD7C-0000Wu-6a; Wed, 04 Oct 2006 16:13:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV482-0002h2-Ql for discuss@apps.ietf.org; Wed, 04 Oct 2006 06:37:30 -0400 Received: from mail92.messagelabs.com ([194.106.220.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GV47x-0001B8-64 for discuss@apps.ietf.org; Wed, 04 Oct 2006 06:37:30 -0400 X-VirusChecked: Checked X-Env-Sender: iko.keesmaat@tno.nl X-Msg-Ref: server-2.tower-92.messagelabs.com!1159958243!18758931!1 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 8635 invoked from network); 4 Oct 2006 10:37:23 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-2.tower-92.messagelabs.com with SMTP; 4 Oct 2006 10:37:23 -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 k94AbNB29428 for ; Wed, 4 Oct 2006 12:37:23 +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 12:37:22 +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, 4 Oct 2006 12:37:22 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56D38E14@ms-dt01thalia.tsn.tno.nl> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reigistry for tv:URI's Thread-Index: AcbmXdp+TQ21bRasR52GRo88UEyetgAbPCiw From: "Keesmaat, N.W. \(Iko\)" To: X-OriginalArrivalTime: 04 Oct 2006 10:37:22.0360 (UTC) FILETIME=[13254B80:01C6E7A1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 X-Mailman-Approved-At: Wed, 04 Oct 2006 16:13:12 -0400 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Mark, I=20tried=20looking=20up=20the=20owner=20of=20nbc.com=20(using=20various=20= web-based=20whois service),=20but=20I=20could=20not=20find=20details.=20The=20website=20www.= nbc.com=20points at=20the=20NBC=20TV=20channel/broadcast.=20=20I=20suspect=20that=20GE=20ow= ns=20NBC? In=20our=20view=20the=20tv:URI=20should=20identify=20a=20TV=20broadcast.=20= Looking=20at=20the=20TV=20broadcast=20known=20in=20the=20USA=20as=20NBC=20= (via=20the=20website http://www.nbc.com),=20then=20we=20can=20see=20that=20it=20has=20four=20di= fferent schedules:=20E=20(Eastern),=20C=20(Central),=20M=20(Mountain),=20and=20P=20= (Pacific). These=20four=20TV=20broadcasts=20can=20be=20seen=20as=20four=20different=20= ones,=20so=20we=20may need=20the=20following=20tv:URIs: *=20eastern.nbc.com *=20central.nbc.com *=20mountain.nbc.com *=20pacific.nbc.com On=20the=20other=20hand=20according=20to=20the=20website=20of=20the=20comp= any=20'owning'=20NBC, NBC=20Universal,=20there=20are=2010=20TV=20stations=20transmitting=20NBC:=20= WNBC=20(NBC4=20New York),=20KNBC=20(NBC4=20Los=20Angeles),=20WMAQ=20(NBC5=20Chicago),=20etc.=20= So=20we=20may=20also need=20the=20following=20tv:URIs: *=20wnbc.nbc.com *=20knbc.nbc.com *=20wmaq.nbc.com etc. The=20tv:URI=20registry=20that=20we=20need=20here=20will=20contain=20the=20= list=20of=20available tv:URIs,=20i.e.=20eastern.nbc.com,=20wnbc.nbc.com,=20etc.=20and=20to=20eac= h=20tv:URI=20in the=20list=20information=20is=20associated=20identifying=20the=20TV=20broa= dcast.=20 For=20instance: tv:eastern.nbc.com=20=3D>=20"The=20eastern=20schedule=20of=20the=20NBC=20T= V=20broadcast=20in the=20USA,=20website=20reference=20http://www.nbc.com" tv:wnbc.nbc.com=20=3D>=20"The=20TV=20broadcast=20transmitted=20by=20the=20= TV=20station=20WNBC (NBC4=20New=20York)=20of=20NBC=20Universal,=20website=20reference http://www.nbcuni.com/About_NBC_Universal/Company_Overview/overview02.sh tml" Regarding=20the=20involvement=20of=20the=20company=20NBC=20or=20the=20comp= any=20GE=20in=20the tv:URIs=20mentioned=20above: *=20if=20they=20get=20involved=20in=20specifying=20the=20information=20ass= ociated=20to=20the tv:URIs=20mentioned,=20they=20are=20very=20welcome.=20 *=20if=20they=20do=20not=20want=20to=20get=20involved=20in=20specifying=20= the=20information associated=20to=20the=20tv:URIs=20mentioned,=20fine=20as=20well. They=20do=20not=20have=20to=20get=20involved,=20but=20they=20are=20sure=20= welcome. The=20main=20relation=20with=20the=20DNS=20domain=20name=20nbc.com=20is=20= by=20'human' association.=20Someone=20wanting=20to=20have=20information=20about tv:eastern.nbc.com,=20might=20have=20a=20look=20at=20a=20website=20http://= www.nbc.com=20as mentioned=20in=20the=20tv:URI=20registry.=20Looking=20up=20the=20domain=20= nbc.com=20(via whois)=20would=20perhaps=20be=20less=20successful=20for=20explaining=20wha= t tv:eastern.nbc.com=20points=20at. So=20actually=20there=20is=20in=20our=20view=20no=20hard=20relationship=20= between=20tv:URIs and=20domain=20names. About=20the=20resolvability=20of=20tv:URIs=20we=20have=20a=20future=20hope= =20that=20they=20might become=20resolvable=20by=20automatic=20means.=20But=20in=20the=20mean=20ti= me=20we=20are=20quite happy=20at=20getting=20the=20list=20of=20available=20tv:URIs=20and=20some=20= identifying information.=20At=20configuration=20of=20a=20TV=20application,=20the=20tv:= URI=20can=20then be=20configured=20by=20human=20intervention=20after=20a=20lookup=20in=20th= e=20tv:URI registry.=20Note=20that=20a=20similar=20situation=20already=20exists=20in=20= Europe=20in=20case of=20the=20use=20of=20Showview=20(see=20http://www.showview.com):=20each=20= buyer=20of=20a video/hard=20disk=20recorder=20with=20Showview=20needs=20to=20configure=20= the=20mapping=20of Showview=20channels=20onto=20actual=20TV=20channels. Making=20the=20resovability=20dependent=20on=20the=20DNS=20system=20is=20n= ot=20our=20intention as=20this=20would=20*force*=20each=20tv:URI=20resolving=20to=20be=20depend= ent=20on=20the cooperation=20of=20the=20domain=20name=20owner=20of=20the=20(super)domain=20= in=20the=20tv:URI. Iko=20Keesmaat=20(and=20Oskar=20van=20Deventer). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Iko=20Keesmaat TNO=20Information=20and=20Communication=20Technology The=20Netherlands E-mail:=20iko.keesmaat@tno.nl -----Original=20Message----- From:=20mbaker@gmail.com=20[mailto:mbaker@gmail.com]=20On=20Behalf=20Of=20= Mark=20Baker Sent:=20maandag=202=20oktober=202006=2022:03 To:=20Deventer,=20M.O.=20(Oskar)=20van Cc:=20discuss@apps.ietf.org;=20Keesmaat,=20N.W.=20(Iko);=20Zigmond,=20Dan Subject:=20Re:=20Reigistry=20for=20tv:URI's Some=20questions=20... On=2010/2/06,=20Deventer,=20M.O.=20(Oskar)=20van=20=20wrote: >=20Ad=205)=20The=20relationship=20with=20the=20DNS=20registry=20will=20be= =20as=20described=20in >=20RFC2838.=20That=20is,=20DNS-style=20domain=20name=20syntax=20is=20used= =20to=20identify=20a >=20broadcast.=20Further=20then=20this=20syntactic=20relation=20we=20do=20= not=20foresee=20any >=20relation=20with=20the=20DNS. So=20would=20there=20be=20any=20relationship=20between,=20say,=20"tv:nbc.c= om"=20and General=20Electric=20(the=20current=20owner,=20per=20the=20DNS)?=20=20If=20= yes,=20do=20you intend=20to=20reuse=20the=20association=20already=20maintained=20by=20the=20= DNS/ICANN, or=20do=20you=20intend=20to=20create=20a=20new=20registry=20to=20make=20th= is=20association? If=20not,=20don't=20you=20think=20General=20Electric=20might=20express=20c= oncern=20about not=20owning=20the=20set=20of=20tv=20URIs=20using=20the=20nbc.com=20name? You=20also=20mentioned=20that=20anybody=20would=20be=20able=20to=20registe= r=20a=20tv=20URI. Again,=20don't=20you=20think=20GE=20(or=20Disney=20or=20...)=20would=20bal= k=20at=20that? >=20Note=20that=20this=20implies=20-=20as=20already=20stated=20in >=20RFC2838=20-=20that=20it=20is=20not=20the=20intention=20that=20tv:URI's= =20are=20resolved >=20through=20the=20DNS. It=20sounds=20like=20you're=20leaving=20the=20door=20open=20to=20resolvabl= e=20URIs=20which is=20good,=20but=20what=20would=20you=20recommend=20for=20those=20that=20w= ant=20them? And=20a=20meta=20question;=20would=20this=20discussion=20not=20be=20more=20= appropriate=20for the=20URI=20list=20(uri@w3.org)? Cheers, Mark. This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html From discuss-bounces@apps.ietf.org Wed Oct 04 18:00:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVEmI-00039C-25; Wed, 04 Oct 2006 17:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVEmG-000389-48 for discuss@apps.ietf.org; Wed, 04 Oct 2006 17:59:44 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVEmE-00017f-Sf for discuss@apps.ietf.org; Wed, 04 Oct 2006 17:59:44 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 2C96D5644D; Wed, 4 Oct 2006 17:58:42 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jf+PIYdLNEA; Wed, 4 Oct 2006 17:58:37 -0400 (EDT) Received: from [10.100.110.213] (adsl-070-147-143-107.sip.tys.bellsouth.net [70.147.143.107]) by shu.cs.utk.edu (Postfix) with ESMTP id A37965644B; Wed, 4 Oct 2006 17:58:36 -0400 (EDT) Message-ID: <45242EC6.9090902@cs.utk.edu> Date: Wed, 04 Oct 2006 17:59:34 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "Keesmaat, N.W. \(Iko\)" Subject: Re: Reigistry for tv:URI's References: <42F3BE57026C6E49B09E267EEF639D56D38E14@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56D38E14@ms-dt01thalia.tsn.tno.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > In our view the tv:URI should identify a TV broadcast. I am not sure that this is a good thing. What is important about distinguishing tv: from other URIs? Is it that the signal is encoded using NTSC or PAL? Or will MPEG do? Is it that the signal is transmitted using radio frequency electromagnetic radiation through the air? Or is it okay if the signal is transmitted over cable? What about satellite? Does it matter how it's modulated? IMO, one of the goals of the tv: URI should be to permit convergence so that different sources of video programming can be viewed by the same computer program (or set-top box, whatever) while at the same time presenting the viewer with a reasonably clean user interface for selecting between different sources, and probably allowing those program sources to be linked to from other sources - say from a web page or email reader. That doesn't inherently mean that tv: URI should be usable by any kind of video programming source, but it probably does mean that there should be _some_ level of naming which can be used by any kind of video programming source. From my point-of-view, whether tv: is the higher-level name that maps to one or more lower-level services, or whether tv: is a specific lower-level service and there's a higher-level name (say a URN) to describe the video programming source, is almost arbitrary - as long as the relationship between the two levels of naming is clear. Though it seems that there is already some investment in the tv: URL prefix along the former lines. Keith From discuss-bounces@apps.ietf.org Thu Oct 05 03:38:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNnC-0006CT-0k; Thu, 05 Oct 2006 03:37:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNnA-0006CO-Sb for discuss@apps.ietf.org; Thu, 05 Oct 2006 03:37:16 -0400 Received: from mail93.messagelabs.com ([194.106.220.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVNn4-0006QJ-Fs for discuss@apps.ietf.org; Thu, 05 Oct 2006 03:37:16 -0400 X-VirusChecked: Checked X-Env-Sender: iko.keesmaat@tno.nl X-Msg-Ref: server-13.tower-93.messagelabs.com!1160033768!2224580!1 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 2865 invoked from network); 5 Oct 2006 07:36:08 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-13.tower-93.messagelabs.com with SMTP; 5 Oct 2006 07:36:08 -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 k957a8B08917; Thu, 5 Oct 2006 09:36:08 +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); Thu, 5 Oct 2006 09:36:07 +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: Thu, 5 Oct 2006 09:36:06 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56D38E17@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <45242EC6.9090902@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reigistry for tv:URI's Thread-Index: AcboAGeO17JjwDpbR5mIEjN0Pt7BBwATezOw From: "Keesmaat, N.W. \(Iko\)" To: "Keith Moore" X-OriginalArrivalTime: 05 Oct 2006 07:36:07.0389 (UTC) FILETIME=[EB9228D0:01C6E850] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: discuss@apps.ietf.org, "Zigmond, Dan" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Keith, I=20do=20not=20understand=20what=20you=20driving=20at=20here.=20In=20RFC28= 38=20the=20tv:URI=20was explicitly=20defined=20as=20an=20identifier=20of=20television=20broadcasts= . Are=20we=20having=20a=20misunderstanding=20about=20what=20a=20TV=20broadca= st=20is?=20 What=20we=20are=20needing=20is=20a=20way=20to=20identify=20what=20people=20= would=20call=20*the*=20TV broadcast,=20i.e.=20if=20you=20have=20a=20device=20that=20can=20display=20= NBC=20as=20received over=20the=20air=20and=20NBC=20as=20received=20over=20the=20cable=20and=20= they=20are=20displaying the=20same=20television=20content=20at=20the=20same=20time,=20then=20that=20= is=20what=20we=20would like=20to=20refer=20to. Whether=20or=20not=20you=20need=20NTSC=20decoding=20software/hardware=20to= =20view=20the=20one and=20PAL=20decoding=20software/hardware=20to=20view=20the=20other=20is=20= not=20important. That=20is=20lower=20level=20information=20that=20may=20be=20locally=20conf= igured. Does=20this=20make=20sense=20to=20you? Iko. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Iko=20Keesmaat TNO=20Information=20and=20Communication=20Technology E-mail:=20iko.keesmaat@tno.nl -----Original=20Message----- From:=20Keith=20Moore=20[mailto:moore@cs.utk.edu]=20 Sent:=20donderdag=205=20oktober=202006=200:00 To:=20Keesmaat,=20N.W.=20(Iko) Cc:=20discuss@apps.ietf.org Subject:=20Re:=20Reigistry=20for=20tv:URI's >=20In=20our=20view=20the=20tv:URI=20should=20identify=20a=20TV=20broadcas= t.=20 I=20am=20not=20sure=20that=20this=20is=20a=20good=20thing.=20=20What=20is=20= important=20about=20 distinguishing=20tv:=20from=20other=20URIs?=20=20Is=20it=20that=20the=20si= gnal=20is=20encoded=20 using=20NTSC=20or=20PAL?=20=20Or=20will=20MPEG=20do?=20=20Is=20it=20that=20= the=20signal=20is=20 transmitted=20using=20radio=20frequency=20electromagnetic=20radiation=20th= rough=20the=20 air?=20=20Or=20is=20it=20okay=20if=20the=20signal=20is=20transmitted=20ove= r=20cable?=20=20What=20about satellite?=20Does=20it=20matter=20how=20it's=20modulated? IMO,=20one=20of=20the=20goals=20of=20the=20tv:=20URI=20should=20be=20to=20= permit=20convergence=20so=20 that=20different=20sources=20of=20video=20programming=20can=20be=20viewed=20= by=20the=20same=20 computer=20program=20(or=20set-top=20box,=20whatever)=20while=20at=20the=20= same=20time=20 presenting=20the=20viewer=20with=20a=20reasonably=20clean=20user=20interfa= ce=20for=20 selecting=20between=20different=20sources,=20and=20probably=20allowing=20t= hose=20program sources=20to=20be=20linked=20to=20from=20other=20sources=20-=20say=20from=20= a=20web=20page=20or=20 email=20reader.=20=20That=20doesn't=20inherently=20mean=20that=20tv:=20URI= =20should=20be=20 usable=20by=20any=20kind=20of=20video=20programming=20source,=20but=20it=20= probably=20does=20 mean=20that=20there=20should=20be=20_some_=20level=20of=20naming=20which=20= can=20be=20used=20by=20 any=20kind=20of=20video=20programming=20source. =20From=20my=20point-of-view,=20whether=20tv:=20is=20the=20higher-level=20= name=20that=20maps=20 to=20one=20or=20more=20lower-level=20services,=20or=20whether=20tv:=20is=20= a=20specific=20 lower-level=20service=20and=20there's=20a=20higher-level=20name=20(say=20a= =20URN)=20to=20 describe=20the=20video=20programming=20source,=20is=20almost=20arbitrary=20= -=20as=20long=20as=20 the=20relationship=20between=20the=20two=20levels=20of=20naming=20is=20cle= ar.=20=20Though=20it=20 seems=20that=20there=20is=20already=20some=20investment=20in=20the=20tv:=20= URL=20prefix=20along=20 the=20former=20lines. Keith This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html From discuss-bounces@apps.ietf.org Thu Oct 05 03:46:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNvB-0003er-CQ; Thu, 05 Oct 2006 03:45:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNvA-0003em-7N for discuss@apps.ietf.org; Thu, 05 Oct 2006 03:45:32 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVNv8-0001CJ-Vz for discuss@apps.ietf.org; Thu, 05 Oct 2006 03:45:32 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 5B3ED2F227; Thu, 5 Oct 2006 03:46:19 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXJPTl+15zUZ; Thu, 5 Oct 2006 03:46:16 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 1185A2F21D; Thu, 5 Oct 2006 03:46:16 -0400 (EDT) Message-ID: <4524B814.3060600@cs.utk.edu> Date: Thu, 05 Oct 2006 03:45:24 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "Keesmaat, N.W. \(Iko\)" Subject: Re: Reigistry for tv:URI's References: <42F3BE57026C6E49B09E267EEF639D56D38E17@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56D38E17@ms-dt01thalia.tsn.tno.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: discuss@apps.ietf.org, "Zigmond, Dan" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > I do not understand what you driving at here. In RFC2838 the tv:URI was > explicitly defined as an identifier of television broadcasts. > > Are we having a misunderstanding about what a TV broadcast is? perhaps. that's why I was asking the questions I asked. I don't understand where you want to draw the line between a "TV broadcast" and some other source of video programming. for example, we have "Internet radio" stations now, why not Internet TV stations? offhand I think the difference between what I would call a "TV broadcast" and some other video program source is that a "TV broadcast" is immediate - that is, there are some set of viewers watching "in real time" (although of course it might also be possible to watch portions of it later) and the programming can therefore be chosen to fit the time at which it is broadcast. > What we are needing is a way to identify what people would call *the* TV > broadcast, i.e. if you have a device that can display NBC as received > over the air and NBC as received over the cable and they are displaying > the same television content at the same time, then that is what we would > like to refer to. that's fine. I just don't think that the notion of TV broadcasts covered by tv: URLs should exclude internet-only broadcasters. Keith From discuss-bounces@apps.ietf.org Thu Oct 05 04:13:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVOLD-0004QR-EP; Thu, 05 Oct 2006 04:12:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVOLC-0004Q9-K0 for discuss@apps.ietf.org; Thu, 05 Oct 2006 04:12:26 -0400 Received: from mail91.messagelabs.com ([194.106.220.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVOKs-0007Rx-3g for discuss@apps.ietf.org; Thu, 05 Oct 2006 04:12:26 -0400 X-VirusChecked: Checked X-Env-Sender: iko.keesmaat@tno.nl X-Msg-Ref: server-6.tower-91.messagelabs.com!1160035914!17442368!1 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 8912 invoked from network); 5 Oct 2006 08:11:55 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-6.tower-91.messagelabs.com with SMTP; 5 Oct 2006 08:11:55 -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 k958BsB25322; Thu, 5 Oct 2006 10:11:54 +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); Thu, 5 Oct 2006 10:11:52 +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: Thu, 5 Oct 2006 10:11:51 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56D38E18@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <4524B814.3060600@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reigistry for tv:URI's Thread-Index: AcboUj1B+ZiHTPj2THqwsSe7+dQdHwAA5Lxw From: "Keesmaat, N.W. \(Iko\)" To: "Keith Moore" X-OriginalArrivalTime: 05 Oct 2006 08:11:52.0287 (UTC) FILETIME=[EA079EF0:01C6E855] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: discuss@apps.ietf.org, "Zigmond, Dan" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >=20perhaps.=20=20that's=20why=20I=20was=20asking=20the=20questions=20I=20= asked.=20=20I=20don't=20 >=20understand=20where=20you=20want=20to=20draw=20the=20line=20between=20a= =20"TV=20 >=20broadcast"=20and=20 >=20some=20other=20source=20of=20video=20programming.=20for=20example,=20w= e=20have=20 >=20"Internet=20 >=20radio"=20stations=20now,=20why=20not=20Internet=20TV=20stations? We=20do=20not=20want=20to=20exclude=20Internet=20TV=20stations,=20but=20we= =20do=20not=20need=20a=20new identifier=20to=20point=20at=20recorded=20video=20clips=20(such=20as=20You= tube.com). >=20offhand=20I=20think=20the=20difference=20between=20what=20I=20would=20= call=20a=20"TV=20 >=20broadcast"=20and=20some=20other=20video=20program=20source=20is=20that= =20a=20"TV=20 >=20broadcast"=20 >=20is=20immediate=20-=20that=20is,=20there=20are=20some=20set=20of=20view= ers=20 >=20watching=20"in=20real=20 >=20time"=20(although=20of=20course=20it=20might=20also=20be=20possible=20= to=20watch=20 >=20portions=20of=20 >=20it=20later)=20and=20the=20programming=20can=20therefore=20be=20chosen=20= to=20fit=20 >=20the=20time=20at=20 >=20which=20it=20is=20broadcast. Exactly.=20The=20keywords=20here=20are:=20'real=20time',=20and=20'broadcas= t',=20i.e. multiple=20viewers. >=20that's=20fine.=20=20I=20just=20don't=20think=20that=20the=20notion=20o= f=20TV=20broadcasts=20 >=20covered=20by=20tv:=20URLs=20should=20exclude=20internet-only=20broadca= sters. It=20shouldn't. Iko. This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html From discuss-bounces@apps.ietf.org Thu Oct 05 04:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVOii-0000XE-T6; Thu, 05 Oct 2006 04:36:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVOih-0000Nm-T4 for discuss@apps.ietf.org; Thu, 05 Oct 2006 04:36:43 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVOZj-0002vO-3u for discuss@apps.ietf.org; Thu, 05 Oct 2006 04:27:31 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id k958RNDx009267Thu, 5 Oct 2006 08:27:23 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1GVOZf-000Ee0-00; Thu, 05 Oct 2006 09:27:23 +0100 Date: Thu, 5 Oct 2006 09:27:23 +0100 From: "Clive D.W. Feather" To: "Keesmaat, N.W. (Iko)" Subject: Re: Reigistry for tv:URI's Message-ID: <20061005082723.GA53743@finch-staff-1.thus.net> References: <42F3BE57026C6E49B09E267EEF639D56D38E14@ms-dt01thalia.tsn.tno.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56D38E14@ms-dt01thalia.tsn.tno.nl> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Keesmaat, N.W. (Iko) said: > Looking at the TV broadcast known in the USA as NBC (via the website > http://www.nbc.com), then we can see that it has four different > schedules: E (Eastern), C (Central), M (Mountain), and P (Pacific). > These four TV broadcasts can be seen as four different ones, so we may > need the following tv:URIs: > > * eastern.nbc.com > * central.nbc.com > * mountain.nbc.com > * pacific.nbc.com Except, as I understand it, they only have two or three, depending on how you look at it - schedules. Thus to take a single programme, "Deal Or No Deal Episode #209", this shows at: Eastern: 21:00 (01:00 UTC) Central: 20:00 (01:00 UTC) Mountain: 20:00 (02:00 UTC) Pacific: 21:00 (04:00 UTC) So there are two "wall time" schedules (E/P and C/M) but three broadcasting schedules (E/C, M, and P). So how should we handle that? Are we interested in actual UTC broadcast time or in local clock broadcast time? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Thu Oct 05 09:20:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVT7b-0007zy-A0; Thu, 05 Oct 2006 09:18:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVT7a-0007zs-CA for discuss@apps.ietf.org; Thu, 05 Oct 2006 09:18:42 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVT7Z-0007dL-5e for discuss@apps.ietf.org; Thu, 05 Oct 2006 09:18:42 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 98E112F1A3; Thu, 5 Oct 2006 09:19:31 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtMru4qz1MEX; Thu, 5 Oct 2006 09:19:23 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 5E2922F21D; Thu, 5 Oct 2006 09:19:21 -0400 (EDT) Message-ID: <45250625.2020604@cs.utk.edu> Date: Thu, 05 Oct 2006 09:18:29 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "Keesmaat, N.W. \(Iko\)" Subject: Re: Reigistry for tv:URI's References: <42F3BE57026C6E49B09E267EEF639D56D38E18@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56D38E18@ms-dt01thalia.tsn.tno.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: discuss@apps.ietf.org, "Zigmond, Dan" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > We do not want to exclude Internet TV stations, but we do not need a new > identifier to point at recorded video clips (such as Youtube.com). concur. Keith From discuss-bounces@apps.ietf.org Mon Oct 09 05:30:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWrSE-00060h-SE; Mon, 09 Oct 2006 05:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWrSD-00060a-Sd for discuss@apps.ietf.org; Mon, 09 Oct 2006 05:29:45 -0400 Received: from mail114.messagelabs.com ([195.245.231.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GWrS8-0001fs-CU for discuss@apps.ietf.org; Mon, 09 Oct 2006 05:29:45 -0400 X-VirusChecked: Checked X-Env-Sender: iko.keesmaat@tno.nl X-Msg-Ref: server-7.tower-114.messagelabs.com!1160385951!21823968!3 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 20431 invoked from network); 9 Oct 2006 09:25:53 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-7.tower-114.messagelabs.com with SMTP; 9 Oct 2006 09:25:53 -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 k998ckB10317; Mon, 9 Oct 2006 10:38:47 +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, 9 Oct 2006 10:38:39 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EB7E.5189E606" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: I-D on Registry for tv:URIs Date: Mon, 9 Oct 2006 10:38:39 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56D38E1F@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D on Registry for tv:URIs Thread-Index: AcbrflGjtCkvYeSdS/KauAIdwVFgDA== From: "Keesmaat, N.W. \(Iko\)" To: X-OriginalArrivalTime: 09 Oct 2006 08:38:39.0981 (UTC) FILETIME=[51F141D0:01C6EB7E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: "Zigmond, Dan" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EB7E.5189E606 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All, Please=20note=20that=20an=20internet-draft=20"Registry=20for=20tv:URIs"=20= is=20available from=20the=20repository: https://datatracker.ietf.org/public/idindex.cgi?command=3Did_detail&id=3D1= 52 22;=20 http://www.ietf.org/internet-drafts/draft-keesmaat-tvreg-00.txt This=20draft=20describes=20the=20registry=20for=20tv:URIs=20that=20we=20fe= el=20is=20needed=20as has=20been=20discusses=20on=20this=20list=20before. We=20welcome=20your=20responses. Iko=20Keesmaat=20(and=20Oskar=20van=20Deventer). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Iko=20Keesmaat TNO=20Information=20and=20Communication=20Technology Room=20BA201b Brassersplein=202 P.O.=20Box=205050 2600=20GB=20Delft The=20Netherlands Tel:=20+31=2015=202857159 Mob:=20+31=206=2051916191 Fax:=20+31=2015=202857349 E-mail:=20iko.keesmaat@tno.nl This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html ------_=_NextPart_001_01C6EB7E.5189E606 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I-D=20on=20Registry=20for=20tv:URIs

All,

Please=20note=20that=20an=20internet-= draft=20"Registry=20for=20tv:URIs"=20is=20available=20from=20the= =20repository:

https://datatracker.ietf.org/public/idindex.cgi?command=3Did_detai= l&id=3D15222;=20

http://www= .ietf.org/internet-drafts/draft-keesmaat-tvreg-00.txt


This=20draft=20describes=20the=20regi= stry=20for=20tv:URIs=20that=20we=20feel=20is=20needed=20as=20has=20been=20= discusses=20on=20this=20list=20before.

We=20welcome=20your=20responses.

Iko=20Keesmaat=20(and=20Oskar=20van=20= Deventer).

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Iko=20Keesmaat
TNO=20Informatio= n=20and=20Communication=20Technology
Room=20BA201b
Brassersplein=20= 2
P.O.=20Box=20505= 0
2600=20GB=20D= elft
The=20Netherl= ands
Tel:=20+31=20= 15=202857159
Mob:=20+31=20= 6=2051916191
Fax:=20+31=20= 15=202857349
E-mail:=20iko= .keesmaat@tno.nl


This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html
------_=_NextPart_001_01C6EB7E.5189E606-- From discuss-bounces@apps.ietf.org Mon Oct 09 07:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWtK8-0001Ku-2h; Mon, 09 Oct 2006 07:29:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWtK6-0001HA-MR for discuss@apps.ietf.org; Mon, 09 Oct 2006 07:29:30 -0400 Received: from mail114.messagelabs.com ([195.245.231.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GWtIp-0006YY-R9 for discuss@apps.ietf.org; Mon, 09 Oct 2006 07:28:15 -0400 X-VirusChecked: Checked X-Env-Sender: iko.keesmaat@tno.nl X-Msg-Ref: server-11.tower-114.messagelabs.com!1160393083!25357265!1 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 1399 invoked from network); 9 Oct 2006 11:24:44 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-11.tower-114.messagelabs.com with SMTP; 9 Oct 2006 11:24:44 -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 k99BOhB23720; Mon, 9 Oct 2006 13:24:43 +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, 9 Oct 2006 13:24:41 +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: Mon, 9 Oct 2006 13:24:41 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56D38E21@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <20061005082723.GA53743@finch-staff-1.thus.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reigistry for tv:URI's Thread-Index: AcboWEdyz2u14ulLQmOOXlEqwqG1OQDJhFfw From: "Keesmaat, N.W. \(Iko\)" To: X-OriginalArrivalTime: 09 Oct 2006 11:24:41.0539 (UTC) FILETIME=[837E6130:01C6EB95] X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: "Clive D.W. Feather" , "Zigmond, Dan" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Clive, >=20>=20need=20the=20following=20tv:URIs: >=20>=20 >=20>=20*=20eastern.nbc.com >=20>=20*=20central.nbc.com >=20>=20*=20mountain.nbc.com >=20>=20*=20pacific.nbc.com >=20 >=20Except,=20as=20I=20understand=20it,=20they=20only=20have=20two=20or=20= three,=20 >=20depending=20on=20how >=20you=20look=20at=20it=20-=20schedules.=20Thus=20to=20take=20a=20single=20= programme,=20 >=20"Deal=20Or=20No >=20Deal=20Episode=20#209",=20this=20shows=20at: >=20 >=20=20=20=20=20Eastern:=20=2021:00=20(01:00=20UTC) >=20=20=20=20=20Central:=20=2020:00=20(01:00=20UTC) >=20=20=20=20=20Mountain:=2020:00=20(02:00=20UTC) >=20=20=20=20=20Pacific:=20=2021:00=20(04:00=20UTC) >=20 >=20So=20there=20are=20two=20"wall=20time"=20schedules=20(E/P=20and=20C/M)= =20but=20 >=20three=20broadcasting >=20schedules=20(E/C,=20M,=20and=20P). >=20 >=20So=20how=20should=20we=20handle=20that?=20Are=20we=20interested=20in=20= actual=20UTC=20 >=20broadcast >=20time=20or=20in=20local=20clock=20broadcast=20time? You=20have=20a=20good=20point=20here. I=20would=20consider=20any=20tv=20broadcast=20that=20is=20not=20showing=20= the=20same=20program at=20the=20same=20UTC=20time=20as=20different,=20because=20communication=20= in=20the=20form: "watch=20tv:yyy=20now!"=20would=20then=20become=20less=20useful. So=20this=20argument=20would=20distinguish=20Eastern=20from=20Mountain=20a= nd=20Pacific=20(at NBC). Remains=20the=20distinction=20between=20Eastern=20and=20Central.=20These=20= two broadcasts=20show=20(most=20likely)=20the=20same=20program=20at=20the=20sa= me=20UTC=20time. However,=20I=20still=20feel=20that=20they=20can=20be=20considered=20differ= ent=20(and=20thus warrant=20different=20tv:URIs).=20A=20communication=20in=20the=20form:=20"= watch=20the upcoming=20program=20at=20tv:yyy=20at=2020:00"=20would=20for=20instance=20= be=20the=20wrong communication=20if=20the=20tv:URIs=20of=20both=20tv=20broadcast=20are=20th= e=20same. Ultimately=20it=20would=20be=20less=20of=20a=20problem=20of=20the=20same=20= tv=20broadcast=20has multiple=20tv:URIs=20pointing=20at=20it.=20But=20the=20reverse:=20a=20sing= le=20tv:URI pointing=20to=20multiple=20tv=20broadcast=20*is*=20a=20major=20problem. So,=20for=20the=20moment=20I=20think=20it=20would=20be=20best=20to=20have=20= both tv:eastern.nbc.com=20and=20tv:central.nbc.com.=20And=20as=20argued=20above= =20also tv:mountain.nbc.com=20and=20tv:pacific.nbc.com. Iko. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Iko=20Keesmaat TNO=20Information=20and=20Communication=20Technology E-mail:=20iko.keesmaat@tno.nl This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html From discuss-bounces@apps.ietf.org Mon Oct 23 11:32:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1lk-0003B9-KU; Mon, 23 Oct 2006 11:31:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1lj-0003AW-UK for discuss@apps.ietf.org; Mon, 23 Oct 2006 11:31:15 -0400 Received: from mail91.messagelabs.com ([194.106.220.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gc1ZW-0005Ra-Fi for discuss@apps.ietf.org; Mon, 23 Oct 2006 11:18:50 -0400 X-VirusChecked: Checked X-Env-Sender: oskar.vandeventer@tno.nl X-Msg-Ref: server-7.tower-91.messagelabs.com!1161616527!22155868!1 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 12377 invoked from network); 23 Oct 2006 15:15:27 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-7.tower-91.messagelabs.com with SMTP; 23 Oct 2006 15:15:27 -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 k9NFFHB26059; Mon, 23 Oct 2006 17:15:27 +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, 23 Oct 2006 17:15:17 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F6B6.0BEF2C3C" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: I-D on Registry for tv:URIs Date: Mon, 23 Oct 2006 17:15:17 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D560124680A@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56D38E1F@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D on Registry for tv:URIs Thread-Index: AcbrflGjtCkvYeSdS/KauAIdwVFgDALM/dLQ From: "Deventer, M.O. \(Oskar\) van" To: X-OriginalArrivalTime: 23 Oct 2006 15:15:17.0654 (UTC) FILETIME=[0C3E7B60:01C6F6B6] X-Spam-Score: 0.1 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: "Zigmond, Dan" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F6B6.0BEF2C3C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Who=20will=20be=20paying=20for=20the=20tv:URI=20registry? =20 We=20contacted=20the=20people=20behind=20Showview.com=20(VCRplus=20in=20th= e=20USA)=20and asked=20them=20about=20their=20business=20model.=20Showview=20maintains=20= lists=20of channel=20numbers=20for=20the=20programming=20of=20video=20recorders.=20It= =20is publications=20companies,=20TV=20listing=20companies=20and=20broadcasters=20= that=20pay annual=20fees=20for=20participation=20in=20the=20Showview=20system.=20They= =20inform Showview=20of=20any=20changes.=20The=20maintenance=20of=20channel=20lists=20= is=20done=20by=20a single=20person=20in=20part-time,=20triggered=20by=20request=20from=20publ= ishers. =20 Perhaps=20a=20registry=20for=20tv:URIs=20could=20follow=20a=20similar=20bu= siness=20model. =20 Oskar ________________________________ From:=20Keesmaat,=20N.W.=20(Iko)=20[mailto:iko.keesmaat@tno.nl]=20 Sent:=20maandag=209=20oktober=202006=2010:39 To:=20discuss@apps.ietf.org Cc:=20Zigmond,=20Dan Subject:=20I-D=20on=20Registry=20for=20tv:URIs All,=20 Please=20note=20that=20an=20internet-draft=20"Registry=20for=20tv:URIs"=20= is=20available from=20the=20repository:=20 https://datatracker.ietf.org/public/idindex.cgi?command=3Did_detail&id=3D1= 52 22 =20;=20 http://www.ietf.org/internet-drafts/draft-keesmaat-tvreg-00.txt =20=20 This=20draft=20describes=20the=20registry=20for=20tv:URIs=20that=20we=20fe= el=20is=20needed=20as has=20been=20discusses=20on=20this=20list=20before.=20 We=20welcome=20your=20responses.=20 Iko=20Keesmaat=20(and=20Oskar=20van=20Deventer).=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=20 Iko=20Keesmaat=20 TNO=20Information=20and=20Communication=20Technology=20 Room=20BA201b=20 Brassersplein=202=20 P.O.=20Box=205050=20 2600=20GB=20Delft=20 The=20Netherlands=20 Tel:=20+31=2015=202857159=20 Mob:=20+31=206=2051916191=20 Fax:=20+31=2015=202857349=20 E-mail:=20iko.keesmaat@tno.nl=20 This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at http://www.tno.nl/disclaimer/email.html This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html ------_=_NextPart_001_01C6F6B6.0BEF2C3C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable = I-D=20on=20Registry=20for=20tv:URIs Who=20will=20be=20paying=20for=20= the=20tv:URI=20 registry?   We=20contacted=20the=20people=20behind=20Showvi= ew.com=20(VCRplus=20in=20 the=20USA) and=20asked=20them=20about=20their=20business=20model.=20S= howview=20maintains=20 lists=20of=20channel=20numbers=20for=20the=20programming=20of=20video=20re= corders.=20It=20is=20 publications=20companies,=20TV=20listing=20companies=20and=20broadcasters&= nbsp;that=20pay=20 annual=20fees=20for=20participation=20in=20the=20Showview=20system.=20They= =20inform=20Showview=20of=20 any=20changes. The=20maintenance=20of=20channel=20lists=20= is=20done=20by=20a=20 single=20person=20in=20part-time,=20triggered=20by=20request=20from=20 publishers.   Perhaps=20a=20registry=20for=20tv:URIs=20could=20= follow=20a=20similar=20 business=20model.   Oskar
From:=20Keesmaat,=20N.W.=20(Iko)=20= [mailto:iko.keesmaat@tno.nl]=20
Sent:=20maandag=209=20oktober=20= 2006=20 10:39
To:=20discuss@apps.ietf.org
Cc:=20Zigmond,=20 Dan
Subject:=20I-D=20on=20Registry=20for=20tv:URIs

All,=20

Please=20note=20that=20an=20internet-dr= aft=20"Registry=20for=20 tv:URIs"=20is=20available=20from=20the=20repository:=20

https://datatracker.ietf.org/public/idindex.cgi?command=3Did_deta= il&id=3D15222;=20

<= U>http://www.ietf.org/internet-drafts/draft-keesmaat-tvreg-00.txt=20


This=20draft=20describes=20the=20regist= ry=20for=20tv:URIs=20that=20we=20 feel=20is=20needed=20as=20has=20been=20discusses=20on=20this=20list=20befo= re.=20

We=20welcome=20your=20responses.= =20

Iko=20Keesmaat=20(and=20Oskar=20van=20D= eventer).=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=20
Iko=20Keesmaat=20
TNO=20Information=20and=20Communication=20Technology=20
Room=20BA201b=20Brassersplein=202=20=
P.O.=20Box=205050=20=
2600=20GB=20Delft=20
The=20Netherlands=20
Tel:=20+31=2015=202857159=20
Mob:=20+31=206=2051916191=20
Fax:=20+31=2015=202857349=20
E-mail:=20iko.keesmaat@tno.nl= =20


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

This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html
------_=_NextPart_001_01C6F6B6.0BEF2C3C-- From discuss-bounces@apps.ietf.org Tue Oct 24 19:34:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVmA-0008Tf-El; Tue, 24 Oct 2006 19:33:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVm7-0008OT-LW for discuss@apps.ietf.org; Tue, 24 Oct 2006 19:33:39 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcVm6-0002UJ-9O for discuss@apps.ietf.org; Tue, 24 Oct 2006 19:33:39 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9ONXamq029889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Oct 2006 16:33:37 -0700 Received: from [10.0.1.4] (vpn-10-50-16-173.qualcomm.com [10.50.16.173]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9ONXYVK021558 for ; Tue, 24 Oct 2006 16:33:36 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Tue, 24 Oct 2006 16:33:33 -0700 To: discuss@apps.ietf.org From: Ted Hardie Subject: NomCom reminder Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Howdy, Just a reminder to folks that the NomCom is now accepting nominations for IESG and IAB. The NomCom page is available at http://www.ietf.org/nomcom/index.html, and it contains pointers to the list of open positions and the requirements from the point of view of the IESG and IAB. As I've mentioned in the past I am not standing for renomination, and I am happy to discuss my take on the job with anyone considering nominating themselves or someone else. regards, Ted Hardie From discuss-bounces@apps.ietf.org Sun Oct 29 20:36:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeM3g-000254-0h; Sun, 29 Oct 2006 20:35:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJOi-0005FC-NP for discuss@apps.ietf.org; Sun, 29 Oct 2006 17:44:56 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeJIR-0006IP-5Z for discuss@apps.ietf.org; Sun, 29 Oct 2006 17:38:28 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8EE3389856; Mon, 30 Oct 2006 00:38:19 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 68DE089854; Mon, 30 Oct 2006 00:38:18 +0200 (EET) Message-ID: <45452D5A.6000007@piuha.net> Date: Mon, 30 Oct 2006 00:38:18 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: IETF Discussion Subject: Re: Last Call: 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)' to Experimental RFC (draft-laganier-ipv6-khi) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Sun, 29 Oct 2006 20:29:34 -0500 Cc: Internet Area , HIP , IETF IPv6 Mailing List , iesg@ietf.org, discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org We are last calling this document for the second time, for two reasons. The first reason is to make sure that the last call has been circulated widely enough in the community. The second reason is that we want to call the attention of the IETF community on the specific issue of using IPv6 addresses as identifiers in this manner. To summarize the background, the document suggests the allocation of a temporary experimental block out of the IPv6 address space for the purposes of easing experiments that deal with identity-locator split. In particular the HIP community wants this in order to be able to run unmodified applications. The allocated address space would be used to represent identifiers in the place of addresses in the existing APIs. While the long-term plan is to use new APIs that reflect the semantics appropriate for identifiers, the ability to experiment without having to upgrade all applications is important. Such an approach is not without problems, however. For instance, applications that deal with referrals (e.g. one application passing an address to another one) may end up "leaking" such identifiers to the hosts that are not involved in an experiment. Since the identifiers are not routable in the current Internet, communications initiated towards such identifiers will fail. My own take on this issue is that there are risks, but that the benefits are greater. In particular, its clear that the identity-locator split proposals need more experiments and experience before we can consider them for real. Making such experiments easy is important. Also, IMHO, the topic is sufficiently far in the domain of research that the practical danger of the experiment becoming a permanent problem is small. But this is enough about my opinions. Please state your opinion -- in the interest of not replicating this discussion on multiple lists, send follow-ups to ietf@ietf.org. > The IESG has received a request from an individual submitter to consider > the following document: > > - 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers > (ORCHID) ' > as an Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-11-24. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-05.txt > From discuss-bounces@apps.ietf.org Sun Oct 29 23:36:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeOsA-0000of-Lr; Sun, 29 Oct 2006 23:35:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeOs8-0000mO-Rs for discuss@apps.ietf.org; Sun, 29 Oct 2006 23:35:40 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeOs6-0006x8-DM for discuss@apps.ietf.org; Sun, 29 Oct 2006 23:35:40 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9U4ZZS1030056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 29 Oct 2006 20:35:36 -0800 Received: from [10.0.1.4] (vpn-10-50-16-94.qualcomm.com [10.50.16.94]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9U4ZW7Z006628; Sun, 29 Oct 2006 20:35:33 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <45452D5A.6000007@piuha.net> References: <45452D5A.6000007@piuha.net> Date: Sun, 29 Oct 2006 20:35:31 -0800 To: Jari Arkko , IETF Discussion From: Ted Hardie Subject: Re: Last Call: 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)' to Experimental RFC (draft-laganier-ipv6-khi) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: HIP , discuss@apps.ietf.org, Internet Area , iesg@ietf.org, IETF IPv6 Mailing List X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org First, my thanks to Jari for agreeing to the second last call. Some further comments below. At 12:38 AM +0200 10/30/06, Jari Arkko wrote: >We are last calling this document for the second time, for >two reasons. The first reason is to make sure that the >last call has been circulated widely enough in the >community. > >The second reason is that we want to call the attention >of the IETF community on the specific issue of using >IPv6 addresses as identifiers in this manner. To summarize >the background, the document suggests the allocation >of a temporary experimental block out of the IPv6 >address space for the purposes of easing experiments >that deal with identity-locator split. In particular the >HIP community wants this in order to be able to run >unmodified applications. The allocated address space >would be used to represent identifiers in the place >of addresses in the existing APIs. While the long-term plan is >to use new APIs that reflect the semantics appropriate >for identifiers, the ability to experiment without having >to upgrade all applications is important. I strongly suggest folks actually read the document, rather than relying on the summary above. In my own reading, there were a couple of issues that struck me as potential problems. The first is that this draft has a view of how applications interact with IPv6 addresses that it somewhat unidimensional. It presumes that the application always passes IPv6 addresses "down" the stack where a routing layer takes care of them. That leads to the idea that inserting a shim between the application layer and the routing layer can introduce new functionality without changing the way in which addresses pass across those APIs. That may be true, but it is certainly not the only way in which applications pass IPv6 addresses. Two trivial examples which do not pass that way are the IPv6 addresses given in SDP packets and the IPv6 addresses which may appear in URIs. By choosing to retain the same syntax (but not the same semantics) as the basic IPv6 address, the draft may be making it possible to pass them "down" through shims, but it is also guaranteeing that if they leak out through application-layer pointers, that non-participating hosts will not know that they cannot be passed to the routing system. Once there, they will (hopefully, anyway) not be routable, which will give some pretty hard to diagnose errors for the non-participating users. The draft is careful to note that this should be used only among consenting hosts, but there is no clear way to determine if a host is participating. It is also somewhat problematic that the range set aside may be used for *any* experimental use of this type (not just, say, HIP). I encourage folks to read the draft and see if they believe it would be possible for a host to participate in multiple experiments of this type, or if it would be effectively limited to a single shim. In that same vein, imagine the case where an application layer pointer is sent to a host that is participating in a *different* experiment from the one originally meant. Stepping up a few thousands of feet, I believe that the draft's setting aside these syntactically-but-not-semantically-equal addresses is implying a value judgement that this is the appropriate way to conduct experiments of this type. While it *may* be true for one or more experiments, that meta-statement is not yet born out by experience, and encouraging that choice seems to run ahead of our facts. Though this draft discusses "overlays", there is no requirement that these systems be overlays in the sense of the term I see used most commonly; they do not have to fit into the same class as one-to-many VPNs, MPLS LSPs, or any of the overlay-as-tunnel mechanisms we commonly see. Instead, they may rely on the resolution of one class of identifier before using the common routing system (and there is no guarantee that any of what was present before the shim did the resolution will be present after). There may well be resolution mechanisms to be tested here which would be much more effective if they did not presume that the input syntax and output syntax had to be the same. Setting aside the range in the way this draft does seems to imply that the answer *should* lie in the class of resolutions where the syntax is the same on both sides of the resolution. Fundamentally, these identifiers are not v6 addresses at all. Setting aside a portion of the v6 address space in this way risks, in my mind, pushing us further down a bad road, where that syntax is fundamentally meaningless without a context. This is bad because we have not successfully designed a mechanism for indicating that context. Leaving the semantics of these identifiers reliant on inference is a recipe for poor performance and, possibly, outright failure. regards, Ted Hardie