From discuss-bounces@apps.ietf.org Sat Aug 19 12:57:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEU7B-0002FZ-Sj; Sat, 19 Aug 2006 12:56:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE5Hn-0001za-VT for discuss@apps.ietf.org; Fri, 18 Aug 2006 10:25:23 -0400 Received: from mail141.messagelabs.com ([85.158.137.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GE5Hf-0001iL-3c for discuss@apps.ietf.org; Fri, 18 Aug 2006 10:25:23 -0400 X-VirusChecked: Checked X-Env-Sender: oskar.vandeventer@tno.nl X-Msg-Ref: server-9.tower-141.messagelabs.com!1155911111!4056424!3 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 21548 invoked from network); 18 Aug 2006 14:25:12 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-9.tower-141.messagelabs.com with SMTP; 18 Aug 2006 14:25:12 -0000 Received: from ms-dt01vs01.tsn.tno.nl (cl-dt01pollux.tno.nl [134.221.225.8]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id k7IE8PB20425; Fri, 18 Aug 2006 16:08:25 +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); Fri, 18 Aug 2006 16:08:25 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C2CF.C5266AE9" Subject: Update of RFC 2838, tv: URI X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 18 Aug 2006 16:08:24 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of RFC 2838, tv: URI Thread-Index: AcbCz8RXcU1VVhdrRYOXmFPPNvryyA== From: "Deventer, M.O. \(Oskar\) van" To: X-OriginalArrivalTime: 18 Aug 2006 14:08:25.0300 (UTC) FILETIME=[C56E5940:01C6C2CF] X-Spam-Score: 0.1 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 X-Mailman-Approved-At: Sat, 19 Aug 2006 12:56:04 -0400 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C2CF.C5266AE9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, We=20see=20a=20need=20for=20an=20update=20to=20RFC=202838,=20which=20is=20= about=20the=20tv:=20URI=20for the=20identification=20of=20television=20channels.=20After=20speaking=20wi= th=20Lisa Dusseault,=20Cullen=20Jennings=20suggested=20discussing=20such=20an=20upda= te=20on=20the discuss@apps.ietf.org=20email=20list.=20The=20rest=20of=20this=20email=20d= escribes=20the use=20cases,=20the=20problem=20statement,=20a=20rough=20proposal=20and=20i= tems=20for=20the proposed=20update.=20We=20would=20like=20to=20invite=20feedback=20on=20the= se. Background:=20RFC=202838=20for=20the=20identification=20of=20TV=20channels= Unambiguous=20identification=20is=20needed=20when=20applications=20refer=20= to=20TV channels.=20An=20example=20use=20case=20is=20clickable=20TV=20watching=20a= dvice=20in=20an instant=20messaging=20application:=20"He=20John,=20check=20out=20BBC1=20no= w".=20Another example=20use=20case=20is=20a=20presence=20application:=20"Your=20buddy=20= John=20is=20now watching=20TV5".=20There=20does=20not=20exist=20an=20international=20namin= g=20authority for=20the=20identification=20of=20TV=20channels.=20RFC=202838=20defines=20= a=20harmonized alternative=20solution,=20namely=20the=20tv:=20URI.=20These=20DNS-style=20= identifiers are=20deduced=20from=20the=20name=20of=20the=20broadcaster=20or=20televisi= on=20network,=20its nationality=20and=20possibly=20the=20name=20of=20the=20broadcast=20stream.= =20The assumption=20of=20RFC=202838=20is=20that=20the=20deduction=20of=20a=20tv:=20= URI=20is unambiguous,=20which=20is=20usually=20true=20in=20the=20American=20context= .=20Here=20are some=20tv:=20URI=20examples=20from=20RFC=202838:=20tv:wqed.org;=20tv:nbc.c= om; tv:abc.com;=20tv:abc.co.au;=20tv:east.hbo.com;=20tv:west.hbo.com. Problem:=20Ambiguities=20with=20RFC=202838=20in=20a=20European=20context Because=20of=20the=20public=20network=20system=20in=20several=20European=20= countries,=20the deduction=20of=20tv:=20URIs=20leads=20to=20ambiguities=20in=20the=20Europe= an=20context.=20In the=20Netherlands,=20for=20example,=20the=20public=20network=20system=20ha= s=20more=20than ten=20TV=20stations=20who=20alternatingly=20broadcast=20on=20the=20three=20= public=20TV channels.=20At=20one=20time,=20one=20TV=20station=20may=20be=20broadcastin= g=20different programs=20on=20different=20channels.=20Another=20issue=20is=20"code=20sha= ring"=20where cable=20companies=20broadcast=20on=20one=20TV=20channel=20different=20(for= eign)=20TV channels=20at=20different=20times,=20e.g.=20a=20children's=20channel=20at=20= day=20time=20and=20a film=20channel=20at=20evening=20time.=20In=20all=20these=20examples,=20the= =20deduction=20of=20a tv:=20URI=20for=20the=20TV=20channels=20is=20ambiguous. Proposal:=20Take=20the=20website=20name=20of=20the=20TV=20channel Our=20proposal=20is=20to=20deduce=20the=20name=20of=20the=20TV=20channel=20= from=20the=20name=20of its=20official=20website.=20After=20a=20small=20investigation,=20we=20foun= d=20that=20every TV=20channel=20seems=20to=20have=20a=20dedicated=20website.=20American=20T= V=20channels, public=20TV=20channels=20in=20Europe=20and=20even=20small=20local=20TV=20c= hannels=20have=20their own=20website.=20So=20that=20removes=20the=20problem=20of=20ambiguities.=20= The=20deduction of=20a=20tv:=20URI=20then=20becomes=20a=20no-brainer:=20take=20the=20websi= te=20name=20and replace=20"http://"=20by=20"tv:".=20Here=20are=20some=20examples=20of=20Eu= ropean=20tv:=20URIs using=20this=20convention:=20tv:bbc.co.uk/bbcone;=20tv:nederland1.nl;=20tv= :tv5.fr. Update=20to=20RFC=202838:=20syntax=20and=20synonyms -The=20proposed=20new=20RFC=20that=20updates=20RFC=202838=20would=20keep=20= most=20parts=20of=20RFC 2838=20unaffected.=20The=20American=20tv:=20URI=20examples=20of=20RFC=2028= 38=20would=20remain unchanged,=20as=20these=20tv:=20URIs=20do=20already=20match=20with=20a=20w= ebsite.=20The Australian=20ABC=20channel=20would=20become=20tv:abc.net.au,=20correspondi= ng=20to their=20actual=20website=20name. -There=20is=20an=20update=20to=20the=20RFC=202838=20syntax=20needed,=20as=20= some=20TV=20channels would=20be=20identified=20by=20a=20resource=20(using=20"/")=20in=20our=20p= roposal=20and=20not only=20by=20a=20domain=20name.=20Two=20examples=20of=20this=20are=20tv:bbc= .co.uk/bbcone=20and tv:nationalgeographic.nl/channel. -Another=20issue=20for=20the=20update=20is=20synonyms.=20Some=20websites=20= work=20both=20with and=20without=20the=20"www"=20part=20in=20its=20URI.=20Some=20websites=20r= edirect=20to=20other websites.=20The=20website=20http://nederland1.nl=20redirects=20to http://portal.omroep.nl/ned1.=20In=20order=20to=20achieve=20the=20highest=20= level=20of interoperability,=20synonyms=20should=20be=20accepted=20as=20names=20of=20= TV=20channels. Please=20let=20us=20know=20your=20reaction=20on=20this=20proposal. Best=20regards, Oskar -------------------------------- 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 -------------------------------- This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html ------_=_NextPart_001_01C6C2CF.C5266AE9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Update=20of=20RFC=202838,=20tv:=20URI

All,

We=20see=20a=20need=20for=20an=20upda= te=20to=20RFC=202838,=20which=20is=20about=20the=20tv:=20URI=20for=20the=20= identification=20of=20television=20channels.=20After=20speaking=20with=20L= isa=20Dusseault,=20Cullen=20Jennings=20suggested=20discussing=20such=20an=20= update=20on=20the=20discuss@apps.ietf.org=20email=20list.=20The=20rest=20o= f=20this=20email=20describes=20the=20use=20cases,=20the=20problem=20statem= ent,=20a=20rough=20proposal=20and=20items=20for=20the=20proposed=20update.= =20We=20would=20like=20to=20invite=20feedback=20on=20these.

Background:=20RFC=202838=20for=20the=20= identification=20of=20TV=20channels

Unambiguous=20identification=20is=20n= eeded=20when=20applications=20refer=20to=20TV=20channels.=20An=20example=20= use=20case=20is=20clickable=20TV=20watching=20advice=20in=20an=20instant=20= messaging=20application:=20“He=20John,=20check=20out=20BBC1=20now= 221;.=20Another=20example=20use=20case=20is=20a=20presence=20application:=20= “Your=20buddy=20John=20is=20now=20watching=20TV5”.=20There=20d= oes=20not=20exist=20an=20international=20naming=20authority=20for=20the=20= identification=20of=20TV=20channels.=20RFC=202838=20defines=20a=20harmoniz= ed=20alternative=20solution,=20namely=20the=20tv:=20URI.=20These=20DNS-sty= le=20identifiers=20are=20deduced=20from=20the=20name=20of=20the=20broadcas= ter=20or=20television=20network,=20its=20nationality=20and=20possibly=20th= e=20name=20of=20the=20broadcast=20stream.=20The=20assumption=20of=20RFC=20= 2838=20is=20that=20the=20deduction=20of=20a=20tv:=20URI=20is=20unambiguous= ,=20which=20is=20usually=20true=20in=20the=20American=20context.=20Here=20= are=20some=20tv:=20URI=20examples=20from=20RFC=202838:=20tv:wqed.org;=20tv= :nbc.com;=20tv:abc.com;=20tv:abc.co.au;=20tv:east.hbo.com;=20tv:west.hbo.c= om.

Problem:=20Ambiguities=20with=20RFC=20= 2838=20in=20a=20European=20context

Because=20of=20the=20public=20network= =20system=20in=20several=20European=20countries,=20the=20deduction=20of=20= tv:=20URIs=20leads=20to=20ambiguities=20in=20the=20European=20context.=20I= n=20the=20Netherlands,=20for=20example,=20the=20public=20network=20system=20= has=20more=20than=20ten=20TV=20stations=20who=20alternatingly=20broadcast=20= on=20the=20three=20public=20TV=20channels.=20At=20one=20time,=20one=20TV=20= station=20may=20be=20broadcasting=20different=20programs=20on=20different=20= channels.=20Another=20issue=20is=20“code=20sharing”=20where=20= cable=20companies=20broadcast=20on=20one=20TV=20channel=20different=20(for= eign)=20TV=20channels=20at=20different=20times,=20e.g.=20a=20children̵= 7;s=20channel=20at=20day=20time=20and=20a=20film=20channel=20at=20evening=20= time.=20In=20all=20these=20examples,=20the=20deduction=20of=20a=20tv:=20UR= I=20for=20the=20TV=20channels=20is=20ambiguous.

Proposal:=20Take=20the=20website=20na= me=20of=20the=20TV=20channel

Our=20proposal=20is=20to=20deduce=20t= he=20name=20of=20the=20TV=20channel=20from=20the=20name=20of=20its=20offic= ial=20website.=20After=20a=20small=20investigation,=20we=20found=20that=20= every=20TV=20channel=20seems=20to=20have=20a=20dedicated=20website.=20Amer= ican=20TV=20channels,=20public=20TV=20channels=20in=20Europe=20and=20even=20= small=20local=20TV=20channels=20have=20their=20own=20website.=20So=20that=20= removes=20the=20problem=20of=20ambiguities.=20The=20deduction=20of=20a=20t= v:=20URI=20then=20becomes=20a=20no-brainer:=20take=20the=20website=20name=20= and=20replace=20“http://”=20by=20“tv:”.=20Here=20are=20some=20exa= mples=20of=20European=20tv:=20URIs=20using=20this=20convention:=20tv:bbc.c= o.uk/bbcone;=20tv:nederland1.nl;=20tv:tv5.fr.

Update=20to=20RFC=202838:=20syntax=20= and=20synonyms

-The=20proposed=20new=20RFC=20that=20= updates=20RFC=202838=20would=20keep=20most=20parts=20of=20RFC=202838=20una= ffected.=20The=20American=20tv:=20URI=20examples=20of=20RFC=202838=20would= =20remain=20unchanged,=20as=20these=20tv:=20URIs=20do=20already=20match=20= with=20a=20website.=20The=20Australian=20ABC=20channel=20would=20become=20= tv:abc.net.au,=20corresponding=20to=20their=20actual=20website=20name.

-There=20is=20an=20update=20to=20the=20= RFC=202838=20syntax=20needed,=20as=20some=20TV=20channels=20would=20be=20i= dentified=20by=20a=20resource=20(using=20“/”)=20in=20our=20pro= posal=20and=20not=20only=20by=20a=20domain=20name.=20Two=20examples=20of=20= this=20are=20tv:bbc.co.uk/bbcone=20and=20tv:nationalgeographic.nl/channel.=

-Another=20issue=20for=20the=20update= =20is=20synonyms.=20Some=20websites=20work=20both=20with=20and=20without=20= the=20“www”=20part=20in=20its=20URI.=20Some=20websites=20redir= ect=20to=20other=20websites.=20The=20website=20ht= tp://nederland1.nl=20redi= rects=20to=20http://portal.omroep.nl/ned1= .=20In=20order=20to=20ach= ieve=20the=20highest=20level=20of=20interoperability,=20synonyms=20should=20= be=20accepted=20as=20names=20of=20TV=20channels.

Please=20let=20us=20know=20your=20rea= ction=20on=20this=20proposal.

Best=20regards,

Oskar

--------------------------------
dr.ir.=20M.=20Oskar=20van=20Deventer=
TNO=20Information=20and=20Communication=20Technology
P.O.=20box=205050
2600=20GB&nbs= p;=20Delft
Netherlands
+31=20651=20914=209= 18
oskar.vandeve= nter@tno.nl
-------------= -------------------


This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html
------_=_NextPart_001_01C6C2CF.C5266AE9-- From discuss-bounces@apps.ietf.org Sun Aug 20 05:42:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEjnV-0003ci-Ak; Sun, 20 Aug 2006 05:40:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEjnT-0003cd-TE for discuss@apps.ietf.org; Sun, 20 Aug 2006 05:40:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GEjnS-0002if-Gg for discuss@apps.ietf.org; Sun, 20 Aug 2006 05:40:47 -0400 Received: (qmail invoked by alias); 20 Aug 2006 09:40:45 -0000 Received: from p508FA4F7.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.164.247] by mail.gmx.net (mp026) with SMTP; 20 Aug 2006 11:40:45 +0200 X-Authenticated: #1915285 Message-ID: <44E82E18.6030605@gmx.de> Date: Sun, 20 Aug 2006 11:40:40 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "Deventer, M.O. \(Oskar\) van" Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: discuss@apps.ietf.org, "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 Hi, first of all, I was surprised to hear that there a "tv" URI scheme. Turns out, it hasn't been published through the IESG, and the URI scheme hasn't been registered through IANA. I do agree with your analysis that the URI scheme in itself is insufficient. Maybe this would have been discovered if it would have been published through the IESG. Now, as an informational spec what it says may be OK - it just documents what some vendors (probably mainly in the US) have been using. Now if what you're looking for is a URI to be used on the Internet, requirements are higher. In particular, you should demonstrate that you actually need a URI scheme, which is not completely obvious to me. Best regards, Julian From discuss-bounces@apps.ietf.org Sun Aug 20 07:10:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GElB8-00060r-56; Sun, 20 Aug 2006 07:09:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GElB6-00060l-Jp for discuss@apps.ietf.org; Sun, 20 Aug 2006 07:09:16 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GElB5-00011n-Bv for discuss@apps.ietf.org; Sun, 20 Aug 2006 07:09:16 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 20 Aug 2006 04:09:15 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7KB9E2w027102; Sun, 20 Aug 2006 04:09:14 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7KB9EQV019676; Sun, 20 Aug 2006 04:09:14 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4359.cisco.com [10.61.81.6]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7KB0oMG021198; Sun, 20 Aug 2006 04:00:52 -0700 Message-ID: <44E842D6.5000402@cisco.com> Date: Sun, 20 Aug 2006 13:09:10 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: "Deventer, M.O. \(Oskar\) van" Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-4.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=214; t=1156072154; x=1156936154; c=relaxed/simple; s=sjdkim4002; 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=20Update=20of=20RFC=202838,=20tv=3A=20URI; X=v=3Dcisco.com=3B=20h=3DDn2FPYo9gg2C2MrBaR7JBy7nato=3D; b=CaQ1/viqXTKipbttY4bucrqvyMNDFI1+KLHnybn9sWQg1UwPNOBzGLd4xsVZnMp8Ac6IzRkn 1hp5oYBpIPuPMmRI0dmSTC4giDzuAqUXSIAQDIEoq9mzXvCsvr4NXLo+; X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: discuss@apps.ietf.org, "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 Hi, Perhaps I fail to grasp the utility of the TV URI, but why bother going to all of this work when a URL seems to be what you want? What does the new form give you that a URL does not? Thanks, Eliot From discuss-bounces@apps.ietf.org Sun Aug 20 08:25:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEmLJ-0004TB-Q0; Sun, 20 Aug 2006 08:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEmLJ-0004T5-5S for discuss@apps.ietf.org; Sun, 20 Aug 2006 08:23:53 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEmLF-0005FD-SK for discuss@apps.ietf.org; Sun, 20 Aug 2006 08:23:53 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 1E22A2F21C; Sun, 20 Aug 2006 08:24:28 -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 RYhC7VwBYjoC; Sun, 20 Aug 2006 08:24:25 -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 0DFB22F1CA; Sun, 20 Aug 2006 08:24:19 -0400 (EDT) Message-ID: <44E8544E.4020706@cs.utk.edu> Date: Sun, 20 Aug 2006 08:23:42 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Eliot Lear Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> In-Reply-To: <44E842D6.5000402@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 My impression was similar - if you're just going to have the tv: URI point to a web page, why not just use the http (or whatever) URI that points to the web page? IMHO there should be a way to use a tv: URI to do things that you'd want to do with a tv broadcast - watch it (via the net, maybe via broadcast radio, maybe via satellite), record it, find out its schedule (say in XML so you could search through it for particular programs), send them comments on particular programs, respond to opinion polls, etc. but if it turns out that the tv: URI is just equivalent to an http: URI pointing to a web page, that will cripple this potential. it's not that you couldn't define a way to do all of the above via the HTTP protocol, but having the tv: URI point to a web page would require that the HTTP interface be overloaded to support both functions (access to a human-readable web page, along with some sort of method lookup to do the other things). and there is a tremendous amount of inertia behind web servers that makes it difficult to add new methods to them to support such features. so I conclude that to get much benefit out of a tv: URI type they should not be constrained to point to web pages, and probably should not be encouraged to point to web pages. a better path would be to use NAPTR/SRV lookup in DNS to allow a client to look up things that could be done with a tv: URI. -------- Original Message -------- > Hi, > > Perhaps I fail to grasp the utility of the TV URI, but why bother going > to all of this work when a URL seems to be what you want? What does the > new form give you that a URL does not? > > Thanks, > > Eliot > From discuss-bounces@apps.ietf.org Sun Aug 20 11:30:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEpEb-0001vl-4T; Sun, 20 Aug 2006 11:29:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEpEa-0001tG-5M for discuss@apps.ietf.org; Sun, 20 Aug 2006 11:29:08 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEp1T-0004Ng-5b for discuss@apps.ietf.org; Sun, 20 Aug 2006 11:15:41 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7KEjgfa020998 for ; Sun, 20 Aug 2006 08:45:43 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4A00401WZHHH00@mail-amer.sun.com> (original mail from tbray@textuality.com) for discuss@apps.ietf.org; Sun, 20 Aug 2006 08:45:41 -0600 (MDT) Received: from [10.0.1.2] ([69.11.32.204]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4A00AYWX04IQ13@mail-amer.sun.com>; Sun, 20 Aug 2006 08:45:41 -0600 (MDT) Date: Sun, 20 Aug 2006 07:45:52 -0700 From: Tim Bray Subject: Re: Update of RFC 2838, tv: URI In-reply-to: <44E8544E.4020706@cs.utk.edu> To: Keith Moore Message-id: <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , "Zigmond, Dan" , Eliot Lear 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 Aug 20, 2006, at 5:23 AM, Keith Moore wrote: > My impression was similar - if you're just going to have the tv: > URI point to a web page, why not just use the http (or whatever) > URI that points to the web page? +1 -Tim From discuss-bounces@apps.ietf.org Sun Aug 20 16:50:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEuE8-0003xE-1S; Sun, 20 Aug 2006 16:49:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEuE7-0003x9-AN for discuss@apps.ietf.org; Sun, 20 Aug 2006 16:48:59 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEuE6-0005Gr-2K for discuss@apps.ietf.org; Sun, 20 Aug 2006 16:48:59 -0400 Received: from [192.168.1.100] (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 30D9C142288; Sun, 20 Aug 2006 13:48:53 -0700 (PDT) In-Reply-To: <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <52FC1A76-419A-4E06-9C7B-646F4925CE91@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Update of RFC 2838, tv: URI Date: Sun, 20 Aug 2006 13:48:40 -0700 To: Tim Bray X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: discuss@apps.ietf.org, Eliot Lear , Keith Moore , "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 This is also supported by the W3C TAG group's findings on appropriate use of URIs/URLs . An alternative that solves some use cases (not sure what the TV use cases are) is to have a "TV channel descriptor" file format which could be retrieved via HTTP, therefore have a http: scheme. Lisa On Aug 20, 2006, at 7:45 AM, Tim Bray wrote: > On Aug 20, 2006, at 5:23 AM, Keith Moore wrote: > >> My impression was similar - if you're just going to have the tv: >> URI point to a web page, why not just use the http (or whatever) >> URI that points to the web page? > > +1 > > -Tim > > > > > From discuss-bounces@apps.ietf.org Sun Aug 20 17:00:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEuOT-00072v-7S; Sun, 20 Aug 2006 16:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEuOR-00072m-DR for discuss@apps.ietf.org; Sun, 20 Aug 2006 16:59:39 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEuOQ-0006uC-6a for discuss@apps.ietf.org; Sun, 20 Aug 2006 16:59:39 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 5311F2F233; Sun, 20 Aug 2006 17:00:16 -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 IN+PQxxIUERz; Sun, 20 Aug 2006 17:00:13 -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 C47422F22A; Sun, 20 Aug 2006 17:00:12 -0400 (EDT) Message-ID: <44E8CD36.5020800@cs.utk.edu> Date: Sun, 20 Aug 2006 16:59:34 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> <52FC1A76-419A-4E06-9C7B-646F4925CE91@osafoundation.org> In-Reply-To: <52FC1A76-419A-4E06-9C7B-646F4925CE91@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , Tim Bray , "Zigmond, Dan" , Eliot Lear 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 Personally I think W3C goes a bit overboard on this. Expecting everything on the web to use HTTP just to get a description file or a redirect is just wrong. And there are many cases where, for the sake of a good user interface, you really want to expose some semantic information about the resource without the client having to access the net to get it. There's nothing wrong with having a tv: URL, just don't cripple it so that it can never be more functional than an http: URL. Keith > This is also supported by the W3C TAG group's findings on appropriate > use of URIs/URLs . > An alternative that solves some use cases (not sure what the TV use > cases are) is to have a "TV channel descriptor" file format which could > be retrieved via HTTP, therefore have a http: scheme. From discuss-bounces@apps.ietf.org Sun Aug 20 18:27:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEvkK-00019l-Vk; Sun, 20 Aug 2006 18:26:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEvkK-00019g-Dn for discuss@apps.ietf.org; Sun, 20 Aug 2006 18:26:20 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEvkI-0002CO-2G for discuss@apps.ietf.org; Sun, 20 Aug 2006 18:26:20 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7KMQGsM012357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 20 Aug 2006 15:26:16 -0700 Received: from [10.0.1.2] (vpn-10-50-16-2.qualcomm.com [10.50.16.2]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7KMQ9tA006530; Sun, 20 Aug 2006 15:26:15 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44E82E18.6030605@gmx.de> References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E82E18.6030605@gmx.de> Date: Sun, 20 Aug 2006 15:26:08 -0700 To: Julian Reschke , "Deventer, M.O. \(Oskar\) van" From: Ted Hardie Subject: Re: Update of RFC 2838, tv: URI Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: discuss@apps.ietf.org, "Zigmond, Dan" , "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 At 11:40 AM +0200 8/20/06, Julian Reschke wrote: >Hi, > >first of all, I was surprised to hear that there a "tv" URI scheme. Turns out, it hasn't been published through the IESG, and the URI scheme hasn't been registered through IANA. Actually, this looks like a bug in the IANA registry. The TV uri scheme is described in RFC 2838, as the original poster notes. That means it should be (at the very least) be in the registry as provisional. Have the proponents of changing it talked to the original authors to see if it is still in use according to the original spec? I believe Liberate made set-top boxes, for example, which may still be in use and are pretty tough to upgrade. The salient bit for this discussion seems to come from section 3.2 of 2838; especially this text: In some cases, networks have multiple broadcast streams that need to be distinguished. This is also handled in DNS style: tv:east.hbo.com HBO East tv:west.hbo.com HBO West It is important to note that these DNS-style identifiers need not match real hostnames; they should not be resolved to IP addresses using DNS. Thus, using the terms as defined in RFC 2396, the "tv:" scheme is a Uniform Resource Identifier and not a Uniform Resource Locator. In order to support these identifiers in a "tv:" URI, a receiver must implement a means to map known identifiers to frequencies. The nature of this map and the way in which it is used are currently browser- and device-specific and are beyond the scope of this document. In this way, the "tv:" scheme is somewhat analogous to the "news:" and "file:" schemes in [1]: it merely names a television broadcast signal but assumes that the local browser has some means for actually retrieving that signal on the local device. A variety of software systems currently provide device-specific mappings from such identifiers to specific channel numbers or directly to frequencies. These systems can be incorporated into television sets or set-top boxes to facilitate the interpretation of television URIs by the client device. That is, the original registrants presumed that you would be able to mint dns-style identifiers for the mapping. Sounds like this does not satisfy the needs that have now been expressed. I note as well that we already have a second URI scheme (CRID, described in RFC 4078) that tackles the same space. Is there any hope of using it instead? Or are we looking at a third, with possible deprecation of a the first? regards, Ted Hardie From discuss-bounces@apps.ietf.org Mon Aug 21 01:29:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF2LD-00074w-F4; Mon, 21 Aug 2006 01:28:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF2LC-00074o-3T for discuss@apps.ietf.org; Mon, 21 Aug 2006 01:28:50 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF2L9-0005hM-Di for discuss@apps.ietf.org; Mon, 21 Aug 2006 01:28:50 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k7L5SXU8023415; Mon, 21 Aug 2006 14:28:33 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 05bb_e340678c_30d5_11db_8d2e_0014221fa3c9; Mon, 21 Aug 2006 14:28:33 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7L5SS6e006540; Mon, 21 Aug 2006 14:28:29 +0900 Message-Id: <6.0.0.20.2.20060821121320.18846140@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 21 Aug 2006 12:38:58 +0900 To: Keith Moore , Eliot Lear From: Martin Duerst Subject: Re: Update of RFC 2838, tv: URI In-Reply-To: <44E8544E.4020706@cs.utk.edu> References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: discuss@apps.ietf.org, "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 [Re. venue for follow-up discussions, I suggest that the URI mailing list (uri@w3.org), in particular for syntax aspects.] At 21:23 06/08/20, Keith Moore wrote: >My impression was similar - if you're just going to have the tv: URI point to a web page, why not just use the http (or whatever) URI that points to the web page? In my understanding, the intent is not to use HTTP for retrieval, but just to use DNS and Web pages as a lightweight way of assigning IDs to TV channels. The web page is only used for minting, and the URI points to the actual TV program/channel/feed or whatever you call it. >IMHO there should be a way to use a tv: URI to do things that you'd want to do with a tv broadcast - watch it (via the net, maybe via broadcast radio, maybe via satellite), record it, find out its schedule (say in XML so you could search through it for particular programs), send them comments on particular programs, respond to opinion polls, etc. Again just in my understanding, watching it would indeed be the primary purpose. So if you clicked on a URI like tv:bbc.co.uk/bbcone, on a sufficiently equiped and configured device, you would view that channel. On the other hand, if you clicked http://bbc.co.uk/bbcone, you would just be looking at a Web page, not a television program. The association between the tv: URI and the actual channel can be done in various ways. One way is to embedd the URI into the metadata part of the actual channel, i.e. having something in the program say "hey, btw, I'm tv:bbc.co.uk/bbcone". A device would scan the channels every so often and cache that information. While I don't know to what extent this kind of scanning is feasible from a HW point of view, it would be most reliable (assuming that TV stations wouldn't want to claim that they are somebody else). Another way is to hard-code that data when configuring the device, but this is only possible to a certain extent. A third way is to get the data from a third party (e.g. a TiVO like service). A fourth way would be to embedd some data into the 'corresponding' Web page, but this is likely going to be rather difficult, because the same TV program may appear on different physical channels in different areas of a country (at least that's the case here in Japan, NHK, the national program, appears on channel 1 in the greater Tokyo area, and on channel 2 in and around Osaka). >but if it turns out that the tv: URI is just equivalent to an http: URI pointing to a web page, that will cripple this potential. it's not that you couldn't define a way to do all of the above via the HTTP protocol, but having the tv: URI point to a web page would require that the HTTP interface be overloaded to support both functions (access to a human-readable web page, along with some sort of method lookup to do the other things). and there is a tremendous amount of inertia behind web servers that makes it difficult to add new methods to them to support such features. While my understanding is that this is not what's intended, 'extension' of HTTP for the above purposes wouldn't be done by adding new methods to HTTP. It could be done much more easily through content negotiation (defining new mime types for the "other things"). [As for new methods, they would indeed meet with substantial inertia, but it's important to see that the number of servers affected would be minimal when compared to all the Web servers out there.] >so I conclude that to get much benefit out of a tv: URI type they should not be constrained to point to web pages, and probably should not be encouraged to point to web pages. a better path would be to use NAPTR/SRV lookup in DNS to allow a client to look up things that could be done with a tv: URI. This would be in line with the DNS-based handling that Ted mentioned is already in the current RFC: tv:east.hbo.com HBO East tv:west.hbo.com HBO West Regards, Martin. >-------- Original Message -------- > >> Hi, >> Perhaps I fail to grasp the utility of the TV URI, but why bother going >> to all of this work when a URL seems to be what you want? What does the >> new form give you that a URL does not? >> Thanks, >> Eliot >> > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Mon Aug 21 07:59:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF8QH-00043E-5R; Mon, 21 Aug 2006 07:58:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF8QF-000438-AF for discuss@apps.ietf.org; Mon, 21 Aug 2006 07:58:27 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF8QC-00074X-W7 for discuss@apps.ietf.org; Mon, 21 Aug 2006 07:58:27 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 2043F56501; Mon, 21 Aug 2006 07:03:14 -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 THZ8YNg7yzfq; Mon, 21 Aug 2006 07:03:10 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 3C96056506; Mon, 21 Aug 2006 07:03:08 -0400 (EDT) Message-ID: <44E9931D.50201@cs.utk.edu> Date: Mon, 21 Aug 2006 07:03:57 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Martin Duerst Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <6.0.0.20.2.20060821121320.18846140@localhost> In-Reply-To: <6.0.0.20.2.20060821121320.18846140@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , "Zigmond, Dan" , Eliot Lear 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 > [Re. venue for follow-up discussions, I suggest that the URI mailing > list (uri@w3.org), in particular for syntax aspects.] > > At 21:23 06/08/20, Keith Moore wrote: >> My impression was similar - if you're just going to have the tv: >> URI point to a web page, why not just use the http (or whatever) >> URI that points to the web page? > > In my understanding, the intent is not to use HTTP for retrieval, but > just to use DNS and Web pages as a lightweight way of assigning IDs > to TV channels. The web page is only used for minting, and the URI > points to the actual TV program/channel/feed or whatever you call it. > yes, that's my understanding also. but it's poor design to expect existing web pages intended for humans to also contain machine-readable information about TV feeds. and it's poor architecture to effectively expect future URI types to depend on HTTP. >> IMHO there should be a way to use a tv: URI to do things that you'd >> want to do with a tv broadcast - watch it (via the net, maybe via >> broadcast radio, maybe via satellite), record it, find out its >> schedule (say in XML so you could search through it for particular >> programs), send them comments on particular programs, respond to >> opinion polls, etc. > > Again just in my understanding, watching it would indeed be the > primary purpose. So if you clicked on a URI like tv:bbc.co.uk/bbcone, > on a sufficiently equiped and configured device, you would view that > channel. On the other hand, if you clicked http://bbc.co.uk/bbcone, > you would just be looking at a Web page, not a television program. more generally you might have a pull-down menu that provided options about what to do with the tv: URI - watch, look at the schedule for future programs, schedule a recording of a future program, look at recordings or transcripts of previously broadcast programs, etc. even more generally, the URI might be processed by a very different tool than a web browser. (we shouldn't assume that the only vehicle to resources on "the web" is via a single kind of tool) > The association between the tv: URI and the actual channel can be > done in various ways. true, but when you have a URI that is based on a DNS name, the natural authoritative source of that data is DNS. >> but if it turns out that the tv: URI is just equivalent to an http: >> URI pointing to a web page, that will cripple this potential. >> it's not that you couldn't define a way to do all of the above via >> the HTTP protocol, but having the tv: URI point to a web page would >> require that the HTTP interface be overloaded to support both >> functions (access to a human-readable web page, along with some >> sort of method lookup to do the other things). and there is a >> tremendous amount of inertia behind web servers that makes it >> difficult to add new methods to them to support such features. > > While my understanding is that this is not what's intended, > 'extension' of HTTP for the above purposes wouldn't be done by adding > new methods to HTTP. It could be done much more easily through > content negotiation (defining new mime types for the "other things"). > that's even uglier. Keith From discuss-bounces@apps.ietf.org Mon Aug 21 08:37:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF91C-0007er-D9; Mon, 21 Aug 2006 08:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF91B-0007em-54 for discuss@apps.ietf.org; Mon, 21 Aug 2006 08:36:37 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF919-0004VB-Oa for discuss@apps.ietf.org; Mon, 21 Aug 2006 08:36:37 -0400 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7LCanY1001484; Mon, 21 Aug 2006 05:36:50 -0700 Message-ID: <44E9A612.20906@ninebynine.org> Date: Mon, 21 Aug 2006 13:24:50 +0100 From: Graham Klyne User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Julian Reschke Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E82E18.6030605@gmx.de> In-Reply-To: <44E82E18.6030605@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: gk@ninebynine.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 FWIW, discussion about including the tv: URI scheme (and some others that got missed) in the URI registry is already under way. (This comment is independent of the separate discussion about the appropriateness or role of a tv: URI scheme.) #g -- Julian Reschke wrote: > Hi, > > first of all, I was surprised to hear that there a "tv" URI scheme. > Turns out, it hasn't been published through the IESG, and the URI scheme > hasn't been registered through IANA. > > I do agree with your analysis that the URI scheme in itself is > insufficient. Maybe this would have been discovered if it would have > been published through the IESG. > > Now, as an informational spec what it says may be OK - it just documents > what some vendors (probably mainly in the US) have been using. > > Now if what you're looking for is a URI to be used on the Internet, > requirements are higher. In particular, you should demonstrate that you > actually need a URI scheme, which is not completely obvious to me. > > Best regards, Julian > -- Graham Klyne For email: http://www.ninebynine.org/#Contact From discuss-bounces@apps.ietf.org Mon Aug 21 11:21:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBa2-00073d-Lb; Mon, 21 Aug 2006 11:20:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEqb8-0004bg-6i for discuss@apps.ietf.org; Sun, 20 Aug 2006 12:56:30 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEqSL-0007as-DW for discuss@apps.ietf.org; Sun, 20 Aug 2006 12:47:26 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 12:47:42 -0400 Received: from 10.128.41.1 ([10.128.41.1]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Sun, 20 Aug 2006 16:47:41 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Sun, 20 Aug 2006 12:47:17 -0400 Subject: Re: Update of RFC 2838, tv: URI From: Eric Burger To: "Keesmaat,N.W. (Iko)" Message-ID: Thread-Topic: Update of RFC 2838, tv: URI Thread-Index: AcbEU7LPt4udk5BuQze9vh6t+56w/wAJJjKi In-Reply-To: <44E8544E.4020706@cs.utk.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3238922838_1201136" X-OriginalArrivalTime: 20 Aug 2006 16:47:42.0376 (UTC) FILETIME=[5AB7EA80:01C6C478] X-Spam-Score: 0.5 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 X-Mailman-Approved-At: Mon, 21 Aug 2006 11:20:44 -0400 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 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3238922838_1201136 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Said more strongly, most TV is IPTV is today carried by RTSP (although some of us would like to see SIP there, but that is an RAI, not APP issue). It sounds like you are looking for some sort of location and guide service. For that, have you considered SAP or related protocols? On 8/20/06 8:23 AM, "Keith Moore" wrote: > My impression was similar - if you're just going to have the tv: URI > point to a web page, why not just use the http (or whatever) URI that > points to the web page? > > IMHO there should be a way to use a tv: URI to do things that you'd want > to do with a tv broadcast - watch it (via the net, maybe via broadcast > radio, maybe via satellite), record it, find out its schedule (say in > XML so you could search through it for particular programs), send them > comments on particular programs, respond to opinion polls, etc. > > but if it turns out that the tv: URI is just equivalent to an http: URI > pointing to a web page, that will cripple this potential. it's not > that you couldn't define a way to do all of the above via the HTTP > protocol, but having the tv: URI point to a web page would require that > the HTTP interface be overloaded to support both functions (access to a > human-readable web page, along with some sort of method lookup to do the > other things). and there is a tremendous amount of inertia behind web > servers that makes it difficult to add new methods to them to support > such features. > > so I conclude that to get much benefit out of a tv: URI type they should > not be constrained to point to web pages, and probably should not be > encouraged to point to web pages. a better path would be to use > NAPTR/SRV lookup in DNS to allow a client to look up things that could > be done with a tv: URI. > > -------- Original Message -------- > >> > Hi, >> > >> > Perhaps I fail to grasp the utility of the TV URI, but why bother going >> > to all of this work when a URL seems to be what you want? What does the >> > new form give you that a URL does not? >> > >> > Thanks, >> > >> > Eliot >> > > > > --B_3238922838_1201136 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: Update of RFC 2838, tv: URI Said = more strongly, most TV is IPTV is today carried by RTSP (although some of us= would like to see SIP there, but that is an RAI, not APP issue).

It sounds like you are looking for some sort of location and guide service.= For that, have you considered SAP or related protocols?


On 8/20/06 8:23 AM, "Keith Moore" <moore@cs.utk.edu> wrote:=

My impression was similar - if you're just going to hav= e the tv: URI
point to a web page, why not just use the http (or whatever) URI that
points to the web page?

IMHO there should be a way to use a tv: URI to do things that you'd want to do with a tv broadcast - watch it (via the net, maybe via broadcast
radio, maybe via satellite), record it, find out its schedule (say in
XML so you could search through it for particular programs), send them
comments on particular programs, respond to opinion polls, etc.

but if it turns out that the tv: URI is just equivalent to an http: URI
pointing to a web page,  that will cripple this potential.  it's = not
that you couldn't define a way to do all of the above via the HTTP
protocol, but having the tv: URI point to a web page would require that
the HTTP interface be overloaded to support both functions (access to a
human-readable web page, along with some sort of method lookup to do the other things).  and there is a tremendous amount of inertia behind web=
servers that makes it difficult to add new methods to them to support
such features.

so I conclude that to get much benefit out of a tv: URI type they should not be constrained to point to web pages, and probably should not be
encouraged to point to web pages.  a better path would be to use
NAPTR/SRV lookup in DNS to allow a client to look up things that could
be done with a tv: URI.

-------- Original Message --------

> Hi,
>
> Perhaps I fail to grasp the utility of the TV URI, but why bother goin= g
> to all of this work when a URL seems to be what you want?  What d= oes the
> new form give you that a URL does not?
>
> Thanks,
>
> Eliot
>




 --B_3238922838_1201136-- From discuss-bounces@apps.ietf.org Mon Aug 21 11:46:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFByL-0007ts-Bj; Mon, 21 Aug 2006 11:45:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFByJ-0007rb-Bx for discuss@apps.ietf.org; Mon, 21 Aug 2006 11:45:51 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFByI-0006kv-3r for discuss@apps.ietf.org; Mon, 21 Aug 2006 11:45:51 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 21 Aug 2006 08:36:48 -0700 X-IronPort-AV: i="4.08,152,1154934000"; d="scan'208"; a="441104738:sNHT30204136" 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 k7LFalCg022212; Mon, 21 Aug 2006 08:36:47 -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 k7LFao1E007428; Mon, 21 Aug 2006 08:36:50 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp580.cisco.com [10.61.66.68]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7LFSKgD030461; Mon, 21 Aug 2006 08:28:21 -0700 Message-ID: <44E9D30D.6070902@cisco.com> Date: Mon, 21 Aug 2006 17:36:45 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Eric Burger Subject: Re: Update of RFC 2838, tv: URI References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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=210; t=1156174607; x=1157038607; 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=20Update=20of=20RFC=202838,=20tv=3A=20URI; X=v=3Dcisco.com=3B=20h=3DDn2FPYo9gg2C2MrBaR7JBy7nato=3D; b=blSkK3f7BHqjhmtBQ5UTahe6kkSsBE6y/rSL3H+uONdblc98tUnQpV0/OOp250sMexqAjCc7 t72tumbwgnErJAlqP0rKGdEb60KDM7814oJs5wFnhFrlwOTSGszKS1mg; X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: discuss@apps.ietf.org, "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 Has anyone considered taking the best of the CRID standard and of iCalendar to transmit this information? That way people can integrate what shows they want to watch with their personal calendars. Eliot From discuss-bounces@apps.ietf.org Mon Aug 21 11:54:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFC5y-0001T9-35; Mon, 21 Aug 2006 11:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFC5w-0001T3-6u for discuss@apps.ietf.org; Mon, 21 Aug 2006 11:53:44 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFC5t-0008D7-T9 for discuss@apps.ietf.org; Mon, 21 Aug 2006 11:53:44 -0400 Received: from [192.168.1.100] (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 87358142288; Mon, 21 Aug 2006 08:27:55 -0700 (PDT) In-Reply-To: <44E8CD36.5020800@cs.utk.edu> References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> <52FC1A76-419A-4E06-9C7B-646F4925CE91@osafoundation.org> <44E8CD36.5020800@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33C674FE-1075-4911-A0D2-A3C690C672FE@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Update of RFC 2838, tv: URI Date: Mon, 21 Aug 2006 08:27:42 -0700 To: Keith Moore X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , Tim Bray , "Zigmond, Dan" , Eliot Lear 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 agree there is a need, for a good interface, to expose some semantic information about the resource without having to access it across the net. I'm not sure that means the scheme is a good place for this information though (and pretty clearly W3C TAG thinks it's not). The Microformats mechanisms uses "class" attributes on the "a" link element to indicate what kind of an HTTP link is in the "href" attribute: a friend's blog location, the page owner's calendar location, etc. Of course, this approach works best in Web pages, and can work in email only if using rich email or ugly URLs, and can be used in other media similarly. Lisa On Aug 20, 2006, at 1:59 PM, Keith Moore wrote: > Personally I think W3C goes a bit overboard on this. Expecting > everything on the web to use HTTP just to get a description file or > a redirect is just wrong. And there are many cases where, for the > sake of a good user interface, you really want to expose some > semantic information about the resource without the client having > to access the net to get it. > > There's nothing wrong with having a tv: URL, just don't cripple it > so that it can never be more functional than an http: URL. > > Keith > >> This is also supported by the W3C TAG group's findings on >> appropriate use of URIs/URLs > SchemeProtocols.html>. An alternative that solves some use cases >> (not sure what the TV use cases are) is to have a "TV channel >> descriptor" file format which could be retrieved via HTTP, >> therefore have a http: scheme. > From discuss-bounces@apps.ietf.org Mon Aug 21 12:14:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCPM-0000my-SR; Mon, 21 Aug 2006 12:13:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCMW-0008HA-Ul for discuss@apps.ietf.org; Mon, 21 Aug 2006 12:10:53 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFC97-0000k9-Ck for discuss@apps.ietf.org; Mon, 21 Aug 2006 11:57:03 -0400 Received: (qmail invoked by alias); 21 Aug 2006 15:56:59 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp035) with SMTP; 21 Aug 2006 17:56:59 +0200 X-Authenticated: #1915285 Message-ID: <44E9D7CE.2030505@gmx.de> Date: Mon, 21 Aug 2006 17:57:02 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> <52FC1A76-419A-4E06-9C7B-646F4925CE91@osafoundation.org> <44E8CD36.5020800@cs.utk.edu> <33C674FE-1075-4911-A0D2-A3C690C672FE@osafoundation.org> In-Reply-To: <33C674FE-1075-4911-A0D2-A3C690C672FE@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Eliot Lear , discuss@apps.ietf.org, Tim Bray , "Zigmond, Dan" , Keith Moore , "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 Lisa Dusseault schrieb: > > I agree there is a need, for a good interface, to expose some semantic > information about the resource without having to access it across the > net. I'm not sure that means the scheme is a good place for this > information though (and pretty clearly W3C TAG thinks it's not). > > The Microformats mechanisms uses "class" attributes > on the "a" link element to indicate what kind of an HTTP link is in the > "href" attribute: a friend's blog location, the page owner's calendar > location, etc. Of course, this approach works best in Web pages, and > can work in email only if using rich email or ugly URLs, and can be used > in other media similarly. Wait a second; please don't confuse this with Microformats. HTML already has a way to signal information about the nature of a relation, that's the "rel" attribute (). Best regards, Julian From discuss-bounces@apps.ietf.org Mon Aug 21 12:42:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCqi-0001iv-6F; Mon, 21 Aug 2006 12:42:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCqg-0001iq-S0 for discuss@apps.ietf.org; Mon, 21 Aug 2006 12:42:02 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFCqf-0003Sc-Jb for discuss@apps.ietf.org; Mon, 21 Aug 2006 12:42:02 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 96437FD3C; Mon, 21 Aug 2006 12:07:27 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDHKqPbB7EdD; Mon, 21 Aug 2006 12:07:17 -0400 (EDT) Received: from [192.168.1.126] (adsl-155-107-20.tys.bellsouth.net [72.155.107.20]) by bes.cs.utk.edu (Postfix) with ESMTP id A6FDCFD24; Mon, 21 Aug 2006 12:07:10 -0400 (EDT) Message-ID: <44E9DA72.9050807@cs.utk.edu> Date: Mon, 21 Aug 2006 12:08:18 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> <52FC1A76-419A-4E06-9C7B-646F4925CE91@osafoundation.org> <44E8CD36.5020800@cs.utk.edu> <33C674FE-1075-4911-A0D2-A3C690C672FE@osafoundation.org> In-Reply-To: <33C674FE-1075-4911-A0D2-A3C690C672FE@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , Tim Bray , "Zigmond, Dan" , Eliot Lear 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 agree there is a need, for a good interface, to expose some semantic > information about the resource without having to access it across the > net. I'm not sure that means the scheme is a good place for this > information though (and pretty clearly W3C TAG thinks it's not). > > The Microformats mechanisms uses "class" attributes > on the "a" link element to indicate what kind of an HTTP link is in the > "href" attribute: a friend's blog location, the page owner's calendar > location, etc. Of course, this approach works best in Web pages, and > can work in email only if using rich email or ugly URLs, and can be used > in other media similarly. I agree that there are limitations to what can or should be exposed in a URI scheme name, though I don't think the example of "tv:" stretches the bounds too much. I think it's a stretch to assume that URIs can generally be associated with metadata that exposes semantic information about the resource. For better or worse, a URI is a natural container, and the URI is really the only thing that approaches being a universal coin of the web. There's not nearly the degree of acceptance for any kind of metadata that there is for the URI, and I'd expect convergence on metadata (both schemas and presentation layers) to occur much more slowly than convergence on resource identifiers. I find myself disagreeing with many of TAG's recommendations about URI use - basically I think they're being very unrealistic and idealistic in some areas while ignoring a number of practical considerations. I don't think IETF should constrain itself, or the URI registry should be constrained by, the mere fact that TAG has made some contrary recommendations. Keith From discuss-bounces@apps.ietf.org Mon Aug 21 21:10:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKlv-0001Vw-1p; Mon, 21 Aug 2006 21:09:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKlt-0001Uy-W8 for discuss@apps.ietf.org; Mon, 21 Aug 2006 21:09:38 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFKlo-0004Mg-Aq for discuss@apps.ietf.org; Mon, 21 Aug 2006 21:09:37 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k7M19SNO009888; Tue, 22 Aug 2006 10:09:28 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 738a_dbe42c6c_317a_11db_8013_0014221f2a2d; Tue, 22 Aug 2006 10:09:27 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7M197XY024478; Tue, 22 Aug 2006 10:09:08 +0900 Message-Id: <6.0.0.20.2.20060822095245.07682840@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 22 Aug 2006 09:57:56 +0900 To: Keith Moore From: Martin Duerst Subject: Re: Update of RFC 2838, tv: URI In-Reply-To: <44E9931D.50201@cs.utk.edu> References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <6.0.0.20.2.20060821121320.18846140@localhost> <44E9931D.50201@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , "Zigmond, Dan" , Eliot Lear 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 At 20:03 06/08/21, Keith Moore wrote: >> [Re. venue for follow-up discussions, I suggest that the URI mailing list (uri@w3.org), in particular for syntax aspects.] >> At 21:23 06/08/20, Keith Moore wrote: >>> My impression was similar - if you're just going to have the tv: >>> URI point to a web page, why not just use the http (or whatever) >>> URI that points to the web page? >> In my understanding, the intent is not to use HTTP for retrieval, but >> just to use DNS and Web pages as a lightweight way of assigning IDs >> to TV channels. The web page is only used for minting, and the URI >> points to the actual TV program/channel/feed or whatever you call it. >> >yes, that's my understanding also. but it's poor design to expect >existing web pages intended for humans to also contain machine-readable >information about TV feeds. But that's not part of the design. >and it's poor architecture to effectively >expect future URI types to depend on HTTP. They don't depend on HTTP except for minting, with is a one-time operation. If HTTP ever goes away, the URI scheme can easily be redefined to mint new identifiers in a different way. >> Again just in my understanding, watching it would indeed be the primary purpose. So if you clicked on a URI like tv:bbc.co.uk/bbcone, >> on a sufficiently equiped and configured device, you would view that >> channel. On the other hand, if you clicked http://bbc.co.uk/bbcone, you would just be looking at a Web page, not a television program. > >more generally you might have a pull-down menu that provided options >about what to do with the tv: URI - watch, look at the schedule for >future programs, schedule a recording of a future program, look at >recordings or transcripts of previously broadcast programs, etc. > >even more generally, the URI might be processed by a very different tool >than a web browser. (we shouldn't assume that the only vehicle to >resources on "the web" is via a single kind of tool) Yes. Please note above that I said "click", which is somewhat problematic with respect to accessibility, but is completely tool-agnostic. I regularly click on URIs in my MUA :-). >> The association between the tv: URI and the actual channel can be done in various ways. > >true, but when you have a URI that is based on a DNS name, the natural >authoritative source of that data is DNS. This is a good point. >> While my understanding is that this is not what's intended, >> 'extension' of HTTP for the above purposes wouldn't be done by adding >> new methods to HTTP. It could be done much more easily through >> content negotiation (defining new mime types for the "other things"). >> >that's even uglier. Can you explain that. How is it uglier to define mime types video/... or application/videometadata+xml or something like that than to use a new method such as GETVIDEOMETADATA ? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Mon Aug 21 21:10:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKm1-0001Xt-8U; Mon, 21 Aug 2006 21:09:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKm0-0001Xg-2h for discuss@apps.ietf.org; Mon, 21 Aug 2006 21:09:44 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFKlw-0004Mw-Fu for discuss@apps.ietf.org; Mon, 21 Aug 2006 21:09:44 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k7M19ctB017356; Tue, 22 Aug 2006 10:09:38 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 66d8_e227429e_317a_11db_8437_0014221fa3c9; Tue, 22 Aug 2006 10:09:38 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7M197Xc024478; Tue, 22 Aug 2006 10:09:37 +0900 Message-Id: <6.0.0.20.2.20060822100240.07685ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 22 Aug 2006 10:04:38 +0900 To: Graham Klyne , Julian Reschke From: Martin Duerst Subject: Re: Update of RFC 2838, tv: URI In-Reply-To: <44E9A612.20906@ninebynine.org> References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E82E18.6030605@gmx.de> <44E9A612.20906@ninebynine.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 At 21:24 06/08/21, Graham Klyne wrote: >FWIW, discussion about including the tv: URI scheme (and some others that got >missed) in the URI registry is already under way. Great to hear that. Can you give an idea where that's underway? I was under the assumption I'm subscribed to the relevant mailing list (uri-review@ietf.org). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Mon Aug 21 21:10:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKlv-0001Vw-1p; Mon, 21 Aug 2006 21:09:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKlt-0001Uy-W8 for discuss@apps.ietf.org; Mon, 21 Aug 2006 21:09:38 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFKlo-0004Mg-Aq for discuss@apps.ietf.org; Mon, 21 Aug 2006 21:09:37 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k7M19SNO009888; Tue, 22 Aug 2006 10:09:28 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 738a_dbe42c6c_317a_11db_8013_0014221f2a2d; Tue, 22 Aug 2006 10:09:27 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7M197XY024478; Tue, 22 Aug 2006 10:09:08 +0900 Message-Id: <6.0.0.20.2.20060822095245.07682840@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 22 Aug 2006 09:57:56 +0900 To: Keith Moore From: Martin Duerst Subject: Re: Update of RFC 2838, tv: URI In-Reply-To: <44E9931D.50201@cs.utk.edu> References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <6.0.0.20.2.20060821121320.18846140@localhost> <44E9931D.50201@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , "Zigmond, Dan" , Eliot Lear 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 At 20:03 06/08/21, Keith Moore wrote: >> [Re. venue for follow-up discussions, I suggest that the URI mailing list (uri@w3.org), in particular for syntax aspects.] >> At 21:23 06/08/20, Keith Moore wrote: >>> My impression was similar - if you're just going to have the tv: >>> URI point to a web page, why not just use the http (or whatever) >>> URI that points to the web page? >> In my understanding, the intent is not to use HTTP for retrieval, but >> just to use DNS and Web pages as a lightweight way of assigning IDs >> to TV channels. The web page is only used for minting, and the URI >> points to the actual TV program/channel/feed or whatever you call it. >> >yes, that's my understanding also. but it's poor design to expect >existing web pages intended for humans to also contain machine-readable >information about TV feeds. But that's not part of the design. >and it's poor architecture to effectively >expect future URI types to depend on HTTP. They don't depend on HTTP except for minting, with is a one-time operation. If HTTP ever goes away, the URI scheme can easily be redefined to mint new identifiers in a different way. >> Again just in my understanding, watching it would indeed be the primary purpose. So if you clicked on a URI like tv:bbc.co.uk/bbcone, >> on a sufficiently equiped and configured device, you would view that >> channel. On the other hand, if you clicked http://bbc.co.uk/bbcone, you would just be looking at a Web page, not a television program. > >more generally you might have a pull-down menu that provided options >about what to do with the tv: URI - watch, look at the schedule for >future programs, schedule a recording of a future program, look at >recordings or transcripts of previously broadcast programs, etc. > >even more generally, the URI might be processed by a very different tool >than a web browser. (we shouldn't assume that the only vehicle to >resources on "the web" is via a single kind of tool) Yes. Please note above that I said "click", which is somewhat problematic with respect to accessibility, but is completely tool-agnostic. I regularly click on URIs in my MUA :-). >> The association between the tv: URI and the actual channel can be done in various ways. > >true, but when you have a URI that is based on a DNS name, the natural >authoritative source of that data is DNS. This is a good point. >> While my understanding is that this is not what's intended, >> 'extension' of HTTP for the above purposes wouldn't be done by adding >> new methods to HTTP. It could be done much more easily through >> content negotiation (defining new mime types for the "other things"). >> >that's even uglier. Can you explain that. How is it uglier to define mime types video/... or application/videometadata+xml or something like that than to use a new method such as GETVIDEOMETADATA ? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Mon Aug 21 21:10:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKm1-0001Xt-8U; Mon, 21 Aug 2006 21:09:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKm0-0001Xg-2h for discuss@apps.ietf.org; Mon, 21 Aug 2006 21:09:44 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFKlw-0004Mw-Fu for discuss@apps.ietf.org; Mon, 21 Aug 2006 21:09:44 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k7M19ctB017356; Tue, 22 Aug 2006 10:09:38 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 66d8_e227429e_317a_11db_8437_0014221fa3c9; Tue, 22 Aug 2006 10:09:38 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7M197Xc024478; Tue, 22 Aug 2006 10:09:37 +0900 Message-Id: <6.0.0.20.2.20060822100240.07685ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 22 Aug 2006 10:04:38 +0900 To: Graham Klyne , Julian Reschke From: Martin Duerst Subject: Re: Update of RFC 2838, tv: URI In-Reply-To: <44E9A612.20906@ninebynine.org> References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E82E18.6030605@gmx.de> <44E9A612.20906@ninebynine.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 At 21:24 06/08/21, Graham Klyne wrote: >FWIW, discussion about including the tv: URI scheme (and some others that got >missed) in the URI registry is already under way. Great to hear that. Can you give an idea where that's underway? I was under the assumption I'm subscribed to the relevant mailing list (uri-review@ietf.org). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Tue Aug 22 00:17:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFNgM-0006sj-4O; Tue, 22 Aug 2006 00:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFNgK-0006se-Qg for discuss@apps.ietf.org; Tue, 22 Aug 2006 00:16:04 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFNgI-0000Af-G8 for discuss@apps.ietf.org; Tue, 22 Aug 2006 00:16:04 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 01EE4FD06; Tue, 22 Aug 2006 00:14:45 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwXSLm3NCUyi; Tue, 22 Aug 2006 00:14:43 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id B86F8FD04; Tue, 22 Aug 2006 00:14:40 -0400 (EDT) Message-ID: <44EA84F5.4030004@cs.utk.edu> Date: Tue, 22 Aug 2006 00:15:49 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Martin Duerst Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <6.0.0.20.2.20060821121320.18846140@localhost> <44E9931D.50201@cs.utk.edu> <6.0.0.20.2.20060822095245.07682840@localhost> In-Reply-To: <6.0.0.20.2.20060822095245.07682840@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , "Zigmond, Dan" , Eliot Lear 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 my understanding, the intent is not to use HTTP for retrieval, but >>> just to use DNS and Web pages as a lightweight way of assigning IDs >>> to TV channels. The web page is only used for minting, and the URI >>> points to the actual TV program/channel/feed or whatever you call it. >>> >> yes, that's my understanding also. but it's poor design to expect >> existing web pages intended for humans to also contain machine-readable >> information about TV feeds. > > But that's not part of the design. it was proposed to be part of the design. >> and it's poor architecture to effectively >> expect future URI types to depend on HTTP. > > They don't depend on HTTP except for minting, with is a one-time > operation. If HTTP ever goes away, the URI scheme can easily be > redefined to mint new identifiers in a different way. I think it's difficult to change the meaning of a URI scheme once that meaning is encoded in widely deployed software. furthermore, it's bad design to require a DNS lookup, TCP connection setup, and HTTP GET (presumably over IPv4, because that's the de facto assumption for HTTP URLs on the web) for every new URI type, when that URI type might be intended to work with DNS in a different way (say NAPTR/SRV), and perhaps contact a different host than is advertised in the DNS A or AAAA records for that domain. this defeats fate-sharing, introduces an unnecessary dependency on a web server that might be totally unrelated to the resource described by the URI, and can slow things down needlessly. >> even more generally, the URI might be processed by a very different tool >> than a web browser. (we shouldn't assume that the only vehicle to >> resources on "the web" is via a single kind of tool) > > Yes. Please note above that I said "click", which is somewhat > problematic with respect to accessibility, but is completely > tool-agnostic. I regularly click on URIs in my MUA :-). me too. but clicking is a pretty limited way of interacting with a resource - it implies that there's only one or two things you can do with it. so I don't want to think of user interfaces to resources as being just clicks. for instance, if you embedded a tv: URL in a document, you might expect to be able to watch that tv station live from within the document, or browse its (past or present) schedule, or watch programs aired in the past, etc. >>> While my understanding is that this is not what's intended, >>> 'extension' of HTTP for the above purposes wouldn't be done by adding >>> new methods to HTTP. It could be done much more easily through >>> content negotiation (defining new mime types for the "other things"). >>> >> that's even uglier. > > Can you explain that. How is it uglier to define mime types video/... > or application/videometadata+xml or something like that than to use > a new method such as GETVIDEOMETADATA ? because it tempts people to overload a resource name (URI) to mean completely different things - to be different resources - depending on content-type negotiation. somehow I don't think that's what content-negotiation is intended to be. also - if the content of the resource is the same modulo presentation format, it makes sense to use content-type negotiation, and content negotiation is designed to handle this case. but if what you're really trying to do is query a resource to find out what methods apply to the resource, content-negotiation doesn't work nearly so well. and if you overload content-negotiation to do method selection, you get a less flexible way of interacting with a resource and it also cripples the ability to do content-negotiation on some particular method of that resource. Keith From discuss-bounces@apps.ietf.org Tue Aug 22 05:30:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSZj-0001hT-0M; Tue, 22 Aug 2006 05:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSZg-0001eD-Ve for discuss@apps.ietf.org; Tue, 22 Aug 2006 05:29:32 -0400 Received: from mail134.messagelabs.com ([85.158.137.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFSZY-0006Ij-FV for discuss@apps.ietf.org; Tue, 22 Aug 2006 05:29:32 -0400 X-VirusChecked: Checked X-Env-Sender: oskar.vandeventer@tno.nl X-Msg-Ref: server-10.tower-134.messagelabs.com!1156237281!17151150!1 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 2890 invoked from network); 22 Aug 2006 09:01:21 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-10.tower-134.messagelabs.com with SMTP; 22 Aug 2006 09:01:21 -0000 Received: from ms-dt01vs01.tsn.tno.nl (cl-dt01pollux.tno.nl [134.221.225.8]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id k7M91KB04864; Tue, 22 Aug 2006 11:01:20 +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, 22 Aug 2006 11:02:10 +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: Update of RFC 2838, tv: URI Date: Tue, 22 Aug 2006 11:02:10 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56C2A73E@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of RFC 2838, tv: URI Thread-Index: AcbFoevLNplWhKAETyOgIsgg53bM/AAJw3pA From: "Deventer, M.O. \(Oskar\) van" To: X-OriginalArrivalTime: 22 Aug 2006 09:02:10.0624 (UTC) FILETIME=[A6EC4C00:01C6C5C9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 All, Here=20are=20my=20responses=20on=20some=20of=20the=20comments=20received. >=20the=20URI=20scheme=20hasn't=20been=20registered=20through=20IANA. I=20do=20not=20know=20what=20happened=20with=20RFC=202838.=20Perhaps=20Dan= =20Zigmond=20can=20tell. Notice=20that=20there=20is=20no=20(central)=20registry=20for=20tv:=20URIs,= =20as=20they=20are deduced/derived=20from=20other=20information. >=20tv:=20URI=20point=20to=20a=20web=20page A=20tv:=20URI=20does=20not=20point=20to=20a=20web=20page.=20It=20points=20= to=20a=20TV=20channel. >=20Have=20the=20proponents=20of=20changing=20it=20talked=20to=20the=20ori= ginal=20authors We=20contacted=20Dan=20Zigmond.=20Notice=20that=20all=20of=20the=20origina= l=20RFC=202838 authors=20have=20changed=20jobs. >=20Liberate=20made=20set-top=20boxes,=20...=20pretty=20tough=20to=20upgra= de Fortunately,=20there=20are=20no=20differences=20between=20RFC=202838=20and= =20our=20proposed update=20in=20the=20American=20context.=20In=20the=20American=20context,=20= RFC 2838-derived=20tv:=20URI's=20seem=20to=20match=201-on-1=20with=20the=20web= site=20associated with=20that=20TV=20channel.=20I=20haven't=20found=20any=20counter-example=20= yet.=20It=20is only=20in=20the=20European=20public-networks=20context=20that=20ambiguitie= s=20occur, which=20we=20propose=20to=20solve=20with=20an=20update. >=20it's=20difficult=20to=20change=20the=20meaning=20of=20a=20URI=20scheme= =20 >=20once=20that=20meaning=20is=20encoded=20in=20widely=20deployed=20softwa= re. Our=20proposed=20update=20will=20keep=20the=20semantics=20of=20the=20tv:=20= URI=20unchanged.=20It will=20even=20keep=20all=20American=20tv:=20URI's=20unchanged,=20as=20ment= ioned=20above. >=20It=20sounds=20like=20you=20are=20looking=20for=20some=20sort=20of=20lo= cation=20and=20guide service. We=20are=20looking=20for=20a=20way=20to=20identify=20TV=20channels=20unamb= iguously=20for=20a wide=20variety=20of=20use=20cases.=20The=20RFC=202838=20tv:=20URI=20matche= s=20our=20needs. However,=20we=20need=20an=20update=20to=20make=20this=20RFC=20also=20unamb= iguous=20in=20the European=20context. >=20CRID,=20described=20in=20RFC=204078 Crid's=20identify=20references=20to=20content,=20as=20its=20acronym=20says= .=20I=20can=20use=20a crid=20to=20make=20a=20reference=20to=20an=20episode=20of=20"Friends",=20t= o=20the=20whole "Friends"=20series=20or=20to=20comedies=20in=20general.=20When=20people=20= check=20my electronic=20program=20guide,=20it=20is=20my=20responsibility=20to=20resol= ve=20a particular=20crid=20to=20a=20locator.=20Notice=20that=20my=20crid=20that=20= refers=20to=20an episode=20of=20"Friends"=20is=20different=20from=20your=20crid=20referring= =20to=20that=20same episode,=20as=20your=20and=20my=20domain=20names=20are=20incorporated=20in= =20our=20crids. In=20summary,=20crids=20refer=20to=20content=20and=20are=20unsuited=20for=20= the=20unambiguous identification=20of=20TV=20channels.=20This=20is=20why=20RFC=202838=20exis= ts. >=20if=20you=20clicked=20on=20a=20URI=20like=20tv:bbc.co.uk/bbcone,=20on=20= a=20 >=20sufficiently=20equipped=20and=20configured=20device,=20you=20would=20v= iew >=20that=20channel. Yes,=20that=20is=20one=20of=20the=20use=20cases=20for=20RFC=202838=20and=20= its=20proposed=20update. >=20you=20might=20have=20a=20pull-down=20menu=20that=20provided=20options >=20about=20what=20to=20do=20with=20the=20tv:=20URI Yes,=20that=20could=20be=20another=20use=20case. >=20iCalendar=20to=20transmit=20this=20information?=20That=20way=20people=20= can=20integrate >=20what=20shows=20they=20want=20to=20watch=20with=20their=20personal=20ca= lendars. Yes,=20this=20is=20another=20relevant=20use=20case=20for=20tv:=20URI.=20Th= at=20is,=20if=20the TC-channel=20identification=20needs=20to=20be=20unambiguous=20and understood/interpreted=20by=20a=20machine/application. >=20the=20URI=20might=20be=20processed=20by=20a=20very=20different=20tool >=20than=20a=20web=20browser Indeed. >=20[discussions=20on=20URI=20versus=20URL,=20identifier=20versus=20locato= r] The=20tv:=20URI=20of=20RFC=202838=20is=20an=20identifier,=20not=20a=20loca= tor.=20It=20identifies TV=20channels,=20independent=20of=20the=20way=20it=20is=20broadcast=20(eth= er,=20cable, analog,=20digital,=20fast=20pigeon=20transport).=20The=20resolution=20of=20= tv:=20URI's=20is outside=20the=20scope=20of=20RFC=202838=20and=20its=20proposed=20update. >=20They=20don't=20depend=20on=20HTTP=20except=20for=20minting,=20 >=20[which]=20is=20a=20one-time=20operation. Correct. Best=20regards, Oskar 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 Aug 22 05:35:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSec-00033l-7B; Tue, 22 Aug 2006 05:34:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSeb-00033g-0w for discuss@apps.ietf.org; Tue, 22 Aug 2006 05:34:37 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFSeY-0007Em-JI for discuss@apps.ietf.org; Tue, 22 Aug 2006 05:34:37 -0400 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7M8wcA2013899; Tue, 22 Aug 2006 01:58:39 -0700 Message-ID: <44EAC134.8000809@ninebynine.org> Date: Tue, 22 Aug 2006 09:32:52 +0100 From: Graham Klyne User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Martin Duerst Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E82E18.6030605@gmx.de> <44E9A612.20906@ninebynine.org> <6.0.0.20.2.20060822100240.07685ec0@localhost> In-Reply-To: <6.0.0.20.2.20060822100240.07685ec0@localhost> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: gk@ninebynine.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Martin, Sorry, I should have given some context for my comment. As the "designated reviewer" for URI scheme registration, I was asked by IANA to review some helpful comments that have been submitted that note, among other things, a number of URI schemes that appear in RFCs but have not been captured in the registry. tv: is one of them. FWIW, my advice in this is that any scheme that is described in an RFC should be recorded in the permanent URI scheme registry, in some cases as "historic" or "obsolete", as developers out there may legitimately use these for their documented purpose, and that we should try to avoid potential inconsistent use of any scheme name. Discouraging or encouraging widespread use of any such scheme is a matter for the wider community (here and on uri-review@ietf.org), and in my role as reviewer I try to avoid judgement concerning whether a scheme is well-conceived, just that it meets appropriate criteria for registration. #g -- Martin Duerst wrote: > At 21:24 06/08/21, Graham Klyne wrote: >> FWIW, discussion about including the tv: URI scheme (and some others that got >> missed) in the URI registry is already under way. > > Great to hear that. Can you give an idea where that's underway? > I was under the assumption I'm subscribed to the relevant > mailing list (uri-review@ietf.org). > > Regards, Martin. > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > -- Graham Klyne For email: http://www.ninebynine.org/#Contact From discuss-bounces@apps.ietf.org Tue Aug 22 11:08:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFXqb-00041F-O9; Tue, 22 Aug 2006 11:07:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFXqb-000415-1e for discuss@apps.ietf.org; Tue, 22 Aug 2006 11:07:21 -0400 Received: from mail150.messagelabs.com ([85.158.136.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFXqZ-0002JH-5k for discuss@apps.ietf.org; Tue, 22 Aug 2006 11:07:21 -0400 X-VirusChecked: Checked X-Env-Sender: oskar.vandeventer@tno.nl X-Msg-Ref: server-4.tower-150.messagelabs.com!1156259237!2998092!1 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 21114 invoked from network); 22 Aug 2006 15:07:17 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-4.tower-150.messagelabs.com with SMTP; 22 Aug 2006 15:07:17 -0000 Received: from ms-dt01vs01.tsn.tno.nl (cl-dt01pollux.tno.nl [134.221.225.8]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id k7MF7GB02503; Tue, 22 Aug 2006 17:07:16 +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, 22 Aug 2006 17:08: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: Update of RFC 2838, tv: URI Date: Tue, 22 Aug 2006 17:08:07 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56C2A753@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of RFC 2838, tv: URI Thread-Index: AcbF9EUsZN0wk/QSTVekH61Rl2zX+wAB6bHQ From: "Deventer, M.O. \(Oskar\) van" To: X-OriginalArrivalTime: 22 Aug 2006 15:08:07.0436 (UTC) FILETIME=[C633ECC0:01C6C5FC] X-Spam-Score: 0.1 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd 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 Da,=20all, (Dan,=20thank=20you=20for=20forwarding=20your=20response.=20I=20missed=20i= t=20on=20the=20mailing list) >=20I=20would=20be=20happy=20to=20work=20on=20a=20revision=20of=20RFC=2028= 38=20if=20one=20is=20desired Thank=20you. >=20broadcasters=20have=20not=20rushed=20to=20establish=20identifiers=20ba= sed=20on=20this scheme This=20is=20the=20good=20thing=20about=20the=20RFC=202838=20tv:=20URI.=20I= t=20allows=20me=20to create=20internet-based=20services=20that=20point=20to=20TV=20channels=20w= ithout=20being dependent=20on=20the=20collaboration=20of=20broadcasters.=20Many=20use=20c= ases=20(see previous=20posts=20in=20this=20thread)=20would=20not=20need=20such=20colla= boration,=20but only=20an=20unambiguous=20identification=20of=20TV=20channels. >=20I'm=20not=20sure=20I=20agree=20that=20this=20approach=20runs=20into=20= any=20particular problems=20in=20Europe. Following=20the=20RFC=202838=20scheme,=20both=20tv:bbc1.bbc.co.uk=20and tv:one.bbc.co.uk=20would=20be=20proper=20tv:=20URI=20to=20identify=20the=20= BBC1=20TV channel.=20If=20my=20application=20use=20the=20one=20and=20your=20applicat= ion=20uses=20the other,=20we=20have=20an=20interoperability=20problem.=20The=20Dutch=20situ= ation=20is=20even worse=20with=20at=20least=20four=20synonyms=20for=20NED1=20and=20a=20pleth= ora=20of=20domain names=20that=20could=20be=20applicable. >=20the=20biggest=20problem=20is=20how=20to=20register=20identifiers=20und= er=20this=20scheme. The=20whole=20idea=20is=20that=20no=20registration=20is=20needed=20at=20al= l,=20if=20the deduction/derivation=20of=20the=20tv:=20URI=20from=20the=20website=20name=20= is sufficiently=20unambiguous. Best=20regards, Oskar ----------=20Forwarded=20message=20---------- From:=20Dan=20Zigmond=20 Date:=20Aug=2021,=202006=2010:01=20AM Subject:=20Re:=20Update=20of=20RFC=202838,=20tv:=20URI To:=20Keith=20Moore=20<=20moore@cs.utk.edu=20=20>= ,=20Lisa Dusseault=20,=20Tim=20Bray=20, discuss@apps.ietf.org,=20Eliot=20Lear=20,=20"Keesmaat,=20N= .W. (Iko)"=20 Hello,=20all.=20I'm=20responding=20to=20the=20thread=20as=20a=20whole=20he= re,=20rather=20than the=20specific=20comments=20about=20microformats=20and=20TAG.=20I=20was=20= the=20original author=20of=20RFC=20of=20RFC=202838=20and=20so=20can=20give=20some=20backg= round=20on=20the thinking=20behind=20it=20and=20how=20ti=20evolved=20in=20the=20process=20o= f=20RFC=20publication. (I=20vaguely=20remember=20that=20Keith=20was=20involved=20at=20the=20time,= =20but=20Microsoft did=20not=20allow=20me=20to=20keep=20my=20emails=20from=20that=20period=20= when=20I=20left,=20so=20I can't=20be=20sure.)=20 The=20original=20tv:=20Internet-Draft=20(circa=201996)=20used=20a=20much=20= simpler=20syntax: tv:nbc,=20tv:cnn,=20tv:bbc1,=20etc.=20Of=20course,=20this=20required=20som= e=20sort=20of registry,=20so=20we=20envisioned=20that=20IANA=20would=20allow=20TV=20netw= orks=20to=20reserve identifiers=20for=20their=20channels,=20and=20even=20started=20writing=20u= p=20an=20initial list=20of=20reserved=20identifiers=20for=20the=20major=20US=20networks=20a= nd=20a=20few international=20ones.=20 Unfortunately,=20we=20ran=20into=20name=20collisions=20almost=20immediatel= y:=20ABC signifies=20a=20very=20different=20TV=20broadcaster=20to=20US=20audiences=20= than=20to Australian=20ones.=20So=20we=20started=20thinking=20about=20how=20to=20res= olve=20such conflicts,=20and=20perhaps=20some=20way=20of=20qualifying=20these=20identi= fiers=20by geography,=20and=20so=20forth.=20It=20was=20my=20co-author,=20Mark=20Vicke= rs,=20who=20then suggested=20that=20this=20seemed=20like=20a=20duplication=20of=20effort:=20= the=20domain=20name system=20already=20provided=20all=20these=20mechanisms,=20and=20most=20TV=20= broadcasters already=20had=20a=20domain=20name.=20So=20we=20changed=20the=20draft=20to=20= mandate=20that identifiers=20include=20an=20assigned=20domain=20name,=20and=20the=20above= =20examples became=20something=20like=20tv:=20nbc.com =20,=20tv:=20cn= n.com =20,=20and tv:one.bbc.co.uk =20. As=20someone=20else=20already=20pointed=20out=20on=20this=20thread,=20thes= e=20were=20not intended=20to=20be=20actual=20hostnames.=20Instead,=20we=20were=20trying=20= to=20design something=20closer=20to=20the=20Java=20package=20naming=20system,=20overlo= ading=20domain names=20to=20ensure=20the=20uniqueness=20of=20an=20unrelated=20set=20of=20= identifiers.=20 I'm=20not=20sure=20I=20agree=20that=20this=20approach=20runs=20into=20any=20= particular problems=20in=20Europe.=20The=20issue,=20rather,=20is=20that=20broadcaster= s=20have=20not rushed=20to=20establish=20identifiers=20based=20on=20this=20scheme.=20So,=20= for=20example, the=20BCC=20has=20not=20published=20a=20format=20for=20referring=20to=20th= eir=20distinct broadcasts=20using=20this=20scheme;=20neither=20has=20NED1=20in=20the=20Ne= therlands. Furthermore,=20there=20isn't=20a=20clear=20mechanism=20for=20publicizing=20= such=20a decisions=20one=20a=20broadcast=20has=20made=20it;=20if=20BBC=20decided=20= tomorrow=20to=20use the=20form=20tv:=20bbc1.bbc.co.uk =20,=20i= t's not=20clear=20how=20anyone=20would=20know. We=20explicitly=20left=20everything=20beyond=20the=20usual=20hostname=20pa= rt=20of=20the=20URI undefined=20in=20this=20draft.=20Our=20assumption=20was=20that=20eventuall= y=20people=20would want=20to=20use=20the=20other=20path=20components=20to=20refer=20to=20spec= ific=20shows=20or segments=20of=20broadcasts=20(perhaps=20tv:=20bb1.bbc.co.uk/news =20= =20or something=20like=20that).=20As=20far=20as=20I=20know,=20no=20one=20is=20do= ing=20this,=20but=20it still=20seems=20a=20possibility=20for=20the=20future.=20As=20Oskar=20point= s=20out indirectly,=20the=20identifiers=20are=20"ambiguous"=20in=20the=20loose=20s= ense=20that=20one can=20image=20multiple=20ways=20for=20someone=20like=20the=20BBC=20to=20na= me=20their broadcasts=20under=20this=20scheme,=20and=20so=20the=20broadcaster=20needs= =20to=20pick=20one.=20 The=20tv:=20URIs=20are=20used=20today=20in=20the=20TV=20world,=20and=20I=20= believe=20are implemented=20by=20most=20TV-based=20browsers.=20By=20far=20the=20most=20c= ommon=20usecase however,=20is=20simply=20the=20unadorned=20"tv:",=20used=20to=20refer=20to= =20the=20current broadcast.=20When=20a=20browser=20wants=20to=20overlay=20graphics=20on=20t= he=20TV=20picture, for=20example,=20the=20background=20image=20is=20simply=20set=20to=20this=20= URI,=20and=20when the=20browser=20wants=20to=20include=20a=20resized=20TV=20picture=20in=20t= he=20corner,=20they insert=20an=20image=20pointing=20to=20"tv:"=20in=20the=20desired=20locatio= n.=20 I=20would=20be=20happy=20to=20work=20on=20a=20revision=20of=20RFC=202838if= =20one=20is=20desired.=20In my=20mind,=20the=20biggest=20problem=20is=20how=20to=20register=20identifi= ers=20under=20this scheme.=20But=20based=20on=20Oskar's=20comments,=20perhaps=20further=20cla= rifying=20the relationship=20(or=20lack=20of=20relationship)=20of=20these=20DNS-based=20= identifiers=20to actual=20HTTP=20sites=20would=20also=20be=20helpful.=20 =20=20=20=20=20Dan On=208/21/06,=20Keith=20Moore=20<=20moore@cs.utk.edu=20=20> wrote:=20 =09>=20I=20agree=20there=20is=20a=20need,=20for=20a=20good=20interface,=20= to=20expose=20some semantic =09>=20information=20about=20the=20resource=20without=20having=20to=20acce= ss=20it across=20the =09>=20net.=20=20I'm=20not=20sure=20that=20means=20the=20scheme=20is=20a=20= good=20place=20for this=20 =09>=20information=20though=20(and=20pretty=20clearly=20W3C=20TAG=20thinks= =20it's not). =09> =09>=20The=20Microformats=20mechanisms=20<=20microformats.org =20>=20= uses "class"=20attributes =09>=20on=20the=20"a"=20link=20element=20to=20indicate=20what=20kind=20of=20= an=20HTTP=20link is=20in=20the=20 =09>=20"href"=20attribute:=20a=20friend's=20blog=20location,=20the=20page=20= owner's calendar =09>=20location,=20etc.=20=20Of=20course,=20this=20approach=20works=20best= =20in=20Web pages,=20and =09>=20can=20work=20in=20email=20only=20if=20using=20rich=20email=20or=20u= gly=20URLs,=20and can=20be=20used=20 =09>=20in=20other=20media=20similarly. =09 =09I=20agree=20that=20there=20are=20limitations=20to=20what=20can=20or=20s= hould=20be exposed=20in=20a =09URI=20scheme=20name,=20though=20I=20don't=20think=20the=20example=20of=20= "tv:" stretches=20the =09bounds=20too=20much.=20 =09 =09I=20think=20it's=20a=20stretch=20to=20assume=20that=20URIs=20can=20gene= rally=20be associated =09with=20metadata=20that=20exposes=20semantic=20information=20about=20the= resource.=20=20For =09better=20or=20worse,=20a=20URI=20is=20a=20natural=20container,=20and=20= the=20URI=20is really=20the=20 =09only=20thing=20that=20approaches=20being=20a=20universal=20coin=20of=20= the=20web. There's =09not=20nearly=20the=20degree=20of=20acceptance=20for=20any=20kind=20of=20= metadata that=20there =09is=20for=20the=20URI,=20and=20I'd=20expect=20convergence=20on=20metadat= a=20(both schemas=20and=20 =09presentation=20layers)=20to=20occur=20much=20more=20slowly=20than=20con= vergence on =09resource=20identifiers. =09 =09I=20find=20myself=20disagreeing=20with=20many=20of=20TAG's=20recommenda= tions about=20URI =09use=20-=20basically=20I=20think=20they're=20being=20very=20unrealistic=20= and idealistic=20in=20 =09some=20areas=20while=20ignoring=20a=20number=20of=20practical=20conside= rations. I=20don't =09think=20IETF=20should=20constrain=20itself,=20or=20the=20URI=20registry= =20should be =09constrained=20by,=20the=20mere=20fact=20that=20TAG=20has=20made=20some=20= contrary =09recommendations.=20 =09 =09Keith =09 --=20 ------------------------ djz@google.com --=20 ------------------------ djz@google.com 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 Aug 22 12:19:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFYxR-0005TR-81; Tue, 22 Aug 2006 12:18:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFYxQ-0005TG-4L for discuss@apps.ietf.org; Tue, 22 Aug 2006 12:18:28 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFYxO-00055k-Sf for discuss@apps.ietf.org; Tue, 22 Aug 2006 12:18:28 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id A880356540; Tue, 22 Aug 2006 11:48:06 -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 Re+7LSpc3Qia; Tue, 22 Aug 2006 11:48:03 -0400 (EDT) Received: from [192.168.1.126] (adsl-150-230-59.tys.bellsouth.net [72.150.230.59]) by shu.cs.utk.edu (Postfix) with ESMTP id D897D56544; Tue, 22 Aug 2006 11:48:02 -0400 (EDT) Message-ID: <44EB275D.3010000@cs.utk.edu> Date: Tue, 22 Aug 2006 11:48:45 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: "Deventer, M.O. \(Oskar\) van" Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A753@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56C2A753@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: 9182cfff02fae4f1b6e9349e01d62f32 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 >> broadcasters have not rushed to establish identifiers based on this >> scheme > This is the good thing about the RFC 2838 tv: URI. It allows me to > create internet-based services that point to TV channels without being > dependent on the collaboration of broadcasters. Many use cases (see > previous posts in this thread) would not need such collaboration, but > only an unambiguous identification of TV channels. I'm not sure it's entirely a good thing to have a scheme that encourages creation of identifiers for broadcasters without their participation. If nothing else, it seems like it would be difficult to keep the URI-to-broadcaster mappings up to date (say when they change their domain names, or call letters - maybe because a station is sold to a new owner or wishes to change its target market) without the cooperation of the broadcasters. I like the idea of using domain names in tv: URIs, but broadcasters should be allowed/encouraged to use DNS to associate information about their channels with the TV URI. I dislike the idea of using web page addresses as tv: URIs for reasons mentioned earlier, but also because web page addresses (including both the domain and a path) change more frequently than domain names, as web sites get reorganized. Keith From discuss-bounces@apps.ietf.org Tue Aug 22 12:39:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZHC-0004C0-KD; Tue, 22 Aug 2006 12:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFDIs-0004B8-SB for discuss@apps.ietf.org; Mon, 21 Aug 2006 13:11:10 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFD9p-0007A0-91 for discuss@apps.ietf.org; Mon, 21 Aug 2006 13:01:53 -0400 Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id k7LH1aN6013115 for ; Mon, 21 Aug 2006 10:01:36 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:in-reply-to: mime-version:content-type:references; b=xUP91k4aNrVioQttrFtX27pEoXoCgI2zk6hDfA0nlS2iKo7euQlrd2Vtcu8xMW4Z6 l2dpmGj6AdDqIGEHO5IDw== Received: from smtp-out2.google.com (fpr16.prod.google.com [10.253.18.16]) by zps77.corp.google.com with ESMTP id k7LFiFdg027940 for ; Mon, 21 Aug 2006 10:01:27 -0700 Received: by smtp-out2.google.com with SMTP id 16so36446fpr for ; Mon, 21 Aug 2006 10:01:26 -0700 (PDT) Received: by 10.253.14.20 with SMTP id 20mr191656fpn; Mon, 21 Aug 2006 10:01:26 -0700 (PDT) Received: by 10.253.2.8 with HTTP; Mon, 21 Aug 2006 10:01:26 -0700 (PDT) Message-ID: <8526f7580608211001p75b77c49p98f76f4ee4ed2a3@mail.google.com> Date: Mon, 21 Aug 2006 10:01:26 -0700 From: "Dan Zigmond" To: "Keith Moore" , "Lisa Dusseault" , "Tim Bray" , discuss@apps.ietf.org, "Eliot Lear" , "Keesmaat, N.W. (Iko)" Subject: Re: Update of RFC 2838, tv: URI In-Reply-To: <44E9DA72.9050807@cs.utk.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9348_20192844.1156179686738" References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> <52FC1A76-419A-4E06-9C7B-646F4925CE91@osafoundation.org> <44E8CD36.5020800@cs.utk.edu> <33C674FE-1075-4911-A0D2-A3C690C672FE@osafoundation.org> <44E9DA72.9050807@cs.utk.edu> X-Spam-Score: -4.0 (----) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 X-Mailman-Approved-At: Tue, 22 Aug 2006 12:38:53 -0400 Cc: 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 ------=_Part_9348_20192844.1156179686738 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, all. I'm responding to the thread as a whole here, rather than the specific comments about microformats and TAG. I was the original author of RFC of RFC 2838 and so can give some background on the thinking behind it and how ti evolved in the process of RFC publication. (I vaguely remember that Keith was involved at the time, but Microsoft did not allow me to keep my emails from that period when I left, so I can't be sure.) The original tv: Internet-Draft (circa 1996) used a much simpler syntax: tv:nbc, tv:cnn, tv:bbc1, etc. Of course, this required some sort of registry, so we envisioned that IANA would allow TV networks to reserve identifiers for their channels, and even started writing up an initial list of reserved identifiers for the major US networks and a few international ones. Unfortunately, we ran into name collisions almost immediately: ABC signifies a very different TV broadcaster to US audiences than to Australian ones. So we started thinking about how to resolve such conflicts, and perhaps some way of qualifying these identifiers by geography, and so forth. It was my co-author, Mark Vickers, who then suggested that this seemed like a duplication of effort: the domain name system already provided all these mechanisms, and most TV broadcasters already had a domain name. So we changed the draft to mandate that identifiers include an assigned domain name, and the above examples became something like tv:nbc.com, tv:cnn.com, and tv:one.bbc.co.uk. As someone else already pointed out on this thread, these were not intended to be actual hostnames. Instead, we were trying to design something closer to the Java package naming system, overloading domain names to ensure the uniqueness of an unrelated set of identifiers. I'm not sure I agree that this approach runs into any particular problems in Europe. The issue, rather, is that broadcasters have not rushed to establish identifiers based on this scheme. So, for example, the BCC has not published a format for referring to their distinct broadcasts using this scheme; neither has NED1 in the Netherlands. Furthermore, there isn't a clear mechanism for publicizing such a decisions one a broadcast has made it; if BBC decided tomorrow to use the form tv:bbc1.bbc.co.uk, it's not clear how anyone would know. We explicitly left everything beyond the usual hostname part of the URI undefined in this draft. Our assumption was that eventually people would want to use the other path components to refer to specific shows or segments of broadcasts (perhaps tv:bb1.bbc.co.uk/news or something like that). As far as I know, no one is doing this, but it still seems a possibility for the future. As Oskar points out indirectly, the identifiers are "ambiguous" in the loose sense that one can image multiple ways for someone like the BBC to name their broadcasts under this scheme, and so the broadcaster needs to pick one. The tv: URIs are used today in the TV world, and I believe are implemented by most TV-based browsers. By far the most common usecase however, is simply the unadorned "tv:", used to refer to the current broadcast. When a browser wants to overlay graphics on the TV picture, for example, the background image is simply set to this URI, and when the browser wants to include a resized TV picture in the corner, they insert an image pointing to "tv:" in the desired location. I would be happy to work on a revision of RFC 2838if one is desired. In my mind, the biggest problem is how to register identifiers under this scheme. But based on Oskar's comments, perhaps further clarifying the relationship (or lack of relationship) of these DNS-based identifiers to actual HTTP sites would also be helpful. Dan On 8/21/06, Keith Moore wrote: > > > I agree there is a need, for a good interface, to expose some semantic > > information about the resource without having to access it across the > > net. I'm not sure that means the scheme is a good place for this > > information though (and pretty clearly W3C TAG thinks it's not). > > > > The Microformats mechanisms uses "class" attributes > > on the "a" link element to indicate what kind of an HTTP link is in the > > "href" attribute: a friend's blog location, the page owner's calendar > > location, etc. Of course, this approach works best in Web pages, and > > can work in email only if using rich email or ugly URLs, and can be used > > in other media similarly. > > I agree that there are limitations to what can or should be exposed in a > URI scheme name, though I don't think the example of "tv:" stretches the > bounds too much. > > I think it's a stretch to assume that URIs can generally be associated > with metadata that exposes semantic information about the resource. For > better or worse, a URI is a natural container, and the URI is really the > only thing that approaches being a universal coin of the web. There's > not nearly the degree of acceptance for any kind of metadata that there > is for the URI, and I'd expect convergence on metadata (both schemas and > presentation layers) to occur much more slowly than convergence on > resource identifiers. > > I find myself disagreeing with many of TAG's recommendations about URI > use - basically I think they're being very unrealistic and idealistic in > some areas while ignoring a number of practical considerations. I don't > think IETF should constrain itself, or the URI registry should be > constrained by, the mere fact that TAG has made some contrary > recommendations. > > Keith > -- ------------------------ djz@google.com ------=_Part_9348_20192844.1156179686738 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, all. I'm responding to the thread as a whole here, rather than the specific comments about microformats and TAG. I was the original author of RFC of RFC 2838 and so can give some background on the thinking behind it and how ti evolved in the process of RFC publication. (I vaguely remember that Keith was involved at the time, but Microsoft did not allow me to keep my emails from that period when I left, so I can't be sure.)

The original tv: Internet-Draft (circa 1996) used a much simpler syntax: tv:nbc, tv:cnn, tv:bbc1, etc. Of course, this required some sort of registry, so we envisioned that IANA would allow TV networks to reserve identifiers for their channels, and even started writing up an initial list of reserved identifiers for the major US networks and a few international ones.

Unfortunately, we ran into name collisions almost immediately: ABC signifies a very different TV broadcaster to US audiences than to Australian ones. So we started thinking about how to resolve such conflicts, and perhaps some way of qualifying these identifiers by geography, and so forth. It was my co-author, Mark Vickers, who then suggested that this seemed like a duplication of effort: the domain name system already provided all these mechanisms, and most TV broadcasters already had a domain name. So we changed the draft to mandate that identifiers include an assigned domain name, and the above examples became something like tv: nbc.com, tv:cnn.com, and tv:one.bbc.co.uk.

As someone else already pointed out on this thread, these were not intended to be actual hostnames. Instead, we were trying to design something closer to the Java package naming system, overloading domain names to ensure the uniqueness of an unrelated set of identifiers.

I'm not sure I agree that this approach runs into any particular problems in Europe. The issue, rather, is that broadcasters have not rushed to establish identifiers based on this scheme. So, for example, the BCC has not published a format for referring to their distinct broadcasts using this scheme; neither has NED1 in the Netherlands. Furthermore, there isn't a clear mechanism for publicizing such a decisions one a broadcast has made it; if BBC decided tomorrow to use the form tv: bbc1.bbc.co.uk, it's not clear how anyone would know.

We explicitly left everything beyond the usual hostname part of the URI undefined in this draft. Our assumption was that eventually people would want to use the other path components to refer to specific shows or segments of broadcasts (perhaps tv: bb1.bbc.co.uk/news or something like that). As far as I know, no one is doing this, but it still seems a possibility for the future. As Oskar points out indirectly, the identifiers are "ambiguous" in the loose sense that one can image multiple ways for someone like the BBC to name their broadcasts under this scheme, and so the broadcaster needs to pick one.

The tv: URIs are used today in the TV world, and I believe are implemented by most TV-based browsers. By far the most common usecase however, is simply the unadorned "tv:", used to refer to the current broadcast. When a browser wants to overlay graphics on the TV picture, for example, the background image is simply set to this URI, and when the browser wants to include a resized TV picture in the corner, they insert an image pointing to "tv:" in the desired location.

I would be happy to work on a revision of RFC 2838if one is desired. In my mind, the biggest problem is how to register identifiers under this scheme. But based on Oskar's comments, perhaps further clarifying the relationship (or lack of relationship) of these DNS-based identifiers to actual HTTP sites would also be helpful.

     Dan


On 8/21/06, Keith Moore <moore@cs.utk.edu> wrote:
> I agree there is a need, for a good interface, to expose some semantic
> information about the resource without having to access it across the
> net.  I'm not sure that means the scheme is a good place for this
> information though (and pretty clearly W3C TAG thinks it's not).
>
> The Microformats mechanisms <microformats.org> uses "class" attributes
> on the "a" link element to indicate what kind of an HTTP link is in the
> "href" attribute: a friend's blog location, the page owner's calendar
> location, etc.  Of course, this approach works best in Web pages, and
> can work in email only if using rich email or ugly URLs, and can be used
> in other media similarly.

I agree that there are limitations to what can or should be exposed in a
URI scheme name, though I don't think the example of "tv:" stretches the
bounds too much.

I think it's a stretch to assume that URIs can generally be associated
with metadata that exposes semantic information about the resource.  For
better or worse, a URI is a natural container, and the URI is really the
only thing that approaches being a universal coin of the web.  There's
not nearly the degree of acceptance for any kind of metadata that there
is for the URI, and I'd expect convergence on metadata (both schemas and
presentation layers) to occur much more slowly than convergence on
resource identifiers.

I find myself disagreeing with many of TAG's recommendations about URI
use - basically I think they're being very unrealistic and idealistic in
some areas while ignoring a number of practical considerations.  I don't
think IETF should constrain itself, or the URI registry should be
constrained by, the mere fact that TAG has made some contrary
recommendations.

Keith



--

------------------------
djz@google.com
------=_Part_9348_20192844.1156179686738-- From discuss-bounces@apps.ietf.org Tue Aug 22 12:41:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZIh-00051C-1P; Tue, 22 Aug 2006 12:40:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZIg-000516-3F for discuss@apps.ietf.org; Tue, 22 Aug 2006 12:40:26 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFZId-0008Ea-5v for discuss@apps.ietf.org; Tue, 22 Aug 2006 12:40:26 -0400 Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id k7MGeFl6023732 for ; Tue, 22 Aug 2006 09:40:15 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=SAkKI+msiyo2NsOGH++YFYMR4h7MTMK8RPR6k6349UYPhTmIAgS4Fo3xyTqp0ZpTM gNwJog1yGvzwac+yiRcLw== Received: from smtp-out2.google.com (fpr16.prod.google.com [10.253.18.16]) by zps35.corp.google.com with ESMTP id k7MDNBRN017555 for ; Tue, 22 Aug 2006 09:40:11 -0700 Received: by smtp-out2.google.com with SMTP id 16so17280fpr for ; Tue, 22 Aug 2006 09:40:11 -0700 (PDT) Received: by 10.253.29.11 with SMTP id c11mr113601fpc; Tue, 22 Aug 2006 09:40:11 -0700 (PDT) Received: by 10.253.2.8 with HTTP; Tue, 22 Aug 2006 09:40:11 -0700 (PDT) Message-ID: <8526f7580608220940m1cdd0478u5f7dbbd0d9d2d124@mail.google.com> Date: Tue, 22 Aug 2006 09:40:11 -0700 From: "Dan Zigmond" To: "Keith Moore" , "Deventer, M.O. (Oskar) van" Subject: Re: Update of RFC 2838, tv: URI In-Reply-To: <44EB275D.3010000@cs.utk.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16032_28763583.1156264811317" References: <42F3BE57026C6E49B09E267EEF639D56C2A753@ms-dt01thalia.tsn.tno.nl> <44EB275D.3010000@cs.utk.edu> X-Spam-Score: -4.0 (----) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: discuss@apps.ietf.org, "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 ------=_Part_16032_28763583.1156264811317 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think I agree with Keith here. But first, I would like to emphasize that there is no essentially "European" issue with RFC 2838. Rather, the issue is that one cannot unambiguously deduce the correct tv: URL for a given broadcaster without additional information. But this is a very loose sort of ambiguity, and it exists everywhere on the Internet. You cannot deduce my email address unless I tell you; based on my name and employer, it could easily be djz@mail.google.com, for example, or dan.zigmond@google.com, or any of a very large number of plausible things. The basic standards simply allow me to pick one, but do not mandate which one I choose or how I tell you my choice. Similarly, you can't deduce an HTTP URI from a domain name either. Google is free to support, say, http://www.google.com, http://google.com, or http://foo.google.com (or any combination). Unless someone tells your which one is in use, you can't accurately guess. The situation with tv: is the same. Second, I don't see how supporting path components like tv:bbc.co.uk/bbconewould solve the basic problem. You would still have many potential ambiguities. As Oskar notes, there can be multiple web sites for a given broadcast. But how do you know that the various sites refer to the same underlying TV signal? You could use HTTP to detect redirects (assuming all devices supporting tv: also support HTTP, which is doubtful), but this can't be guaranteed to be a reliable indicator. Perhaps the two different sites don't redirect, or use slightly different content for some reason. Perhaps for a week, both http://bbc.co.uk/bbcone and hhtp://bbc.co.uk/bbctwo redirect to the same "Under Construction" page. Should the corresponding tv: URIs be treated as equivalent during that week? And as Keith notes, web sites changes fairly frequently, while new TV broadcasts are introduced very rarely these days. In some cases, the opposite problem will exist, too. In the US, for example, both HBO East and HBO West share the same web pages, because they are the "same" channel, but with the West version delayed three hours. Yet my TV receives both, and I need to be clear about which one to tune to if I want to watch a given program since at any given moment they are almost guaranteed to show distinct content. In summary, I agree that a problem exists with RFC 2838: there is no universal way for everyone to agree on which tv: URIs refer to which TV broadcasts. But I don't think the proposed change solves this problem. The only solution I can think of is a central registry to which broadcasters would be encouraged to submit unique tv: identifiers for their broadcasts. Dan On 8/22/06, Keith Moore wrote: > > >> broadcasters have not rushed to establish identifiers based on this > >> scheme > > This is the good thing about the RFC 2838 tv: URI. It allows me to > > create internet-based services that point to TV channels without being > > dependent on the collaboration of broadcasters. Many use cases (see > > previous posts in this thread) would not need such collaboration, but > > only an unambiguous identification of TV channels. > > I'm not sure it's entirely a good thing to have a scheme that encourages > creation of identifiers for broadcasters without their participation. > If nothing else, it seems like it would be difficult to keep the > URI-to-broadcaster mappings up to date (say when they change their > domain names, or call letters - maybe because a station is sold to a new > owner or wishes to change its target market) without the cooperation of > the broadcasters. > > I like the idea of using domain names in tv: URIs, but broadcasters > should be allowed/encouraged to use DNS to associate information about > their channels with the TV URI. I dislike the idea of using web page > addresses as tv: URIs for reasons mentioned earlier, but also because > web page addresses (including both the domain and a path) change more > frequently than domain names, as web sites get reorganized. > > Keith > > -- ------------------------ djz@google.com ------=_Part_16032_28763583.1156264811317 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think I agree with Keith here. But first, I would like to emphasize that there is no essentially "European" issue with RFC 2838. Rather, the issue is that one cannot unambiguously deduce the correct tv: URL for a given broadcaster without additional information.

But this is a very loose sort of ambiguity, and it exists everywhere on the Internet. You cannot deduce my email address unless I tell you; based on my name and employer, it could easily be djz@mail.google.com, for example, or dan.zigmond@google.com, or any of a very large number of plausible things. The basic standards simply allow me to pick one, but do not mandate which one I choose or how I tell you my choice. Similarly, you can't deduce an HTTP URI from a  domain name either. Google is free to support, say, http://www.google.com, http://google.com, or http://foo.google.com (or any combination). Unless someone tells your which one is in use, you can't accurately guess. The situation with tv: is the same.

Second, I don't see how supporting path components like tv:bbc.co.uk/bbcone would solve the basic problem. You would still have many potential ambiguities. As Oskar notes, there can be multiple web sites for a given broadcast. But how do you know that the various sites refer to the same underlying TV signal? You could use HTTP to detect redirects (assuming all devices supporting tv: also support HTTP, which is doubtful), but this can't be guaranteed to be a reliable indicator. Perhaps the two different sites don't redirect, or use slightly different content for some reason. Perhaps for a week, both http://bbc.co.uk/bbcone and hhtp://bbc.co.uk/bbctwo redirect to the same "Under Construction" page. Should the corresponding tv: URIs be treated as equivalent during that week? And as Keith notes, web sites changes fairly frequently, while new TV broadcasts are introduced very rarely these days.

In some cases, the opposite problem will exist, too. In the US, for example, both HBO East and HBO West share the same web pages, because they are the "same" channel, but with the West version delayed three hours. Yet my TV receives both, and I need to be clear about which one to tune to if I want to watch a given program since at any given moment they are almost guaranteed to show distinct content.

In summary, I agree that a problem exists with RFC 2838: there is no universal way for everyone to agree on which tv: URIs refer to which TV broadcasts. But I don't think the proposed change solves this problem. The only solution I can think of is a central registry to which broadcasters would be encouraged to submit unique tv: identifiers for their broadcasts.

     Dan


On 8/22/06, Keith Moore <moore@cs.utk.edu> wrote:
>> broadcasters have not rushed to establish identifiers based on this
>> scheme
> This is the good thing about the RFC 2838 tv: URI. It allows me to
> create internet-based services that point to TV channels without being
> dependent on the collaboration of broadcasters. Many use cases (see
> previous posts in this thread) would not need such collaboration, but
> only an unambiguous identification of TV channels.

I'm not sure it's entirely a good thing to have a scheme that encourages
creation of identifiers for broadcasters without their participation.
If nothing else, it seems like it would be difficult to keep the
URI-to-broadcaster mappings up to date (say when they change their
domain names, or call letters - maybe because a station is sold to a new
owner or wishes to change its target market) without the cooperation of
the broadcasters.

I like the idea of using domain names in tv: URIs, but broadcasters
should be allowed/encouraged to use DNS to associate information about
their channels with the TV URI.  I dislike the idea of using web page
addresses as tv: URIs for reasons mentioned earlier, but also because
web page addresses (including both the domain and a path) change more
frequently than domain names, as web sites get reorganized.

Keith




--

------------------------
djz@google.com
------=_Part_16032_28763583.1156264811317-- From discuss-bounces@apps.ietf.org Wed Aug 23 09:03:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsNY-0002vw-Ic; Wed, 23 Aug 2006 09:02:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsNW-0002v2-NZ for discuss@apps.ietf.org; Wed, 23 Aug 2006 09:02:42 -0400 Received: from mail93.messagelabs.com ([194.106.220.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFsNQ-0007an-LH for discuss@apps.ietf.org; Wed, 23 Aug 2006 09:02:42 -0400 X-VirusChecked: Checked X-Env-Sender: oskar.vandeventer@tno.nl X-Msg-Ref: server-14.tower-93.messagelabs.com!1156338153!1329882!1 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 476 invoked from network); 23 Aug 2006 13:02:33 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-14.tower-93.messagelabs.com with SMTP; 23 Aug 2006 13:02:33 -0000 Received: from ms-dt01vs01.tsn.tno.nl (cl-dt01pollux.tno.nl [134.221.225.8]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id k7ND2WB18273; Wed, 23 Aug 2006 15:02:32 +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, 23 Aug 2006 15:02:31 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C6B4.82C9E440" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Update of RFC 2838, tv: URI Date: Wed, 23 Aug 2006 15:03:21 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56C2A75D@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of RFC 2838, tv: URI Thread-Index: AcbGCct5beO57rL/Q7e26lUAZKHNEQAqizeA From: "Deventer, M.O. \(Oskar\) van" To: X-OriginalArrivalTime: 23 Aug 2006 13:02:31.0588 (UTC) FILETIME=[64E68640:01C6C6B4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7ddf3da2e36bf1816c08a54f16fcec30 Cc: "Moore, Keith" , "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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C6B4.82C9E440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I=20think=20Dan=20is=20absolutely=20right=20that=20there=20will=20always=20= remain ambiguities,=20as=20long=20as=20there=20is=20no=20central=20registry=20for= =20the identification=20of=20TV=20channels.=20I=20do=20not=20think=20anyone=20is=20= proposing=20to create=20such=20a=20registry,=20am=20I=20right?=20So,=20our=20task=20is=20= to=20provide guidelines=20to=20make=20the=20identification=20as=20unambiguous=20as=20po= ssible,=20and guidelines=20how=20to=20handle=20possible=20ambiguities=20(aliases/synonym= s). =20 Let's=20take=20a=20look=20at=20the=20HBO=20channels=20for=20example.=20I=20= checked=20their website.=20They=20have=20lots=20of=20channels,=20each=20with=20its=20own=20= website. -hbo.com/hbo2 -hbo.com/hbosignature -hbofamily.com -hbo.com/comedyplex -hbo.com/zone -hbolatino.com -etcetera. What=20would=20be=20proper=20RFC=202838=20identification(s)=20for=20these=20= TV=20channels? Would=20it=20help=20if=20we=20provide=20(lots=20of)=20additional=20example= s=20that=20help people=20deduce/derive=20these=20tv:=20URI's?=20Would=20it=20help=20when=20= we=20suggest=20to people=20how=20they=20could=20use=20the=20website=20name=20as=20inspiratio= n=20to deduce/derive=20the=20tv:=20URI? =20 I=20think=20that=20we=20should=20also=20provide=20guidelines=20on=20handli= ng synonyms/aliases.=20Let's=20take=20the=20HBO=20Family=20channel=20as=20exa= mple.=20Viable RFC=202838=20identifications=20for=20this=20TV=20channel=20would=20be=20e.= g. -tv:hbofamily.com -tv:hbofamily.hbo.com -tv:familiy.hbo.com If=20my=20application=20knows=20only=20the=20first=20two=20and=20your=20ap= plication=20knows only=20the=20latter=20two,=20there=20can=20still=20be=20interoperability.=20= I=20my=20presence application=20publishes=20"Oskar=20is=20now=20watching=20tv:hbofamily.com=20= AKA tv:hbofamily.hbo.com",=20then=20your=20application=20recognizes=20the=20se= cond synonym=20and=20makes=20the=20match.=20So=20you=20see=20that=20I=20am=20wa= tching=20the=20HBO Family=20channel.=20And=20if=20you=20click=20on=20the=20channel=20identifi= cation,=20your=20TV may=20automatically=20zap=20to=20the=20that=20channel,=20if=20that=20is=20= what=20your application=20is=20programmed=20to=20do. =20 Do=20you=20think=20that=20such=20guidelines=20on=20tv:=20URI=20derivation/= deduction=20and synonym/alias=20handling=20would=20be=20useful? =20 Best=20regards, =20 Oskar ________________________________ From:=20Dan=20Zigmond=20[mailto:djz@google.com]=20 Sent:=20dinsdag=2022=20augustus=202006=2018:40 To:=20Keith=20Moore;=20Deventer,=20M.O.=20(Oskar)=20van Cc:=20discuss@apps.ietf.org;=20Keesmaat,=20N.W.=20(Iko) Subject:=20Re:=20Update=20of=20RFC=202838,=20tv:=20URI I=20think=20I=20agree=20with=20Keith=20here.=20But=20first,=20I=20would=20= like=20to=20emphasize that=20there=20is=20no=20essentially=20"European"=20issue=20with=20RFC=202= 838.=20Rather,=20the issue=20is=20that=20one=20cannot=20unambiguously=20deduce=20the=20correct=20= tv:=20URL=20for=20a given=20broadcaster=20without=20additional=20information.=20 But=20this=20is=20a=20very=20loose=20sort=20of=20ambiguity,=20and=20it=20e= xists=20everywhere=20on the=20Internet.=20You=20cannot=20deduce=20my=20email=20address=20unless=20= I=20tell=20you; based=20on=20my=20name=20and=20employer,=20it=20could=20easily=20be=20djz@= mail.google.com, for=20example,=20or=20dan.zigmond@google.com,=20or=20any=20of=20a=20very=20= large=20number=20of plausible=20things.=20The=20basic=20standards=20simply=20allow=20me=20to=20= pick=20one,=20but do=20not=20mandate=20which=20one=20I=20choose=20or=20how=20I=20tell=20you=20= my=20choice. Similarly,=20you=20can't=20deduce=20an=20HTTP=20URI=20from=20a=20=20domain= =20name=20either. Google=20is=20free=20to=20support,=20say,=20http://www.google.com, http://google.com,=20or=20http://foo.google.com=20(or=20any=20combination)= .=20Unless someone=20tells=20your=20which=20one=20is=20in=20use,=20you=20can't=20accu= rately=20guess.=20The situation=20with=20tv:=20is=20the=20same.=20 Second,=20I=20don't=20see=20how=20supporting=20path=20components=20like tv:bbc.co.uk/bbcone=20would=20solve=20the=20basic=20problem.=20You=20would= =20still=20have many=20potential=20ambiguities.=20As=20Oskar=20notes,=20there=20can=20be=20= multiple=20web sites=20for=20a=20given=20broadcast.=20But=20how=20do=20you=20know=20that=20= the=20various=20sites refer=20to=20the=20same=20underlying=20TV=20signal?=20You=20could=20use=20= HTTP=20to=20detect redirects=20(assuming=20all=20devices=20supporting=20tv:=20also=20support=20= HTTP,=20which is=20doubtful),=20but=20this=20can't=20be=20guaranteed=20to=20be=20a=20rel= iable=20indicator. Perhaps=20the=20two=20different=20sites=20don't=20redirect,=20or=20use=20s= lightly different=20content=20for=20some=20reason.=20Perhaps=20for=20a=20week,=20b= oth http://bbc.co.uk/bbcone=20and=20hhtp://bbc.co.uk/bbctwo=20redirect=20to=20= the=20same "Under=20Construction"=20page.=20Should=20the=20corresponding=20tv:=20URIs= =20be=20treated as=20equivalent=20during=20that=20week?=20And=20as=20Keith=20notes,=20web=20= sites=20changes fairly=20frequently,=20while=20new=20TV=20broadcasts=20are=20introduced=20= very=20rarely these=20days.=20 In=20some=20cases,=20the=20opposite=20problem=20will=20exist,=20too.=20In=20= the=20US,=20for example,=20both=20HBO=20East=20and=20HBO=20West=20share=20the=20same=20web= =20pages,=20because they=20are=20the=20"same"=20channel,=20but=20with=20the=20West=20version=20= delayed=20three hours.=20Yet=20my=20TV=20receives=20both,=20and=20I=20need=20to=20be=20cle= ar=20about=20which=20one to=20tune=20to=20if=20I=20want=20to=20watch=20a=20given=20program=20since=20= at=20any=20given=20moment they=20are=20almost=20guaranteed=20to=20show=20distinct=20content.=20 In=20summary,=20I=20agree=20that=20a=20problem=20exists=20with=20RFC=20283= 8:=20there=20is=20no universal=20way=20for=20everyone=20to=20agree=20on=20which=20tv:=20URIs=20= refer=20to=20which=20TV broadcasts.=20But=20I=20don't=20think=20the=20proposed=20change=20solves=20= this=20problem. The=20only=20solution=20I=20can=20think=20of=20is=20a=20central=20registry= =20to=20which broadcasters=20would=20be=20encouraged=20to=20submit=20unique=20tv:=20iden= tifiers=20for their=20broadcasts.=20 =20=20=20=20=20Dan On=208/22/06,=20Keith=20Moore=20=20wrote:=20 =09>>=20broadcasters=20have=20not=20rushed=20to=20establish=20identifiers=20= based on=20this =09>>=20scheme =09>=20This=20is=20the=20good=20thing=20about=20the=20RFC=202838=20tv:=20U= RI.=20It=20allows me=20to =09>=20create=20internet-based=20services=20that=20point=20to=20TV=20chann= els without=20being=20 =09>=20dependent=20on=20the=20collaboration=20of=20broadcasters.=20Many=20= use=20cases (see =09>=20previous=20posts=20in=20this=20thread)=20would=20not=20need=20such collaboration,=20but =09>=20only=20an=20unambiguous=20identification=20of=20TV=20channels. =09 =09I'm=20not=20sure=20it's=20entirely=20a=20good=20thing=20to=20have=20a=20= scheme=20that encourages =09creation=20of=20identifiers=20for=20broadcasters=20without=20their participation. =09If=20nothing=20else,=20it=20seems=20like=20it=20would=20be=20difficult=20= to=20keep=20the =09URI-to-broadcaster=20mappings=20up=20to=20date=20(say=20when=20they=20c= hange their=20 =09domain=20names,=20or=20call=20letters=20-=20maybe=20because=20a=20stati= on=20is=20sold to=20a=20new =09owner=20or=20wishes=20to=20change=20its=20target=20market)=20without=20= the cooperation=20of =09the=20broadcasters. =09 =09I=20like=20the=20idea=20of=20using=20domain=20names=20in=20tv:=20URIs,=20= but broadcasters=20 =09should=20be=20allowed/encouraged=20to=20use=20DNS=20to=20associate=20in= formation about =09their=20channels=20with=20the=20TV=20URI.=20=20I=20dislike=20the=20idea= =20of=20using=20web page =09addresses=20as=20tv:=20URIs=20for=20reasons=20mentioned=20earlier,=20bu= t=20also because =09web=20page=20addresses=20(including=20both=20the=20domain=20and=20a=20p= ath)=20change more =09frequently=20than=20domain=20names,=20as=20web=20sites=20get=20reorgani= zed. =09 =09Keith =09 =09 --=20 ------------------------=20 djz@google.com This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html ------_=_NextPart_001_01C6C6B4.82C9E440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable = All,

  I=20think=20Dan=20is=20absolutely=20 right=20that=20there=20will=20always=20remain=20ambiguities,=20as=20long=20= as=20there=20is=20no=20central=20 registry=20for=20the=20identification=20of=20TV=20channels.=20I=20do=20not= =20think=20anyone=20is=20 proposing=20to=20create=20such=20a=20registry,=20am=20I=20right?=20So,=20o= ur=20task=20is=20to=20provide=20 guidelines=20to=20make=20the=20identification=20as=20unambiguous=20as=20po= ssible,=20and=20guidelines=20 how=20to=20handle=20possible=20ambiguities=20(aliases/synonyms).

 

Let’s=20take=20a=20look=20at=20the=20HBO=20channels=20for=20= example.=20I=20checked=20their=20 website.=20They=20have=20lots=20of=20channels,=20each=20with=20its=20own=20= website.

-hbo.com/hbo2

-hbo.com/hbosignature

-hbofamily.com

-hbo.com/comedyplex

-hbo.com/zone

-hbolatino.com

-etcetera.

What=20would=20be=20proper=20RFC=202838=20identification(s)=20for= =20these=20TV=20channels?=20 Would=20it=20help=20if=20we=20provide=20(lots=20of)=20additional=20example= s=20that=20help=20people=20 deduce/derive=20these=20tv:=20URI’s?=20Would=20it=20help=20when=20we= =20suggest=20to=20people=20how=20they=20 could=20use=20the=20website=20name=20as=20inspiration=20to=20deduce/derive= =20the=20tv:=20 URI?

 

I=20think=20that=20we=20should=20also=20provide=20guidelines=20on= =20handling=20 synonyms/aliases.=20Let’s=20take=20the=20HBO=20Family=20channel=20as= =20example.=20Viable=20RFC=202838=20 identifications=20for=20this=20TV=20channel=20would=20be=20e.g.=

-tv:hbofamily.com

-tv:hbofamily.hbo.com

-tv:familiy.hbo.com

If=20my=20application=20knows=20only=20the=20first=20two=20and=20= your=20application=20knows=20 only=20the=20latter=20two,=20there=20can=20still=20be=20interoperability.=20= I=20my=20presence=20 application=20publishes=20“Oskar=20is=20now=20watching=20tv:hbofamil= y.com=20AKA=20 tv:hbofamily.hbo.com”,=20then=20your=20application=20recognizes=20th= e=20second=20synonym=20and=20 makes=20the=20match.=20So=20you=20= see=20that=20I=20am=20 watching=20the=20HBO=20Family=20channel.=20And=20if=20you=20click=20on=20t= he=20channel=20identification,=20 your=20TV=20may=20automatically=20zap=20to=20the that=20channel,=20if=20that=20is=20what=20= your=20application=20 is=20programmed=20to=20do.

 

Do=20you=20think=20that=20such=20guidelines=20on=20tv:=20URI=20de= rivation/deduction=20and=20 synonym/alias=20handling=20would=20be=20useful?  

Best=20regards,

 

Oskar


From:=20Dan=20Zigmond=20[mailto:dj= z@google.com]=20
Sent:=20dinsdag=2022=20augustus=202006=2018:40
To:=20= Keith=20Moore;=20 Deventer,=20M.O.=20(Oskar)=20van
Cc:=20discuss@apps.ietf.org;=20= Keesmaat,=20N.W.=20 (Iko)
Subject:=20Re:=20Update=20of=20RFC=202838,=20tv:=20URI
=
I=20think=20I=20agree=20with=20Keith=20here.=20But=20first,=20I= =20would=20like=20to=20emphasize=20 that=20there=20is=20no=20essentially=20"European"=20issue=20with=20RFC=202= 838.=20Rather,=20the=20issue=20 is=20that=20one=20cannot=20unambiguously=20deduce=20the=20correct=20tv:=20= URL=20for=20a=20given=20 broadcaster=20without=20additional=20information.=20

But=20this=20i= s=20a=20very=20loose=20 sort=20of=20ambiguity,=20and=20it=20exists=20everywhere=20on=20the=20Inter= net.=20You=20cannot=20deduce=20 my=20email=20address=20unless=20I=20tell=20you;=20based=20on=20my=20name=20= and=20employer,=20it=20could=20 easily=20be=20djz@mail.google.com= ,=20for=20 example,=20or=20dan.zigmond@go= ogle.com,=20 or=20any=20of=20a=20very=20large=20number=20of=20plausible=20things.=20The= =20basic=20standards=20simply=20 allow=20me=20to=20pick=20one,=20but=20do=20not=20mandate=20which=20one=20I= =20choose=20or=20how=20I=20tell=20you=20my=20 choice.=20Similarly,=20you=20can't=20deduce=20an=20HTTP=20URI=20from=20a&n= bsp;=20domain=20name=20either.=20 Google=20is=20free=20to=20support,=20say,=20http://www.google.com,=20http://google.com,=20or=20http://foo.google.com=20(or=20any=20com= bination).=20 Unless=20someone=20tells=20your=20which=20one=20is=20in=20use,=20you=20can= 't=20accurately=20guess.=20The=20 situation=20with=20tv:=20is=20the=20same.=20

Second,=20I=20don't=20= see=20how=20supporting=20path=20 components=20like=20tv:bbc.co.uk/bbc= one=20would=20 solve=20the=20basic=20problem.=20You=20would=20still=20have=20many=20poten= tial=20ambiguities.=20As=20 Oskar=20notes,=20there=20can=20be=20multiple=20web=20sites=20for=20a=20giv= en=20broadcast.=20But=20how=20do=20 you=20know=20that=20the=20various=20sites=20refer=20to=20the=20same=20unde= rlying=20TV=20signal?=20You=20 could=20use=20HTTP=20to=20detect=20redirects=20(assuming=20all=20devices=20= supporting=20tv:=20also=20 support=20HTTP,=20which=20is=20doubtful),=20but=20this=20can't=20be=20guar= anteed=20to=20be=20a=20reliable=20 indicator.=20Perhaps=20the=20two=20different=20sites=20don't=20redirect,=20= or=20use=20slightly=20 different=20content=20for=20some=20reason.=20Perhaps=20for=20a=20week,=20b= oth=20http://bbc.co.uk/bbcone=20and=20 hhtp://bbc.co.uk/bbctwo=20redirect=20to=20the=20same=20"Under=20Constructi= on"=20page.=20Should=20 the=20corresponding=20tv:=20URIs=20be=20treated=20as=20equivalent=20during= =20that=20week?=20And=20as=20 Keith=20notes,=20web=20sites=20changes=20fairly=20frequently,=20while=20ne= w=20TV=20broadcasts=20are=20 introduced=20very=20rarely=20these=20days.=20

In=20some=20cases,=20= the=20opposite=20problem=20 will=20exist,=20too.=20In=20the=20US,=20for=20example,=20both=20HBO=20East= =20and=20HBO=20West=20share=20the=20 same=20web=20pages,=20because=20they=20are=20the=20"same"=20channel,=20but= =20with=20the=20West=20version=20 delayed=20three=20hours.=20Yet=20my=20TV=20receives=20both,=20and=20I=20ne= ed=20to=20be=20clear=20about=20which=20 one=20to=20tune=20to=20if=20I=20want=20to=20watch=20a=20given=20program=20= since=20at=20any=20given=20moment=20they=20 are=20almost=20guaranteed=20to=20show=20distinct=20content.=20

In=20= summary,=20I=20agree=20that=20 a=20problem=20exists=20with=20RFC=202838:=20there=20is=20no=20universal=20= way=20for=20everyone=20to=20agree=20 on=20which=20tv:=20URIs=20refer=20to=20which=20TV=20broadcasts.=20But=20I=20= don't=20think=20the=20proposed=20 change=20solves=20this=20problem.=20The=20only=20solution=20I=20can=20thin= k=20of=20is=20a=20central=20 registry=20to=20which=20broadcasters=20would=20be=20encouraged=20to=20subm= it=20unique=20tv:=20 identifiers=20for=20their=20broadcasts.=20

    = =20 Dan


On=208/22/06,=20Keith=20 Moore=20<moore@cs.utk.edu= >=20 wrote: >>=20 =20=20broadcasters=20have=20not=20rushed=20to=20establish=20identifiers=20= based=20on=20 =20=20this
>>=20scheme
>=20This=20is=20the=20good=20thing=20= about=20the=20RFC=202838=20tv:=20 =20=20URI.=20It=20allows=20me=20to
>=20create=20internet-based=20ser= vices=20that=20point=20to=20TV=20 =20=20channels=20without=20being=20
>=20dependent=20on=20the=20colla= boration=20of=20 =20=20broadcasters.=20Many=20use=20cases=20(see
>=20previous=20posts= =20in=20this=20thread)=20would=20 =20=20not=20need=20such=20collaboration,=20but
>=20only=20an=20unamb= iguous=20identification=20of=20 =20=20TV=20channels.

I'm=20not=20sure=20it's=20entirely=20a=20good=20= thing=20to=20have=20a=20scheme=20 =20=20that=20encourages
creation=20of=20identifiers=20for=20broadcaster= s=20without=20their=20 =20=20participation.
If=20nothing=20else,=20it=20seems=20like=20it=20wo= uld=20be=20difficult=20to=20keep=20 =20=20the
URI-to-broadcaster=20mappings=20up=20to=20date=20(say=20when=20= they=20change=20their=20 =20=20
domain=20names,=20or=20call=20letters=20-=20maybe=20because=20a=20= station=20is=20sold=20to=20a=20 =20=20new
owner=20or=20wishes=20to=20change=20its=20target=20market)=20= without=20the=20cooperation=20 =20=20of
the=20broadcasters.

I=20like=20the=20idea=20of=20using=20= domain=20names=20in=20tv:=20 =20=20URIs,=20but=20broadcasters=20
should=20be=20allowed/encouraged=20= to=20use=20DNS=20to=20 =20=20associate=20information=20about
their=20channels=20with=20the=20T= V=20URI.  I=20 =20=20dislike=20the=20idea=20of=20using=20web=20page
addresses=20as=20t= v:=20URIs=20for=20reasons=20 =20=20mentioned=20earlier,=20but=20also=20because
web=20page=20addresse= s=20(including=20both=20the=20 =20=20domain=20and=20a=20path)=20change=20more
frequently=20than=20doma= in=20names,=20as=20web=20sites=20 =20=20get=20reorganized.

Keith



--=20

------------------------=20
djz@google.com

This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html
------_=_NextPart_001_01C6C6B4.82C9E440-- From discuss-bounces@apps.ietf.org Wed Aug 23 09:50:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFt70-0005w8-Rr; Wed, 23 Aug 2006 09:49:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFt6z-0005mb-4u for discuss@apps.ietf.org; Wed, 23 Aug 2006 09:49:41 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFt6x-0006d8-St for discuss@apps.ietf.org; Wed, 23 Aug 2006 09:49:41 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 2B65BFCFF; Wed, 23 Aug 2006 09:48:23 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPt8BxfesLLg; Wed, 23 Aug 2006 09:48:20 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 88EBFFCF0; Wed, 23 Aug 2006 09:48:15 -0400 (EDT) Message-ID: <44EC5CE5.20508@cs.utk.edu> Date: Wed, 23 Aug 2006 09:49:25 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: "Deventer, M.O. \(Oskar\) van" Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A75D@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56C2A75D@ms-dt01thalia.tsn.tno.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 > I think Dan is absolutely right that there will always remain > ambiguities, as long as there is no central registry for the > identification of TV channels. I do not think anyone is proposing to > create such a registry, am I right? I don't think anyone has figured out how to solve the problem without creating a registry. So yes, I'm inclined to think that if tv: is to be viable, there needs to be a registry. Or maybe there should be two registries - a "video broadcast channel" registry and a "video content stream" registry. The video broadcast channel registry would try to define a hierarchy for uniquely naming all ways of broadcasting video (terrestrial radio, satellite, IPv4 multicast, etc.). The idea would be to make it obvious, for a particular kind of broadcast channel, where it fits in the hierarchy. The "video content stream" registry populated by content channel sources would consist of a list of domain names that were owned by those sources. There would then be a well-defined way for those domain owners to publish the mappings from those content streams to broadcast channels. This mapping should allow a single content stream to be associated with multiple content channels; it should also allow the content stream to be associated with a content channel only at certain times. This registry would serve two purposes - it would allow content streams to advertise information about their content and link it to tv: URLs; it would also serve to collect a list of all video content channels so that comprehensive information about such channels could be compiled without scanning every node in the DNS. Keith From discuss-bounces@apps.ietf.org Wed Aug 23 23:34:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG5yH-00082a-2D; Wed, 23 Aug 2006 23:33:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG5yG-00082N-BN for discuss@apps.ietf.org; Wed, 23 Aug 2006 23:33:32 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG5yC-0004ai-SU for discuss@apps.ietf.org; Wed, 23 Aug 2006 23:33:32 -0400 Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7O3XGYR020708 for ; Wed, 23 Aug 2006 21:33:22 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4H00701GESKO00@mail-amer.sun.com> (original mail from tbray@textuality.com) for discuss@apps.ietf.org; Wed, 23 Aug 2006 21:33:16 -0600 (MDT) Received: from [192.168.0.104] ([69.11.32.204]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4H00EEJGJFSL8P@mail-amer.sun.com>; Wed, 23 Aug 2006 21:33:16 -0600 (MDT) Date: Wed, 23 Aug 2006 20:33:14 -0700 From: Tim Bray Subject: Re: Update of RFC 2838, tv: URI In-reply-to: <44E8CD36.5020800@cs.utk.edu> To: Keith Moore Message-id: <96992436-8AFD-407E-997D-3FDB62A5C6DA@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> <52FC1A76-419A-4E06-9C7B-646F4925CE91@osafoundation.org> <44E8CD36.5020800@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , "Zigmond, Dan" , Eliot Lear 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 Aug 20, 2006, at 1:59 PM, Keith Moore wrote: > Personally I think W3C goes a bit overboard on this. Expecting > everything on the web to use HTTP just to get a description file or > a redirect is just wrong. And there are many cases where, for the > sake of a good user interface, you really want to expose some > semantic information about the resource without the client having > to access the net to get it. Um, the W3C dogma doesn't say much about retrieval. It just encourages using "http:" URIs to name things unless you have a good strong reason to use another scheme; and when you look closely at many of the alleged reasons, they tend to involve a lot of arm-waving. > There's nothing wrong with having a tv: URL, just don't cripple it > so that it can never be more functional than an http: URL. I think that if it's going to be used as a distributed persistent naming scheme, that's a good argument for using http: URIs. It is very unlikely that tv: URIs will ever be as remotely functional as http: URIs, which have software already widely deployed on essentially every desktop and server on the planet. If you want to have this argument, please read http:// norman.walsh.name/2006/07/25/namesAndAddresses first. -Tim [former W3C TAG member] From discuss-bounces@apps.ietf.org Wed Aug 23 23:37:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG616-0000zw-On; Wed, 23 Aug 2006 23:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG614-0000zo-Oi for discuss@apps.ietf.org; Wed, 23 Aug 2006 23:36:26 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG613-0004xQ-BQ for discuss@apps.ietf.org; Wed, 23 Aug 2006 23:36:26 -0400 Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7O3aO8g004776 for ; Wed, 23 Aug 2006 21:36:25 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4H00901GOA1J00@mail-amer.sun.com> (original mail from tbray@textuality.com) for discuss@apps.ietf.org; Wed, 23 Aug 2006 21:36:24 -0600 (MDT) Received: from [192.168.0.104] ([69.11.32.204]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4H00EGSGOKSL8P@mail-amer.sun.com>; Wed, 23 Aug 2006 21:36:24 -0600 (MDT) Date: Wed, 23 Aug 2006 20:36:19 -0700 From: Tim Bray Subject: Re: Update of RFC 2838, tv: URI In-reply-to: <33C674FE-1075-4911-A0D2-A3C690C672FE@osafoundation.org> To: Lisa Dusseault Message-id: <77641027-67A7-46EE-84F3-7672F10333EA@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> <52FC1A76-419A-4E06-9C7B-646F4925CE91@osafoundation.org> <44E8CD36.5020800@cs.utk.edu> <33C674FE-1075-4911-A0D2-A3C690C672FE@osafoundation.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , Keith Moore , "Zigmond, Dan" , Eliot Lear 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 Aug 21, 2006, at 8:27 AM, Lisa Dusseault wrote: > I agree there is a need, for a good interface, to expose some > semantic information about the resource without having to access it > across the net. I disagree. It is a design axiom of the Web that URIs are opaque, and that the only way to authoritatively find out anything about what a URI identifies is to dereference it (which, given the caching infrastructure, in many cases won't require going across the net). This is one of the reasons why the Web exhibits good scaling behavior. > I'm not sure that means the scheme is a good place for this > information though (and pretty clearly W3C TAG thinks it's not). If you want to keep link metadata around (nothing intrinsically wrong with that as long as you're willing to eat the management overhead and scaling barriers), the URI scheme is a really lousy place for it. -Tim [former W3C TAG member] From discuss-bounces@apps.ietf.org Thu Aug 24 02:36:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG8oc-0000CU-Mk; Thu, 24 Aug 2006 02:35:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG8oc-0000CP-3L for discuss@apps.ietf.org; Thu, 24 Aug 2006 02:35:46 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG8oa-0004L0-QV for discuss@apps.ietf.org; Thu, 24 Aug 2006 02:35:46 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id BD376564C6; Thu, 24 Aug 2006 02:34:56 -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 dFxl3O2Eu2SZ; Thu, 24 Aug 2006 02:34:53 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id B8D12564C4; Thu, 24 Aug 2006 02:34:48 -0400 (EDT) Message-ID: <44ED48B4.2010300@cs.utk.edu> Date: Thu, 24 Aug 2006 02:35:32 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Tim Bray Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> <52FC1A76-419A-4E06-9C7B-646F4925CE91@osafoundation.org> <44E8CD36.5020800@cs.utk.edu> <96992436-8AFD-407E-997D-3FDB62A5C6DA@textuality.com> In-Reply-To: <96992436-8AFD-407E-997D-3FDB62A5C6DA@textuality.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , "Zigmond, Dan" , Eliot Lear 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 >> Personally I think W3C goes a bit overboard on this. Expecting >> everything on the web to use HTTP just to get a description file or a >> redirect is just wrong. And there are many cases where, for the sake >> of a good user interface, you really want to expose some semantic >> information about the resource without the client having to access the >> net to get it. > > Um, the W3C dogma doesn't say much about retrieval. It just encourages > using "http:" URIs to name things unless you have a good strong reason > to use another scheme; and when you look closely at many of the alleged > reasons, they tend to involve a lot of arm-waving. I agree that the purported reasons for always using http: involve a lot of arm-waving. >> There's nothing wrong with having a tv: URL, just don't cripple it so >> that it can never be more functional than an http: URL. > > I think that if it's going to be used as a distributed persistent naming > scheme, that's a good argument for using http: URIs. It is very > unlikely that tv: URIs will ever be as remotely functional as http: > URIs, which have software already widely deployed on essentially every > desktop and server on the planet. if you insist on tv: being equivalent to (or dependent on) http: then it's very unlikely that it will ever be as remotely functional as http:. on the other hand if you don't impose the constraint that tv: should be tied to http:, then there's a potential for tv: URIs to do things that far exceed what can reasonably be done with http:. again, the widely deployed software tends to consist of web browsers and web servers which are optimized for certain kinds of user interfaces and use cases and pessimized for all others. I don't think URIs should be constrained to that set of optimizations and pessimizations. > If you want to have this argument, please read > http://norman.walsh.name/2006/07/25/namesAndAddresses first. thanks for the ref, I'll take a look. Keith From discuss-bounces@apps.ietf.org Thu Aug 24 02:39:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG8rQ-0001gl-66; Thu, 24 Aug 2006 02:38:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG8rO-0001a6-Dc for discuss@apps.ietf.org; Thu, 24 Aug 2006 02:38:38 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG8rN-0004ei-6v for discuss@apps.ietf.org; Thu, 24 Aug 2006 02:38:38 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 72E6C5646B; Thu, 24 Aug 2006 02:37:49 -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 OfGd29nbqlNR; Thu, 24 Aug 2006 02:37:46 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id F306D5647E; Thu, 24 Aug 2006 02:37:45 -0400 (EDT) Message-ID: <44ED4966.8080204@cs.utk.edu> Date: Thu, 24 Aug 2006 02:38:30 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Tim Bray Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> <52FC1A76-419A-4E06-9C7B-646F4925CE91@osafoundation.org> <44E8CD36.5020800@cs.utk.edu> <33C674FE-1075-4911-A0D2-A3C690C672FE@osafoundation.org> <77641027-67A7-46EE-84F3-7672F10333EA@textuality.com> In-Reply-To: <77641027-67A7-46EE-84F3-7672F10333EA@textuality.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , "Zigmond, Dan" , Eliot Lear 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 agree there is a need, for a good interface, to expose some semantic >> information about the resource without having to access it across the >> net. > > I disagree. It is a design axiom of the Web that URIs are opaque, the fact that this "axiom" is not followed in practice should give an indication that this "axiom" is a poor design choice. > If you want to keep link metadata around (nothing intrinsically wrong > with that as long as you're willing to eat the management overhead and > scaling barriers), the URI scheme is a really lousy place for it. mostly true, though pragmatically it works really well to convey a small number of bits of useful information. Keith From discuss-bounces@apps.ietf.org Thu Aug 24 11:56:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHXf-0006Fo-NA; Thu, 24 Aug 2006 11:54:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHXe-0006Fg-Cq for discuss@apps.ietf.org; Thu, 24 Aug 2006 11:54:50 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGHXd-0005Pl-4F for discuss@apps.ietf.org; Thu, 24 Aug 2006 11:54:50 -0400 Received: from [192.168.1.100] (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 A37BD14227F; Thu, 24 Aug 2006 08:54:43 -0700 (PDT) In-Reply-To: <77641027-67A7-46EE-84F3-7672F10333EA@textuality.com> References: <42F3BE57026C6E49B09E267EEF639D56C2A729@ms-dt01thalia.tsn.tno.nl> <44E842D6.5000402@cisco.com> <44E8544E.4020706@cs.utk.edu> <88CB5416-88D2-45FD-98B5-18F2458DE166@textuality.com> <52FC1A76-419A-4E06-9C7B-646F4925CE91@osafoundation.org> <44E8CD36.5020800@cs.utk.edu> <33C674FE-1075-4911-A0D2-A3C690C672FE@osafoundation.org> <77641027-67A7-46EE-84F3-7672F10333EA@textuality.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <48796A42-4FCC-4A0B-9609-1FE31F71055C@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Update of RFC 2838, tv: URI Date: Thu, 24 Aug 2006 08:54:39 -0700 To: Tim Bray X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: discuss@apps.ietf.org, "Keesmaat, N.W. \(Iko\)" , Keith Moore , "Zigmond, Dan" , Eliot Lear 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 Aug 23, 2006, at 8:36 PM, Tim Bray wrote: > On Aug 21, 2006, at 8:27 AM, Lisa Dusseault wrote: > >> I agree there is a need, for a good interface, to expose some >> semantic information about the resource without having to access >> it across the net. > > I disagree. It is a design axiom of the Web that URIs are opaque, > and that the only way to authoritatively find out anything about > what a URI identifies is to dereference it (which, given the > caching infrastructure, in many cases won't require going across > the net). This is one of the reasons why the Web exhibits good > scaling behavior. I didn't say that the URI shouldn't be opaque. I didn't say that this need was universal for every link (a solution shouldn't impose a cost when not wanted). I didn't suggest a mechanism that would degrade scaling. I still assert that in many use cases a good UI requires a bit of advertisement about the nature a linked resource that a user might want to retrieve. Lisa From discuss-bounces@apps.ietf.org Mon Aug 28 05:35:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHdVS-0007GR-NJ; Mon, 28 Aug 2006 05:34:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHdVR-0007GL-VN for discuss@apps.ietf.org; Mon, 28 Aug 2006 05:34:09 -0400 Received: from mail150.messagelabs.com ([85.158.136.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHdVK-00051w-Ga for discuss@apps.ietf.org; Mon, 28 Aug 2006 05:34:09 -0400 X-VirusChecked: Checked X-Env-Sender: oskar.vandeventer@tno.nl X-Msg-Ref: server-14.tower-150.messagelabs.com!1156757200!3066320!1 X-StarScan-Version: 5.5.10.7; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 21713 invoked from network); 28 Aug 2006 09:26:40 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-14.tower-150.messagelabs.com with SMTP; 28 Aug 2006 09:26:40 -0000 Received: from ms-dt01vs01.tsn.tno.nl (cl-dt01pollux.tno.nl [134.221.225.8]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id k7S8ftB03659; Mon, 28 Aug 2006 10:41:59 +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, 28 Aug 2006 10:41:54 +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: Update of RFC 2838, tv: URI Date: Mon, 28 Aug 2006 10:41:54 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56C2A78B@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of RFC 2838, tv: URI Thread-Index: AcbHlcoxwqrcFOStQE6A6ae/CetevwC5zgAw From: "Deventer, M.O. \(Oskar\) van" To: , "Dusseault, Lisa" X-OriginalArrivalTime: 28 Aug 2006 08:41:54.0727 (UTC) FILETIME=[D0ABA370:01C6CA7D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: "Lear, Eliot" , "Bray, Tim" , "Zigmond, Dan" , "Moore, Keith" , "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 Lisa,=20all, What=20I=20need=20is=20a=20solution 1)=20that=20identifies=20TV=20channels=20reasonably=20unambiguously, 2)=20that=20can=20handle=20synonyms=20when=20needed, 3)=20that=20does=20not=20require=20bilateral=20agreements,=20and 4)=20that=20does=20not=20require=20active=20participation=20of=20broadcast= ers. I=20think=20that=20RFC=202838=20satisfies=203)=20and=204),=20whereas=20sup= port=20of=202)=20could be=20included=20in=20the=20update=20and=201)=20could=20be=20improved=20by=20= providing=20further guidelines=20(like=20the=20tv:family.hbo.com=20case,=20see=20my=20earlier=20= email). What=20do=20you=20think? Best=20regards, Oskar -----Original=20Message----- From:=20Lisa=20Dusseault=20[mailto:lisa@osafoundation.org]=20 Sent:=20donderdag=2024=20augustus=202006=2017:55 To:=20Tim=20Bray Cc:=20discuss@apps.ietf.org;=20Keesmaat,=20N.W.=20(Iko);=20Keith=20Moore;=20= Zigmond, Dan;=20Eliot=20Lear Subject:=20Re:=20Update=20of=20RFC=202838,=20tv:=20URI On=20Aug=2023,=202006,=20at=208:36=20PM,=20Tim=20Bray=20wrote: >=20On=20Aug=2021,=202006,=20at=208:27=20AM,=20Lisa=20Dusseault=20wrote: > >>=20I=20agree=20there=20is=20a=20need,=20for=20a=20good=20interface,=20to= =20expose=20some=20=20 >>=20semantic=20information=20about=20the=20resource=20without=20having=20= to=20access=20=20 >>=20it=20across=20the=20net. > >=20I=20disagree.=20=20It=20is=20a=20design=20axiom=20of=20the=20Web=20tha= t=20URIs=20are=20opaque,=20=20 >=20and=20that=20the=20only=20way=20to=20authoritatively=20find=20out=20an= ything=20about=20=20 >=20what=20a=20URI=20identifies=20is=20to=20dereference=20it=20(which,=20g= iven=20the=20=20 >=20caching=20infrastructure,=20in=20many=20cases=20won't=20require=20goin= g=20across=20=20 >=20the=20net).=20=20This=20is=20one=20of=20the=20reasons=20why=20the=20We= b=20exhibits=20good=20=20 >=20scaling=20behavior. I=20didn't=20say=20that=20the=20URI=20shouldn't=20be=20opaque.=20=20I=20di= dn't=20say=20that=20=20 this=20need=20was=20universal=20for=20every=20link=20(a=20solution=20shoul= dn't=20impose=20a=20=20 cost=20when=20not=20wanted).=20=20I=20didn't=20suggest=20a=20mechanism=20t= hat=20would=20=20 degrade=20scaling.=20=20I=20still=20assert=20that=20in=20many=20use=20case= s=20a=20good=20UI=20=20 requires=20a=20bit=20of=20advertisement=20about=20the=20nature=20a=20linke= d=20resource=20=20 that=20a=20user=20might=20want=20to=20retrieve. Lisa 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 Aug 28 08:32:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHgGc-0001AW-IY; Mon, 28 Aug 2006 08:31:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHgGa-0001AR-VX for discuss@apps.ietf.org; Mon, 28 Aug 2006 08:31:00 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHgGZ-0000sM-Ez for discuss@apps.ietf.org; Mon, 28 Aug 2006 08:31:00 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id E10455647F; Mon, 28 Aug 2006 08:30:09 -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 Ox8+D67CqzUX; Mon, 28 Aug 2006 08:30:07 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id E18AA5647B; Mon, 28 Aug 2006 08:30:01 -0400 (EDT) Message-ID: <44F2E1F9.10201@cs.utk.edu> Date: Mon, 28 Aug 2006 08:30:49 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: "Deventer, M.O. \(Oskar\) van" Subject: Re: Update of RFC 2838, tv: URI References: <42F3BE57026C6E49B09E267EEF639D56C2A78B@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <42F3BE57026C6E49B09E267EEF639D56C2A78B@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: cf4fa59384e76e63313391b70cd0dd25 Cc: "Lear, Eliot" , discuss@apps.ietf.org, "Bray, Tim" , "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 -------- Original Message -------- > Lisa, all, > > What I need is a solution > 1) that identifies TV channels reasonably unambiguously, > 2) that can handle synonyms when needed, > 3) that does not require bilateral agreements, and > 4) that does not require active participation of broadcasters. I think the resulting solution set is the null set. Keith