IMO, the following conformance requirement needs to be relaxed to a SHOULD.
[[
# ta-FDGQBROtzW
When acquiring a potential Zip archive that has not been labeled with
a media type (e.g., from a file system), a user agent must attempt to
process the resource regardless of the file extension
Quote from WARP:
Let sub domains be the result of applying the rule for getting a
single attribute value to the value of the subdomains attribute. If
the value of sub domains is not a valid boolean value, then this
element is in error and the user agent MUST ignore this element.
subdomains has
I want to again voice my concerns about WARP's strictness; The
following requirement has to be relaxed in the future (v2?):
If origin is not a valid IRI, if it has components other than scheme
and iauthority, if it has no host component, or if it has a iuser info
component, then this element is
Hello public-webapps members,
(I wanted to post this proposed draft spec for the DOMCrypt API (
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to this list
- if there is a more fitting mailing list, please let me know)
I recently posted this draft spec for a crypto API for
On Thu, 02 Jun 2011 09:40:33 +0200, Marcos Caceres
marcosscace...@gmail.com wrote:
I want to again voice my concerns about WARP's strictness; The
following requirement has to be relaxed in the future (v2?):
If origin is not a valid IRI, if it has components other than scheme
and iauthority,
I support WebApps starting some new work, provided there is broad
support for it and it doesn't block or slow work we already started.
All, especially implementors - what is your level of interest in Adam's
URL API?
Dom - what's your interest here? F.ex., is this API something DAP or
some
Hixie, All - PLH proposed a fix for this bug in comment #5 (use
DOMString instead of any in {get,set}Item).
AFAIU, PLH's proposal matches what has been widely implemented. As such,
it seems like the spec should be updated accordingly.
-AB
On Jun/2/2011 8:31 AM, ext bugzi...@jessica.w3.org
On Thu, Jun 2, 2011 at 9:26 AM, Marcos Caceres marcosscace...@gmail.com wrote:
Quote from WARP:
Let sub domains be the result of applying the rule for getting a
single attribute value to the value of the subdomains attribute. If
the value of sub domains is not a valid boolean value, then
On 6/2/11 5:13 PM, Marcos Caceres wrote:
On Thu, Jun 2, 2011 at 9:26 AM, Marcos Caceresmarcosscace...@gmail.com wrote:
Quote from WARP:
Let sub domains be the result of applying the rule for getting a
single attribute value to the value of the subdomains attribute. If
the value of sub
On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russell k...@google.com wrote:
On Tue, May 31, 2011 at 3:35 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 31 May 2011, Kenneth Russell wrote:
Jonas's suggestion of adding another argument to postMessage, and
Gregg's generalization to declare it as an
What are the specific change(s) to the Web Messaging spec being proposed:
http://dev.w3.org/html5/postmsg/
-AB
On Jun/2/2011 11:25 AM, ext Jonas Sicking wrote:
On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russellk...@google.com wrote:
On Tue, May 31, 2011 at 3:35 PM, Ian Hicksoni...@hixie.ch
Hello,
I was trying to find any information concerning CORS and HTTP headers spoofing.
Couldn't find any relevant information though. So if I am able to set Origin
header to some custom value, it means that there is no more secure
communication between domains as I can pretend to be anyone?
Hi All,
The comment period for Progress Events LC ended on June 1 and my take on
the status is: no comments were submitted to public-webapps during the
LC comment period; there are no open bugs for this spec (Webapps has no
related component in Bugzilla and Tracker has 0 bugs); and the ED
I'm a little concerned about the inherit approach that Ian outlines...
This plan requires all objects that want to opt-in to a new
transfer-of-ownership (or really any special custom behavior for postMessage)
to 1) participate in the special inheritance interface and 2) be isolated from
the
(It would have been better not to fork the thread with a different
subject line...)
On Thu, Jun 2, 2011 at 9:58 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
I'm a little concerned about the inherit approach that Ian outlines...
This plan requires all objects that want to opt-in to
On Thu, Jun 2, 2011 at 9:58 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
This plan requires all objects that want to opt-in to a new
transfer-of-ownership (or really
any special custom behavior for postMessage) to 1) participate in the special
inheritance
interface and 2) be
On Thu, Jun 2, 2011 at 8:25 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russell k...@google.com wrote:
On Tue, May 31, 2011 at 3:35 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 31 May 2011, Kenneth Russell wrote:
Jonas's suggestion of adding another
On Thu, Jun 2, 2011 at 12:58 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
I'm a little concerned about the inherit approach that Ian outlines...
This plan requires all objects that want to opt-in to a new
transfer-of-ownership (or really any special custom behavior for
2011/5/31 Margarita Podskrobko mpodskro...@hotmail.com:
Hello,
I was trying to find any information concerning CORS and HTTP headers
spoofing. Couldn't find any relevant information though. So if I am able to
set Origin header to some custom value, it means that there is no more
secure
On Thu, Jun 2, 2011 at 10:22 AM, ben turner bent.mozi...@gmail.com wrote:
On Thu, Jun 2, 2011 at 9:58 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
This plan requires all objects that want to opt-in to a new
transfer-of-ownership (or really
any special custom behavior for
On 6/1/11 5:42 PM, Adam Barth wrote:
I've been implementing bits and pieces in WebKit. If there's interest
from other implementors, I'm happy to work on the document in the W3C
process.
I'm definitely interested in seeing this become a rec-track document.
Ad-hoc pieces of this live in other
On Thu, Jun 2, 2011 at 5:50 PM, Philippe Le Hegaret p...@w3.org wrote:
On Thu, 2011-06-02 at 17:47 +0200, Marcos Caceres wrote:
Hi Philippe,
Just wondering if we have different port support yet on test-w3c.org?
Would be nice to at least have 81, 82 or something (any none-standard
ports would
: Mozilla/5.0 (X11; Linux i686; rv:7.0a1) Gecko/20110602
Firefox/7.0a1
--
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.
On Thu, 2 Jun 2011, Arthur Barstow wrote:
Hixie, All - PLH proposed a fix for this bug in comment #5 (use
DOMString instead of any in {get,set}Item).
AFAIU, PLH's proposal matches what has been widely implemented. As such,
it seems like the spec should be updated accordingly.
This isn't
On Thu, 2 Jun 2011, Arun Ranganathan wrote:
On 6/1/11 5:42 PM, Adam Barth wrote:
I've been implementing bits and pieces in WebKit. If there's interest
from other implementors, I'm happy to work on the document in the W3C
process.
I'm definitely interested in seeing this become a
On Thu, 2011-06-02 at 18:38 +, Ian Hickson wrote:
On Thu, 2 Jun 2011, Arthur Barstow wrote:
Hixie, All - PLH proposed a fix for this bug in comment #5 (use
DOMString instead of any in {get,set}Item).
AFAIU, PLH's proposal matches what has been widely implemented. As such,
it
On Thu, 2 Jun 2011, Philippe Le Hegaret wrote:
On Thu, 2011-06-02 at 18:38 +, Ian Hickson wrote:
On Thu, 2 Jun 2011, Arthur Barstow wrote:
Hixie, All - PLH proposed a fix for this bug in comment #5 (use
DOMString instead of any in {get,set}Item).
AFAIU, PLH's proposal
On Thu, 2 Jun 2011, ben turner wrote:
I interpreted the proposal differently... This is what I envisioned:
var bufferToTransfer = /* make ArrayBuffer */;
var bufferToCopy = /* make ArrayBuffer */;
var worker = /* make Worker */;
var message = { buf1: bufferToTransfer, buf2:
On Thu, 2011-06-02 at 18:51 +, Ian Hickson wrote:
I don't believe that this new feature will get implemented. It's going
to break too many pages on the Web,
That's the kind of thing implementation feedback will determine.
You've got that feedback already. See
On Jun/2/2011 2:51 PM, ext Ian Hickson wrote:
On Thu, 2 Jun 2011, Philippe Le Hegaret wrote:
On Thu, 2011-06-02 at 18:38 +, Ian Hickson wrote:
On Thu, 2 Jun 2011, Arthur Barstow wrote:
Hixie, All - PLH proposed a fix for this bug in comment #5 (use
DOMString instead of any in
On Thu, 2 Jun 2011, Arthur Barstow wrote:
On Jun/2/2011 2:51 PM, ext Ian Hickson wrote:
On Thu, 2 Jun 2011, Philippe Le Hegaret wrote:
On Thu, 2011-06-02 at 18:38 +, Ian Hickson wrote:
On Thu, 2 Jun 2011, Arthur Barstow wrote:
Hixie, All - PLH proposed a fix for this bug in
On Thu, 2 Jun 2011, Philippe Le Hegaret wrote:
On Thu, 2011-06-02 at 18:51 +, Ian Hickson wrote:
I don't believe that this new feature will get implemented. It's going
to break too many pages on the Web,
That's the kind of thing implementation feedback will determine.
You've
On Thu, 2011-06-02 at 19:00 +, Ian Hickson wrote:
On Thu, 2 Jun 2011, Philippe Le Hegaret wrote:
On Thu, 2011-06-02 at 18:51 +, Ian Hickson wrote:
I don't believe that this new feature will get implemented. It's going
to break too many pages on the Web,
That's the kind
On Thu, Jun 2, 2011 at 11:54 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 2 Jun 2011, ben turner wrote:
I interpreted the proposal differently... This is what I envisioned:
var bufferToTransfer = /* make ArrayBuffer */;
var bufferToCopy = /* make ArrayBuffer */;
var worker = /* make
In summary, there is a desire for a mechanism to transfer objects (to allow
for potentially better perf) across a MessagePort.
The mechanism:
- needs to have an intuitive feel for developers,
- must preserve backwards compatibility,
- should ideally allow the port to function the same
On 6/2/11 3:53 PM, David Levin wrote:
The mechanism:
* needs to have an intuitive feel for developers,
* must preserve backwards compatibility,
* should ideally allow the port to function the same regardless of
whether the message was cloned or transferred.
I'm not sure what
On Thu, Jun 2, 2011 at 12:53 PM, David Levin le...@chromium.org wrote:
In summary, there is a desire for a mechanism to transfer objects (to allow
for potentially better perf) across a MessagePort.
The mechanism:
needs to have an intuitive feel for developers,
must preserve backwards
On Thu, Jun 2, 2011 at 1:13 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/2/11 3:53 PM, David Levin wrote:
The mechanism:
* needs to have an intuitive feel for developers,
* must preserve backwards compatibility,
* should ideally allow the port to function the same regardless of
On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell k...@google.com wrote:
On Thu, Jun 2, 2011 at 12:53 PM, David Levin le...@chromium.org wrote:
The desire would be for this change to apply not just to the
postMessage method on MessagePort and Worker but also to that on
Window.
I agree--the
On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell k...@google.com wrote:
On Thu, Jun 2, 2011 at 12:53 PM, David Levin le...@chromium.org wrote:
The desire would be for this change to apply not just to the
postMessage method
On Thu, Jun 2, 2011 at 5:01 PM, David Levin le...@chromium.org wrote:
It feels like this array of objects given to transfer may complicate (and
slow down) both the implementation of this as well as the developer's use of
it.
Even with thousands of objects, creating an array containing them is
On Thu, Jun 2, 2011 at 3:00 PM, Ian Hickson i...@hixie.ch wrote:
That isn't implementor feedback, and it says nothing about the volume of
breakage. If Aryeh is the only person affected, then I'm sure he'd agree
with me that that means we can change this without worry.
I do agree, but I don't
From: jo...@sicking.cc
Date: Thu, 2 Jun 2011 10:29:04 -0700
Subject: Re: CORS and HTTP headers spoofing
To: mpodskro...@hotmail.com
CC: public-webapps@w3.org
2011/5/31 Margarita Podskrobko mpodskro...@hotmail.com:
Hello,
I was trying to find any information concerning CORS and HTTP
Why only SHA256? Presumably sha1 and md5 are worth exposing as well.
Also, pk and sym appear to be algorithm agonistic but hash isn't. In
addition to hashing, it would be valuable to expose HMAC modes of the
hash functions.
In the pk API, there doesn't seem to be any way to install a
This spec is also incredibly vague:
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
There's no description of what these functions do. There's no way
this spec can be used to create a second interoperable implementation.
Adam
On Thu, Jun 2, 2011 at 4:19 PM, Adam Barth
On Thu, Jun 2, 2011 at 2:01 PM, David Levin le...@chromium.org wrote:
On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell k...@google.com wrote:
On Thu, Jun 2, 2011 at 12:53 PM, David Levin le...@chromium.org wrote:
The
On Thu, Jun 2, 2011 at 5:30 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jun 2, 2011 at 5:01 PM, David Levin le...@chromium.org wrote:
It feels like this array of objects given to transfer may complicate (and
slow down) both the implementation of this as well as the developer's use of
it.
2011/6/2 Margarita Podskrobko mpodskro...@hotmail.com:
From: jo...@sicking.cc
Date: Thu, 2 Jun 2011 10:29:04 -0700
Subject: Re: CORS and HTTP headers spoofing
To: mpodskro...@hotmail.com
CC: public-webapps@w3.org
2011/5/31 Margarita Podskrobko mpodskro...@hotmail.com:
Hello,
I was
On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 2, 2011 at 2:01 PM, David Levin le...@chromium.org wrote:
On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard gl...@zewt.org wrote:
port.postMessage({frameBuffer: frame}, {transfer: [frame], ports:
[port]});
- Original Message -
From: Adam Barth w...@adambarth.com
To: David Dahl dd...@mozilla.com
Cc: public-webapps@w3.org
Sent: Thursday, June 2, 2011 6:19:24 PM
Subject: Re: Request for feedback: DOMCrypt API proposal
Why only SHA256? Presumably sha1 and md5 are worth exposing as well.
- Original Message -
From: Adam Barth w...@adambarth.com
To: David Dahl dd...@mozilla.com
Cc: public-webapps@w3.org
Sent: Thursday, June 2, 2011 6:21:24 PM
Subject: Re: Request for feedback: DOMCrypt API proposal
This spec is also incredibly vague:
On 6/2/11 6:41 PM, Margarita Podskrobko wrote:
I have read couple of discussions in this mail list concerning security
issues of CORS. AFAIU, the main point of CORS is to delegate security
enforcement point from client browser(requestor of resource) to server
(possessor of resource).
It's the
On Thu, Jun 2, 2011 at 4:46 PM, David Dahl dd...@mozilla.com wrote:
- Original Message -
From: Adam Barth w...@adambarth.com
To: David Dahl dd...@mozilla.com
Cc: public-webapps@w3.org
Sent: Thursday, June 2, 2011 6:19:24 PM
Subject: Re: Request for feedback: DOMCrypt API proposal
I unfortunately know very little about crypto (at least compared to
this crowd), so I can't provide much useful input. But I do have a few
comments.
What is a cipherAddressbook ?
It is an object literal that you store discovered public keys in - which are
referred to as addressbook entries.
54 matches
Mail list logo
