On Jan 11, 2010, at 4:17 PM, ext Maciej Stachowiak wrote:
On Jan 11, 2010, at 12:10 PM, Arthur Barstow wrote:
However, I believe that this spec actually is within our charter.
Overall, Section 2 of the charter, Scope, states: The scope of the
Web Applications Working Group covers the
On Jan 12, 2010, at 3:48 AM, Arthur Barstow wrote:
On Jan 11, 2010, at 4:17 PM, ext Maciej Stachowiak wrote:
On Jan 11, 2010, at 12:10 PM, Arthur Barstow wrote:
However, I believe that this spec actually is within our charter.
Overall, Section 2 of the charter, Scope, states: The scope
Hi Robin,
Le 11/01/2010 15:41, Robin Berjon a écrit :
Hi Cyril,
On Jan 7, 2010, at 15:59 , Cyril Concolato wrote:
sorry to put you on the spot, but I don't recall this being discussed by WebApps
I know that a liaison was sent from MPEG to the W3C early may 2009 and that the
WG was informed.
Hi Cyril,
On Jan 12, 2010, at 17:34 , Cyril Concolato wrote:
Le 11/01/2010 15:41, Robin Berjon a écrit :
Ah, do you have a pointer? I searched for MPEG-U in all the public and
member lists yet only this thread shows up.
The liaison was sent by the ISO/IEC/JTC1/SC29 secretariat, and since
On Mon, Jan 11, 2010 at 5:06 PM, Adam Barth w...@adambarth.com wrote:
On Mon, Jan 11, 2010 at 12:40 PM, Tyler Close tyler.cl...@gmail.com wrote:
On Sun, Jan 10, 2010 at 2:25 PM, Adam Barth w...@adambarth.com wrote:
More abstractly, why aren't we worrying about P misbehaving based on
the
On Tue, Jan 12, 2010 at 10:51 AM, Tyler Close tyler.cl...@gmail.com wrote:
It's not feasible to remove all ambient authority. For example, the
client has the authority to send requests from its IP address. So we
draw a line between network connectivity and issued credentials. Proxy
credentials
[Resending from the correct address.]
In the current draft of UMP, the client can opt-in to UMP by choosing
to use the UniformMessaging API, but the server is unable to force
clients to use UMP because the way the server opts into the protocol
is by returning the Access-Control-Allow-Origin
On Jan 12, 2010, at 12:29 PM, Adam Barth wrote:
On Tue, Jan 12, 2010 at 10:51 AM, Tyler Close
tyler.cl...@gmail.com wrote:
It's not feasible to remove all ambient authority. For example, the
client has the authority to send requests from its IP address. So we
draw a line between network
On Tue, Jan 12, 2010 at 12:29 PM, Adam Barth w...@adambarth.com wrote:
On Tue, Jan 12, 2010 at 10:51 AM, Tyler Close tyler.cl...@gmail.com wrote:
It's not feasible to remove all ambient authority. For example, the
client has the authority to send requests from its IP address. So we
draw a line
I believe all three protocols attach the same semantics to the
Access-Control-Allow-Origin: * response header sent in response to a
GET or POST request. Unless you know of a significant difference in
the semantics, breaking compatibility seems unwarranted.
--Tyler
On Tue, Jan 12, 2010 at 12:54
On Tue, Jan 12, 2010 at 2:19 PM, Tyler Close tyler.cl...@gmail.com wrote:
On Tue, Jan 12, 2010 at 12:54 PM, Adam Barth aba...@webkit.org wrote:
In the current draft of UMP, the client can opt-in to UMP by choosing
to use the UniformMessaging API, but the server is unable to force
clients to
On Tue, Jan 12, 2010 at 2:44 PM, Adam Barth w...@adambarth.com wrote:
On Tue, Jan 12, 2010 at 2:19 PM, Tyler Close tyler.cl...@gmail.com wrote:
On Tue, Jan 12, 2010 at 12:54 PM, Adam Barth aba...@webkit.org wrote:
In the current draft of UMP, the client can opt-in to UMP by choosing
to use the
On Tue, Jan 12, 2010 at 2:47 PM, Tyler Close tyler.cl...@gmail.com wrote:
On Tue, Jan 12, 2010 at 2:44 PM, Adam Barth w...@adambarth.com wrote:
Let my phrase my question another way. Suppose the following situation:
1) I'm a server operator and I want to provide a resource to other web sites.
On Tue, Jan 12, 2010 at 1:59 PM, Tyler Close tyler.cl...@gmail.com wrote:
On Tue, Jan 12, 2010 at 12:29 PM, Adam Barth w...@adambarth.com wrote:
On Tue, Jan 12, 2010 at 10:51 AM, Tyler Close tyler.cl...@gmail.com wrote:
It's not feasible to remove all ambient authority. For example, the
client
On Tue, Jan 12, 2010 at 2:57 PM, Adam Barth w...@adambarth.com wrote:
On Tue, Jan 12, 2010 at 2:47 PM, Tyler Close tyler.cl...@gmail.com wrote:
On Tue, Jan 12, 2010 at 2:44 PM, Adam Barth w...@adambarth.com wrote:
Let my phrase my question another way. Suppose the following situation:
1) I'm
This is a Call for Consensus (CfC) to publish the First Public
Working Draft (FPWD) of the Uniform Messaging Policy (UMP) spec,
latest Editor's Draft at:
http://dev.w3.org/2006/waf/UMP/
This CfC satisfies the group's requirement to record the group's
decision to request advancement.
By
Support.
On Tue, Jan 12, 2010 at 3:29 PM, Arthur Barstow art.bars...@nokia.com wrote:
This is a Call for Consensus (CfC) to publish the First Public Working Draft
(FPWD) of the Uniform Messaging Policy (UMP) spec, latest Editor's Draft at:
http://dev.w3.org/2006/waf/UMP/
This CfC satisfies
I support this.
For the record: I have admittedly not been following the recent
discussions, but some of it has worried me a bit. I liked how UMP was
originally a subset of CORS, in that it gave some amount of
compatibility between the two models. In particular the ability for a
UMP client to
Hi Adam, I don't understand this at all. First, as the draft UMP already
says, were it not for the need to be compatible with currently deployed
browser behaviors, UMP would prefer a short header U: anyway, rather than
the unfortunately long Access-Control-Allow-Origin:* in
an incompressible
Support.
On Tue, Jan 12, 2010 at 3:29 PM, Arthur Barstow art.bars...@nokia.comwrote:
This is a Call for Consensus (CfC) to publish the First Public Working
Draft (FPWD) of the Uniform Messaging Policy (UMP) spec, latest Editor's
Draft at:
http://dev.w3.org/2006/waf/UMP/
This CfC
support
On Tue, Jan 12, 2010 at 3:29 PM, Arthur Barstow art.bars...@nokia.com wrote:
This is a Call for Consensus (CfC) to publish the First Public Working Draft
(FPWD) of the Uniform Messaging Policy (UMP) spec, latest Editor's Draft at:
http://dev.w3.org/2006/waf/UMP/
This CfC satisfies
Hi Jonas,
I too like the subset relationship between UMP and CORS and hope to
retain it. AFAIK, the only issue here is whether or not the user-agent
can follow a non-uniform redirect. There are two ways to resolve this:
UMP forbids following or CORS enables following. Is there any chance
of the
UMP supports confidentiality where client and server desire
confidentiality. I am mystified as to why you might think otherwise.
Concern over CSRF does not preclude concern over confidentiality, to
the contrary, it requires it.
--Tyler
On Tue, Jan 12, 2010 at 3:24 PM, Adam Barth
On Tue, Jan 12, 2010 at 4:37 PM, Tyler Close tyler.cl...@gmail.com wrote:
Hi Jonas,
I too like the subset relationship between UMP and CORS and hope to
retain it. AFAIK, the only issue here is whether or not the user-agent
can follow a non-uniform redirect. There are two ways to resolve this:
On Tue, Jan 12, 2010 at 3:04 PM, Adam Barth w...@adambarth.com wrote:
On Tue, Jan 12, 2010 at 1:59 PM, Tyler Close tyler.cl...@gmail.com wrote:
On Tue, Jan 12, 2010 at 12:29 PM, Adam Barth w...@adambarth.com wrote:
On Tue, Jan 12, 2010 at 10:51 AM, Tyler Close tyler.cl...@gmail.com wrote:
It's
For the record, I'd like to make the read atomic, such that you can
never get half a file before a change, and half after. But it likely
depends on what OSs can enforce here.
I think *enforcing* atomicity is difficult across all OSes.
But implementations can get nearly the same effect by
My question, then, is how can a server enjoy the confidentiality
benefits of UMP without paying the security costs of CORS? As
currently specced, a server needs to take all the CORS risks in order
to use UMP. That seems unnecessary.
The page at http://dev.w3.org/2006/waf/UMP/#security
27 matches
Mail list logo
