Re: [WARP4U] WARP with UPnP
On 2 Dec 2009, at 13:05, Marcin Hanclik wrote: I am sorry for bypassing earlier comments, I want to answer them anyway asap. So here comes short summary. What are we trying to solve? Forgetting the UPnP and related stacks, the issues can be summarized as follows: - pattern for IP addresses in URIs (we have pattern for domains, but nothing for IP addresses) and/or - possibility to exclude local (definition needed: I proposed to leave it out of scope if we cannot agree, but it could be home or corporate network or private LAN etc) - network resource from being controlled with access element. This acts as a kind of (loosely defined) pattern for IP addresses. Keeping things simple, the most compelling use case I can see (aka the one I care about...) is where the developer wants to write a widget that can access resources on a network with no centralised DNS or developer-predictable IP addresses. This is the case for many home networks. As a concrete example, one of my projects here at BBC RD is to write a web API for networked televisions and set-top boxes that fits this use case precisely. We'd like widget developers to be able to access it just as easily as native application developers can, and the current WARP spec precludes this. So it's not just about UPnP. (FWIW, we're seriously considering Robin's suggestion that the BBC appoint me as a representative on the webapps WG, but right now I'm not a member. Nevertheless I can put forward some implementation suggestions if that would be of interest to the group.) S
Re: [WARP4U] WARP with UPnP
On Dec 3, 2009, at 12:12 , Stephen Jolly wrote: Keeping things simple, the most compelling use case I can see (aka the one I care about...) is where the developer wants to write a widget that can access resources on a network with no centralised DNS or developer-predictable IP addresses. This is the case for many home networks. As a concrete example, one of my projects here at BBC RD is to write a web API for networked televisions and set-top boxes that fits this use case precisely. We'd like widget developers to be able to access it just as easily as native application developers can, and the current WARP spec precludes this. That's a use case that is definitely interesting, and I believe that there is interest in the group in supporting it. (FWIW, we're seriously considering Robin's suggestion that the BBC appoint me as a representative on the webapps WG, but right now I'm not a member. Nevertheless I can put forward some implementation suggestions if that would be of interest to the group.) It would be really great if you were to join this group. If you are already following this list, and willing to make implementation proposals, it wouldn't necessarily take more of your time than it already does — probably no more than an extra phone call now and then when we're discussing this topic (of course, if you want to get more involved, that's fine as well!). It would, however, help with the IPR thing. We certainly welcome technical solutions in this area. The scope of WARP 1.0 was decided a while ago and since we need to ship it really shouldn't be extended *but* it would not be difficult to have a separate document that plugs on top of the existing one and that can be published quickly. Right now a lot of the hesitation stems from the fact that we don't really have a clear definition of what local is, so a solution that doesn't have that issue will certainly be good. -- Robin Berjon - http://berjon.com/
Re: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December
On Wed, Dec 2, 2009 at 11:58 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Art, Robin, Marcos, Thanks for your comments. Here is the consolidated answer. Just to clarify: I do not think that we should be so strict about the dates regarding the arrival of the comments. If we were not strict, we would never publish. We are strict because we get consensus on a draft from either 1) the WG or 2) in the case of CR+, the Director and the Chairs. The flexibility is already present for many of the WebApps WG's specifications. Only for typos, simple clarifications, and all non-normative text. Art, being responsible for how this working group functions and adheres to the W3C Process, makes sure of that. You once accused us of being a kindergarten, and now you are asking us to willfully violate the process? I believe all of the comments submitted during the LC#1 comment period (that ended 20-Sept-2009) were addressed. Since you indicate otherwise, please clearly identify any comment submitted during the LC comment period that was _not_ addressed. Yes, as far as I can tell all the comments provided in the LC#1 period were already addressed. It is my oversight to name the comments that arrived later as received within LC#1 period. I have just assumed that all comments - also those received after LC period - should be addressed. Of course all emails will be addressed; we are not monsters. We address all emails that come in and never ignore an email. However, we are under no obligation to include those emails as part of the LC process. As indicated earlier in this mail thread, the comments that in my opinion need technical answers stem from the mail thread [1]. They arrived after LC#1. Than they shall be addressed in the period between LC1 and LC2. But will be part of neither unless they require a substantive change in LC2. Technically the comments in [1] are about the flexibility of expressing the URIs by means of a pattern. [2] from Scott Wilson backs it up, although we seem to agree that regular expression is better name for the syntax. [3] from Stephen Jolly is about local network. [4] from Phil Archer about using POWDER. [5] from Bryan Sullivan about semantics of the special value U+002A ASTERISK (*). Some other comments started in [5] were already addressed. From the comments [1]-[5] I derive that the general use case that people are asking for from WARP is the ability to flexibly (by some pattern / regexp) define the value of @origin attribute that later is to be applied to define some kind of local or private network, either by means of domain names (addressed in the current WARP based on the @subdomains attribute) or by IP addresses (not possible to realize efficiently based on the current WARP). Given the above use case, I think that the special value local could address it and together with @subdomains attribute covers all but one ([5]) from the above comments. In the light of LC#2 it seems that the my comments to CfC could be summarized as: Do the comments that arrived after the LC#1 deadline have to be repeated by their authors to get into LC#2 review (I assume not, but it is unclear to me). Comments should be addressed and we should leave it to the editor and chair to decide which comments become part of the Disposition of Comments. Regardless, all comments will be addressed. Robin has always addressed every comment that has come in. If not, then I assume they will be addressed in the LC#2 and I should not worry. Yes, you can rest easy:) Additionally, I may be (again) wrong, but I assume that LC#2 should start once the group internally is aligned with regard to the already received comments. We have already aligned. Hence this being public call for consensus. You still have not presented any valid reasons to progress LC#1 to LC#2. http://dev.w3.org/2006/waf/widgets-access-upnp/ This draft does not meet my expectations and we will _not_ publish a document that includes a copy of all of the WARP spec. It would be helpful to have a clear definition of at least: the problem statement, use case(s), requirement(s), security considerations, proposed syntax and semantics, UA processing model. I slightly improved this document: added processing model and security considerations. It will be potentially extremely short. The delta spec will come shortly (depending also on further discussion on the topics in this mail thread, maybe it could be addressed during LC#2?) and will contain the diff between WARP and WARP4U. Maybe... I recommend that you formally re-raise the local pattern issues once we publish LC#2 or continue working on your new spec (which Opera supports, btw)... but please, remove all duplicate text and keep is short, as Robin suggested. -- Marcos Caceres http://datadriven.com.au
RE: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December
Hi Marcos, You once accused us of being a kindergarten, and now you are asking us to willfully violate the process? Well :), I do not want to remember those multi-context discussions. We have already aligned. Thanks. Maybe... I recommend that you formally re-raise the local pattern issues once we publish LC#2 or continue working on your new spec (which Opera supports, btw)... but please, remove all duplicate text and keep is short, as Robin suggested. Ok, I will re-raise in LC#2 or discuss how to bring them back a kind of automatically. The delta spec will be short. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Thursday, December 03, 2009 1:23 PM To: Marcin Hanclik Cc: Arthur Barstow; Robin Berjon; public-webapps Subject: Re: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December On Wed, Dec 2, 2009 at 11:58 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Art, Robin, Marcos, Thanks for your comments. Here is the consolidated answer. Just to clarify: I do not think that we should be so strict about the dates regarding the arrival of the comments. If we were not strict, we would never publish. We are strict because we get consensus on a draft from either 1) the WG or 2) in the case of CR+, the Director and the Chairs. The flexibility is already present for many of the WebApps WG's specifications. Only for typos, simple clarifications, and all non-normative text. Art, being responsible for how this working group functions and adheres to the W3C Process, makes sure of that. You once accused us of being a kindergarten, and now you are asking us to willfully violate the process? I believe all of the comments submitted during the LC#1 comment period (that ended 20-Sept-2009) were addressed. Since you indicate otherwise, please clearly identify any comment submitted during the LC comment period that was _not_ addressed. Yes, as far as I can tell all the comments provided in the LC#1 period were already addressed. It is my oversight to name the comments that arrived later as received within LC#1 period. I have just assumed that all comments - also those received after LC period - should be addressed. Of course all emails will be addressed; we are not monsters. We address all emails that come in and never ignore an email. However, we are under no obligation to include those emails as part of the LC process. As indicated earlier in this mail thread, the comments that in my opinion need technical answers stem from the mail thread [1]. They arrived after LC#1. Than they shall be addressed in the period between LC1 and LC2. But will be part of neither unless they require a substantive change in LC2. Technically the comments in [1] are about the flexibility of expressing the URIs by means of a pattern. [2] from Scott Wilson backs it up, although we seem to agree that regular expression is better name for the syntax. [3] from Stephen Jolly is about local network. [4] from Phil Archer about using POWDER. [5] from Bryan Sullivan about semantics of the special value U+002A ASTERISK (*). Some other comments started in [5] were already addressed. From the comments [1]-[5] I derive that the general use case that people are asking for from WARP is the ability to flexibly (by some pattern / regexp) define the value of @origin attribute that later is to be applied to define some kind of local or private network, either by means of domain names (addressed in the current WARP based on the @subdomains attribute) or by IP addresses (not possible to realize efficiently based on the current WARP). Given the above use case, I think that the special value local could address it and together with @subdomains attribute covers all but one ([5]) from the above comments. In the light of LC#2 it seems that the my comments to CfC could be summarized as: Do the comments that arrived after the LC#1 deadline have to be repeated by their authors to get into LC#2 review (I assume not, but it is unclear to me). Comments should be addressed and we should leave it to the editor and chair to decide which comments become part of the Disposition of Comments. Regardless, all comments will be addressed. Robin has always addressed every comment that has come in. If not, then I assume they will be addressed in the LC#2 and I should not worry. Yes, you can rest easy:) Additionally, I may be (again) wrong, but I assume that LC#2 should start once the group internally is aligned with regard to the already received comments. We have already aligned. Hence this being public call for consensus. You still have not presented any valid reasons to progress LC#1 to LC#2.
Re: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December
Marcin Hanclik wrote: Hi Marcos, You once accused us of being a kindergarten, and now you are asking us to willfully violate the process? Well :), I do not want to remember those multi-context discussions. We have already aligned. Thanks. Maybe... I recommend that you formally re-raise the local pattern issues once we publish LC#2 or continue working on your new spec (which Opera supports, btw)... but please, remove all duplicate text and keep is short, as Robin suggested. Ok, I will re-raise in LC#2 or discuss how to bring them back a kind of automatically. The delta spec will be short. Long specs suck The shorter the better; everyone hates reading specs (specially me, unless they have pictures... which I like). However, something tell me we are underestimating the complexity of this whole local service discovery thing and the spec you are proposing will grow into a little beast of it's own :)
Re: [WARP4U] WARP with UPnP
On Thu, 03 Dec 2009 12:12:23 +0100, Stephen Jolly stephen.jo...@rd.bbc.co.uk wrote: Keeping things simple, the most compelling use case I can see (aka the one I care about...) is where the developer wants to write a widget that can access resources on a network with no centralised DNS or developer-predictable IP addresses. This is the case for many home networks. Through Opera Unite, Opera has a considerable interest in the discoverability of local web services (being agnostic with regards to the definition of local, and the actual underlying implementation, whether that is called UPnP, m-DNS, or something entirely different). At Opera, we already have (experimental) running code and DOM interfaces for such local service discovery. This spec is not in conflict with the WARP specification, nor does it have dependencies on it. We would be willing to, given some preparation, provide this as input for a new working item. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Interface published
2009/11/30 Robin Berjon ro...@berjon.com: widget.getItem(name) Revolutionary? Well, if you're in business selling keyboards and RSI relief, maybe. I thought it might save on DOM pollution. I have been playing with a debugger and the global vars passed between the Web runtime and debugger are outrageously bloated. There isn't a standard mapping from XML to JSON, but there have been experiments mapping the Infoset to JSON. Good luck using that here! Loads of PHP developers write something like: ? $s = simplexml_load_file(rawurlencode(config.xml)); echo json_encode($s); ? Though it looks pretty darn ugly. We could expose more things, but no one asked for them. If people ask for them, we can expose them in 1.1. It's not complicated. Well it is complicated when you think you have to wait until all the people upgrade to the next version in order to expose something new. Though, I can't think of a Debian package that relies on the debian/control file for anything during runtime. Please consider my comments as resolved.
[widgets] Draft Minutes for 3 December 2009 Voice Conference
The draft minutes from the 3 December Widgets voice conference are available at the following and copied below: http://www.w3.org/2009/12/03-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 10 December 2009 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 03 Dec 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/1089.html See also: [3]IRC log [3] http://www.w3.org/2009/12/03-wam-irc Attendees Present Art, Arve, Marcos, Marcin, Suresh, Robin, Steven Regrets Chair Art Scribe ArtB Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]the Widget Interface (TWI) spec 4. [8]WARP: CfC to publish LC#2 5. [9]WARP spec: post-LC#1 comment handling 6. [10]URI Scheme spec: LC comment processing 7. [11]View Modes Interface (VMI) spec 8. [12]Updates spec: 9. [13]AOB * [14]Summary of Action Items _ scribe Scribe: ArtB scribe ScribeNick: ArtB Meeting Widgets Voice Conference Date: 3 December 2009 Review and tweak agenda AB: agenda posted on 2 December ( [15]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/10 89.html ). Any change requests? [15] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/1089.html [ None ] Announcements AB: 1) reminder that December 18 is the last day to request a publication for 2009. 2) December 8 is the last day for comments on TWI LC#2. ... any other short announcements? [ None ] the Widget Interface (TWI) spec AB: LC#2 comment period ends Dec 08. The comment tracking (CT) document is ( [16]http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-a pis-20091117/ ). ... The TWI spec has several Editors. Who is going to take the lead on the CT document? ... or share the responsibility? [16] http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- widgets-apis-20091117/ MC: I can maintain it ... would like some help from ArtB ... don't expect too many comments AB: It is theoretically possible for a CR to be published in 2009 but IFF we are able to respond to complete the round-trip with all Commentors by Dec 10 and we could get approval from the Director by the 18th. MC: I would like to try to do this ... we already have the test suite AB: in the best case scenario, on Dec 10 we would be in a position to agree to publish a Candidate of the spec. ... anything else on TWI for today? [ No ] WARP: CfC to publish LC#2 AB: the CfC to publish WARP LC#2 ended 2 December ( [17]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/10 06.html ). There were no objections to that CfC thus this CfC has passed and later today I will submit a publication request for this LC. ... In Marcin's response to this CfC he asked for some clarification on the commenting process ( [18]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/10 98.html ). Let's discuss that now. ... First, let me re-state one of WebApps' mantras: WebApps welcomes and encourages comments for all of its specs at any time. ... naturally, there is some tension between actually completing a spec and reflecting ongoing feedback. Completing a spec can be impossible if the comment deadline isn't fixed. ... on July 9 ( [19]http://www.w3.org/2009/07/09-wam-minutes.html#item06 ) we agreed the WARP spec met the Last Call requirements and the comment period for LC#1 was 7 weeks (more than twice the required 3-weeks). ... There has been no indication the people who participated in that agreement have changed their position. I do not generally support re-visiting Resolutions unless there is overwhelming support for doing so from the people who agreed to a Resolution. ... So, before we move to the next topic re handling post-LC#1 comments, does anyone have any comments? [17] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/1006.html [18] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/1098.html [19] http://www.w3.org/2009/07/09-wam-minutes.html#item06 MC: no comments from Opera AB: anyone else? SC: no comments MH: no comments AB: the CfC included the resolution so need to capture it here ... re the LC#2 comment period end date, I propose Jan 13. Any objections to that? darobin +1 [ No objections ] darobin ACTION: Robin to prepare LC#2 draft for WARP [recorded in
XHR LC
Hi, here's a very generic comment... did the browser makers that are present over here actually try to update their implementations to what XHR specifies? Or are they actually waiting for it to progress? The reason I'm asking is the frustrating level of support for HTTP extension methods; IE8 blocks many methods (forcing developers to fall back to the ActiveX XHR object which *does* support them). Opera is even worse: it silently (!) rewrites method names to GET. Best regards, Julian PS: Firefox/Opera/Chrome are ok.
Re: XHR LC
On Thu, Dec 3, 2009 at 8:13 AM, Julian Reschke julian.resc...@gmx.de wrote: Hi, here's a very generic comment... did the browser makers that are present over here actually try to update their implementations to what XHR specifies? Or are they actually waiting for it to progress? The reason I'm asking is the frustrating level of support for HTTP extension methods; IE8 blocks many methods (forcing developers to fall back to the ActiveX XHR object which *does* support them). Opera is even worse: it silently (!) rewrites method names to GET. Best regards, Julian PS: Firefox/Opera/Chrome are ok. I can only answer for firefox (which might not be relevant then), but no, we're not waiting for the spec to progress further in the W3C process. We just need someone to find the time to through the spec, test if we conform or not, and file bugs/attach patches. A comprehensive test suite would of course be hugely helpful here. Once we get time to do the above I'm certain that we'll be able to contribute tests to such a test suite. / Jonas
Re: Wiki for WebApps' Database, Storage, AppCache and related specs
Thanks Art and Nikunj! Overall, I think it looks great. There are a few things I'd suggest we change for WebStorage: StorageEvents should be mentioned. They're actually one of the greatest strengths of the WebStorage API. Right now, there's a no for atomicity, concurrency-error-free operation, etc. I think this at least deserves a * that explains this is only a problem with browsers that have multiple event loops and there is a solution that's spec'ed but not implemented. Also the text introducing the DataCache APIs introduction is right above the text of the AppCache's introduction. Is there any chance this page could be linked from the various specs? Thanks, J On Wed, Dec 2, 2009 at 3:23 PM, Arthur Barstow art.bars...@nokia.comwrote: A few weeks ago, WebApps' was asked to rationalize and explain how the [various Database-related] APIs fit together. Thanks to some good work by Nikunj, we now have a wiki for this purpose: [[ http://www.w3.org/2008/webapps/wiki/Database The purpose of this document is to provide a short summary regarding the relationships between WebApps' database-related specifications. By relationships in this context, we mean for example, are some specifications complimentary, are some specifications competing, do any of the specs specify overlapping functionality, etc. The summaries are high-level yet they do articulate the key relationships between these specs. Status of this Document: this document is a Work In Progress and the contents do NOT necessarily reflect the consensus of the WebApps Working Group. ... ]] As with all of our wiki documents, all WG members are encouraged to update and maintain this document. -Art Barstow
Re: [WARP4U] WARP with UPnP, was: RE: [widgets] Draft Minutes for 19 November 2009 Voice Conference
+1, duplicating material is a recipe for disaster. regards, Frederick Frederick Hirsch Nokia On Dec 2, 2009, at 8:22 AM, ext Robin Berjon wrote: On Dec 1, 2009, at 22:22 , Marcin Hanclik wrote: Can you please update this to just be a delta? As far as I know W3C specs, delta documents are usually errata or WG Notes. What we have been calling delta specification in WebApps are specifications that add to another. For instance, WARP adds the access element to P+C. It doesn't make some huge cut and paste of P +C just because it modifies. This is as much about sane editing practice and being able to work with a team as it is about clean architecture and separation of concerns. The expectation was that WARP4U would add something to WARP, perhaps attributes, perhaps attribute values, perhaps child elements, and certainly some processing. It's a delta spec. It's not considered to be the next version, it's a different feature set. Therefore I would keep the document as it is. I then have to maintain the strongest objection possible to it being published, even as FPWD. Such copying is inappropriate, and will lead to no end of editorial problems. It fosters confusion and brings no value. -- Robin Berjon - http://berjon.com/
Re: [widgets] test-cases for icons: some possible errors
On Sun, Nov 29, 2009 at 6:03 PM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
Some more potential test case errors and fixes:
==
bl.wgt
✔ Tests the UA's ability to locate an icon in a locale folder and at the
root of the widget. To pass, after processing, the icons list must contain a
pointer to locales/en/icon.jpg, and icon.png, which is at the root of
the widget. The icons list needs to be in the correct order, where
locales/en/icon.jpg must be first and icon.png must be second.
Following Step 9 and using Rule for Finding a File Within a Widget Package
I always get these the other way around, as icon.png is in front of
icon.jpg in the default icons list
mmm. I'm not sure I understand how that happens? Section
9.1.3. Rule for Finding a File Within a Widget Package, step 5 in
the algorithm should be forcing you to find the localized icon first.
Please recheck the spec and I can try to clarify where it is confusing
in regards to how files are found (i.e., always localized content
first, then followed by unlocalized content)
==
bm.wgt
✔ Tests the UA's ability to deal with custom icon declaration in the config
document and matching default icons. To pass, the icons list must contain a
pointer to locales/en/icon.jpg and icon.png, which is at the root of the
widget. The list needs to be in the correct order, where
locales/en/icon.jpg must be first and icon.png must be second.
Following Step 9 and using Rule for Finding a File Within a Widget Package
I always get these the other way around, as icon.png is in front of
icon.jpg in the default icons list
As above.
==
bn.wgt
✔ Tests the UA's ability to deal with custom icon declarations in the
config document and matching default icons. To pass, the icons list must
contain a pointer to icons/pass.png, and icon.png, which is at the root
of the widget. The list needs to be in the correct order, where
icons/pass.png must be first, followed by icon.png.
As {root}/icon.png doesn't exist I think this should instead be
✔ Tests the UA's ability to deal with custom icon declarations in the config
document and matching default icons. To pass, the icons list must contain a
pointer to icons/pass.png, and locales/en/icon.png, which is at the root
of the widget. The list needs to be in the correct order, where
icons/pass.png must be first, followed by locales/en/icon.png.
correct - test was ok, but description was wrong.
==
bp.wgt
✔ Test the UA's ability to load default icons in the correct order. To pass,
the icons list must contain a pointer icon.png followed by a pointer to
en/locales/icon.jpg.
Looks like a typo; I think this should instead be:
✔ Test the UA's ability to load default icons in the correct order. To pass,
the icons list must contain a pointer icon.png followed by a pointer to
locales/en/icon.jpg.
fixed
==
zz.wgt
✔ Tests the ability of the user agent to correctly deal with an icon element
that points to a file that is not present in the widget package. To pass,
the icon list must contain pass.png.
I don't think this is correct - either the package needs to include the file
icon.png and that gets in the list, or the list needs to be empty, as
there is no rule that identifies pass.png is a valid icon when its not
specified as a custom icon.
You are correct. It now says To pass, the icon list must be empty.
--
Marcos Caceres
http://datadriven.com.au
Re: Wiki for WebApps' Database, Storage, AppCache and related specs
On Dec 3, 2009, at 9:19 AM, Jeremy Orlow wrote: Thanks Art and Nikunj! Overall, I think it looks great. There are a few things I'd suggest we change for WebStorage: StorageEvents should be mentioned. They're actually one of the greatest strengths of the WebStorage API. You are right. I planned to include this in the comparison but the Ctrl + E key handler in the Wiki disturbed me enough times that I missed it. Now it has been added. Please take a look and change as you see fit. Right now, there's a no for atomicity, concurrency-error-free operation, etc. I think this at least deserves a * that explains this is only a problem with browsers that have multiple event loops and there is a solution that's spec'ed but not implemented. Fine by me. Also the text introducing the DataCache APIs introduction is right above the text of the AppCache's introduction. Is there a change you are proposing? Is there any chance this page could be linked from the various specs? Thanks, J On Wed, Dec 2, 2009 at 3:23 PM, Arthur Barstow art.bars...@nokia.com wrote: A few weeks ago, WebApps' was asked to rationalize and explain how the [various Database-related] APIs fit together. Thanks to some good work by Nikunj, we now have a wiki for this purpose: [[ http://www.w3.org/2008/webapps/wiki/Database The purpose of this document is to provide a short summary regarding the relationships between WebApps' database-related specifications. By relationships in this context, we mean for example, are some specifications complimentary, are some specifications competing, do any of the specs specify overlapping functionality, etc. The summaries are high-level yet they do articulate the key relationships between these specs. Status of this Document: this document is a Work In Progress and the contents do NOT necessarily reflect the consensus of the WebApps Working Group. ... ]] As with all of our wiki documents, all WG members are encouraged to update and maintain this document. -Art Barstow Nikunj http://o-micron.blogspot.com
RE: [WARP4U] WARP with UPnP, was: RE: [widgets] Draft Minutes for 19 November 2009 Voice Conference
I agree with the principle. I hope this approach could propagate to other specs and WGs, like Geo API etc. It is probably too late for some other specs, though. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] Sent: Thursday, December 03, 2009 6:10 PM To: ext Robin Berjon Cc: Frederick Hirsch; Marcin Hanclik; Barstow Art (Nokia-CIC/Boston); public-webapps Subject: Re: [WARP4U] WARP with UPnP, was: RE: [widgets] Draft Minutes for 19 November 2009 Voice Conference +1, duplicating material is a recipe for disaster. regards, Frederick Frederick Hirsch Nokia On Dec 2, 2009, at 8:22 AM, ext Robin Berjon wrote: On Dec 1, 2009, at 22:22 , Marcin Hanclik wrote: Can you please update this to just be a delta? As far as I know W3C specs, delta documents are usually errata or WG Notes. What we have been calling delta specification in WebApps are specifications that add to another. For instance, WARP adds the access element to P+C. It doesn't make some huge cut and paste of P +C just because it modifies. This is as much about sane editing practice and being able to work with a team as it is about clean architecture and separation of concerns. The expectation was that WARP4U would add something to WARP, perhaps attributes, perhaps attribute values, perhaps child elements, and certainly some processing. It's a delta spec. It's not considered to be the next version, it's a different feature set. Therefore I would keep the document as it is. I then have to maintain the strongest objection possible to it being published, even as FPWD. Such copying is inappropriate, and will lead to no end of editorial problems. It fosters confusion and brings no value. -- Robin Berjon - http://berjon.com/ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: Wiki for WebApps' Database, Storage, AppCache and related specs
On Thu, Dec 3, 2009 at 5:32 PM, Nikunj R. Mehta nikunj.me...@oracle.comwrote: On Dec 3, 2009, at 9:19 AM, Jeremy Orlow wrote: Thanks Art and Nikunj! Overall, I think it looks great. There are a few things I'd suggest we change for WebStorage: StorageEvents should be mentioned. They're actually one of the greatest strengths of the WebStorage API. You are right. I planned to include this in the comparison but the Ctrl + E key handler in the Wiki disturbed me enough times that I missed it. Now it has been added. Please take a look and change as you see fit. Looks fine. Right now, there's a no for atomicity, concurrency-error-free operation, etc. I think this at least deserves a * that explains this is only a problem with browsers that have multiple event loops and there is a solution that's spec'ed but not implemented. Fine by me. I don't have write access to the page, otherwise I'd go ahead and fix it. Can you either give me write access (username jorlow) or do it? Also the text introducing the DataCache APIs introduction is right above the text of the AppCache's introduction. Is there a change you are proposing? I'm pointing out a typo. Is there any chance this page could be linked from the various specs? Thanks, J On Wed, Dec 2, 2009 at 3:23 PM, Arthur Barstow art.bars...@nokia.comwrote: A few weeks ago, WebApps' was asked to rationalize and explain how the [various Database-related] APIs fit together. Thanks to some good work by Nikunj, we now have a wiki for this purpose: [[ http://www.w3.org/2008/webapps/wiki/Database The purpose of this document is to provide a short summary regarding the relationships between WebApps' database-related specifications. By relationships in this context, we mean for example, are some specifications complimentary, are some specifications competing, do any of the specs specify overlapping functionality, etc. The summaries are high-level yet they do articulate the key relationships between these specs. Status of this Document: this document is a Work In Progress and the contents do NOT necessarily reflect the consensus of the WebApps Working Group. ... ]] As with all of our wiki documents, all WG members are encouraged to update and maintain this document. -Art Barstow Nikunj http://o-micron.blogspot.com
Re: Feedback on the Strict-Transport-Security specification (part 1)
[Apologies for latency, I was pretty much buried/OOTO during Nov.] Many thanks to EricLaw for his detailed review, and to Adam for the detailed reply. Below is my build on Adam's responses (part 1). In a separate msg (part 2), I'll respond to the (editorial) items that Adam didn't address. Also, I'll start a separate thread wrt mixed content (aka mixed security context). =JeffH -- Adam replied: On Tue, Oct 27, 2009 at 5:01 PM, Eric Lawrence eric...@exchange.microsoft.com wrote: [mixed content snipped] [Section 2.4.2: Detailed Core Requirements]: 4.UAs need to re-write all insecure UA http URI loads to use the https secure scheme for those web sites for which secure policy is enabled. This requirement is insufficiently specific and does not really explain what rewrite means? Does this mean that the HTML parser will detect any insecure-but-should-be URIs and rewrite them within the markup, such that JavaScript could observe the change in the HREF attribute? This is how our original prototype worked, but I don't think that's how the real implementations should work. Or does it simply mean that upon de-reference the URI is automatically upgraded to HTTPS with no notice to the caller? What I'd recommend here is to treat the HTTP-to-HTTPS rewrite as a simulated 307 redirect, like the one the site is supposed to provide if we actually retrieved the HTTP URL. Actually, we specify a 301 in the spec, section 6.2. The above discussion of course is about (and depends upon) browser implementation details. [Section 2.4.2: Detailed Core Requirements]: Requirements #5 and #6 are problematic because browsers (generally speaking) often don't have rock solid knowledge of where the proper private domain / public suffix transition occurs. I think there might be some confusion about what higher-level means in this context. The intent is that: 1) both example.com and foo.example.com could set policy for bar.foo.example.com. 2) Neither bar.foo.example.com nor foo.example.com could set policy for example.com. 3) bar.foo.example.com cannot set policy for foo.example.com. 4) foo.example.com cannot set policy for qux.example.com. etc. I don't think we need a notion of a public suffix to enforce these rules. agreed. [Section 5.1: Syntax] Are the tokens intended to be interpreted case-sensitively? Yes. I think this is implied but the grammar style Jeff using, but it might be worth noting for us non-ABNF experts. Yes, quoted strings in the ABNF are case-insensitive by default. I can add some notes wrt ABNF details. I'm also thinking we ought to ref draft-ietf-httpbis-p1-messaging-08 rfc5234 rather than rfc2616 wrt ABNF as the former is getting close to last call. [Section 5.1: Syntax] What should be done if the server has multiple Strict-Transport-Security response header fields of different values? My opinion is we should honor the most recently received header, both within a request and between requests. agreed. i.e. in a given response, first occurance wins. across received responses for a given STS server, most recently received header wins. [Section 6.1: HTTP-over-Secure-Transport Request Type] Why must the server include this header on every response? This seems likely to prove prohibitively difficult across, say, Akamai load balancers for images, etc. What happens if the server fails to include the response header on a given response? I think that's a server conformance requirement. The UA conformance requirements are set up so that this doesn't matter too much. As long as you get your entry in the STS cache, you'll be fine. so this is a good point it seems. Given the UA behaivor, the server /can/ be more relaxed. I'll think about how to describe this in that section. Perhaps changing the MUST to a SHOULD, and explaining the ramifications of not returning STS on every response will do it. [Section 6.2] A STS Server must not include the Strict-Transport-Security HTTP Response Header in HTTP responses conveyed over a non-secure transport. Why not? It seems harmless to include if the UA doesn't respect it. Again, this is a server conformance requirement that doesn't affect UAs. It doesn't make sense to send the header here. We might as well prohibit servers from sending it. well, there's security considerations here. If the STS header is conveyed also over insecure transport, then it is possible an attacker can turn off STS policy for a victim site. There's also the desire to avoid DoS attacks where an attacker sets STS for a site that's available only (or for critical pieces) only insecurely (HTTP/TCP). Need to add these to sec cons. [Section 7.1] What if the STS response header is present but contains no tokens? 7.1 suggests that the header alone indicates an STS server. That sounds like a bug. An empty header should be a no-op. agreed. [Section 7.1.1; Design Decision #4] I know there are
Re: Feedback on the Strict-Transport-Security specification (part 2)
This addresses the remaining items in EricLaw's feedback. I have a -06 spec rev opened up and spread around the garage here with various fixes enhancements in progress... =JeffH -- Editorial issues [Section: Abstract] defines a mechanism to enabling Web sites fixed in -06. [Section 1: Introduction] I've never seen a spec use the word annunciate before. Any reason not to prefer announce or display? Ah, well, as one who's been exposed to control systems design, it seemed a natural term to me (and it's used correctly in the instance you cite). I did a little bit of research and it's apparently a term of art in the HCI world. fyi/fwiw. [Section 1: Introduction] or if a server's domain name appears incorrectly. Isn't the problem here typically that the domain name does not appear at all? [Section 1 : Introduction] a HTTP request header field is used to convey site policy to the UA. This specification proposes a HTTP response header, not a request header. oops. fixed in -06. [Section 2.2: Policy Summary] terminates, without user recourse, any secure transport connection attempts upon any and all errors. I'm not convinced that any and all is the right way to go here. Shouldn't this spec call out each certificate and certificate chain error? Otherwise, should I consider the failure in a different protocol level (e.g. gateway or DNS hiccup) as a fatal error? Good question. What is meant here is any and all secure transport errors. I used any and all because e.g. TLS has some error alerts that aren't by default fatal -- i.e. its various cert errors. I'll see about crafting some more explicit language. [Section 4: Terminology] The production of the Effective Request URI omits the protocol scheme. I assume this was inadvertent and that the protocol scheme was meant to be included. By production I'm assuming you mean definition. Yes, the definition in Section 4 for Effective Request URI (ERU) is vague wrt scheme, and also about the details of how the server would go about constructing an ERU in the case where the Request-line header field contains just and abs-path value, and the Host header field contains the authority. I was thinking that we wouldn't need to spec the particulars on constructing an ERU in that case in this spec. (do we need to?) Also, ERU is used only in section 6.2 HTTP Request Type where it's stipulated that the scheme is altered as necessary to be https (which could mean that's where the implementor has the scheme added, depending on how one's implementation works). [Section 5.1: Syntax] The spec should probably specify whether the delta-seconds value expected to be adjusted by the HTTP Age response header, if present. good question -- I'm not sure. If Age is present, but if age_value is small compared to the STS max-age value, then it won't really matter whether the adjustment is made. If age_value and the STS max-age value are of similar magnitude, then it starts to matter, it would seem. I suppose one could have a situation where there's long-lived (weeks? months?) cached response messages whose STS max-age value is less than the cached age, and thus could still being returned to clients even if the origin server (say) wants to turn STS off. In looking through draft-ietf-httpbis-p6-cache-08, it seems that if an origin server is expecting its responses to be served through caches, and it is using a STS max-age value that is of the same or similar order of magnitude as the value it is using for the max-age response cache directive (if any), or the effective expires time calculated from the STS max-age value is near that stipulated by the Expires header (if any). I am not familiar with http cache intricacies, so would appreciate help here from those who are so familiar. [Section 5.1 Syntax] Typo: Strict-Transport-Sec HTTP Response Header fixed in -06. [Section 6.2] I'm not sure why the spec contains the confusing terminology HTTP-over-Secure-Transport whilst simultaneously demanding that various URLs be converted to specifically HTTPS, which would preclude the flexibility allowed by the more awkward terminology? I don't think there is a conflict here, but we could perhaps explain it better. We want to leave the door open to having HTTP mapped onto various secure transports, which at this time would all be signified by the https scheme. E.g. today's browsers typically offer a selection between SSLv2, v3, and TLS. So if one configs one's browser to use only SSLv2 (for whatever reason), then that's what it uses when it attempts a load of a URI having a https scheme. [Section 7.3] If there are any certificate errors in a HTTPS request, you better not have gotten any HTTP header fields back from the server; if you did, you've implemented HTTPS incorrectly. Yep, fixed in -06. [Section 9] expiry time match that for the web site's domain certificate I'm not sure I understand the
Re: Microsoft pre-LCWD feedback on WebSocket API
On Thu, 19 Nov 2009, Adrian Bateman wrote: 1) In the WebSocket constructor, we think it would make sense to limit the optional protocol string to a set of characters that is easier to secure. The UI never surfaces this string and having something that doesn't require processing the full set of strings into UTF-8 shouldn't be a significant restriction. We also think that specifying length constraints would be useful. For example, stipulating the minimum length that conforming implementations must be able to handle. One suggestion was to re-use the same criteria as a valid scheme name as defined in section 3.1 of RFC 3986. I don't see why we'd make it _that_ restricted, but I do agree that it needs to be restricted to at least disallow non-ASCII characters and CRLF, since that would break the handshake. I've updated the spec accordingly. 2) The second comment about the protocol string is editorial. There was quite a lot of confusion about what the protocol string is used for and whether a central registry would be needed for well-known protocol strings. I don't believe this is intended or necessary but this suggests that the language could be clearer. Perhaps an informative section describing the expected use of the protocol string might be included. Done (as an intro section in the protocol spec). 3) The spec uses many terms that the HTML5 spec defines. As far as I can tell, there isn't a definitive list of these. The 2.1 dependencies section notes that many concepts come from HTML5 but not saying which ones seems insufficient for spec moving to Last Call. Most of the people who looked at this spec had never looked at HTML5 before and their feedback was simply that many terms were undefined. I recommend using the WHATWG complete.html version of the spec, which integrates all of HTML5 and both the Web Sockets API and Web Socket protocol specs (and a few others) into a single document: http://www.whatwg.org/specs/web-apps/current-work/complete.html#network The cross-references in that document mean that all the terms defined in HTML5 are clearly referenced. I am hoping that we will be able to make the postprocessor generate appropriate cross-references even in the case of the split specs. 4) In step 2 of the UA steps for the WebSocket() constructor, the spec calls for an exception to be thrown if the user agent chooses to block a well-known port. We think that web developers will often miss this case because it will be hard to test the error case and may be an unusual failure. We propose that the UA signal this condition in the same way as failing to connect to a service which will be much more common and more likely to be handled by web developers. Wouldn't this error be caught very early in development, when the connection just wasn't established? It seems unlikely that non-hostile authors will ever run into this anyway, since they shouldn't be using these ports. 5) It is not clear precisely where the 'fail the Web Socket connection algorithm' is defined. Section 4.3. Closing the connection of the Web Socket protocol spec. 6) The send() method can both throw an exception in the CONNECTING state or return an 'error' flag if in the CLOSED state. APIs that both have return values and also throw exceptions commonly cause coding errors by developers using them. For example, here web developers may fail to deal with the CONNECTING state because on their test service they get an almost immediate connection but once they deploy hitting this case becomes much more common. We recommend choosing between exceptions or return values but not both. The exceptions are thrown for cases where there is a logic error, and the return value (not an error code, just the connection status) is used to handle expected events such as network errors. Using exceptions for network errors is a bad idea because it would mean any use of the API would have to use exception handling. Using a more elaborate return value to report logic errors also would IMHO not really lead to a clearer programming model in this case, since authors wouldn't be looking for those errors either, and would likely just treat it as a connection failure, leading to trying to reconnect, which would then cause increased load on the server -- an especially bad result, since the slow connection is likely to be caused by an overloaded server! Using exceptions here sidesteps this since it is not expected that authors will catch the exception, and thus it will just report an error on the error console (useful for development) and abort the script, without preventing the connection from being established. 7) It is not clear exactly how to implement the bufferedAmount property and be interoperable. Where is the queue of bytes not yet sent? Is this at the application layer, in the networking stack, on the network card, or somewhere else? Any of the
Re: Feedback on WebSocket API, Editor's Draft 13 November 2009.
On Wed, 25 Nov 2009, Sebastian Andersson wrote: I have a few problems with the WebSocket API as it is described. If the client is sending too much data to the server, I don't want it to be disconnected just because some buffer is temporarily full, but that is the required semantics of the API. If my application must send out a lot of data, I don't want my applications to have to guess the networking bandwidth, the browser's buffer quota and the server's capacity and throttle my sending. Let me, the developer, be able to say what I want to do if the server/network can't swallow my messages fast enough. If you have a finite but large amount of data to send, then just send it. The client will buffer it for you and send it as far as possible. This should not cause the connection to close unless you're sending _so_ much data that the client is unable to handle it (but then it probably would have prevented you from allocating the memory in the JS space too). If you have an infinite amount of data to send, just send it so that the bufferedAmount attribute is non-zero but small and not growing. That results in sending data at the highest possible bandwidth with nearly the lowest possible latency. One way is to let Send return false without closing the WebSocket, increase the ready state with an extra state (SendBufferFull?) and an extra event handler. Throw an exception if one tries to send a message when the ready state is SendBufferFull. This would result in most (naive) authors writing code that appears to just randomly drop packets every now and then, which is worse than closing the connection, IMHO. The send function should in that case also send the message later (since it would otherwise be hard to implement this functionality efficiently on most OSes). Not sure what you mean. There should be a described way of sending options to the protocol implementation. Ie how to enable/disable something like Nagle's algorithm for a TCP protocol implementation. Perhaps add an optional third argument to the constructor instead of having to encode options into the url or protocol strings. This kind of thing would make sense for a future version, but I think we should keep the first version relatively simple. Most Web authors aren't going to have any idea whether they should enable or disable Nagle's algorithm, and it seems likely that we'd therefore just end up with half of the Web pages with it enabled and the other half with it disabled, with no correlation to whether they need it or not. The document does not describe what happens when a message is received when no event handler has been associated with onmessage. There are at least three choices for an implementation; A) Throw away the message. B) Enqueue the message until an event handler has been added. C) Don't read from the socket until an event handler has been added. Actually the spec defines it as (A) - the event is fired, but no listeners are there to receive it, so nothing happens. Only the C option it acceptable to me and that allows the application to implement A and B if that is needed. If my application can not process received messages fast enough, I want my application to be able to throttle the amount of messages sent and a common way to do that is to simply stop receiving data (remove the handler in this case) until one is ready to receive more. The client's and server's buffers will fill up and the server application can take action on its end. Since that can always happen, it doesn't burden the server with any extra logic. This isn't an unreasonable idea, though I am uncomfortable with making this dependent on whether an event listener is attached. I think a better solution here would be to provide a feature in a future version that allows the connection to be paused, e.g. socket.pause() and socket.resume(). Although it is partly outside of the scope of the document, I still would like to raise the question about why creating a new protocol and not allowing plain TCP? It would be a security nightmare (e.g. it would mean a hostile Web site, when visited by a corporate user, could connect to an arbitrary HTTP server behind the intranet firewall and read its files). I understand the need to limit the amount of damage a browser can do via malicious javascript, but why not simply use one of the existing limits of the current networking capable web technologies? With Java applets you can connect to TCP ports on the same hostname that served the applet (or is it the same IP?). That allows attacks on shared hosting providers, and prevents cross-site websocket access. With flash, you can connect to any server and any port as long as the application can first download a policy file from the same IP number. Flash's security model has had so many security holes reported on it that I really don't want to try to emulate it. It also requires
Ready for LC on the various drafts I edit
As predicted last week [1], I have replied to the outstanding issues that had been raised on the following specs, and thus am ready to suggest that we take these specs to LC to get wider review: http://dev.w3.org/html5/eventsource/ http://dev.w3.org/html5/webdatabase/ http://dev.w3.org/html5/websockets/ http://dev.w3.org/html5/webstorage/ http://dev.w3.org/html5/workers/ A six month review period should be reasonable, so I would suggest giving a last call deadline of something like July 1st 2010. [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0942.html Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: The most basic File API use case
Peter:
Thanks for sending this and the previous email. I'm sorry about
the slow response; it arrived just as I went away on holiday.
On Mon, Nov 23, 2009 at 6:34 AM, Peter O. Ussuri uss...@threetags.com wrote:
The current File API draft lets a web app to read the file, but there
seems
to be no easy way for a web app to construct an arbitrary binary file and
trigger a SaveAs/download dialog, with the file name suggested by the
app.
I agree with this use case being a logical next step.
As far as Group 0 goes, I agree and think we'll need:
1. A script initiated SaveAs mechanism.
2. Something like BlobBuilder (as you point out).
Next steps can evolve from these.
+1
May I suggest then a specific implementation, in order to move the process
forward a bit. All names/signatures/behaviors below are intended to start
the discussion only, and not as a draft or anything formal. :)
Based on [1] and [2], we can have two interfaces introduced into the File
API specification:
BlobBuilder: based on Google Gears [2].
interface BlobBuilder {
void appendText( in DOMString text, [Optional] in DOMString encoding );
void appendBinaryString( in DOMString text ); /* same as in FileReader
*/
void appendByte( in long val ); /* if val is not in the [0-255] range,
throws an exception */
void appendBlob( in Blob blob );
/* this method can probably be asynchronous, but IMHO this is not
necessary at the Group 0 use case stage */
Blob getBlob();
}
FileWriter:
interface FileWriter {
/* shows the SaveAs dialog, returns the saved File or null if
error/canceled by the user */
/* can be made synchronous (modal) or asynchronous, I'm not sure at the
moment which approach is better */
File saveBlobAsFilePrompt( in Blob blob, in [Optional] DOMString
suggestedFileName ); /* synchronous/modal variant; asynchronous will return
nothing and have events */
}
Later FileWriter can be expanded to cover other use cases.
Thanks,
Peter
[1] http://www.w3.org/TR/2009/WD-FileAPI-20091117/
[2] http://code.google.com/apis/gears/api_blobbuilder.html
I like the BlobBuilder vs. FileWriter split. I'd prefer an HTML
element to something that could pop up a modal dialog, though. Robin
Berjon has just posted [1] a draft that handles that part nicely,
though he combines building and writing into a single interface.
The pieces I'd like to see implemented separately are:
1) Some way of obtaining a FileWriter [likely via an input element
that spawns a dialog box].
2) Some way of building a Blob [your BlobBuilder or what Maciej's [2]
been talking about].
3) A way to write the Blob [no matter where it came from] to the FileWriter.
Eric Uhrhane
[1] http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0113.html
[2] http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0093.html
