Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

From: Alan Johnston <[email-masked]>
Date: Wed, 15 Dec 2010 11:09:16 -0600

Harald,

Thanks for kicking off this work with your drafts.  I know a lot of us
are greatly looking forward to starting this work after thinking and
talking about it for a long time.

My thinking is basically aligned with your draft.  However, I think we
need a little more clarity on exactly what we are trying to do:
exactly how do all the components talk to you each other using
standard protocols or APIs?  I found your datagram session URI
proposal in the other draft a little hard to understand - I think we
will need good requirements before we can decide if this is the right
mechanism.

I also understand your arguments on connection management, which is
really signaling.  I agree that it is possible for this to be a local
matter between a web browser and a web server, and that establishing
voice sessions from within a web domain can be handled without
standards, and voice sessions between web domains could be signaled
using existing standards such as SIP.

However, I do think there is value in standardizing some kind of
lightweight API for signaling between the browser and server.   Some
of us have been thinking about this for a while now:

     http://tools.ietf.org/html//draft-sinnreich-sip-web-apis
     http://tools.ietf.org/html/draft-peterson-sipcore-advprop

The good news is that this work is completely orthogonal to the mainly
media work you propose in your draft. But it does tie in nicely and
helps provide a fully interoperable set of protocols/APIs, which
ultimately is what the IETF is all about.   I don't see any need for
one effort to delay the other - in fact, both could potentially be
done in separate working groups.

Finally, a comment on the name for the overall effort - I know, really
important stuff...  The acronym RTC has baggage in our industry, and
it might be nice avoid yet another three letter acronym ;-).  I was
thinking about Web RTCom, short for Web Real Time Communications.

- Alan -

On Wed, Nov 10, 2010 at 5:34 AM, Harald Alvestrand <[email-masked]> wrote:
>
> This is the overview document for the IETF-related RTC-WEB work.
>
> -------- Original Message --------
> Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
> Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST)
> From: IETF I-D Submission Tool <[email-masked]>
> To: [email-masked]
>
> A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.
>
> Filename:	 draft-alvestrand-dispatch-rtcweb-protocols
> Revision:	 00
> Title:		 Overview: Real Time Protocols for Brower-based Applications
> Creation_date:	 2010-11-11
> WG ID:		 Independent Submission
> Number_of_pages: 9
>
> Abstract:
> This document gives an overview of a protocol suite intended for use
> with real-time applications that can be deployed in browsers - "real
> time communication on the Web".
>
> It intends to serve as a starting and coordination point to make sure
> all the parts that are needed to achieve this goal are findable, and
> that the parts that belong in the Internet protocol suite are fully
> specified and on the right publication track.
>
> This work is an attempt to synthesize the input of many people, but
> makes no claims to fully represent the views of any of them.  All
> parts of the document should be regarded as open for discussion.
>
>
>
> The IETF Secretariat.
>
>
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 17 Dec 2010 06:48:28 -0500

I'd also like to echo Alan's thanks for these drafts. 

The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-)  ]

One observation to the group. The mandatory to implement video CODEC is VP8 (presumably since it does not have IPR issues - which some other choices would have). 

Regards, 

Peter Musgrave

Nits
Introduction
s/veichle/vehicle/

Section 2 Para "Within each.."
s/implementaiton/implementation/

Section 4 Para1
"such as" (something missing here?)

Section 5 Para2
"There is no third mandatory to implement" 
? Was there a mention of a third before. Not sure why this statement is there.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Dec 2010 14:47:49 +0100

> will need good requirements before we can decide if this is the right
I think the API work will be handled in W3C, and described in the form 
of Javascript - one central issue is that various components will have 
to send media to each other *without* going through the Javascript level 
- this is AFAIK relatively new territory for all concerned.
> done in separate working groups.
Thanks for the pointers - will certainly read up on these!
> thinking about Web RTCom, short for Web Real Time Communications.
Names are the ultimate timesink in discussion :-) - somewhat 
tongue-in-cheek, I wonder if the best approach is if everyone with a 
proposed name sends them to the BOF in Prague, we put them all in a hat, 
and then draw one at random :-)
> - Alan -
>
>
>
> On Wed, Nov 10, 2010 at 5:34 AM, Harald Alvestrand<[email-masked]>  wrote:
>> From: IETF I-D Submission Tool<[email-masked]>
>> To: [email-masked]
>>

---

From: [email-masked]
Date: Tue, 21 Dec 2010 14:15:45 +0800

Harald,

Your draft is about realtime communication in the Web. I think SIP&SDP is 
one way for it, and this overlaps my concerning.

I also concerne about openning multimedia capability to the Web from 
current SIP infrastructure, such as IMS(a system defined by 3GPP with AAA, 
security, QoS). IMO, if we can standardize embedded SIP session into 
HTML(HTML5's video/audio elements), then people can access IMS's quality 
multimedia service by normal Web Browser without any plugin.

Thanks,

Gao
 
===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: <[email-masked]>
Date: Tue, 21 Dec 2010 21:38:42 +0000

Hi Peter, all,

About the video codec: Are there any arguments on why VP8 would not have IPR issues? It is available as an open source implementation, but that does not mean there are no IPR against it. My understanding is that the IPR situation wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as far as I know, the lack of a clear spec out of which independent interoperable implementations can be created.

So I don't at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons.

I'm working on a separate review on Harald's drafts (thanks for putting them together) and will come back to the codec issue there in more detail, but just wanted to respond to Peter's point here.

Regards,
                Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Peter Musgrave
Sent: 17 December, 2010 13:48
To: Harald Alvestrand
Cc: [email-masked]; [email-masked]; Ted Hardie
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

Regards,

Peter Musgrave

Nits
Introduction
s/veichle/vehicle/

Section 4 Para1

Section 5 Para2

-------- Original Message --------
Subject:

New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

Date:

Wed, 10 Nov 2010 03:31:05 -0800 (PST)

From:

IETF I-D Submission Tool <[email-masked]><mailto:[email-masked]>

To:

[email-masked]<mailto:[email-masked]>

Revision:      00

Number_of_pages: 9

Abstract:

The IETF Secretariat.

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: David Singer <[email-masked]>
Date: Tue, 21 Dec 2010 13:46:00 -0800

I have to agree.  If IPR issues are what we want to avoid, VP8 seems like a poor choice (e.g. <http://www.digitaltrends.com/computing/mpeg-la-looking-at-patents-for-googles-vp8webm-video/>).

On Dec 21, 2010, at 13:38 , [email-masked] wrote:

> So I don’t at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons.
>  
> I’m working on a separate review on Harald’s drafts (thanks for putting them together) and will come back to the codec issue there in more detail, but just wanted to respond to Peter’s point here.
>  
> Regards,
>                 Markus
>  
> IETF I-D Submission Tool <[email-masked]>
> To:
> [email-masked]
>  
> 

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Gerard Fernando <[email-masked]>
Date: Wed, 22 Dec 2010 00:09:49 +0000 (GMT)

I also feel that it's not appropriate to choose VP8 as a mandatory codec. It 
makes sense to limit any mandatory codecs to standards. 

If VP8 does need to be standardized, the IETF CODEC WG comes to my mind as a 
possible place to carry out such a standard - I do understand that this WG is 
currently only focused on audio. I suppose the charter could be changed to 
include video. One advantage of this WG is that it aims to deliver a 
royalty-free spec. 

There's also a Call-for-Evidence put out by ISO/MPEG with the aim of starting a 
royalty-free codec development activity. 

Regards

Gerard Fernando

________________________________
From: David Singer <[email-masked]>
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Sent: Tue, 21 December, 2010 13:46:00
Subject: Re: [dispatch] Fwd: New Version Notification for 
draft-alvestrand-dispatch-rtcweb-protocols-00

I have to agree.  If IPR issues are what we want to avoid, VP8 seems like a poor 
choice (e.g. 
<http://www.digitaltrends.com/computing/mpeg-la-looking-at-patents-for-googles-vp8webm-video/>).

Hi Peter, all,
> 
>About the video codec: Are there any arguments on why VP8 would not have IPR 
>issues? It is available as an open source implementation, but that does not mean 
>there are no IPR against it. My understanding is that the IPR situation wrt. VP8 
>is still unclear and thus risky. The other issue with VP8 is, as far as I know, 
>the lack of a clear spec out of which independent interoperable implementations 
>can be created.
> 
>So I don’t at least buy the argument that we should choose VP8 as mandatory to 
>implement video codec because of IPR reasons.
> 
>I’m working on a separate review on Harald’s drafts (thanks for putting them 
>together) and will come back to the codec issue there in more detail, but just 
>wanted to respond to Peter’s point here.
> 
>Regards,
>                Markus
> 
>Subject: Re: [dispatch] Fwd: New Version Notification for 
>draft-alvestrand-dispatch-rtcweb-protocols-00
> 
>One observation to the group. The mandatory to implement video CODEC is VP8 
>(presumably since it does not have IPR issues - which some other choices would 
>have). 
> 
>Regards, 
> 
>Peter Musgrave
> 
> 
>Nits
>Introduction
>s/veichle/vehicle/
> 
>Subject: New Version Notification for 
>draft-alvestrand-dispatch-rtcweb-protocols-00 
>
>A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been 
>successfully submitted by Harald Alvestrand and posted to the IETF repository.
>  

David Singer

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 21 Dec 2010 20:32:28 -0600

It is interesting, almost funny (or sad depending on the perspective) how
the reaction to a _God Forbid_ IP-free video codec is mirroring the
opposition to the Internet audio codec. That opposition proved eventually
futile and we have now a CODEC WG.
I hope the AD¹s will have now the same fortitude as was shown when the
Internet audio codec WG was formed.

I have taken the liberty to copy the CODEC WG and hope they can participate
now in the video codec discussion as well.
My apology for the double posting.

Thanks, Henry 

On 12/21/10 3:38 PM, "[email-masked]" <[email-masked]>
wrote:

> issues? It is available as an open source implementation, but that does not
> mean there are no IPR against it. My understanding is that the IPR situation
> wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as far
> as I know, the lack of a clear spec out of which independent interoperable
> implementations can be created.
>  
> So I don¹t at least buy the argument that we should choose VP8 as mandatory to
> I¹m working on a separate review on Harald¹s drafts (thanks for putting them
> wanted to respond to Peter¹s point here.
>  
> Regards,
>                 Markus
>  
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Dec 2010 22:18:20 -0800

It does appear presumptive to suggest that a codec that hasn't completed a standardization process be made "mandatory to implement."

Since there have been some large judgments over use of 
allegedly "free" codecs, the lesson is that codecs that are claimed to 
be "free of encumbrance" may in time be discovered not to be.  The IETF process can potentially be useful in helping to clarify the IPR status of codecs.  However, those wheels grind slowly. 

From: [email-masked]
To: [email-masked]; [email-masked]
Date: Tue, 21 Dec 2010 21:38:42 +0000
CC: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTW] [dispatch] Fwd: New Version Notification	for	draft-alvestrand-dispatch-rtcweb-protocols-00

Hi Peter, all,

About the video codec: Are there any arguments on why VP8 would
not have IPR issues? It is available as an open source implementation, but that
does not mean there are no IPR against it. My understanding is that the IPR
situation wrt. VP8 is still unclear and thus risky. The other issue with VP8 is,
as far as I know, the lack of a clear spec out of which independent interoperable
implementations can be created.

So I don’t at least buy the argument that we should choose
VP8 as mandatory to implement video codec because of IPR reasons.

I’m working on a separate review on Harald’s drafts
(thanks for putting them together) and will come back to the codec issue there in
more detail, but just wanted to respond to Peter’s point here.

Regards,

                Markus

From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Peter Musgrave

To: Harald Alvestrand

 

 

The protocol doc is very clear. [If you read only one
dispatch draft this Christmas, make it this one. ;-)  ]

One observation to the group. The mandatory to implement
video CODEC is VP8 (presumably since it does not have IPR issues - which some
other choices would have). 

Regards, 

Peter Musgrave

 

Nits

Introduction

s/veichle/vehicle/

Section 2
Para "Within each.."

 

Section 4
Para1

"such
as" (something missing here?)

Section 5
Para2

"There
is no third mandatory to implement" 

? Was
there a mention of a third before. Not sure why this statement is there.

 

This is the overview document for the IETF-related RTC-WEB
work.

-------- Original Message -------- 

  
  Subject: 

  New Version Notification for
  draft-alvestrand-dispatch-rtcweb-protocols-00

  
  Date: 

 
  
  From: 

 
  
  To: 

  [email-masked]

A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename:      draft-alvestrand-dispatch-rtcweb-protocolsRevision:      00Title:         Overview: Real Time Protocols for Brower-based ApplicationsCreation_date:  2010-11-11WG ID:         Independent SubmissionNumber_of_pages: 9 Abstract:This document gives an overview of a protocol suite intended for usewith real-time applications that can be deployed in browsers - "realtime communication on the Web". It intends to serve as a starting and coordination point to make sureall the parts that are needed to achieve this goal are findable, andthat the parts that belong in the Internet protocol suite are fullyspecified and on the right publication track. This work is an attempt to synthesize the input of many people, butmakes no claims to fully represent the views of any of them.  Allparts of the document should be regarded as open for discussion.                                                                                    The IETF Secretariat.   

dispatch mailing list

[email-masked]

 

_______________________________________________
RTC-Web mailing list
[email-masked]
http://www.alvestrand.no/mailman/listinfo/rtc-web

---

From: <[email-masked]>
Date: Wed, 22 Dec 2010 07:46:12 +0000

Hi,

The good thing about Opus codec is that as it has been developed through the IETF process, the ownership and change control issues are clear. This makes referencing and even mandating it by IETF or W3C more comfortable.

Markus

From: ext Henry Sinnreich [mailto:[email-masked]]
Sent: 22 December, 2010 04:32
To: Isomaki Markus (Nokia-CIC/Espoo); [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

It is interesting, almost funny (or sad depending on the perspective) how the reaction to a _God Forbid_ IP-free video codec is mirroring the opposition to the Internet audio codec. That opposition proved eventually futile and we have now a CODEC WG.
I hope the AD's will have now the same fortitude as was shown when the Internet audio codec WG was formed.

I have taken the liberty to copy the CODEC WG and hope they can participate now in the video codec discussion as well.
My apology for the double posting.

Thanks, Henry

On 12/21/10 3:38 PM, "[email-masked]" <[email-masked]> wrote:
Hi Peter, all,

Regards,
                Markus

Regards,

Peter Musgrave

Nits

Introduction

s/veichle/vehicle/

Section 4 Para1

Section 5 Para2

-------- Original Message --------

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 22 Dec 2010 16:14:21 +0100

On 12/22/10 07:18, Bernard Aboba wrote:
> It does appear presumptive to suggest that a codec that hasn't 
> completed a standardization process be made "mandatory to implement."
>
> Since there have been some large judgments over use of allegedly 
> "free" codecs, the lesson is that codecs that are claimed to be "free 
> of encumbrance" may in time be discovered not to be.  The IETF process 
> can potentially be useful in helping to clarify the IPR status of 
> codecs.  However, those wheels grind slowly.
I agree that we can't make anything mandatory to implement that we don't 
have an accepted stable, publicly available reference for. (I'm working 
on solving that for the case of VP8).

However, I don't agree that we necessarily have to complete a standards 
process in order to refer to it; that would put, for instance, the Zip 
format (used, among other places, in OOXML and ODF) out of scope for 
standards.

WRT IPR issues: I think we just have to push forward on the assumption 
that all IPR holders who are part of the process will do their duty and 
disclose any relevant IPR, and hope that IPR held by nonparticipants in 
the process is not serious enough to cause us to regret our decision.

Note: The statement about VP8 in the rtcweb-protocols document is a 
placeholder, put in there to indicate that we need to have the 
discussion. It's not a WG decision, but input to a WG discussion.

                       Harald

---

From: Roar Hagen <[email-masked]>
Date: Wed, 22 Dec 2010 08:49:38 +0100

I agree with what Silvia says here. Similarly, I believe royalty free is the
goal/requirement for the new internet audio codec currently being
standardized by the IETF. Furthermore, the term IPR free is also wrong since
the designers/contributors that make the codec royalty free usually have IPR
in th codec. The best one can do is to do your best in avoiding other known
IPR.

Roar

On Wed, Dec 22, 2010 at 8:31 AM, Silvia Pfeiffer
<[email-masked]>wrote:

> Where is the MPEG-LA patent pool for WebM? As far as I can tell this has
> just been a hollow announcement, but MPEG-LA have not been able to set up
> such a patent pool yet. Maybe it's because there aren't any patents out
> there that are being infringed? Unfortunately, the non-existence of
> infringing patents can never be proven and this situation is therefore
> always open to creating fear, uncertainty and doubt.
>
> Also note that going through an actual standardisation process and becoming
> part of a license pool by MPEG-LA doesn't actually protect you from lawsuits
> for patent infringement, see e.g.
>
> http://www.itnews.com.au/News/74186,apple-samsung-and-sandisk-hit-by-mp3-patent-claim.aspx
>
> MPEG-LA patent pools are only there to protect you from lawsuits of patents
> that are being made available through the pool. The pool is not an insurance
> against patent infringement lawsuits - not even from those that have joined
> the patent pool, as the law suit of Lucent against MicroSoft has taught us:
> http://en.wikipedia.org/wiki/Alcatel-Lucent_v._Microsoft
>
> As said before: IPR issues are not a good decision factor on which to
> select a codec for common use. Royalty-free is important. And the rest
> should be based on technical merit.
>
> Regards,
> Silvia.
>
>
> On Tue, Dec 21, 2010 at 10:46 PM, David Singer <[email-masked]> wrote:
>
>> I have to agree.  If IPR issues are what we want to avoid, VP8 seems like
>> a poor choice (e.g. <
>> http://www.digitaltrends.com/computing/mpeg-la-looking-at-patents-for-googles-vp8webm-video/
>> >).
>>
>> About the video codec: Are there any arguments on why VP8 would not have
>> IPR issues? It is available as an open source implementation, but that does
>> not mean there are no IPR against it. My understanding is that the IPR
>> situation wrt. VP8 is still unclear and thus risky. The other issue with VP8
>> is, as far as I know, the lack of a clear spec out of which independent
>> interoperable implementations can be created.
>>
>> So I don’t at least buy the argument that we should choose VP8 as
>> mandatory to implement video codec because of IPR reasons.
>>
>> I’m working on a separate review on Harald’s drafts (thanks for putting
>> them together) and will come back to the codec issue there in more detail,
>> but just wanted to respond to Peter’s point here.
>>
>> Regards,
>>                 Markus
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *ext Peter Musgrave
>> *Sent:* 17 December, 2010 13:48
>> *To:* Harald Alvestrand
>> *Cc:* [email-masked]; [email-masked]; Ted Hardie
>> *Subject:* Re: [dispatch] Fwd: New Version Notification for
>> One observation to the group. The mandatory to implement video CODEC is
>> VP8 (presumably since it does not have IPR issues - which some other choices
>> would have).
>>
>> Regards,
>>
>> Peter Musgrave
>>
>>
>> Nits
>> Introduction
>> s/veichle/vehicle/
>>
>>  *Subject:*
>> *Date:*
>> *From:*
>> IETF I-D Submission Tool <[email-masked]> <[email-masked]>
>> *To:*
>> [email-masked]
>>
>>
>>

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 22 Dec 2010 04:41:43 -0800

> http://www.webmproject.org/media/pdf/vp8-bitstream.pdf . An independent
> implementation of VP8 can be made by anyone, see
> http://www.webmproject.org/license/bitstream/ .

And, in particular, an independent implementation has been made, namely 
ffvp8: http://x264dev.multimedia.cx/archives/499

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 22 Dec 2010 16:18:16 +0100

On 12/21/10 22:46, David Singer wrote:
> I have to agree.  If IPR issues are what we want to avoid, VP8 seems 
> like a poor choice (e.g. 
That article is by now 7 months old (May 2010), and AFAIK, no specific 
IPR claims have been made public.

I wouldn't presume to claim that this proves anything.

                       Harald

>
> On Dec 21, 2010, at 13:38 , [email-masked] 
> <mailto:[email-masked]> wrote:
>
>> Hi Peter, all,
>> About the video codec: Are there any arguments on why VP8 would not 
>> have IPR issues? It is available as an open source implementation, 
>> but that does not mean there are no IPR against it. My understanding 
>> is that the IPR situation wrt. VP8 is still unclear and thus risky. 
>> The other issue with VP8 is, as far as I know, the lack of a clear 
>> spec out of which independent interoperable implementations can be 
>> created.
>> I’m working on a separate review on Harald’s drafts (thanks for 
>> putting them together) and will come back to the codec issue there in 
>> *From:[email-masked] 
>> <mailto:[email-masked]>[mailto:[email-masked]]*On 
>> Behalf Of*ext Peter Musgrave
>> *Sent:*17 December, 2010 13:48
>> *To:*Harald Alvestrand
>> *Cc:[email-masked] 
>> <mailto:[email-masked]>;[email-masked] 
>> <mailto:[email-masked]>; Ted Hardie
>> *Subject:*Re: [dispatch] Fwd: New Version Notification for 
>> One observation to the group. The mandatory to implement video CODEC 
>> is VP8 (presumably since it does not have IPR issues - which some 
>> IETF I-D Submission Tool<[email-masked]> 
>> <mailto:[email-masked]>
>> *To:*
>> 	
>> [email-masked] <mailto:[email-masked]>
>>
>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 22 Dec 2010 07:25:36 -0800

> the process is not serious enough to cause us to regret our decision.

We don't have to limit ourselves to just hope (and in this case I think 
it would be a bad idea). There are processes in other non-IETF standards 
organizations to address patents held by nonpaticipants as well (for 
example, a W3C PAG).

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 22 Dec 2010 11:46:41 -0600

>The statement about VP8 in the rtcweb-protocols document is a placeholder,
>put in there to indicate that we need to have the discussion. It's not a WG
decision, but input to a WG discussion.

This is an excellent position, thanks Harald!

Now that many people agree on the need for an ³IP-free as possible² RTC Web
codec, it would be a good start to make a short list of candidates and then
discuss them on merit. Such as IMO (sorry I am not a video codec expert):
V8, Theora and what other may contribute that require no IP. Even just
starting with a table like
http://en.wikipedia.org/wiki/Comparison_of_video_codecs

To avoid rat holes and flames, I suggest not even to mention H.264 :-)
except as an example for what not to adopt.

Henry

On 12/22/10 9:14 AM, "Harald Alvestrand" <[email-masked]> wrote:

>>   It does appear presumptive to suggest that a codec that hasn't completed a
>> standardization process be made "mandatory to implement."
>>  
>>  Since there have been some large judgments over use of allegedly "free"
>> codecs, the lesson is that codecs that are claimed to be "free of
>> encumbrance" may in time be discovered not to be.  The IETF process can
>> potentially be useful in helping to clarify the IPR status of codecs. 
>> However, those wheels grind slowly.
>>  
>  I agree that we can't make anything mandatory to implement that we don't have
> an accepted stable, publicly available reference for. (I'm working on solving
> that for the case of VP8).
>  
> process in order to refer to it; that would put, for instance, the Zip format
> (used, among other places, in OOXML and ODF) out of scope for standards.
>  
>  WRT IPR issues: I think we just have to push forward on the assumption that
> all IPR holders who are part of the process will do their duty and disclose
> any relevant IPR, and hope that IPR held by nonparticipants in the process is
> not serious enough to cause us to regret our decision.
>  
> placeholder, put in there to indicate that we need to have the discussion.
> It's not a WG decision, but input to a WG discussion.
>  
>                        Harald
>  
>  
>  
>  
>

---

From: <[email-masked]>
Date: Wed, 22 Dec 2010 21:12:41 +0000

Hi Harald,

We can reference things as long as they are public and stable. But I also think that if we were to mandate some technology as part of an IETF standard, the future development of that technology should preferably be done under an open process. How does the future development of VP8 (or VP9) will happen from that point of view? I've seen some concerns about this so it would be good to get the facts.

As long as VP8 spec itself is not published as an Internet-draft, I don't suppose the IETF IPR rules apply to it. So I'm not sure which process we are following with it right now. That would be good to clarify.

Regards,
                Markus

From: ext Harald Alvestrand [mailto:[email-masked]]
Sent: 22 December, 2010 17:14
To: Bernard Aboba
Cc: Isomaki Markus (Nokia-CIC/Espoo); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Codec standardization (Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)

Since there have been some large judgments over use of allegedly "free" codecs, the lesson is that codecs that are claimed to be "free of encumbrance" may in time be discovered not to be.  The IETF process can potentially be useful in helping to clarify the IPR status of codecs.  However, those wheels grind slowly.
I agree that we can't make anything mandatory to implement that we don't have an accepted stable, publicly available reference for. (I'm working on solving that for the case of VP8).

However, I don't agree that we necessarily have to complete a standards process in order to refer to it; that would put, for instance, the Zip format (used, among other places, in OOXML and ODF) out of scope for standards.

WRT IPR issues: I think we just have to push forward on the assumption that all IPR holders who are part of the process will do their duty and disclose any relevant IPR, and hope that IPR held by nonparticipants in the process is not serious enough to cause us to regret our decision.

Note: The statement about VP8 in the rtcweb-protocols document is a placeholder, put in there to indicate that we need to have the discussion. It's not a WG decision, but input to a WG discussion.

                      Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 22 Dec 2010 23:45:02 +0100

On 12/22/10 22:12, [email-masked] wrote:
>
> Hi Harald,
>
> We can reference things as long as they are public and stable. But I 
> also think that if we were to mandate some technology as part of an 
> IETF standard, the future development of that technology should 
> preferably be done under an open process. How does the future 
> development of VP8 (or VP9) will happen from that point of view? I've 
> seen some concerns about this so it would be good to get the facts.
>
VP8 (the bitstream format) is not going to change in any incompatible 
way. Too much software and hardware is already dependent on the current 
definition.
It seems reasonable to do the development of a successor specification 
in a standards body, but that's probably going to take a few years.
>
> As long as VP8 spec itself is not published as an Internet-draft, I 
> don't suppose the IETF IPR rules apply to it. So I'm not sure which 
> process we are following with it right now. That would be good to clarify.
>
I'm hoping to make that clearer within a few weeks - sorry that I can't 
say more yet.
>
> Regards,
>
>                 Markus
>
> *From:*ext Harald Alvestrand [mailto:[email-masked]]
> *Sent:* 22 December, 2010 17:14
> *To:* Bernard Aboba
> *Cc:* Isomaki Markus (Nokia-CIC/Espoo); [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> *Subject:* Codec standardization (Re: [RTW] [dispatch] Fwd: New 
> Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
>
> I agree that we can't make anything mandatory to implement that we 
> don't have an accepted stable, publicly available reference for. (I'm 
> working on solving that for the case of VP8).
>
> However, I don't agree that we necessarily have to complete a 
> standards process in order to refer to it; that would put, for 
> instance, the Zip format (used, among other places, in OOXML and ODF) 
> out of scope for standards.
>
> that all IPR holders who are part of the process will do their duty 
> and disclose any relevant IPR, and hope that IPR held by 
> nonparticipants in the process is not serious enough to cause us to 
> regret our decision.
>

---

From: David Singer <[email-masked]>
Date: Wed, 22 Dec 2010 14:46:36 -0800

I should say that I am perfectly happy to have the discussion about whether, and what, to mandate codec(s).  If the placeholder is there to spark the discussion, you succeeded!

For me, significant IPR risk is worse than a payment -- free but risky is not an improvement on costs-but-low-risk.  But others may differ, of course.

I do think we should be looking carefully at layered design.  Ideally, we define the missing technology bits -- HTML, Javascript/DOM, and so on;  and then, perhaps, we write an umbrella specification that uses those, and other technology pieces, to achieve an interoperable end.  But the pieces should 'make sense' by themselves, and be usable with other assemblages, I think, if the specs are to have 'legs' and survive over years.  The pieces are ideally stable standards/publications in their own right (and I agree, sometimes, rarely, something is stable and well-known enough, such as ZIP or ID3 tags, without being a 'standard').

I also agree that RF codecs are happening and are here to stay.  Those of you who know me from MPEG will have heard this before.  They will exist, and they will have a place. MPEG is working (slowly) on RF codecs as well.

As to what MPEG-LA is doing, I am afraid I don't actually know. We'd have to ask them, and they tend not to reply. The silence is strange, but I don't think that mitigates the possibility that there is an IPR entanglement.

Despite Henry's position (that mentioning VP8 results in no rat-holes and flames, and that mentioning H.264 will) I think we should consider the balance between cost, risk, quality, and existing adoption, and it would be foolish to omit cost-bearing codecs from that analysis, as H.264 is widely used already.

The link between open-source and royalty-free is not perfect;  there are quality open-source implementations of non-free codecs, for a start, and there are companies who license proprietary systems royalty-free.  Let's not confuse the two, even if they often occur together.

David Singer

---

From: Alan Johnston <[email-masked]>
Date: Mon, 27 Dec 2010 09:11:24 -0600

Harald,

Thanks for the reply.  I'm sure the work will get done in the right
place.  Clearly, Javascript is outside our expertise here at the IETF,
but we have a lot of media knowledge to utilize.

And as for the name, perhaps no one remembers the use of RTC by a
small company based in Redmond a few years back.  If so, and if
there's no trademarks or other issue, then maybe we are good to use
it.

- Alan -

On Mon, Dec 20, 2010 at 7:47 AM, Harald Alvestrand <[email-masked]> wrote:
> I think the API work will be handled in W3C, and described in the form of
> Javascript - one central issue is that various components will have to send
> media to each other *without* going through the Javascript level - this is
> AFAIK relatively new territory for all concerned.
>>
> proposed name sends them to the BOF in Prague, we put them all in a hat, and
> then draw one at random :-)
>>
>> - Alan -
>>
>>
>>
>>> A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt
>>> has been successfully submitted by Harald Alvestrand and posted to the IETF
>>> repository.
>>>