Subject: RE: draft-zigmond-tv-url-02

From: Dan Zigmond <[email-masked]>
Date: Tue, 17 Aug 1999 09:57:45 -0700

At the risk of repeating several of the points Mike already made, I thought
I add my own response to this thread.

This URI scheme is already in widespread use by a variety of companies.
These include major producers and broadcasters of television programming
(such as Disney), television service providers (like DIRECTV), and software
companies (including Liberate Technologies and Microsoft/WebTV), among many
others.  The issue at hand is really how this use should be documented.  We
have proposed documenting the scheme as an Informational RFC in order both
to give it wide distribution within the Internet community and to encourage
just this sort of debate within the IETF on a better solution to the many
problems raised in trying to reference broadcast television content.  If the
IETF decides not to publish this specification, the URI scheme will not go
away.  Rather, it will continue to be used much as it is now, with perhaps a
somewhat greater likelihood of subtle interoperability problems across
disparate implementations.  Of course, those of us using the scheme will
attempt to avoid those problems by making the specification widely available
on our own, so, again, the issue is really the manner of publication, not
the material itself.

I would certainly favor the establishment of a working group to design a new
URI for television broadcasts that could be published on the standards
track.  In fact, I have supported that idea since I first published an
Internet-Draft on this subject in 1996.  I believe the IETF is surely the
right place for this to happen, but I also think that the experience of
implementing and using the "tv:" scheme as described in this draft will go a
long way towards informing the process.  

Having worked in this area for several years now, I think I can say with
some confidence that it will take time to complete a document worthy of the
standards track.  The problems (most of which I hope are at least mentioned
in the draft) are difficult.  In the meantime, I see no harm in documenting
existing practice, perhaps with the standard sort of IESG "disclaimer"
explaining that this draft should not serve as a model for other URI schemes
and that a standard mechanism will eventually be published by the IETF to
replace this one.  Despite its flaws, many people have found this scheme
surprisingly useful as an interim solution, and we would like to share our
experience with the rest of the community.  By my reading of RFC 2026, this
is exactly what the Informational RFC series is for.

	Dan

---------------------------------------------------
Dan Zigmond
Senior Manager, Broadcast Applications
WebTV Networks, Inc.
[email-masked]
---------------------------------------------------

-----Original Message-----
From: Michael A. Dolan [mailto:[email-masked]]
Sent: Tuesday, August 17, 1999 7:55 AM
To: Matt Crawford; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: draft-zigmond-tv-url-02 

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

At 09:13 AM 8/17/99 -0500, Matt Crawford wrote:
>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
>
>

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

---

From: Robert Elz <[email-masked]>
Date: Thu, 19 Aug 1999 16:28:11 +1000

Date:        Tue, 17 Aug 1999 09:57:45 -0700
    From:        Dan Zigmond <[email-masked]>
    Message-ID:  <15AAE0EBDCC9D1119FFA00805F85642E0287AFB1@WNI-MSG-02>

  | In the meantime, I see no harm in documenting
  | existing practice, perhaps with the standard sort of IESG "disclaimer"

That doesn't sound too unreasonable, given that the things are in actual
use, and in more use than can easily be fixed.

I'd suggest as the disclaimer, something like:

	This document describes behaviour used by some of the XYZ industry
	at the time of its writing.   The IESG and IETF suggest that this
	usage be abandoned, and also suggest that no future implementations
	of the techniques described here be contemplated.  The method
	described here does not scale, is poorly defined, and subect to
	ambiguity and numerous failure modes.   Publication of this
	document in the RFC series of documents is meant only as a
	community service, to allow those who may have to interact with
	implementations of this scheme to know how to, as correctly as is
	possible, ignore it.

That is probably almost clear enough (once XYZ is replaced by a label that
indicates which industry segment has actually had the short sightedness to
actually use this nonsense).

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 19 Aug 1999 16:28:11 +1000

kre