Subject: draft-zigmond-tv-url-02 informational RFC

From: "Marlin E. Davis" <[email-masked]>
Date: Mon, 23 Aug 1999 08:39:56 -0500

IETF members,

Screamingly Different Entertainment uses and supports the conventions
documented in draft-zigmond-tv-url-02.
We support the release of this document as an Informational RFC.  It is
essential for the effective development of content across the industry and
across various platforms.
Marlin E. Davis
CEO/Executive Producer
Screamingly Different Entertainment
West Coast (213)680-3330 Midwest (316)267-3024
[email-masked]

---

From: "John W. Noerenberg" <[email-masked]>
Date: Mon, 23 Aug 1999 12:27:50 -0700

>documented in draft-zigmond-tv-url-02.

Severe technical limitations to the protocol described in this 
document have been identified with some discussion of them on the 
[email-masked] list.  Draft-zigmond-tv-url itself notes some of the 
problems.  It is clear from the discussion the protocol is unsuitable 
for reliable deployment across the net as it stands.

>across various platforms.

An informational RFC is not the correct document as the basis of an 
interoperable design.  What is required is a standards-track 
document.  Dan Zigmond's paper describes current practice.  That it 
brings attention to the limitations of the current scheme is 
laudable.  That a number of organizations feel the need for this sort 
of protocol is noteworthy.

However your note does not address the problems which have been 
raised with the protocol.  As a consequence, it will carry little 
weight with the IETF community, specifically with the IESG, in regard 
to its acceptance as an informational RFC.

Perhaps you should look into the objections that have been raised and 
invest some time in understanding how Internet protocol standards are 
developed by the IETF.

best,

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   The man that can most truly be accounted brave is he who best
   knows the meaning of what is sweet in life and what is terrible,
   and then goes out undeterred to meet what is to come.
   -- Pericles, "Funeral Oration", 479 B.C.
   ----------------------------------------------------------------------

---

From: "John W. Noerenberg" <[email-masked]>
Date: Mon, 23 Aug 1999 12:27:50 -0700

best,

john noerenberg
[email-masked]

---

From: "Michael A. Dolan" <[email-masked]>
Date: Mon, 23 Aug 1999 14:33:29 -0700

The thread is repeating, but as long as folks continue to say these 
sorts of things, I still feel somewhat compelled to reply...

The technical issues with tv: are well-known and understood by the 
authors and the people adopting its use.  The extent to which these 
limitations have not been as well documented as they could have in 
the submitted I-D is noted and hopefully corrected in the next draft.

Sweeping assertions about the scheme being unusable are just 
opinions.  And, we certainly all have our opinions on this.  However, 
the strong evidence to the contrary is in the fact that it is fairly 
widely deployed now and has been in use for some time (subjective 
discussions on "how wide is wide" not withstanding).  The fact that 
it may have very limited use is not at issue.  The only issue is 
documentation of existing practice.

Comments on what the IESG will or will not be affected by seem very 
odd to me since the people making this sort of statement are not 
members of the IESG; and such postings were specifically and clearly 
solicited by the RFC Editor in the Last Call.  There was no mention 
of providing technical arguments - only support for the scheme.

And, detailed knowledge of IETF processes (which is understood by 
folks on this list to quite varying degrees) is not a requirement to 
reply to an RFC Editor request, which are very widely distributed.  
If Last Call's were meant to be only to IETF members with an 
understanding of IETF processes, then such postings would be made 
only to IETF (or a subset).  If folks feel compelled to educate the 
uninformed posters on the workings of IETF, I'm sure the individuals 
would appreciate a private email.

I hope that future such posts of deployment support for tv: (if any) 
will not elicit these sorts of replies from the list.  (I can hope, 
can't I?)

And, to Mr. Noerenberg's new point that the draft should not be 
Informational.  That's interesting, but I would argue the next step 
up in this situation would be a BCP, which also doesn't have the 
technical review process everyone seeks.  In any event, it is not 
appropriate as a Standard, to which I think we would find concensus.

	Mike

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

---

From: "Michael A. Dolan" <[email-masked]>
Date: Mon, 23 Aug 1999 14:33:29 -0700

Mike

---

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Aug 1999 17:37:40 -0400

Gee, isn't summer a nice time to discuss IETF procedure?..

Let's go back to first principles there.  Publication of "foreign"
protocols is a time honored tradition of the IETF, or rather of the RFC
Editor. The basis is that if a protocol is actually used in the Internet,
it is better to have the specification available for everyone to look at,
than to have it hidden in some repository. The messages of support that we
all saw on the least make that point clear: this protocol is widely used.
(The point would be clearer if instead of a set of "I like the draft"
messages, we had a documentation of the level of usage. Maybe in an
appendix to a revised version.)

Publication does not mean endorsement. The comments that were received on
this list show that the "tv:" scheme has some quite obvious shortcomings.
The normal way to cope with such situations is for the IESG to prepend a
warning of some sort in front of the message, documenting the shortcomings.
This should be our classic mode of operation.

Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Aug 1999 17:37:40 -0400

Christian Huitema

---

From: "Jack Lang" <[email-masked]>
Date: Mon, 23 Aug 1999 22:57:05 +0100

> for reliable deployment across the net as it stands.
I replied to Keith Moore and Tony Hain as follows:

I respectfully disagree - you are confusing about two different things!!

tv: is about picking up a local broadcast, using local names. It means tune
the receiver on this box to xxxMhz (or set filters for a particular service
in a digital broadcast). A short form name for xxxMhz is convenient, but
strictly local to the STB.  This is very different from defining global
names for TV
stations, even assuming you could get agreement.
Finding stuff in a global ether is a quite different problem. There is
no reason why the two namespaces should be the same.

Local descriptors are often useful, even if they don't mean the same in all
contexts. There is no reason for them to satisfy the context independence
test. For example "file:foobar" doesn't mean the same in all contexts.
"tv:foobar"
is similar. Call them something different from a URL by all means, but that
is not an
argument against legitimising the practice.

I think that there are two separate problems, global and local control
within an STB (or cable head-end). How to tune an STB is a now problem;
namespaces for global webcasts are a future problem. I agree that  a more
complex name space is needed for the global problem, but I don't think that
we will resolve in finite time the problem of an acceptable global naming of
TV stations, even if that is in our remit.  Station names may match via
broadcast and cable (but not always), but may conflict across wider areas.

I suspect that global webcasts will be built on extensions to conventional
URLs. Even today we get a sort of live tv as things like
"mms://domain/service" - I'm watching one now, small and jerky.  That's
quite a different space from tv:BBC1, and even with a rich global namespace,
local short form names that map to a full name have a place.

The problem that Dan's proposal addresses, and one which is soluble, is
local
(local to the STB even) tuning. For example I can envisage an application,
for example the EPG application, asking the user at set-up time to pick a
short-form station name from a drop-down list at channel scan time. That
also neatly avoids the problem where multiple sources of the same broadcast
are available. Alternatively some digital services (DVB for example) are
self-identifying with the SI information carrying the service name. Some
analogue services, at least in the UK, let you can deduce the channel  from
the
teletext service carried in the VBI.

I do not see that adopting Dan's proposal in any way compromises a later
global name scheme, They solve different problems in different spaces. They
can co-exist.  I'd have no objection to (say) something like
tv:analogtuner/BBC1 or attv:BBC1 if required, but I don't see that it adds
much.

How else would you propose controlling an STB's tuner? Java calls?

Jack Lang
ntl:

---

From: "Jack Lang" <[email-masked]>
Date: Mon, 23 Aug 1999 22:57:05 +0100

Jack Lang
ntl:

---

From: [email-masked]
Date: Mon, 23 Aug 1999 16:54:20 -0700 (PDT)

> argument against legitimising the practice.

Local descriptors are very useful. Conventions about how to create
local descriptors are also useful, because they help others reading
code to understand the type and use of that-which-is-described.  Among
the most common of these conventions is that you do not use reserved
terms as local descriptors, as these may later clash with something
more global.

I believe that a lot of the pushback on this scheme could be
summarized as metaphorically equivalent to "You are using a reserved
term as a local descriptor".

There are a couple of choices about how to resolve this problem. One
is to have the larger community abandon the term as reserved and
reserve a new term.  Since URIs include a syntax as well as a prefix,
that could mean a new syntax instead of new prefix; the proposal
within this draft to use tv:// as reserved and allow tv: to be local
is a species of this solution.

Another possible solution is to continue to reserve the term globally
and to have a global reference to the local descriptor which
distinguishes the two.  I have proposed in private discussions with
one of the companies involved that they consider using "prefix-tv:" in
their docs and future implementations and note in their description of
this practice that some early implementations assumed the "prefix-".
This would force them to work around references to the globally
reservered term in later occurrences; that company felt that they
could do that, but that may not be universal.  If that is workable, it
would retain tv: as reserved for a future URI scheme and would notify
those using URIs that "prefix-tv:" might look like a URI but it is 
a term reserved for a local descriptor.

A last possible approach is to assert that the local descriptor is not
the globally reserved term and hope that context will later distinguish
the two.  This last approach seems to have the least hope of continued
interoperability.
			regards,
				Ted Hardie

---

From: [email-masked]
Date: Mon, 23 Aug 1999 16:54:20 -0700 (PDT)

---

From: Richard Shockey <[email-masked]>
Date: Mon, 23 Aug 1999 19:06:11 -0500

>Gee, isn't summer a nice time to discuss IETF procedure?..

There is a reason its called the "Dog Days of August". :-)

>than to have it hidden in some repository.

Yes.. and not have to pay a outrageous sums of money to d/l.

>This should be our classic mode of operation.

And on the basis of this discussion thread I would endorse that solution 
without reservation.

The key IMHO is that the author has correctly made the draft available for 
IETF comment and discussion.   I found the draft to be interesting, which 
does not mean that I have made any judgement on its suitability.  The 
fundamental principal is that anyone should be able to come to the IETF 
with ideas and concepts.  I would hope that the authors of this draft and 
the other TV industry representatives continue to view the IETF as a 
appropriate forum for the free and open exchange of ideas.  My mailbox is 
always open.

Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Richard Shockey <[email-masked]>
Date: Mon, 23 Aug 1999 19:06:11 -0500

Richard Shockey
Shockey Consulting LLC

---

From: Glen Zorn <[email-masked]>
Date: Mon, 23 Aug 1999 20:30:24 -0700 (PDT)

> This should be our classic mode of operation.

At last, the voice of reason!  I was beginning to despair.    

> 
> 
> Christian Huitema
> 
> -
> This message was passed through [email-masked], which
> is a sublist of [email-masked]. Not all messages are passed.
> Decisions on what to pass are made solely by Harald Alvestrand.
>

---

From: Glen Zorn <[email-masked]>
Date: Mon, 23 Aug 1999 20:30:24 -0700 (PDT)

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Aug 1999 00:10:31 -0400

> Publication does not mean endorsement.

no it does not.  however, we need to realize that if we publish this
document we are encouraging further use of the protocol described in
this document, and by implicitly "registering" this URL scheme
we are encouraging further pollution of the URI prefix space with 
poorly designed schemes.  it's not  clear that either of these 
benefits the Internet community.

IETF isn't bound to publish every document that reflects existing
practice.  

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Aug 1999 00:10:31 -0400

Keith

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Aug 1999 10:09:48 -0400

>IETF isn't bound to publish every document that reflects existing

Publication IS interpreted as endorsement by many folks, a not unreasonable
interpretation since the RFC editor has always reserved the right to refuse
to publish submissions.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Aug 1999 10:09:48 -0400

Steve

---

From: Tim Salo <[email-masked]>
Date: Tue, 24 Aug 1999 10:40:11 -0500 (CDT)

> Date: Tue, 24 Aug 1999 10:09:48 -0400
> From: Stephen Kent <[email-masked]>
> Subject: Re: draft-zigmond-tv-url-02 informational RFC
> 	[...]

An end to April Fool's RFCs?

-tjs

---

From: Tim Salo <[email-masked]>
Date: Tue, 24 Aug 1999 10:40:11 -0500 (CDT)

-tjs

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 24 Aug 1999 16:34:58 -0500

> An end to April Fool's RFCs?

I like a good joke better than the next guy, but this wouldn't bother
me, as the quality has been seriously slipping for several years.

				Matt

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 24 Aug 1999 16:34:58 -0500

Matt

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 24 Aug 1999 23:51:30 +0100 (BST)

> me, as the quality has been seriously slipping for several years.

April-Fool's internet drafts. They're what a six-month
expiry date is _for_.

L.

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

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 24 Aug 1999 23:51:30 +0100 (BST)

L.