Re: iPhone streaming Internet-Draft posted

Two more questions:

1) Can you speak to why you chose to do this by extending m3u, rather  
than using HTTP's built-in partial content mechanism (ranges)?

While you'd need to specify some metadata (e.g., headers to describe  
where alternate encodings/bitrates can be found), this would be easy  
to do, and would have the advantage of not requiring the server to  
split up the file into multiple chunks at different URIs (an  
administration and operations headache).

The analogy that comes immediately to mind is PDFs; the approach  
you're taking is roughly equivalent to Adobe saying that PDF files  
should be split into a URI-per-page and then putting an index file on  
the site to link to each page.

2) Apple has disclosed IPR <>  
for this draft.

My layman's reading is that anyone who wants to host a stream using  
this technique requires a written license from you, including the  
possibility of paying a fee, once your patents are granted.

Is there anything else we should know about this? As it is, (and only  
speaking as an implementer), this just gives me more motivation to use  
other techniques.


On 02/05/2009, at 6:36 AM, Roger Pantos wrote:

> My apologies if this is a bit off-topic. I just posted the following
> Internet-Draft:
>   This document describes a protocol for transmitting unbounded  
> streams
>   of multimedia data over HTTP.  It specifies the data format of the
>   files and the actions to be taken by the server (sender) and the
>   clients (receivers) of the streams.  It describes version 1.0 of  
> this
>   protocol.
> The folks on this list have a great deal of expertise on HTTP and  
> specifications
> in general. I would appreciate your feedback on the document, and  
> the protocol
> itself.
> thank you,
> Roger Pantos
> Apple, Inc.

Mark Nottingham

Received on Thursday, 16 July 2009 06:01:04 UTC