Subject: Re: [AVT] I-D Action:draft-pantos-http-live-streaming-01.txt

From: David Singer <[email-masked]>
Date: Tue, 9 Jun 2009 08:17:40 -0700

At 13:57  +0200 9/06/09, Roy T. Fielding wrote:
>
>I find this draft to be quite annoying.  It doesn't have anything
>to do with HTTP or live, or really even streaming -- the title is
>just from the marketing term that Apple has chosen to describe this
>concept in general.
>
>What the draft defines is a set of media type extensions to the
>unregistered "audio/x-mpegurl" media type (M3U Playlist format)
>that provide additional information for an indirect request of a
>stream via sequential requests on the listed URIs.  While I think
>that might be a fine idea, it should start by registering the
>media type being extended, and the title/introduction should reflect
>what the document defines so that the right people will review it
>prior to publication.  I don't like it when the IETF is abused
>for marketing purposes.

Roy, I'm sorry that is what you feel we are doing.  We thought we 
were trying to be as open as possible by providing this for 
information and criticism.  We're not trying to standardize it.  I 
don't think we 'own' the MIME type, so even though it's a concern 
it's unregistered, it's not clear it's for us to fix, is it?

The draft covers the delivery of live multimedia information which 
can be essentially indefinite in duration - a stream in common 
parlance - using HTTP.  Given that the content is live and it's an 
indefinite stream being delivered, and we use HTTP, I don't think the 
title is very far off base, if at all.

There have been glimpses of a general debate over how to deliver 
multimedia, here in the AVT list.  There are the upcoming MPEG and 
DVB workshops, where that debate will also continue.  We're not the 
only ones to have tried the 'proper' protocols and found that, after 
many years, there are infrastructure problems with them.  We even 
open-source a streaming server, and (at one point at least) had 
sample code for a proxy, iirc, to try to help them along.
-- 
David Singer
Multimedia Standards, Apple Inc.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 9 Jun 2009 18:10:05 +0200

> it's unregistered, it's not clear it's for us to fix, is it?

If you aren't trying to standardize it (at least a little), then why
isn't this just a page on the Apple site?  Presumably you want other
organizations to be able to produce interoperable M3U playlists, which
seems to be a perfectly good reason to publish a document here.  What
doesn't make any sense is the use of the Apple marketing phrase as
the title, because that phrase does not describe what is being defined.
It has the effect of claiming ownership on a broad use of HTTP,
for which the IETF is the standards caretaker, rather than simply
describing the stuff being engineered.

Somebody should register the media type or invent a new media type
that includes your suggested extensions.  It does not have to be the
owner of the data format.  That is why we have an Internet media type
registry which simply requires a template be inserted in an RFC for
this kind of (non-vendor) type.  It therefore makes sense for you to
include a media type registration as part of this document even if the
draft is only being submitted for publication as an Informational
(not standards-track) RFC.

> indefinite stream being delivered, and we use HTTP, I don't think  
> the title is very far off base, if at all.

The draft covers the data format for a document that might be retrieved
from any source (filesystem, HTTP, FTP, etc.) and which contains a list
of URIs for obtaining the individual data segments that make up the
"stream", said URIs being of whatever schemes the provider thinks is
most appropriate.  It is not limited by HTTP at all.  There are no
changes required of HTTP.  There are no extensions to HTTP.  Thus,
when the HTTP experts go to review it thinking it might be applicable
to their expertise, the result is "WTF?".  AFAICT, the content isn't
required to be "live" either -- it could be playing an old movie.

Just to be clear, I am not objecting to the design at all.  I do not
want you to make the specification dependent on HTTP -- that would
be silly given the orthogonal nature of URIs.  I just see no reason
for HTTP to appear in the title and abstract.  What it should say is
that the document defines a format for describing a sequence of Web
resources for delivery of their individual representations as a
logical stream of data.  The title should be something like
"MPEG3 URI Playlist media type for sequenced data streams".

> only ones to have tried the 'proper' protocols and found that,  
> after many years, there are infrastructure problems with them.  We  
> even open-source a streaming server, and (at one point at least)  
> had sample code for a proxy, iirc, to try to help them along.

That's all great.  But when you submit a specification to the IETF,
it should be titled/described according to what the spec defines
so that the right people will know to review it.

....Roy

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 25 Jun 2009 03:56:51 -0700

I am pleased that Apple submitted this document as an Internet Draft. 
While I feel that much of the subsequent criticism has been 
excessively harsh (or in some cases, misguided), I do agree with the 
criticism that the document's title could be more descriptive.  The 
current title - "HTTP Live Streaming" - suggests that it is a broad, 
architectural overview document, which this really isn't.  A more 
meaningful title for this document might be something like
	"Using URI Playlist Files to Simulate Live Streaming"

Nonetheless, if this approach is seen as being useful, then I would 
like to see the IETF adopting and standardizing it (or something 
similar), because both media streaming and transport protocols 
(including HTTP/TCP - the transport protocol most commonly specified 
within URIs) are clearly within the IETF's arena.

However, this document focuses attention on a much bigger issue - a 
proverbial "elephant in the room" - that at some point the IETF in 
general, and the MMUSIC and AVT working groups in particular, are 
going to have to address:

Thanks to the ever increasing abundance of cheap mass storage, we are 
now in a world where media consumption is increasingly 'on demand' - 
e.g, via DVRs or online services like YouTube - rather than live.  It 
seems inevitable that on-demand media playback will dominate, with 
live media being relegated to relatively minor niches where 
timeliness remains essential.

Given this, we have to ask ourselves whether there is going to 
continue to be a practical role for specialized protocols for live 
media, or whether we will see more and more of the live media niches 
being satisfied by hacks (like the one described by this draft) that 
can make use of the increasingly dominant infrastructure that will 
already be in place for on-demand media?  Telephony currently remains 
a refuge for live media protocols, but how much beyond this in the 
future?  (There are even companies out there now that are providing 
videoconferencing over HTTP, within users' web browsers!)

I believe that, at the very least, the IETF should try to be more 
pragmatic about this (even if it means sometimes tarnishing 
architectural purity).  To give just one specific example, I'm 
disappointed that the IETF did not adopt and standardize Apple's 
earlier mechanism (developed several years ago) for tunneling 
RTSP/RTP over HTTP.  But given the points that I note above, I think 
we're going to have to think hard about the future of RTSP in 
general...