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

[Ross Finlayson <finlayson at live555.com>]

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