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

Re: iPhone streaming Internet-Draft posted

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 4 Aug 2009 16:04:22 -0700
Cc: "Travis W. Brown" <travis@apple.com>, Steve Sinclair <steve.sinclair@apple.com>, http-live-streaming-review <http-live-streaming-review@group.apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <67668CBD-8648-46BF-A7C1-97A7E47094DC@mnot.net>
To: David Singer <singer@apple.com>
On 04/08/2009, at 3:19 PM, David Singer wrote:

> On Aug 3, 2009, at 2:45 PM, Mark Nottingham wrote:
>> FWIW, I agree with Daniel on this one; there are lots of good  
>> reasons to purposefully separate the format and the protocol. If  
>> you need to specify a combination to use with your software, it's  
>> normal practice to say that in the documentation.
>>
>> That's not to say that it wouldn't be appropriate to have a section  
>> or appendix on using the format with HTTP, of course.
>
> Almost every RFC that specifies a network protocol also specifies a  
> data format. RFC 2616, for instance, specifies HTTP headers.

You seem to be asserting that because protocols define data  
structures, there's no reason for layering between protocol metadata  
and payload. If that's the case, I'm not sure I can say much that'd be  
productive at this point.

> Although the draft specifies the m3u8 playlist format, its primary  
> purpose is to describe a protocol by which a client may obtain a  
> continuous stream of media from an HTTP server.


I think that at best, this note isn't defining a protocol in any  
useful sense from an IETF or standards perspective; it's more of an  
applicability note that points out how you can use an existing  
protocol, existing format and a few new extensions to that format to  
achieve a particular effect. If you couch it in such terms, I imagine  
that you'd be able to avoid this kind of confusion.

Cheers,

--
Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 4 August 2009 23:05:00 GMT

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