Re: [widgets] MWBP WG Comments of Widgets Reqs LC WD, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD
Hi Bryan, On Thu, Sep 4, 2008 at 6:42 AM, Sullivan, Bryan [EMAIL PROTECTED] wrote: Hi Marcos, I was starting to respond and thank you for the inclusion in the previous email when I saw this... having been out for vacation etc I did not get a chance to respond earlier. Yeah... as you know, I did include the requirements in the Requirements doc, but I was overruled by the working group and the consensus was reached to remove them. I would like the opportunity to discuss these in detail and support the rationale on the Widgets call. I don't understand the justification for rejection you have described. Overall the requirements represent the core (a limited set) of some pragmatic considerations that will affect the success of widget frameworks in real-world deployments, especially in the mobile device context. As you stated: The main reason for rejecting the feedback was that the proposed requirements were: (a) had limited impact on the actual specs (in normative terms), (b) were overly prescriptive and should really be left as an implementation detail on which implementations can compete, (c) added complexity on either the client side or the server side. (a) Is unclear (which specs are you talking about?). The Widget Requirements spec is the one being commented on, and it is giving direction to conforming specification writers (presumably in W3C and externally). Several of the proposed additions were written in normative terms and meant to be so. At the top of the Widget Requirements document, I list the specs that make up the Widgets 1.0: Family of Specifications. Those are the specifications that, possibly in conjunction with other W3C or external standards, will collectively address the requirements. During our August 14 teleconf [1], the Working Group reached consensus that we could not address the requirements within the specs we are producing or we disagreed with the requirement. Please refer to the teleconf minutes [1]. (b) In which cases were they overly prescriptive. This seems to me to be a value judgment based upon some criteria. The criteria I use is whether there will be significant negative effects on usability, interoperability, or efficiency if the requirements are not supported. Especially in the mobile case, the normative requirements I proposed can be supported in one or more of those terms. Again, it's not that we disagree with the requirements. It's just that some of them where prescriptive of technologies that the working group did not believe actually addressed the requirement (eg. CC/PP, etc.) (c) Re complexity, little of value comes free. But overall I don't think any of the proposed normative requirements could reasonably be called complex. I am willing to explain why if given the opportunity. We welcome all feedback and I'm personally happy to continue discussing any issues further. However, please be mindful that the working group is on a very tight deadline for these specifications (October's TPAC) and we would like to get MWBP's working group's approval or formal objections (if any) ASAP so we can move the Requirements forward along the publication track. If possible, we would really appriciate a formal response on behalf of MWBP by the end of next week. Kind regards, Marcos [1] http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0417.html -- Marcos Caceres http://datadriven.com.au
Re: XDomainRequest Integration with AC
Anne van Kesteren wrote: On Fri, 08 Aug 2008 20:44:04 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: The big worry I have though is if there is any possibility to puny encode the same origin in multiple ways (other than with or without default port). This could lead to different UAs encoding the same origin in different ways, which could lead to interoperability issues if sites rather than echoing the 'Origin' header always send out a static value for the Access-Control-Allow-Origin header. Is that possible? I don't think it is. Domain names follow a strict set of normalization rules. (That would also mean the Origin header could contain different values depending on the implementation, which is not the case.) The only thing that i _know_ of is that: http://foo.com and http://foo.com:80 are the same origin but have different string representations. I have also heard that some UAs are able to handle non-ascii characters in header values by somehow specifying an encoding. I don't really know how that works, but for those UAs the following to origins would be equivalent: http://www.xn--jrnspikar-v2a.com and http://www.järnspikar.com / Jonas
Re: XDomainRequest Integration with AC
On Fri, 05 Sep 2008 09:43:29 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: The only thing that i _know_ of is that: http://foo.com and http://foo.com:80 are the same origin but have different string representations. Yes, authors would have to use the former. (The former is also what Origin will tell them as well.) I have also heard that some UAs are able to handle non-ascii characters in header values by somehow specifying an encoding. I don't really know how that works, but for those UAs the following to origins would be equivalent: http://www.xn--jrnspikar-v2a.com and http://www.järnspikar.com Using the latter is non-conforming for Origin and also non-conforming for Access-Control-Allow-Origin, which per its current definition either mathces Origin literally or is a wildcard. So currently RFC 2047 extensions are simply not supported (and not needeD) by the specification. Given that interoperability on encoded-word is very poor I suggest we keep it that way. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[xmlhttprequest2] timeout and JSON
On Fri, 05 Sep 2008 02:36:58 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
1. A timeout property like the one on microsofts XDR. I haven't looked
into the specifics of XDRs property, but I would think that an
'abort' event should fire as well as readystate transitioning to
something if the timeout is reached.
What's wrong with using setTimeout?
2. A .responseJSON property. This would return the same thing as the
following code:
if (xhr.readyState != 4) {
return null;
}
return JSON.parse(xhr.responseText);
However there are a few details that can be quibbled about:
a) Should a partial result be returned during readystate 3
b) If the property is gotten multiple times, should that return the
same or a new object every time.
What's wrong with using JSON.parse?
(I'm not necessarily opposed, but I'd like to only add features that are
necessary.)
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: XDomainRequest Integration with AC
Anne van Kesteren wrote: ... Using the latter is non-conforming for Origin and also non-conforming for Access-Control-Allow-Origin, which per its current definition either mathces Origin literally or is a wildcard. So currently RFC 2047 extensions are simply not supported (and not needeD) by the specification. Given that interoperability on encoded-word is very poor I suggest we keep it that way. ... By all means, please do so. Maybe add a warning that RFC 2047 encoding is *not* allowed? BR, Julian
Re: XDomainRequest Integration with AC
Anne van Kesteren wrote: On Fri, 05 Sep 2008 09:43:29 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: http://foo.com and http://foo.com:80 are the same origin but have different string representations. Yes, authors would have to use the former. (The former is also what Origin will tell them as well.) I might be missing some context here... but use the former where, exactly? Would a page loaded from the latter not be able to do AC stuff? In general, I think forcing authors to think about whether the port is included is really poor practice and sounds like it would break real-world systems (e.g. any system that wants to run HTTP servers on multiple ports and just always specifies ports everywhere instead of specifying 8080 but not 80). Handling this in UAs is almost certainly reasonably straightforward (have to replace string compares with origin object compares, with the objects doing port normalization as needed). It doesn't seem like it would be hard to deal with in the spec either, though obviously it's a bit more work than just not dealing. So I'm not sure why we want to break the long-standing (and imo obvious per the relevant RFCs) convention that you get the same behavior for http:// no matter whether the port is explicitly listed as 80. -Boris
Re: XDomainRequest Integration with AC
On Fri, 05 Sep 2008 14:42:45 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: On Fri, 05 Sep 2008 09:43:29 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: http://foo.com and http://foo.com:80 are the same origin but have different string representations. Yes, authors would have to use the former. (The former is also what Origin will tell them as well.) I might be missing some context here... but use the former where, exactly? In the Access-Control-Allow-Origin header. Would a page loaded from the latter not be able to do AC stuff? That wouldn't matter. In general, I think forcing authors to think about whether the port is included is really poor practice and sounds like it would break real-world systems (e.g. any system that wants to run HTTP servers on multiple ports and just always specifies ports everywhere instead of specifying 8080 but not 80). Handling this in UAs is almost certainly reasonably straightforward (have to replace string compares with origin object compares, with the objects doing port normalization as needed). It doesn't seem like it would be hard to deal with in the spec either, though obviously it's a bit more work than just not dealing. So I'm not sure why we want to break the long-standing (and imo obvious per the relevant RFCs) convention that you get the same behavior for http:// no matter whether the port is explicitly listed as 80. That sounds reasonable. What's currently specified is equivalent to what HTML 5 specifies for the WebSocket protocol. It seemed reasonable to keep the two synchronized somewhat though maybe they should both change. Though do note that the value authors get (through the Origin header) will be without the default port so authors will have to deal with this anyway. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [widgets] OMTP input to W3C Widget Requirements (1 of 2)
Hi All, I've now integrated the OMTP requirements into the Req spec. OMTP crew, I'm made lots of edits (and dropped some of your requirements with Mark's permission) so please check to see that your intent is still conveyed (and that I haven't introduced any new typos, etc.). Apologies to those who are still waiting for me to respond to your comments, I'm going as fast as I can and will do my best to address everyone's comments within the next week. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-reqs/ On Fri, Aug 1, 2008 at 12:30 PM, David Rogers [EMAIL PROTECTED] wrote: Dear Art, Marcos and all, Please find attached the OMTP BONDI input to the W3C Web Applications WG Widget Requirements last call. I've extracted the text of the input below. Please note this is the first of two sets of input. This first input contains comments to existing requirements and proposals for new requirements. The second document contains more general comments, applicable to the Widget Requirements and also the Packaging and Configuration work. Introduction OMTP is a forum backed by many of the largest mobile operators and has members from many hardware and software vendors across the value chain. It was set up with the aim of gathering and driving mobile terminal requirements to ensure consistent and secure implementations, thereby reducing fragmentation and simplifying the customer experience of mobile data services. OMTP recommendations benefit carriers, content providers, middleware vendors and handset manufacturers to develop open and compatible mobile devices. OMTP have created their BONDI initiative to specifically address the problem of fragmentation in the evolution of the mobile web and to ensure the protection of the user from malicious web based services. The BONDI initiative will be delivering documentation throughout 2008 with the aim of driving activities in other appropriate standardisation and industry bodies such as W3C. Devices supporting some of the features of BONDI will become available in 2009. This document forms the input from BONDI relating to the security aspects of the W3C Widgets: 1.0 Requirements found at http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/. The document is divided into two parts; the first part details proposed changes to existing W3C requirements, the second part proposes new requirements that for inclusion. Part I - Changes to Existing Requirements Proposed By BONDI R11. Digital Signature We suggest the following re-wording of the existing requirement so that it reads: A conforming specification MUST specify a means to verify the authenticity and integrity of all resources in a widget resource, with the exception of any resources explicitly excluded by the specification. A conforming specification MUST provide this capability by specifying a processing model for generating and verifying a digital signature associated to a 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 SHALL support the ability to include a certificate chain with a digital signature to enable the receiving device to build a certificate chain from the end entity certificate used to generate the signature to a locally stored root certificate. In addition, the recommended digital signature format SHOULD support the ability for a widget resource to be signed using multiple end entity keys (i.e. it SHOULD be possible to include multiple signatures and associated certificate chains). The proposed changes attempt to tighten and clarify the use of digital signatures and certificate chains. In addition we suggest that the following text should be added to the existing requirement: A conforming specification SHALL specify the expected behaviour when multiple signatures and certificate chains are provided. A conforming specification SHALL specify that if none of the signatures and certificate chains can be verified, e.g. because of missing root certificates or where any certificates in the chain have expired or are not yet valid, then the widget resource SHALL be treated as unsigned. A conforming specification SHALL specify that the widget environment SHALL not install or load a widget resource when it can determine that any certificate in the chain has been revoked. This addition is to ensure that there is a consistent behaviour when verifying signatures and certificate chains, especially in error cases in which the verification fails because of missing certificates and in which one of the certificates has been revoked. We use the term load to cover the case in which a widget is not subject to an installation event. In addition, we suggest the following changes to the Rationale: To provide a means to verify authenticity, check data integrity, and
Re: Comments on Widgets 1.0: Requirements - Editor's Draft 15 August 2008
Hi Josh, Please approve the following corrections. Your comments did not require any further clarification from my part. Kind regards, Marcos On Thu, Aug 21, 2008 at 2:57 PM, timeless [EMAIL PROTECTED] wrote: http://dev.w3.org/2006/waf/widgets-reqs/ - Editor's Draft 15 August 2008 I'm very sorry about the delay, other things came up, most of my comments below are really English grammar notes and aren't particularly important (some are spelling which are just embarrassing) I put them in on purpose to keep you on your toes:) I believe my only major comment, which I didn't learn until last week (i.e. I wouldn't have known to comment about before the expiry period) is this point on 4-R12: I ran across a problem here (in 4-R12); we're internally discussing proxies (for mobile devices) that want to recompress data on the fly, they'd *love* to compress the files in a zip (thereby reducing the download size to the device), but in order for that to work, we'd need to make sure it doesn't break the signing. In general, keeping the radio on for larger downloads is a significant drain on device use time, and as such anything that can enable devices to leave it on for shorter periods is seen as a significant win (note this isn't asking that people use BZ2 or some extremely expensive to decompress algorithm, although I'm not actually sure if even that would be more expensive than the radio, but simple compression algorithms are definitely cheaper). (This now refers to R11). The spec is designed in such a way that recompressing will not break the signature. And yes, I'm aware that some people may download archives which have external pgp signatures. I don't expect mobile devices behind such proxies to have any interest in doing that, whereas I do expect them to want to access widgets. Given some of the things that the proxies have considered doing, I'm fairly certain they're not particularly worried about breaking a pgp signature (they don't seem to mind lossy image compression) . 3-Web and offline distribution: It must be possible to perform updates from either an online or offline source. but not both? True. Changed to It must be possible to perform updates from online and offline sources * Already a de facto standard on market-leading widget user agents on both desktops and mobile devices. this sounds wrong w/o included or supported, but i don't know how to fix it. Changed to already the supported de facto standard on market-leading widget user agents 4-R7-Rationale: ...variation in character encoding ...may render a widget ...inoperable ...unless a comment character encoding is used. 'comment'? Fixed. 4-R12 authorities (i.e., multiple signatures). drop the comma here - only use it for lists - see (e.g. 100 years from date of the a specification reaching Recommendation Status W3C Process) fixed. 4-R16-Copyright Notice and License Metadata A conforming specification MUST specify the structure and semantics of fields that explicitly reference, or otherwise include, a software license agreement or notice, and declare who holds the copyright for the widget, as well as a model for how this data must be processed by a widget user agent. the English here seems wrong 'and' again seems to be in the wrong place actually the sentence is just too long and complicated. :) Broke it up into two sentences. R17. Visual Rendering Dimensions or any dimensional values implicitly computed by the widget user agent. should we make sure there's a way to let user specified styles override application styles? ... 4-R18-Rationale: ... (e.g., '/ui/clock.svg'). drop , (see earlier) fixed Alternatively, the bootstrap might be a Web page that when combined with the visual rendering dimensions requirement displays at the appropriate size. the bootstrap _process|file|?_ Changed to resource might be a HTML document that when.. 4-R25-Rationale: NOT A RATIONALE!! this doesn't look like something that should be published :( Sorry, that was note to myself. Removed. R33. Cross-Widget Communication (pairing and unparring). unpairing. fixed. R34. Icon API To allow widget to widgets (please check globally) Fixed. Checked. R36. Open Default System Web Browser To allow author to open a URL in the default system web browser. authors (please check this globally) Fixed. Checked. R38. Additional Digital Certificates A conforming specification SHOULD NOT recommend that, aside from including standard root certificates, widget user agent allow end-users to install digital certificates from other trusted sources. Rationale: To allow authors and publisher to sign widgets. the requirement and the rationale don't seem to match. Good point. This was a SHOULD and got changed to a SHOULD NOT... this is now an open issue AFAIK. R40. Automatic Updates what happens if i have 3 instances of a widget? do they all get
FileUpload Editor | Re: File Upload Status ?
All, On behalf of Mozilla, I'd like to take over as editor of the FileUpload spec., which was actually once assigned to me quite some time ago :) Of course, I think that form.getDataAsString(); form serialization is out of scope of this particular specification, but I think other things like Blobs (as per the Google Gears proposal -- maybe a File interface can have a getBlobs on it) are probably in, as well as some other interface proposals by Opera, etc. Security makes or breaks all of this, so I'll start with the restrictions we've put on this as a strawperson. After talking to Jonas, I also think File Download should be in scope, again modulo security which, following a straw person, is a welcome group discussion. I've gotten CVS access from Mike. I'd like till the end of the week (next week) to turn around a a first revision. -- A*
