Re: [httpstreaming] Why a new standard for streaming HTTP?

[Henry Sinnreich <[e-mail]>]

This is not an issue of duplicating work in other SDO, but rather why would
an IETF standard be different?

Obviously, the business models and the resulting standards of the other SDO
stake holders may be, legitimately so, different from the global, open
Internet.

An informational RFC discussing both the ³why² and the ³how² would be no
doubt very useful and interesting. Qin Wu has already mentioned some items.
But since I have no idea how to access the documents of the other SDO, their
discussions, meeting slides, the decision process, etc., or even find out
who the authors and contributors are, such an RFC may not be doable by
individual IETF contributors.

Example: Some SDO documents have come to my notice where the word ³Internet²
was studiously avoided.
How can one follow the discussions on how and who came to this editorial
direction? Quite troubling in the IETF it would seem.
Naïve question: If the ³Internet² does not exist, why have liaison people?
The IETF has individual contributors.

Never mind the above, there are plenty of reasons to have an Internet
standard for streaming HTTP that may differ quite substantially from other
SDO.
Just think of IPR-free codecs that can be plugged in, vs. the single,
heavily licensed video codec I have seen.
Which reminds me of similar discussions, meant to avoid an IETF WG for an
Internet audio codec.
http://datatracker.ietf.org/wg/codec/

Henry


On 9/27/10 3:34 PM, "Luby, Michael" <[e-mail]> wrote:

> A few comments/thoughts.
> 
> (1) The SDOs that are already deeply involved in standardizing OTT HTTP
> streaming have worked hard to stay aligned, e.g., 3GPP, MPEG, OIPF.  There is
> a lot of ongoing coordination between these organizations on HTTP streaming
> (DASH ‹ dynamic adaptive streaming over HTTP), many of the people involved are
> working across these organizations, and liaisons are being sent back and forth
> to coordinate, etc.  For example, they have all adopted the same baseline
> standard that was initiated in 3GPP, and features that were developed by MPEG
> are being rolled back into 3GPP, etc.  It is not clear what the IETF adds in
> this sense (or perhaps may subtract?)  The attempt is to create one standard
> across the different organizations, and not disparate competing standards.
> 
> (2) If there is any effort in this area by the IETF, it would be good to align
> with the goal of one common standard.  If there is fragmentation, it will not
> be good for deployment.  For example, I¹ve seen emails on this list that
> suggest that the IETF might go in a different direction and use a different
> basis other than HTTP, or do something that is based on HTTP but is contrary
> to these other standards, and it seems that these directions will only
> confuse/slow down any adoption.
> 
> (3) If the IETF decides to go off in a different direction and not use HTTP
> 1.1 as the basis, to avoid confusion it would be really helpful not to call
> this HTTP streaming, but instead call it some other name that is suitable for
> whatever is being standardized.
> 
> Mike Luby
> 
> 
> 
> On 9/27/10 12:00 PM, "[e-mail]"
> <[e-mail]> wrote:
> 
>> If you have received this digest without all the individual message
>> attachments you will need to update your digest options in your list
>> subscription.  To do so, go to
>> 
>> https://www.ietf.org/mailman/listinfo/httpstreaming
>> 
>> Click the 'Unsubscribe or edit options' button, log in, and set "Get
>> MIME or Plain Text Digests?" to MIME.  You can set this option
>> globally for all the list digests you receive at this point.
>> 
>> 
>> 
>> Send httpstreaming mailing list submissions to
>>  [e-mail]
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>  https://www.ietf.org/mailman/listinfo/httpstreaming
>> or, via email, send a message with subject or body 'help' to
>>  [e-mail]
>> 
>> You can reach the person managing the list at
>>  [e-mail]
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of httpstreaming digest..."
> 
> 
> _______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming