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

From: Dan Zigmond <[email-masked]>
Date: Wed, 18 Aug 1999 15:59:56 -0700

Again, this is far from being the central point of this debate, but the
words do mean different things.  I read "uniform" as meaning roughly "always
the same".  In this sense, "tv:bbc", for example, could be a "uniform"
identifier for the BBC, in the sense that the BBC could always refer to
their broadcasts this way.  On the other hand, I believe "universal" implies
something more like "occurring everywhere", and "tv:bbc" might not be a
"universal" identifier in that it couldn't be guaranteed to resolve to the
BBC's broadcast signal in all contexts.  Using similar reasoning, "Dan" is a
good uniform name for me, but a lousy universal one.

Putting that aside, it sounds like there are some folks out there who would
like to help us improve the current draft before any publication and some
who would like to see it published in its present form and then fixed (and
republished in the standards track).  What's the best way to make a decision
and wrap this up?  My own preference would be to publish the draft with a
very clear disclaimer, and speed the standards track work along as best we
can concurrently.

	Dan

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

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Wednesday, August 18, 1999 3:32 PM
To: Dan Zigmond
Cc: Michael A. Dolan; [email-masked]; Matt Crawford; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: draft-zigmond-tv-url-02

Dan Zigmond wrote:
> 
> Actually, I think it stands for "uniform".  :-)

Correct, but I think my point remains valid
> 
> These URIs are certainly different from, say, "http:" URIs.  But they are
> similar to "file:", I suppose, and perhaps to "news:".  

Yes, not ones we should be especially proud of.

> ...But I'm not sure
> this point really matters.  The question is whether "tv:" is worth
> documenting as currently specified and used, "fixing" and the documenting,
> or none of the above.

True.

   Brian

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 19 Aug 1999 01:58:53 +0100 (BST)

On Wed, 18 Aug 1999, Dan Zigmond wrote:
> Brian Carpenter wrote:
> | Dan Zigmond wrote:
> | > Actually, I think it stands for "uniform".  :-)
> | 
> | Correct, but I think my point remains valid
>
> their broadcasts this way. 

Wait - you're using tv: as a _uniform_ identifier to identify
organisations (BBC) rather than channels? (in this case, BBC1, BBC2,
BBCNews24 BBCwhateverextraondigital BBCpayperview etc). That doesn't
seem very _uniform_ to me.

Such a 'network identifier' cannot be reliably mapped to a known call
sign and then to a frequency, and section 3.5 of your draft presents
problems, especially:

   These hierarchical forms also will be important in allowing
   geographically separated networks (such as the Australian Broadcast
   Corporation and the American Broadcast Company) to share
   identifiers, and for disambiguating call signs and network
   identifiers in cases where they collide.

...by allocationg the American organisation tv:abc/1 2 and 3 and the
Australian tv:abc/10 11 and 12 or some other separation at a further
level, say? That's the first thing that comes to mind.

That's generally not how hierarchies work, and the distinction between
'network identifiers' (a very US-specific term and concept, that),
companies operating television channels, and the channels themselves 
is not at all clear to this non-US reader.

Presumably the UK companies Channel 4 and Channel 5 would not be
permitted tv:4 and tv:5, in accordance with section 4 of your draft.

   It is expected that IANA will be asked to register both tuning
   spaces and identifiers within some of those spaces.

Is IANA able to comment on this?

And how would your draft handle e.g. a corporate merger and resulting
assimilation of the namespace?

> On the other hand, I believe "universal" implies
> republished in the standards track). 

...and some others who'd just like to see it expire without trace.
Publication as informational? Possibly, after considerable cleanup
(esp of IPR) - but _standards track_?

L.

digital television? it's still just television.

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

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 19 Aug 1999 01:58:53 +0100 (BST)

L.

---

From: Daniel Senie <[email-masked]>
Date: Wed, 18 Aug 1999 20:59:48 -0400

I am willing to see it published, as the basis for future work, provided
the following things are done:

1. Remove or substantially rework the proprietary rights segments, those
being sections 9 and 10. To be honest, I didn't see anything in this
document that was worthy of being proprietary property. Let the two
companies officially declare (in this document or elsewhere) that they
lay no claim to this name space whatsoever. They seem to say this
anyway, but in a rediculously obtuse way. Just give it away, don't
bother with the "will give a free license..." stuff.

Clearly the wording of these sections is objectionable on several
levels, from the issue of talking about publication as an "Internet
Standard" to issues of a claim to intellectual property for claiming
"tv:bbc" is novel in any stretch of the imagination.

2. I don't see any copyright listing. This is required.

3. While your document references RFC 2026, section 10, it's unclear
whether the document meets those requirements or not. I'd suggest this
needs careful review, especially in light of #1 above.

4. Limit this document to the present condition, making it a document
which solely covers existing practice. Write a separate document which
begins the process of "getting it right." Plenty of folks will be happy
to comment on and make suggestions for that second document. Get a first
draft out there, and folks will have at it.

5. Be sure your examples of callsigns include other than USA callsigns.
For example, in the Netherlands Antilles, you might have a TV station
which has PJ as its starting letters. In Albania, it'd be 9A followed by
the station's specific letters. The main reason to call this out is to
be sure folks realize callsigns MAY start with a letter or a digit.

6. Security Considerations: In addition to costs associated with tuning
pay-per-view, there's the issue of a child tuning in adult programming.
I'm not sure either belongs in this section, but if one does, they both
do.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com

---

From: Daniel Senie <[email-masked]>
Date: Wed, 18 Aug 1999 20:59:48 -0400

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Aug 1999 21:01:02 -0400

> their broadcasts this way.  

except that as you've got tv: defined, tv:bbc might mean something
different in some other context.  therefore BBC could *not* always
refer to their broadcasts that way if they expected it to be 
interpreted in a uniform fashion.

> What's the best way to make a decision and wrap this up?  

ultimately the decision is made by IESG, and perhaps, the RFC Editor.

at this point we're just looking for input from the community.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Aug 1999 21:01:02 -0400

Keith

---

From: George Michaelson <[email-masked]>
Date: Thu, 19 Aug 1999 11:25:02 +1000

If the IETF does anything which codifies and formalizes tv://abc meaning
a US broadcasting company rather than any co-existing ABC (abc.net.au) or
a putative other ABC in some other country, It will be re-capitulating the
entire f**kup which leads to .com instead of .com.us and the predictable
warfare over US territorial issues being scoped globally in the namespace.

This would be rilly rilly stupid. Please, whatever else you do in the tv: URI
space, don't foist US domestic commercial decisions into a global worldwide
naming space. I don't care if the (US) TV companies want this. That is not
a good determinant of naming behaviour in the Internet.

[ I am betting that the last thing the TV companies want is for tv://abc to
  locate what the viewer, locally regards as their preferred mapping into that
  namespace. After all, that defeats the global branding doesn't it? ]

cheers
	-George

--
George Michaelson         |  DSTC Pty Ltd
Email: [email-masked]    |  University of Qld 4072
Phone: +61 7 3365 4310    |  Australia
  Fax: +61 7 3365 4311    |  http://www.dstc.edu.au

---

From: George Michaelson <[email-masked]>
Date: Thu, 19 Aug 1999 11:25:02 +1000

cheers
	-George

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 19 Aug 1999 04:28:06 +0100 (BST)

> be sure folks realize callsigns MAY start with a letter or a digit.

That much is covered by the BNF in section 4 of the draft.

Callsigns can contain more than just letters or digits; how would you
indicate/encode a Russian television channel written in Cyrillic? A
Chinese television station? Or accents?

In mapping organisation names in multiple languages into an artificial
namespace represented in a subset of common ascii, you need to
consider encoding of foreign (that is, non-US) characters, which you
haven't. This would ease finding a channel once a user has typed in
the URI and make the user and software interface more consistent
across different vendors, otherwise the namespace fragments locally
because whatever-the-binary-code-for-the-special-char-when-typed-in-a-
Microsoft-font is is something else on non-webtv equipment. It's smart
apostrophes writ large.

The four lines of broken BNF in section 4 strike me as unclear in
specification; I don't know about you, but I can't find definitions
for 'extra' or 'safe' in RFC 2396; they're only in 1808 (where safe
permits 'Canal+' and extra allows us 'E!'.) Given the scope of this
draft and as the BNF stands:

      tvuri        = "tv:" [ broadcast ]
      broadcast    = call-sign | network-id
      call-sign    = 1*[ alpha | digit ]
      network-id   = 1*[ alpha | digit | safe | extra ]

might be better written something clearer along the lines of:

      URI-tv       = "tv:" [ local_id ]
      local_id     = 1*( alphanum | "+" | "-" | "!" )

since the draft hasn't clearly distinguished, separated, or
established the relationship between broadcast, call-sign and
network-id, and you want something workable. Note use of brackets and
pre-existing conventions.

> I'm not sure either belongs in this section, but if one does, they both

And if _that_ gets in, it should probably be mentioned that
'viewing televisions may require a license under local
laws, and automatic tuning using tv: may put the user in violation of
such laws'. (thinking of the UK television license here).

Oh, and that television rots your brain.

and why is the filename url-02 and not uri-02 ?

> -
> 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.

I believe someone was asking who 'Harald' was, too.

L.

cc'd to people not reading this list.

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 19 Aug 1999 04:28:06 +0100 (BST)

L.

---

From: Daniel Senie <[email-masked]>
Date: Wed, 18 Aug 1999 23:58:12 -0400

>Chinese television station? Or accents?

ITU sanctioned callsigns use the English alphabet.

A good table of prefixes for callsigns is located at:

	http://www.itu.int/radioclub/rr/aps42.htm

also see the page:

	http://www.itu.int/radioclub/rr/arts19.htm

especially S19.29. Note that this is not only applicable to Amatuer
Radio stations.

Also see Section III in that document, starting with S19.45, as it gives
the requirements for callsigns. It clearly defines callsigns as
comprised of 26 letters, as well as digits. Accented letters are
specifically excluded.

IF we are talking about callsigns, as sanctioned by the ITU, then we're
specifically concerned with the letters A-Z and digits 0-9. It is my
contention that the draft in question should specifically call out
references to ITU regulation for the specification of callsigns in this
URI scheme.

---

From: Daniel Senie <[email-masked]>
Date: Wed, 18 Aug 1999 23:58:12 -0400

also see the page:

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 19 Aug 1999 05:05:16 +0100 (BST)

This is another good reason why the draft should not attempt to
discuss anything other than local identifiers; understanding of
'callsign' differs widely outside WKRP in Cincinatti.

L.

On Wed, 18 Aug 1999, Daniel Senie wrote:

> Date: Wed, 18 Aug 1999 23:58:12 -0400
> From: Daniel Senie <[email-masked]>
> To: Lloyd Wood <[email-masked]>,
    [email-masked]

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 19 Aug 1999 05:05:16 +0100 (BST)

L.

    [email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Thu, 19 Aug 1999 15:27:13 +1000

"The basic structure of a television URI is: tv: where broadcast is a 
description of the data source. The description can take the form of an 
over-the-air broadcast call sign, or a network identifier. For example: 
tv:wqed the WQED station tv:nbc the NBC network "

It strikes me as incredible that this draft appears to be so wilfully 
ignorant of recent history. Sure its ok to document what people do, but if 
what people do has serious side effects, then those side effects need to be 
documented as well. This document describes a proposal for yet another name 
space on the Internet, and proposes to legacy a name space from just one 
national environment and provide no inherent structure to distinguish one 
legacy namespace from any other, implying that there is no other national 
namespace of media broadcast call signs outside that of the US. Hrumph!

If we are going to legacy other folks' name spaces then it would make only 
basic common sense to include in the Internet namespace the precise origin 
and nameing authority of the namespace administrator. Surprisingly enough 
to some, evidently,the rest of the world outside of the US also has 
television stations, and also surprisingly enough the call signs clash with 
US call signs. If there is to be some concept of using call signs, then 
surely it becomes a hierarchy. In which case the comment in the draft : 
"all hierarchical forms of "tv:" URIs are reserved for future 
specifications. " appears to be just plain silly.

Geoff Huston

---

From: Geoff Huston <[email-masked]>
Date: Thu, 19 Aug 1999 15:27:13 +1000

Geoff Huston

---

From: Garrett Wollman <[email-masked]>
Date: Thu, 19 Aug 1999 11:56:03 -0400 (EDT)

> ITU sanctioned callsigns use the English alphabet.

Of course, this doesn't save `tv:', since most countries outside North
America don't give callsigns to their domestic broadcasters.  (And
neither the US nor Canada use international callsigns for
government-owned stations; in the US they just don't have any, and in
Canada most CBC stations have callsigns assigned from the range
CBA-CBZ, which belongs to Chile.)

The unfortunate fact of life is that the Real World namespace is
broken; if we want to have a standard which doesn't replicate that
brokenness, we will have to introduce Yet Another Registry.

-GAWollman

---

From: Garrett Wollman <[email-masked]>
Date: Thu, 19 Aug 1999 11:56:03 -0400 (EDT)

-GAWollman