[hybi] Revision of draft-ietf-hybi-thewebsocketprotocol-00

[S Moonesamy]

Hi Ian,

The Abstract Section of draft-ietf-hybi-thewebsocketprotocol-00
contains the following text:

"NOTE! THIS COPY OF THIS DOCUMENT IS OBSOLETE.

For an up-to-date copy of this specification, please see:

http://www.whatwg.org/specs/web-socket-protocol/"

And:

"Author's note

This document is automatically generated from the same source
document as the HTML specification. [HTML]

Please send feedback to either the ***@ietf.org list or the
***@whatwg.org list."

As draft-ietf-hybi-thewebsocketprotocol-00 is a work item of the HyBi
Working Group, the document is not obsolete.

The Author's note is not in line with IETF practices as comments
about working group drafts should be sent to the relevant IETF
mailing list; i.e. ***@ietf.org in this case.

Please submit a revision of draft-ietf-hybi-thewebsocketprotocol-00
by August 16, 2010 with the following changes:

(i) Removal of the obsolete note as quote above.

(ii) Removal of the Author's Note as quote above.

Regards,
S. Moonesamy
HyBi WG Secretary

[Adam Barth]

As a curiosity, what's the basis of this message? Is this a decision
from the chairs or some other folks at the IETF? Is this the
consensus of the working group? I'm confused by the authoritarian
tone of your message.

Adam


On Thu, Aug 12, 2010 at 2:56 PM, S Moonesamy <sm+***@elandsys.com> wrote:
> Hi Ian,
>
> The Abstract Section of draft-ietf-hybi-thewebsocketprotocol-00 contains the
> following text:
>
>  "NOTE!  THIS COPY OF THIS DOCUMENT IS OBSOLETE.
>
>   For an up-to-date copy of this specification, please see:
>
>   http://www.whatwg.org/specs/web-socket-protocol/"
>
> And:
>
>  "Author's note
>
>   This document is automatically generated from the same source
>   document as the HTML specification.  [HTML]
>
>   Please send feedback to either the ***@ietf.org list or the
>   ***@whatwg.org list."
>
> As draft-ietf-hybi-thewebsocketprotocol-00 is a work item of the HyBi
> Working Group, the document is not obsolete.
>
> The Author's note is not in line with IETF practices as comments about
> working group drafts should be sent to the relevant IETF mailing list; i.e.
> ***@ietf.org in this case.
>
> Please submit a revision of draft-ietf-hybi-thewebsocketprotocol-00 by
> August 16, 2010 with the following changes:
>
>  (i)  Removal of the obsolete note as quote above.
>
>  (ii) Removal of the Author's Note as quote above.
>
> Regards,
> S. Moonesamy
> HyBi WG Secretary
>
> _______________________________________________
> hybi mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

[Alexey Melnikov]

Adam Barth wrote:

>As a curiosity, what's the basis of this message? Is this a decision
>from the chairs or some other folks at the IETF?
>
Adam,
Yes, SM is acting in his capacity of the WG Secretary by the authority
given to him by the WG chairs.

>Is this the
>consensus of the working group? I'm confused by the authoritarian
>tone of your message.
>
>Adam
>
>
>On Thu, Aug 12, 2010 at 2:56 PM, S Moonesamy <sm+***@elandsys.com> wrote:
>
>
>>Hi Ian,
>>
>>The Abstract Section of draft-ietf-hybi-thewebsocketprotocol-00 contains the
>>following text:
>>
>> "NOTE! THIS COPY OF THIS DOCUMENT IS OBSOLETE.
>>
>> For an up-to-date copy of this specification, please see:
>>
>> http://www.whatwg.org/specs/web-socket-protocol/"
>>
>>And:
>>
>> "Author's note
>>
>> This document is automatically generated from the same source
>> document as the HTML specification. [HTML]
>>
>> Please send feedback to either the ***@ietf.org list or the
>> ***@whatwg.org list."
>>
>>As draft-ietf-hybi-thewebsocketprotocol-00 is a work item of the HyBi
>>Working Group, the document is not obsolete.
>>
>>The Author's note is not in line with IETF practices as comments about
>>working group drafts should be sent to the relevant IETF mailing list; i.e.
>>***@ietf.org in this case.
>>
>>Please submit a revision of draft-ietf-hybi-thewebsocketprotocol-00 by
>>August 16, 2010 with the following changes:
>>
>> (i) Removal of the obsolete note as quote above.
>>
>> (ii) Removal of the Author's Note as quote above.
>>
>>Regards,
>>S. Moonesamy
>>HyBi WG Secretary
>>
--
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

[Pieter Hintjens]

On Fri, Aug 13, 2010 at 12:11 AM, Adam Barth <***@adambarth.com> wrote:

> As a curiosity, what's the basis of this message?  Is this a decision
> from the chairs or some other folks at the IETF?  Is this the
> consensus of the working group?  I'm confused by the authoritarian
> tone of your message.

Adam,

The chairs asked Ian to fix these two aspects of the spec on June 21,
for what seem to be fairly obvious and justified reasons. The draft
spec cannot invite discussion outside the IETF structures and cannot
hold another text as authoritative, or else the IETF process has no
meaning and this workgroup is rendered irrelevant.

Given that the change was requested almost two months ago, it seems
correct to ask for it again with a deadline.

-Pieter

[Adam Barth]

On Thu, Aug 12, 2010 at 3:25 PM, Pieter Hintjens <***@imatix.com> wrote:
> On Fri, Aug 13, 2010 at 12:11 AM, Adam Barth <***@adambarth.com> wrote:
>> As a curiosity, what's the basis of this message?  Is this a decision
>> from the chairs or some other folks at the IETF?  Is this the
>> consensus of the working group?  I'm confused by the authoritarian
>> tone of your message.
>
> The chairs asked Ian to fix these two aspects of the spec on June 21,
> for what seem to be fairly obvious and justified reasons.  The draft
> spec cannot invite discussion outside the IETF structures and cannot
> hold another text as authoritative, or else the IETF process has no
> meaning and this workgroup is rendered irrelevant.
>
> Given that the change was requested almost two months ago, it seems
> correct to ask for it again with a deadline.

Oh, I must have missed or forgotten the earlier message. So S.
Moonesamy is speaking on behalf of the chairs.

Thanks,
Adam

[Pieter Hintjens]

On Fri, Aug 13, 2010 at 12:28 AM, Adam Barth <***@adambarth.com> wrote:

> Oh, I must have missed or forgotten the earlier message.  So S.
> Moonesamy is speaking on behalf of the chairs.
>
> Thanks,
> Adam

Adam,

Here's the relevant email from June:
http://www.ietf.org/mail-archive/web/hybi/current/msg02137.html

-Pieter

[Adam Barth]

On Thu, Aug 12, 2010 at 3:31 PM, Pieter Hintjens <***@imatix.com> wrote:
> On Fri, Aug 13, 2010 at 12:28 AM, Adam Barth <***@adambarth.com> wrote:
>> Oh, I must have missed or forgotten the earlier message.  So S.
>> Moonesamy is speaking on behalf of the chairs.
>
> Here's the relevant email from June:
> http://www.ietf.org/mail-archive/web/hybi/current/msg02137.html

Thanks. That would have been helpful context to include in the
original message. One note: the earlier message invites Ian to remove
the author's note whereas the message today instructs him to do so.
Presumably the escalation there is also under the authority of the
chairs.

Kind regards,
Adam

[Ian Hickson]

On Thu, 12 Aug 2010, S Moonesamy wrote:
>
> The Abstract Section of draft-ietf-hybi-thewebsocketprotocol-00 contains
> the following text:
>
> "NOTE! THIS COPY OF THIS DOCUMENT IS OBSOLETE.
>
> For an up-to-date copy of this specification, please see:
>
> http://www.whatwg.org/specs/web-socket-protocol/"
>
> And:
>
> "Author's note
>
> This document is automatically generated from the same source
> document as the HTML specification. [HTML]
>
> Please send feedback to either the ***@ietf.org list or the
> ***@whatwg.org list."
>
> As draft-ietf-hybi-thewebsocketprotocol-00 is a work item of the HyBi
> Working Group, the document is not obsolete.

I'm happy to use other terminology if you would like, or alternatively to
resume sending every update to the IETF site. My concern is that
implementors (in particular, browser vendors) should make sure to use the
latest draft, so that we do not end up with a fragmented implementation
base. This has been a real problem with this specification, in particular
after I was asked to stop updating the draft on the IETF site at the
frequency with which the specification was uploaded. Would you prefer I
change the terminology, or that I resume the immediate updates? If the
former, what terminology would be more in line with IETF policy? Should I
replace "is obsolete" with "may not contain the latest updates"?


> The Author's note is not in line with IETF practices as comments about
> working group drafts should be sent to the relevant IETF mailing list;
> i.e. ***@ietf.org in this case.

The draft is also published as part of the WHATWG specification, and
feedback is therefore on occasion sent to the ***@whatwg.org mailing
list. It would be helpful to readers to know this. Is it against IETF
policy to suggest sending feedback to that list, or is it against IETF
policy to even acknowledge the existence of other mailing lists? If only
the former, I think it would be helpful if we could at least mention that
this occurs, even if we discourage it.

Please let me know which it is so that I can update the draft as
requested.


On Fri, 13 Aug 2010, Pieter Hintjens wrote:
>
> The chairs asked Ian to fix these two aspects of the spec on June 21,
> for what seem to be fairly obvious and justified reasons.

I replied:

http://www.ietf.org/mail-archive/web/hybi/current/msg02252.html

...but the chairs did not answer my questions.

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

[S Moonesamy]

Hi Ian,
At 15:41 12-08-10, Ian Hickson wrote:
>I'm happy to use other terminology if you would like, or alternatively to
>resume sending every update to the IETF site. My concern is that

[snip]

I'll reply to this part of your message in a longer note.

>Please let me know which it is so that I can update the draft as
>requested.

Please submit a revision of draft-ietf-hybi-thewebsocketprotocol with
the changes that were requested in my previous message [1].

Regards,
S. Moonesamy
HyBi WG Secretary

1. http://www.ietf.org/mail-archive/web/hybi/current/msg03136.html

[Ian Hickson]

On Thu, 12 Aug 2010, S Moonesamy wrote:
>
> Please submit a revision of draft-ietf-hybi-thewebsocketprotocol with
> the changes that were requested in my previous message [1].

I am very happy to work with you and the chairs and the working group and
whoever else to find wording that encourages interoperability, gives
readers a full understanding of the situation, and fulfills whatever
policies you may care about.

However, I'm not going to regress the specification text. Removing the
text pointing to the latest version and removing the text saying where
that feedback should be sent (even if that's just the hybi list and we
stick our head in the sand about the WHATWG list) is a bad idea, which
will directly lead to worse implementations and worse interoperability. My
primary concern is with fostering interoperability, far above any IETF
policies that might contradict such a goal, and I will not act in a way to
harm interoperability.

Here is proposed text to replace the two sections you mentioned:

Abstract

[...]

NOTE! THIS COPY OF THIS DOCUMENT IS NOT THE EDITOR'S DRAFT AND
THEREFORE MAY NOT CONTAIN THE LATEST CHANGES.

For an up-to-date copy of this specification, please see:

http://www.whatwg.org/specs/web-socket-protocol/

Author's note

Please send feedback to the ***@ietf.org mailing list.

This document is automatically generated from the same source
document as the HTML specification, and is also published in HTML
form as part of the WHATWG Web Applications 1.0 specification.
Feedback is therefore also occasionally sent, against IETF policy, to
the ***@whatwg.org mailing list.

Would this address your concerns?

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

[L***@surrey.ac.uk]

It's been almost two months, including an IETF meeting, and this situation is getting increasingly farcical.

The WHATWG oversight committee has the ability to override the WHATWG editor (Hixie).

There should be direct dialogue between the IETF chairs and AD and the oversight committee. The results of that dialogue can then
be communicated to Hixie and the rest of us.

(Please include discussion of development timescales and mismatched expectations of the different communities in that dialogue.)

Hixie: The message above was written without saying 'I' or 'my'. Try it.

________________________________________
From: hybi-***@ietf.org [hybi-***@ietf.org] On Behalf Of Ian Hickson [***@hixie.ch]
Sent: 13 August 2010 00:25
To: ***@ietf.org
Subject: Re: [hybi] Revision of draft-ietf-hybi-thewebsocketprotocol-00

On Thu, 12 Aug 2010, S Moonesamy wrote:
>
> Please submit a revision of draft-ietf-hybi-thewebsocketprotocol with
> the changes that were requested in my previous message [1].

I am very happy to work with you and the chairs and the working group and
whoever else to find wording that encourages interoperability, gives
readers a full understanding of the situation, and fulfills whatever
policies you may care about.

However, I'm not going to regress the specification text. Removing the
text pointing to the latest version and removing the text saying where
that feedback should be sent (even if that's just the hybi list and we
stick our head in the sand about the WHATWG list) is a bad idea, which
will directly lead to worse implementations and worse interoperability. My
primary concern is with fostering interoperability, far above any IETF
policies that might contradict such a goal, and I will not act in a way to
harm interoperability.

Here is proposed text to replace the two sections you mentioned:

Abstract

[...]

NOTE! THIS COPY OF THIS DOCUMENT IS NOT THE EDITOR'S DRAFT AND
THEREFORE MAY NOT CONTAIN THE LATEST CHANGES.

For an up-to-date copy of this specification, please see:

http://www.whatwg.org/specs/web-socket-protocol/

Author's note

Please send feedback to the ***@ietf.org mailing list.

This document is automatically generated from the same source
document as the HTML specification, and is also published in HTML
form as part of the WHATWG Web Applications 1.0 specification.
Feedback is therefore also occasionally sent, against IETF policy, to
the ***@whatwg.org mailing list.

Would this address your concerns?

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

[S Moonesamy]

Hi Ian,
At 16:25 12-08-10, Ian Hickson wrote:
>I am very happy to work with you and the chairs and the working group and
>whoever else to find wording that encourages interoperability, gives
>readers a full understanding of the situation, and fulfills whatever
>policies you may care about.

According to BCP 9, "under no circumstances should an Internet-Draft
be referenced by any paper, report, or Request-for-Proposal, nor
should a vendor claim compliance with an
Internet-Draft. draft-ietf-hybi-thewebsocketprotocol is "Work in Progress".

>However, I'm not going to regress the specification text. Removing the
>text pointing to the latest version and removing the text saying where
>that feedback should be sent (even if that's just the hybi list and we
>stick our head in the sand about the WHATWG list) is a bad idea, which
>will directly lead to worse implementations and worse interoperability. My
>primary concern is with fostering interoperability, far above any IETF
>policies that might contradict such a goal, and I will not act in a way to
>harm interoperability.
>
>Here is proposed text to replace the two sections you mentioned:
>
> Abstract
>
> [...]
>
> NOTE! THIS COPY OF THIS DOCUMENT IS NOT THE EDITOR'S DRAFT AND
> THEREFORE MAY NOT CONTAIN THE LATEST CHANGES.
>
> For an up-to-date copy of this specification, please see:
>
> http://www.whatwg.org/specs/web-socket-protocol/
>
> Author's note
>
> Please send feedback to the ***@ietf.org mailing list.
>
> This document is automatically generated from the same source
> document as the HTML specification, and is also published in HTML
> form as part of the WHATWG Web Applications 1.0 specification.
> Feedback is therefore also occasionally sent, against IETF policy, to
> the ***@whatwg.org mailing list.
>
>Would this address your concerns?

This does not address the points mentioned in my previous
messages. A Document Editor is responsible for ensuring that the
contents of the document accurately reflect the decisions that have
been made by the working group. Your proposed text does not reflect that.

It is also a general practice for a Document Editor to help ensure
that that all processes are followed.

Regards,
S. Moonesamy
HyBi WG Secretary

[Ian Hickson]

On Thu, 12 Aug 2010, S Moonesamy wrote:
> Hi Ian,
> At 16:25 12-08-10, Ian Hickson wrote:
> > I am very happy to work with you and the chairs and the working group
> > and whoever else to find wording that encourages interoperability,
> > gives readers a full understanding of the situation, and fulfills
> > whatever policies you may care about.
>
> According to BCP 9, "under no circumstances should an Internet-Draft be
> referenced by any paper, report, or Request-for-Proposal, nor should a
> vendor claim compliance with an Internet-Draft.
> draft-ietf-hybi-thewebsocketprotocol is "Work in Progress".

I don't understand the relevance of this. Who is referencing the draft or
claiming conformance to it?

My concern is not with people claiming conformance, it's with people
implementing it, of which there are many. It's imperative that people
implement the same thing, not old versions of the specification.

As I see it there are two ways to address this:

1. Make sure all versions are up to date.

2. Make sure versions that aren't up to date point to the version that is
up to date.

When Joe and I met a few months ago, Joe asked me to not update the
version on the IETF site as frequently. Therefore option 1 isn't available
to us. This leaves only option 2 as far as I can tell. I'm happy to use
option 1; that would indeed by far preferable to me. However, that
contradicts instructions I've received so far. Do those intstructions no
longer apply? I'm open to other options, if you have any. Simply ignoring
this situation, however, is not a good option.

Similar points apply to the other paragraph in question.


> > Here is proposed text to replace the two sections you mentioned:
> >
> > Abstract
> >
> > [...]
> >
> > NOTE! THIS COPY OF THIS DOCUMENT IS NOT THE EDITOR'S DRAFT AND
> > THEREFORE MAY NOT CONTAIN THE LATEST CHANGES.
> >
> > For an up-to-date copy of this specification, please see:
> >
> > http://www.whatwg.org/specs/web-socket-protocol/
> >
> > Author's note
> >
> > Please send feedback to the ***@ietf.org mailing list.
> >
> > This document is automatically generated from the same source
> > document as the HTML specification, and is also published in HTML
> > form as part of the WHATWG Web Applications 1.0 specification.
> > Feedback is therefore also occasionally sent, against IETF policy, to
> > the ***@whatwg.org mailing list.
> >
> > Would this address your concerns?
>
> This does not address the points mentioned in my previous messages.

It doesn't say the IETF version is obsolete and it doesn't recommend using
the WHATWG list. What points does it not address?


> A Document Editor is responsible for ensuring that the contents of the
> document accurately reflect the decisions that have been made by the
> working group. Your proposed text does not reflect that.

What decisions does it not reflect? I would be happy to correct this to
reflect any relevant decisions.


> It is also a general practice for a Document Editor to help ensure that
> that all processes are followed.

I'm trying to follow all the processes, but I don't think that should
preclude us doing the right thing as well. (Having said that, it's more
important that we foster interoperability than that we follow processes.
Without interoperability, the group is irrelevant. Without processes, the
group can still make progress.)

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

[S Moonesamy]

Hi Ian,
At 17:11 12-08-10, Ian Hickson wrote:
>My concern is not with people claiming conformance, it's with people
>implementing it, of which there are many. It's imperative that people
>implement the same thing, not old versions of the specification.

Your concern is noted. However, it does not take precedence on the
concerns of this working group and the work this working group is
chartered to do.

>As I see it there are two ways to address this:
>
> 1. Make sure all versions are up to date.
>
> 2. Make sure versions that aren't up to date point to the version that is
> up to date.

Your suggestions will be taken into consideration.

>It doesn't say the IETF version is obsolete and it doesn't recommend using
>the WHATWG list. What points does it not address?

I asked you to do two changes.

>What decisions does it not reflect? I would be happy to correct this to
>reflect any relevant decisions.

This working group has never decided that the document that is being
used as a working group item is obsolete.

>I'm trying to follow all the processes, but I don't think that should
>preclude us doing the right thing as well. (Having said that, it's more
>important that we foster interoperability than that we follow processes.
>Without interoperability, the group is irrelevant. Without processes, the
>group can still make progress.)

I'll be happy to work with you and see how your concern and your
suggestions can be addressed. Meanwhile, I suggest that you make the
changes I mentioned in my previous messages.

The Working Group Chairs have ultimate responsibility for ensuring
that a working group achieves forward progress and meets its milestones.

I gather that you have accepted to follow the process. In the IETF,
there is a presumption that participants act in good faith.

Regards,
S. Moonesamy
HyBi WG Secretary

[Ian Hickson]

On Thu, 12 Aug 2010, S Moonesamy wrote:
> >
> > What decisions does it not reflect? I would be happy to correct this
> > to reflect any relevant decisions.
>
> This working group has never decided that the document that is being
> used as a working group item is obsolete.

The proposed text does not say it's obsolete.


> > I'm trying to follow all the processes, but I don't think that should
> > preclude us doing the right thing as well. (Having said that, it's
> > more important that we foster interoperability than that we follow
> > processes. Without interoperability, the group is irrelevant. Without
> > processes, the group can still make progress.)
>
> I'll be happy to work with you and see how your concern and your
> suggestions can be addressed. Meanwhile, I suggest that you make the
> changes I mentioned in my previous messages.

I'm quite willing to apply changes, so long as they do not make the
current situation worse. What you're asking will make the situation worse.
I will not make the situation worse.

I have proposed text that attempts to address your concerns. I have
proposed other solutions to address your concern. You have not said what
is wrong with those proposals. I encourage you to do so, so that I can
edit the text accordingly and resolve this process issue to everyone's
satisfaction.


> The Working Group Chairs have ultimate responsibility for ensuring that
> a working group achieves forward progress and meets its milestones.

Agreed. That doesn't seem at issue here. There's nothing about this entire
conversation that has the slightest effect on the group making any sort of
progress or meeting any milestones, it's all about completely
non-normative text that won't even appear in the final specification.


> I gather that you have accepted to follow the process. In the IETF,
> there is a presumption that participants act in good faith.

Trying to find a solution that is to everyone's satisfaction is acting in
good faith. I am not so sure that asking me to make a change that would
harm interoperability is. Making that change certainly would not be.

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

[S Moonesamy]

Hi Ian,

[This is an individual comment]

At 18:13 12-08-10, Ian Hickson wrote:
>The proposed text does not say it's obsolete.

I don't feel strongly about the issues within the HyBi WG. I prefer
not to comment on the proposed text as there are issues, in my
opinion. I could be wrong. I don't believe that "work related"
disagreements should spill in the personal realm. There is a risk
that it might happen if I raise the issues. I will not comment
further on this, whether on-list or off-list.

>I'm quite willing to apply changes, so long as they do not make the
>current situation worse. What you're asking will make the situation worse.
>I will not make the situation worse.

The current situation will not be made better if the authority of the
Working Group Chairs is put into question. This is an editorial
change after all.

>I have proposed text that attempts to address your concerns. I have
>proposed other solutions to address your concern. You have not said what
>is wrong with those proposals. I encourage you to do so, so that I can
>edit the text accordingly and resolve this process issue to everyone's
>satisfaction.

This is not my concern; it is a concern of the HyBi Working Group.

>Agreed. That doesn't seem at issue here. There's nothing about this entire
>conversation that has the slightest effect on the group making any sort of
>progress or meeting any milestones, it's all about completely
>non-normative text that won't even appear in the final specification.

This is turning into individual concerns trumping community goodwill.

>Trying to find a solution that is to everyone's satisfaction is acting in
>good faith. I am not so sure that asking me to make a change that would
>harm interoperability is. Making that change certainly would not be.

The solution can be found if we do not continue debating about these
non-technical changes. If the Document Editor cannot work with the
Working Group Secretary, then we have a problem. One alternative is
for you to ask the Working Chairs to fire me. The other is for you
to ask me to step down as HyBi Working Group Secretary and I will do
so, no questions asked.

Regards,
S. Moonesamy

[Ian Hickson]

On Thu, 12 Aug 2010, S Moonesamy wrote:
> >
> > I'm quite willing to apply changes, so long as they do not make the
> > current situation worse. What you're asking will make the situation
> > worse. I will not make the situation worse.
>
> The current situation will not be made better if the authority of the
> Working Group Chairs is put into question.

The situation to which I was referring was the problem of implementors
using older versions of the text when implementing their clients and
servers, a situation which has been mostly resolved through the addition
of the paragraph pointing to the latest version. I'm not sure how anyone's
authority would affect this; as far as I can tell all that can affect this
is the presence or absence of pointers in the various versions of the
specification.

For the record, I have no problem with the authority of the chairs.


> This is turning into individual concerns trumping community goodwill.

I certainly hope that getting interoperable implementations is not merely
a personal concern of mine! That would be quite shocking.


> > Trying to find a solution that is to everyone's satisfaction is acting
> > in good faith. I am not so sure that asking me to make a change that
> > would harm interoperability is. Making that change certainly would not
> > be.
>
> The solution can be found if we do not continue debating about these
> non-technical changes. If the Document Editor cannot work with the
> Working Group Secretary, then we have a problem. One alternative is for
> you to ask the Working Chairs to fire me. The other is for you to ask
> me to step down as HyBi Working Group Secretary and I will do so, no
> questions asked.

I have absolute no problem with you or your position as secretary, and
look forward to many months of productive work together.

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

[John Tamplin]

On Thu, Aug 12, 2010 at 10:46 PM, Ian Hickson <***@hixie.ch> wrote:

> On Thu, 12 Aug 2010, S Moonesamy wrote:
> > >
> > > I'm quite willing to apply changes, so long as they do not make the
> > > current situation worse. What you're asking will make the situation
> > > worse. I will not make the situation worse.
> >
> > The current situation will not be made better if the authority of the
> > Working Group Chairs is put into question.
>
> The situation to which I was referring was the problem of implementors
> using older versions of the text when implementing their clients and
> servers, a situation which has been mostly resolved through the addition
> of the paragraph pointing to the latest version. I'm not sure how anyone's
> authority would affect this; as far as I can tell all that can affect this
> is the presence or absence of pointers in the various versions of the
> specification.
>

Until the spec is finalized, I would think everyone understands there will
be interoperability issues, especially as early versions of the spec did not
provide much in the way of versioning or extensibility.

I assume that everyone here has an interest in having a WebSocket spec
accepted as an IETF standard, and that standard should reflect the consensus
of this group as far as it is possible.

The discussion of implementors using outdated versions of the specs seems
misplaced considering the lack of consensus at this point. The most recent
update of the WHATWG document reflects framing that is not compatible with
v76 and AFAIK had no consensus here and failed to address many of the
concerns that were brought up here during the discussion about various
framing ideas. If someone were to implement that spec, it isn't clear what
other implementations they would find to interoperate with.

Rather than bickering about procedures, can we get on with achieving
consensus on the outstanding issues so we can standardize the spec? Ian
Fette recently posted a proposal which seems to take into account most of
the results of various discussions here over the past two weeks, and I am
hopeful we can come to agreement on it or articulate clear deficiencies
which can be addressed in short order.

--
John A. Tamplin
Software Engineer (GWT), Google

[Rob Sayre]

On 8/12/10 8:05 PM, John Tamplin wrote:
>
> Until the spec is finalized, I would think everyone understands there
> will be interoperability issues

Fully agree.

I'm pretty sick of insolent little notes being inserted in specs the
WHATWG is collaborating on. Given their tone, it seems obvious that they
will waste working group time, and they are usually non-technical.
Basically, the editor is trolling.

- Rob

[S Moonesamy]

Hi Ian,

[This is an individual comment]

At 19:46 12-08-10, Ian Hickson wrote:
>The situation to which I was referring was the problem of implementors
>using older versions of the text when implementing their clients and
>servers, a situation which has been mostly resolved through the addition
>of the paragraph pointing to the latest version. I'm not sure how anyone's
>authority would affect this; as far as I can tell all that can affect this
>is the presence or absence of pointers in the various versions of the
>specification.

The question of authority arises as the situation you are referring
has given way to the discussion we are having.

>I have absolute no problem with you or your position as secretary, and
>look forward to many months of productive work together.

This still leaves the problem unsolved. I personally do not have any
problem working with you. But there is now a process issue as the
document editor has to follow the guidance or else raise an issue
about the process used.

Regards,
S. Moonesamy

[Ian Hickson]

On Thu, 12 Aug 2010, S Moonesamy wrote:
> At 19:46 12-08-10, Ian Hickson wrote:
> > The situation to which I was referring was the problem of implementors
> > using older versions of the text when implementing their clients and
> > servers, a situation which has been mostly resolved through the
> > addition of the paragraph pointing to the latest version. I'm not sure
> > how anyone's authority would affect this; as far as I can tell all
> > that can affect this is the presence or absence of pointers in the
> > various versions of the specification.
>
> The question of authority arises as the situation you are referring has
> given way to the discussion we are having.
>
> > I have absolute no problem with you or your position as secretary, and
> > look forward to many months of productive work together.
>
> This still leaves the problem unsolved. I personally do not have any
> problem working with you. But there is now a process issue as the
> document editor has to follow the guidance or else raise an issue about
> the process used.

I'm happy to change the paragraphs you mentioned. I would like to find a
solution that is mutually acceptable. The ball is in your court; either
you, or whomever you represent, needs to explain what the problem with
what I proposed is, or needs to put forward a counter-proposal that takes
into account my feedback (as you said you would [1]). So far all you've
said is essentially "do what I say, your concerns aren't worth addressing".

I have a draft ready to go with the text I proposed if it's acceptable:

http://www.whatwg.org/specs/web-apps/current-work/.ietf-websocket-protocol/draft-ietf-hybi-thewebsocketprotocol-01

I can submit it at a moment's notice. I'm also happy to change the text to
be something else. I just want to make sure that we (a) either include a
pointer to the most up to date draft or not have out-of-date drafts
anywhere, and (b) include a statement regarding where feedback should be
sent, either acknowledging the WHATWG mailing list or pretending it
doesn't exist, I don't mind either way. This seems like a quite reasonable
position, that is made in good faith (to further interoperability, as I've
noted before, which I presume what we're all here for in the first place)
and I really can't see how it is controversial. Is there really no
solution that you or whomever you represent (presumably the chairs) can
find acceptable and that also addresses these concerns?

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg03155.html

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

[S Moonesamy]

Hi Ian,
At 00:07 13-08-10, Ian Hickson wrote:
>I'm happy to change the paragraphs you mentioned. I would like to find a
>solution that is mutually acceptable. The ball is in your court; either
>you, or whomever you represent, needs to explain what the problem with
>what I proposed is, or needs to put forward a counter-proposal that takes
>into account my feedback (as you said you would [1]). So far all you've
>said is essentially "do what I say, your concerns aren't worth addressing".

What I said should be read as "Please do the change. The HyBi
Working Group Chairs will work with you to address your concerns in a
way that is acceptable to all parties".

>I have a draft ready to go with the text I proposed if it's acceptable:
>
>
>http://www.whatwg.org/specs/web-apps/current-work/.ietf-websocket-protocol/draft-ietf-hybi-thewebsocketprotocol-01
>
>I can submit it at a moment's notice. I'm also happy to change the text to
>be something else. I just want to make sure that we (a) either include a

I have to report back to the HyBi Working Group Chairs on this issue.

>pointer to the most up to date draft or not have out-of-date drafts
>anywhere, and (b) include a statement regarding where feedback should be
>sent, either acknowledging the WHATWG mailing list or pretending it
>doesn't exist, I don't mind either way. This seems like a quite reasonable
>position, that is made in good faith (to further interoperability, as I've
>noted before, which I presume what we're all here for in the first place)
>and I really can't see how it is controversial. Is there really no
>solution that you or whomever you represent (presumably the chairs) can
>find acceptable and that also addresses these concerns?

I'll forward your concerns to the HyBi Working Group Chairs.

Regards,
S. Moonesamy
HyBi WG Secretary

[Julian Reschke]

On 13.08.2010 09:07, Ian Hickson wrote:
> ...
> I have a draft ready to go with the text I proposed if it's acceptable:
>
> http://www.whatwg.org/specs/web-apps/current-work/.ietf-websocket-protocol/draft-ietf-hybi-thewebsocketprotocol-01
> ...

This says:

4. If /secure/ is true, perform a TLS handshake over the
connection. If this fails (e.g. the server's certificate could
not be verified), then fail the WebSocket connection and abort
these steps. Otherwise, all further communication on this
channel must run through the encrypted tunnel. [RFC2246]

User agents must use the Server Name Indication extension in the
TLS handshake. [RFC4366]

User agents must use the Next Protocol Negotiation extension in
the TLS handshake, selecting the "776562736f636b657473" protocol
("websockets"). [NPN]

and

12. Normative References

...

[NPN] Langley, A., "Transport Layer Security (TLS) Next Protocol
Negotiation Extension", January 2010,
<http://tools.ietf.org/html/draft-agl-tls-nextprotoneg>.


Is that consistent with the latest discussions on this topic (for
instance,
<http://www.ietf.org/mail-archive/web/hybi/current/msg03063.html>)?

Best regards, Julian

PS: and, a nit: there's a specific way how Internet Drafts are to be
cited, which results in the text "work in progress" being added to the
reference automatically :-)

[Ian Hickson]

On Fri, 13 Aug 2010, Julian Reschke wrote:
> On 13.08.2010 09:07, Ian Hickson wrote:
> > ...
> > I have a draft ready to go with the text I proposed if it's acceptable:
> >
> > http://www.whatwg.org/specs/web-apps/current-work/.ietf-websocket-protocol/draft-ietf-hybi-thewebsocketprotocol-01
> > ...
>
> This says:
>
> 4. If /secure/ is true, perform a TLS handshake over the
> connection. If this fails (e.g. the server's certificate could
> not be verified), then fail the WebSocket connection and abort
> these steps. Otherwise, all further communication on this
> channel must run through the encrypted tunnel. [RFC2246]
>
> User agents must use the Server Name Indication extension in the
> TLS handshake. [RFC4366]
>
> User agents must use the Next Protocol Negotiation extension in
> the TLS handshake, selecting the "776562736f636b657473" protocol
> ("websockets"). [NPN]
>
> and
>
> 12. Normative References
>
> ...
>
> [NPN] Langley, A., "Transport Layer Security (TLS) Next Protocol
> Negotiation Extension", January 2010,
> <http://tools.ietf.org/html/draft-agl-tls-nextprotoneg>.
>
>
> Is that consistent with the latest discussions on this topic (for instance,
> <http://www.ietf.org/mail-archive/web/hybi/current/msg03063.html>)?

Adam L (who wrote the draft) seemed to think it was fine (in fact the text
I used is based on his suggestions). NPN seems like a net improvement to
the security, so if implementors are willing to implement it, then it
seems like a win. If implementors aren't willing to implement it, then we
should remove it, certainly.


> PS: and, a nit: there's a specific way how Internet Drafts are to be
> cited, which results in the text "work in progress" being added to the
> reference automatically :-)

What is it? I couldn't find anything to make references to anything but
RFCs automatic, so I just do them manually. If there's a way to make that
easier, I'm certainly all ears!

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

[Julian Reschke]

On 13.08.2010 10:56, Ian Hickson wrote:
>> PS: and, a nit: there's a specific way how Internet Drafts are to be
>> cited, which results in the text "work in progress" being added to the
>> reference automatically :-)
>
> What is it? I couldn't find anything to make references to anything but
> RFCs automatic, so I just do them manually. If there's a way to make that
> easier, I'm certainly all ears!

In the <reference>, say:

<seriesInfo name="Internet-Draft"
value="draft-agl-tls-nextprotoneg-00"/>

(and drop the @target attribute).

BR, Julian

[Salvatore Loreto]

Hi Ian,

if you do feel necessary having a pointer to a working in progress
version of the draft,
then a possible solution would be hosting the work in progress version
in the IETF svn repository
and eventually insert within the official draft (the one submitted to
the IETF) a pointer to it.

HyBi uses already the svn repository to host the xml version of the
requirement draft: http://svn.tools.ietf.org/svn/wg/hybi/

In order to use it you have to create your own account (in up-right of
the following link)

http://trac.tools.ietf.org/wg/hybi/trac/


all the instraction ca be found at the following link:

http://trac.tools.ietf.org/wg/hybi/trac/wiki/IetfSpecificFeatures


I would appreciate if you can also upload in the svn the xml version of
the 00 version wg draft.


About the version you have ready, I haven't read it yet,
but at least John in the ml, and in this specific thread (
http://www.ietf.org/mail-archive/web/hybi/current/msg03160.html )
has pointed out that it does not reflect the consensus reached (in the
f2f meeting and in the mailing list)
till now on the technical issues.

cheers
/Sal

--
Salvatore Loreto
www.sloreto.com




On 8/13/10 9:07 AM, Ian Hickson wrote:
> On Thu, 12 Aug 2010, S Moonesamy wrote:
>
>> At 19:46 12-08-10, Ian Hickson wrote:
>>
>>> The situation to which I was referring was the problem of implementors
>>> using older versions of the text when implementing their clients and
>>> servers, a situation which has been mostly resolved through the
>>> addition of the paragraph pointing to the latest version. I'm not sure
>>> how anyone's authority would affect this; as far as I can tell all
>>> that can affect this is the presence or absence of pointers in the
>>> various versions of the specification.
>>>
>> The question of authority arises as the situation you are referring has
>> given way to the discussion we are having.
>>
>>
>>> I have absolute no problem with you or your position as secretary, and
>>> look forward to many months of productive work together.
>>>
>> This still leaves the problem unsolved. I personally do not have any
>> problem working with you. But there is now a process issue as the
>> document editor has to follow the guidance or else raise an issue about
>> the process used.
>>
> I'm happy to change the paragraphs you mentioned. I would like to find a
> solution that is mutually acceptable. The ball is in your court; either
> you, or whomever you represent, needs to explain what the problem with
> what I proposed is, or needs to put forward a counter-proposal that takes
> into account my feedback (as you said you would [1]). So far all you've
> said is essentially "do what I say, your concerns aren't worth addressing".
>
> I have a draft ready to go with the text I proposed if it's acceptable:
>
> http://www.whatwg.org/specs/web-apps/current-work/.ietf-websocket-protocol/draft-ietf-hybi-thewebsocketprotocol-01
>
> I can submit it at a moment's notice. I'm also happy to change the text to
> be something else. I just want to make sure that we (a) either include a
> pointer to the most up to date draft or not have out-of-date drafts
> anywhere, and (b) include a statement regarding where feedback should be
> sent, either acknowledging the WHATWG mailing list or pretending it
> doesn't exist, I don't mind either way. This seems like a quite reasonable
> position, that is made in good faith (to further interoperability, as I've
> noted before, which I presume what we're all here for in the first place)
> and I really can't see how it is controversial. Is there really no
> solution that you or whomever you represent (presumably the chairs) can
> find acceptable and that also addresses these concerns?
>
> [1] http://www.ietf.org/mail-archive/web/hybi/current/msg03155.html
>
>

[Ian Hickson]

On Fri, 13 Aug 2010, Salvatore Loreto wrote:
>
> if you do feel necessary having a pointer to a working in progress
> version of the draft, then a possible solution would be hosting the work
> in progress version in the IETF svn repository and eventually insert
> within the official draft (the one submitted to the IETF) a pointer to
> it.

Done.


> About the version you have ready, I haven't read it yet, but at least
> John in the ml, and in this specific thread (
> http://www.ietf.org/mail-archive/web/hybi/current/msg03160.html ) has
> pointed out that it does not reflect the consensus reached (in the f2f
> meeting and in the mailing list) till now on the technical issues.

What specifically isn't reflected? I specifically edited it to match what
was apparently agreed, over my own objections (e.g. it now uses a single
frame type with a fixed-width length).

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

[John Tamplin]

On Fri, Aug 13, 2010 at 5:03 PM, Ian Hickson <***@hixie.ch> wrote:

> What specifically isn't reflected? I specifically edited it to match what
> was apparently agreed, over my own objections (e.g. it now uses a single
> frame type with a fixed-width length).


There have been lots of competing proposals, and there were several things
that various people felt strongly about that are not reflected in your
draft:

- low overhead for small frames
- fragmentation support (which is actually accepted as a consensus
requirement)

[Julian Reschke]

On 13.08.2010 23:03, Ian Hickson wrote:
> On Fri, 13 Aug 2010, Salvatore Loreto wrote:
>>
>> if you do feel necessary having a pointer to a working in progress
>> version of the draft, then a possible solution would be hosting the work
>> in progress version in the IETF svn repository and eventually insert
>> within the official draft (the one submitted to the IETF) a pointer to
>> it.
>
> Done.
> ...

Salvatore also said:

> I would appreciate if you can also upload in the svn the xml version of the 00 version wg draft.

...I guess both -00 and the current version would be useful.

Best regards, Julian

[Maciej Stachowiak]

On Aug 12, 2010, at 6:57 PM, S Moonesamy wrote:

>
>> I have proposed text that attempts to address your concerns. I have
>> proposed other solutions to address your concern. You have not said what
>> is wrong with those proposals. I encourage you to do so, so that I can
>> edit the text accordingly and resolve this process issue to everyone's
>> satisfaction.
>
> This is not my concern; it is a concern of the HyBi Working Group.

I don't recall there being a consensus call on this question. On what basis are you claiming to speak for the HyBi Working Group?

Given the tone and content of your messages on this topic, you certainly don't speak for me.

Regards,
Maciej

[S Moonesamy]

Hi Maciej,

[This is an individual comment]

At 19:51 12-08-10, Maciej Stachowiak wrote:
>I don't recall there being a consensus call on this question. On
>what basis are you claiming to speak for the HyBi Working Group?

The message you quoted is an individual comment.

>Given the tone and content of your messages on this topic, you
>certainly don't speak for me.

Noted.

Regards,
S. Moonesamy

[Daniel Stenberg]

On Thu, 12 Aug 2010, Ian Hickson wrote:

> This has been a real problem with this specification, in particular after I
> was asked to stop updating the draft on the IETF site at the frequency with
> which the specification was uploaded.

But that was before. Before the IETF process started to matter for Websockets,
while you still updated the draft according to what you thought was good and
made sense and it could change several times per day.

Reaching "rough consensus" on technical matters really cannot be achieved at
that speed, and I doubt editorial changes really need that high update
frequency.

The IETF process has worked for many protocols over the years, many of which
browsers use already. It is a bit curious why this protocol needs this special
attention. A high frequency also hurts existing implementors as they need to
keep track of the news and keep up with them accordingly.

We read this "we need to update the spec at very high frequency" mantra, but
with very little actual facts backing it up.

--

/ daniel.haxx.se

[Anne van Kesteren]

On Fri, 13 Aug 2010 11:27:19 +0200, Daniel Stenberg <***@haxx.se> wrote:
> On Thu, 12 Aug 2010, Ian Hickson wrote:
>> This has been a real problem with this specification, in particular
>> after I was asked to stop updating the draft on the IETF site at the
>> frequency with which the specification was uploaded.
>
> But that was before. Before the IETF process started to matter for
> Websockets, while you still updated the draft according to what you
> thought was good and made sense and it could change several times per
> day.
>
> Reaching "rough consensus" on technical matters really cannot be
> achieved at that speed, and I doubt editorial changes really need that
> high update frequency.
>
> The IETF process has worked for many protocols over the years, many of
> which browsers use already. It is a bit curious why this protocol needs
> this special attention. A high frequency also hurts existing
> implementors as they need to keep track of the news and keep up with
> them accordingly.
>
> We read this "we need to update the spec at very high frequency" mantra,
> but with very little actual facts backing it up.

It matters at least for experimental implementations in browsers. If we do
not change quickly enough we might get stuck with something. So far the
trade-off that gives between less than good (or "ideal", if you wish) and
relatively rapid forward movement has been rather positive.


--
Anne van Kesteren
http://annevankesteren.nl/

[Julian Reschke]

On 13.08.2010 11:54, Anne van Kesteren wrote:
> ...
> It matters at least for experimental implementations in browsers. If we
> do not change quickly enough we might get stuck with something. So far
> the trade-off that gives between less than good (or "ideal", if you
> wish) and relatively rapid forward movement has been rather positive.
> ...

If we do not want to get stuck with something (and I don't we think we
want that), then we should VERY clearly tell implementers not to ship
this except in experimental builds (or to turn it off by default).

Best regards, Julian

[Christer Holmberg]

Hi,

I don't see how this is different than any other specification IETF (and many other SDOs) is working on. A draft is a draft, until i becomes an RFC, and implementors should be aware of that.

Regarding new versions, I don't think there are any rules regarding how often you can submit a new version. It's up to the document editor to decide. Just because a version has an expiration date it doesn't mean that you can't submit a new version before that.

Of course, it might not be good to submit a new version for every minor editorial change, but personally I try to always submit a new version when some technical functionality has been agreed upon.

Regards,

Christer


> -----Original Message-----
> From: hybi-***@ietf.org [mailto:hybi-***@ietf.org] On
> Behalf Of Julian Reschke
> Sent: 13. elokuuta 2010 13:00
> To: Anne van Kesteren
> Cc: ***@ietf.org
> Subject: Re: [hybi] Revision of
> draft-ietf-hybi-thewebsocketprotocol-00
>
> On 13.08.2010 11:54, Anne van Kesteren wrote:
> > ...
> > It matters at least for experimental implementations in
> browsers. If
> > we do not change quickly enough we might get stuck with
> something. So
> > far the trade-off that gives between less than good (or "ideal", if
> > you
> > wish) and relatively rapid forward movement has been rather
> positive.
> > ...
>
> If we do not want to get stuck with something (and I don't we
> think we want that), then we should VERY clearly tell
> implementers not to ship this except in experimental builds
> (or to turn it off by default).
>
> Best regards, Julian
> _______________________________________________
> hybi mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

[Ian Fette (イアンフェッティ)]

On Fri, Aug 13, 2010 at 2:54 AM, Anne van Kesteren <***@opera.com> wrote:

> On Fri, 13 Aug 2010 11:27:19 +0200, Daniel Stenberg <***@haxx.se>
> wrote:
>
>> On Thu, 12 Aug 2010, Ian Hickson wrote:
>>
>>> This has been a real problem with this specification, in particular after
>>> I was asked to stop updating the draft on the IETF site at the frequency
>>> with which the specification was uploaded.
>>>
>>
>> But that was before. Before the IETF process started to matter for
>> Websockets, while you still updated the draft according to what you thought
>> was good and made sense and it could change several times per day.
>>
>> Reaching "rough consensus" on technical matters really cannot be achieved
>> at that speed, and I doubt editorial changes really need that high update
>> frequency.
>>
>> The IETF process has worked for many protocols over the years, many of
>> which browsers use already. It is a bit curious why this protocol needs this
>> special attention. A high frequency also hurts existing implementors as they
>> need to keep track of the news and keep up with them accordingly.
>>
>> We read this "we need to update the spec at very high frequency" mantra,
>> but with very little actual facts backing it up.
>>
>
> It matters at least for experimental implementations in browsers. If we do
> not change quickly enough we might get stuck with something. So far the
> trade-off that gives between less than good (or "ideal", if you wish) and
> relatively rapid forward movement has been rather positive.
>
>
I don't agree that it matters. FWIW we are still shipping -76/-00 in Chrome,
and we have no intention of shipping what Hixie updated on WHATWG. I think
all the people seriously looking at implementing WebSockets right now (e.g.
the browsers + major server vendors) are on this mailing list and can see
that things are in a state of flux. I don't see much good having a copy on
WHATWG that doesn't reflect group consensus, nor frankly do I see much good
in protocol discussion happening in another forum when there is critical
mass here.

-Ian


>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
> _______________________________________________
> hybi mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

[Daniel Stenberg]

On Fri, 13 Aug 2010, Anne van Kesteren wrote:

>> Reaching "rough consensus" on technical matters really cannot be achieved
>> at that speed, and I doubt editorial changes really need that high update
>> frequency.

> It matters at least for experimental implementations in browsers. If we do
> not change quickly enough we might get stuck with something. So far the
> trade-off that gives between less than good (or "ideal", if you wish) and
> relatively rapid forward movement has been rather positive.

I'm sorry, then I must be following the wrong working group. The discussions
on this list are long and they certainly do not end up in consensus on a daily
basis or less. I would actually say that the last few months have only
resulted in a few subjects where we can say there are rough consensus.

There is in fact exacly *no* indications that this process will move MUCH
faster all of a sudden and require a very high pace of spec updates. That
requirement is thus moot.

--

/ daniel.haxx.se

[S Moonesamy]

Hi Adam,
At 15:11 12-08-10, Adam Barth wrote:
>As a curiosity, what's the basis of this message? Is this a decision
>from the chairs or some other folks at the IETF? Is this the

Alexey Melnikov, Area Director, answered the first two questions [1].

>consensus of the working group? I'm confused by the authoritarian
>tone of your message.

This is an editorial change to bring the document in line with IETF practices.

Regards,
S. Moonesamy
HyBi WG Secretary

1. http://www.ietf.org/mail-archive/web/hybi/current/msg03138.html