Re: [XHR2] Upload progress events and simple cross-origin requests

On Thu, Mar 19, 2009 at 3:18 PM, Anne van Kesteren wrote: > On Thu, 19 Mar 2009 19:00:36 +0100, Jonas Sicking wrote: >> >> While I agree that there are other ways of doing this, I think I'd >> have a really hard time selling a feature that explicitly allows port >> scanning to our security team.

Re: [XHR2] Upload progress events and simple cross-origin requests

On Thu, 19 Mar 2009 19:00:36 +0100, Jonas Sicking wrote: While I agree that there are other ways of doing this, I think I'd have a really hard time selling a feature that explicitly allows port scanning to our security team. Especially when there is an easy remedy. Since there are other ways o

Re: [CORS] Charset in content type

On Thu, 19 Mar 2009 20:37:50 +0100, Giovanni Campagna wrote: Actually both of them are invalid per RFC2616 and thus should raise SYNTAX_ERR. I do not want to enforce validity in the XMLHttpRequest API. That seems inconsistent with other APIs, e.g. the DOM API. (It also seems complex and

Re: [widgets] Further argument for making config.xml mandatory

Ok, here is my first crack at specifying this...If you prefer to read it in the spec (so you can follow any cross references, etc), then please check out: http://dev.w3.org/2006/waf/widgets/#element-based-content-localization [[ ==Element-based Content Localization== This specification defines th

Re: [CORS] Charset in content type

2009/3/19 Jonas Sicking : > [...] > > Two things that I think we need to watch out for: > > 1. Someone doing >    xhr.setRequestHeader("Content-Type", "text/plain; application/xml"); > > 2. Someone doing >    xhr.setRequestHeader("Content-Type", "text/plain; > somewierdthing=application/xml"); > >

Re: [CORS] Charset in content type

On Tue, Mar 17, 2009 at 6:40 AM, Anne van Kesteren wrote: > On Mon, 16 Mar 2009 11:12:01 -, Anne van Kesteren > wrote: >> >> On Mon, 16 Mar 2009 12:07:22 +0100, Alexey Proskuryakov >> wrote: >>> >>> I think that the algorithm can only compare MIME types, not the full >>> Content-Type string.

Re: [XHR2] Upload progress events and simple cross-origin requests

19.03.2009, в 21:00, Jonas Sicking написал(а): While I agree that there are other ways of doing this, I think I'd have a really hard time selling a feature that explicitly allows port scanning to our security team. Especially when there is an easy remedy. The price comes mainly in the form o

Re: [XHR2] Upload progress events and simple cross-origin requests

On Thu, Mar 19, 2009 at 12:29 AM, Ian Hickson wrote: > On Thu, 19 Mar 2009, Alexey Proskuryakov wrote: >> >> In fact, it seems very likely that even timing of preflight requests >> makes port scans possible, but I don't have any data to support this >> theory. > > Port scans are already possible w

Re: [widget-digsig] Editorial update of Widget Signature

Awesome! thanks. I'll do the cleanup ASAP. On Thu, Mar 19, 2009 at 5:17 PM, Frederick Hirsch wrote: > Completed additional changes to Editorial note in section 6, added links to > XML Security WG home page, list of comments on FPWD and mailto link for > comments on XML Signature 1.1. > > Also fix

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 5:07 PM, wrote: > The reason why the I18N BP document frowns upon this is because if you have > the material sent for translation, it might (or most probably will) be > translated by different people in different places. So it makes coordination > a little difficult when a

Re: [widget-digsig] Editorial update of Widget Signature

Completed additional changes to Editorial note in section 6, added links to XML Security WG home page, list of comments on FPWD and mailto link for comments on XML Signature 1.1. Also fixed editorial nit, "final set" to "a final set" regards, Frederick Frederick Hirsch Nokia On Mar 19, 2

Re: [widgets] Further argument for making config.xml mandatory

On 19.3.2009 17.43, "ext Marcos Caceres" wrote: On Thu, Mar 19, 2009 at 4:36 PM, Andrew Welch wrote: >> To be clear, the proposal is: >> http://www.w3.org/ns/widgets";> >> Mon widget >> My Widget >> Widget >> > > heh... be careful that looks very similar to this "Best Practice": > > "Avo

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 4:52 PM, Andrew Welch wrote: >> That's exactly what I was talking about when I said "even thought the XML >> i18n >> guidelines say it's bad practice,'. > > Ahh very sorry, I just saw the email after that containing the code > sample, and gmail collapses the quoted parts..

Re: [widgets] Further argument for making config.xml mandatory

> That's exactly what I was talking about when I said "even thought the XML i18n > guidelines say it's bad practice,'. Ahh very sorry, I just saw the email after that containing the code sample, and gmail collapses the quoted parts my bad. > However, Addison Phillips, the > Chair of i18n cor

[widget-digsig] Editorial update of Widget Signature

I have completed the following editorial update of Widget Signature [1]: 1. Added proposed change to 7.1 http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0827.html also added minor change in response to review comment from Mark: http://lists.w3.org/Archives/Public/public-webapps/2

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 4:36 PM, Andrew Welch wrote: >> To be clear, the proposal is: >> http://www.w3.org/ns/widgets";> >>   Mon widget >>   My Widget >>   Widget >> > > heh... be careful that looks very similar to this "Best Practice": > > "Avoid document formats that store multiple localized v

Re: [widget-digsig] Editors note to be added to widget signature

On Thu, Mar 19, 2009 at 2:57 PM, Frederick Hirsch wrote: > revised to be as follows, now that I look at it more closely: > > Note: > > The Web Applications WG is seeking feedback on required  algorithms for > widget signatures, in particular which algorithms should be required in > addition to RSA

Re: [widgets] Further argument for making config.xml mandatory

> To be clear, the proposal is: > http://www.w3.org/ns/widgets";> >   Mon widget >   My Widget >   Widget > heh... be careful that looks very similar to this "Best Practice": "Avoid document formats that store multiple localized versions of content within the same document." http://www.w3.org/T

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 4:30 PM, Marcos Caceres wrote: > On Thu, Mar 19, 2009 at 4:22 PM,   wrote: >> I still think that more than one config document is the most confusing >> aspect of this. Having just one (mandatory) config document, with the >> localized parts tagged with xml:lang attributes w

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 4:22 PM, wrote: > I still think that more than one config document is the most confusing > aspect of this. Having just one (mandatory) config document, with the > localized parts tagged with xml:lang attributes would be the simplest. > However, as I understand it, the sepa

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 4:20 PM, Andrew Welch wrote: >>> Other suggestions are of course welcome! >>> >>> One alternative would be to separate out the non-localisable data into a >>> separate document, eg manifest.xml... But this is also likely to irritate >>> implementers :( >>> >> >> No, the W

Re: [widgets] Further argument for making config.xml mandatory

I still think that more than one config document is the most confusing aspect of this. Having just one (mandatory) config document, with the localized parts tagged with xml:lang attributes would be the simplest. However, as I understand it, the separate config files were recommended by the W3C I

Re: [widgets] Further argument for making config.xml mandatory

>> Other suggestions are of course welcome! >> >> One alternative would be to separate out the non-localisable data into a >> separate document, eg manifest.xml... But this is also likely to irritate >> implementers :( >> > > No, the WG are saving manifest.xml for an actual manifest format. Lets

Re: [widgets] s on s

Hi, here is a draft of for the option element... which I've renamed param ("inspired" by HTML5;)) =The param Element= The param element defines a parameter for a feature. A parameter is name-value pair that a user agent must pass to the corresponding feature for which the parameter is declared for

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 3:54 PM, Priestley, Mark, VF-Group wrote: >>FWIW, I think this will confuse authors... and irritate the >>poor souls who need to implement this :) > > Other suggestions are of course welcome! > > One alternative would be to separate out the non-localisable data into a > se

RE: [widgets] Further argument for making config.xml mandatory

>FWIW, I think this will confuse authors... and irritate the >poor souls who need to implement this :) Other suggestions are of course welcome! One alternative would be to separate out the non-localisable data into a separate document, eg manifest.xml... But this is also likely to irritate im

Re: [widget-digsig] changed widget signature files processing rule in section 4

I think the current text is clearer since it make clear which direction to process the list, which would be ambiguous otherwise. regards, Frederick Frederick Hirsch Nokia On Mar 19, 2009, at 9:40 AM, ext Priestley, Mark, VF-Group wrote: Hi Frederick, Small comment. I would change the sen

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 1:15 PM, Priestley, Mark, VF-Group wrote: > Hi Marcos, All, > > I would like to raise a comment in support of making the configuration > document at the root of the widget mandatory. > > The localisation model currently described by [1] allows for multiple > configuration d

RE: [widget-digsig] proposed change to 7.1, common constraints, for algorithms

Mark I'll change the sentence to read "The ds:Signature MUST be produced using a key of the recommended key length or stronger." Probably should change term from "recommended key length" to "minimum key length". Later when we update algorithms we probably should review whether we need

[widgets] Minutes from 19 March 2009 Voice Conference

The minutes from the March 19 Widgets voice conference are available at the following and copied below: WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 26 March 2009 (the next

Re: [widget-digsig] Editors note to be added to widget signature

revised to be as follows, now that I look at it more closely: Note: The Web Applications WG is seeking feedback on required algorithms for widget signatures, in particular which algorithms should be required in addition to RSAwithSHA256. The WG has not yet agreed on final set of required

RE: [widget-digsig] proposed change to 7.1, common constraints, for algorithms

Hi Frederick, I agree with all of your changes with two comments. The sentence: "The Signature MUST be produced using a key of the recommended key length " is still problematic given that we allow (although discourage) key l

[widget-digsig] Editors note to be added to widget signature

Based on the discussion on today's call, I will add the following editors note to Widget Signature in section 6, Algorithms [1]: Note: This Widget Signature specification relies on XML Signature 1.1 and the Web Applications WG is also seeking feedback on required algorithms for widget sig

RE: [widgets-digsig] Updated 5.1 with revised Reference constraint text

Looks good to me - thanks Frederick and Marcos! From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Frederick Hirsch Sent: 18 March 2009 21:03 To: WebApps WG Cc: Frederick Hirsch Subject:

RE: [widget-digsig] changed widget signature files processing rule in section 4

Hi Frederick, Small comment. I would change the sentence: "Process the digital signatures in the signatures list in descending order, with distributor signature s first." to "Process the digital signatures in the signatures

RE: [widgets] Agenda for 19 March 2009 Voice Conference

Regrets for today's call; conflict with UWA. I will join late if possible. Best regards, Bryan Sullivan | AT&T -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Wednesday, March 18, 2009 6:41 AM To: public-webap

Re: [widgets] Minutes from 25 February 2009 Widgets F2F Meeting

Please take a look at the FPWD of XML Signature 1.1 which describes the use of Elliptic Curve algorithms in the context of XML Signature: http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/ Ideally widgets signature should just reference XML Signature 1.1 algorithms. I also note that the

[widgets] Further argument for making config.xml mandatory

Hi Marcos, All, I would like to raise a comment in support of making the configuration document at the root of the widget mandatory. The localisation model currently described by [1] allows for multiple configuration documents; zero or one at the root of the widget and zero or one at the root o

Re: [widgets] s on s

Hi Robin, On Thu, Mar 19, 2009 at 7:34 AM, Marcos Caceres wrote: > On Thu, Mar 19, 2009 at 7:27 AM, Robin Berjon wrote: > Will fix required. Required denotes if a feature is absolutely needed > for the widget to function (i.e., without this feature, the widget > serves no purpose.) > I've simpl

RE: [widgets] Minutes from 25 February 2009 Widgets F2F Meeting

Dear Art, May I give feedback on an old action item regarding the preference for ECDSA vs. DSA. I hope that T-Mobile's position statement is not too late. T-Mobile favors ECDSA. DSA has no advantage regarding speed and memory consumption against the classic RSA. ECDSA improves the security leve

Re: [XHR2] Upload progress events and simple cross-origin requests

On Thu, 19 Mar 2009, Alexey Proskuryakov wrote: > > In fact, it seems very likely that even timing of preflight requests > makes port scans possible, but I don't have any data to support this > theory. Port scans are already possible with unscripted HTML using elements and , and are certainly

Re: [XHR2] Upload progress events and simple cross-origin requests

19.03.2009, в 2:48, Jonas Sicking написал(а): It can, though potentially not as reliably. And it's also something we'd like to fix. In other words, port-scanning of intranets isn't something I'd like to build into the standard. Especially when protection for it comes at a relatively low cost. L