Subject: Don't put descriptive info in a URI, only identifying info

From: Dan Connolly <[email-masked]>
Date: Mon, 21 Dec 1998 11:24:20 -0600

In a review of a draft of requirements for a TV URL scheme[1],
I just noticed:
|4.The URI scheme MUST support for OPTIONAL information
|     from which it MUST be possible for a receiver to determine
|     the time period(s) within which the resource can be retrieved
|     from the (also resolved) location. 

This conflicts with a design principle I hold about URIs,
explained in my message to the uri list in Feb 1997[2]:

|If you're talking about "the document XYZ, which has title
|ABC" then then ABC must not be part of the identifier. Because
|you might want a reference ala "the document XYZ, which
|has author Fred" to be recognized as the same resource.
|
|On the other hand, you might refer to a resource using
|a restrictive clause: "the service ZZZ that started in 1996".
|In this case, "the service ZZZ that started in 1995" is a
|distinct resource. So the year is part of the URL.

I started to (a) ask the editors of [1] to
cite the URL scheme guidelines[3], and (b) remove requirement
4 since it conflicts. But [3] doesn't say anything about
[2], so first I'm asking for [3] to reflect [2].

I think [2] provides enough text for the editors to work
with, but if it doesn't, let me know and I'll try to
provide some.

[1] TV Broadcast URI Schemes Requirements 
                       26th November 1998 
Editors: 
     Warner ten Kate <[email-masked]>. 
     Gomar Thomas <[email-masked]>. 
     Craig Finseth <[email-masked]>. 
http://www.w3.org/TV/TVWeb/TVWeb-URI-Requirements-19981126.html

[2] Re: Attributes should only be there if part of the name/address
space
Dan Connolly ([email-masked])
Thu, 20 Feb 1997 10:05:36 -0600 
http://www.acl.lanl.gov/URI/archive/uri-96.messages/0232.html

[3]
Title           : Guidelines for new URL Schemes
Author(s)       : L. Masinter, H. Alvestrand, D. Zigmond, R. Petke
Filename        : draft-ietf-urlreg-guide-04.txt
Pages           : 6
Date            : 16-Nov-98
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urlreg-guide-04.txt

-- 
Dan Connolly
http://www.w3.org/People/Connolly/

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 21 Dec 1998 09:43:15 PST

> [2], so first I'm asking for [3] to reflect [2].
As one of the editors of [3], I wonder if you might be willing
to make a specific suggestion as to what wording should be
included. I agree that the principle is reasonable. If you have
any other additional constraints you think belong in [3], please
send them along too.

---

From: "Michael A. Dolan" <[email-masked]>
Date: Mon, 21 Dec 1998 10:23:00 -0800

Hi Dan-

Long time no talk...

I understand your concern and it is perfectly valid in HTTP/Internet
systems with on-demand servers/proxies, or when the resource is a document
object.

However, referencing other data objects and streaming video/audio content
in a broadcast carousel introduces some unusual circumstances not really
contemplated in traditional HTTP-like document schemes.

I think the TV application deserves some further thought before out of hand
discarding it as not being compliant with general requirements that I
believe did not contemplate this unusual broadcast/multicast system
environment.

The requirements being listed here on this list are very likely to result
in multiple URL schemes, some of which will meet your test, and some of
which may not (for good reason, I believe).  For example, without time as a
specifier, how would one uniquely reference a broadcast program that starts
at 12:00pm, as opposed to one that starts before or after this time on the
otherwise same stream?  There is no discrete object - just a stream where
time is a critical identifier component.

The matter is admittedly cloudier when trying to capture a traditional
document object that is on a broadcast carousel.  However, the problem
remains that the object may only be broadcast from 1:00-1:01 am and at no
other times.  The capture time could (and perhaps should) be specified out
of band, but omitting it from the general requirements may not be the right
way to tackle the issue this early in the definition process.

It would be my recommentation that the (time) addressing requirement
remain.  In the resulting URL schemes, where they reference documents, then
the URL guidelines should definitely be followed wherever applicable, and
if timing information is required, then out of band definitions should be
strongly considered.

Completely eliminating the timing requirement will break the resulting
overall designs.

Regards,
	Mike

>ftp://ftp.ietf.org/internet-drafts/draft-ietf-urlreg-guide-04.txt
---------------------------------------------------------------------------
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   FAX: (619)445-6122
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901

---

From: Warner ten Kate <[email-masked]>
Date: Mon, 21 Dec 1998 19:46:33 +0100

> |distinct resource. So the year is part of the URL.

Thanks for pointing to this.

Do I understand you correctly, that the first example URL
is wrong and the second example is right ?

In our model of a TV Broadcast stream we assume that the
content is scheduled by the service provider and the user
has no influence on that. The user accesses the stream(s) 
rather than the server at the uplink station.

For this discussion, there are two types of resources:
- TV channel
- TV program
A TV channel is the concatenation of TV programs. For 
example, "BBC-1" is a TV channel and "8 o'clock news"
is a TV program.

What does your comment imply when I want to express the 
location of the 8 o'clock news ?

- Is 8 o'clock news a further characteristic of BBC-1 (case 1)?
  It means TV programs should not be considered a resource ?
- Is 8 o'clock news a restrictive clause on BBC-1 (case 2)?
  It means temporal availability is allowed as part of the URL.

> cite the URL scheme guidelines[3], and 

Will do.

> (b) remove requirement 4 since it conflicts. 

This has probably to do with the model above.
Do you have a suggestion how to deal with this ?
Should we adapt another model ? 

Warner.

--
Philips Research Labs. WY21 ++ New Media Systems & Applications
Prof. Holstlaan 4 ++ 5656 AA  Eindhoven ++ The Netherlands
Phone: +31 4027 44830
Fax:   +31 4027 44648    [email-masked]

---

From: Dan Connolly <[email-masked]>
Date: Mon, 21 Dec 1998 13:12:58 -0600

I don't mean to argue against time specifiers in URIs.

Perhaps I just misread the sense of "OPTIONAL."
If you mean optional in the syntax (sometimes it appears,
sometimes it doesn't) then I have no problem. But
if it's optional in the sense that even when it
appears, you don't need it
to identify the referent, then I object.

Michael A. Dolan wrote:
> 
>   For example, without time as a

If "time is a critical identifier component" then very well,

> >|distinct resource. So the year is part of the URL.

Warner writes:

|Do I understand you correctly, that the first example URL
|is wrong and the second example is right ?

No; there's a "right" URI in each case; in the 1st case,
the URI doesn't contain title=ABC; in the 2nd case,
the URI does contain year=1996.

---

From: Gomer Thomas <[email-masked]>
Date: Mon, 21 Dec 1998 14:25:46 -0500

Dan,

My own interpretation of this requirement is that the "location" of a
resource in a TV broadcast environment very often has a time dimension
as well as a network address dimension.

I believe that in most, if not all cases, the time dimension will be
specified by identifying the "event" (TV program, in ordinary
terminology), with perhaps in some cases an offset relative to the start
of the event, rather than by explicitly specifying a clock time.

Gomer Thomas

--
Gomer Thomas
LGERCA, Inc.
40 Washington Road
Princeton Junction, NJ 08550
phone: 609-716-3513
fax: 609-716-3503

---

From: "Michael A. Dolan" <[email-masked]>
Date: Mon, 21 Dec 1998 11:55:34 -0800

Dan-

Understood.  Your point is important and very reasonable.  As we proceed on
the URI design(s), we should definitely adhere to this rule.  The time we
are referring to is not authoring time, but broadcast time, which in
general is a very transient property.

There is no analogy using standard http servers except in the multicast
model.  Is there relevant work that you know of in multicast proxy/server
designs that might apply here?

Thanks,
	Mike

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

---

From: "Michael A. Dolan" <[email-masked]>
Date: Mon, 21 Dec 1998 11:54:48 -0800

Gomer/Dan-

>as well as a network address dimension.

True (but in different ways) for both V/A stream content, as well as
discrete documents broadcast on a carousel.  These items may, in the end,
be referenced using different URI schemes, for which different rules for
specifying time may be appropriate.

>of the event, rather than by explicitly specifying a clock time.

This is one way to do it that is more object-oriented and fits the object
model much better.  However, there is not agreement on the list that this
is the (only) possible or useful solution.  There are other possible URI
designs that do not directly reference an EPG object, and thus might need
absolute (GMT) time.

	Mike

---

From: "Craig A. Finseth" <[email-masked]>
Date: Mon, 21 Dec 1998 14:20:32 -0600 (CST)

> >|distinct resource. So the year is part of the URL.

Actually, the conclusion is not supported by the data.

The requirement appears to be that I can _somehow_ refer to "the
service ZZZ that started in 1995" as different from "the service ZZZ
that started in 1996".  There is no requirement that the year as such
be included in the UR* so long as there are other ways that one can
distinguish them.

	...

The same argument that a URI can't contain "title=ABC" serves
to deny that a URI include "year=1996".

Craig

---

From: "Craig A. Finseth" <[email-masked]>
Date: Mon, 21 Dec 1998 14:26:08 -0600 (CST)

...

Umm, you just proved the opposite of your point.

We all agree (I believe) that there is a requirement to designate
time-related content on a channel (e.g., an event).

The open question is whether that requirement may _only_ be met
by putting time-related information in the URI itself.

You agree that there are valid schemes that meet the requirement
without such encoding.  That indicates that the encoding is not itself
part of the requirement.  (The fact that one can devise schemes that use
the encoding is not relevant to the question.)

Craig

---

From: "Michael A. Dolan" <[email-masked]>
Date: Mon, 21 Dec 1998 14:15:21 -0800

At 02:26 PM 12/21/98 -0600, Craig A. Finseth wrote:
>time-related content on a channel

yes.

>(e.g., an event).

Not if you literally mean an event in EPG terms.  This implies a solution
limited to existing EPG event data only, which I do not agree with.

>by putting time-related information in the URI itself.

It is not that simple.  Specifying time (or not) in a scheme is not the
only design criteria.

>without such encoding.

Syntactically "valid", yes.  The best design - not necessarily.

>That indicates that the encoding is not itself

There are always multiple solutions to a problem.  I am not advocating
multiple concurrent schemes to do the same thing, nor am I in any way
advocating that eliminating time encoding is the utmost design goal in
meeting the URI requirements.  There may be other reasons for needing a
time-based approach that outweigh a general desire to avoid it.  In the
end, we must consider all reasonable solutions, of which there will be
compromises, including possibly desires to eliminate time in the URI(s).

	Mike

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 21 Dec 1998 23:12:36 -0800

>contemplated in traditional HTTP-like document schemes.

No, it doesn't.  Figure out what the resource is and then define a
naming scheme for that resource.  If the resource is a time segment on
a particular broadcast, then it should have an identifier that indicates
the broadcast channel and time segment.  If, however, the resource is
something less broadcast dependent, such as "Buffy the Vampire Slayer,
episode 24", then it shouldn't have a channel and time segment.
Whatever you do, never mix these two paradigms -- there is no reason
why a streaming video/audio content cannot have more than one URI,
so it is always better to use multiple references rather than try to
over-identify something within a single URI.

There is no difference here between HTTP and broadcast, other than the
fact that the 'http' URL contains a hostname.  The philosophical properties
of naming are the same.

....Roy

---

From: "Michael A. Dolan" <[email-masked]>
Date: Tue, 22 Dec 1998 08:33:33 -0800

>episode 24", then it shouldn't have a channel and time segment.

We agree.

>over-identify something within a single URI.

We agree again.

>fact that the 'http' URL contains a hostname.  The philosophical properties

Here is where we may diverge somewhat.  Taking the example of a broadcast
HTML document, the problem is in fully specifying it's "location".  For
example, let's say this document will be part of a broadcast stream and it
is known in advance that it will be sent at 1:00am tonight on some stream,
and at no other time and no other stream.

Is it appropriate to put this broadcast time (and stream specifics) in the
URL?  Or, should the URL simply be an opaque pointer to the object, and
broadcast time (and stream specifics) be communicated to the recipient by
some other means?  The former would permit, with only the URL, to locate
and acquire the object (albeit somewhat delayed in delivery).  The latter
case would *require* that a document cache be maintained (which is useful
anyway for other purposes) and it would either get a cache hit or not at
any given point in time - no acquisition could occur with the URL alone,
and no feeback to the user could be provided saying that "I don't have it
now, but I will at 1:01am".

Thoughts on this?  I personally think both will prove useful, but the
problem suggests that URL's in broadcast systems might take on another
dimension to specify a "location" that is not relevant in non-broadcast
systems.

Are you aware of any previous work in the area of multicast proxies and
URL's?  How about generally locating objects in streaming (Internet push)
content that might apply?

Thanks,
	Mike

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 22 Dec 1998 15:45:37 PST

Think of the 'news' URL scheme, and our (unsuccessful) attempt to
separate out 'news' and 'nntp'. We wound up with one scheme which
was used for identifying a variety of types of resources:
A stream of information (like a channel):

   'news:comp.infosystems.www'

A particular message (like an event):

   'news:[email-masked]'

In addition, the 'news' scheme was used for NTTP:

    news://news.parc.xerox.com/comp.infosystems.www.announce

(news.parc.xerox.com is a Xerox-internal nntp server.)

There were other elements of the news stream for which there
are no URLs, even though URLs would be 'useful', e.g., 
'a conversational thread'.

So it's not as if we have no experience with other kinds of
'streaming broadcast' material in the URL space. It's not clear
that the 'news' URL scheme is a wonderful example that must
be followed, but it's at least prior art.

In the netnews space, at least, articles have unique IDs that
allow them to be identified independently of the stream in 
which they are broadcast. That isn't the case for most of TV
today (is it?) so you may need more designators, but don't try
to pack an arbitrarily complex expression into the locator.
The scenarios will help figure out what's truely useful.

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

---

From: "Michael A. Dolan" <[email-masked]>
Date: Tue, 22 Dec 1998 16:50:54 -0800

At 03:45 PM 12/22/98 PST, Larry Masinter wrote:
>separate out 'news' and 'nntp'...
>
>...So it's not as if we have no experience with other kinds of
>'streaming broadcast' material in the URL space.

I personally value greatly your, Roy and Dan's thoughts in this space.  I
trust everyone else does as well.  I only hope that this list keeps your
attention, as we will all benefit from your input.

But, I'm not sure too many of the TV scenarios map into news: all that
well.  In the case where there is a stream of discrete objects with tagged
ID's not found anywhere else, it is at least a better analogy.  One
difference though is that news has no concept of broadcast time - the
messages arrive synchronously on request from a recipient.  One can
"locate" a news item by querying the news server on demand.  The news
servers themselves are synchronous distribution systems - not exactly
broadcast in any part of it, including the recipient using the URL.

Broadcast systems (TV) are highly driven in the temporal space.  One cannot
request an object without puting a caching gateway in-between the recipient
and the broadcast.

>today (is it?)

In no existing transport today are programs identifiable in a globally
unique manner.  When they are tagged at all, they are done so in a
transport-specific way.  Ditto for even just channels.  So, the tv: URL
problem is plagued first and foremost by a lack of a good namespace(s) to
work with.  Hence, solving the namespace problem is high on the design list.

Some people have proposed tagging everything of interest with opaque (URI)
identifiers.  Others propose schemes that are transport specific (DAVIC/DVB
for example).  Neither is a great solution (at least in my opinion).

>so you may need more designators, but don't try

Roger.

	Mike

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 22 Dec 1998 17:30:15 -0800

>and at no other time and no other stream.

You can either identify the resource that is represented by the document
or you can identify the resource that is a period on a broadcast stream.
Those are two different resources, even when they map to the same
representation.  Honestly, there is zero difference between allocating
the TV namespace and allocating the HTTP namespace after the hostname --
they both identify resources without any real bound on the scope of
resources that might be identified.

>now, but I will at 1:01am".

You want both, but not in the same URL.  Even if you use strict name-based
(not necessarily opaque) semantics for one URI, you will still need some
other form of identifier(s) for identifying the set of broadcast streams.
The key point that Dan was arguing is that you don't want to put all of
it in a single URI, since the URI should only contain the identification
part and not general information about the resource.

....Roy