Subject: draft-zigmond-tv-url-02

From: Scott Watson <[email-masked]>
Date: Mon, 16 Aug 1999 17:39:43 -0700 (PDT)

IETF members,

The Walt Disney Company uses and supports the conventions
documented in draft-zigmond-tv-url-02.

We support the release of this document as an Informational RFC.

--

Scott Watson
Technical Director, Disney Enhanced Television Group
Director / Sr. Prinicipal Staff, Disney Research and Development

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 17 Aug 1999 10:57:09 +0200

>We support the release of this document as an Informational RFC.

I don't.

This scheme uses unregistered, ambiguous identifiers (the Network ID) in an 
URL scheme. This means that those URLs will cause as much trouble as the 
"file:" URL does.

The draft acknowledges this problem (section 3.3):

    The flat namespace for network identifiers poses a serious problem
    going forward.  IANA registration could be used avoid collisions,
    but at the cost of restricting bona fide networks with identical
    identifiers from using their common abbreviations in these URIs.

This paragraph also repeats the mistake that has plagued the domain name 
wars from the beginning - equating technical identifiers with "common 
abbreviations". This approach has known problems, to put it mildly.

That Disney has chosen to use a scheme with known technical problems does 
not mean that the IETF should endorse this practice.

                        Harald

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 17 Aug 1999 09:13:20 -0500

This draft looks broken, bad, wrong and insufficiently baked.  It
would lock out legitimate holders of certain "call-signs" by
conflicting "network-ids" and force broadcasters with duplicate
network-ids to race or fight for their established names.  The draft
briefly acknowledges the problem but reserves and defers to the
future any mechanism for solving it.

The conflicts MUST be resolved before this scheme can be dignified
by IETF publication.

Furthermore, the intellectual property notices are fraught with
troubles.  It promises a royalty-free license "upon adoption of this
contribution as an Internet Standard", yet the draft itself purports
to be on the Informational track.  (Even if it were on the standards
track, it's very plasible to argue that a Proposed or Draft Standard
is not an "Internet Standard".)

Send it back to the drawing board, please.

				Matt Crawford

---

From: "Michael A. Dolan" <[email-masked]>
Date: Tue, 17 Aug 1999 07:55:09 -0700

Matt-

I'll let Dan and Mark reply in any formal capacity, but I must really 

disagree with the severity of this message.

This draft is an attempt to document existing practice in the form of 

an informational RFC.  While I do not believe that it is "broken" as 
you claim, even if it is, nothing you or anyone else says on this 
list is going to suddenly stop it from being used.  It is in use 
today and will continue to be in use.  If the authors felt that this 
URI scheme was worthy of IETF endorsement as a standard, they would 
have proposed it as such.

It is not possible to resolve the call-sign namespace.  The namespace 

itself is broken, not the URI scheme that uses it.  It can be used 
very carefully in an unambiguous manner, and the signs listed here 
are in use today.  But to request that the authors of this draft 
attempt to resolve an existing world-wide video feed namespace 
problem that existed long before this draft and will continue to 
exist, is not reasonable and is way beyond the scope of this URI.
The fact that this namespace is broken is not this draft's fault or
problem to solve.

I'm sure the IP statement syntax error you pointed out can be easily 
corrected with the change one word.  Or if you prefer, I'm sure they 
can take away the free license if you wish and put it back to just 
the standard wording.  Give them a break on trying to be generous.

I feel that your recommendation that this draft be "sent back to the 
drawing board" is neither productive in the context of an 
Informational RFC, nor warranted from the items you pointed out.

	Mike

>Send it back to the drawing board, please.

------------------------------------------------------
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122

---

From: [email-masked]
Date: Tue, 17 Aug 1999 09:41:24 -0700 (PDT)

Mike,
	If nothing anyone says on this list will influence the use of
this protocol, we are the wrong group to consult and the wrong group
to publish documents related to the protocol.  If, on the other hand,
you would like to take advantage of the group's many years of
experience with translating namespaces to network addressable
resources, many people seem willing to help.
draft-ietf-urlreg-procedures-07.txt and draft-ietf-urlreg-guide-05.txt
should help you capture some of that experience; I believe that many
of the objections you are seeing would be captured by reference to the
provisions of the latter document.
	Documenting existing practice is useful in IETF contexts when
the IETF plans to take a hand in creating a follow-on standard which
eliminates the warts being documented. It's also done when a
proprietary standard is so widely deployed that network folk need to
understand how its traffic, security, and transport characteristics
will influence the network.  Neither seems warranted here, especially
since you are only documenting the namespace, not the protocol.
	Still, if you are absolutely determined to use the IETF to
document this, I suggest you change your approach to the IESG to ask
for a non-IETF registration tree under the proposed procedures in
draft-ietf-urlreg-procedures-07.txt.  Like the vendor registrations
under MIME, those provisions allow for private change control for a
registered URL scheme; the URL scheme will be faceted, but your
installed base is actually small enough to move toward a foo-tv:
namespace.
			regards,
				Ted Hardie

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Matt-
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP for Personal Privacy 5.0
> Charset: noconv
> 
> iQA/AwUBN7l3zCl9dIG/haQGEQJWKgCffQnYJL99KAHf9Llv0818xiR3eQYAn2Kj
> +Bq6tkP6uvcCtyIkApKyU108
> =oHBm
> -----END PGP SIGNATURE-----
>

---

From: "Michael A. Dolan" <[email-masked]>
Date: Tue, 17 Aug 1999 10:16:58 -0700

At 09:41 AM 8/17/99 -0700, [email-masked] wrote:
>to publish documents related to the protocol.

I don't understand the above statement relative to the statements you 
made below.  Clearly there is a place in IETF for documenting 
existing practice without "taking it back to the drawing board".

>If, on the other hand,
>should help you capture some of that experience;

Could you please point me to those people who wish to help?  The only 
comment so far from anyone is from Mr. Crawford. Is this who you are 
refering to?

>I believe that many
>eliminates the warts being documented.

Not withstanding the contradictory first sentence, it has always been 
the submittors' intent to follow this up with a new tv:// syntax that 
more properly addresses the noted (and many more) concerns.  It would 
be our hope that IETF members would actively participate in this 
effort.

>It's also done when a
>will influence the network.

Yes.

>Neither seems warranted here, especially

We disagree.  We are documenting the semantics of the scheme, for 
which there is existing and growing usage.  It is critical that the 
growing usage not diverge in its syntax and semantics.

The namespace is only one component of the semantics of this scheme.

>registered URL scheme; the URL scheme will be faceted,

This is not adequate in our opinion for the reasons stated above.

>but your

What could you possibly know about our installed base?  And, what may 
be "small" to you is not "small" to someone else who has to replace 
CE equipment.

	Mike

---

From: [email-masked]
Date: Tue, 17 Aug 1999 12:33:59 -0700 (PDT)

> >to publish documents related to the protocol.

I made that comment in the context of your earlier statement:

   While I do not believe that it is "broken" as you claim, even if it
   is, nothing you or anyone else says on this list is going to suddenly
   stop it from being used.

(The entire earlier message is quoted below, for those who wish
 to see it in context)

I agree that there is a place in the IETF for documenting existing
practice, but the contexts are limited.  In my message, I attempted to
draw out what the contexts might be here.  I did not see your current
draft fitting any of those contexts; in your later message, you
indicate that you intend to turn over revision control of this work to
the IETF.  If the IETF accepted that, that would place it in an
appropriate context.  As others have noted, however, there is work
going on in other fora on this topic (the W3C, for example), and the
IETF has agreed to coordinate its work with bodies like the ITU and
the W3C.  That means that the IESG and IAB would need to coordinate
the work with those bodies and decide whether to take on a working
group focused on this task.

> comment so far from anyone is from Mr. Crawford. Is this who you are 

I thought Harald's message indicated a willingness to share his
considerable experience, and I got the same impression from other
earlier messages.  You may also wish to contact the URLREG working
group for more contacts.  That group is in the process of finishing
its work, but the mailing list should remain active as a contact
point for discovering interested parties.

> be our hope that IETF members would actively participate in this 

I think you will find that one of the primary concerns of the IETF is
interoperability.  A major element of that is ensuring that protocols
and addressing schemes get extended in ways which are backwards
compatible (or they are completely replaced).  Having a scheme with
one syntax which morphed into a scheme with another syntax while
retaining the same name would be a problem.  At best, you would have
to cruft things up to distinguish which version is in use; at worst,
you would get interoperability problems which prevent forward
progress. 

> The namespace is only one component of the semantics of this scheme.

If there is growing usage of a scheme which has fundamental
ambiguities, documenting the syntax and semantics is not enough
to ensure interoperability.  You are getting considerable
feedback that the scheme has problems; continuing to promote
its use in the face of that feedback does not seem the wisest
course.

> This is not adequate in our opinion for the reasons stated above.

I take it the "existing and growing usage" is the reason you do
not wish to use a faceted scheme.  If there is a different reason,
I did not glean it from the statements above.

> be "small" to you is not "small" to someone else who has to replace 

I absolutely agree that replacing and reworking code to deal with
either a faceted scheme or a new version will be painful.  But I see
bugs in this scheme, and so do others.  Fixing bugs is a painful but
necessary part of the business.  My advice is to do it as early as
you can.

I remember John Klensin trying to persuade the HTTP working group to
up the version number on HTTP in order to have full URLs in the
requests.  The installed base persuaded folks not to do it, and we
now have several permanent pieces of cruft (viz Host:) in an installed
base one hundred times as large.

				regards,
					Ted Hardie

> iQA/AwUBN7mZCSl9dIG/haQGEQJHAACdHoFS2MTyN7FzCenxTIP10HKQmGsAn3Nl
> 5c+BRo3WbKsdTbPcrhSSDhKM
> =9X3c

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Aug 1999 19:11:44 -0400

Ted has done, IMO, an excellent job of summarizing most of the
issues on this and I won't repeat his comments.  However, since
he mentioned the HTTP experience and my comments then, an
observation...

--On Tuesday, August 17, 1999, 12:33 -0700 [email-masked]
wrote:

>> >...
> I remember John Klensin trying to persuade the HTTP working
> group to up the version number on HTTP in order to have full
> URLs in the requests.  The installed base persuaded folks not
> to do it, and we now have several permanent pieces of cruft
> (viz Host:) in an installed base one hundred times as large.

In general, "can't change the installed base" arguments are at
their strongest if the installed base is at least moderately
large (quibbles about how large that is aren't important) and
fairly stable, i.e., the installed base is expected to grow
slowly or not at all.  If one posits exponential (or other very
rapid) growth in the user base, and changes will need to be made
to make things work properly --with this scheme, my guess is
that the killer will be the non-uniqueness of network
identifiers although other things ought to be cleaned up at the
same time-- then it is almost always best to figure out what
needs to be done and do it quickly, rather than defer it into
the future. Exponential growth causes exponential (or worse)
increases in the pain of making incompatible changes.

     john

---

From: "Michael A. Dolan" <[email-masked]>
Date: Tue, 17 Aug 1999 16:12:15 -0700

At 12:33 PM 8/17/99 -0700, [email-masked] wrote:
>appropriate context.

We agree.

>As others have noted, however, there is work
>going on in other fora on this topic (the W3C, for example),

I am part of the W3C www-tv interest group and there simply isn't any 
work going on in W3C, despite this group's existence.  If you are 
aware of something else, please provide a specific pointer.

>and the

Understood.  Are you saying that the documentation of tv: is out of 
scope of any existing IETF WG and/or out of scope of IETF altogether?

>point for discovering interested parties.

I don't know "Harald", have not received email from him to my 
knowledge, and am not aware of any email on this draft other than Mr. 
Crawford's.  Sorry if I am an IETF process idiot these days, but I 
would appreciate a pointer to the list archive where I can find these 
comments.  I'll be happy to reply to them.

>> >I believe that many
>> >of the objections you are seeing would be captured by reference 
to 
>> the

Agreed.  But I think you are mistaken about the URI syntax usage.  
tv: and tv:// syntaxes are two entirely different spaces.  While 
unusual for a scheme name to span both, it is not ambiguous and 
perfectly legal.

In any event, there is no attempt whatsoever to morph anything or 
create any non-interoperability as you assumed.

>to ensure interoperability.

The namespace is only ambiguous if you assume it is global all the 
time.  In practice the scheme is often used within the context of a 
network, in which case the feednames are NOT ambiguous.  In a perfect 
world, we would resolve the feed namespace problem with the TV 
industry (good luck), THEN make a URI that used that namespace.  But 
c'est la vie.  Here we are with a use in practice we need to 
document.

>You are getting considerable

I personally have not seen anything except Mr. Crawford's email.  So 
if you can point me to where these "problems" are being discussed, 
perhaps I, Dan or Mark can address them.  However I certainly expect 
that the opinions that have apparently formed are based on the 
document not being clear as opposed to it being a fundamantally 
flawed scheme.  Proof against the latter is that it is in use 
successfully by multiple vendors (you did notice that this draft was 
jointly submitted by fierce market competitors, yes?).  Obviously it 
has *some* value.  If we need to further clarify the scope and 
(possibly unstated) restrictions to better document it, then that's 
fine.  But lack of clarity is not a reason to abandon it.

>I did not glean it from the statements above.

OK, I will try to summarize them here:

	1. Future revision control by IETF (assumed by the authors)
	2. Related work of interest to IETF (assumed)
	3. Syntax and semantics are important to capture
	4. In wide use and thus important to publicly document *somewhere*

Now, if you are saying that the scheme belongs in the "alternative 
tree" as described in the proposed IETF process and documentation 
mechanism by Mr. Petke, that may be OK.  But that is still just a 
proposed draft, there is no clear procedure yet in IETF to make this 
really work in practice yet, and the ramifications of such a 
submission's status relative to the "IETF tree" is not clear and 
needs study.

What I was objecting to was your implied proposal that only the 
scheme name be registered.  That is simply not adequate, and I hope 
it is clear why now.

Regardless of what tree the registration occurs in, it still needs to 
be publicly documented.  And, IETF has decided that URL's will be 
documented in its organization (as evidenced by the above draft you 
reference).  So, if you still disagree with the premise that this URI 
scheme should be documented in IETF somewhere, then I am really 
confused.

If we're past that, then we can certainly continue to discuss how 
*best* to document it. 

>bugs in this scheme, and so do others.

Please elaborate in detail.

>Fixing bugs is a painful but

I wish we could, but it is now too late.  We can fix them in the next 
URI scheme (tv://).

>now have several permanent pieces of cruft (viz Host:)

I'm not sure this is the same issue, but I wasn't there, so I can't 
comment.

But, if you want a trip down memory lane, then lets talk about the 
more relevant news: and nntp: URL schemes which were also not fixed 
right away, despite my being on your side of the debate on those up 
against TimBL and LarryM.

But, in retrospect of 5 years, I do not now disagree with the final 
decision to maintain the documentation of then current practice, no 
matter how broken it seemed at the time.  I see tv: as EXACTLY the 
same issue.  It is in use and needs to be documented as it is being 
used.  IETF can't change this course by refusing to permit the 
documentation of it.

>in an installed

You continue to presume you know what the installed base of tv: is.  
And, the fact that there is a large lead time for CE equipment design 
that is/will use tv: and its manufacture not stoppable (even if it is 
not in user's hands this afternoon).  But, I do not intend to argue 
volumes with you unless ou can point me to where it says in IETF 
documents how many units have to be deployed before a standard is 
considered by IETF - i.e. "how many Cisco routers does a standard 
make?"

Also, there is an important distinction between router protocol 
standards and TV standards.  The latter get written to tape forever!  
As an example of the impact of this "foreverness" is what if we never 
wrote down the audio format used by the early TV shows, and the "I 
Love Lucy" audio track format was now deprecated (or worse) - it 
would be silent in the endless reruns (well, OK, *you* might like 
that, but you get the point :-).  tv: is already on lots of tape and 
DVD.  Like it or not, it is here forever.

And, if relative volume does matter somehow, then I would estimate 
that the installed base of tv: devices by yearend will be 100x larger 
than the installed base of news: and nntp: capable devices when that 
discussion occured.

	Mike

---

From: [email-masked]
Date: Tue, 17 Aug 1999 17:33:53 -0700 (PDT)

Mike,

> scope of any existing IETF WG and/or out of scope of IETF altogether?

If the IETF took on change control of the tv: URI scheme, then
documenting existing practice might well be something that would
take place within the IETF.  Please note the big "If".  

> comments.  I'll be happy to reply to them.

I meant Harald Alvestrand; he commented on this proposal to the IETF
list, which I thought you were following.  

The archive seems to be at:

ftp://ftp.ietf.org/ietf-mail-archive/ietf/current

though that version seems to be about a day behind.  There are other
comments which are going to the ietf list, probably from people
assuming as I did that the interested parties were following it.  You
may wish to subscribe if you want to respond in near real time.

> c'est la vie.  Here we are with a use in practice we need to 

The identifiers are fundamentally ambiguous, because you cannot
establish the context from the identifier.  You need to have a
globally unique identifier, or work from a scheme that has a way of
indicating context.  The draft acknowledges this, but does nothing to
resolve it.  It points to a section which acknowledges proposals for a
hierarchical scheme, and reserves a specific form, but contains no
method for resolve the underlying problem.

> fine.  But lack of clarity is not a reason to abandon it.

I look forward to your responses to the other comments made to
the IETF list.

> considered by IETF - i.e. "how many Cisco routers does a standard 

Please see John Klensin's comments on this topic; I note he cc'ed
you on them, so you should see them even without a subscription to
the IETF list.

> DVD.  Like it or not, it is here forever.

Given that the current tv: scheme implies "tune in whatever is showing
on the feed named in your context by this identifier", I do not
see how this archival usage enhances the argument for this scheme. 

			regards,
				Ted Hardie

---

From: "Michael A. Dolan" <[email-masked]>
Date: Tue, 17 Aug 1999 18:23:05 -0700

>ftp://ftp.ietf.org/ietf-mail-archive/ietf/current

I took a guess and poked around here a little earlier today, but 
could not find any relevant comments.  I did not look very far back 
in time however.  And, there were several lists being cc'd in all 
this and did not wish to subscribe to all of them (even if I could).  
I'll subscribe to ietf going forward.  About when in time did these 
previous posts occur?

>method for resolve the underlying problem.

The URI is unambiguous within a transport context.  Yes, this is far 
from  perfect, and is certainly not "global".  But it does serve the 
purpose unambiguously.  Any suggestions on how best to document this 
usage restriction?

>see how this archival usage enhances the argument for this scheme. 

It enhances the justification for its public documentation, which is 
all we are discussing.  Its pure technical merit (or lack thereof) is 
not at issue.

And, I will *cheerfully* lead a discussion, or even WG, on how we 
*should* have done it.  As Dan I think mentioned, a couple of us have 
informally started on requirements and a couple of proposed syntaxes 
from which to start thinking.  I'm sure the individuals involved 
would welcome a more formal home for these discussions; and we 
certainly welcome the technical advice of the group on the next step.

Before we can use feed namespace, we need to standard those in the TV 
industry (and that I am certain is outside the scope of IETF).  That 
is an ugly process, and some have suggested impossible.

But noone is asking IETF to endorse tv: as the future of TV URI's - 
just to recognize that it is in use and serves *some* purpose, so we 
can move on from there for the future.

	Mike

-----------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    
PO Box 1673 Alpine, CA 91903       FAX: (619)445-6122
URL:http://www.tbt.com

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 18 Aug 1999 13:20:38 +0100 (BST)

> I'll subscribe to ietf going forward.  About when in time did these 

Oh, just after a bunch of corporations weighed in demanding an
Informational RFC. Presumably they're not subscribed either.

Since this archive url hasn't been pointed out, it would be useful if 

http://www.ietf.org/mail-archive/ietf/Current/maillist.html

wasn't running more than a day behind, and if a search index was
implemented so that 'zigmond' produced the expected results.

The thread should show up there tomorrow.

> *should* have done it.

*lead* the discussion? right now you're not even following it...

L.

amazing how you can turn anything into a demonstration of the need for
accessible mailing-list archives to bring people up to speed, isn't
it?

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 18 Aug 1999 15:36:30 +0200

>purpose unambiguously.  Any suggestions on how best to document this

Not within a transport context. A naming context, which is established by
means that the draft says are "not described here".
The trouble with URIs has *always* been that they *move* - Web pages, 
documents and transmissions get taped, copied to file, sent by email, get 
looked at in text editors - and so on.
And once it's out of its naming context, you're in trouble.

>all we are discussing.  Its pure technical merit (or lack thereof) is

since the naming context is dynamically created, and time-varying 
(obviously), the archival argument is actually a strong argument AGAINST 
encouraging the prolonged usage of this scheme.
When you get the thing back from the tape, you have *no* idea what "tv:nrk" 
was supposed to mean.

>certainly welcome the technical advice of the group on the next step.

I tried to help Dan think about what to think about when he first proposed 
this, some 2 years ago. As far as I can tell, the changes since then are 
that all the ideas that gave hope for the future have vanished, along with 
one of the bad ideas (channel numbers). What's left isn't much.

What's your mailing list?

>can move on from there for the future.

If it has to be thrown out, documenting it without at the same time 
pointing out "the right way" might not be worthwhile.

[Warning - half-baked, but workable in my limited understanding
of the context, idea ahead. That's what you get from asking engineers.]

If you want simple, make it simple.

tv:<insert token here>unique.domain.name/nbc.
Or tv:[email-masked] (it's even syntactically distinguishable from 
the current practice, and could probably be retrofitted if there isn't a 
horribly low size limit somewhere around).

Just like the NAI of ROAMOPS - a domain name doesn't have to refer to a 
service contacted at a hostname, it can refer to a naming authority.
The properties of authority for assigning names in the DNS are well known.

                    Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Aug 1999 16:01:47 -0500

Michael A. Dolan wrote:
...
> The URI is unambiguous within a transport context.  

Then it is not a URI, because the U stands for "universal".

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Aug 1999 16:01:47 -0500

Michael A. Dolan wrote:
...

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 19 Aug 1999 00:43:01 PDT

Speaking of mailing lists archives, the 'tv' URL scheme was
discussed at some length last February, see:

http://lists.w3.org/Archives/Public/www-tv/

and, for example, the messages starting with:

http://lists.w3.org/Archives/Public/www-tv/1999JanMar/0022.html

I don't think many of the issues raised then have been resolved.

Larry
-- 
http://www.parc.xerox.com/masinter

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 19 Aug 1999 00:43:01 PDT

Larry

---

From: "Michael A. Dolan" <[email-masked]>
Date: Thu, 19 Aug 1999 11:16:20 -0700

Larry-

Here are replies to the issues that I think you refer to.  If I 
missed any, or misundertood them, please let me know.

There was a discussion between Werner and myself about trying the URN 
definition tack, which was abandoned, partly on your advice.

And to the issues you raised that were not specifically addressed on 
this list:

>Larry Masinter ([email-masked])
>Tue, 16 Feb 1999 22:33:31 PST 
>
>It would be acceptable if you included in the description of
>"tv:" all of the ways that it fails to behave as well as most
>other kinds of URLs...

Some attempt to do this was done by noting in this new draft that the 
namespace is a problem.  However, this admission of problems has 
drawn huge fire from others on this list and is being shown as proof 
that the scheme should not be published.  Damned if you do, and 
damned if you don't...

>...It would
>be useful to define something else that would work better --
>e.g., be well-defined in the context of a system with more
>than one TV tuner, for example, or for documents that were
>saved from TV onto a PC's disk. But that's not what you have.

The issue of handling multiple tuners is a known limitation, we can 
certainly document that fact.  And, we would all like to define 
something better in the near future.

>...At a minimum, I think you'd have to do
>a better job of dealing with the technical ambiguities of
>the meaning of "tv:" outside of the context of a particular
>mode of transmission, and that seems difficult to me.

The above led to a long discussion about the use of tv: as a 
reference within the HTML page, including ue of the data: scheme and 
OBJECT, etc.  The conclusion of this discussion with substantial 
input from W3C offline and confirmation from Werner was in fact that 
there was no better way to do it.  A URI (substantively like tv:) is 
needed to perform the desired function.

Again, there are many discussions we could have on the technical 
merit (or lack thereof) of tv:.  But since this is intended to 
capture current practice, I hope we can save those discussions for 
the next (better) scheme definition.

	Mike

---

From: "Michael A. Dolan" <[email-masked]>
Date: Thu, 19 Aug 1999 11:16:20 -0700

Larry-

	Mike

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 19 Aug 1999 13:31:16 PDT

> there was no better way to do it.

It's hard to confirm that there is 'no better way', especially
when presented with something that isn't a very good way.

I think, actually,

data:application/vnd.webtv.tune,channel=us.abc,date=19990819,time=23:30pdt,durat
ion=1hr

would work nicely for your application; you could register
'application/vnd.webtv.tune' (or whatever) as a new MIME type,
the content of which is a line of text which tells a TV when
and how to tune itself, and which can contain whatever data
you think is necessary to give useful instructions. In the
example above, you might include a global channel identifier,
and a date, time and duration. But you could include whatever
data was appropriate and implemented by your implementations.

Whether a receiver of such a URI chooses to interpret this data
is then not a matter of URL resolution (the resolution of a
data URL is the URL itself). Instead, you have a more typical
issue of whether you decide or can interpret this particular
vendor-specific media type in the local context.

It also means that the extensibility model would be clear, and the
authority for determining what 'us.abc' meant would be within
the context of the vnd.webtv.tune datatype.

Now, if you're designing application/vnd.webtv.tune, I'd suggest
that you try to make the content unambiguous without reference
to any other local state, but that's your business.

Larry

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 19 Aug 1999 13:31:16 PDT

I think, actually,

Larry

---

From: "Michael A. Dolan" <[email-masked]>
Date: Thu, 19 Aug 1999 13:45:03 -0700

Larry-

I will have to research some old email lists and various private 
email to reconstruct why what you propose below was decided won't 
work.  As I recall, the problems were in the semantics of the OBJECT 
tag.  I don't know if this is the forum for that discussion, but I'll 
try and reconstruct the argument.  This may take some time, so please 
stand by...

However, even if it turns out this will work and is a better HTML 
solution, we still need to document tv: since we weren't clever 
enough to do it that way and invented tv: instead.

	Mike

---

From: "Michael A. Dolan" <[email-masked]>
Date: Thu, 19 Aug 1999 13:45:03 -0700

Larry-

	Mike

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 20 Aug 1999 14:57:08 +0100 (BST)

> data:application/vnd.webtv.tune,channel=us.abc,date=19990819,time=23:30pdt,durat

If there was only one unambiguous 'pdt' this might be workable, but
there are people living in the Pacific outside the US... providing an
explicit offset from UTC avoids the problems of time zones and dayligt
savings somewhat.

L.

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 20 Aug 1999 14:57:08 +0100 (BST)

L.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 20 Aug 1999 08:49:40 +0200

>needed to perform the desired function.

Perhaps part of the problem is that "the desired function" is not described 
terribly clearly.
I looked at the spec referenced as "proof of usage" (the one using "tv:" 
without a channel name), and thought the requirement it tried to fill was 
quite bizarre, and likely to get you into trouble, but not the same as the 
requirement that would lead one to use channel name.

What are your requirements?

                    Harald A

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 20 Aug 1999 08:49:40 +0200

Harald A

---

From: John Stracke <[email-masked]>
Date: Fri, 20 Aug 1999 11:13:23 -0400

Larry Masinter wrote:

> would work nicely for your application;

Or perhaps you could extend iCalendar (RFC-2445) to carry channel information.  You
could then use some URL that would provide the text/calendar--data:, http:,
whatever.  This would give you all the scheduling features of iCalendar (e.g.,
repeating rules: if I'm going to watch The Simpsons every night, I don't want a
separate URL for each night), plus a user's calendar software could use the same
MIME object as their TV software.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: John Stracke <[email-masked]>
Date: Fri, 20 Aug 1999 11:13:23 -0400

---

From: "Michael A. Dolan" <[email-masked]>
Date: Fri, 20 Aug 1999 08:30:03 -0700

We're drifting into left field a bit, but FYI, there is a globally 
unique program ID namespace being defined by SMPTE for ISO.  Once 
this spec has settled down, and the bindings are defined in specific 
transport SI data, I would envision a URI scheme to be able to 
reference these in some manner to accomplish what you suggest below.

But even before that, one could use a btv:-like scheme that is author-
controlled, to accomplish it.  The namespace is derived from the DNS 
registration (like all well-formed // URI schemes), and a broadcaster-
specific identifier is appended.  This is then tagged and bound to 
the programs they point to in the transport SI.

Also, one can never presume in a TV that there is a route that 
permits HTTP (or any other query/response protocol).  The bindings 
for the information (however it is done - IP or otherwise) must be 
sent in the broadcast stream.

Which leads me to a whole other interesting topic on the broadcast IP 
network model, but I digress even more...

	Mike

>> I think, actually,
data:application/vnd.webtv.tune,channel=us.abc,date=19990819,time=23:3
0pdt,durat

---

From: "Michael A. Dolan" <[email-masked]>
Date: Fri, 20 Aug 1999 08:30:03 -0700

Mike

---

From: "Michael A. Dolan" <[email-masked]>
Date: Sat, 21 Aug 1999 16:03:58 -0700

Larry-

I reviewed various email archives and the consideration of using 
data: actually was related to another TV HTML/OBJECT tag problem I 
was wrestling with concurrent with the public discussion on tv:.  But 
it was not related to the use of tv: in any way.

So, there was *not* in fact a conclusion that data: would not work.

Sorry for the confusion and my misstatement.

As to the technical matter, the fact that there may be a better way 
(or 2 or 3) to do it now is not really the issue.

When we get around to more formally proposing tv://, perhaps we 
should consider a form of data: instead of that.

	Mike

---

From: "Michael A. Dolan" <[email-masked]>
Date: Sat, 21 Aug 1999 16:03:58 -0700

Larry-

	Mike