/irc-logs / w3c / #webapps / 2009-04-03 / end

Options:

# Session Start: Fri Apr 03 00:00:00 2009
# Session Ident: #webapps
# [01:27] * Disconnected
# [01:27] * Attempting to rejoin channel #webapps
# [01:27] * Rejoined channel #webapps
# [01:27] * Topic is 'Web Applications WG (this channel is logged at http://krijnhoetmer.nl/irc-logs/)'
# [01:27] * Set by ArtB on Wed Mar 11 20:47:52
# [02:49] <anne> shepazu: http://lists.w3.org/Archives/Public/ietf-http-wg/2007OctDec/0298.html
# [04:15] * Quits: shepazu (schepers@128.30.52.30) (Client exited)
# [04:15] * Joins: shepazu (schepers@128.30.52.30)
# [04:20] * Quits: shepazu (schepers@128.30.52.30) (Client exited)
# [04:20] * Joins: shepazu (schepers@128.30.52.30)
# [06:37] * Quits: nico (nico@133.27.247.181) (Ping timeout)
# [06:37] * Joins: nico (nico@133.27.247.181)
# [07:28] * Quits: heycam (cam@130.194.73.110) (Quit: bye)
# [07:47] * Joins: arve (arve@95.34.27.22)
# [08:16] * Quits: arve (arve@95.34.27.22) (Quit: Ex-Chat)
# [08:30] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [09:09] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [09:48] * Joins: arve (arve@213.236.208.22)
# [10:19] * Joins: Marcos (Marcos@213.236.208.22)
# [10:22] * Joins: heycam (cam@210.84.21.15)
# [11:32] * Quits: arve (arve@213.236.208.22) (Connection reset by peer)
# [11:33] * Joins: arve (arve@213.236.208.22)
# [12:06] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
# [12:23] * Joins: Lachy (Lachlan@213.236.208.22)
# [13:05] * Joins: ArtB (d0309a43@128.30.52.43)
# [13:20] <ArtB> Marcos, thanks for the quick work moving <update> to Updates spec!
# [13:21] <Marcos> no probs
# [13:21] <ArtB> hmmm, http://dev.w3.org/2006/waf/widgets-updates/ says Oct 8 2008
# [13:21] <Marcos> I'll upload now
# [13:21] <ArtB> cool
# [13:22] <ArtB> since we aren't meeting next week, perhaps I should start a 1-wk CfC to pulish a new WD of Updates spec. WDYT?
# [13:22] <Marcos> done
# [13:23] <Marcos> Let me clean it up a wee bit
# [13:23] <anne> Marcos, if you really need preferences, why not store them in a separate API?
# [13:23] <ArtB> Marcos - I will wait for a heads up. I found one typo:
# [13:23] <anne> Marcos, Widgets will get localStorage by virtue of using HTML+JavaScript
# [13:24] <Marcos> Anne, not following
# [13:24] <ArtB> "public list of any patent disclosures" link has a "chttp://..." i.e. extra "c" that should be removed
# [13:25] <Marcos> Anne, yes, we get localStorage for HTML. But what about SVG?
# [13:26] <Marcos> ArtB: fixed
# [13:26] <Marcos> uploaded
# [13:26] <Marcos> n
# [13:28] <ArtB> ok; I'll send the CfC when you tell me you're ready
# [13:28] <anne> Marcos, it's attached to the global object, not HTML
# [13:29] <Marcos> Anne, all we want is that Storage be available on whatever technology uses widgets. If someone wants to build a Flash widget engine, the Storage interface must be available
# [13:29] <Marcos> Don't care what the global object is, so long as it has storage
# [13:30] <Marcos> (and that some of the values are read only)
# [13:31] <Marcos> and that the values of storage are pre-populated based on the preference elements in the config doc on first run
# [13:32] <anne> If Flash supports Web Storage it should work
# [13:33] <anne> and the Window object
# [13:33] <anne> but I'm not sure why we should care about proprietary technology
# [13:36] <Marcos> Anne, you can't stifle innovation like that. We care about proprietary tech because proprietary is what becomes a web standard. Think XHR, for instance.
# [13:37] <Marcos> Adobe could give Flash to the W3C tomorrow. Or any entity could hand over a technology tomorrow for standardization. The idea is to future proof and not limit how widgets are used.
# [13:37] <Marcos> while keeping new uses of widgets standards compliant
# [13:38] <anne> Flash already has storage capabilities, why would we want to add more
# [13:39] <anne> you seem to insist on that some things should always be the same and some things like format, scripting language, styling language, etc. can be invariant
# [13:39] <anne> but the way you pick this seems arbitrary at best
# [13:40] <Marcos> Kinda true.
# [13:40] <Marcos> Widgets are just a general container format with some guaranteed APIs. That's it.
# [13:40] <Marcos> it says nothing of the content itself.
# [13:41] <Marcos> In the real world, however, you are right to say: "that's dumb, they are only to really be used with the web stack"
# [13:41] <anne> that's pretty pointless because the app is build out of the "content"
# [13:42] <anne> and if the "content" provides better APIs they won't use the ones Widgets "guarantee"
# [13:43] <Marcos> Ya. But in architecture astronaut land it makes sense. If they don't use our APIs, then they ain't a widget user agent.
# [13:43] <Marcos> It's like having a HTML browser with no Window object
# [13:43] <Marcos> Does HTML4.01 define a window object?
# [13:44] <anne> I'm saying that authors will use the APIs from Flash rather than the ones from Widgets if they author Flash Widgets.
# [13:44] <anne> Of course it doesn't. You know that.
# [13:44] <Marcos> Why would they use the ones in Flash if they can use the ones provided by widgets?
# [13:45] <anne> because they're already familiar with how Flash works and Adobe prolly has better documentation
# [13:46] <anne> reinventing storage just because you want it to be the same for all theoretical widget engines is silly
# [13:46] <anne> are you going to reinvent geolocation too?
# [13:46] <Marcos> No, we are not reinventing anything. We are just using it.
# [13:47] <anne> if you expose it separately from localStorage every HTML widget engine will end up with two storage areas for each widget (at least in theory)
# [13:47] <anne> that's just dumb engineering
# [13:47] <Marcos> My Open Widget Flash Player is not build by Adobe, and it only supports the widget storage interface
# [13:48] <Marcos> Anne, no, this is not true. They both use the same Storage interface.
# [13:48] <anne> sure, but diffrent objects
# [13:49] <anne> subsetting Flash seems to go against the idea of that widgets just provide a simple wrapper for what you already know
# [13:49] <Marcos> However, iff it is a widget, the values of Storage are firstly populated by the <preference> element. The widget Storage interface is only slightly different in that it supports read only prefs
# [13:49] <anne> for an architecture astronaut you're not very consistent :)
# [13:49] <Marcos> lol!
# [13:50] <Marcos> I never claimed they did anything for anyone, especially in regards to reusing existing native code for any platform.
# [13:51] <Marcos> Ok, stop using Flash. Talk about SVG now.
# [13:51] <Marcos> do I get Storage with my SVG widget engine?
# [13:51] <anne> yes, under window.localStorage
# [13:52] <anne> you'll get it with any XML markup language rendered in a browsing context
# [13:52] <Marcos> is that defined in the SVG spec? (i.e., that localStorage and Window must be available to a widget implementation that supports SVG?)
# [13:52] <anne> no, it follows from requirements in HTML5 and Web Storage atm
# [13:53] <Marcos> But it needs to be stated explicitly that X is a "browsing context" [HTML5]
# [13:53] <anne> I don't really see how you can still position it as SVG vs HTML though
# [13:53] <anne> they work together
# [13:53] <Marcos> it's not a VS thing
# [13:53] <Marcos> SVG can be standalone right?
# [13:54] <anne> yeah, but HTML5 has some requirements for that too
# [13:54] <Marcos> for that? that = svg?
# [13:55] <Marcos> what about tomorrow's FOOML?
# [13:55] <anne> for loading any kind of document
# [13:55] <Marcos> ok, so long as it is a browsing context?
# [13:56] <anne> it goes a bit further than that
# [13:56] <Marcos> how so?
# [13:57] <anne> see bits on navigation and page loading
# [14:02] <anne> anyway, you need something like it for HTML/SVG widget engines otherwise you have no scripting :)
# [14:04] <Marcos> I see. This only abstracts things further. Basically what you are saying is to do away with the Storage requirement and the XHR requirement and leave it as an implementation detail.
# [14:04] <Marcos> Forget the baseline APIs.
# [14:05] <Marcos> Makes some sense, as we did the same with all supported content types for the same rationale you are giving
# [14:05] <Marcos> more or less
# [14:06] <Marcos> Still, it's gonna be a hard sell. Regardless, we would still want the Storage interface to include our requirements.
# [14:07] <Marcos> Arve: ^^^^
# [14:07] <anne> you can require baseline APIs for HTML widget engines
# [14:07] <anne> if you really think your silly distinction matters :p
# [14:08] <Marcos> It only matters because I want to guarantee XHR and Storage.
# [14:08] <Marcos> no other reason
# [14:08] <Marcos> I see them as critical features.
# [14:09] <anne> it seems to me you can require them just fine, but if you only want ot require them from HTML/SVG widget engines you could do it in a section dedicated to those
# [14:09] <anne> or something like that
# [14:09] <Marcos> But Why can't I require them for Flash?
# [14:11] <anne> makes no sense for Flash, they have their own APIs
# [14:11] <Marcos> But they could add XHR tomorrow
# [14:12] <anne> why would they want two HTTP APIs?
# [14:12] <Marcos> This is what Yahoo! did, they added XHR
# [14:12] <anne> still drinking the Y! koolaid?
# [14:12] <Marcos> Just an example
# [14:12] <anne> could have known it was that
# [14:13] <anne> right...
# [14:14] <arve> I'm fine with ditching XHR
# [14:14] <arve> I'm not fine with ditching an API that provides the widget with its own packaging data
# [14:15] <Marcos> Yeah, that makes sense because it is unique to widgets. What about storage?
# [14:15] <Marcos> Do we dump storage?
# [14:15] <arve> no
# [14:15] <arve> it's required, given that we've decided that the widget can carry declared storage data
# [14:15] <Marcos> why, by the same logic that we dump XHR we should dump Storage?
# [14:15] <arve> because if we can't, we're back to redefining an already functioning API
# [14:16] <arve> there is no requirement that a widget should have network capabilities
# [14:16] <Marcos> We have a requirement that widgets provide some mechanism to perform async network communication
# [14:16] <arve> do we?
# [14:16] <Marcos> we sure do
# [14:16] <arve> can we nuke that?
# [14:16] <Marcos> hehe
# [14:16] <arve> from orbit
# [14:17] <arve> I'm leaning towards making network a <feature>
# [14:17] <Marcos> http://dev.w3.org/2006/waf/widgets-reqs/#asynchronous-http-requests
# [14:17] <arve> if we drop that requirement, it would be a property of the underlying document technologhy
# [14:17] <arve> s/ghy/gy/
# [14:18] <Marcos> From the astronauts perspective, we are crippling widgets
# [14:18] <Marcos> but I can live with that
# [14:19] <anne> you know that architecture astronaut projects are not that successful right?
# [14:20] <Marcos> ya, look at that HTTP crap
# [14:21] <anne> I'm not quite sure there's an anology there
# [14:22] <Marcos> prolly not
# [14:39] <ArtB> Marcos, fyi, TLR asked IETF's SAAG for comment about Widgets Dig Sig http://www.ietf.org/mail-archive/web/saag/current/msg02590.html
# [14:47] <Marcos> Artb, great
# [14:47] <Marcos> Anne, so we will drop XHR, but we still need Storage :)
# [14:51] <Marcos> well, I'm kinda convinced we don't need it... but we need some API to access preferences declared in the config document and Storage fits
# [14:54] <anne> it's still unclear to me why you'd have preferences in config and not just in script
# [14:54] <Marcos> I argued the same thing, talk to Artb :)
# [14:55] <anne> not too interested in debating this
# [14:55] <Marcos> Understood. It's in there now, so we have to live with ti
# [14:55] <Marcos> it
# [14:57] <anne> that's not how it works
# [15:12] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
# [15:15] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: Leaving)
# [15:15] * Joins: Lachy (Lachlan@213.236.208.22)
# [15:19] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: Leaving)
# [15:39] * Joins: Lachy (Lachlan@213.236.208.22)
# [16:08] * Quits: nico (nico@133.27.247.181) (Ping timeout)
# [16:11] * Joins: nico (nico@133.27.247.181)
# [16:18] <Marcos> anne, how does it work then?
# [16:32] <timelE61i> fWiw, i think i agree w/ anne
# [16:50] <Marcos> timelE61i: Anne made a lot of crazy statements, which do you agree with? :)
# [17:01] <anne> Marcos, that something is in a draft does not mean it cannot be taken out again
# [17:01] <anne> Marcos, the draft in fact says that right at the top
# [17:02] <anne> Marcos, crazy?
# [17:02] <Marcos> I'm just messin with ya :)
# [17:02] <Marcos> I'm just saying they are crazy because I know you are right
# [17:03] <anne> I see, guess I'm plenty crazy then :p
# [17:03] <Marcos> (it's a feeble attempt to keep my dignity while making the changes you suggested but at the same time denigrating your status for being correct)
# [17:04] <Marcos> so yeah! you crazy@
# [17:15] * Quits: anne (annevk@83.86.138.148) (Ping timeout)
# [17:19] * Joins: anne (annevk@83.86.138.148)
# [18:01] * Joins: aroben (aroben@71.58.77.15)
# [18:09] * Quits: timelE61i (timeless@80.186.61.136) (Ping timeout)
# [18:41] * Joins: Marcos_ (Marcos@213.236.208.247)
# [18:42] * Quits: Marcos_ (Marcos@213.236.208.247) (Quit: Marcos_)
# [18:43] * Quits: Marcos (Marcos@213.236.208.22) (Ping timeout)
# [19:30] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
# [20:03] <shepazu> anne: all the HTTP Origin Header discussion on ietf-http-wg would be relevant evidence for liaison with IETF, regarding Adobe's comment, would it not?
# [20:17] * Quits: arve (arve@213.236.208.22) (Quit: Ex-Chat)
# [20:17] <anne> that's sort of a side discussion, not directly related to CORS
# [20:18] <anne> the HTTP WG has never given direct feedback on CORS
# [20:34] <shepazu> anne: the message you sent was rather old... Nov 2007, about 1.5 years... should we try again to get some feedback?
# [20:35] <anne> we could I suppose
# [20:35] <anne> mnot said he's raise it with the http wg again though
# [20:36] <anne> so I guess he will
# [20:36] <shepazu> yeah, people get busy and distracted
# [20:36] <shepazu> so, I think it would be appropriate for us to do so, especially if it's changed in that time
# [20:37] <anne> mnot is going to do it already
# [20:38] <anne> it changed, but it got pretty much ignored the first time around...
# [20:38] <shepazu> when did you talk to mnot?
# [20:38] <shepazu> any url?
# [20:38] <anne> private
# [20:39] <anne> one of the rare standards related private emails I get
# [20:39] <shepazu> ok, but he said recently that he'd raise it again?
# [20:40] <shepazu> I think I'll make a public request for review, if you don't mind
# [20:40] <shepazu> that way, it's all in public view
# [20:41] <shepazu> anne: what do you think of Adobe's request to split out CORS into a separate WG?
# [20:41] <shepazu> nobody really commented on that, ArtB... should we do that?
# [20:42] <anne> I think it's a waste of resources
# [20:43] <shepazu> how so?
# [20:43] <anne> because I don't see why it's needed
# [20:43] <anne> the spec is pretty much done
# [20:43] <anne> impls are shipping
# [20:44] <anne> what are we doing to do? over engineer a v2 because we need to do something at those F2F meetings?
# [20:45] <shepazu> dunno, I have no opinion, I'm just trying to assess responses based on feedback for the AC review of the charter
# [20:47] <anne> have fun :)
# [20:47] <shepazu> tlr didn't mind where it happened, Adobe wanted to split it out so more people could get involved... Jonas didn't mind splitting it out (but really just wants more feedback)
# [20:48] <sicking> i want a reason for why splitting it out is going to archive the effects they seek
# [20:49] <shepazu> anne: as editor, you're affected by this... I don't want to hear complaints about how W3C resolved this if the feedback for keeping it in is all indifferent
# [20:49] <sicking> shepazu, a convincing reason
# [20:49] <sicking> but if they have that i'm fine with splitting out security webapps work
# [20:49] <sicking> (though really, security is part of many specs)
# [20:49] <anne> shepazu, I gave you my opinion
# [20:50] <shepazu> sicking: yes, the fact that they have had a chance to review it for 1.5 years and have neglected to do so doesn't seem like splitting it out would change things
# [20:50] <sicking> shepazu, indeed
# [20:50] <sicking> shepazu, unless the reason they haven't is because they don't want to join the group for patent reasons
# [20:50] <sicking> shepazu, which is not a strong argument with me personally
# [20:51] <shepazu> sicking: that seems to be implied, but without more explicit statement, that is too close to FUD
# [20:52] <sicking> shepazu, FUD from their part? Or mine?
# [20:53] <shepazu> their part... there is an indication that splitting out the work would let more entities join in, but they haven't said why... if it's because of patent concerns, they should simply say so
# [20:53] <shepazu> if it's because of other reasons, they should state those
# [20:53] <shepazu> as it stands, there is "fear, uncertainty, and doubt" about the reasons for lack of review or participation
# [20:53] <anne> Having a separate WG for CORS, a specification which is nearly finished, has three implementations, just seems like a lot of overhead. And the only reason that has been given is that we would get better review, by a person who has not given a review himself.
# [20:54] <shepazu> anne: that is that kind of rationale I was looking for from you, thanks
# [20:54] <shepazu> you pretty sure that's Opera's stance, in addition to the editor's?
# [20:55] <shepazu> note that Adobe's concern was:
# [20:55] <shepazu> [[
# [20:55] <shepazu> Among other missing communities, the majority
# [20:55] <shepazu> of implementors and operators of web servers, proxies, firewalls, and
# [20:55] <shepazu> security analysis mechanisms that are concerned with cross-site security
# [20:55] <shepazu> issues are not represented in the working group.
# [20:55] <shepazu> ]]
# [20:56] <shepazu> and:
# [20:56] <shepazu> [[
# [20:56] <shepazu> Similar coordination concerns apply to coordination of the URI reference
# [20:56] <shepazu> mechanism, and the zip-based packaging mechanisms being proposed. The
# [20:56] <shepazu> packaging mechanism and the reference scheme used within it, the
# [20:56] <shepazu> defaulting of MIME types and the mechanisms for identifying content within
# [20:56] <shepazu> a package, the means of cross or intra-packaging issues affect implementors
# [20:56] <shepazu> of email security scanners, proxies, gateways, and other internet
# [20:56] <anne> shepazu, I've no idea whether Opera cares; we haven't spent a single minute discussing this issue internally so far (thank god)
# [20:56] <shepazu> infrastructure that is not well-represented in the working group.
# [20:56] <shepazu> ]]
# [20:57] <anne> that second issue is about Widgets, not CORS
# [20:57] <shepazu> yes
# [20:57] <shepazu> I guess marcos isn't here, the bum
# [20:57] <anne> the first one may be true, but we invited feedback from the HTTP WG which has those communities on their mailing list I assume
# [20:58] <shepazu> but we have plenty of people on record as saying they don't want to split out the widgets work, so the voice is stronger there than on CORS
# [20:59] <shepazu> anne: it may not matter to you what Opera's stance is, but it may matter to other companies (like Adobe)
# [20:59] <anne> I doubt most of the CORS people care enough to debate about this
# [21:01] <shepazu> wow, glibness is such a powerful argument, thanks
# [21:02] <anne> I'm pretty much indifferent as I all I have to do is get chaals to nominate me and change the boilerplate text. The W3C otoh has to find a chair, set up a group site, find a team contact, invite members to join, etc. And all for a draft that will unlikely change much.
# [21:03] <anne> I think the same goes for most other contributors to CORS. Just a different mailing list to select...
# [21:05] * anne looks up glibness
# [21:05] <shepazu> the larger, more interesting question is how to get the web server, proxy, and firewall folks on board, if indeed that's the issue
# [21:06] <anne> I wonder if he's talking about CORS there or about using Origin as XSRF defense
# [21:06] <shepazu> I'm not totally convinced that a new WG would do that, so I don't see strong reason to split it, but is there a strategy to actually engage them, or would simply having a spec be enough to move them forward?
# [21:07] <anne> As far as I can tell they do not really have to move anywhere...
# [21:07] * Joins: Lachy (Lachlan@85.196.122.246)
# [21:07] <shepazu> if the latter is the assumption, then is there evidence from past behavior that they would?
# [21:08] <anne> Again, I don't know where you want to move them.
# [21:08] <shepazu> Larry seems to think they need to be directly involved, are you saying they don't? and if not, why not? (a pointer to an email message would be fine)
# [21:09] <anne> I'm not sure why they need to be involved.
# [21:11] <shepazu> this seems to be the level of involvement Adam Barth anticipates is needed: http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0092.html
# [21:11] <shepazu> (for the Origin header, in general)
# [21:11] <shepazu> I'm not sure it's applicable here
# [21:12] <anne> That's just about authors, as far as I can tell.
# [21:12] <anne> We already had plenty of author feedback that they want something like this.
# [21:13] <shepazu> sure, I agree there
# [21:15] <shepazu> but what is the essence of Larry's argument then? how does this affect web server, proxy, and firewall folks? you seem to imply that this doesn't affect them, but Larry seems to think it does
# [21:15] <shepazu> sicking: any thoughts on that?
# [21:17] <anne> I suppose it is mostly wondering whether firewalls and proxies will filter out the Origin header. But that was a concern mostly with using Origin for XSRF.
# [21:18] <anne> They currently do not filter it out though.
# [21:18] <anne> So I think we'll just have to see, especially since this is getting deployed already anyway.
# [21:18] <shepazu> CORS does rely on the Origin header, right?
# [21:19] <anne> I just said as much...
# [21:19] <shepazu> just getting my facts straight
# [21:21] <shepazu> and as of right now, the only way this would be affected is if firewalls and proxies *actively change* with regards to the Origin header
# [21:21] <shepazu> ok, thanks for the input
# [21:38] * Quits: heycam (cam@210.84.21.15) (Ping timeout)
# [21:43] * ArtB begins to catch up ...
# [21:44] <shepazu> anne: the implementers are Opera, Mozilla, and who else? Safari? Chrome?
# [21:44] <ArtB> shepazu, WAF and the WebApps started AC4CSR nka CORS over 3 years ago
# [21:44] <shepazu> yeah, I know
# [21:44] <ArtB> I think that is sufficient time for detractors to raise formal objections to the work being done in WebApps
# [21:44] * Joins: heycam (cam@210.84.43.129)
# [21:44] <shepazu> one would think so
# [21:45] <shepazu> then again, that was before the Origin header was proposed
# [21:45] <ArtB> Given the Consortium's resource constraints I don't understand the logic in creating a new WG just because 1 of 400 members recommends it
# [21:45] <shepazu> it has changed dramatically in that time (including 3-4 name changes)
# [21:46] <ArtB> We have gone through great efforts and pains to do all of the related work in Public
# [21:46] <ArtB> and as such Adobe can contribute even if they don't join WebApps
# [21:47] <ArtB> changes - true but I don't think that is justification to split the work off
# [21:47] <shepazu> ArtB: I didn't say we were necessarily going to create a WG, but if there are security concerns raised, it behooves us to thoroughly put those concerns to rest to avoid any confusion
# [21:47] <shepazu> so, I'm looking for sound justification not to split it out, to reduce future concerns
# [21:47] <ArtB> We live by the "silence is assent" rule in Web Apps. Given this, there is 100% unanimity that CORS remain in WebApps
# [21:48] <shepazu> I'm not talking about process, I'm talking about due diligence
# [21:48] <ArtB> I don't recall any member of WebApps WG ever saying security isn't important
# [21:48] <shepazu> did you read the whole backscroll, ArtB?
# [21:48] <ArtB> If we have been remiss about not asking the right communities to review, them we can easily correct that, right?
# [21:49] <shepazu> ArtB: I'm writing that liaison email right now
# [21:50] <shepazu> I'm not satisfied with the work simply remaining under WebApps WG, I'm eager that we be above reproach in doing so
# [21:50] <ArtB> that just sounds like grand standing to me Doug
# [21:51] <ArtB> "not satisifed"
# [21:51] <shepazu> whatever
# [21:51] <ArtB> "above reproach"
# [21:53] <shepazu> look, Adobe raised an issue that this has not gotten sufficient security review, and I think it's a good idea to make sure that 1) it has, and 2) we prove it has
# [21:53] <shepazu> sorry if that offends your delicate sensibilities
# [21:53] <ArtB> Please define "sufficient" here
# [21:53] <ArtB> as I said, if we missed a community then we (WG + Team Contacts) have been remiss and we can easily correct that
# [21:53] <ArtB> without creating a new WG!
# [21:54] <shepazu> when did I say we were creating a new WG??
# [21:54] <ArtB> "I'm not satisfied with the work simply remaining under WebApps WG
# [21:55] <ArtB> "
# [21:55] <ArtB> "
# [21:55] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
# [21:55] <ArtB> That sounds like "creating a new WG" to me
# [21:55] <shepazu> let me restate then
# [21:55] <ArtB> so what did you mean by the "not satisfied" stuff?
# [21:56] <anne> shepazu, can't speak for Opera; what is publicy known is Internet Explorer 8, beta versions of Firefox 3.5 and beta versions of Safari 4
# [21:56] <anne> and maybe some version of Chrome too
# [21:56] <shepazu> if we are going to continue moving the work forward in WebApps WG despite some criticism for doing so, we need to make sure that the points of criticism are addressed from within the WebApps WG
# [21:56] <anne> I haven't found documentation for that and cannot test since I do not have Windows
# [21:56] <shepazu> anne: thanks
# [21:57] <ArtB> shepazu, of course; I don't think I have said otherwise and forgive me if I have
# [21:57] <anne> Origin has always been part of the CORS work
# [21:57] <shepazu> no, I didn't say you said otherwise... I must not be communicating well
# [21:57] <anne> it just had different names over the course of three years
# [21:58] <shepazu> anne: it has changed a bit, though, no?
# [21:59] <anne> it was always an origin
# [22:00] <anne> stuff changed, but all the essentials remained the same
# [22:07] * Quits: Hixie (ianh@129.241.93.37) (Quit: restarting irc client to pick up new configuration)
# [22:07] * Joins: Hixie (ianh@129.241.93.37)
# [22:11] <ArtB> shepazu, I need to leave for the day so please feel free to follow-up with e-mail
# [22:11] <shepazu> ok
# [22:13] <ArtB> thanks again to Krijn for making sure all of this is logged !
# [22:13] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
# [22:27] * Joins: Marcos (Marcos@84.215.160.79)
# Session Close: Sat Apr 04 00:00:00 2009

The end :)