On Tue, Nov 17, 2009 at 9:12 PM, Julian Reschke julian.resc...@gmx.de wrote:
3. We could not directly call out a URI scheme at all. The benefit of
doing this is we can specify *behavior* without actually getting into
details about the actual identifier scheme used. But, the chief reason to
I'm not sure that further back-and-forth on this topic is useful at
this time. I know that you are strongly against Web Database. You have
expressed that view for some time, and I don't expect to change your
mind. I don't find your arguments particularly persuasive either. If
we continue
Jonas Sicking wrote:
On Tue, Nov 17, 2009 at 9:12 PM, Julian Reschke julian.resc...@gmx.de wrote:
3. We could not directly call out a URI scheme at all. The benefit of
doing this is we can specify *behavior* without actually getting into
details about the actual identifier scheme used. But,
Hi Paul!
On Nov 11, 2009, at 12:30 , paul.dow...@bt.com paul.dow...@bt.com wrote:
During our review we have one overall disappointment: whilst the
Use Cases describe saving local files programatically, the
specification does not provide any write methods.
We wondered if these were to be
Hi,
My understanding is that the File Upload spec is now superseded by the
File API spec, but
http://www.w3.org/TR/file-upload/ doesn't redirect to
http://www.w3.org/TR/FileAPI/
I guess ideally the latter would have used the former has previous
version, but since it’s too late for that, I think
On Wed, 18 Nov 2009 09:35:57 +0100, Maciej Stachowiak m...@apple.com
wrote:
Further: if the other vendors planning to ship Web Database
implementations (Google, Opera, perhaps others who have not spoken up
yet) take the position that they would be like to end work on Web
Database at the
On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com
wrote:
I think that just as the names 'load*' were chosen for generic data
transfer events (either networked or within a document), and are used
within documents loaded in the DOM, XHR, and FileReader, we'll need
On Wed, 18 Nov 2009 10:13:10 +0100, Dominique Hazael-Massieux d...@w3.org
wrote:
My understanding is that the File Upload spec is now superseded by the
File API spec, but
http://www.w3.org/TR/file-upload/ doesn't redirect to
http://www.w3.org/TR/FileAPI/
I guess ideally the latter would have
On Wed, 18 Nov 2009 01:03:23 +0100, Arun Ranganathan a...@mozilla.com
wrote:
1. We could coin a new scheme such as the originally proposed filedata:
scheme. This has the advantages of associating behavior (and semantics)
with a scheme, so that existing schemes aren't confused or co-opted
On Wed, Nov 18, 2009 at 9:16 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 18 Nov 2009 09:35:57 +0100, Maciej Stachowiak m...@apple.com
wrote:
Further: if the other vendors planning to ship Web Database
implementations (Google, Opera, perhaps others who have not spoken up yet)
take
On Tue, 17 Nov 2009 22:26:20 +0100, Arun Ranganathan a...@mozilla.com
wrote:
1. I agree that name consistency is desirable, so mediaType is now
simply type. I'll point out that style.type expects very few types
back, whereas for files, the picture is more complicated, so simply
calling it
Hey Arun,
On Nov 13, 2009, at 11:28 , Arun Ranganathan wrote:
Discussion about renaming shows that there isn't really consensus about a
name change [1][2], so I haven't proceeded with one. I'd rather proceed
without a name change for now, but work towards evolving file write
capabilities
On Nov 14, 2009, at 04:30 , Marcos Caceres wrote:
Also, we are working on an implementation of the widget spec but we don't
have support for HTML, only SVG. The tests are currently designed with HTML
start files. Would it be possible to have alternative versions with SVG
start files ?
Sure!
On Nov 12, 2009, at 16:36 , Marcin Hanclik wrote:
I understand that too many details may not work or be an obstacle in the
adoption.
However, I derive that from the security point of view we still would like to
distinguish at least between executable and non-executable content.
That doesn't
On Nov 9, 2009, at 20:22 , SULLIVAN, BRYAN L (ATTCINW) wrote:
(1) we need to be specific about which API's / resource types are affected by
inclusion (or exclusion) of domains in access (and keep this equivalent to
HTML5)
We're very specific: it's a blanket exclusion. Now I can be sensitive
2009/11/12 Dominique Hazael-Massieux d...@w3.org:
Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit :
I would be concerned with leaving file writing to DAP, because a
widely held view in DAP seems to be that security can be ignored while
designing APIs and added back later
2009/11/14 Scott Wilson scott.bradley.wil...@gmail.com:
I've added the tests to Apache Wookie as JUnit tests that directly load the
test .wgt's from the SVN - so far so good!
Awesome.
However testing has revealed a few possible bugs in the test cases:
Assertion 14: Test AY
Hi, Marcin!
2009/11/17 Marcin Hanclik marcin.hanc...@access-company.com:
Hi,
A couple of comments to the latest PC.
7.4
Media type attribute
Media type attribute defines the grammar and refers to RFC2045/6.
What about referring to RFC4288 that includes the grammar required for MIME
5.3 (grammar: I hope these are final corrections :( )
[*folder-name]
Should be
*folder-name
Since the current form makes it optional twice
Zip-rel-path
file-name/
could be
file-name /
(note the space before '/')
safe-char
I suggest putting the '/' sign at the end of each line instead of at the
Hi Marcos,
Thanks!
Kind regards,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
-Original Message-
From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On
Robin Berjon wrote:
...
Couldn't we just register a URN NID for this? It seems that one has to go
through fewer hurdles, and no matter how transient I believe that it's a useful
thing to identify.
...
Yes, that's possible and probably would cause less eyebrows being raised...
BR, Julian
+1
APIs - specifically their design - shall be specified tightly with the security
model in mind to make them both easy to use and effective.
This is what makes the whole task that difficult.
Thanks,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax:
OK, I will take your word for it that security is an important
consideration for DAP. But while at the TPAC, I heard more than one
DAP participant say, when faced with a potential security concern,
something like can't we just leave that up to the policy? In one
case when I enquired
Hi Anne,
XHR still is used also for data retrieval, so it is a kind of border case and I
can live with load there :) .
Using load for writing to a file will mean that we are stuck with the legacy
stuff. load and write pull semantically in the opposite directions, IMHO.
I think there is still
Hi Maciej,
From my side I'd like to understand what your thoughts and proposals for file
writing security / policy would entail - would you defer the decision
responsibility to the user via a prompt?
Thanks,
David.
-Original Message-
From: public-device-apis-requ...@w3.org
Hi Marcos,
For the purposes of my LC comments, I am satisfied with your response.
Thanks,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
-Original Message-
From:
On 18 Nov 2009, at 12:02, Marcos Caceres wrote:
2009/11/14 Scott Wilson scott.bradley.wil...@gmail.com:
woops, fixed.
Assertion 34: Test d7, d8
===
These test cases both contain badly-formed XML:
widget
content
/widget
Presumably these ought to be:
widget
content/
Below is the draft agenda for the 19 November Widgets Voice
Conference (VC).
Inputs and discussion before the VC on all of the agenda topics via
public-webapps is encouraged (as it can result in a shortened meeting).
Please address Open/Raised Issues and Open Actions before the meeting:
Hi Maciej,
I think that there are many potential oversimplifications when stating that
security concerns are to be left to the policy and that a policy file could be
a cure to everything. These seem to be just superficial comments from the
people who already did related exercise in some
Maciej,
Security is important in DAP, and should be considered carefully in the context
of each API and its use cases. There is no one size fits all solution to
security, and that includes approaches based solely upon explicit user action
(including explicitly expressed permission via
Hi Marcin,
On Nov 18, 2009, at 14:37 , Marcin Hanclik wrote:
One could request an
image that is redirected to
http://address/of/image?put+a+complete+script+here
and then evaluate the query.
Ok, but then it will still be processed as image and will result in an
invalid image, I think.
Not
On Nov 18, 2009, at 13:13 , Julian Reschke wrote:
Robin Berjon wrote:
...
Couldn't we just register a URN NID for this? It seems that one has to go
through fewer hurdles, and no matter how transient I believe that it's a
useful thing to identify.
...
Yes, that's possible and probably
On Tue, Nov 17, 2009 at 6:25 PM, Arun Ranganathan a...@mozilla.com wrote:
Eric,
I recall you saying at TPAC that you wanted to keep the Blob
interface as small as possible, since it seemed likely to get used in
a lot of places. I think that's an excellent goal, but of course,
having
On Wed, Nov 18, 2009 at 5:27 AM, David Rogers david.rog...@omtp.org wrote:
Hi Maciej,
From my side I'd like to understand what your thoughts and proposals for
file writing security / policy would entail - would you defer the decision
responsibility to the user via a prompt?
From my point
On Nov 18, 2009, at 2:03 PM, Robert O'Callahan wrote:
On Wed, Nov 18, 2009 at 9:35 PM, Maciej Stachowiak m...@apple.com
wrote:
Further: if the other vendors planning to ship Web Database
implementations (Google, Opera
What they are going to ship is mostly the same implementation as
Hi folks,
this is a Call for consensus to request publishing the Selectors API draft
at
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=iso-8859-1
as a Candidate Recommendation (assuming Lachy fixes the apparent
I'm about to issue a CfC on publishing Selectors as a CR, independent of
getting the test suite done. Because it has taken a long time not to get
it done, and the result is no CR.
We will need to agree on a Test Suite, and on exit criteria. So this
message is to see if there is any
Marcin Hanclik wrote:
Hi Anne,
XHR still is used also for data retrieval, so it is a kind of border case and I can live
with load there :) .
Using load for writing to a file will mean that we are stuck with the legacy stuff.
load and write pull semantically in the opposite directions, IMHO.
Charles McCathieNevile wrote:
Hi folks,
this is a Call for consensus to request publishing the Selectors API
draft at
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=iso-8859-1
as a Candidate Recommendation (assuming Lachy
On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com
wrote:
Greetings Marcin,
Thanks for the thoughtful feedback. My comments below:
In my opinion some part of the design from ProgressEvents is taken over
in FileReader API too directly.
Specifically the event names are
This is a good point, and an argument for policy rather than
implicit user consent, if I'm not mistaken. It highlights that
usability might also be an issue with the non-modal interaction
model, as well as not always be very meaningful (since I the user
might have no idea what most
On Nov 18, 2009, at 5:13 PM, Frederick Hirsch wrote:
This is a good point, and an argument for policy rather than
implicit user consent, if I'm not mistaken. It highlights that
usability might also be an issue with the non-modal interaction
model, as well as not always be very meaningful
42 matches
Mail list logo
