Re: [rtcweb] Plan for MTI video codec?

[Mohammed Raad <[e-mail]>]

Hi Stephan,

The relevant section in the ISO/IEC directives
<http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-1%7Bed11.0%7Den.pdf>
is:

2.14.3 Should it be revealed after publication of a document that licences
under patent
rights, which appear to cover items included in the document, cannot be
obtained under
reasonable and non-discriminatory terms and conditions, the document shall
be referred back
to the relevant committee for further consideration.

It should be clear to participants in this discussion that not listing any
patents in a type 3 declaration makes it difficult to claim that it has
been "revealed after publication of a document that licences under patent
rights, which appear to cover items included in the document,  cannot be
obtained".

So, yes, ISO does have a way of dealing with such situations. MPEG,
specifically, has dealt with such a situation during the development of the
CDVS standard, which is a recent standard. The path chosen in that instance
was to work around the known unlicensable patent.

If one was to accept the idea that a type-3 declaration (i.e. there will be
no licensing) without being told as to what patent the claim refers to
should stop the progress of a standard, then it would be impossible to
develop any standard.

Regards,
Mohammed

On Wed, Oct 22, 2014 at 9:45 PM, Stephan Wenger <[e-mail]> wrote:

> Hi,
> I have to make one correction in the light of information that has
> surfaced at the MPEG meeting currently ongoing in Strasbourg.  (I’m not at
> that meeting this time, but a colleague is and she briefed me.)
> Nokia has made MPEG and ISO/IEC officially aware that they are not willing
> to license essential patents under RAND terms.  For those with MPEG
> document access, please see M34917.  The official declaration is dated
> 9/19/2014, and is not yet available from the respective databases, as ISO
> is apparently changing its recordation infrastructure.
> My understanding of the joint ITU/ISO/IEC patent policy is that no
> standard can be issued that has a type 3 declaration against it.  To the
> best of my knowledge, ISO has no established procedure how to deal with
> type 3 (non-RAND) declarations and still keep the standard project going.
> Unlike, for example, W3C and its Patent Advisory Groups.
> The declaration does not list specific patents. To the best of my
> knowledge, such info is not required (only desired) for ISO and IEC
> standardization work--one of the few differences in patent policy
> guidelines between ITU and ISO/IEC.
> Therefore, I have to row back on my previous statement of likeliness of
> having an ISO number for VP8 anytime soon.  At this point, I just don’t
> know whether, if ever, that will happen.
> Regards,
> Stephan
>
>
> On 10/19/14, 6:10 PM, "Stephan Wenger" <[e-mail]> wrote:
>
> >Hi,
> >
> >On 10/19/14, 9:15 AM, "Watson Ladd" <[e-mail]> wrote:
> >
> >>On Sun, Oct 19, 2014 at 9:13 AM, Alexandre GOUAILLARD
> >><[e-mail]> wrote:
> >>> @jonathan,
> >>>
> >>> while you are right and availability of 264 implementation or hardware
> >>> acceleration has improved, it has never been reported as a problem in
> >>>the
> >>> previous pool by anyone. The 264 royalties, and the VP8 IP risks were,
> >>> AFAIR, the main reasons used by individuals to justify their positions.
> >>> Today, nothing has changed with respect to those two items (even though
> >>> providing open264 royalties and absorbing the license cost for some
> >>> platforms might have been a set in the right direction). This is why I
> >>>think
> >>> the conditions are not met for a consensus to be reached.
> >>
> >>But now VP8 is going through ISO,
> >
> >... and is is DIS ballot.  Few projects in ISO get stopped at that stage.
> >To me, it¹s pretty clear that VP8 will have an ISO/IEC blessing within a
> >year or two.  Without substantial technical changes.  Given the very
> >limited participation in the relevant subgroup in MPEG, it¹s unclear to me
> >what good that will do, though.
> >
> >>and the people claiming patents on
> >>VP8 have had time to sue, and haven't.
> >
> >That¹s factually incorrect.  To the best of my knowledge, what would be
> >factually correct is this: in two cases, companies have been sued over
> >patents allegedly reading on VP8 in the context of the wider ³smartphone
> >wars² lawsuits, and the defendants have won non-infringement rulings in
> >the first instance (though, last I looked, appeals were pending in both
> >cases).  At least one other case was settled on undisclosed terms.  Some
> >of these cases were widely reported in the press, others are a little bit
> >harder to find without access to legal search tools.
> >
> >>That's evidence that some
> >>concerns are overblown.
> >
> >And that depends on your viewpoint.
> >
> >Stephan
> >
> >>
> >>>
> >>> Alex.
> >>>
> >>>
> >>> On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba
> >>><[e-mail]>
> >>> wrote:
> >>>>
> >>>> "And its one of the issues holding up wider adoption of the
> >>>>technology"
> >>>>
> >>>> [BA] Specifying an MTI encoder/decoder is not sufficient for
> >>>> interoperability.  It is also necessary to specify the transport in
> >>>>enough
> >>>> detail to allow independent implementations that interoperate well
> >>>>enough to
> >>>> be usable in a wide variety of scenarios, including wireless networks
> >>>>where
> >>>> loss is commonly experienced.
> >>>>
> >>>> We made the mistake of having an MTI discussion previously with not
> >>>>enough
> >>>> details on that subject, particularly with respect to H.264.
> >>>> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.
> >>>>
> >>>> So if we are to have the discussion again, it should occur in the
> >>>>context
> >>>> of detailed specifications and interoperability reports.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg
> >>>><[e-mail]>
> >>>> wrote:
> >>>>>
> >>>>> I'm in favor of taking another run at this.
> >>>>>
> >>>>> The working group has repeatedly said that an MTI codec is something
> >>>>>we
> >>>>> need to produce. And its one of the issues holding up wider adoption
> >>>>>of the
> >>>>> technology (not the only one for sure).
> >>>>>
> >>>>> And things have changed since the last meeting, a year ago now
> >>>>>(November
> >>>>> in Vancouver). Cisco's open264 plugin shipped and now just recently
> >>>>>is
> >>>>> integrated into Firefox. iOS8 shipped with APIs for H264. There are
> >>>>>other
> >>>>> things worth noting. Will this change the minds of everyone? Surely
> >>>>>not.
> >>>>> Will it sway enough for us to achieve rough consensus? Maybe. IMHO -
> >>>>>worth
> >>>>> finding out.
> >>>>>
> >>>>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD
> >>>>> <[e-mail]> wrote:
> >>>>>>
> >>>>>> +1 to not having MTI codec discussion unless some progress has been
> >>>>>>made
> >>>>>> on VP8 at MPEG. Any news on that? I'm sharing harald's  feeling that
> >>>>>>there
> >>>>>> was no change on the members position.
> >>>>>>
> >>>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand
> >>>>>> <[e-mail]> wrote:
> >>>>>>>
> >>>>>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote:
> >>>>>>>>
> >>>>>>>> One thing we could do instead of wasting time on MTI is to
> >>>>>>>>actually
> >>>>>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so
> >>>>>>>>we could
> >>>>>>>> actually interoperate regardless of the codec.
> >>>>>>>
> >>>>>>>
> >>>>>>> The big argument for an MTI is actually the one stated in
> >>>>>>>-overview: It
> >>>>>>> guards against interoperability failure.
> >>>>>>>
> >>>>>>> I would like to have an ecosystem where one can field a box,
> >>>>>>>connect it
> >>>>>>> to everything else, and run well for *some* level of "well" - and I
> >>>>>>>would
> >>>>>>> prefer that ecosystem to be one where it's possible to field the
> >>>>>>>box without
> >>>>>>> making prior arrangements with anyone about licenses.
> >>>>>>>
> >>>>>>> This argument hasn't changed one whit since last time we discussed
> >>>>>>>it.
> >>>>>>> And I don't see much movement on the specifics of the proposals
> >>>>>>>either.
> >>>>>>>
> >>>>>>> We'll have to interoperate well with the codecs we field. So using
> >>>>>>>some
> >>>>>>> time to discuss draft-ietf-rtcweb-video seems to make sense. (And
> >>>>>>>4.1 isn't
> >>>>>>> finished either. There's one sentence that needs to be removed.)
> >>>>>>>
> >>>>>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But
> >>>>>>>I'd
> >>>>>>> prefer to re-discuss based on the knowledge that some significant
> >>>>>>>players
> >>>>>>> have actually changed their minds.
> >>>>>>>
> >>>>>>> At the moment, I don't see signs that any of the poll respondents
> >>>>>>>have
> >>>>>>> said "I have changed my mind".
> >>>>>>>
> >>>>>>> Harald
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson
> >>>>>>>>> <[e-mail]> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 16 October 2014 14:17, Matthew Kaufman <[e-mail]>
> >>>>>>>>>> wrote:
> >>>>>>>>>> And that's because something substantive has changed, or simply
> >>>>>>>>>> because
> >>>>>>>>>> wasting the WG time on this again is more entertaining than
> >>>>>>>>>>actually
> >>>>>>>>>> finishing a specification that can be independently implemented
> >>>>>>>>>>by
> >>>>>>>>>> all
> >>>>>>>>>> browser vendors? (A specification that we are nowhere near
> >>>>>>>>>>having,
> >>>>>>>>>> as far as
> >>>>>>>>>> I can tell)
> >>>>>>>>>
> >>>>>>>>> Personally, I've found the reprieve from this fight refreshing.
> >>>>>>>>>And
> >>>>>>>>> it would appear that we've made some real progress as a result.
> >>>>>>>>>I'd
> >>>>>>>>> suggest that if we don't have new information, we continue to
> >>>>>>>>>spend
> >>>>>>>>> our time productively.  If we can't find topics to occupy our
> >>>>>>>>>meeting
> >>>>>>>>> agenda time, then maybe we can free an agenda slot.
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> rtcweb mailing list
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> rtcweb mailing list
> >>>>>>>> [e-mail]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> rtcweb mailing list
> >>>>>>> [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Alex. Gouaillard, PhD, PhD, MBA
> >>>>>>
> >>>>>>
> >>>>>>---------------------------------------------------------------------
> >>>>>>-
> >>>>>>--------------
> >>>>>> CTO - Temasys Communications, S'pore / Mountain View
> >>>>>> President - CoSMo Software, Cambridge, MA
> >>>>>>
> >>>>>>
> >>>>>>---------------------------------------------------------------------
> >>>>>>-
> >>>>>>--------------
> >>>>>> sg.linkedin.com/agouaillard
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> rtcweb mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Jonathan Rosenberg, Ph.D.
> >>>>> [e-mail]
> >>>>> http://www.jdrosen.net
> >>>>>
> >>>>> _______________________________________________
> >>>>> rtcweb mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Alex. Gouaillard, PhD, PhD, MBA
> >>>
> >>>------------------------------------------------------------------------
> >>>-
> >>>-----------
> >>> CTO - Temasys Communications, S'pore / Mountain View
> >>> President - CoSMo Software, Cambridge, MA
> >>>
> >>>------------------------------------------------------------------------
> >>>-
> >>>-----------
> >>> sg.linkedin.com/agouaillard
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>
> >>
> >>
> >>
> >>--
> >>"Those who would give up Essential Liberty to purchase a little
> >>Temporary Safety deserve neither  Liberty nor Safety."
> >>-- Benjamin Franklin
> >>
> >>_______________________________________________
> >>rtcweb mailing list
> >>[e-mail]
> >>https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >_______________________________________________
> >rtcweb mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>



-- 
Mohammed Raad, PhD.
Partner
RAADTECH CONSULTING
P.O. Box 113
Warrawong
NSW 2502 Australia
Phone: [phone]
Email: [e-mail]