- From: Roger Pantos <rpantos@apple.com>
- Date: Thu, 6 Aug 2009 16:49:25 -0700
- To: HTTP Working Group <ietf-http-wg@w3.org>
- 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>
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 UTC