[cors] Case-sensitive matching of origin URLs?
Hi, I'm writing a generic Java servlet filter to implement the current CORS draft. I'm confused about the correct way to check if a reported Origin is allowed by the resource's allow list. The Origin spec, which the CORS draft refers to, implies that 2 origins are equal if they match, regardless of their case (upper or lower): http://tools.ietf.org/html/draft-abarth-origin-07 The CORS draft on the other hand requires case-sensitive matching of origins: http://www.w3.org/TR/access-control/#resource-requests Please, advise. Vladimir -- Vladimir Dzhuvinov :: software.dzhuvinov.com
Re: [cors] Case-sensitive matching of origin URLs?
On Thu, 23 Sep 2010 08:40:42 +0200, Vladimir Dzhuvinov vladi...@dzhuvinov.com wrote: The CORS draft on the other hand requires case-sensitive matching of origins: http://www.w3.org/TR/access-control/#resource-requests It requires case-sensitive matching of the serialization of origins. They are never parsed into origins to begin with. -- Anne van Kesteren http://annevankesteren.nl/
Re: [IndexedDB] A versionchangeblocked event
Are we really sure this is needed? I was just writing up a bug for this and started to wonder if we needed any event when there no longer is a block. I then realized that once you're unblocked the onsuccess should fire immediately, so there's no need. But wait...isn't this true of normal blocking as well? Basically either the onsuccess will fire immediately or onblocked will. So couldn't an app just assume it's blocked until it receives a onsuccess message? The worst case is that the web app blinks up some message to the user to close other windows, but it seems like that could happen even with an onblocked event being added. Am I missing something here? J On Thu, Sep 23, 2010 at 9:57 PM, ben turner bent.mozi...@gmail.com wrote: I'm voting for 1! I'd hate to give all the other requests a property that only setVersion requests will use. -Ben On Thu, Sep 23, 2010 at 9:48 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Sep 22, 2010 at 9:07 PM, ben turner bent.mozi...@gmail.com wrote: Hi folks, While implementing the latest setVersion changes Jonas and I decided that it would be really useful to be able to signal to the caller that other web pages are open and using the database (thus preventing a setVersion transaction from running). Consider a web page open in two windows, one minimized or otherwise obscured and the other in the foreground. If the background window is running a transaction then the foreground window will not be able to immediately begin a setVersion transaction when it makes that request. The spec currently informs the background page that it should close all its databases, but it would be even more useful to inform the foreground page that it is currently blocked. That way the foreground page could display some kind of notification (Hey, you! Go close your other tabs if you want us to upgrade the database!) that would aid the process. We are also relying on page authors to correctly call close() on their databases in response to the versionchanged event and I don't believe that they will always follow through. Jonas and I thought of three possibilities: 1. Make setVersion return a special kind of request that had an onblocked event handler. The caller could then add a handler just as they do for success and error conditions. 2. Make all IDBRequests have an onblocked handler, but just never call it in other situations. 3. Fire a versionchangeblocked event at the database. What do you guys think? Any preferences? I don't really like 2, and I've preemptively implemented 3, but I'm not in love with 1 or 3 either. This exact thing came up when we originally talked about setVersion. I thought Jonas proposed and we decided on 1 (though I'm not against 3)..? Did this just not make it into the spec? I think that 1 and 2 are the best solutions and I too thought that that was what we had decided on. I don't really see the advantage with 3 since it means that you have to register event handlers on two separate objects, and potentially worry about colliding with other pieces of code doing version upgrades (though the latter problem seems somewhat far fetched). IMHO 2 seems simpler but I don't really care between 1 and 2. I'll note that there is lots of precedence in the HTML5 spec of adding attribute handlers on objects even though they don't necessarily fire on the given object. This was done to keep down the number of interfaces and thus keep things simpler. But if people prefer 1 I'm game for that too. / Jonas
Re: [cors] Case-sensitive matching of origin URLs?
The CORS draft on the other hand requires case-sensitive matching of origins: http://www.w3.org/TR/access-control/#resource-requests It requires case-sensitive matching of the serialization of origins. They are never parsed into origins to begin with. Does this mean that the value of the origin header should be treated as an arbitrary string? Because if I don't parse the origin value I have no mean of knowing that it actually represents a valid origin. Vladimir -- Vladimir Dzhuvinov :: software.dzhuvinov.com
[CORS] Multiple origin values?
Another question regarding the CORS spec: 1. Why would a browser report multiple Origins to the web server? 2. http://www.w3.org/TR/access-control/#resource-requests Why does the spec prescribe match any instead of match all when multiple origin values are received? Shouldn't the server app determine whether AND or OR matching is more appropriate? Vladimir -- Vladimir Dzhuvinov :: software.dzhuvinov.com
Re: [IndexedDB] A versionchangeblocked event
The strategy we decided on was to send a 'versionchange' event to every database that isn't closed first. Then we loop again and if there are any left that are not closed we fire the blocked event. Since we expect pages to call close() inside their 'versionchange' handler we shouldn't be firing the blocked event unless it's really necessary. -Ben On Fri, Sep 24, 2010 at 3:17 AM, Jeremy Orlow jor...@chromium.org wrote: Are we really sure this is needed? I was just writing up a bug for this and started to wonder if we needed any event when there no longer is a block. I then realized that once you're unblocked the onsuccess should fire immediately, so there's no need. But wait...isn't this true of normal blocking as well? Basically either the onsuccess will fire immediately or onblocked will. So couldn't an app just assume it's blocked until it receives a onsuccess message? The worst case is that the web app blinks up some message to the user to close other windows, but it seems like that could happen even with an onblocked event being added. Am I missing something here? J On Thu, Sep 23, 2010 at 9:57 PM, ben turner bent.mozi...@gmail.com wrote: I'm voting for 1! I'd hate to give all the other requests a property that only setVersion requests will use. -Ben On Thu, Sep 23, 2010 at 9:48 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Sep 22, 2010 at 9:07 PM, ben turner bent.mozi...@gmail.com wrote: Hi folks, While implementing the latest setVersion changes Jonas and I decided that it would be really useful to be able to signal to the caller that other web pages are open and using the database (thus preventing a setVersion transaction from running). Consider a web page open in two windows, one minimized or otherwise obscured and the other in the foreground. If the background window is running a transaction then the foreground window will not be able to immediately begin a setVersion transaction when it makes that request. The spec currently informs the background page that it should close all its databases, but it would be even more useful to inform the foreground page that it is currently blocked. That way the foreground page could display some kind of notification (Hey, you! Go close your other tabs if you want us to upgrade the database!) that would aid the process. We are also relying on page authors to correctly call close() on their databases in response to the versionchanged event and I don't believe that they will always follow through. Jonas and I thought of three possibilities: 1. Make setVersion return a special kind of request that had an onblocked event handler. The caller could then add a handler just as they do for success and error conditions. 2. Make all IDBRequests have an onblocked handler, but just never call it in other situations. 3. Fire a versionchangeblocked event at the database. What do you guys think? Any preferences? I don't really like 2, and I've preemptively implemented 3, but I'm not in love with 1 or 3 either. This exact thing came up when we originally talked about setVersion. I thought Jonas proposed and we decided on 1 (though I'm not against 3)..? Did this just not make it into the spec? I think that 1 and 2 are the best solutions and I too thought that that was what we had decided on. I don't really see the advantage with 3 since it means that you have to register event handlers on two separate objects, and potentially worry about colliding with other pieces of code doing version upgrades (though the latter problem seems somewhat far fetched). IMHO 2 seems simpler but I don't really care between 1 and 2. I'll note that there is lots of precedence in the HTML5 spec of adding attribute handlers on objects even though they don't necessarily fire on the given object. This was done to keep down the number of interfaces and thus keep things simpler. But if people prefer 1 I'm game for that too. / Jonas
Re: [CORS] Multiple origin values?
On Fri, 24 Sep 2010 16:31:52 +0200, Vladimir Dzhuvinov vladi...@dzhuvinov.com wrote: Another question regarding the CORS spec: 1. Why would a browser report multiple Origins to the web server? Redirects. 2. http://www.w3.org/TR/access-control/#resource-requests Why does the spec prescribe match any instead of match all when multiple origin values are received? Shouldn't the server app determine whether AND or OR matching is more appropriate? The server can pretty much do whatever it wants, but if it does not do what is described here there would be a security vulnerability. -- Anne van Kesteren http://annevankesteren.nl/
[Bug 9989] Is the number of replacement characters supposed to be well-defined? If not this should be explicitly noted. If it is then more detail is required.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9989 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||NEEDSINFO --- Comment #6 from Ian 'Hixie' Hickson i...@hixie.ch 2010-09-24 14:56:48 --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: see comment 5 -- 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.
[CORS] Access-Control-Expose-Headers
Regarding the CORS spec: Shouldn't list of exposed headers be added to the resource policy bullet list? Or is that already covered by list of supported headers? http://www.w3.org/TR/access-control/#resource-processing-model -- Vladimir Dzhuvinov :: software.dzhuvinov.com
Re: [DOMCore] Attr
11.09.2010, в 21:17, Michael A. Puls II написал(а): At the time, I made http://shadow2531.com/opera/testcases/attr/suite0.html to test some things with Attr nodes. (Note that the description on that page is outdated.) A few days ago, I fixed some aspects of Attr behavior in WebKit, here's a test I made: http://trac.webkit.org/export/68258/trunk/LayoutTests/fast/dom/Attr/change-id-via-attr-node-value.html. Opera pretty much passes it, with the minor exception of Attr.firstChild.splitText() not splitting the text node. - WBR, Alexey Proskuryakov
Re: Request for Comments: view-mode Media Feature test cases
I was looking at the spec, and it has minimized spelled two different ways: minimized Describes a Web application docked or otherwise minimised... On Sep 24, 2010, at 8:47 AM, Arthur Barstow wrote: Hi All, Opera's participants in the WebApps WG have completed a test suite for the 24-June-2010 'view-mode' Media Feature Candidate Recommendation [CR]. Given this spec's dependency on Media Queries, we would appreciate feedback from the CSS community on the test cases, which can be found by following the Show all tests link at: http://dev.w3.org/2006/waf/widgets-vmmf/test-suite/#product-ua Note the test suite only covers the Widget [Widget] use case. If you have any comments, please send them to the following mail list by the end of October: public-webapps@w3.org -Regards, Art Barstow [CR] http://www.w3.org/TR/2010/CR-view-mode-20100624/ [Widget] http://www.w3.org/TR/widgets/#abstract
Re: [IndexedDB] A versionchangeblocked event
On Fri, Sep 24, 2010 at 3:17 AM, Jeremy Orlow jor...@chromium.org wrote: Are we really sure this is needed? I was just writing up a bug for this and started to wonder if we needed any event when there no longer is a block. I then realized that once you're unblocked the onsuccess should fire immediately, so there's no need. But wait...isn't this true of normal blocking as well? Basically either the onsuccess will fire immediately or onblocked will. So couldn't an app just assume it's blocked until it receives a onsuccess message? The worst case is that the web app blinks up some message to the user to close other windows, but it seems like that could happen even with an onblocked event being added. Am I missing something here? I guess it isn't strictly needed, pages can always install a timeout and cancel that timeout when the success event fires. But I think it might be worth having still since it's generally hard to get people do to proper error handling, and so it's extra important to make it easy for people to do so. / Jonas
Small tweak to FileWriter's event sequences
The abort sequence in FileWriter looks like this: If readyState is DONE, throw a FileException with error code INVALID_STATE_ERR and terminate this overall series of steps. Set readyState to DONE. Terminate any steps having to do with writing a file. Dispatch a progress event called error. Set the error attribute to a FileError object with the appropriate code (in this case, ABORT_ERR; see error conditions). Dispatch a progress event called abort Dispatch a progress event called writeend Stop dispatching any further progress events. In this sequence, readyState gets set to DONE before any of the progress events get sent out. This leaves open a window of opportunity in which one could start another write/truncate [e.g. in onError] before the abort and writeend events get dispatched. At that point you'd get a writeend error that didn't refer to the write in progress, which is at best nonintuitive. I'm planning to move the setting of readyState to just before the writeEnd event gets dispatched. That way readyState==DONE always means it's safe to start another operation, and an abort or writeend event is always unambiguously tied to a particular write. Similarly, in the FileWriter's write and truncate sequences, readyState gets set to DONE before the error and writeend progress events are dispatched. I'm going to make the same change there, for the same reasons, and I'll alter the FileSaver's event sequence to match. Let me know if you see any problem with this. Thanks, Eric
Re: [cors] Case-sensitive matching of origin URLs?
On Fri, Sep 24, 2010 at 12:41 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 23 Sep 2010 08:40:42 +0200, Vladimir Dzhuvinov vladi...@dzhuvinov.com wrote: The CORS draft on the other hand requires case-sensitive matching of origins: http://www.w3.org/TR/access-control/#resource-requests It requires case-sensitive matching of the serialization of origins. They are never parsed into origins to begin with. Anne is correct. CORS uses case-sensitive matching of the serialization of origins. It just so happens that whenever you serialize an origin, you end up with something in lower case, but that detail is too low-level for CORS to worry about. Adam
[Bug 10734] New: Create LR Grammar
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10734 Summary: Create LR Grammar Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: WebIDL AssignedTo: c...@mcc.id.au ReportedBy: ke...@kevlindev.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org This is a request to include an LR grammar of WebIDL in addition to the current LL grammar. Having an LR grammar would make it easier to convert for parser generators and is more conducive to building ASTs during the parse. Thanks, Kevin -- 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: Small tweak to FileWriter's event sequences
On Fri, Sep 24, 2010 at 1:15 PM, Eric Uhrhane er...@google.com wrote: The abort sequence in FileWriter looks like this: If readyState is DONE, throw a FileException with error code INVALID_STATE_ERR and terminate this overall series of steps. Set readyState to DONE. Terminate any steps having to do with writing a file. Dispatch a progress event called error. Set the error attribute to a FileError object with the appropriate code (in this case, ABORT_ERR; see error conditions). Dispatch a progress event called abort Dispatch a progress event called writeend Stop dispatching any further progress events. In this sequence, readyState gets set to DONE before any of the progress events get sent out. This leaves open a window of opportunity in which one could start another write/truncate [e.g. in onError] before the abort and writeend events get dispatched. At that point you'd get a writeend error that didn't refer to the write in progress, which is at best nonintuitive. I'm planning to move the setting of readyState to just before the writeEnd event gets dispatched. That way readyState==DONE always means it's safe to start another operation, and an abort or writeend event is always unambiguously tied to a particular write. Similarly, in the FileWriter's write and truncate sequences, readyState gets set to DONE before the error and writeend progress events are dispatched. I'm going to make the same change there, for the same reasons, and I'll alter the FileSaver's event sequence to match. Let me know if you see any problem with this. Thanks, Eric
Re: [XHR2] ArrayBuffer integration
On Thu, Sep 23, 2010 at 2:42 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell k...@google.com wrote: Mozilla's experimental name is mozResponseArrayBuffer, so perhaps to avoid collisions the spec could call it responseArrayBuffer. While I do not think there would be collision (at least not in ECMAScript, which is what we are designing for) naming it responseArrayBuffer is fine with me. And also now done that way in the draft. Still need to get a saner reference to the ArrayBuffer specification than https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html though. :-) http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Thanks, this is great and very exciting. This motivates implementing the proposed DataView interface ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html#6 ), which will make it easier to read multi-byte values with specified endianness out of an ArrayBuffer. For WebKit I've filed https://bugs.webkit.org/show_bug.cgi?id=46541 . -Ken (You can also do send(ArrayBuffer) obviously. I personally think supporting this for both BlobBuilder and send() makes sense. That way Blob/File etc. work too.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer integration
I plan to add ArrayBuffer support to BlobBuilder and FileReader. Chris, it is good that you would pick up the work for XHR. We can talk about how we're going to add ArrayBufferView to read ArrayBuffer. Jian On Fri, Sep 24, 2010 at 5:23 PM, Kenneth Russell k...@google.com wrote: On Thu, Sep 23, 2010 at 2:42 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell k...@google.com wrote: Mozilla's experimental name is mozResponseArrayBuffer, so perhaps to avoid collisions the spec could call it responseArrayBuffer. While I do not think there would be collision (at least not in ECMAScript, which is what we are designing for) naming it responseArrayBuffer is fine with me. And also now done that way in the draft. Still need to get a saner reference to the ArrayBuffer specification than https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html though. :-) http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Thanks, this is great and very exciting. This motivates implementing the proposed DataView interface ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html#6 ), which will make it easier to read multi-byte values with specified endianness out of an ArrayBuffer. For WebKit I've filed https://bugs.webkit.org/show_bug.cgi?id=46541 . -Ken (You can also do send(ArrayBuffer) obviously. I personally think supporting this for both BlobBuilder and send() makes sense. That way Blob/File etc. work too.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer integration
On Fri, Sep 24, 2010 at 5:36 PM, Jian Li jia...@chromium.org wrote: I plan to add ArrayBuffer support to BlobBuilder and FileReader. Chris, it is good that you would pick up the work for XHR. We can talk about how we're going to add ArrayBufferView to read ArrayBuffer. All of the Typed Array view types (Uint8Array, Float32Array, etc.) except for Float64Array are already implemented in WebKit. The major missing one for file and network I/O is DataView. -Ken Jian On Fri, Sep 24, 2010 at 5:23 PM, Kenneth Russell k...@google.com wrote: On Thu, Sep 23, 2010 at 2:42 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell k...@google.com wrote: Mozilla's experimental name is mozResponseArrayBuffer, so perhaps to avoid collisions the spec could call it responseArrayBuffer. While I do not think there would be collision (at least not in ECMAScript, which is what we are designing for) naming it responseArrayBuffer is fine with me. And also now done that way in the draft. Still need to get a saner reference to the ArrayBuffer specification than https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html though. :-) http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Thanks, this is great and very exciting. This motivates implementing the proposed DataView interface ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html#6 ), which will make it easier to read multi-byte values with specified endianness out of an ArrayBuffer. For WebKit I've filed https://bugs.webkit.org/show_bug.cgi?id=46541 . -Ken (You can also do send(ArrayBuffer) obviously. I personally think supporting this for both BlobBuilder and send() makes sense. That way Blob/File etc. work too.) -- Anne van Kesteren http://annevankesteren.nl/
Re: A URL API
If you really don't want to care what happened before, either do a clearParameter every time first, or define your own setParameter that just clears then appends. Append/clear is a cleaner API design in general imo, precisely because you don't have to worry about colliding with previous activity by default. A set/clear pair means that you have to explicitly check for existing data and handle it in a way that isn't completely trivial. I am not saying remove append - I am saying that just also have set, with the semantics that if you use set, its equivalent to clear;append Attempting to relegate same-name params to second-tier status isn't a good idea. It's very useful for far more than the old services that are also accessed via basic HTML forms that you stated earlier. I am not sure about that - I think a modern API design would be to just send multiple values as an array (maybe CSV or TSV). Consider how JSON values are encoded - do you have multiple values to denote arrays? neither is this the case in XML (afaik). This semantic of multiple yet different values for the same parameter is just confusing, and as you said a mess for server side. I am less optimistic than you are that it will be fixed. cheers devdtta ~TJ
Re: A URL API
On Wed, Sep 22, 2010 at 12:54 AM, Devdatta Akhawe dev.akh...@gmail.com wrote: 2) I've added two flavors of appendParameter. The first flavor takes a DOMString for a value and appends a single parameter. The second flavor takes an array of DOMStrings and appends one parameter for each array. This seemed better than using a variable number of arguments. -1 I really want the setParameter method - appendParameter now requires the developer to know what someone might have done in the past with the URL object. this can be a cause of trouble as the web application might do something that the developer doesn't expect , so I specifically want the developer to opt-in to using appendParameters. If you really don't want to care what happened before, either do a clearParameter every time first, or define your own setParameter that just clears then appends. Append/clear is a cleaner API design in general imo, precisely because you don't have to worry about colliding with previous activity by default. A set/clear pair means that you have to explicitly check for existing data and handle it in a way that isn't completely trivial. I know clearParameter is a method - but this is not the clear separation between the '2 APIs' that we talked about earlier in the thread. I remember reading about how some web application frameworks combine ?q=aq=b to q=ab at the server side, whereas some will only consider q=a and some will only consider q=b. This is such a mess - the developer should have to specifically opt-in to this. It's a mess for server-side languages/frameworks, yes. Some of them handle this incorrectly. Most of the current crop of popular ones, though, do things properly with one method that retrieves the last value and one that retrieves all values (PHP is marginal in this respect with its magic naming convention). Attempting to relegate same-name params to second-tier status isn't a good idea. It's very useful for far more than the old services that are also accessed via basic HTML forms that you stated earlier. ~TJ
[Bug 10420] Can you post sample of cross domain for web workers?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10420 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch, ||public-webapps@w3.org Component|HTML5 spec (editor: Ian |Web Workers (editor: Ian |Hickson)|Hickson) Resolution||NEEDSINFO Product|HTML WG |WebAppsWG QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2010-09-25 04:47:06 --- What kind of cross-domain? Do you mean creating a MessageChannel and passing one MessagePort to a worker and another to a different origin? -- 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: Seeking agenda items for WebApps' Nov 1-2 f2f meeting
On Mon, Sep 20, 2010 at 6:03 PM, Cameron McCormack c...@mcc.id.au wrote: Art, Arthur Barstow: * Web IDL - Cameron - will you attend this meeting? At this stage I won’t be attending. I believe list discussion should be sufficient for progressing the spec at this point, and a scheduling conflict will make it difficult for me to attend regardless. Yeah? I think as far as Mozilla is concerned, we could send you to this Nov 1-2 meeting if you want to go. By the way, there is a Mozilla all-hands meeting scheduled December 13-17 (in Mountain View) that we'll definitely want you to to go. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
