Subject: Re: iPhone streaming Internet-Draft posted

From: Roger Pantos <[email-masked]>
Date: Sun, 2 Aug 2009 12:45:39 -0700

On May 4, 2009, at 5:21 PM, Mark Nottingham wrote:
> I had a quick look over this. My impression was that the  
> relationship to HTTP is pretty tangental; i.e., you may only intend  
> to use this over HTTP, but there's not much (anything?) HTTP- 
> specific about it.
>
> As such, it may be better to position this as a format description  
> (or indeed a description of an extension to an existing format),  
> rather than something HTTP-specific. E.g., a good name might be  
> 'Live Streaming Extensions for the M3U Playlist Format.'

Hello Mark. Sorry it took so long to get back to you on this.

The reason we published the draft was to encourage the production of  
interoperable implementations. Similarly, we restrict our protocol to  
HTTP because more generality makes it too difficult to guarantee  
interoperability.

Because of this we believe that it is important that HTTP appear in  
the title of the draft. But I agree that we should avoid the  
appearance of endorsement by the HTTP standards bodies, so it makes  
sense to consider a different title.

How about live-media-streaming-over-http?

Roger.

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 2 Aug 2009 22:55:47 +0200 (CEST)

On Sun, 2 Aug 2009, Roger Pantos wrote:

> Similarly, we restrict our protocol to HTTP because more generality makes it 
> too difficult to guarantee interoperability.

Your restricting of access to your data only to HTTP doesn't make your 
protocol any more HTTP (-like). The restriction to HTTP-only is rather 
artificial and any implementer of this protocol would easily be able to expand 
it to other application protocols (like for example FTP), couldn't they? Or 
perhaps that new funky protocol we'll invent two years into the future.

In fact, I think the proposal would benefit from loosening its fixation to 
HTTP.

> Because of this we believe that it is important that HTTP appear in the title 
> of the draft.

I disagree. I think HTTP in the title would imply that the protocol has 
something to do with HTTP, while this hasn't. This only describes a data 
format basicly, with embedded URIs.

> How about live-media-streaming-over-http?

How about live-media-streaming-playlist-format ?

-- 

  / daniel.haxx.se

---

From: David Singer <[email-masked]>
Date: Sun, 2 Aug 2009 14:48:26 -0700

At 22:55  +0200 2/08/09, Daniel Stenberg wrote:
>>Similarly, we restrict our protocol to HTTP because more generality 
>>makes it too difficult to guarantee interoperability.
>
>Your restricting of access to your data only to HTTP doesn't make 
>your protocol any more HTTP (-like). The restriction to HTTP-only is 
>rather artificial and any implementer of this protocol would easily 
>be able to expand it to other application protocols (like for 
>example FTP), couldn't they? Or perhaps that new funky protocol 
>we'll invent two years into the future.
>
>In fact, I think the proposal would benefit from loosening its 
>fixation to HTTP.

Hm.  I don't know how to do that while still making it clear that the 
only transport the client is required to be able to parse and use is 
HTTP.  Do you?

-- 
David Singer
Multimedia Standards, Apple Inc.

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 3 Aug 2009 08:53:50 +0200 (CEST)

On Sun, 2 Aug 2009, David Singer wrote:

> Hm.  I don't know how to do that while still making it clear that the only 
> transport the client is required to be able to parse and use is HTTP.  Do 
> you?

First, it also mentions HTTPS so that makes it two different protocols URI 
wise at least.

The protocol _could_ say something like HTTP and HTTPS MUST be supported by 
the client, but that it MAY support other protocols. That would at least not 
close the door for other protocols to get used at some point without them 
violating the spec.

But really, I'm mostly speaking with my HTTP hat on here and this spec has 
very little to do with HTTP and I think I'd better rest my case about the 
rest.

-- 

  / daniel.haxx.se

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 3 Aug 2009 14:45:18 -0700

Thanks for the reply.

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.

Cheers,

On 02/08/2009, at 12:45 PM, Roger Pantos wrote:
> interoperable implementations. Similarly, we restrict our protocol  
> to HTTP because more generality makes it too difficult to guarantee  
> interoperability.
>

--
Mark Nottingham     http://www.mnot.net/