- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 4 Aug 2009 16:04:22 -0700
- To: David Singer <singer@apple.com>
- 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>
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 UTC