On Tue, 22 Dec 2009 02:48:42 +0100, Kenton Varda wrote:
It *is* a problem today with XMLHttpRequest. This is, for example, one
reason why we cannot host arbitrary HTML documents uploaded by users on
google.com -- a rather large inconvenience! If it were feasible, we'd be
arguing for removing t
On Mon, Dec 21, 2009 at 5:35 PM, Adam Barth wrote:
> On Mon, Dec 21, 2009 at 5:17 PM, Kenton Varda wrote:
> > The problem we're getting at is that CORS is being presented as a
> security
> > mechanism, when in fact it does not provide security. Yes, CORS is
> > absolutely easier to use than UM
On Mon, Dec 21, 2009 at 5:35 PM, Adam Barth wrote:
> On Mon, Dec 21, 2009 at 5:17 PM, Kenton Varda wrote:
>> The problem we're getting at is that CORS is being presented as a security
>> mechanism, when in fact it does not provide security. Yes, CORS is
>> absolutely easier to use than UM in som
On Mon, Dec 21, 2009 at 5:31 PM, Ian Hickson wrote:
> The most simple cases are also the most common and are by far the cases I
> care the most about. The more complicated cases are authored by more
> competent authors, and can be more complicated (e.g. they don't have to
> use CORS).
>
It seems
On Mon, Dec 21, 2009 at 5:17 PM, Kenton Varda wrote:
> The problem we're getting at is that CORS is being presented as a security
> mechanism, when in fact it does not provide security. Yes, CORS is
> absolutely easier to use than UM in some cases -- I don't think anyone is
> going to dispute tha
On Mon, 21 Dec 2009, Kenton Varda wrote:
>
> The problem is that the security it provides in those cases simply
> doesn't exist unless you can ensure that no resource on *any* of your
> allowed origins can be tricked into fetching your "protected" resource
> for a third party. In practice this w
You are conflating so many different issues that it's impossible to make an
argument regarding any one of them because you just start talking about a
different issue in which the argument is different.
CORS is a fine way to protect your bandwidth against other sites embedding
your resources, becau
On Mon, 21 Dec 2009, Tyler Close wrote:
> On Mon, Dec 21, 2009 at 2:39 PM, Ian Hickson wrote:
> > On Mon, 21 Dec 2009, Tyler Close wrote:
> >>
> >> No, there is a difference in access-control between the two designs.
> >>
> >> In the two header design:
> >> 1) An XHR GET of the XBL file data by ex
On Mon, Dec 21, 2009 at 2:39 PM, Ian Hickson wrote:
> On Mon, 21 Dec 2009, Tyler Close wrote:
>>
>> No, there is a difference in access-control between the two designs.
>>
>> In the two header design:
>> 1) An XHR GET of the XBL file data by example.org *is* allowed.
>> 2) An import of the XBL da
On Mon, 21 Dec 2009, Tyler Close wrote:
>
> No, there is a difference in access-control between the two designs.
>
> In the two header design:
> 1) An XHR GET of the XBL file data by example.org *is* allowed.
> 2) An import of the XBL data by example.org triggers a rendering error.
That's a bad
On Mon, Dec 21, 2009 at 2:16 PM, Ian Hickson wrote:
> On Mon, 21 Dec 2009, Tyler Close wrote:
>> On Thu, Dec 17, 2009 at 5:49 PM, Ian Hickson wrote:
>> > On Thu, 17 Dec 2009, Tyler Close wrote:
>> >>
>> >> Starting from the X-FRAME-OPTIONS proposal, say the response header
>> >> also applies to a
On Mon, 21 Dec 2009, Tyler Close wrote:
> On Thu, Dec 17, 2009 at 5:49 PM, Ian Hickson wrote:
> > On Thu, 17 Dec 2009, Tyler Close wrote:
> >>
> >> Starting from the X-FRAME-OPTIONS proposal, say the response header
> >> also applies to all embedding that the page renderer does. So it also
> >> co
On Thu, Dec 17, 2009 at 5:49 PM, Ian Hickson wrote:
> On Thu, 17 Dec 2009, Tyler Close wrote:
>>
>> Starting from the X-FRAME-OPTIONS proposal, say the response header
>> also applies to all embedding that the page renderer does. So it also
>> covers , , etc. In addition to the current values, the
On Fri, 18 Dec 2009, Kenton Varda wrote:
> >
> > If you're saying that a caps-based infrastructure would have
> > insoluable problems, then that makes it a non-starter.
>
> No, I think all the problems are solvable, but the time we might spend
> debating them is unbounded.
If the time it takes
On Fri, Dec 18, 2009 at 8:08 AM, Mark S. Miller wrote:
> On Thu, Dec 17, 2009 at 8:43 PM, Kenton Varda wrote:
>
>>
>> That said, I personally don't actually expect that there's any chance of
>> stopping CORS, or even that doing so is necessarily the best way to break
>> the cycle.
>>
>
> Hi Kent
On Thu, Dec 17, 2009 at 8:43 PM, Kenton Varda wrote:
>
> That said, I personally don't actually expect that there's any chance of
> stopping CORS, or even that doing so is necessarily the best way to break
> the cycle.
>
Hi Kenton, if you expect that, then I don't understand what you are
debatin
On Fri, Dec 18, 2009 at 12:04 AM, Ian Hickson wrote:
> On Thu, 17 Dec 2009, Kenton Varda wrote:
> >
> > With the right capability-based infrastructure, the capability-based
> > solution would be trivial too. We don't have this infrastructure.
> > This is a valid concern.
>
> It's not so much tha
On Thu, 17 Dec 2009, Kenton Varda wrote:
>
> With the right capability-based infrastructure, the capability-based
> solution would be trivial too. We don't have this infrastructure.
> This is a valid concern.
It's not so much that we don't have one, so much as nobody is proposing
one... I'd
On Thu, Dec 17, 2009 at 5:49 PM, Ian Hickson wrote:
> On Thu, 17 Dec 2009, Tyler Close wrote:
> > X-FRAME-OPTIONS: *.example.com
> > Access-Control-Allow-Origin: *
>
> Why is this better than:
>
> Access-Control-Allow-Origin: *.example.com
>
> ...?
>
I think Tyler missed on this one. X-FRAME-
On Thu, 17 Dec 2009, Kenton Varda wrote:
> On Thu, Dec 17, 2009 at 12:58 PM, Ian Hickson wrote:
> >
> > With CORS, I can trivially (one line in the .htaccess file for my
> > site) make sure that no sites can use XBL files from my site other
> > than my sites. My sites don't do any per-user trac
On Thu, 17 Dec 2009, Tyler Close wrote:
>
> Starting from the X-FRAME-OPTIONS proposal, say the response header
> also applies to all embedding that the page renderer does. So it also
> covers , , etc. In addition to the current values, the
> header can also list hostname patterns that may embed t
On Thu, 17 Dec 2009, Kenton Varda wrote:
> On Thu, Dec 17, 2009 at 4:41 PM, Ian Hickson wrote:
> >
> > What one liner are your proposing that would solve the problem for
> > XBL, XML data, videos, etc, all at once?
>
> Are we debating about the state of existing infrastructure, or
> theoretica
On Thu, Dec 17, 2009 at 4:41 PM, Ian Hickson wrote:
> On Thu, 17 Dec 2009, Tyler Close wrote:
>> On Thu, Dec 17, 2009 at 3:46 PM, Ian Hickson wrote:
>> > On Thu, 17 Dec 2009, Tyler Close wrote:
>> >> On Thu, Dec 17, 2009 at 9:38 AM, Ian Hickson wrote:
>> >> > One of the big reasons to restrict w
On Thu, Dec 17, 2009 at 4:41 PM, Ian Hickson wrote:
> What one liner are your proposing that would solve the problem for XBL,
> XML data, videos, etc, all at once?
>
Are we debating about the state of existing infrastructure, or theoretically
ideal infrastructure? Honest question. .htaccess is
On Thu, Dec 17, 2009 at 12:58 PM, Ian Hickson wrote:
> With CORS, I can trivially (one line in the .htaccess file for my site)
> make sure that no sites can use XBL files from my site other than my
> sites. My sites don't do any per-user tracking; doing that would involve
> orders of magnitude mo
On Thu, 17 Dec 2009, Tyler Close wrote:
> On Thu, Dec 17, 2009 at 3:46 PM, Ian Hickson wrote:
> > On Thu, 17 Dec 2009, Tyler Close wrote:
> >> On Thu, Dec 17, 2009 at 9:38 AM, Ian Hickson wrote:
> >> > One of the big reasons to restrict which origin can use a
> >> > particular resource is bandwi
On Thu, Dec 17, 2009 at 3:46 PM, Ian Hickson wrote:
> On Thu, 17 Dec 2009, Tyler Close wrote:
>> On Thu, Dec 17, 2009 at 9:38 AM, Ian Hickson wrote:
>> > One of the big reasons to restrict which origin can use a particular
>> > resource is bandwidth management. For example, resources.example.com
On Thu, 17 Dec 2009, Tyler Close wrote:
> On Thu, Dec 17, 2009 at 9:38 AM, Ian Hickson wrote:
> > One of the big reasons to restrict which origin can use a particular
> > resource is bandwidth management. For example, resources.example.com
> > might want to allow *.example.com to use its XBL fil
On Thu, Dec 17, 2009 at 9:38 AM, Ian Hickson wrote:
> One of the big reasons to restrict which origin can
> use a particular resource is bandwidth management. For example,
> resources.example.com might want to allow *.example.com to use its XBL
> files, but not allow anyone else to directly use th
On Thu, 17 Dec 2009, Kenton Varda wrote:
>
> It seems more useful to attribute resource usage to the user rather than
> to the sites the user uses to access those resources. In my example, I
> might want to limit Alice to, say, 1GB data transfer per month, but I
> don't see why I would care if
On Thu, Dec 17, 2009 at 10:08 AM, Maciej Stachowiak wrote:
>
> On Dec 17, 2009, at 9:15 AM, Kenton Varda wrote:
>
>
>
> On Thu, Dec 17, 2009 at 2:21 AM, Maciej Stachowiak wrote:
>
>>
>> I'm not saying that Alice should be restricted in who she shares the feed
>> with. Just that Bob's site should
On Thu, Dec 17, 2009 at 10:08 AM, Maciej Stachowiak wrote:
> My goal was merely to argue that adding an origin/cookie check to a
> secret-token-based mechanism adds meaningful defense in depth, compared to
> just using any of the proposed protocols over UM. I believe my argument
> holds. If the se
On Dec 17, 2009, at 9:15 AM, Kenton Varda wrote:
On Thu, Dec 17, 2009 at 2:21 AM, Maciej Stachowiak
wrote:
I'm not saying that Alice should be restricted in who she shares the
feed with. Just that Bob's site should not be able to automatically
grant Charlie's site access to the feed
On Thu, 17 Dec 2009, Kenton Varda wrote:
>
> OK, I'm sure that this has been said before, because it is critical to
> the capability argument:
>
> If Bob can access the data, and Bob can talk to Charlie *in any way at
> all*, then it *is not possible* to prevent Bob from granting access to
> C
On Thu, Dec 17, 2009 at 2:21 AM, Maciej Stachowiak wrote:
>
> On Dec 17, 2009, at 1:42 AM, Kenton Varda wrote:
>
> Somehow I suspect all this has been said many times before...
>
> On Wed, Dec 16, 2009 at 11:45 PM, Maciej Stachowiak wrote:
>
>> CORS would provide at least two benefits, using the
On Wed, 16 Dec 2009, Devdatta wrote:
>
> hmm.. just a XDR GET on the file at hixie.ch which allows access only if
> the request is from damowmow.com ?
It couldn't be XDR -- XDR is a script-based mechanism, whereas XBL can be
invoked before the root element is parsed. But even assuming the XDR
p
On Dec 17, 2009, at 1:42 AM, Kenton Varda wrote:
Somehow I suspect all this has been said many times before...
On Wed, Dec 16, 2009 at 11:45 PM, Maciej Stachowiak
wrote:
CORS would provide at least two benefits, using the exact protocol
you'd use with UM:
1) It lets you know what site i
Somehow I suspect all this has been said many times before...
On Wed, Dec 16, 2009 at 11:45 PM, Maciej Stachowiak wrote:
> CORS would provide at least two benefits, using the exact protocol you'd
> use with UM:
>
> 1) It lets you know what site is sending the request; with UM there is no
> way f
On Dec 16, 2009, at 9:10 PM, Kenton Varda wrote:
Without the benefit of full context (I only started following this
list recently), I'd like cautiously to suggest that the UM solution
to Ian's "challenge" seems awkward because the challenge is itself a
poor design, and UM tends to be more
On Dec 16, 2009, at 11:30 PM, Devdatta wrote:
hmm.. just a XDR GET on the file at hixie.ch which allows access only
if the request is from damowmow.com ?
I am not sure -- is there anything special about XBL bindings which
would result in this not working ?
If I recall correctly, XDR sends an
hmm.. just a XDR GET on the file at hixie.ch which allows access only
if the request is from damowmow.com ?
I am not sure -- is there anything special about XBL bindings which
would result in this not working ?
Cheers
devdatta
2009/12/16 Ian Hickson :
> On Wed, 16 Dec 2009, Devdatta wrote:
>> >
On Wed, 16 Dec 2009, Devdatta wrote:
> >
> > Another example would be an XBL binding file on hixie.ch that is
> > accessible only to pages on damowmow.com. With CORS I can do this with one
> > line in my .htaccess file. I don't see how to do it at all with UM.
>
> Seems to me that these examples c
>
> Another example would be an XBL binding file on hixie.ch that is
> accessible only to pages on damowmow.com. With CORS I can do this with one
> line in my .htaccess file. I don't see how to do it at all with UM.
>
Seems to me that these examples can just as easily be done with IE's
XDomainRequ
On Wed, Dec 16, 2009 at 9:25 PM, Ian Hickson wrote:
> A concrete example of the example I was talking about is Google's Finance
> GData API. There's a fixed URL on A (Google's site) that represents my
> finance information. There's a site B (my portal page) that is hard-coded
> to fetch that data
On Wed, 16 Dec 2009, Kenton Varda wrote:
>
> Without the benefit of full context (I only started following this list
> recently), I'd like cautiously to suggest that the UM solution to Ian's
> "challenge" seems awkward because the challenge is itself a poor design,
> and UM tends to be more diff
Without the benefit of full context (I only started following this list
recently), I'd like cautiously to suggest that the UM solution to Ian's
"challenge" seems awkward because the challenge is itself a poor design, and
UM tends to be more difficult to work with when used to implement designs
that
On Tue, Dec 15, 2009 at 10:12 AM, Tyler Close wrote:
> Just so that everyone knows, IE has changed this policy, so it's not a
> situation where we'll be waiting forever. See:
>
> http://msdn.microsoft.com/en-us/library/bb250473(VS.85).aspx
>
> Adam, were you aware of this policy change?
Nope. I'
On Mon, Dec 14, 2009 at 4:26 PM, Tyler Close wrote:
> On Mon, Dec 14, 2009 at 2:38 PM, Adam Barth wrote:
>> On Mon, Dec 14, 2009 at 2:13 PM, Tyler Close wrote:
>>> For example, the
>>> User Consent Phase and Grant Phase above could be replaced by a single
>>> copy-paste operation by the user.
>>
On Mon, Dec 14, 2009 at 6:14 PM, Jonas Sicking wrote:
> On Mon, Dec 14, 2009 at 4:52 PM, Tyler Close wrote:
>> On Sun, Dec 13, 2009 at 6:15 PM, Maciej Stachowiak wrote:
>>> There seem to be two schools of thought that to some extent inform the
>>> thinking of participants in this discussion:
>>>
On Mon, Dec 14, 2009 at 6:14 PM, Jonas Sicking wrote:
> For what it's worth, I'm not sure that "eliminating" is correct here.
> With UM, I can certainly see people doing things like using a wrapping
> library for all UM requests (very commonly done with XHR today), and
> then letting that library
On Mon, Dec 14, 2009 at 4:52 PM, Tyler Close wrote:
> On Sun, Dec 13, 2009 at 6:15 PM, Maciej Stachowiak wrote:
>> There seem to be two schools of thought that to some extent inform the
>> thinking of participants in this discussion:
>> 1) Try to encourage capability-based mechanisms by not provi
On Sun, Dec 13, 2009 at 6:15 PM, Maciej Stachowiak wrote:
> There seem to be two schools of thought that to some extent inform the
> thinking of participants in this discussion:
> 1) Try to encourage capability-based mechanisms by not providing anything
> that lets you extend the use of origins an
On Mon, Dec 14, 2009 at 3:04 PM, Maciej Stachowiak wrote:
>
> On Dec 14, 2009, at 2:38 PM, Adam Barth wrote:
>
>> On Mon, Dec 14, 2009 at 2:13 PM, Tyler Close
>> wrote:
>>>
>>> For example, the
>>> User Consent Phase and Grant Phase above could be replaced by a single
>>> copy-paste operation by
On Mon, Dec 14, 2009 at 2:38 PM, Adam Barth wrote:
> On Mon, Dec 14, 2009 at 2:13 PM, Tyler Close wrote:
>> For example, the
>> User Consent Phase and Grant Phase above could be replaced by a single
>> copy-paste operation by the user.
>
> Any design that involves storing confidential information
Hi Arthur, I'm happy to help Tyler with #1 and to help with #3. Thanks.
On Mon, Dec 14, 2009 at 3:57 AM, Arthur Barstow wrote:
> Hi All,
>
> Given the feedback on this thread, my proposal on the next steps are:
>
> 1. Mark and/or Tyler prepare a FPWD of UM
>
> 2. Anne proactively drive CORS to LC
On Dec 14, 2009, at 2:38 PM, Adam Barth wrote:
On Mon, Dec 14, 2009 at 2:13 PM, Tyler Close
wrote:
For example, the
User Consent Phase and Grant Phase above could be replaced by a
single
copy-paste operation by the user.
Any design that involves storing confidential information in the
c
On Mon, Dec 14, 2009 at 2:13 PM, Tyler Close wrote:
> For example, the
> User Consent Phase and Grant Phase above could be replaced by a single
> copy-paste operation by the user.
Any design that involves storing confidential information in the
clipboard is insecure because IE lets arbitrary web
On Mon, Dec 14, 2009 at 12:42 PM, Arthur Barstow wrote:
> Thanks Adam and Tyler!
>
> Re #3, assuming a wiki is OK, two options are the new Security wiki created
> a few weeks ago:
>
> http://www.w3.org/Security/wiki/
>
> Or WebApps wiki:
>
> http://www.w3.org/2008/webapps/wiki/
>
> Using the Sec
On Mon, Dec 14, 2009 at 12:29 PM, Devdatta wrote:
>> I also agree with Jonas on these points. What might make the most
>> sense is to let the marketplace decide which model is most useful.
>> The most likely outcome (in my mind) is that they are optimized for
>> different use cases and will each
On Mon, Dec 14, 2009 at 11:35 AM, Maciej Stachowiak wrote:
>
> On Dec 14, 2009, at 10:44 AM, Tyler Close wrote:
>
>> On Mon, Dec 14, 2009 at 10:16 AM, Adam Barth wrote:
>>>
>>> On Mon, Dec 14, 2009 at 5:53 AM, Jonathan Rees
>>> wrote:
The only complaint I know of regarding UM is that i
On Dec 14, 2009, at 1:17 PM, ext Adam Barth wrote:
I'd be happy to help with #3.
3. Before we begin a CfC to publish #1 and #2 above, some
combination of the
active participants in the CORS and UM discussions (Adam, Anne,
Jonas,
Maciej, Hixie, Tyler, Mark, etc.) create a comparison document
>
> I also agree with Jonas on these points. What might make the most
> sense is to let the marketplace decide which model is most useful.
> The most likely outcome (in my mind) is that they are optimized for
> different use cases and will each find their own niche.
>
I am not sure this is the ca
On Mon, Dec 14, 2009 at 1:16 PM, Adam Barth wrote:
> You're really overstating your case to the point where it's ridiculous.
Thanks for the feedback.
Hi Art,
Yes, I'm happy to serve as editor for UM, as indicated by #1 below. I
will also contribute to the discussion needed for the CORS vs UM
comparison document for #3 below.
--Tyler
On Mon, Dec 14, 2009 at 3:57 AM, Arthur Barstow wrote:
> Hi All,
>
> Given the feedback on this thread, my pro
On Dec 14, 2009, at 10:44 AM, Tyler Close wrote:
On Mon, Dec 14, 2009 at 10:16 AM, Adam Barth
wrote:
On Mon, Dec 14, 2009 at 5:53 AM, Jonathan Rees > wrote:
The only complaint I know of regarding UM is that it is so
complicated
to use in practice that it will not be as enabling as CORS
A
On Mon, Dec 14, 2009 at 10:16 AM, Adam Barth wrote:
> On Mon, Dec 14, 2009 at 5:53 AM, Jonathan Rees
> wrote:
>> The only complaint I know of regarding UM is that it is so complicated
>> to use in practice that it will not be as enabling as CORS
>
> Actually, Tyler's UM protocol requires the use
I'd be happy to help with #3.
Adam
On Mon, Dec 14, 2009 at 3:57 AM, Arthur Barstow wrote:
> Hi All,
>
> Given the feedback on this thread, my proposal on the next steps are:
>
> 1. Mark and/or Tyler prepare a FPWD of UM
>
> 2. Anne proactively drive CORS to LCWD
>
> 3. Before we begin a CfC to
On Mon, Dec 14, 2009 at 5:53 AM, Jonathan Rees wrote:
> The only complaint I know of regarding UM is that it is so complicated
> to use in practice that it will not be as enabling as CORS
Actually, Tyler's UM protocol requires the user to confirm message 5
to prevent a CSRF attack. Maciej's CORS
Comments inline
On Sun, Dec 13, 2009 at 9:15 PM, Maciej Stachowiak wrote:
>
> On Dec 13, 2009, at 3:47 PM, Mark S. Miller wrote:
>
> On Sun, Dec 13, 2009 at 3:19 PM, Maciej Stachowiak wrote:
>>
>> The literature you cited seems to mostly be about whether capability
>> systems have various techni
Hi All,
Given the feedback on this thread, my proposal on the next steps are:
1. Mark and/or Tyler prepare a FPWD of UM
2. Anne proactively drive CORS to LCWD
3. Before we begin a CfC to publish #1 and #2 above, some combination
of the active participants in the CORS and UM discussions (Adam
I'm not really sure what we're discussing anymore. Do you have any
new information to add, or are we just going in circles?
On Sun, Dec 13, 2009 at 1:29 PM, Mark S. Miller wrote:
> On Sun, Dec 13, 2009 at 12:26 PM, Adam Barth wrote:
>> On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller
>> wrote:
On Dec 13, 2009, at 3:47 PM, Mark S. Miller wrote:
On Sun, Dec 13, 2009 at 3:19 PM, Maciej Stachowiak
wrote:
The literature you cited seems to mostly be about whether capability
systems have various technical flaws, and whether they can be made
to do various things that ACL-based syste
On Sun, Dec 13, 2009 at 3:19 PM, Maciej Stachowiak wrote:
>
> I enter this subthread with trepidation, because I do not think the Working
> Group is in a position to engage in a literature review on an active
> research topic. However, a few comments below:
>
>
I am not the one who brought up the
I enter this subthread with trepidation, because I do not think the
Working Group is in a position to engage in a literature review on an
active research topic. However, a few comments below:
On Dec 13, 2009, at 1:29 PM, Mark S. Miller wrote:
On Sun, Dec 13, 2009 at 12:26 PM, Adam Barth
On Sun, Dec 13, 2009 at 1:29 PM, Mark S. Miller wrote:
> On Sun, Dec 13, 2009 at 12:26 PM, Adam Barth wrote:
>
>> On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller
>> wrote:
>> > On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth wrote:
>> >> I agree with Jonas. It seems unlikely we'll be able to
>> >
On Sun, Dec 13, 2009 at 12:26 PM, Adam Barth wrote:
> On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller
> wrote:
> > On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth wrote:
> >> I agree with Jonas. It seems unlikely we'll be able to
> >> design-by-commitee around a difference in security philosophy d
On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller wrote:
> On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth wrote:
>> I agree with Jonas. It seems unlikely we'll be able to
>> design-by-commitee around a difference in security philosophy dating
>> back to the 70s.
>
> Hi Adam, the whole point of arguin
On Dec 13, 2009, at 10:14 AM, Mark S. Miller wrote:
On Sat, Dec 12, 2009 at 11:14 PM, Maciej Stachowiak
wrote:
I agree with Jonas and Adam as well. I think both models have their
use cases. A few specific additional thoughts:
- Something like UM seems pretty important, probably essential,
On Sat, Dec 12, 2009 at 11:14 PM, Maciej Stachowiak wrote:
> I agree with Jonas and Adam as well. I think both models have their use
> cases. A few specific additional thoughts:
>
> - Something like UM seems pretty important, probably essential, for running
> guest code if you are relying on orig
On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth wrote:
> On Thu, Dec 10, 2009 at 12:04 PM, Jonas Sicking wrote:
> > On Thu, Dec 10, 2009 at 10:53 AM, Arthur Barstow
> wrote:
> >> Ideally, the group would agree on a single model and this could be
> achieved
> >> by converging CORS + UM, abandoning o
On Dec 12, 2009, at 7:17 PM, Adam Barth wrote:
On Thu, Dec 10, 2009 at 12:04 PM, Jonas Sicking
wrote:
On Thu, Dec 10, 2009 at 10:53 AM, Arthur Barstow > wrote:
Ideally, the group would agree on a single model and this could be
achieved
by converging CORS + UM, abandoning one model in defere
On Thu, Dec 10, 2009 at 12:04 PM, Jonas Sicking wrote:
> On Thu, Dec 10, 2009 at 10:53 AM, Arthur Barstow
> wrote:
>> Ideally, the group would agree on a single model and this could be achieved
>> by converging CORS + UM, abandoning one model in deference to the other,
>> etc.
>>
>> Can we all r
On Thu, Dec 10, 2009 at 10:53 AM, Arthur Barstow wrote:
> CORS and Uniform Messaging People,
>
> We are now just a few weeks away from the February 2006 start of what has
> now become the CORS spec. In those four years, the model has been
> significantly improved, Microsoft deployed XDR, we now ha
On Thu, Dec 10, 2009 at 10:53 AM, Arthur Barstow wrote:
> CORS and Uniform Messaging People,
>
> We are now just a few weeks away from the February 2006 start of what has
> now become the CORS spec. In those four years, the model has been
> significantly improved, Microsoft deployed XDR, we now ha
CORS and Uniform Messaging People,
We are now just a few weeks away from the February 2006 start of what
has now become the CORS spec. In those four years, the model has been
significantly improved, Microsoft deployed XDR, we now have the
Uniform Messaging counter-proposal. Meanwhile, the i
We intend that Uniform Messaging be adopted instead of CORS. We intend
that those APIs that were expected to utilize CORS (SSE, XBL) instead
utilize Uniform Messaging. As for XHR2, we intend to propose a similar
UniformRequest that utilizes Uniform Messaging.
We intend the current proposal, Unifor
Mark, Tyler,
On Nov 23, 2009, at 12:33 PM, ext Tyler Close wrote:
I made some minor edits and formatting improvements to the document
sent out on Friday. The new version is attached. If you read the prior
version, there's no need to review the new one. If you're just getting
started, use the at
87 matches
Mail list logo