Subject: Re: iPhone streaming Internet-Draft posted

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

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.

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.

-- 
David Singer
Multimedia Standards, Apple Inc.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 4 Aug 2009 16:04:22 -0700

On 04/08/2009, at 3:19 PM, David Singer wrote:

>> 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.
>>

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.

> 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/