Peter O. Ussuri wrote:
Hello!
This is in reply to Eric Uhrhane's message, and other discussions [1]
Various File API use cases discussed in this mailing list are designed to
illustrate some kind of expansion of existing browser capabilities, with
ensuing discussion of potential new security ris
Hi Marcos, All,
Just a couple of comments about the consistency of the W3C specifications:
XHR (whose editor is also from Opera) says:
"The term [...] valid MIME type [are] ..is.. defined by the HTML 5
specification. [HTML5]"
HTML5 says:
"A string is a valid MIME type if it matches the media-ty
fyi
From: whatwg-boun...@lists.whatwg.org [whatwg-boun...@lists.whatwg.org] On
Behalf Of Anthony Bryan [anthonybr...@gmail.com]
Sent: Friday, November 20, 2009 11:18 PM
To: wha...@lists.whatwg.org
Subject: [whatwg] FYI: Mozilla's Resource Packages
More inf
Hello!
This is in reply to Eric Uhrhane's message, and other discussions [1]
Various File API use cases discussed in this mailing list are designed to
illustrate some kind of expansion of existing browser capabilities, with
ensuing discussion of potential new security risks. However, there is one
Hi Richard,
I just comment on the non-legal part.
The numbering schemes are the headache of the telco industry and I assume W3C
will not help too much, but who knows.
>>> >>The weather.example.com Widget can connect to weather.example.com
>>> >>without notifying the user, except when roaming.
>>
On Nov 20, 2009, at 8:24 PM, Marcin Hanclik > wrote:
Hi Marcos,
I don't know, maybe parameter allows spaces? but yeah, that first
space after "Content-type:" seems non-conforming.
RFC2045:
parameter := attribute "=" value
attribute := token
; Matching of attribut
Hi Marcos,
>>I don't know, maybe parameter allows spaces? but yeah, that first
>>space after "Content-type:" seems non-conforming.
RFC2045:
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
On Fri, Nov 20, 2009 at 11:36 AM, Marcin Hanclik
wrote:
> Hi Marcos,
>
>
>
> It seems I found another problem in RFC.
>
>
>
> 7.4
>
> valid-MIME-type = type "/" subtype *(";" parameter)
>
> and we refer to RFC2045 that says:
>
> [1] content := "Content-Type" ":" type "/" subtype
>
>
Hi,
> >>The weather.example.com Widget can connect to weather.example.com
> >>without notifying the user, except when roaming.
How do we cover the additional 113 million+ domain names (and x number
of subdomains) on the web via a policy such as this? Is that a blanket
'deny all' and a fall back
Hi Cyril,
On Fri, Nov 20, 2009 at 5:50 PM, Cyril Concolato
wrote:
> Hi,
>
> The test d1.wgt is about the src attribute of the icon element. It says that
> it tests the following assertion:
> "If the src attribute of this icon element is absent, then the user agent
> must ignore this element."
> b
On Nov 20, 2009, at 18:36 , Cyril Concolato wrote:
> Robin Berjon a écrit :
>> I actually like it, it's one less thing that we need to specify (I was
>> unfavourable to making the configuration requires in the first place). I've
>> implemented it and it works nicely. Yes, it's a bit of a performa
Hi,
The test d1.wgt is about the src attribute of the icon element. It says that it
tests the following assertion:
"If the src attribute of this icon element is absent, then the user agent must
ignore this element."
but the config.xml contains an src attribute with an empty value. This seems a
Marcos Caceres a écrit :
On Fri, Nov 20, 2009 at 4:58 PM, Cyril Concolato
wrote:
Hi all,
While implementing the required features to pass the tests of the test
suite, I was wondering if you really want to keep the default start file
table. The benefit of this table seems to be just avoiding th
Robin Berjon a écrit :
Hi Cyril,
On Nov 20, 2009, at 17:58 , Cyril Concolato wrote:
While implementing the required features to pass the tests of the test suite, I was
wondering if you really want to keep the default start file table. The benefit of
this table seems to be just avoiding the us
On Fri, Nov 20, 2009 at 3:44 PM, Robin Berjon wrote:
> Hi Cyril,
>
> On Nov 20, 2009, at 09:52 , Cyril Concolato wrote:
>> Yes I agree, that should not be difficult, I've already manually created the
>> green/red SVG files. But I was wondering about the order given in the
>> default start files
On Fri, Nov 20, 2009 at 4:58 PM, Cyril Concolato
wrote:
> Hi all,
>
> While implementing the required features to pass the tests of the test
> suite, I was wondering if you really want to keep the default start file
> table. The benefit of this table seems to be just avoiding the use of a
> eleme
On Fri, Nov 20, 2009 at 11:49 AM, Scott Wilson
wrote:
> Thanks Marcos,
>
> I'm happy with this solution.
>
Great. Your approval has been noted in the disposition of comments:
http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-20091029/doc/
--
Marcos Caceres
http://datadriven.com.
Hi Cyril,
On Nov 20, 2009, at 17:58 , Cyril Concolato wrote:
> While implementing the required features to pass the tests of the test suite,
> I was wondering if you really want to keep the default start file table. The
> benefit of this table seems to be just avoiding the use of a
> element w
On Nov 20, 2009, at 17:40 , Adam Barth wrote:
On Fri, Nov 20, 2009 at 8:34 AM, Robin Berjon wrote:
>> DAP will handle security at the API definition level. Full stop.
>
> Can you elaborate on what this means concretely? For example, how is
> security handled at the API definition level for the f
Hi All,
As discussed on the yesterday's call, I committed to CVS the WARP spec with the
section about local network (required for UPnP use cases) at:
http://dev.w3.org/2006/waf/widgets-access-upnp/
Handling of local network is based on my proposal from [1].
Thanks,
Marcin
[1] http://lists.w3.o
Hi all,
While implementing the required features to pass the tests of the test suite, I was
wondering if you really want to keep the default start file table. The benefit of
this table seems to be just avoiding the use of a element with an src
attribute in the config file while the drawback i
Robin pointed out that the following test was also wrong :
http://samaxes.svn.beanstalkapp.com/widgets_compatibility_matrix/trunk/test-cases/ta-klLDaEgJeU/002/
Now fixed, but will need to retest.
On Fri, Nov 20, 2009 at 1:17 PM, Samuel Santos wrote:
> Thanks Scott,
>
> It's fixed now.
>
> --
>
On Fri, Nov 20, 2009 at 8:34 AM, Robin Berjon wrote:
> DAP will handle security at the API definition level. Full stop.
Can you elaborate on what this means concretely? For example, how is
security handled at the API definition level for the file writing API?
Adam
On Nov 20, 2009, at 01:26 , Maciej Stachowiak wrote:
>> For what it's worth, I think any API that opened a dialog asking the
>> user "Do you want to give website X access to directory Y in your file
>> system" would not be an API we'd be willing to implement in firefox.
>> I.e. our security policy
On Nov 20, 2009, at 00:22 , Adam Barth wrote:
> It's emails like this that make me skeptical of the security work
> being done in the device APIs working group.
*sigh* I feel like a broken record. It feels like I've spent my time since TPAC
involved in an endless repeat of the following discussio
On Fri, Nov 20, 2009 at 5:05 PM, Marcos Caceres wrote:
> On Fri, Nov 20, 2009 at 8:48 AM, Dan Brickley wrote:
>> Hello,
>>
>> I understand from http://www.w3.org/TR/2009/WD-widgets-20091029/ that
>> this is the place to direct my feedback on the widget packaging spec,
>> and that I have missed th
Hi Dan,
Thanks for you comment. WebApps welcomes comments for any of its
specs at any time.
You are correct, however, that your comment below missed the LC#3
comment deadline and as such will not be reflected in CR#2. However,
we will discuss your e-mail and depending upon the results of
On Fri, Nov 20, 2009 at 8:48 AM, Dan Brickley wrote:
> Hello,
>
> I understand from http://www.w3.org/TR/2009/WD-widgets-20091029/ that
> this is the place to direct my feedback on the widget packaging spec,
> and that I have missed the Last Call deadline by one day. I hope you
> will consider my
Hi Adam,
The editors draft has been updated with the items from our last emails:
http://www.w3.org/2006/WSC/drafts/rec/rewrite.html
Please raise any additional issues by November 27. Thanks.
Mez
Hi Cyril,
On Nov 20, 2009, at 09:52 , Cyril Concolato wrote:
> Yes I agree, that should not be difficult, I've already manually created the
> green/red SVG files. But I was wondering about the order given in the default
> start files table. For example, if a widget package contains both a index.
Hi Frederick,
My comment inline below.
I think, it would be good if someone else involved in BONDI verified my below
statements.
>>Do you have any more to add, or better use cases? I was going to ask
>>about premium rate numbers so thanks for bringing that up.
As below, maybe we should ask GSMA
Marcin
do you have any more comment on any of the following from the draft
policy requirements document?
http://dev.w3.org/2009/dap/policy-reqs/#use-cases
Example Widget use cases, to give examples of the types of policy that
might be expressed:
• A Widget whose signature chains to ope
Marcin Hanclik wrote:
Hi Marcos,
3. say that parameter is allowed, but if it includes an encoding
parameter, then @encoding beats it (or the other way around).
OK
" let start file encoding be the value of the last
supported parameter components whose purpose is to declare the
character enco
Hi,
>>Reliably identified Websites can send and receive SMS except to
>>premium rate numbers.
There seems to be no worldwide pattern to recognize the premium numbers based
on the number itself, this could be some network operators service or something
similar IP-geolocation databases. The policy
On Friday, November 20, 2009 4:44 AM, Charles McCathieNevile wrote:
> On Fri, 20 Nov 2009 06:23:38 +0100, Adrian Bateman
> wrote:
>
> > ...As I noted at TPAC, at Microsoft we don't think we'll collectively
> > be able to achieve reasonable interop because of the SQL dialect issue
> ...
> > it see
I'm not saying that there is no need for policies (you listed two great
examples of where they can be useful). They seem useful for overriding
default secure behavior that we require for the web. All that I (and I
believe others) am saying is that security cannot completely be decoupled
from the
Jeremy
Thanks. I want to make sure I understand the concerns.
I guess the question is whether one can bake all the security in that
is needed for various (possibly conflicting) use cases, including
those that do not presume user interaction. An argument for policy is
to decouple the mecha
These are reasons, but I think the greatest cause of our concern is that we
have not seen any examples of how policies can provide the same level of
security that baking security into the API from the beginning can provide.
All too often the policy based approaches fall back on either asking the
u
Cyril Concolato wrote:
Yes I agree, that should not be difficult, I've already manually created
the green/red SVG files. But I was wondering about the order given in
the default start files table. For example, if a widget package contains
both a index.htm and index.svg, is the UA required to us
My understanding from reading the thread is that the concern is with
complexity, increased attack surface due to mechanisms that can be
used in unanticipated ways or misconfigured, and management issues.
Thus though policy can state a simple approach, I'm not sure the above
concerns are add
Thanks Scott,
It's fixed now.
--
Samuel Santos
http://www.samaxes.com/
On Fri, Nov 20, 2009 at 11:53 AM, Scott Wilson <
scott.bradley.wil...@gmail.com> wrote:
> Another test case issue:
>
> Assertion 30: test ag, ah
> ===
>
> I think these two got mixed up; ag should result in
On Fri, 20 Nov 2009 06:23:38 +0100, Adrian Bateman
wrote:
...As I noted at TPAC, at Microsoft we don't think we'll collectively be
able to achieve reasonable interop because of the SQL dialect issue ...
it seems unlikely that there will be two independent interoperable
implementations at
Hi Marcos, All,
For the purposes of my LC comments, I am satisfied with the text in P&C as it
is in section 7.4.
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
From: p
This is a Call for Consensus to publish a Last Call Working Draft of
each of the following specs:
1. Server-Sent Events
http://dev.w3.org/html5/eventsource/
2. Web Storage
http://dev.w3.org/html5/webstorage/
3. Web Workers
http://dev.w3.org/html5/workers/
This CfC satisfies the grou
Another test case issue:
Assertion 30: test ag, ah
===
I think these two got mixed up; ag should result in "P A S S" and ah
should result in "PASS".
S
On 19 Nov 2009, at 23:05, Marcos Caceres wrote:
On Wed, Nov 18, 2009 at 1:59 PM, Scott Wilson
wrote:
On 18 Nov 2009, at
Thanks Marcos,
I'm happy with this solution.
S
On 19 Nov 2009, at 21:05, Marcos Caceres wrote:
On Thu, Nov 19, 2009 at 8:53 PM, Marcos Caceres
wrote:
Hi Scott,
Artb would like to include this comment as part of our Disposition of
Comments for P&C. We intend to republish next week, so I nee
Hi Marcos,
It seems I found another problem in RFC.
7.4
valid-MIME-type = type "/" subtype *(";" parameter)
and we refer to RFC2045 that says:
[1] content := "Content-Type" ":" type "/" subtype
*(";" parameter)
Then, RFC2045 gives examples like:
[2] Content-type: text/plain; c
Hi Marcos,
>>3. say that parameter is allowed, but if it includes an encoding
>>parameter, then @encoding beats it (or the other way around).
OK
" let start file encoding be the value of the last
supported parameter components whose purpose is to declare the
character encoding of the start file."
Hi All,
On Nov 4, 2009, at 8:46 AM, Barstow Art (Nokia-CIC/Boston) wrote:
As noted on 23 October [1], the following "HTML5 APIs" are ready or
very close to being ready for Last Call Working Draft (LC):
1. Server-Sent Events
http://dev.w3.org/html5/eventsource/
2. Web Database
http://dev
Hi Robin,
Robin Berjon a écrit :
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
Hi Jonas,
Thanks for your comments.
The below policy actually blocks access to all device APIs for all websites (up
to bugs in the RE, now I think it should be /.*/ instead of /.+/), thus
actually expresses the currently applied policy available in the browsers. I.e.
it already works to some e
Hello,
I understand from http://www.w3.org/TR/2009/WD-widgets-20091029/ that
this is the place to direct my feedback on the widget packaging spec,
and that I have missed the Last Call deadline by one day. I hope you
will consider my plea anyway, since it is based on evaluation of an
implementation
52 matches
Mail list logo
