Thanks Thomas (and also Marcin from an earlier email) for the
explanation.
I support Thomas' suggested changes.
Mark
>-Original Message-
>From: Thomas Roessler [mailto:t...@w3.org]
>Sent: 16 March 2009 11:18
>To: Frederick Hirsch
>Cc: Priestley, Mark, VF-Group; ext Marcos Caceres; WebA
Frederick,
Many thanks for the feedback.
Responses inline, marked [mp]. Happy with the resolution you suggest for
all the other comments.
Thanks,
Mark
>-Original Message-
>From: Frederick Hirsch [mailto:frederick.hir...@nokia.com]
>Sent: 13 March 2009 14:50
>To: Priestley, Mark, VF-G
I agree with Scott's concern.
I'm not 100% up-to-speed with the latest modification to the HTML5 specs
(if any) but I remember that this kind of "Rubyesque" way of accessing
elements in the Storage is only present into the "attached usage
examples", but there is none in the API described in the d
We've managed to implement Storage for Widget.preferences as an
overlay over the older get/set method without any problems.
One issue though is the HTML5 doc uses some syntax that relies on a
Rubyesque method_missing capability that just isn't present in many
environments, including, notabl
On Thu, 05 Mar 2009 10:18:39 +0100, Jonas Sicking wrote:
[...] So this is quite a common pattern on the web today, and ideally
should
be more common.
The pattern is typically implemented using 302, but yeah...
For this setup it makes a lot of sense to not redirect a OPTIONS
request, but t
On Mon, 16 Mar 2009 12:29:34 +0100, Alexey Proskuryakov
wrote:
The difference is that when one does , the
MIME type on the wire is "text/plain", but with setRequestHeader, it's
"TEXT/Plain". So, server-side code that does case-sensitive comparisons
(something like if (contentType == "text/
Hi Marcos,
On Mar 16, 2009, at 16:00 , Marcos Caceres wrote:
On Mon, Mar 16, 2009 at 3:44 PM, Robin Berjon
wrote:
I would like to echo these concerns. I may have missed something
but it is
still rather unclear to me how making config.xml required improves
security.
I would expect there to
Dear Frederick,
I agree with you and Mark to remove "Only the first distributor signature MUST
be processed." It may depend on a security policy which is currently not
defined. It might be the first matching signature which can be successfully
validated with a public key that is available to th
On Mon, Mar 16, 2009 at 3:44 PM, Robin Berjon wrote:
> On Mar 16, 2009, at 15:06 , Hillebrand, Rainer wrote:
>>
>> Regarding "P&C spec - Mandatory config file", I would like to give more
>> information about my concerns.
>>
>> According to the current "W3C Working Draft 9 March 2009", the config.x
On Mon, Mar 16, 2009 at 3:06 PM, Hillebrand, Rainer
wrote:
> Dear Art,
>
> Regarding "P&C spec - Mandatory config file", I would like to give more
> information about my concerns.
>
> According to the current "W3C Working Draft 9 March 2009", the config.xml
> file has a single mandatory element.
Ok!
*
T-Mobile International
Terminal Technology
Rainer Hillebrand
Head of Terminal Security
Landgrabenweg 151, D-53227 Bonn
Germany
+49 171 5211056 (My T-Mobile)
+49 228 936 13916 (Tel.)
+49 228 936 18406 (Fax)
E-Mail: rainer.hillebr...@t-mobile.net
http://w
I have updated the Widgets Signature editors draft [1] according to
the following, please review the changes:
1) Added ABNF update
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0731.html
and
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0732.html
See section 1.
On Mar 16, 2009, at 15:06 , Hillebrand, Rainer wrote:
Regarding "P&C spec - Mandatory config file", I would like to give
more information about my concerns.
According to the current "W3C Working Draft 9 March 2009", the
config.xml file has a single mandatory element. This is the
element.
On Fri, Mar 13, 2009 at 2:22 PM, Frederick Hirsch
wrote:
> Yes, I made this change since we decided this week to have case sensitivity.
> Too bad we have to use literals in hex for this case ...
Hmmm... is it bad that in the P&C spec we just say "case sensitive"
and not give the hex to match the
This thread seems to have died out without further follow-up. What
are the next steps?
--
Thomas Roessler, W3C
On 26 Feb 2009, at 13:23, Thomas Roessler wrote:
Getting back to the URI scheme discussion, here's a strawman
proposal that's inspired by the Widget case, where scripting a
Dear Art,
Regarding "P&C spec - Mandatory config file", I would like to give more
information about my concerns.
According to the current "W3C Working Draft 9 March 2009", the config.xml file
has a single mandatory element. This is the element. All its expected
children elements and attribute
Dear Marcos,
The current version "W3C Working Draft 11 March 2009" does not mention the
gallery in Chapter 6.9: "A screenshot is an optional file inside the widget
resource that graphically represents the widget in a running state." Well, the
question is what is a running state and which kind o
Hi Rainier,
On Mon, Mar 16, 2009 at 11:58 AM, Hillebrand, Rainer
wrote:
> Dear Marcos,
>
> IMO, it is a good idea to support multiple screenshots that are used to
> represent a widget in a running state. So, I support your proposal. The P&C
> might not be the right place to define "running state
2009/3/9 Arve Bersvendsen :
> On Mon, 09 Mar 2009 12:20:25 +0100, Arthur Barstow
> wrote:
>
>> Arve,
>>
>> On Mar 5, 2009, at 9:14 AM, ext Arve Bersvendsen wrote:
>>
>>> After the last F2F in Paris, I spoke to Ian Hickson about the Storage APIs
>>> in HTML5, and my understanding is now that his
2009/2/23 Scott Wilson :
> So if a value is declared, there needs to be good guidance for
> widget developers on what to expect - e.g. if you specify name="x" value="y"> in the manifest, don't always assume that this will be
> set by the engine, and have your JS able to handle getPreference("x"
2009/3/5 Frederick Hirsch :
> yes that has been the case ever since I've started working on this.
>
> Perhaps there is a W3C standard stylesheet we should be using. I'm not sure
> why the spec defines its own styles
>
No reason, please removed them if they are causing problems.
--
Marcos Cacer
On Thu, 12 Mar 2009 15:28:51 +0100, Alexey Proskuryakov
wrote:
What is the meaning of upload events flag in XMLHttpRequest 2?
It forces a preflight request when event listeners are registered.
Its definition is that it "is used in the send() algorithm to determine
whether upload progress
Per the current CORS spec draft, cross-origin request with preflight
algorithm is followed if Content-Type is set, and it is not one of the
three predefined types. However, the preflight algorithm itself
immediately decides to skip preflight if these conditions are true:
* For request meth
16.03.2009, в 14:12, Anne van Kesteren написал(а):
An unrelated question about the same sentence is why the header
field value is matched case insensitively. My understanding is that
this rule was meant to prevent exposing unsuspecting servers to
requests that couldn't be made with existin
It strikes me that there are actually two issues here:
1. What constitutes a simple request for the purposes in CORS? As far
as that's concerned, I suspect that Alexey has it right.
2. Who should set charset parameter for XMLHttpRequest? The code
invoking it or the underlying engine? I'm
On 13 Mar 2009, at 15:50, Frederick Hirsch wrote:
Thanks for your review, I have some comments inline. Thomas, can you
please review
my proposed change to the security considerations text Mark mentioned?
I believe that you mean this piece of text:
"Implementations that store the content of
On Mon, 16 Mar 2009 12:07:22 +0100, Alexey Proskuryakov
wrote:
Per the current CORS spec draft, a request can only be a simple request
if, among other conditions:
"Custom request headers does not contain a header field name that is an
ASCII case-insensitive match for Content-Type or it doe
Per the current CORS spec draft, a request can only be a simple
request if, among other conditions:
"Custom request headers does not contain a header field name that is
an ASCII case-insensitive match for Content-Type or it does contain it
and the corresponding header field value is an ASCI
Dear Marcos,
IMO, it is a good idea to support multiple screenshots that are used to
represent a widget in a running state. So, I support your proposal. The P&C
might not be the right place to define "running state". Under the assumption
that a widget could be in different running states multip
29 matches
Mail list logo
