Subject: Re: iPhone streaming Internet-Draft posted

From: David Singer <[email-masked]>
Date: Tue, 4 Aug 2009 15:15:16 -0700

On Aug 2, 2009, at 11:53 PM, Daniel Stenberg wrote:
>On Sun, 2 Aug 2009, David Singer wrote:
>>>In fact, I think the proposal would benefit from loosening its 
>>>fixation to HTTP.
>>
>>Hm.  I don't know how to do that while still making it clear that 
>>the only transport the client is required to be able to parse and 
>>use is HTTP.  Do you?
>
>First, it also mentions HTTPS so that makes it two different 
>protocols URI wise at least.
>
>The protocol _could_ say something like HTTP and HTTPS MUST be 
>supported by the client, but that it MAY support other protocols. 
>That would at least not close the door for other protocols to get 
>used at some point without them violating the spec.

The goal of the draft is to produce interoperable implementations. We 
wish to keep it focused on a single transport: HTTP.

>But really, I'm mostly speaking with my HTTP hat on here and this 
>spec has very little to do with HTTP and I think I'd better rest my 
>case about the rest.

We believe that the title live-media-streaming-over-http removes any 
impression that it is an extension of the HTTP standard.

-- 
David Singer
Multimedia Standards, Apple Inc.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 4 Aug 2009 16:09:05 -0700

On Aug 4, 2009, at 3:15 PM, David Singer wrote:
> The goal of the draft is to produce interoperable implementations.  
> We wish to keep it focused on a single transport: HTTP.

HTTP is not a transport.

>> spec has very little to do with HTTP and I think I'd better rest  
>> my case about the rest.
>
> We believe that the title live-media-streaming-over-http removes  
> any impression that it is an extension of the HTTP standard.

Not as well as the title: Dynamic Playlist Format for Live Media  
Streaming

....Roy

---

From: David Singer <[email-masked]>
Date: Wed, 5 Aug 2009 10:05:49 -0700

>>We wish to keep it focused on a single transport: HTTP.

OK, it is a transfer protocol; and this draft layers on it.

>Not as well as the title: Dynamic Playlist Format for Live Media Streaming
>
>....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 6 Aug 2009 11:30:17 -0700

On Aug 5, 2009, at 10:05 AM, David Singer wrote:

>>> The goal of the draft is to produce interoperable  
>>> implementations. We wish to keep it focused on a single  
>>> transport: HTTP.
>>
>> HTTP is not a transport.
>

No, it just uses it.  User agents and media types are not
another layer -- they are simply using the protocol to transfer
messages.

I don't understand why you are insisting on this marketing crap.
Just describe the media type and its meaning as the contents
change over time.  Which protocol is used to transfer those
contents is completely orthogonal and we need to insist on
the orthogonality principle being obeyed if we are to avoid
being drowned by over-specification.

....Roy

---

From: Roger Pantos <[email-masked]>
Date: Thu, 6 Aug 2009 16:49:25 -0700

> being drowned by over-specification.

I've seen a few people echo the misconception that the draft merely  
specifies a data format instead of a protocol, so I think we need to  
clear that up.

When you have a set of actions that two parties must take together to  
achieve a particular effect, you have a protocol. When this happens  
over the network, you have a network protocol.

The draft specifies actions that a server must take - which are over  
and above those that it must take to comply with the HTTP standard -  
and a set of actions that a client must take - which are also over and  
above the HTTP standard - in order to produce and consume a continuous  
stream of media.

Server actions include making content available in a specific form at  
a specific time in a specific sequence, and keeping it available for a  
specific time. Client actions include discovering that content is  
available, checking for new content at specific times, what to do if  
none is found, and when it should assume that found content is no  
longer available. Following the specifications of these actions is  
critical. If they are not followed the server and client will not  
interoperate.

The fact that the draft also defines a playlist format is a secondary,  
though necessary, detail.

Roger.

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 7 Aug 2009 09:53:21 +0100

> critical. If they are not followed the server and client will not  

What part of that cannot be done in the same way over FTP, SCP, NFS,
or any other protocol for serving files which supports the essential
features, namely range requests?

In other words, in what way does it depend on HTTP, other than the
fact it runs over HTTP because the specification says it must?

-- Jamie