Re: [Widgets] Widget Gallery RSS like sharing format
On Mar 17, 2009, at 13:24 , Marcos Caceres wrote: Agreed. Thinking forward, how do you recommend we identify version 2.0 of the widget configuration file format (or should we just cross that bridge when we get to it?) ? Personally, I would recommend that we don't :) Version identifiers are largely useless and experience shows that users use them wrong (e.g. a bunch of SVG out there that's labelled as 1.1 is really 1.2, but people just copy-paste the root element). There are strategies to implement versioning of XML vocabularies which don't require having a version identifier. These are generally based on an ignore approach whereby elements and attributes that the processor doesn't know about are silently skipped. That means we can add new features in the next revision and it won't break older UAs. If at some point we make breaking changes, then we just change the namespace. Note that this needs to be defined in v1, so no, I think we have to cross that bridge now. SVG includes this strategy: http://www.w3.org/TR/SVGMobile12/implnote.html#UnsupportedProps It is worth pointing out that porting the same strategy to the configuration document would be simpler. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [Widgets] Widget Gallery RSS like sharing format
2009/3/17 Robin Berjon ro...@berjon.com: On Mar 17, 2009, at 13:24 , Marcos Caceres wrote: Agreed. Thinking forward, how do you recommend we identify version 2.0 of the widget configuration file format (or should we just cross that bridge when we get to it?) ? Personally, I would recommend that we don't :) Version identifiers are largely useless and experience shows that users use them wrong (e.g. a bunch of SVG out there that's labelled as 1.1 is really 1.2, but people just copy-paste the root element). There are strategies to implement versioning of XML vocabularies which don't require having a version identifier. These are generally based on an ignore approach whereby elements and attributes that the processor doesn't know about are silently skipped. That means we can add new features in the next revision and it won't break older UAs. If at some point we make breaking changes, then we just change the namespace. Note that this needs to be defined in v1, so no, I think we have to cross that bridge now. SVG includes this strategy: http://www.w3.org/TR/SVGMobile12/implnote.html#UnsupportedProps It is worth pointing out that porting the same strategy to the configuration document would be simpler. Are you sure changing the namespace is preferable to a version attribute? Seems very drastic, and usually it's best to avoid doing it as it makes all tools that process existing markup redundant. Also, you mention most users just copy-paste the root element - surely you'd still have the problem if you change the namespace? At the moment, I don't think there is any establised right way when versioning xml, but changing the namespace is a bad idea. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/
Re: [Widgets] Widget Gallery RSS like sharing format
On Tue, Mar 17, 2009 at 1:57 PM, Robin Berjon ro...@berjon.com wrote: On Mar 17, 2009, at 13:24 , Marcos Caceres wrote: Agreed. Thinking forward, how do you recommend we identify version 2.0 of the widget configuration file format (or should we just cross that bridge when we get to it?) ? Personally, I would recommend that we don't :) Version identifiers are largely useless and experience shows that users use them wrong (e.g. a bunch of SVG out there that's labelled as 1.1 is really 1.2, but people just copy-paste the root element). Agreed. This is the reason we did not specify a version or platform attribute for widgets to date. There are strategies to implement versioning of XML vocabularies which don't require having a version identifier. These are generally based on an ignore approach whereby elements and attributes that the processor doesn't know about are silently skipped. This is our current model in processing. That means we can add new features in the next revision and it won't break older UAs. If at some point we make breaking changes, then we just change the namespace. Exactly. Note that this needs to be defined in v1, so no, I think we have to cross that bridge now. SVG includes this strategy: http://www.w3.org/TR/SVGMobile12/implnote.html#UnsupportedProps We've crossed it :) It's been there since the beginning. It is worth pointing out that porting the same strategy to the configuration document would be simpler. Agreed -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] Widget Gallery RSS like sharing format
On Wed, Mar 18, 2009 at 9:35 AM, Andrew Welch andrew.j.we...@gmail.com wrote: 2009/3/17 Robin Berjon ro...@berjon.com: On Mar 17, 2009, at 13:24 , Marcos Caceres wrote: Agreed. Thinking forward, how do you recommend we identify version 2.0 of the widget configuration file format (or should we just cross that bridge when we get to it?) ? Personally, I would recommend that we don't :) Version identifiers are largely useless and experience shows that users use them wrong (e.g. a bunch of SVG out there that's labelled as 1.1 is really 1.2, but people just copy-paste the root element). There are strategies to implement versioning of XML vocabularies which don't require having a version identifier. These are generally based on an ignore approach whereby elements and attributes that the processor doesn't know about are silently skipped. That means we can add new features in the next revision and it won't break older UAs. If at some point we make breaking changes, then we just change the namespace. Note that this needs to be defined in v1, so no, I think we have to cross that bridge now. SVG includes this strategy: http://www.w3.org/TR/SVGMobile12/implnote.html#UnsupportedProps It is worth pointing out that porting the same strategy to the configuration document would be simpler. Are you sure changing the namespace is preferable to a version attribute? Seems very drastic, and usually it's best to avoid doing it as it makes all tools that process existing markup redundant. Also, you mention most users just copy-paste the root element - surely you'd still have the problem if you change the namespace? At the moment, I don't think there is any establised right way when versioning xml, but changing the namespace is a bad idea. I agree. Changing the namespace is a bad idea. I didn't get the sense that this is what Robin was suggesting, however. From a quick glance at the SVG link above, I didn't see anything relating to changing the namespace (though it was a super quick glance, so I might have missed it!:)) -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] Widget Gallery RSS like sharing format
On Wed, Mar 18, 2009 at 9:49 AM, Andrew Welch andrew.j.we...@gmail.com wrote: I agree. Changing the namespace is a bad idea. I didn't get the sense that this is what Robin was suggesting, however. I was referring to this part: If at some point we make breaking changes, then we just change the namespace. Oh missed that bit :) -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] Widget Gallery RSS like sharing format
On Wed, Mar 18, 2009 at 1:47 AM, Andrew Welch andrew.j.we...@gmail.com wrote: Personally, I would recommend that we don't :) Version identifiers are largely useless and experience shows that users use them wrong (e.g. a bunch of SVG out there that's labelled as 1.1 is really 1.2, but people just copy-paste the root element). Agreed. This is the reason we did not specify a version or platform attribute for widgets to date. That's the worst reason ever to do anything! If users are having problems because they don't understand what they are copying and pasting, then address that I think that is what we are doing. By not including a version identifier, we remove the temptation to make backwards incompatible changes protected by a version switch. Those are the type of changes that are harmful since they require more complex authoring than much of the web seems to use. / Jonas
Re: [Widgets] Widget Gallery RSS like sharing format
I agree. Changing the namespace is a bad idea. I didn't get the sense that this is what Robin was suggesting, however. I was referring to this part: If at some point we make breaking changes, then we just change the namespace. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/
Re: [Widgets] Widget Gallery RSS like sharing format
Personally, I would recommend that we don't :) Version identifiers are largely useless and experience shows that users use them wrong (e.g. a bunch of SVG out there that's labelled as 1.1 is really 1.2, but people just copy-paste the root element). Agreed. This is the reason we did not specify a version or platform attribute for widgets to date. That's the worst reason ever to do anything! If users are having problems because they don't understand what they are copying and pasting, then address that, but don't design your markup around it! :) -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/
Re: [Widgets] Widget Gallery RSS like sharing format
On 3/18/09 9:52 AM, Jonas Sicking wrote: On Wed, Mar 18, 2009 at 1:47 AM, Andrew Welchandrew.j.we...@gmail.com wrote: Personally, I would recommend that we don't :) Version identifiers are largely useless and experience shows that users use them wrong (e.g. a bunch of SVG out there that's labelled as 1.1 is really 1.2, but people just copy-paste the root element). Agreed. This is the reason we did not specify a version or platform attribute for widgets to date. That's the worst reason ever to do anything! If users are having problems because they don't understand what they are copying and pasting, then address that I think that is what we are doing. By not including a version identifier, we remove the temptation to make backwards incompatible changes protected by a version switch. Those are the type of changes that are harmful since they require more complex authoring than much of the web seems to use. Agreed. Our current model follows Jonas' thinking. We think that our approach is architecturally sound but I'm open to hearing further suggestions. Kind regards, Marcos
Re: [Widgets] Widget Gallery RSS like sharing format
I think that is what we are doing. By not including a version identifier, we remove the temptation to make backwards incompatible changes protected by a version switch. Those are the type of changes that are harmful since they require more complex authoring than much of the web seems to use. Agreed. Our current model follows Jonas' thinking. We think that our approach is architecturally sound but I'm open to hearing further suggestions. It's tricky definitely, and currently I don't think there is an established way to handle xml versioning, but there are few things to consider: - never change the namespace, unless you want every existing consumer of your xml to change too - when multiple versions of the xml exist, you need some way to differentiate them other than checking for the existence of certain elements/attribute If you do use an attribute to identify the intended version of the xml then: - a 1.0 parser can still parse a 2.0 instance, but give a good error message when it encounters an instruction it doesn't understand (so this forward looking behaviour has to be built into the 1.0 parsers). When a user tries parsing a 2.0 instance using a 1.0 parser, they can be told you need a 2.0 parser rather than unknown element nnn. - a 2.0 parser knows all about the 1.0 spec, so can parse both, can switch modes if there are incompatible changes etc This allows you to tweak 1.0 functionality in subsequent versions, rather than having 1.0 instructions set in stone forever (and then having to provide 2.0 alternatives or workarounds etc) - users/developers/IDEs know exactly what they are dealing with. That's how XSLT 2.0 does it, and I think XHTML 2.0, but I notice XSD 1.1 is going down a different route... I guess it's slightly harder here because version currently refers to the widget version, and not the xml version, so you would need to differentiate them somehow. Either way, I think an explicit version is definitely something that you should include (if only in 2.0, with no version implying 1.0). -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/
Re: [cors] Redirects
On Tue, 17 Mar 2009 21:56:52 +0100, Anne van Kesteren ann...@opera.com wrote: On Tue, 17 Mar 2009 21:50:21 +0100, Anne van Kesteren ann...@opera.com wrote: * cross-origin request with preflight, actual request If we want to follow redirects here at all we can only do it for requests that do not require a preflight. Therefore I'm still not quite convinced that we should honor 303 here because the headers might still be dangerous and have not been checked prior to the request. I think doing what the specification suggests here is safest. Alternatively, we could change the specification so that redirects are not followed, but that their contents (and maybe the Location header) are exposed to application authors if the resource sharing check works out ok. That way the details are still revealed but we do not have to get really complicated and perform a preflight request for every redirect that follows an actual request. Thinking about this some more I rather treat redirects as errors. I think that will work better as future extension point. It also is more consistent I think. They are either a point of error or are transparently followed. So that leaves deciding what to do with a 303 on a preflight request. I'm leaning towards simply making it a network error. -- Anne van Kesteren http://annevankesteren.nl/
Re: [Widgets] Widget Gallery RSS like sharing format
On Mar 18, 2009, at 09:35 , Andrew Welch wrote: Are you sure changing the namespace is preferable to a version attribute? Seems very drastic, and usually it's best to avoid doing it as it makes all tools that process existing markup redundant. I didn't say that changing the namespace should be the versioning mechanism, I said If at some point we make breaking changes, then we just change the namespace. That's very different! The idea is that in version 1.1, 1.2, perhaps even 2.0, 3.0 we just add elements and attributes, and when they are not understood they are simply skipped. We only ever get to change the namespace if and only if at some point, in a future version, we realise that we have got everything wrong (perhaps because the usage of widgets has changed radically) and need to start from scratch. I don't see that happening within a reasonable time frame, and if it does we'll have a bunch of other problems to solve anyway. Also, you mention most users just copy-paste the root element - surely you'd still have the problem if you change the namespace? Yes, but presumably if we were brought to be in a situation where we would need to change the namespace, we would be making a whole lot of other changes that would make copy-pasting impossible anyway. In other words, we'd be defining a new language. You describe further applications of a version attribute, notably the ability to give a proper error (you have a v1 processor, this is a v2 document) and the ability for an implementation to switch code paths. For one, errors that the end-user can't do much about should be proscribed as much as possible. If your phone tells you you need a v2 user agent, there's not much that the average user can do. You also don't address the case of a user stating that a document is v1 but using v2 features. That's going to happen a lot, not just because of copy-pasting but simply because people don't know which version added what feature. Do you know which version of HTML added sup, blockquote, listing, tab, font, math, em, or the script attribute on form? At the moment, I don't think there is any establised right way when versioning xml, but changing the namespace is a bad idea. There's no fully established right way, but there's a body of work and experience to guide us. See: http://www.w3.org/2001/tag/issues.html#XMLVersioning-41 for some stuff, or more precisely (if you have the time): http://lists.w3.org/Archives/Public/www-tag/2004Nov/att-0071/versioning-part1 http://lists.w3.org/Archives/Public/www-tag/2004Nov/att-0071/versioning-part2 Seeing as these are fairly long write-ups, you might wish to focus on part 1 (which concerns us) and more specifically on section 7. The approach I'm proposing (and which is also that of the draft) is based on experience with languages that are to be used by web developers and deployed to a large and varied set of distributed clients over which there is very little control (i.e. HTML and SVG, mostly). It can be summed up as: - ignore what you don't know - in a new version, add new features in such a way that ignoring them doesn't break anything - if and only if you need to make a new version that can't be made compatible, then change the namespace -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [Widgets] Widget Gallery RSS like sharing format
Hi Robin, The idea is that in version 1.1, 1.2, perhaps even 2.0, 3.0 we just add elements and attributes, and when they are not understood they are simply skipped. Ok, but you do of course open yourself up to typos not revealing themselves until quite far down the line (after parsing anyway) You describe further applications of a version attribute, notably the ability to give a proper error (you have a v1 processor, this is a v2 document) and the ability for an implementation to switch code paths. For one, errors that the end-user can't do much about should be proscribed as much as possible. If your phone tells you you need a v2 user agent, there's not much that the average user can do. ...but at least you'll know why it's not working, as opposed to it just not working. With explicit versioning, there's potential for the client to update itself. You also don't address the case of a user stating that a document is v1 but using v2 features. That's going to happen a lot, not just because of copy-pasting but simply because people don't know which version added what feature. Do you know which version of HTML added sup, blockquote, listing, tab, font, math, em, or the script attribute on form? I think of it in reverse - if you want to use feature x, you know need at least version x. Equally, decent editors will tell you when there's a problem. At least with explcit versioning, you know you want feature x from version 2.0, but your device currently only supports 1.0 - you don't have to try it and see - ignore what you don't know - in a new version, add new features in such a way that ignoring them doesn't break anything - if and only if you need to make a new version that can't be made compatible, then change the namespace The two issues I see are: - ignoring things you don't know means you discover problems like simple typos late in the day, I thought the web was moving towards stricter processes? :) - how do you know which schema to validate the xml with? Given a lump of xml that looks like a widget config, how would you decide which version of the schema to use to validate it with? Or would you not validate it, and just let it fail during processing? I'm still not totally convinced either way, but I do see the benefits of explicit versioning, and not really any drawbacks... -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/
[widgets] options on features
It might be good to add an options element on the feature element to allow options to be set for features using name-value pairs. For example: feature name=http://clothing.com/api; option name=fancy value=pants/ option name=color value=green/ /feature Thoughts? comments? Kind regards, Marcos
Re: [widgets] options on features
On Wed, Mar 18, 2009 at 3:38 PM, Marcos Caceres marc...@opera.com wrote: It might be good to add an options element on the feature element to allow options to be set for features using name-value pairs. For example: feature name=http://clothing.com/api; option name=fancy value=pants/ option name=color value=green/ /feature Thoughts? comments? (displaying multiple personalities here...) The above could also be achieved by using query strings feature name=http://clothing.com/api?pants=fancyamp;color=green/ Or another way: feature name=http://clothing.com/api/pants/facy/green/ But I think using an option element is easier to work with... -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] Widget Gallery RSS like sharing format
Hi Andrew, On Mar 18, 2009, at 13:34 , Andrew Welch wrote: The idea is that in version 1.1, 1.2, perhaps even 2.0, 3.0 we just add elements and attributes, and when they are not understood they are simply skipped. Ok, but you do of course open yourself up to typos not revealing themselves until quite far down the line (after parsing anyway) Which is just a fact of life in HTML, SVG, etc. If you want to check your code, use a validator. It's not the UA's job to validate, the UA's job is for end-users, it's not a development tool (especially not a mobile UA). For one, errors that the end-user can't do much about should be proscribed as much as possible. If your phone tells you you need a v2 user agent, there's not much that the average user can do. ...but at least you'll know why it's not working, as opposed to it just not working. With explicit versioning, there's potential for the client to update itself. You're thinking about the developer here. The developer has oodles of tools available to figure out why something is not working. For the end-user, with must-ignore rules the widget will work (or at least its configuration will), there just might not be all the advertised bells- and-whistles. Where is comes to the client updating itself, it certainly won't be because it sees a widget configuration file with a new version number. That just doesn't happen (and is potentially covered by an Apple patent). You also don't address the case of a user stating that a document is v1 but using v2 features. That's going to happen a lot, not just because of copy-pasting but simply because people don't know which version added what feature. Do you know which version of HTML added sup, blockquote, listing, tab, font, math, em, or the script attribute on form? I think of it in reverse - if you want to use feature x, you know need at least version x. But how do you know that? Are you supposed to keep it all in your head? Without looking it up, can you tell me which minimal HTML version needs to be supported by a browser for each of the HTML elements I list above? I know I can't, and frankly I think I'd be hard- pressed to find a list of five people who can. Equally, decent editors will tell you when there's a problem. I have a decent editor and it's not telling me anything. Seriously though, the sort of editor you're thinking of is an IDE, and a large proportion of web developers hate those with rare intensity — it's not a solution except for Java programmers, who are hardly the core constituency we're addressing here. At least with explcit versioning, you know you want feature x from version 2.0, but your device currently only supports 1.0 - you don't have to try it and see That's an unrealistic situation. Implementations don't ship at version boundaries. There will always be implementations that support part of 2.0, and maybe all of them will support just some useful bits of 2.0 that you then know you can use. You've just reminded me of another downside of version-flagging: implementers lie. They might not do it on purpose, but they do do it. And frankly they have a point: if an implementer supports a useful subset of v2, is he supposed to just report supporting v1 until he's finished? What if he supports everything in v2 except one feature? Do you think that a specification will be enough to scare them into not declaring support for v2? Do you have the money to hire Causa Nostra dispatchers to scare them into submission? The fact of the matter is that you *always* have to try and see (or reuse the analysis of someone who has tried and seen for you). This is one of the primary issues with creating XML vocabularies: it gives one the impression that just by adding an element or attribute some functionality will magically appear. That's not unlike thinking that increasing the speedometer's range on a car will make it faster. Adding a version attribute will not make compatibility issues disappear, will not help developers deploy interoperable content, will not help end users figure out what's going on. The two issues I see are: - ignoring things you don't know means you discover problems like simple typos late in the day, I thought the web was moving towards stricter processes? :) We tried moving to stricter processes, it didn't work. The current move is in defining fallback and error behaviour (or which versioning is one aspect) so that interoperable content is easier to produce. - how do you know which schema to validate the xml with? Given a lump of xml that looks like a widget config, how would you decide which version of the schema to use to validate it with? Or would you not validate it, and just let it fail during processing? Schema? What schema? We don't need no schemata. If you want to validate, then you use a validator since it's likely a schema won't be able to
Re: [widgets] options on features
On Mar 18, 2009, at 15:38 , Marcos Caceres wrote: It might be good to add an options element on the feature element to allow options to be set for features using name-value pairs. For example: feature name=http://clothing.com/api; option name=fancy value=pants/ option name=color value=green/ /feature Do you have some examples that involve things that aren't pants? -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [widgets] options on features
Marcos Caceres marc...@opera.com writes: It might be good to add an options element on the feature element to allow options to be set for features using name-value pairs. For example: feature name=http://clothing.com/api; option name=fancy value=pants/ option name=fancypants/option Shorter by 1 char, and more extensible: you can use CDATA for the value, and perhaps one day you might allow markup in the value. Max. option name=color value=green/ /feature Thoughts? comments? Kind regards, Marcos
[widget-digsig] zip relative path update
Marcos Regarding the requirement for validity checking zip relative paths in widget signature [1] references, does the following change make sense to you?: Change last paragraph in section 5.1, Use of XML Signature in Widgets to (only last sentence is changed, to two new sentences): Every ds:Reference used within a widget signature MUST have a URI attribute. Every ds:Reference to an item within the widget signature MUST use an IDREF value for the ds:Reference URI attribute, referring to a unique ID within the widget signature [XML-Schema-Datatypes]. Every ds:Reference to a widget file MUST use a URI expressing the zip relative path to the widget file, properly URL encoded [URI]. The zip relative path MUST conform to the requirements expressed in [Widgets Packaging]. Please let me know any comment or suggestion. Thanks for noting this concern. regards, Frederick Frederick Hirsch Nokia [1] http://dev.w3.org/2006/waf/widgets-digsig/ On Mar 17, 2009, at 8:15 AM, ext Marcos Caceres wrote: Hi Frederick, On 3/17/09 1:01 PM, Frederick Hirsch wrote: The latest draft includes the revised text from Thomas. Marcos, are you suggesting we add something more? It sounds like what you are saying here, is that it should be a valid widget file. Isn't that part of PC checking? I'm not sure what it means to check that the paths are as secure as possible. You might want to check the following section of the PC [1] and see if it is usable in dig sigs. Given that the paths in the reference elements MUST be zip-relative-paths, the rules for checking the validity of those paths may apply to the Widgets Dig Sig spec. [1] http://dev.w3.org/2006/waf/widgets/#zip-relative-paths
Splitting out sections from HTML5
I've now split out the Server-sent Events and Storage APIs out of HTML5, and I've removed the text for Web Sockets, which was split out earlier. By popular demand I've also done some tweaks to the styling of these specs. HTML5 http://dev.w3.org/html5/spec/ Server-Sent Events http://dev.w3.org/html5/eventsource/ Web Storage http://dev.w3.org/html5/webstorage/ Web Workers http://dev.w3.org/html5/workers/ Web Sockets http://dev.w3.org/html5/websockets/ http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol It is my understanding that the desire is to publish the Server-Sent Events, Web Storage, Web Workers, and Web Sockets specs through the Web Apps working group, so that is what I put into the status of this document sections. I would like to be able to put more permissive licenses (ideally MIT) on these drafts, rather than the W3C license. The following sections still haven't been split out: URLs I'll remove this section as soon as DanC's draft is published. Content-Type sniffing I'll remove this section once Adam's draft is on a standards track. Timeout API This section is lacking an active editor. Origin I'm unsure what will happen with this section. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[widget-digsig] proposed change to 7.1, common constraints, for algorithms
Mark One issue you raised was that we have MUSTS on algorithms in the processing rules in section 7.1, but allow other algorithms in the algorithm section with MAY. After our previous email exchange, I suggest the following changes to section 7.1 in Widget Signature [1] to address this concern: (1) Change item 3b from The Algorithm attribute of the ds:digestMethod MUST be set to a digest algorithm specified in the Algorithms section of this document. to The Algorithm attribute of the ds:digestMethod MUST comply with the digest algorithm requirements specified in the Algorithms section of this document. (2) Change 5a from The Algorithm attribute of the ds:CanonicalizationMethod element MUST be set to a Canonicalization method specified in the Algorithms section of this document. to The Algorithm attribute of the ds:CanonicalizationMethod element MUST comply with the Canonicalization method algorithm requirements specified in the Algorithms section of this document. (3) Change 5b from The ds:SignatureValue element MUST contain a signature generated using a Signature method specified in the Algorithms section of this document and MUST use a key that is of the length of arecommended key length. to The Signature method algorithm used in the ds:SignatureValue element MUST comply with Signature method algorithm requirements in the Algorithms section of this document. The Signature MUST be produced using a key of the recommended key length Does this change make sense? Do you have any suggestion or comment? Thanks for the careful review of the draft. regards, Frederick Frederick Hirsch Nokia [1] http://dev.w3.org/2006/waf/widgets-digsig/ [mp] While this is better I think it misses the fact that we are strongly recommending the use of certain algorithms. I still like the idea of including authoring (signing) guidelines/recommendations, ie you can sign your widget using any signature algorithm but if you want it to work across all W3C widget user agents use algorithm X. Same sort of thing for digest algorithm and key length. What do you think?
Re: [widget-digsig] zip relative path update
I wonder what the interaction between this and a manifest approach for URI dereferencing would be. I could argue the case both ways, but would be interested in your thoughts. -- Thomas Roessler, W3C t...@w3.org On Mar 18, 2009, at 20:53, Frederick Hirsch frederick.hir...@nokia.com wrote: Marcos Regarding the requirement for validity checking zip relative paths in widget signature [1] references, does the following change make sense to you?: Change last paragraph in section 5.1, Use of XML Signature in Widgets to (only last sentence is changed, to two new sentences): Every ds:Reference used within a widget signature MUST have a URI attribute. Every ds:Reference to an item within the widget signature MUST use an IDREF value for the ds:Reference URI attribute, referring to a unique ID within the widget signature [XML-Schema- Datatypes]. Every ds:Reference to a widget file MUST use a URI expressing the zip relative path to the widget file, properly URL encoded [URI]. The zip relative path MUST conform to the requirements expressed in [Widgets Packaging]. Please let me know any comment or suggestion. Thanks for noting this concern. regards, Frederick Frederick Hirsch Nokia [1] http://dev.w3.org/2006/waf/widgets-digsig/ On Mar 17, 2009, at 8:15 AM, ext Marcos Caceres wrote: Hi Frederick, On 3/17/09 1:01 PM, Frederick Hirsch wrote: The latest draft includes the revised text from Thomas. Marcos, are you suggesting we add something more? It sounds like what you are saying here, is that it should be a valid widget file. Isn't that part of PC checking? I'm not sure what it means to check that the paths are as secure as possible. You might want to check the following section of the PC [1] and see if it is usable in dig sigs. Given that the paths in the reference elements MUST be zip-relative-paths, the rules for checking the validity of those paths may apply to the Widgets Dig Sig spec. [1] http://dev.w3.org/2006/waf/widgets/#zip-relative-paths
[widgets-digsig] Updated 5.1 with revised Reference constraint text
I have updated the Widgets Signature editors draft, section 5.1 (use of xml signature) with revised text for Reference constraints. This is revised from what I proposed on list earlier as I tried to make the two cases clear (and disallow other random external references): I replaced: Every ds:Reference used within a widget signature MUST have a URI attribute. Every ds:Reference to an item within the widget signature MUST use an IDREF value for the ds:Reference URI attribute, referring to a unique ID within the widget signature [XML-Schema-Datatypes]. Every ds:Reference to a widget file MUST use a relative URI expressing the path from the root of the widget resource to the referenced widget file [URI]. with Every ds:Reference used within a widget signature MUST have a URI attribute. Every ds:Reference MUST be one of the following two kinds of reference: Reference to content within the same ds:Signature element Every ds:Reference to an item within the widget signature MUST use an IDREF value for theds:Reference URI attribute, referring to a unique ID within the widget signature [XML-Schema-Datatypes]. Reference to a widget file in the same widget resource The URI attribute of every ds:Reference to a widget file MUST be a URL- encoded [URI] zip relative path that identifies a file inside the widget package. A zip relative path MUST conform to the [ABNF] for zip- rel-path as specified in [Widgets Packaging]. Please let me know any additional comment or corrections. Thanks Marcos for suggestions to this wording. (Also removed Inc from Nokia in title page) regards, Frederick Frederick Hirsch Nokia [1] http://dev.w3.org/2006/waf/widgets-digsig/
[widget-digsig] changed widget signature files processing rule in section 4
I have updated the latest Widget Signature editors draft section 4 (locating and processing digital signatures) to no longer require the first signature to be processed. http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures The language is now (numbering ok in draft): Process the digital signatures in the signatures list in descending order, with distributor signatures first. The decision of which (if any) distributor signatures are to be validated and whether the author signature is validated is out of scope of this specification. This may be determined by the Security Policy used by the user agent. The ordering by widget file name can be used to allow consistent processing and possible optimization. Every signature that is validated MUST be validated according to Signature Validation defined in this specification. Please indicate any comment or correction. The latest draft also changes all usage of widget user agent to user agent. regards, Frederick Frederick Hirsch Nokia On Mar 16, 2009, at 4:46 PM, ext Priestley, Mark, VF-Group wrote: [mp] My view is that whether zero, one or more signatures is processed is up to the widget user agents security policy therefore we don't need to say anything about which signatures (if any) must be processed. The purpose of sorting the distributor signatures into ascending order is to allow some optimisation of signature processing under certain conditions. Maybe good to further clarify - I can try and come up with something if you'd like (and of course if you agree)?
Re: [XHR2] Upload progress events and simple cross-origin requests
On Wed, Mar 18, 2009 at 1:04 PM, Alexey Proskuryakov a...@webkit.org wrote: Per the current XHR2 spec draft, upload progress events are not sent if the cross-origin request didn't do preflight. What is the rationale behind this requirement? I used to think that this was necessary to prevent port scans of internal networks, but that can be done via other mechanisms anyway, as far as I know. 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. Low enough that it's very doubtful authors will ever notice this. / Jonas
Re: Splitting out sections from HTML5
Great stuff Ian! This is something I think a lot of people, me included, is happy to see happening! Of course I'd like to see even more stuff split out (*cough* window *cough*), but I won't whine about it until I have an editor or draft to propose :) / Jonas On Wed, Mar 18, 2009 at 12:55 PM, Ian Hickson i...@hixie.ch wrote: I've now split out the Server-sent Events and Storage APIs out of HTML5, and I've removed the text for Web Sockets, which was split out earlier. By popular demand I've also done some tweaks to the styling of these specs. HTML5 http://dev.w3.org/html5/spec/ Server-Sent Events http://dev.w3.org/html5/eventsource/ Web Storage http://dev.w3.org/html5/webstorage/ Web Workers http://dev.w3.org/html5/workers/ Web Sockets http://dev.w3.org/html5/websockets/ http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol It is my understanding that the desire is to publish the Server-Sent Events, Web Storage, Web Workers, and Web Sockets specs through the Web Apps working group, so that is what I put into the status of this document sections. I would like to be able to put more permissive licenses (ideally MIT) on these drafts, rather than the W3C license. The following sections still haven't been split out: URLs I'll remove this section as soon as DanC's draft is published. Content-Type sniffing I'll remove this section once Adam's draft is on a standards track. Timeout API This section is lacking an active editor. Origin I'm unsure what will happen with this section. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
