Re: [cors] Redirects and preflights
What about the following scenario: 1. A page on site A initiates a DELETE request to a uri on site B 2. The UA makes a preflight OPTIONS request to the uri on site B 3. The site responds and says the original DELETE request is ok 4. The UA makes the DELETE request to site B 5. The site responds with a 303 that redirects to a different uri on site B. Network error steps. Should this redirect not be followed even though it technically does not require a preflight? Correct. All redirects on the actual request fail. I don't think that is desirable nor necessary, see below. I think it's fairly important that we do follow the redirect since a common way to deal with state changing requests is to redirect to a URI that contains the response. This avoids ugly you have to refresh to display this page pages in browsers. So I think the redirect should be followed. Why would there be no redirect on the OPTIONS request? It's very possible for a server to serve different redirects for different request methods. My understanding of the HTTP spec is that a 303 response is meant to mean that the current uri has handled the request, but that the response is located at a different uri. For normal browser navigation this is the recommended way to, for example, allow a POST to a shopping cart that adds an item to the shopping cart, while still allowing the user to navigate back to the result page without worrying about another item being added to the shopping cart. A POST is performed to a uri that adds the desired item, but then uses a 303 response to redirect the user to the page that actually displays the shopping cart. If the user then navigates away from that page, and then back to it, it'll still result in a safe GET request to the uri that displays the shopping cart, without adding any additional items to it. So this is quite a common pattern on the web today, and ideally should be more common. Rather than using the state-changing GET requests sites do today to avoid having to deal with the ugly you need to refresh to display this page again error pages that browsers produce from un-redirected POST requests. For this setup it makes a lot of sense to not redirect a OPTIONS request, but to redirect a POST request to the same uri. What should be done in the following scenario: 1. A page on site A initiates a DELETE request to a uri on site B 2. The UA makes a preflight OPTIONS request to the uri on site B 3. The site responds with a 303 to a different uri on site B. Currently the specification treats all redirects the same. I guess we could special case 303. In the setup described above, even if the server redirects the add-item-to-cart OPTIONS response to the display-shopping-cart uri, it makes little sense to redirect the POST there. That would never have happened for a same-site POST request going to the add-item-to-cart uri. Should perhaps a 303 redirect mean that the DELETE request should be made to the initial uri on site B, assuming that the preflight after redirects ended up returning a response with the appropriate headers? No, that seems wrong. Why? A 303 just means that the response is located elsewhere, not that the action is performed by a different uri. I don't have strong opinions on this one. But a gut feeling is that only a 307 should cause the DELETE to go somewhere else as that is the only time when that would have happened if the DELETE would have been done directly to the first uri on site B. 301 and 302 should do that too. Why? Note that 302 is basically treated as a 303 by most browsers today just because what the spec says is basically terrible UI asking the user to make a decision he/she does not have enough information to make. More below. And here's another: 1. A page on site A initiates a POST request to a uri on site B. The request is a entity body and a Content-Type of text/plain 2. Since no preflight is needed The UA makes the request to the uri on site B 3. Before the server has responded, the page adds a event listener for the progress event on the upload object. (This listener won't be notified according to spec) 4. The server responds with a 307 redirect to another URI on site B. Should the request to the new URI on site be now be done with a preflight? Or should the algorithm abort because a preflight is now required but there is a redirect. Or should the redirect be followed but the event listener not be notified? In other words, should the fact that there is upload event listeners be measured on just the initial request, or on each redirect. I think the fact that there is upload event listeners should be measured just on the initial request. So in the example above the redirect should be followed but no events would be fired on the upload object. I think this is already clear in the specification. My understanding is that the answer is that it's only measured in the beginning. Is this correct?
RE: [Widgets] Opera's position on Elliptic Curve and x509v3
I agree with both of Marcos's points here. I support postponing elliptic curve to later version I also agree restricting x509 to version 3 is ok -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: Wednesday, March 04, 2009 6:25 AM To: Frederick Hirsch; public-webapps; ext Priestley, Mark, VF-Group Cc: Arve Bersvendsen Subject: [Widgets] Opera's position on Elliptic Curve and x509v3 At the F2F, I agreed to ascertain Opera's position on adding elliptic curve support and restricting x509 to version 3. Wrt Eliptic Curve, Opera would prefer _not_ to have elliptic curve support for version 1 of Widgets Dig Sig, but would possibly like to see its inclusion in future version of the spec. Wrt restricting to x509 to version 3, we are ok with this. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
RE: [widgets] Agenda for 5 March 2009 Voice Conference
My regrets for this call. One input however, in the last F2F there was a call for more editors to help speed up the widgets work (part of the AI to Dave Rogers). Please let me know which specs need editors, and I will make a proposal on where I can help. Best regards, Bryan Sullivan | ATT -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Wednesday, March 04, 2009 5:28 AM To: public-webapps Subject: [widgets] Agenda for 5 March 2009 Voice Conference Below is the draft agenda for the March 5 Widgets Voice Conference (VC). Inputs and discussion before the meeting on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Logistics: Time: 23:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration = 60 minutes Zakim Bridge +1.617.761.6200, conference 9231 (WAF1) IRC channel = #wam; irc.w3.org:6665 Confidentiality of minutes = Public Agenda: 1. Review and tweak agenda 2. Announcements 3. DigSig + PC synchronization - is this now addressed adequately in the latest EDs: http://dev.w3.org/2006/waf/widgets/ http://dev.w3.org/2006/waf/widgets-digsig/ 4. Issue-19 - Widgets digital Signatures spec does not meet required use cases and requirements; Proposal to Close this issue: http://www.w3.org/2008/webapps/track/issues/19 5. Issue-80 - Runtime localization model for widgets; can this be closed? http://www.w3.org/2008/webapps/track/issues/80 6. Issue-82 - potential conflict between the XHTML access and Widget access element. What, if anything, should be done: http://www.w3.org/2008/webapps/track/issues/82 7. Issue-83 - Instantiated widget should not be able to read digital signature. What is the status: http://www.w3.org/2008/webapps/track/issues/83 8. Widget requirement #37 (URI scheme etc) - see e-mail from Thomas: http://www.w3.org/mid/9dd110c1-d860-40c9-b688-2e08f4d86...@w3.org 9. Open Actions - please address your Open Actions: http://www.w3.org/2008/webapps/track/products/8 10. AOB: a. June f2f meeting - besides Oslo/Opera and Edinburgh/OMTP, are there any other proposals? b. TPAC meeting in November
Re: Progress Events normative text
On Sat, 10 Jan 2009 00:28:42 +0100, Ian Hickson i...@hixie.ch wrote: On Fri, 21 Nov 2008, Charles McCathieNevile wrote: I think it is wrong to make content non-conforming because it fires events in a fashion that isn't consistent with this draft. These are conformance requirements. Nothing forces content to be conforming, but it is valuable to have a clear explanation of what conformance means (otherwise why would you have bothered commenting on the need for such clarity). There are many reasons for doing so... There are some reasons why this might be done, but I don't see any example sufficiently compelling to effectively abrogate a sense of conformance for content. It seems odd to me to say that content is not allowed to work around bugs in browsers, for instance. Content is allowed to do whatever it wants. However, only some content is defined as conforming, and in this case, content that does things not predicted by the spec is defined as non-conforming. This avoids attempting to ascribe motive to the content. Do these requirements mean that if a script calls dispatchEvent(), that the UA would be non-conforming if it dispatched the event? e.g. if the script fires 'abort', then 'load', then 'progress', then 'loadstart' twice, is the UA non-conforming? The text is unclear. If the script (content) calls for the events to be dispatched in a non-conforming order, then the content is non-conforming. That a conformant UA can support non-conformant content is unclear - I will clarify that in the text. This still seems unclear to me in the text. I added a more explicit note in the conformance section of rev 1.30 Below the table, there are some paragraphs that again may not make sense: # User agents must implement these events such that by default the events # do not bubble, and are not be cancelable. What does it mean for an event to not bubble by default? Or not be cancelable by default? Events don't have defaults. User agent implementations of events have defaults - either the user agent (absent other considerations) makes the event bubble, or it doesn't. Could you illustrate some way in which one of these events could be fired without an explicit decision on whether the event bubbles or is cancelable, such that the default has an effect? Or to put it another way, could you show a test case that tests this requirement? Such a test case would require a specification that used progress events without saying what they do, and testing whether they bubble. # Two kinds of initialisation methods are provided: one # (initProgressEventNS) in which the namespace is required and must be # null (any event in another namespace is not defined by this # specification), and one (initProgressEvent) which assigns the null # namespace automatically. I don't understand what it means for the argument to be required to be null. Why shouldn't people use the ProgressEvent interface with custom events in their own namespace? There is no prohibition on or recommendation against doing that. This specification simply refrains from any attempt to define what such events might mean. I don't understand what this means: # Two kinds of initialisation methods are provided: one # (initProgressEventNS) in which the namespace is required and must be # null [...] ...if it does not mean that the namespace must be null. If you mean namespace must be null _when used to create events defined in this specification_ then that should be said, though it is redundant with earlier text. changed. How does this interact with equivalent requirements in other specifications? Does this mean that two events should be fired, one for the requirement in HTML5, say, and one for this spec? No. The event in HTML5 that is the event initially defined in this spec, with further specification relevant to HTML5-specific features (if I am not mistaken). It is very confusing to me to have two specs saying that an event must be fired, if we are only expecting one ever to be fired. (This is why I would have preferred this spec to define functions or macros that other specs could then invoke to fire the events.) Added a section on Firing Progress Events # 2.3 Interface definitions This is the one section that really needs normative text, since it is the one section that is really defining new features. However, as far as I can tell, it really doesn't define anything normatively. For example, the attributes have no UA requirements. Is lengthComputable supposed to throw, return true, return false, have any side-effects? Same for the others. This problem still exists. Perhaps I am missing something here. They are attributes. They have values, which are described. In what circumstances would they throw, or have side effects, or return anything except their value? The only requirement that _is_ given and isn't redundant with WebIDL is: # If any other parameter is
New Progress draft 1.30
(Finally, some progress!) Hopefully I have resolved ISSUE-79 raised by Ian, by removing the requirement that lengthComputable be clamped by the user agent. So the question is whether this draft is ready for last call. Ideally there would be test cases available, and more examples, but those are not requirements (although I welcome anybody producing them). http://dev.w3.org/2006/webapi/progress/Progress.html cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: BONDI Candidate Release 1.0 - open for public comment until 9th of March 2009
Dear Art, Thanks for the email. Please see my comments inline marked [DAVID]. David, Since many of WebApps' members are not familiar with OMTP and BONDI, I have a some first order process-related questions regarding the proposed Release Candidate (RC). I'll withhold other comments e.g spec forking, fragmentation, etc. for now. * Where can we find the process that describes OMTP's comment and response process/protocol as well as the next step after RC? Does OMTP's process include a consensus commitment regarding the public's comments (as does the W3C's process [1])? [DAVID] We can receive any public comments through either our public forum (under feedback at the bottom left of the BONDI homepage) or through a formal change request. In order to register a formal change request you will need to register for an account first. OMTP will discuss all comments during our working group meetings. * Where is the public archive for the comments? [DAVID] All the public comments are stored on the BONDI site, viewable to all. Please see the links from the Release Candidate page. * Where is the exit criteria for this RC? Assuming this criteria requires two or more interoperable implementations (as is typically the case for W3C Candidate specs), where can we find the data that show there are interoperable implementations of the RC? [DAVID] This is dependent on the feedback received from the public review. I should add that we have extended this review period - it will now close on the 23rd of March 2009. I'll be able to give you some more information following those discussions. Clearly we are not going to encourage non-interoperable solutions as the whole intention of BONDI is to have interoperable widgets across devices. * Based on a scan of [2], it appears this RC codifies the following version of WebApps' widgets specs: Packaging and Configuration - 12- Dec-2008; Digital Signatures - unspecified; APIs and Event - not included; Updates - the 07-Oct-2008 FPWD. Please confirm/clarify. [DAVID] As Marcos raised in the meeting, there was an error in one of these references to an earlier draft. You are welcome to register this as feedback. You are correct in stating that we do not reference the APIs and Events spec yet. Our plan is to update references upon the closure date for feedback (23rd of March). * Regarding the following text in [2]: [[ BONDI has chosen to adopt the W3C Widgets 1.0: Packaging and Configuration [7] specification. At the time of writing this specification has been published by the W3C Web Applications group (http://www.w3.org/2008/webapps) as a Working Draft at Last Call, and is judged to be stable enough to use as a basis for this BONDI specification. ]] Given the clear Implementers should be aware that this document is not stable. warning in this LCWD [3], what criteria was used to determine this LCWD is judged to be stable enough to use as a basis for this BONDI specification? [DAVID] Given the wealth of widget platforms being developed and already in the market and OMTP's timelines, I think this is the case for many other organisations who are developing widget solutions. It is our intention to deliver a W3C compliant BONDI once the W3C specifications are complete. We are fully aware that the specs could change. As agreed last week, we will produce an evolution plan to show how we intend to do this. We have committed to doing as much as possible to help W3C in working towards this. Indeed, every person around the table at the Widgets meeting last week was an OMTP member. Thanks, David. OMTP Director of External Relations -Regards, Art Barstow, Chair of WebApps WG [1] http://www.w3.org/2005/10/Process-20051014/policies.html#Consensus [2] http://bondi.omtp.org/Documents/CR10/ BONDI_Architecture_Security_Task_CR10.pdf [3] http://www.w3.org/TR/2008/WD-widgets-20081222/ On Feb 26, 2009, at 3:46 AM, ext David Rogers wrote: Dear all, As discussed in the Widgets F2F in Paris, please find the links to the OMTP BONDI Candidate Release 1.0 documentation as follows. This is open for public comment at the moment until the 9th of March 2009 and can be downloaded from the BONDI site [1]: 1) BONDI Architecture Security [2] 2) BONDI Architecture Security Appendices [3] 3) BONDI Interfaces [4] 4) BONDI Architecture Security Lifecycle Events Use Cases [5] 5) All above files in a zip [6] Please also have a look at the BONDI APIs [7]. We would welcome any feedback or change proposals and if you have any questions, please feel free to email me. Thanks, David. [1] http://bondi.omtp.org/ [2] http://bondi.omtp.org/Documents/CR10/ BONDI_Architecture_Security_Task_CR10.pdf [3] http://bondi.omtp.org/Documents/CR10/ BONDI_Architecture_Security_Task_Appendices_CR10.pdf [4] http://bondi.omtp.org/Documents/CR10/
RE: Re: BONDI Candidate Release 1.0 - open for public comment until 9th of March 2009
The URL for public archive of comments: http://bondi.omtp.org/Lists/BONDI%2010%20CR%20%20Feedback/AllItems.aspx Dr. Nick Allott Chief Technology Officer OMTP - BONDI From: David Rogers Sent: 05 March 2009 14:06 To: Arthur Barstow Cc: public-webapps@w3.org; public-device-a...@w3.org; Nick Allott Subject: Re: BONDI Candidate Release 1.0 - open for public comment until 9th of March 2009 Dear Art, Thanks for the email. Please see my comments inline marked [DAVID]. David, Since many of WebApps' members are not familiar with OMTP and BONDI, I have a some first order process-related questions regarding the proposed Release Candidate (RC). I'll withhold other comments e.g spec forking, fragmentation, etc. for now. * Where can we find the process that describes OMTP's comment and response process/protocol as well as the next step after RC? Does OMTP's process include a consensus commitment regarding the public's comments (as does the W3C's process [1])? [DAVID] We can receive any public comments through either our public forum (under feedback at the bottom left of the BONDI homepage) or through a formal change request. In order to register a formal change request you will need to register for an account first. OMTP will discuss all comments during our working group meetings. * Where is the public archive for the comments? [DAVID] All the public comments are stored on the BONDI site, viewable to all. Please see the links from the Release Candidate page. * Where is the exit criteria for this RC? Assuming this criteria requires two or more interoperable implementations (as is typically the case for W3C Candidate specs), where can we find the data that show there are interoperable implementations of the RC? [DAVID] This is dependent on the feedback received from the public review. I should add that we have extended this review period - it will now close on the 23rd of March 2009. I'll be able to give you some more information following those discussions. Clearly we are not going to encourage non-interoperable solutions as the whole intention of BONDI is to have interoperable widgets across devices. * Based on a scan of [2], it appears this RC codifies the following version of WebApps' widgets specs: Packaging and Configuration - 12- Dec-2008; Digital Signatures - unspecified; APIs and Event - not included; Updates - the 07-Oct-2008 FPWD. Please confirm/clarify. [DAVID] As Marcos raised in the meeting, there was an error in one of these references to an earlier draft. You are welcome to register this as feedback. You are correct in stating that we do not reference the APIs and Events spec yet. Our plan is to update references upon the closure date for feedback (23rd of March). * Regarding the following text in [2]: [[ BONDI has chosen to adopt the W3C Widgets 1.0: Packaging and Configuration [7] specification. At the time of writing this specification has been published by the W3C Web Applications group (http://www.w3.org/2008/webapps) as a Working Draft at Last Call, and is judged to be stable enough to use as a basis for this BONDI specification. ]] Given the clear Implementers should be aware that this document is not stable. warning in this LCWD [3], what criteria was used to determine this LCWD is judged to be stable enough to use as a basis for this BONDI specification? [DAVID] Given the wealth of widget platforms being developed and already in the market and OMTP's timelines, I think this is the case for many other organisations who are developing widget solutions. It is our intention to deliver a W3C compliant BONDI once the W3C specifications are complete. We are fully aware that the specs could change. As agreed last week, we will produce an evolution plan to show how we intend to do this. We have committed to doing as much as possible to help W3C in working towards this. Indeed, every person around the table at the Widgets meeting last week was an OMTP member. Thanks, David. OMTP Director of External Relations -Regards, Art Barstow, Chair of WebApps WG [1] http://www.w3.org/2005/10/Process-20051014/policies.html#Consensus [2] http://bondi.omtp.org/Documents/CR10/ BONDI_Architecture_Security_Task_CR10.pdf [3] http://www.w3.org/TR/2008/WD-widgets-20081222/ On Feb 26, 2009, at 3:46 AM, ext David Rogers wrote: Dear all, As discussed in the Widgets F2F in Paris, please find the links to the OMTP BONDI Candidate Release 1.0 documentation as follows. This is open for public comment at the moment until the 9th of March 2009 and can be downloaded from the BONDI site [1]: 1) BONDI Architecture Security [2] 2) BONDI Architecture Security Appendices [3] 3) BONDI Interfaces [4] 4) BONDI Architecture Security Lifecycle Events Use Cases [5] 5) All above files in a zip [6] Please also have a look at the BONDI APIs [7].
numbering
http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures 4.3 If the signatures list is not empty, sort the list of signatures by the file name field in descending order (e.g. signature001.xml followed by signature9.xml followed by signature.xml). How do you sort signature009.xml and signature9.xml? The proposal is to only allow [1-9][0-9]*, which should solve this. And validators should complain about archives containing files of the form signature [0][0-9]* .xml
Re: [Selectors API] Call for Consensus - approve John Resig's tests
Ian Hickson wrote: However, I don't think the things tested in 002 are controversal. In particular, all the UAs have converged on the behaviour tested by 002-001 for other objects Ah, that wasn't the case last I checked. And again, there's no specification I can find that requires it. 002-002 is explicitly required by the IDL block in Selectors API This is the dependency on WebIDL I was talking about. and I think there's no controversy over that particular requirement Probably not, though I suspect that Gecko won't implement this any time soon; certainly not until WebIDL stabilizes more. It requires some pretty nontrivial changes. and 002-003 is a bog-standard DOM test of one of the requirements in the Selectors API that doesn't really depend on WebIDL at all. Sure; I didn't have any issues with that one. So since everyone is converging on the behaviour tested here, it should be pretty safe. It depends on whether you want tests for behavior that UAs are converging on or for behavior that the relevant specs actually require. For that matter, it's not clear to me that test 001 is. Why not? I think everything in 001 is non-controversal and tests only things that are required by Selectors API, no? I was talking about 002-001. -Boris
Re: New Progress draft 1.30
On Mar 5, 2009, at 14:15 , Charles McCathieNevile wrote: So the question is whether this draft is ready for last call. Ideally there would be test cases available, and more examples, but those are not requirements (although I welcome anybody producing them). I'd go to LC as that's the only way to be sure people actually wake up and comment :) You don't specify what IDL you use, that should probably be clarified. The rest seems fine to me, though it could use a little CSS polish here and there. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
[widgets] Minutes from 5 March 2009 Voice Conference
The minutes from the March 5 Widgets voice conference are available at the following and copied below: http://www.w3.org/2009/03/05-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 12 March 2009 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 05 Mar 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009JanMar/0622.html See also: [3]IRC log [3] http://www.w3.org/2009/03/05-wam-irc Attendees Present Art, Frederick, Josh, Jere, Marcos, Arve, David, Benoit Regrets Claudio, Bryan Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]DigSig + PC synchronization 4. [8]Issue-19 - Widgets digital Signatures spec does not meet required use cases and requirements; 5. [9]Issue-80 - Runtime localization model for widgets 6. [10]Issue-82 - potential conflict between the XHTML access and Widget access element. 7. [11]Issue-83 - Instantiated widget should not be able to read digital signature. 8. [12]Widget requirement #37 (URI scheme etc) - see e-mail from Thomas: 9. [13]Open Actions 10. [14]June f2f meeting 11. [15]TPAC meeting in November 12. [16]Window Modes 13. [17]Editorial Tasks 14. [18]Anything Else * [19]Summary of Action Items _ scribe ScribeNick: ArtB scribe Scribe: Art Date: 5 March 2009 fjh widgets signature editors draft update fjh [20]http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures [20] http://dev.w3.org/2006/waf/widgets-digsig/#locating- signatures fjh [21]http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures [21] http://dev.w3.org/2006/waf/widgets-digsig/#locating- signatures Review and tweak agenda AB: agenda posted March 4 - is [22]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/06 22.html ... the main agenda items are Open Issues. I only want to spend a few minutes on each of them to get a sense of where we are e.g. still Open, pending inputs, can be Closed. Any detailed technical discussions should occur on public-webapps mail list. ... Are there any change requests? [22] http://lists.w3.org/Archives/Public/public-webapps/ 2009JanMar/0622.html [ None ] Announcements AB: I don't have any urgent announcements ... what about others? FH: please submit comments on XML Sig 1.1 drafts DR: I will respond to Art's BONDI 1.0 email so please look at that fjh please review XML Signature 1.1 and XML Signature Properties FPWD fjh [23]http://www.w3.org/News/2009#item25 [23] http://www.w3.org/News/2009#item25 MC: I uploaded the Window Modes spec; would like to get that on the agenda DigSig + PC synchronization AB: earlier this week Frederick asked me if the DigSig + PC specs are now in synch, based on last week's discussions? fjh [24]http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures [24] http://dev.w3.org/2006/waf/widgets-digsig/#locating- signatures AB: I believe the answer is yes. ... where are we on this? MC: FH and I talked about this ... I think this is mostly now addressed ... PC has no real depedency on DigSig fjh marcos notes merged steps 4 +5, moved locating to dig sig, removed signature variable from p + c MC: I haven't completed the PC changes yet ... e.g. renumber some steps fjh fjh notes revised text on locating to fit it within digsig but essence is same FH: I had to revise the location text a bit but the logic is the same ... Josh asked about the sorting ... I need to think about that a bit more JS: need to clarify diff between 9 and 009 ... we can take this discussion to the list FH: I agree we need more rigor here MC: I agree too ... need to address case sensitivity too AB: can we point to some existing work? FH: I don't think this is a big issue and agree we can discuss on the list AB: what needs to be done then? FH: I need to make a few changes to DigSig and MC needs to do a bit more on PC JS: re styling, orange doesn't work well for me regarding readability MC: I can help with that FH: I'll take a pass at that DR: re the ell curve issue, I have asked OMTP to provide comments by March 9 so I should have data for the WG by Mar 12 Issue-19 - Widgets digital Signatures spec does not meet required use cases and requirements;
Re: numbering
Josh, This does not seem quite right since it requires 10 or more signatures? e.g. disallows signature01.xml, signature02.xml etc and requires signature10.xml etc --- I propose the following alternative in section 5.3 Naming convention for a distributor signature:signature [0-9]* .xml Every distributor signature MUST have the same number of digits in the file name and use leading zeros for numbers less than the maximum numeric value. This is to enable consistent sorting. To give an example, if nine distributor signatures are expected the numbers should range from 01 to 09, e.g. signature01.xml to signature09.xml. --- Does this make sense? regards, Frederick Frederick Hirsch Nokia On Mar 5, 2009, at 9:15 AM, ext timeless wrote: http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures 4.3 If the signatures list is not empty, sort the list of signatures by the file name field in descending order (e.g. signature001.xml followed by signature9.xml followed by signature.xml). How do you sort signature009.xml and signature9.xml? The proposal is to only allow [1-9][0-9]*, which should solve this. And validators should complain about archives containing files of the form signature [0][0-9]* .xml
Re: [widgets] Minutes from 5 March 2009 Voice Conference
I updated the style for code items in the Digital Signature specification to brown. Does this work better? It does not conflict with other color uses as far as I can tell. Please look at http://dev.w3.org/2006/waf/widgets-digsig/ (refresh) regards, Frederick Frederick Hirsch Nokia On Mar 5, 2009, at 10:11 AM, Barstow Art (Nokia-CIC/Boston) wrote: The minutes from the March 5 Widgets voice conference are available at the following and copied below: http://www.w3.org/2009/03/05-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 12 March 2009 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 05 Mar 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009JanMar/0622.html See also: [3]IRC log [3] http://www.w3.org/2009/03/05-wam-irc Attendees Present Art, Frederick, Josh, Jere, Marcos, Arve, David, Benoit Regrets Claudio, Bryan Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]DigSig + PC synchronization 4. [8]Issue-19 - Widgets digital Signatures spec does not meet required use cases and requirements; 5. [9]Issue-80 - Runtime localization model for widgets 6. [10]Issue-82 - potential conflict between the XHTML access and Widget access element. 7. [11]Issue-83 - Instantiated widget should not be able to read digital signature. 8. [12]Widget requirement #37 (URI scheme etc) - see e-mail from Thomas: 9. [13]Open Actions 10. [14]June f2f meeting 11. [15]TPAC meeting in November 12. [16]Window Modes 13. [17]Editorial Tasks 14. [18]Anything Else * [19]Summary of Action Items _ scribe ScribeNick: ArtB scribe Scribe: Art Date: 5 March 2009 fjh widgets signature editors draft update fjh [20]http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures [20] http://dev.w3.org/2006/waf/widgets-digsig/#locating- signatures fjh [21]http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures [21] http://dev.w3.org/2006/waf/widgets-digsig/#locating- signatures Review and tweak agenda AB: agenda posted March 4 - is [22]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 06 22.html ... the main agenda items are Open Issues. I only want to spend a few minutes on each of them to get a sense of where we are e.g. still Open, pending inputs, can be Closed. Any detailed technical discussions should occur on public-webapps mail list. ... Are there any change requests? [22] http://lists.w3.org/Archives/Public/public-webapps/ 2009JanMar/0622.html [ None ] Announcements AB: I don't have any urgent announcements ... what about others? FH: please submit comments on XML Sig 1.1 drafts DR: I will respond to Art's BONDI 1.0 email so please look at that fjh please review XML Signature 1.1 and XML Signature Properties FPWD fjh [23]http://www.w3.org/News/2009#item25 [23] http://www.w3.org/News/2009#item25 MC: I uploaded the Window Modes spec; would like to get that on the agenda DigSig + PC synchronization AB: earlier this week Frederick asked me if the DigSig + PC specs are now in synch, based on last week's discussions? fjh [24]http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures [24] http://dev.w3.org/2006/waf/widgets-digsig/#locating- signatures AB: I believe the answer is yes. ... where are we on this? MC: FH and I talked about this ... I think this is mostly now addressed ... PC has no real depedency on DigSig fjh marcos notes merged steps 4 +5, moved locating to dig sig, removed signature variable from p + c MC: I haven't completed the PC changes yet ... e.g. renumber some steps fjh fjh notes revised text on locating to fit it within digsig but essence is same FH: I had to revise the location text a bit but the logic is the same ... Josh asked about the sorting ... I need to think about that a bit more JS: need to clarify diff between 9 and 009 ... we can take this discussion to the list FH: I agree we need more rigor here MC: I agree too ... need to address case sensitivity too AB: can we point to some existing work? FH: I don't think this is a big issue and agree we can discuss on the list AB: what needs to be done then? FH: I need to make a few changes to DigSig and MC needs to do a bit more on PC
Re: New Progress draft 1.30
On Thu, 05 Mar 2009 15:54:38 +0100, Robin Berjon ro...@berjon.com wrote: On Mar 5, 2009, at 14:15 , Charles McCathieNevile wrote: So the question is whether this draft is ready for last call. Ideally there would be test cases available, and more examples, but those are not requirements (although I welcome anybody producing them). I'd go to LC as that's the only way to be sure people actually wake up and comment :) Actually people have been reasonably good about commenting whenever we *think* about going to LC :) You don't specify what IDL you use, that should probably be clarified. agree... The rest seems fine to me, though it could use a little CSS polish here and there. We accept patches :) Seriously, I have a pretty minimalist sense of aesthetics, and find it easier to read without too much CSS polish, but I would be happy to look at anything you think is an improvement. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [widgets] Minutes from 5 March 2009 Voice Conference
Easier on the eye, but to me it's pretty close to the color of RFC 2119 keyword style (em.ct). Seems like the body text font has grown in size somewhat, compared to other specs. --Jere On 5.3.2009 18.03, Hirsch Frederick (Nokia-CIC/Boston) frederick.hir...@nokia.com wrote: I updated the style for code items in the Digital Signature specification to brown. Does this work better? It does not conflict with other color uses as far as I can tell. Please look at http://dev.w3.org/2006/waf/widgets-digsig/ (refresh) regards, Frederick Frederick Hirsch Nokia On Mar 5, 2009, at 10:11 AM, Barstow Art (Nokia-CIC/Boston) wrote: JS: re styling, orange doesn't work well for me regarding readability MC: I can help with that FH: I'll take a pass at that
Re: [widgets] Minutes from 5 March 2009 Voice Conference
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 regards, Frederick Frederick Hirsch Nokia On Mar 5, 2009, at 11:45 AM, Kapyaho Jere (Nokia-D-MSW/Tampere) wrote: Easier on the eye, but to me it’s pretty close to the color of RFC 2119 keyword style (em.ct). Seems like the body text font has grown in size somewhat, compared to other specs. --Jere On 5.3.2009 18.03, Hirsch Frederick (Nokia-CIC/Boston) frederick.hir...@nokia.com wrote: I updated the style for code items in the Digital Signature specification to brown. Does this work better? It does not conflict with other color uses as far as I can tell. Please look at http://dev.w3.org/2006/waf/widgets-digsig/ (refresh) regards, Frederick Frederick Hirsch Nokia On Mar 5, 2009, at 10:11 AM, Barstow Art (Nokia-CIC/Boston) wrote: JS: re styling, orange doesn't work well for me regarding readability MC: I can help with that FH: I'll take a pass at that
Updated Widgets 1.0 Signature editors draft
I have updated the Widgets 1.0 Signature editors draft [1] as follows: 1) Added new section Locating and Processing Widget Signatures as noted on today's call. This section contains material that was formerly in the Packaging and Configuration Specification. 2) Updated the definitions section 3) Updated the references to reference the current XML Security First Public Working Drafts and more recent Widgets drafts. 4) Revised processing rules section to have common constraints for both signing and validation, rewrote some of the text, updated language related to signature failure. 5) Changed code style to brown and fixed various other editorial nits. There is currently some new text regarding distributor file naming from today's call, but this will probably change as we are discussing this on the list (I sent a proposed revision to the list) Still to do are possible changes related to Thomas's comments re ID reference language and additional properties. regards, Frederick Frederick Hirsch Nokia [1] http://dev.w3.org/2006/waf/widgets-digsig/
Re: numbering
On Mar 5, 2009, at 9:15 AM, I wrote: The proposal is to only allow [1-9][0-9]*, which should solve this. On Thu, Mar 5, 2009 at 5:59 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: This does not seem quite right since it requires 10 or more signatures? e.g. disallows signature01.xml, signature02.xml etc and requires signature10.xml etc I'm not certain about the []* notation. I was hoping for leading non-zero digit and 0 or more digits I propose the following alternative in section 5.3 Naming convention for a distributor signature:signature [0-9]* .xml Every distributor signature MUST have the same number of digits in the file name and use leading zeros for numbers less than the maximum numeric value. This is to enable consistent sorting. To give an example, if nine distributor signatures are expected the numbers should range from 01 to 09, e.g. signature01.xml to signature09.xml. --- Does this make sense? That'd work too, and i suppose would be easier on a sorter since it could do an alpha sort. Although you need to explain what to do if there are only signature01.xml and signature1.xml, does the engine always favor the longest string and ignore all shorter sets? Either way, validators need instructions, for yours it would need to warn about signatures which have the wrong number of digits.
Re: [widgets] Minutes from 5 March 2009 Voice Conference
how about simple italics for code? I'll also look into reducing body text regards, Frederick Frederick Hirsch Nokia On Mar 5, 2009, at 11:59 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote: 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 regards, Frederick Frederick Hirsch Nokia On Mar 5, 2009, at 11:45 AM, Kapyaho Jere (Nokia-D-MSW/Tampere) wrote: Easier on the eye, but to me it’s pretty close to the color of RFC 2119 keyword style (em.ct). Seems like the body text font has grown in size somewhat, compared to other specs. --Jere On 5.3.2009 18.03, Hirsch Frederick (Nokia-CIC/Boston) frederick.hir...@nokia.com wrote: I updated the style for code items in the Digital Signature specification to brown. Does this work better? It does not conflict with other color uses as far as I can tell. Please look at http://dev.w3.org/2006/waf/widgets-digsig/ (refresh) regards, Frederick Frederick Hirsch Nokia On Mar 5, 2009, at 10:11 AM, Barstow Art (Nokia-CIC/Boston) wrote: JS: re styling, orange doesn't work well for me regarding readability MC: I can help with that FH: I'll take a pass at that
Re: ISSUE-19: Widgets digital Signatures spec does not meet required use cases and requirements [Widgets]
During the March 5 widgets voice conference, the group agreed [1] this issue can be closed since the latest version of the Widgets Digital Signature spec [2] address this issues' concerns. -Regards, Art Barstow [1] http://www.w3.org/2009/03/05-wam-minutes.html#item04 [2] http://dev.w3.org/2006/waf/widgets-digsig/ On Jun 26, 2008, at 11:54 PM, ext Web Applications Working Group Issue Tracker wrote: ISSUE-19: Widgets digital Signatures spec does not meet required use cases and requirements [Widgets] http://www.w3.org/2008/webapps/track/issues/ Raised by: Marcos Caceres On product: Widgets R11. Digital Signature A conforming specification must specify a means to digitally sign resources in a widget resource and a processing model for verifying the authenticity and the data integrity of the widget resource. The digital signature scheme must be compatible with existing Public Key Infrastructures (PKI), particularly X.509 digital certificates. In addition, the recommended digital signature format should support certificate chaining and the ability for a package to be signed by multiple authorities (i.e., multiple signatures). The current Widgets 1.0: Digital Signature spec does not meet these requirements [1]. We currently only solve the problem for one signer signing the widget. We need to find solutions for: 1. Signing the package and allowing certificate chaining: signature.xml = A signs B signs...N signs widget files 2. Allowing multiple parties to sign the certificate in a separate file: SignatureB signs signatureA signs widget files 3. Allowing parallel signatures to sign the contents of a package: SignatureA signs widget files SignatureB signs widget files We are still exploring if there are any use cases for a mixed-mode, e.g.: SignatureA signs widget files SignatureB signs widget files SignatureC signs SignatureA [1] http://dev.w3.org/2006/waf/widgets-digsig/
Re: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]
Mark - during the March 5 widgets voice conference we discussed this issue that you raised [1]. Marcos created this issue from the following e-mail thread: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 0521.html A couple of the people on the call asked for some more information, in particular the specific threat scenario. We would appreciate it if you would please elaborate on your concern. -Regards, Art Barstow On Feb 22, 2009, at 11:53 AM, ext Web Applications Working Group Issue Tracker wrote: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets] http://www.w3.org/2008/webapps/track/issues/83 Raised by: Mark Priestley On product: Widgets Need to mention somewhere that the digital signature must not be accessible by the start file once the widget is running.
RE: [Widgets] APIs and Events preference change
Arve, I'm glad you find a way to push this in! ;) Regards --- Ivan De Marino Orange Labs Mobile and Web Software Engineer, RD UK tel. +44 20 8849 5806 mob. +44 7515 955 861 mob. +44 7974 156 216 ivan.demar...@orange-ftgroup.com This e-mail, and any files transmitted with it, is intended only for the use of the person/s or entity to whom it is addressed. If you are not the intended recipient (or authorised to receive information for the intended recipient) you must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and delete all copies of this e-mail. Thank you. France Telecom RD UK Ltd is a company registered in England and Wales with company number 4193379. Our registered office is Minerva House, Montague Close, London, SE1 9BB. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arve Bersvendsen Sent: 05 March 2009 14:14 To: public-webapps@w3.org Subject: [Widgets] APIs and Events preference change After the last F2F in Paris, I spoke to Ian Hickson about the Storage APIs in HTML5, and my understanding is now that his intent is to split this part of the spec into a separate document. This makes it much easier for us to reference an external spec, given that the scope of such a specification is much smaller. I have updated the spec, currently reflected in http://dev.w3.org/2006/waf/widgets-api/Overview.src.html to be in line with the current state of this future specification. Note that the Storage API as involved here obsoletes the need for the set/getPreference methods, and they are now commented out to reflect this. If the change is acceptable, it should close ACTION-233 and ACTION-313 -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: numbering
well I wonder why this regex disallow all multiple of 10 signature10.xml is not possible any more Xmlizer On Thu, Mar 5, 2009 at 6:10 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: I see, perhaps we can combine the text I proposed with a variant on the bnf you mentioned; signature[0-9]*[1-9].xml and add to my proposal the additional text: If a widget resource contains signatures that are not consistent in the number of digits in the names then the result of ordering will be implementation dependent. regards, Frederick Frederick Hirsch Nokia On Mar 5, 2009, at 12:03 PM, ext timeless wrote: On Mar 5, 2009, at 9:15 AM, I wrote: The proposal is to only allow [1-9][0-9]*, which should solve this. On Thu, Mar 5, 2009 at 5:59 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: This does not seem quite right since it requires 10 or more signatures? e.g. disallows signature01.xml, signature02.xml etc and requires signature10.xml etc I'm not certain about the []* notation. I was hoping for leading non-zero digit and 0 or more digits I propose the following alternative in section 5.3 Naming convention for a distributor signature:signature [0-9]* .xml Every distributor signature MUST have the same number of digits in the file name and use leading zeros for numbers less than the maximum numeric value. This is to enable consistent sorting. To give an example, if nine distributor signatures are expected the numbers should range from 01 to 09, e.g. signature01.xml to signature09.xml. --- Does this make sense? That'd work too, and i suppose would be easier on a sorter since it could do an alpha sort. Although you need to explain what to do if there are only signature01.xml and signature1.xml, does the engine always favor the longest string and ignore all shorter sets? Either way, validators need instructions, for yours it would need to warn about signatures which have the wrong number of digits.
Apple Patent Exclusion on Widgets 1.0: Updates
Hi, WebApps WG- Please be advised that Apple has disclosed a patent [1][2] and excluded claims from the W3C Royalty-Free License commitment of the W3C Patent Policy [3], for the Widgets 1.0: Updates specification [4]. The W3C Team, in conjunction with the Chairs and Apple, are now following the procedures for launching and operating a Patent Advisory Group (PAG). [5] We will update this Working Group as more details unfold. [1] http://www.w3.org/2004/01/pp-impl/42538/status [2] http://www.w3.org/2004/01/pp-impl/p66 [3] http://www.w3.org/TR/widgets-updates/ [4] http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion [5] http://www.w3.org/2007/04/patent-exception-management Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
