This is with regard to the draft at
http://tools.ietf.org/html/draft-pantos-http-live-streaming-02 and
discussed on this list
(http://www.ietf.org/mail-archive/web/mmusic/current/maillist.html)
under the subject "Comments on draft-pantos-http-live-streaming."

I agree with this comment by Rémi Denis-Courmont of VideoLan:
===
* I don't understand how the receiver (the client) of the playlist can
_reliably_ distinguish a plain old playlist file from a live streaming file.
M3U URLs are already in common use to deliver "real" playlist, and the
semantics are significantly different from what your draft does. If none ofthe
new parameters you introduce are mandatory, this protocol is basically
impossible to implement in a way that does not break existing functionality in
many media players.
===

David Singer replied that "Players can use the presence of the
EXT-X-TARGETDURATION tag to determine whether the playlist file
follows the rules of the draft."

However, that is only true for players that are retrofitted to use
this tag as a magic number. This approach does no good for the
installed base of software.  The result will be that a large amount of
software which is working will acquire a bug.

In addition, there is no way for a pre-existing M3U handler invoked as
a helper app for the browser to pass control along to other apps that
may be able to handle this new protocol.

In addition, Apple's iTunes client does not correctly render ordinary
M3U files.  If the M3U contains more than one reference, the iTunes
client will only render the first one.  Therefore users should not
associate the iTunes client with M3U files.  If the iTunes client is
needed to handle this new protocol, and only software aside from the
iTunes client can handle the existing M3U protocol, then there will be
two broken protocols rather than two working -- but distinct -- ones.

Also, a nit about this section: "M3U Playlist files whose names end in
.m3u8 and/or have the HTTP Content-Type
"application/vnd.apple.mpegurl" are encoded in UTF-8 [RFC3629].  Files
whose names end with .m3u and/or have the HTTP Content-Type [RFC2616]
"audio/mpegurl" are encoded in US-ASCII."  This document is not the
place to specify the media type of existing protocols like the .m3u8
and .m3u extensions.  If it were, the common media type identifier for
M3U is audio/x-mpegurl.  audio/mpegurl is not widely used for M3U and
is not listed by IANA at
http://www.iana.org/assignments/media-types/audio/.

David, I don't intend to flame.  I wouldn't be surprised if what was
happening here was that you were taking the initiative within Apple to
document the protocol for the benefit of the internet community, and I
absolutely do believe that this informational note is a contribution
to the community.

Best,
Lucas Gonze