Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Julian Reschke]

On 2012-07-19 17:30, Arthur Barstow wrote:

On 7/12/12 8:06 AM, ext Julian Reschke wrote:

On 2012-07-12 13:47, Arthur Barstow wrote:

I agree with Hixie that ideally the fix would apply to the original
source rather than 1-off versions in dev.w3. However, if that isn't
worked out, I will apply Julian's patch to the CR version.


Sounds good.


FYI, your patch was applied to this document that will be used as the
basis for the CR
.



What do we do about the normative reference to a non-W3C-part of the
WhatWG spec? ("decoded as UTF-8, with error handling")


What about using ?


Actually, 
; 
dunno why I missed that.


Best regards, Julian

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Arthur Barstow]

On 7/12/12 8:06 AM, ext Julian Reschke wrote:

On 2012-07-12 13:47, Arthur Barstow wrote:

I agree with Hixie that ideally the fix would apply to the original
source rather than 1-off versions in dev.w3. However, if that isn't
worked out, I will apply Julian's patch to the CR version.


Sounds good.


FYI, your patch was applied to this document that will be used as the 
basis for the CR 
.



What do we do about the normative reference to a non-W3C-part of the 
WhatWG spec? ("decoded as UTF-8, with error handling")


What about using ?

-Thanks, AB

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Ian Hickson]

On Thu, 12 Jul 2012, Julian Reschke wrote:
> 
> It almost seems to me that nobody cares over here what the W3C document 
> actually says, as there is that other "more helpful" version. In which 
> case I wonder why it's published at all?

Patent policy.

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

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Julian Reschke]

On 2012-07-12 13:47, Arthur Barstow wrote:

On 7/11/12 7:52 PM, ext Ian Hickson wrote:

On Wed, 11 Jul 2012, Julian Reschke wrote:


OK; the amount of work is ~45 minutes (and probably can be automated
for future publication cycles).

See attachments; an edited version of the current editor's draft, and
the diffs. ...

..and the diff was reversed; new version attached.


Thanks, I do appreciate this patch Julian!


Applying that diff to the spec on dev.w3.org


I agree with Hixie that ideally the fix would apply to the original
source rather than 1-off versions in dev.w3. However, if that isn't
worked out, I will apply Julian's patch to the CR version.

-Thanks, AB


Sounds good.

What do we do about the normative reference to a non-W3C-part of the 
WhatWG spec? ("decoded as UTF-8, with error handling")


Best regards, Julian

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Arthur Barstow]

On 7/11/12 7:52 PM, ext Ian Hickson wrote:

On Wed, 11 Jul 2012, Julian Reschke wrote:


OK; the amount of work is ~45 minutes (and probably can be automated
for future publication cycles).

See attachments; an edited version of the current editor's draft, and
the diffs. ...

..and the diff was reversed; new version attached.


Thanks, I do appreciate this patch Julian!


Applying that diff to the spec on dev.w3.org


I agree with Hixie that ideally the fix would apply to the original 
source rather than 1-off versions in dev.w3. However, if that isn't 
worked out, I will apply Julian's patch to the CR version.


-Thanks, AB

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Julian Reschke]

On 2012-07-12 07:16, Anne van Kesteren wrote:

On Thu, Jul 12, 2012 at 5:44 AM, Julian Reschke  wrote:

My interest was to demonstrate the problem, and to fix it for the pending
publication. In the process of it, I also discovered that one term used in
the spec is undefined.


Except as you can see in the more helpful version of the specification
at http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html
the term is in fact defined.
...


What we are discussing here is the W3C version of the spec; that one 
will reference the W3C HTML5 spec (as far as I can tell), which does not.


It almost seems to me that nobody cares over here what the W3C document 
actually says, as there is that other "more helpful" version. In which 
case I wonder why it's published at all?


Best regards, Julian

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Anne van Kesteren]

On Thu, Jul 12, 2012 at 5:44 AM, Julian Reschke  wrote:
> My interest was to demonstrate the problem, and to fix it for the pending
> publication. In the process of it, I also discovered that one term used in
> the spec is undefined.

Except as you can see in the more helpful version of the specification
at http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html
the term is in fact defined.


> Go ahead and claim that's not helpful; I beg to differ.


-- 
http://annevankesteren.nl/

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Julian Reschke]

On 2012-07-12 01:52, Ian Hickson wrote:

On Wed, 11 Jul 2012, Julian Reschke wrote:


OK; the amount of work is ~45 minutes (and probably can be automated
for future publication cycles).

See attachments; an edited version of the current editor's draft, and
the diffs. ...


..and the diff was reversed; new version attached.


Applying that diff to the spec on dev.w3.org is dumb, as it will just get


As the other changes the W3C team applies to the spec when it gets 
published.



blown away the next time I update the spec. If you actually want to help
please e-mail me (as I suggested on the bug) and I can provide you with
the relevant files against which to write the diff so that it will be
maintained in future versions of the spec.


My interest was to demonstrate the problem, and to fix it for the 
pending publication. In the process of it, I also discovered that one 
term used in the spec is undefined.


Go ahead and claim that's not helpful; I beg to differ.

Best regards, Julian

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Ian Hickson]

On Wed, 11 Jul 2012, Julian Reschke wrote:

> > OK; the amount of work is ~45 minutes (and probably can be automated 
> > for future publication cycles).
> > 
> > See attachments; an edited version of the current editor's draft, and 
> > the diffs. ...
> 
> ..and the diff was reversed; new version attached.

Applying that diff to the spec on dev.w3.org is dumb, as it will just get 
blown away the next time I update the spec. If you actually want to help 
please e-mail me (as I suggested on the bug) and I can provide you with 
the relevant files against which to write the diff so that it will be 
maintained in future versions of the spec.

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

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Cameron McCormack]

Arthur Barstow:

2. The patch [3] to remove the TreatNonCallableAsNull qualifier for some
attributes. If anyone considers this change as substantive, please speak
up. Cameron - what's your opinion on this?


"[TreatNonCallableAsNull] attribute Function?" should be equivalent to 
"attribute EventHandler" so I would class it as an editorial change.

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Julian Reschke]

On 2012-07-11 20:25, Julian Reschke wrote:

On 2012-07-11 15:44, Julian Reschke wrote:

On 2012-07-11 15:11, Arthur Barstow wrote:

Yesterday Hixie closed several of the Web Sockets bugs mentioned in the
e-mail below and he updated others. I think this now provides a basis to
determine if we have consensus to publish a Candidate Recommendation. As
such, this is a Call for Consensus to publish a Candidate Recommendation
of Web Sockets.

I propose the CR be based on the May 24 LC [1] plus include:

1. The editorial patch for 17224 [2]

2. The patch [3] to remove the TreatNonCallableAsNull qualifier for some
attributes. If anyone considers this change as substantive, please speak
up. Cameron - what's your opinion on this?

Additionally:

* 12510 - as Hixie indicated in the bug, if anyone is willing to create
a patch, please contact Hixie privately and please let me know of your
intent
...


I'll re-state that the current spec is under defined, and should not be
published.

As far as I can tell, the W3C team will have to tune some parts of the
spec anyway, so why not also insert the missing links?

(If the answer to that is: "too much work" then why do you consider that
it's not a problem for the *audience* of the spec?)
...


OK; the amount of work is ~45 minutes (and probably can be automated for
future publication cycles).

See attachments; an edited version of the current editor's draft, and
the diffs.
...


..and the diff was reversed; new version attached.

--- wsapi.html  2012-07-10 22:38:35.0 +0100
+++ ws.html 2012-07-11 19:20:05.712293700 +0100
@@ -507,7 +507,7 @@
   4 The WebSocket interface
 
   [Constructor(DOMString url, optional (DOMString or 
DOMString[]) protocols)]
-interface WebSocket : EventTarget {
+interface WebSocket : http://dev.w3.org/html5/spec/infrastructure.html#eventtarget";>EventTarget
 {
   readonly attribute DOMString url;
 
   // ready state
@@ -519,23 +519,23 @@
   readonly attribute unsigned long bufferedAmount;
 
   // networking
-   attribute EventHandler onopen;
-   attribute EventHandler onerror;
-   attribute EventHandler onclose;
+   attribute http://dev.w3.org/html5/spec/webappapis.html#eventhandler";>EventHandler
 onopen;
+   attribute http://dev.w3.org/html5/spec/webappapis.html#eventhandler";>EventHandler
 onerror;
+   attribute http://dev.w3.org/html5/spec/webappapis.html#eventhandler";>EventHandler
 onclose;
   readonly attribute DOMString extensions;
   readonly attribute DOMString protocol;
   void close([Clamp] optional unsigned short code, 
optional DOMString reason);
 
   // messaging
-   attribute EventHandler onmessage;
+   attribute http://dev.w3.org/html5/spec/webappapis.html#eventhandler";>EventHandler
 onmessage;
attribute DOMString binaryType;
   void send(DOMString data);
   void send(ArrayBufferView data);
-  void send(Blob data);
+  void send(http://dev.w3.org/html5/spec/infrastructure.html#blob";>Blob data);
 };
 
   The WebSocket(url, protocols)
-  constructor takes one or two arguments. The first argument, url, specifies the URL to which to
+  constructor takes one or two arguments. The first argument, url, specifies the http://dev.w3.org/html5/spec/urls.html#url";>URL to which to
   connect. The second, protocols, if present, is
   either a string or an array of strings. If it is a string, it is
   equivalent to an array consisting of just that string; if it is
@@ -555,7 +555,7 @@
SyntaxError exception and abort these steps. [WSP]
 
If secure is false but the
-   origin of the entry script has a scheme
+   http://dev.w3.org/html5/spec/origin-0.html#origin";>origin of 
the http://dev.w3.org/html5/spec/browsers.html#entry-script";>entry 
script has a scheme
component that is itself a secure protocol, e.g. HTTPS, then throw
a SecurityError exception.
 
@@ -594,8 +594,8 @@
 
Let origin be the ASCII serialization of the
-   origin of the entry script,
-   converted to ASCII lowercase.
+   http://dev.w3.org/html5/spec/origin-0.html#origin";>origin of 
the http://dev.w3.org/html5/spec/browsers.html#entry-script";>entry 
script,
+   http://dev.w3.org/html5/spec/infrastructure.html#converted-to-ascii-lowercase";>converted
 to ASCII lowercase.
 
Return a new WebSocket object, 
and continue
these steps in the background (without blocking scripts).
@@ -633,15 +633,15 @@
 

 
-  This constructor must be visible when the script's global
-  object is either a Window object or an object
+  This constructor must be visible when the http://dev.w3.org/html5/spec/webappapis.html#script-s-global-object";>script's
 global
+  object is either a Window object or an object
   implementing the WorkerUtils interface.
 
   The url
   attribute must return the result of resolving the URL that was passed to the
+  url">resolving the http://dev.w3.org/html5/spec/urls.html#url";>URL that was passed to the
   constructor. (It doesn't matter what it is resolved

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Glenn Adams]

On Wed, Jul 11, 2012 at 10:52 AM, Edward O'Connor wrote:

> Art wrote:
>
> > As such, this is a Call for Consensus to publish a Candidate
> > Recommendation of Web Sockets.
>
> Ship it! :)
>

+1

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Edward O'Connor]

Art wrote:

> As such, this is a Call for Consensus to publish a Candidate
> Recommendation of Web Sockets.

Ship it! :)


Ted

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Julian Reschke]

On 2012-07-11 15:11, Arthur Barstow wrote:

Yesterday Hixie closed several of the Web Sockets bugs mentioned in the
e-mail below and he updated others. I think this now provides a basis to
determine if we have consensus to publish a Candidate Recommendation. As
such, this is a Call for Consensus to publish a Candidate Recommendation
of Web Sockets.

I propose the CR be based on the May 24 LC [1] plus include:

1. The editorial patch for 17224 [2]

2. The patch [3] to remove the TreatNonCallableAsNull qualifier for some
attributes. If anyone considers this change as substantive, please speak
up. Cameron - what's your opinion on this?

Additionally:

* 12510 - as Hixie indicated in the bug, if anyone is willing to create
a patch, please contact Hixie privately and please let me know of your
intent
...


I'll re-state that the current spec is under defined, and should not be 
published.


As far as I can tell, the W3C team will have to tune some parts of the 
spec anyway, so why not also insert the missing links?


(If the answer to that is: "too much work" then why do you consider that 
it's not a problem for the *audience* of the spec?)


Best regards, Julian

CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Arthur Barstow]

Yesterday Hixie closed several of the Web Sockets bugs mentioned in the 
e-mail below and he updated others. I think this now provides a basis to 
determine if we have consensus to publish a Candidate Recommendation. As 
such, this is a Call for Consensus to publish a Candidate Recommendation 
of Web Sockets.


I propose the CR be based on the May 24 LC [1] plus include:

1. The editorial patch for 17224 [2]

2. The patch [3] to remove the TreatNonCallableAsNull qualifier for some 
attributes. If anyone considers this change as substantive, please speak 
up. Cameron - what's your opinion on this?


Additionally:

* 12510 - as Hixie indicated in the bug, if anyone is willing to create 
a patch, please contact Hixie privately and please let me know of your 
intent


* 15829 - the CR will include a fix for this as was done for the LC

* 16927 - the CR will include a fix for this as was done for the LC

* Other bugs to remain open for v.next: 15209, 15210, 17073, 17264, 17685

* The CR's exit criteria be identical to the December 2011 CR.

This CfC satisfies: a) the group's requirement to "record the group's 
decision to request advancement" to CR; and b) "General Requirements for 
Advancement on the Recommendation Track" as defined in the Process Document:


http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs

Positive response is preferred and encouraged and silence will be 
considered as agreeing with the proposal. The deadline for comments is 
July 18 and all comments should be sent to public-webapps at w3.org.


-Thanks, AB

[1] 
http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.269;r2=1.270;f=h
[2] 
http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.268;r2=1.269;f=h

[3] http://www.w3.org/TR/2012/WD-websockets-20120524/


 Original Message 
Subject: 	[websockets] Seeking comments on moving back to CR; deadline 
June 28

Resent-Date:Thu, 21 Jun 2012 14:29:06 +
Resent-From:
Date:   Thu, 21 Jun 2012 10:28:31 -0400
From:   ext Arthur Barstow 
To: public-webapps 



Hi All,

I created a tracking document for the two comments and five bugs that
were submitted against the 24 May LCWD of Web Sockets (or in the
approximate time frame of that publication):
.

Below is my "take" on these bugs and comments. It would be good to get
this spec back to CR and hence closer toward the IP commitments that
will only be final when the spec reaches Recommendation.

Bugs:

* 17073  - marked
as an Enhancement; don't include in the v1 CR

* 17224  - this
looks like an Editorial bug to me as I stated in the bug. Assuming there
is consensus the text should be "unsolicited pongs", if Hixie can't fix
this before the v1 CR copy is created, I'll make this change in the v1 CR.

* 17262  - Jonas'
view as expressed in
 seems
reasonable so I propose closing this with a resolution of WorksForMe.

* 17263  -
send(ArrayBuffer), which was included in the December 2011 CR, has been
implemented and presumably must be supported by some browsers (e.g.
bc/legacy reasons). As such, it seems reasonable to fix this bug and
perhaps we could argue a new LCWD is not needed since it has already
been implemented.

* 17264  - this
bug appears to be a rehash of bug 13104 which was Fixed in October 2011
so I propose closing this with a resolution of Duplicate.

Comments:

* LC-1
 -
The 28-May-2012 reply by Takeshi Yoshino notes this is a Chrome bug and
not a spec bug. The 1-June-2012 reply by Simon Pieters indicates the
Protocol spec needs to be updated. As such, I don't think any changes
are needed for v1 of the spec.

* LC-2
 -
This is an editorial bug and is already captured in Bug 12510. Ideally,
this bug would be fixed before the v1 CR branch is created. However, if
Hixie can't fix it before then and if no one else creates an acceptable
patch for Hixie, I don't support blocking the v1 CR for this.

Please send all comments by June 28.

-Thanks, AB