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

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Aug 2010 14:56:37 -0700

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 [email-masked] list or the
    [email-masked] 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. [email-masked] 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

---

From: Adam Barth <[email-masked]>
Date: Thu, 12 Aug 2010 15:11:35 -0700

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 <[email-masked]> wrote:
> Hi Ian,
>
> The Abstract Section of draft-ietf-hybi-thewebsocketprotocol-00 contains the
> following text:
>
> 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.
> [email-masked] in this case.
>
> Please submit a revision of draft-ietf-hybi-thewebsocketprotocol-00 by
> August 16, 2010 with the following changes:
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Aug 2010 23:24:18 +0100

Adam Barth wrote:

>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
-- 
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

---

From: Pieter Hintjens <[email-masked]>
Date: Fri, 13 Aug 2010 00:25:00 +0200

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

---

From: Adam Barth <[email-masked]>
Date: Thu, 12 Aug 2010 15:28:13 -0700

> 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

---

From: Pieter Hintjens <[email-masked]>
Date: Fri, 13 Aug 2010 00:31:20 +0200

Adam,

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

-Pieter

---

From: Ian Hickson <[email-masked]>
Date: Thu, 12 Aug 2010 22:41:51 +0000 (UTC)

On Thu, 12 Aug 2010, S Moonesamy wrote:
>
> The Abstract Section of draft-ietf-hybi-thewebsocketprotocol-00 contains 
> the following text:
> 

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"?

> working group drafts should be sent to the relevant IETF mailing list;
> i.e. [email-masked] in this case.

The draft is also published as part of the WHATWG specification, and 
feedback is therefore on occasion sent to the [email-masked] 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:
> 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.   `._.-(,_..'--(,_..'`-.;.'

---

From: Adam Barth <[email-masked]>
Date: Thu, 12 Aug 2010 15:44:54 -0700

> 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

---

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Aug 2010 16:03:19 -0700

Hi Adam,
>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

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

---

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Aug 2010 16:14:39 -0700

Hi Ian,
>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

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

---

From: Ian Hickson <[email-masked]>
Date: Thu, 12 Aug 2010 23:25:14 +0000 (UTC)

> 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.

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

     Author's note

        Please send feedback to the [email-masked] 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 [email-masked] mailing list.

Would this address your concerns?

---

From: <[email-masked]>
Date: Fri, 13 Aug 2010 00:38:42 +0100

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: [email-masked] [[email-masked]] On Behalf Of Ian Hickson [[email-masked]]
Sent: 13 August 2010 00:25
To: [email-masked]
Subject: Re: [hybi] Revision of draft-ietf-hybi-thewebsocketprotocol-00

     Abstract

        [...]

     Author's note

---

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Aug 2010 16:50:24 -0700

Hi Ian,
>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".

>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

---

From: Ian Hickson <[email-masked]>
Date: Fri, 13 Aug 2010 00:11:05 +0000 (UTC)

On Thu, 12 Aug 2010, S Moonesamy 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.

> 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.)

---

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Aug 2010 17:52:34 -0700

Hi Ian,
>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.

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

Your suggestions will be taken into consideration.

>the WHATWG list. What points does it not address?

I asked you to do two changes.

>reflect any relevant decisions.

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

>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

---

From: Ian Hickson <[email-masked]>
Date: Fri, 13 Aug 2010 01:13:27 +0000 (UTC)

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.
> 

The proposed text does not say it's obsolete.

> > 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'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.

> 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.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Aug 2010 18:57:21 -0700

Hi Ian,

[This is an individual comment]

>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 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.

>edit the text accordingly and resolve this process issue to everyone's

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

>non-normative text that won't even appear in the final specification.

This is turning into individual concerns trumping community goodwill.

>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

---

From: Ian Hickson <[email-masked]>
Date: Fri, 13 Aug 2010 02:46:50 +0000 (UTC)

On Thu, 12 Aug 2010, S Moonesamy wrote:
> > current situation worse. What you're asking will make the situation 
> > worse. I will not make the situation worse.
> 
> 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.
> 
> 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.

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 12 Aug 2010 19:51:33 -0700

> 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

---

From: John Tamplin <[email-masked]>
Date: Thu, 12 Aug 2010 23:05:10 -0400

> is the presence or absence of pointers in the various versions of the

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

---

From: Rob Sayre <[email-masked]>
Date: Thu, 12 Aug 2010 20:18:03 -0700

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

---

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Aug 2010 20:31:21 -0700

Hi Maciej,

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.

>certainly don't speak for me.

Noted.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Aug 2010 20:26:54 -0700

Hi Ian,

>is the presence or absence of pointers in the various versions of the

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

>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

---

From: Ian Hickson <[email-masked]>
Date: Fri, 13 Aug 2010 07:07:43 +0000 (UTC)

On Thu, 12 Aug 2010, S Moonesamy wrote:
> > 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.
> 
> 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

---

From: S Moonesamy <[email-masked]>
Date: Fri, 13 Aug 2010 00:33:42 -0700

Hi Ian,
>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".

>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.

>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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Aug 2010 10:33:45 +0200

On 13.08.2010 09:07, Ian Hickson wrote:
> ...
> ...

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 :-)

---

From: Ian Hickson <[email-masked]>
Date: Fri, 13 Aug 2010 08:56:00 +0000 (UTC)

On Fri, 13 Aug 2010, Julian Reschke wrote:
> Is that consistent with the latest discussions on this topic (for instance,

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.

> 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!

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Aug 2010 11:01:22 +0200

> 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

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 13 Aug 2010 11:27:19 +0200 (CEST)

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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 13 Aug 2010 11:54:31 +0200

On Fri, 13 Aug 2010 11:27:19 +0200, Daniel Stenberg <[email-masked]> wrote:
>> This has been a real problem with this specification, in particular  
>> 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/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Aug 2010 12:00:01 +0200

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

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 13 Aug 2010 17:27:16 +0200

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

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Fri, 13 Aug 2010 09:14:57 -0700

On Fri, Aug 13, 2010 at 2:54 AM, Anne van Kesteren <[email-masked]> 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.
>>>
>>
>> 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.
>>
>> 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.
>>
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

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 13 Aug 2010 22:36:03 +0200 (CEST)

> 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

---

From: Ian Hickson <[email-masked]>
Date: Fri, 13 Aug 2010 21:03:04 +0000 (UTC)

On Fri, 13 Aug 2010, Salvatore Loreto wrote:
> 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).

---

From: John Tamplin <[email-masked]>
Date: Fri, 13 Aug 2010 17:22:07 -0400

> 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)
   - extensibility beyond defining new frame types

>From the discussion threads about buffer management, it was clear several
things would be required to achieve consensus:

   - a sender with the entire message already in memory should be able to
   send it in one frame
   - a sender dynamically generating content, compressing a stream, etc
   should be able to send fragments when a buffer fills rather than having to
   buffer an arbitrarily large item in memory in order to count the bytes for
   the frame header
   - a receiver should know the entire message length up front, if known, so
   it can allocate the message buffer without requiring reallocation

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Aug 2010 00:49:49 +0200

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Julian Reschke
> Sent: 13. elokuuta 2010 13:00
> To: Anne van Kesteren
> Cc: [email-masked]
> > 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
> 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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 14 Aug 2010 08:22:08 +0200

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