Re: [hybi] New charter for HyBi wg

I'm fine with the plan.

Takeshi

On Sat, Jan 21, 2012 at 04:56, Gabriel Montenegro <
Gabriel.Montenegro@microsoft.com> wrote:

>  Yes, the assumption is that multiplexing will use John’s draft as a
> starting point, and the compression will use Takeshi’s draft as a starting
> point. I agree that the compression extension is better understood and more
> contained, which is why it is targeted as finishing earlier, although some
> parallel work might be ok as one tapers off. We can always modify dates and
> estimates later on, but this is just a first stab.****
>
> ** **
>
> I agree that the mux extension is more complex and invite discussion as to
> how the WG sees it and whether the currently proposed milestones are within
> the ballpark (it’s ok for them to be somewhat optimistic, as were our
> original charter’s milestones).****
>
> ** **
>
> *From:* hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] *On Behalf
> Of *John Tamplin
> *Sent:* 20 January, 2012 11:36
> *To:* Jesse McConnell
> *Cc:* hybi@ietf.org
> *Subject:* Re: [hybi] New charter for HyBi wg****
>
> ** **
>
> On Fri, Jan 20, 2012 at 1:14 PM, Jesse McConnell <
> jesse.mcconnell@gmail.com> wrote:****
>
> Is it safe to assume that the starting place for the mux extension
> will be John's google-mux draft?  If so, would it make sense to start
> off the extensions discussions there, or does it make more sense to
> work on some 'official' simple extensions before tackling that more
> complex one?  I am a bit torn on where it would be best to start.  I
> would like to see the mux 'official' as soon as possible but I am
> unclear if individual extensions could have much of an effect on the
> mux extension or vis versa.
>
> Just curious as he has some nice work done there which could be a nice
> starting point.****
>
> ** **
>
> If someone has an alternate proposal, that is fine, but in the absence of
> that I suggest http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-01 is
> as good a place to start as any.****
>
> ** **
>
> I suspect per-frame compression will be easier to get agreement on, and so
> could be completed more quickly.  There is a pressing need for both, but
> shortest-job-first scheduling gets something useful deployed faster.****
>
> ** **
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google****
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>