On Jun 9, 2009, at 5:17 PM, David Singer wrote:

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

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.

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

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

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

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