Subject: [hybi] Issue tracker

From: Salvatore Loreto <[email-masked]>
Date: Wed, 12 May 2010 15:07:05 +0300

Hi there,

during the last meeting in Anaheim we announced the intention to start using
the *issue tracker* to better track the progress of WG documents as well as
the consensus on some particular topic/issue.

The idea is to keep discussing issues on the mailing list, and to use 
the tool to
well keep track of them for the benefit of the chairs in first place, 
but also of the
authors and the whole working group.

We have started inserting two issues that had been already identified 
both on the mailing
list and during the face to face meeting.
Anyone is welcome to suggest new issues (if you have one that want to be 
on the list
please send an email to the chairs)  and comment on the existing one via 
the tool
or on the list.

As this is a sort of experiment, any kind of feedback about the issues 
and the process itself
is very welcome.

Cheers
Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 12 May 2010 17:59:46 +0100

Salvatore Loreto wrote:
> The idea is to keep discussing issues on the mailing list, and to
> use the tool to well keep track of them for the benefit of the
> chairs in first place, but also of the authors and the whole working
> group.
> 
> We have started inserting two issues that had been already
> identified both on the mailing list and during the face to face
> meeting.  Anyone is welcome to suggest new issues (if you have one
> that want to be on the list please send an email to the chairs) and
> comment on the existing one via the tool or on the list.
> 
> and the process itself is very welcome.

+1 excellent plan.

There's been a huge number of good ideas, different approaches,
anticipated problems, and open questions discussed on the list over
the last year.

-- Jamie

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 12 May 2010 21:52:38 +0300

let me clarify about how we intend to work

1) Even if anyone is welcome to suggest issues,
    only the chairs are allowed to create a new issues!

2) We discuss the issues on the list for a while

3)  Issues related to WG documents will be initially
     assigned to one of the authors ( mainly because the tool allows to enter
     only one assignee ).

4) the assignee (or the WG document authors) come up with a form of words that
    they think matches the consensus and attach a diff to the trac

5) if there is a consensus on the text, the author will add it to the WG document
    and the issues will be closed.
    if there is no consensus on the text go back to 4)

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Ian Hickson <[email-masked]>
Date: Thu, 13 May 2010 01:36:34 +0000 (UTC)

>    if there is no consensus on the text go back to 4)

That sounds like a huge amount of overhead. Here are the issues that I'm 
currently aware of for Web Sockets:

   http://www.whatwg.org/issues/#websocket

Do I need to send an e-mail for each one of these to raise it as an issue? 
Doing so would likely take us ten times more time than just going ahead 
and fixing the problems would.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: SM <[email-masked]>
Date: Thu, 13 May 2010 00:14:52 -0700

>and fixing the problems would.

Yes.

If there isn't consensus, the issue might be raised again and the fix 
undone.  It's going to take much more time and effort then.

Regards,
-sm

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 13 May 2010 00:23:04 -0700

>   only the chairs are allowed to create a new issues!

Why not allow anyone create issues, or at least anyone in the WG? I don't see a reason to bottleneck issue creation through the chairs. Anyone should be able to report a problem.

Regards,
Maciej

---

From: Ian Hickson <[email-masked]>
Date: Thu, 13 May 2010 07:57:15 +0000 (UTC)

> undone. It's going to take much more time and effort then.

If there's N issues, and it takes P time to walk each one through the 
proposed procedure plus Q time for the editor to do the edit, then it will 
take N*P+N*Q time to address the issues. However, if instead we just 
do the edits and only go through the procedure for controversial issues 
(issues where the change results in a request for a reversion of the 
change or where the resulting change is not satisfactory), and we assume 
that there's a fraction F of issues that are controversial, then it would 
take N*P+N*F*(Q+P) time.

This means it's more efficient to use this "escalation" process rather 
than putting everything through the heavy-weight process if F is less
than 1/(P/Q+1), which, assuming the fraction of controversial issues is 
less than 80% and the time for the editor to edit the spec is on average 
60 minutes, is true for any value of P greater than about 4 hours, which 
seems quite low given the proposed process.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 13 May 2010 10:10:02 +0200

>    http://www.whatwg.org/issues/#websocket

Ian,

many of those "issues" on that page appear to be individual postings
and arguments that would be covered by one issue in trac.

They even include postings whos entire content is:

   Correct: his name is "Ian Hickson".

So I don't think you will need to raise issues for each and everyone
of these.

regards

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 13 May 2010 12:08:07 +0300

>     http://www.whatwg.org/issues/#websocket
Hi Ian,
thanks for the pointer, and to have collect the WebSocket issues so far.
I wasn't not aware of the link, and I guess a lot of people were in the 
same situation.

as this is an IETF draft we have agreed to use the IETF Issue Tracker to 
collect them,
in this way give also a clear view of the amounts of issues that are 
related to each draft
and a clear knowledge of what those issues are.

> Do I need to send an e-mail for each one of these to raise it as an issue?
If you really think that an issue is important and it is worth to 
discuss it within the community,
then you should send by mail to the mailing list and ask to add it to 
the Issue tracker

> and fixing the problems would.
in order to fix an issue and going ahead you have to discuss how to fix 
within the community
and allow all the people to contribute to the discussion.
Discussing and building consensus is always a time consuming task, but 
it helps a lot in writing
a good and robust protocol leveraging on the help and the experience of 
a lot of people

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 13 May 2010 12:35:59 +0300

Hi Maciej,

as I have written in my first mail this is an experiment, and as such it 
can be changed based on feedback.
However we would like to go this way for the time being, to see how this 
work.

cheers
Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: SM <[email-masked]>
Date: Thu, 13 May 2010 02:58:27 -0700

Hi Ian,
>that there's a fraction F of issues that are controversial, then it would

First of all, it is important to keep in mind that an editor 
expresses the consensus of a WG.  We could take a procedural approach 
where every change goes through what you described above.  Or we can 
have a less stringent approach where we do editorial changes, go 
ahead with uncontroversial changes and tackle the rest as issues.  If 
these issues require a revision of the I-D, we end up with I-Ds that 
do not reflect the rough consensus.  If an implementation is tracking 
the I-Ds, this can cause problems.

Although reversions may happen in practice, it is problematic 
process-wise if we assume consensus and require a reversion of the 
change when someone raises an issue.

>seems quite low given the proposed process.

The IETF process is not light-weight.  The composition of the WG 
influences the speed of the work.  If the editor has to wait for the 
outcome of consensus calls to resolve each issue, the person is going 
to spend much more time editing the specification.  And that could 
happen with an "escalation" process.  If the editor does not try to 
reflect the consensus of the WG, people may end up being annoyed and 
take any action they see fit.  The end-result will be more than inefficient.

Regards,
-sm

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 13 May 2010 03:37:39 -0700

On May 13, 2010, at 2:35 AM, Salvatore Loreto wrote:

> Hi Maciej,
> 
> as I have written in my first mail this is an experiment, and as such it can be changed based on feedback.
> However we would like to go this way for the time being, to see how this work.

My feedback is to please let anyone raise an issue. At the very least you should let document editors raise issues.

I also don't think "this is an experiment" is a good reason to make issue raising overly restricted. What problem are we trying to solve? How will we know if the experiment in severely restricting issue raising is a success?

Regards,
Maciej

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 13 May 2010 17:03:11 +0300

the reason to have a restriction on raising issues is to try to focus 
the attention and the energy on
not many requirements...
as a tentative to check if the use of the issue tracker would help to 
reach a clear consensus on specific issues!

as the issues are related to a document, I think you are right that the 
document editors should already have the
possibility to raise issues.
So now all the editors of wg document that are logged in may create and 
comment on tickets.

cheers
Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Ian Hickson <[email-masked]>
Date: Thu, 13 May 2010 21:21:18 +0000 (UTC)

On Thu, 13 May 2010, Salvatore Loreto wrote:
> discuss it within the community, then you should send by mail to the 
> mailing list and ask to add it to the Issue tracker

Could you give me some guidelines for how I should decide whether an issue 
should result in my following the process above or whether it should 
result in me just fixing the spec? The process you outline above doesn't 
seem to leave any room for me not raising issues. Should I raise all 
issues? If not, how should I determine what issues to raise?

> it helps a lot in writing a good and robust protocol leveraging on the 
> help and the experience of a lot of people

Consensus is not required to write a good and robust protocol leveraging 
on the help and the experience of a lot of people. Determining consensus 
also doesn't need to be time-consuming. However, while my preference is 
for a trivial (and fast!) proven process such as the WHATWG's, as used so 
far in the development of Web Sockets, I'm willing to use whatever process 
you come up with, so long as it is clearly defined.

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 18 May 2010 14:13:52 +0300

> issues? If not, how should I determine what issues to raise?

[Sal] As editor of the document you do not need to necessarily check all 
the details with the WG
before submit a new draft and its up to you judge what to do with each 
specific issue:
if you are confident that the way you are fixing the spec has the 
consensus (perhaps because it has
already been discussed) or it will receive the rough consensus from the 
wg, then go ahead and fix it;
if not it is better follow the process listed above.
Alternatively, if you are not sure you can also decide to go ahead with 
the fix you have in mind,
but you should mark it  properly in the draft with something like ISSUE 
or NewProposal or whatever
you find appropriate as maker.

Cheers
Sal

Salvatore Loreto
www.sloreto.com

---

From: Ian Hickson <[email-masked]>
Date: Tue, 18 May 2010 21:05:25 +0000 (UTC)

On Tue, 18 May 2010, Salvatore Loreto wrote:
> > > > > 1) Even if anyone is welcome to suggest issues, only the chairs 
> > > > > are allowed to create a new issues!
> > > > > 
> > > > > 3) Issues related to WG documents will be initially assigned to 
> > > > > one of the authors ( mainly because the tool allows to enter 
> > > > > only one assignee ).
> > > > > 
> > > > > 4) the assignee (or the WG document authors) come up with a form 
> > > > > of words that they think matches the consensus and attach a diff 
> > > > > to the trac
> > > > > 
> > > > > 5) if there is a consensus on the text, the author will add it 
> > > > > to the WG document and the issues will be closed. if there is no 
> > > > > consensus on the text go back to 4)
> 
> As editor of the document you do not need to necessarily check all the 
> details with the WG before submit a new draft and its up to you judge 
> what to do with each specific issue: if you are confident that the way 
> you are fixing the spec has the consensus (perhaps because it has 
> wg, then go ahead and fix it; if not it is better follow the process 
> listed above.

By consensus do you mean unanimous consent, explicit objections 
outnumbered by explicit support, that objections only come from a 
minority, or something else? What population is relevant for determining 
this; the mailing list membership, the IETF membership, the working group 
and the WHATWG membership, the Web community as a whole, or something 
else? Should consensus be considered more important than technical 
correctness and interoperability with implementations, or should making 
the spec technically sound and making the spec match reality be considered 
more important than consensus?

Any advice you may have on this would be very welcome. I'm not used to the 
IETF process and the W3C and WHATWG do things quite differently, so I 
don't want to make any assumptions about what you meant.

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 19 May 2010 03:16:53 +0100

> you come up with, so long as it is clearly defined.

You keep saying WHATWG's process is fast, and presumably you're implying
it manages to leverage the experience of a lot of people.

I'm rather interested.  Can you say a bit about how the WHATWG process
goes about and achieves this, that is different from the process here?

Do you imagine the WHATWG process could achieve the same goals that
appear (to you) to be the aim of the IETF process, but more quickly?

>From my point of view (a distant and oblique observer of parts of
HTML5) the WHATWG process has been good at getting browser vendors to
agree on APIs for fun things that people can hack on top of, instead
of the old days where they hacked on top of browser-specific methods
for many of the same things.  I'm not sure if the WHATWG process has
successfully produced any new or versatile technology that has real
impact on the network, though, and I haven't heard of any way it takes
into account network and server engineering perspectives - which
WebSocket is certainly expected to impact.  If you have shining
examples where it did, that would be interesting.

You may guess that I don't think WHATWG is a good match for the
WebSocket engineering aspects (for the browser API, I'm sure it's
great), which is I guess why the IETF are involved, but I'm more than
curious if there is process you've witnessed/experienced which could
improve the one over here while successfully taking into consideration
network and server engineering perspectives from many experienced people.

Thanks (I mean that),
-- Jamie

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 19 May 2010 11:36:43 +0300

On 5/19/10 12:05 AM, Ian Hickson wrote:
> minority, or something else?
[Sal]

    "/The general rule on disputed topics is that the Working Group has
    to come to "rough consensus",
      meaning that a very large majority of those who care must agree./"
    ( The Tao of IETF)

    as chair, I consider "those who care must" all the people that are
    involved in the HyBi mailing list discussion!

>   What population is relevant for determining
> else?
[Sal] the draft is intended to be an IETF draft, and the HyBi chairs 
will only consider the discussion within the HyBi mailing list
          as relevant for determining consensus; even if I am also 
monitoring the [email-masked] mailing list.
          the HyBi mailing list is open to anyone who care, the IETF 
community is open to anyone and does not exist anything
          like a membership.
          So the Web community as a whole is very welcome to join the 
discussion in the HyBi mailing list,
          if they do not care to join the discussion then is quite 
difficult to judge their opinion!

> Should consensus be considered more important than technical
[Sal]
           it is quite unlikely that the consensus does not match a 
solution that is technically correct
           and interoperable with implementations.

    /"Rough consensus has been defined in many ways; a simple version is
    that it means that strongly held objections must be debated
    until most people are satisfied that these objections are wrong."
    /(The Tao of IETF)

I think that at this point everything should be clear,
if not the IETF process is publicly and fully explained here: 
http://www.ietf.org/tao.html

Ian please go ahead and submit the -76 as wg item!

cheers
Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Ian Hickson <[email-masked]>
Date: Sun, 23 May 2010 06:29:22 +0000 (UTC)

On Wed, 19 May 2010, Salvatore Loreto wrote:
> > > > > > > 1) Even if anyone is welcome to suggest issues, only the 
> > > > > > > chairs are allowed to create a new issues!
> > > > > > > 
> > > > > > > 3) Issues related to WG documents will be initially assigned 
> > > > > > > to one of the authors ( mainly because the tool allows to 
> > > > > > > enter only one assignee ).
> > > > > > > 
> > > > > > > 4) the assignee (or the WG document authors) come up with a 
> > > > > > > form of words that they think matches the consensus and 
> > > > > > > attach a diff to the trac
> > > > > > > 
> > > > > > > 5) if there is a consensus on the text, the author will add 
> > > > > > > it to the WG document and the issues will be closed. if 
> > > > > > > there is no consensus on the text go back to 4)
> > >
> > > As editor of the document you do not need to necessarily check all 
> > > the details with the WG before submit a new draft and its up to you 
> > > judge what to do with each specific issue: if you are confident that 
> > > the way you are fixing the spec has the consensus (perhaps because 
> > > it has already been discussed) or it will receive the rough 
> > > consensus from the wg, then go ahead and fix it; if not it is better 
> > > follow the process listed above.
> 
> "/The general rule on disputed topics is that the Working Group has to 
> come to "rough consensus", meaning that a very large majority of those 
> who care must agree./"
>  (The Tao of IETF)
> 

Do you mean all the subscribers to the mailing list, or all those posting? 
If the latter, over what time period?

How large a majority is "very large"?

> So the Web community as a whole is very welcome to join the discussion 
> in the HyBi mailing list, if they do not care to join the discussion 
> then is quite difficult to judge their opinion!

It's actually very easy to determine their opinion; we can just ask them, 
or follow their discussions elsewhere. For example, I regularly partake in 
discussions about HTML5 on Reddit, on IRC, and in other forums, even 
though many people there aren't in the HTML working group. Indeed, using 
Google alerts and Backtype alerts one is able to get a very good sense of 
where people outside the working group stand.

However, while I obviously will continue to look at those sources of 
input, I understand that we'd want to ignore this feedback when 
determining "consensus", if we're going to use a consensus-based approach.

> > correctness and interoperability with implementations, or should 
> > making the spec technically sound and making the spec match reality be 
> > considered more important than consensus?
>
> it is quite unlikely that the consensus does not match a solution that 
> is technically correct and interoperable with implementations.

I wish I could share your optimism.

---

From: Scott Ferguson <[email-masked]>
Date: Sun, 23 May 2010 08:43:35 -0700

> determining "consensus", if we're going to use a consensus-based approach.
We have representatives from at least 3 HTTP browser implementors here, 
at least 2 HTTP server implementors, and others with extensive 
networking experience, and the IETF is the proper venue for internet 
protocol specifications.

It's clear that you're planning to ignore the IETF working group in 
favor of selected voices in the HTML community who agree with you, but 
lets at least be honest about that intent, instead of pretending 
confusion over the concept of consensus. It's always possible to shop 
around to find people who agree with you, especially if you ask people 
with with the wrong expertise.
>> is technically correct and interoperable with implementations.

Correct.  However, since you've also selected an editor who's opposed to 
the IETF entirely (opposing to conforming  the HTTP spec when using the 
HTTP port), there's only a slim chance that the specification will 
reflect the consensus.
> I wish I could share your optimism.

Correct. It's clear the spec will not reflect the consensus.

-- Scott

---

From: SM <[email-masked]>
Date: Sun, 23 May 2010 10:42:32 -0700

>If the latter, over what time period?

The IETF uses "an open process in which any technical opinion will be 
heard and any participant's concerns addressed".  Any subscriber to 
this mailing list can post comments.    The period is announced at 
the time of the consensus call.

>How large a majority is "very large"?

There is no such thing as majority as that is akin to voting.  Based 
on your questions, it seems that you have some difficult grasping the 
concept of consensus.

>where people outside the working group stand.

People outside an IETF mailing list are not IETF participants.  There 
is the question of BCP 78 and BCP 79 which might affect external 
"specifications".  Some participants in this working group could invoke that.

>determining "consensus", if we're going to use a consensus-based approach.

Nobody suggested ignoring any feedback which conforms to BCP 78 and BCP 79.

At 08:43 23-05-10, Scott Ferguson wrote:
>Correct.  However, since you've also selected an editor who's 
>opposed to the IETF entirely (opposing to conforming  the HTTP spec 
>when using the HTTP port), there's only a slim chance that the 
>specification will reflect the consensus.

I doubt that the specification would be published as a RFC if it does 
not reflect the consensus of the IETF.

Regards,
-sm

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 23 May 2010 23:35:25 +0200

> Correct. It's clear the spec will not reflect the consensus.

Scott,

The fundamental problem is that Ian as editor of the draft does not
appear willing to accept the consensus view if he thinks it contradicts his
personal view of what is technically sound.  He  rejects the concept
that technical soundness can be determined by rough consensus.

As such, I do not believe that the IETF process can work  with Ian as editor.

---

From: Scott Ferguson <[email-masked]>
Date: Mon, 24 May 2010 11:40:45 -0700

> As such, I do not believe that the IETF process can work  with Ian as editor.
That is my concern.

The outstanding issues that I've been following fall into the following 
groupings:

1. simple but important issues that are easily resolvable:
1a. HTTP compliance and/or avoiding the HTTP port
1b. binary support
1c. binary fragmentation/chunking (required for 1b)

The above are all trivial and fixing them are important for WebSockets 
to have a broad application base, but progress has stalled for months 
because the editor opposes the necessary changes to the spec, despite 
the broad support and technical value.

2. RTT fixes/client pipelining

This group is tougher, but important because not fixing it restricts the 
classes of applications that can use WebSockets, making HTTP itself a 
better solution. However, any real discussion of this issue is stymied 
by the editors opposition (without any solid reason for opposition.)

3. multiplexing/server load/resource issues

Whether or not we want to treat multiplexing as an extension, part of 
the main spec, or not addressed at all, it's an issue that needs to be 
discussed and has been brought up repeatedly as an issue by most of the 
server vendors and by others. Yet, this issue is entirely ignored, 
mostly I think because if we can't even resolve no-brainer issues like 
HTTP compliance while using the HTTP port, there's no point discussing 
anything as complicated as a multiplexing extension.

4. server events and the associated long-lived connection problem

As Roy Fielding pointed out, we may want to broaden the discussion space 
for this topic beyond ideas like multiplexing (e.g. to discussion client 
accept() ports/callbacks, proxies, etc.) And the server-sent event topic 
is at the heart of making WebSockets work.  Yet, if we can't discuss #3 
because it's too complicated, we have no hope of opening up this discussion.

Oh, and also,

5. security

The "security" features in the current draft like the key1/key2 and the 
random bytes are absurd, but there's almost no point discussing them 
because, really, where do you start discussing something that confused?

All these topics can be addressed by this group, because we have the 
expertise collectively, but those discussions are stuck because it's 
clear that the specification itself will not reflect any consensus.

-- Scott
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>
>
>