W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: iPhone streaming Internet-Draft posted

From: Roger Pantos <rpantos@apple.com>
Date: Thu, 6 Aug 2009 16:49:25 -0700
Cc: http-live-streaming-review <http-live-streaming-review@group.apple.com>, Travis Brown <travis@apple.com>, Steve Sinclair <steve.sinclair@apple.com>, Stuart Cheshire <cheshire@apple.com>
Message-Id: <1BBAECC2-555D-4CD0-9669-297AC3FA021F@apple.com>
To: HTTP Working Group <ietf-http-wg@w3.org>

On Aug 6, 2009, at 11:30 AM, Roy T. Fielding wrote:
> On Aug 5, 2009, at 10:05 AM, David Singer wrote:
>> At 16:09  -0700 4/08/09, Roy T. Fielding wrote:
>>> 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.
>>
>> OK, it is a transfer protocol; and this draft layers on it.
>
> 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.


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.
Received on Thursday, 6 August 2009 23:50:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:08 GMT