[Bug 13777] New: The WebSocket protocol draft (hybi-10) restricts the value of subprotocols as follows: The elements that comprise this value MUST be non- empty strings with characters in th
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13777 Summary: The WebSocket protocol draft (hybi-10) restricts the value of subprotocols as follows: The elements that comprise this value MUST be non- empty strings with characters in the range U+0021 to U+007E not including separator characters as defined Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: The WebSocket protocol draft (hybi-10) restricts the value of subprotocols as follows: The elements that comprise this value MUST be non- empty strings with characters in the range U+0021 to U+007E not including separator characters as defined in [RFC2616], and MUST all be unique strings. Current WebSocket API does not fully enforce the above limitations. I think API should be in line with the protocol spec on limitation of subprotocols. This affects the following snippets of text from WS API: The subprotocol names must all be non-empty ASCII strings with no control characters and no spaces in them (i.e. only characters in the range U+0021 to U+007E). This statement should mention: - Subprotocol names must not contain separator characters. - Each subprotocol name must be unique. If any of the values in protocols occur more than once or contain characters with Unicode code points less than U+0021 or greater than U+007E (i.e. the space character or any characters that are not printable ASCII characters), then throw a SYNTAX_ERR exception and abort these steps. This statement should mention: - Any of subprotocol names must not be empty. - Subprotocol names must not contain separator characters. - SYNTAX_ERR must be thrown in these cases. Posted from: 2401:fa00:4:1000:baac:6fff:fe99:adfb User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/15.0.849.0 Safari/535.1 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: publish new WD of DOM Core; deadline August 10
On Thu, 04 Aug 2011 21:21:46 +0200, Anne van Kesteren ann...@opera.com wrote: On Thu, 04 Aug 2011 21:06:58 +0200, Adrian Bateman adria...@microsoft.com wrote: The name was changed. We weren't terribly keen on the change. It is now causing problems. I've had multiple people contact me confused about this. We should fix the problem. Alright, how about DOM4? Adrian, could you please answer the question? Not participating at all in the development of DOM Core, then objecting when publishing, and then not responding when I try to suggest alternative ways to move forward is not a nice way to cooperate within a WG. -- Anne van Kesteren http://annevankesteren.nl/
Re: DOM Mutation Events Replacement: When to deliver mutations
On Sat, 13 Aug 2011 17:41:32 +0200, Anne van Kesteren ann...@opera.com wrote: I created http://wiki.whatwg.org/wiki/Modifications based on your email and the reply from Olli. It probably needs a bit more context. I will try to contact the relevant people at Opera to see if we have any input in the matter. From the perspective of the DOM specification option 2 would be easiest, but that is not really a good argument either way. It does not matter much to Opera. I would personally prefer it if we could stay away from tasks so the definition of modification listeners can be fully contained by node and range modification methods. Since there seems to be consensus to not do either Immediately or New task should I remove those from http://wiki.whatwg.org/wiki/Modifications now? It is fine with me if someone else does it too. -- Anne van Kesteren http://annevankesteren.nl/
[Bug 13786] New: Drop the charset parameter or made it non-conforming. Other MIME types introduced by this specification do not allow the charset parameter.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13786 Summary: Drop the charset parameter or made it non-conforming. Other MIME types introduced by this specification do not allow the charset parameter. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#tex t/event-stream OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html Multipage: http://www.whatwg.org/C#text/event-stream Complete: http://www.whatwg.org/c#text/event-stream Comment: Drop the charset parameter or made it non-conforming. Other MIME types introduced by this specification do not allow the charset parameter. Posted from: 113.197.157.202 User agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.107 Safari/535.1 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [File API] opaque string
On 8/14/11 9:00 AM, Anne van Kesteren wrote: Why can you not use characters legally allowed in IRIs? Are you referring to the permissible charset for ranges of characters or the condition disallowing reserved characters? I've only omitted the ones that should be percent-encoded. Honestly, we just need terse prose requiring something globally unique; I wanted to allow the Chrome Team's use of URL-tagging, and largely do allow it if they percent encode things. Is this nit backed by a use case? Does Opera wish to URl-tag the opaqueString production as well, and does escaping characters fall short of that requirement? The bit on UUID should be turned into a note if it is non-normative instead of saying it is non-normative. OK.
Re: [File API] dependencies
On 8/14/11 8:58 AM, Anne van Kesteren wrote: For the HTML dependency it seems this specification depends on event handler attributes as well. Agreed. The Typed Arrays specification should either become a normal dependency or you need to introduce different conformance classes. Currently it is contradicting. Hmm good point. Currently, the Typed Arrays spec. is useful only for readAsArrayBuffer, which deprecated readAsBinaryString. It should be a normal dependency. The terminology section contains several terms that are not used, such as document base URL. It looks like this was copied from XMLHttpRequest. Could use some cleanup. Agreed. No need for a dependency on DOM Level 3 Events in this specification as far as I can tell. Agreed. Web DOM Core is now named DOM Core and is also edited by Ms2ger. OK, I'll fix this. DOMException extensions are now in DOM Core, not sure why that reference is still there as it is not referenced from the draft. OK, I'll fix this. Could you please use tools.ietf.org for IETF references? E.g. http://tools.ietf.org/html/rfc1630 OK, I'll fix this. -- A*
Re: [File API] opaque string
On Mon, 15 Aug 2011 18:06:30 +0200, Arun Ranganathan a...@mozilla.com wrote: On 8/14/11 9:00 AM, Anne van Kesteren wrote: Why can you not use characters legally allowed in IRIs? Are you referring to the permissible charset for ranges of characters or the condition disallowing reserved characters? I've only omitted the ones that should be percent-encoded. Honestly, we just need terse prose requiring something globally unique; I wanted to allow the Chrome Team's use of URL-tagging, and largely do allow it if they percent encode things. Is this nit backed by a use case? Does Opera wish to URl-tag the opaqueString production as well, and does escaping characters fall short of that requirement? I do not really see why we should be escaping … or other characters outside the ASCII range. After all these URLs are not going over HTTP so we do not have the same restrictions. I am not really sure what URL-tagging is in this context and I think Opera can implement whatever is decided. I just would like it not to be something arbitrary. -- Anne van Kesteren http://annevankesteren.nl/
RE: [indexeddb] Handling negative parameters for the advance method
On Sunday, August 14, 2011 4:09 PM, Aryeh Gregor wrote: On Fri, Aug 12, 2011 at 6:16 PM, Jonas Sicking jo...@sicking.cc wrote: Yup. Though I think WebIDL will take care of the handling for when the author specifies a negative value. I.e. WebIDL will specify what exception to throw, so we don't need to. Similar to how WebIDL specifies what exception to throw if the author specifies too few parameters, or parameters of the wrong type. It doesn't throw an exception -- the input is wrapped. It basically calls the ToUInt32 algorithm from ECMAScript: http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long This behavior is apparently needed for compat, or so I was told when I complained that it's ridiculous to treat JS longs like C. It does have the one (arguable) advantage that authors can use -1 for maximum allowed value. But anyway, yes: if your IDL says unsigned, then your algorithm can't define behavior for what happens when the input is negative, because WebIDL will ensure the algorithm never sees a value outside the allowed range. If you want special behavior for negative values, you have to use a regular long. I like Areyh's suggestion. What if we were to keep the parameter as a long and specify in the spec that zero and negative values will not advance the cursor in any direction. We could add something like this: If the count value is less than or equal to zero the iteration will not take place. After thinking about this some more, I like this better than having the unexpected side effects of passing a negative number to a unsigned long parameter. Jonas, what do you think? Israel
Re: [File API] opaque string
On 8/15/11 12:27 PM, Anne van Kesteren wrote: On Mon, 15 Aug 2011 18:06:30 +0200, Arun Ranganathan a...@mozilla.com wrote: On 8/14/11 9:00 AM, Anne van Kesteren wrote: Why can you not use characters legally allowed in IRIs? Are you referring to the permissible charset for ranges of characters or the condition disallowing reserved characters? I've only omitted the ones that should be percent-encoded. Honestly, we just need terse prose requiring something globally unique; I wanted to allow the Chrome Team's use of URL-tagging, and largely do allow it if they percent encode things. Is this nit backed by a use case? Does Opera wish to URl-tag the opaqueString production as well, and does escaping characters fall short of that requirement? I do not really see why we should be escaping … or other characters outside the ASCII range. After all these URLs are not going over HTTP so we do not have the same restrictions. These URLs are highly localized, but they also allow for fragment identifiers, so the repertoire of the opaqueString should be defined lest the fragment get hosed. Being conservative, I reasoned that all the reserved chars should be banned. It sounds like you think forbidding the URI-reserved chars is a bad idea. OK, I'm willing to relax this restriction. Do you have a proposal? I am not really sure what URL-tagging is in this context and I think Opera can implement whatever is decided. I just would like it not to be something arbitrary. I'm sorry, I should be clearer. Chrome folks want Blob URLs that look like this: blob:http://localhost/c745ef73-ece9-46da-8f66-ebes574789b1 [1] This string is still opaque, but seems to be useful to them to tag the blob URI with some metadata before something like a UUID sequence. I want to allow this, but also want to make fragments valid. *Enforcing* UUID would make my life simpler :) But this use is also valid. -- A* [1] http://www.html5rocks.com/en/tutorials/workers/basics/#toc-inlineworkers-bloburis
Re: Re: Indicating certificate order in XML Dig Sig ( LC-2504)
Dear Marcos Caceres , The XML Security Working Group has reviewed the comments you sent [1] on the Last Call Working Draft [2] of the XML Signature Syntax and Processing Version 1.1 published on 3 Mar 2011. Thank you for having taken the time to review the document and to send us comments! The Working Group's response to your comment is included below. Please review it carefully and let us know by email at public-xml...@w3.org if you agree with it or not before 22 August 2011. In case of disagreement, you are requested to provide a specific solution for or a path to a consensus with the Working Group. If such a consensus cannot be achieved, you will be given the opportunity to raise a formal objection which will then be reviewed by the Director during the transition of this document to the next stage in the W3C Recommendation Track. Thanks, For the XML Security Working Group, Thomas Roessler W3C Staff Contact 1. http://www.w3.org/mid/BANLkTi=ztsu8cyc06jzy1t8duyhkwbk...@mail.gmail.com 2. http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/ = Your comment on : Add link and informative reference to XML SIgnature Best Practices document to XML Signature 1.1 introduction. Working Group Resolution (LC-2504): Editors draft has been updated with text in introduction and reference. http://lists.w3.org/Archives/Public/public-xmlsec/2011Aug/0003.html Text added to editors draft: The Working Group encourages implementers and developers to read XML Signature Best Practices [XMLDSIG-BESTPRACTICES]. It contains a number of best practices related to the use of XML Signature, including implementation considerations and practical ways of improving security. http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.html#sec-Introduction
Re: [indexeddb] Handling negative parameters for the advance method
On Mon, Aug 15, 2011 at 10:29 AM, Israel Hilerio isra...@microsoft.com wrote: On Sunday, August 14, 2011 4:09 PM, Aryeh Gregor wrote: On Fri, Aug 12, 2011 at 6:16 PM, Jonas Sicking jo...@sicking.cc wrote: Yup. Though I think WebIDL will take care of the handling for when the author specifies a negative value. I.e. WebIDL will specify what exception to throw, so we don't need to. Similar to how WebIDL specifies what exception to throw if the author specifies too few parameters, or parameters of the wrong type. It doesn't throw an exception -- the input is wrapped. It basically calls the ToUInt32 algorithm from ECMAScript: http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long This behavior is apparently needed for compat, or so I was told when I complained that it's ridiculous to treat JS longs like C. It does have the one (arguable) advantage that authors can use -1 for maximum allowed value. But anyway, yes: if your IDL says unsigned, then your algorithm can't define behavior for what happens when the input is negative, because WebIDL will ensure the algorithm never sees a value outside the allowed range. If you want special behavior for negative values, you have to use a regular long. I like Areyh's suggestion. What if we were to keep the parameter as a long and specify in the spec that zero and negative values will not advance the cursor in any direction. We could add something like this: If the count value is less than or equal to zero the iteration will not take place. After thinking about this some more, I like this better than having the unexpected side effects of passing a negative number to a unsigned long parameter. Jonas, what do you think? Hmm.. Yeah, I suspect that is the better behavior here. We should probably also throw if the number is 0. / Jonas
RE: [indexeddb] Handling negative parameters for the advance method
On Monday, August 15, 2011 2:22 PM, Jonas Sicking wrote: On Mon, Aug 15, 2011 at 10:29 AM, Israel Hilerio isra...@microsoft.com wrote: On Sunday, August 14, 2011 4:09 PM, Aryeh Gregor wrote: On Fri, Aug 12, 2011 at 6:16 PM, Jonas Sicking jo...@sicking.cc wrote: Yup. Though I think WebIDL will take care of the handling for when the author specifies a negative value. I.e. WebIDL will specify what exception to throw, so we don't need to. Similar to how WebIDL specifies what exception to throw if the author specifies too few parameters, or parameters of the wrong type. It doesn't throw an exception -- the input is wrapped. It basically calls the ToUInt32 algorithm from ECMAScript: http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long This behavior is apparently needed for compat, or so I was told when I complained that it's ridiculous to treat JS longs like C. It does have the one (arguable) advantage that authors can use -1 for maximum allowed value. But anyway, yes: if your IDL says unsigned, then your algorithm can't define behavior for what happens when the input is negative, because WebIDL will ensure the algorithm never sees a value outside the allowed range. If you want special behavior for negative values, you have to use a regular long. I like Areyh's suggestion. What if we were to keep the parameter as a long and specify in the spec that zero and negative values will not advance the cursor in any direction. We could add something like this: If the count value is less than or equal to zero the iteration will not take place. After thinking about this some more, I like this better than having the unexpected side effects of passing a negative number to a unsigned long parameter. Jonas, what do you think? Hmm.. Yeah, I suspect that is the better behavior here. We should probably also throw if the number is 0. / Jonas If a developer specifies zero as a value, we could throw an IDBDatabaseException with a value of NON_TRANSIENT_ERR. What about doing the same for negative values? Israel
[indexeddb] transaction commit failure
When the db is doing a commit after processing all records on the transaction, if for some reason it fails, should we produce an error event first and let the bubbling produce a transaction abort event or should we only produce a transaction abort event. It seems that doing the first approach would be more complete. Israel
Re: [indexeddb] transaction commit failure
On 8/15/2011 3:31 PM, Israel Hilerio wrote: When the db is doing a commit after processing all records on the transaction, if for some reason it fails, should we produce an error event first and let the bubbling produce a transaction abort event or should we only produce a transaction abort event. It seems that doing the first approach would be more complete. I agree; the first approach seems better and I can't think of any reason why it would be difficult to implement. The catch is that calling `preventDefault` will not prevent the abort, which is (I think) different from how we handle other errors, right? Cheers, Shawn
