Subject: RE: IETF tree URL registration procedure incomplete

From: Dan Zigmond <[email-masked]>
Date: Wed, 25 Aug 1999 16:14:32 -0700

> ...but the
> IESG might review the use of 'tv:abc' to reference the US broadcast
> stream.

I know Larry's email isn't attempting to provide a thorough summary of our
"tv:" draft, but I feel that there's a misconception here that our draft
somehow gives American broadcasters unfair rights in the "tv:" namespace.
This is not the case.  What the draft actually says in section 3.3 on
network identifiers is: 

   "The current practice is simply to
   compare network identifiers against a list of those known to be
   available on the receiver." 

In other words, in the US "tv:abc" is likely to tune you to the local
affiliate of the American Broadcasting Company, while on a receiver in
Australia "tv:abc" will take you to the Australian Broadcast Corporation.
The only registrar in this draft is the receiver itself, so it's local
rather than global.

Granted, this behavior is exactly what some people object to in the draft.
But that's not the same as (and, in fact, it's exactly the opposite of)
somehow rewarding the global identifier "tv:abc" to the entity that happens
to use the "ABC" abbreviation in the US.

	Dan

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

-----Original Message-----
From: Larry Masinter [mailto:[email-masked]]
Sent: Wednesday, August 25, 1999 3:31 PM
To: Michael A. Dolan
Cc: [email-masked]
Subject: RE: IETF tree URL registration procedure incomplete

I thought the general idea for allowing "Informational" documents
to describe IETF tree URLs is that the IESG might approve of
the URL as a naming mechanism, even if the thing named were not
itself Standards track. The technical review of "aol:" would not
review the AOL service or its use of keywords, but would review
the use of the 'aol' URL scheme against URL guidelines.

In this case, IESG would not review how televisions were tuned
and whether PIP and 'channel return' were useful concepts, but the
IESG might review the use of 'tv:abc' to reference the US broadcast
stream.

I believe we've meant this in discussions, as evidenced from
the discussion on this topic over the last 5 years, but it hasn't
made its way into the documents; this is something that needs
to be corrected.

In general, when an Informational RFC calls for some kind
of action on the part of IANA, there is necessarily a review
according to the rules of the IANA space being modified.
Perhaps we don't need to make a specific exception to RFC 2026.

We probably will need to deal with dispute resolution as well,
if, say, some Big Web Site Owner wants to define some alternative
meaning for 'aol:' or use it to define links with their own
referents.

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

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 25 Aug 1999 17:01:33 PDT

> to use the "ABC" abbreviation in the US.

But there's a difference between the situation with 'news:' (where
there really is a global name space of netnews groups), and 'file:'
(where the reference is in practice always to some local resource),
and relative URLs (where the sender has some way of setting or
inferring what the BASE is for the relative URL provided.)

In the case of 'tv:abc' in any kind of Internet content, the
sender has no way of knowing anything about the receiver's mapping
of network identifiers to channels. In this case (unlike all of
the other cases), it's likely that those with the most content
(US content providers) will provide links which *they* intend
to refer to mainly US network identifiers. The result will be
that most TV URLs that are authored with a station identifier will
use 'tv:abc' to refer to the American Broadcasting Company, and
those who have a mapping to the Australian Broadcast Corporation
will just be out of luck. The Australian receiver's will wind up
adapting (after all, they wanted to watch "Dallas", too, if that's
what the link *meant*), and the result will be that 'tv:abc' will
evolve to mean the primary meaning.

I don't think that draft-ietf-urlreg-guide-05.txt currently
does a good job of layout out this guideline, and I propose
adding some text to it to capture some requirement for
'uniform interpretation': does the URL designate the same
'resource' no matter where and who is interpreting it. We
might want to acknowledge that some schemes don't do this,
and they suffer because of it.

Larry

---

From: "Michael A. Dolan" <[email-masked]>
Date: Wed, 25 Aug 1999 17:49:26 -0700

Larry-

Your points are well-taken.   But...

Where it *does* work is when the page with the tv: reference in it 
will be broadcast and not available on a globally accessible web 
server.  It thus implicitly contains the context of the channel on 
which it is broadcast, which is a local context to the receiver.  So, 
when watching the Disney channel, Disney will be able to put "tv:abc" 
in one of the broadcast web pages, and the tune event that that URI 
permits will in fact do the "right" thing.  It is in fact good that 
it is somewhat non-specific (and perhaps thus not a URL).  In 
contrast, they can't put in tv:7 at the studio, since it would surely 
do the wrong thing more than 50% of the time, since ABC is not always 
on channel 7.

We've had this discussion before, and I'm not sure Dan and Mark would 
agree with me, but in my view, for network feeds it is a URN.  The 
resolution to a specific transport and channel occurs within the 
receiver.  "abc" is translated locally to a transport (DIRECTV or 
NTSC for example) and channel to the best (or possibly multiple) ABC 
network feeds which is OK.  The receiver knows how to do this.

Disney feeds sent to Australia would not contain "tv:abc" (unless of 
course they meant to get the Australian Broadcasting Company).

And, within intranets, or any locally scoped network where the TV 
space is well known, you can in fact put "click here tv:7 to see the 
president's speech" and it too will do the right thing.

So, we'll try to document all these better, which is I think your 
main point.

	Mike

But yep, you put tv:7 on a global web server

>and they suffer because of it.

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

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 25 Aug 1999 18:18:19 PDT

> permits will in fact do the "right" thing. 

Are you saying that no one in Australia can ever watch the Disney
channel? If the 'right' thing is to tune to the American Broadcast
Company channel?

> It is in fact good that 

And the American Broadcast Company is not always on 'tv:abc'.

> agree with me, but in my view, for network feeds it is a URN. 

Let's not go there.

> The 

So there's more than one Disney channel? You mean that every channel
has to be specifically tied to the entire set of channels that are
available at the local receiver? 

> But yep, you put tv:7 on a global web server

Name one.