RE: Need PDF of MS' input [Was Re: Seeking earlier feedback from MS]

[Sunava Dutta]

Yes, we're working on this as we speak. I'll send out a copy once it's ready.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:public-webapps-
> [EMAIL PROTECTED] On Behalf Of Arthur Barstow
> Sent: Thursday, June 12, 2008 3:46 AM
> To: Sunava Dutta
> Cc: Marc Silbey; public-webapps; public-webapi@w3.org WG (public);
> public-appformats; Eric Lawrence; Chris Wilson; David Ross; Mark
> Shlimovich (SWI); Doug Stamper; Zhenbin Xu; Michael Champion
> Subject: Need PDF of MS' input [Was Re: Seeking earlier feedback from
> MS]
>
>
> Sunava - as requested by several members of the WG, please send a PDF
> version of this document directly to the public-webapps mail list.
>
> -Thanks, Art Barstow
>
>
> On Jun 11, 2008, at 11:36 PM, ext Sunava Dutta wrote:
>
> > Try this link instead: http://code.msdn.microsoft.com/xdsecuritywp
> >
> >
> > ________
> > From: Sunava Dutta
> > Sent: Wednesday, June 11, 2008 8:24 PM
> > To: Sunava Dutta; Arthur Barstow; ext Jonas Sicking; Marc Silbey;
> > [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]; public-webapi@w3.org WG (public); public-
> > [EMAIL PROTECTED]; Eric Lawrence; Chris Wilson; David Ross; Mark
> > Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> > Subject: RE: Seeking earlier feedback from MS [Was: IE Team's
> > Proposal for  Cross Site Requests]
> >
> > Woo hooo, my first mail to the new webapps alias! -:)
> >
> > Thanks for waiting for us to get feedback in from people across
> > MSFT. As promised, here is the whitepaper on client side cross
> > domain security articulating the security principles and challenges
> > (high level and specifics ) of the current CS-XHR draft.
> > I've also addressed the questions members raised in the FAQ.
> >
> > As Jonas and Art mention, in order to provide the opportunity for
> > members to research and usefully discuss the contents and other
> > issues, lets talk about our concerns among other items F2F in the
> > first week of July.
> >
> > https://mail.windows.microsoft.com/OWA/redir.aspx?
> > C=7165bcd1f09048ac9fdcd34d2f9556b1&URL=http%3a%2f%
> > 2fcode.msdn.microsoft.com%2fxdsecuritywp%2fRelease%
> > 2fProjectReleases.aspx%3fReleaseId%3d1157
> >
> > Look forward to hosting the members here in Redmond.
> >
> >
> > 
> > From: [EMAIL PROTECTED] [EMAIL PROTECTED]
> > On Behalf Of Sunava Dutta [EMAIL PROTECTED]
> > Sent: Friday, June 06, 2008 2:54 PM
> > To: Arthur Barstow; ext Jonas Sicking; Marc Silbey
> > Cc: [EMAIL PROTECTED]; public-webapi@w3.org WG (public); public-
> > [EMAIL PROTECTED]; Eric Lawrence; Chris Wilson; David Ross; Mark
> > Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> > Subject: RE: Seeking earlier feedback from MS [Was: IE Team's
> > Proposal for  Cross Site Requests]
> >
> > Art, Jonas,
> > Just a quick update. We've put a lot of effort into the paper and
> > the good news is we're nearly done. It's going through a final peer-
> > review to make sure we've received feedback from experts in the
> > company including our security gurus. (Yes, they do exist at MSFT -
> :))
> >
> > I'll be sending out the paper on Tuesday evening or Wednesday the
> > latest. Thanks for waiting.
> >
> >> -Original Message-
> >> From: Arthur Barstow [mailto:[EMAIL PROTECTED]
> >> Sent: Friday, May 16, 2008 5:06 AM
> >> To: ext Jonas Sicking; Sunava Dutta
> >> Cc: [EMAIL PROTECTED]; public-webapi@w3.org WG (public); public-
> >> [EMAIL PROTECTED]; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris
> >> Wilson;
> >> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> >> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal
> >> for
> >> Cross Site Requests]
> >>
> >> Sunava - I tend to agree with Jonas re the timing of MS' response/
> >> feedback.
> >>
> >> Given the f2f meeting is now about six weeks away, can you commit to
> >> and deliver on an earlier deadline, no later than June 6?
> >>
> >> -Regards, Art Barstow
> >>
> >>
> >> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
> >>
> >>>
> >>> Sunava Dutta wrote:
> >>>>>> This message is not attempting to set forth in detail all the
> >>>>> objections we have had; Sunava will >deliver that in a concise
> >>>>> form.
> >&

RE: Potential bugs identified in XHR LC Test Suite

[Sunava Dutta]

2nd email to the new alias from me!
Dev, test and I ran a few more tests and had some results to share. A few of 
these should probably be clarified in the LC draft or the test cases should 
change.
Details below...

http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm

When Parsing Error happens, IE would still retain responseXML and put error 
information on the object.   Isnt this better than null as there’s more 
relevant information for the web developer?

http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm

The test is expecting us to return NULL in case open() has not been called.  We 
throw an exception in IE.   I’d pre fer if the spec says “MUST return null OR 
an exception” otherwise I fear sites today will be broken.

http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/012.htm
http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/013.htm

This test really doesn’t test XHR here. It seems to be focused on manipulating 
the XML DOM. (I also don’t think Microsoft.XMLDOM supports getElementById for 
an XML document FYI). Also, if I'm barking up the wrong tree here please let me 
know!

http://tc.labs.opera.com/apis/XMLHttpRequest/open/032.htm
What's the purpose of this test case and which part of spec is it testing? It’s 
difficult to understand that.

http://tc.labs.opera.com/apis/XMLHttpRequest/abort/003.htm
The abort() method resets event listeners. I’m looking at the  4/15 spec (on 
W3C site) and was wondering where this is specified?

http://tc.labs.opera.com/apis/XMLHttpRequest/onreadystatechange/004.htm
We don't raise onreadystatechange events from within the onreadystatechange 
event handler as there's danger of recursion. FYI I can't find any guidance 
here in the spec.

http://tc.labs.opera.com/apis/XMLHttpRequest/send/009.htm
http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/017.htm
Another dependency on e.code (As mentioned in the previous round of feedback on 
these tests. We can’t actually run the test until this is removed.

http://tc.labs.opera.com/apis/XMLHttpRequest/send/011.htm
In this test send(1) doesn’t work. The reason being we don’t cast an argument 
to a string.   This is also not defined in the spec.

Thanks!

________
From: Sunava Dutta
Sent: Thursday, June 05, 2008 7:47 PM
To: Web API public; IE8 Core AJAX SWAT Team
Subject: Potential bugs identified in XHR LC Test Suite

Thanks for writing these cases by LC exit. It really makes the process of 
providing feedback prior to CR a lot easier. I ran these (the tests below fail 
on Safari3 ,Firefox 3 and IE8) with my team and had a few questions. If these 
issues can be addressed we can give further feedback and recommendations on the 
results/implementations. (Let me know if I’m wrong on our test analysis!) The 
rest of the tests that fail (without issues in the test itself) are being 
investigated further by my team so expect more over the next few days as we dig 
in.


http://tc.labs.opera.com/apis/XMLHttpRequest/open/033.htm
This test seems to have a bug even though it passes. Line 24 uses 
top.opener.rr. The framework reports FAIL although the test passes.

http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/001.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/004.php
http://tc.labs.opera.com/apis/XMLHttpRequest/getResponseHeader/001.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/getResponseHeader/007.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/013.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/014.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/015.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/016.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/001.htm
http://tc.labs.opera.com/apis/XMLHttpRequest/readyState/002.htm
These tests seem to be failing when the test autorun is used in IE. Running the 
tests individually causes them to pass on IE8. Looks like a bug in the test 
framework.


http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/005.php
This test fails because the network timeout is too short and passes sometimes 
(Unpredictable).

http://tc.labs.opera.com/apis/XMLHttpRequest/send/005.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/send/007.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/send/008.htm

This seems to be a minor test bug. The file we are receiving does not contain 
the string “PASS”, which is necessary for the test to pass.


http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/010.htm
http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/020.htm
The exception object here is not directly supported by IE, causing us to fail 
here. Can the test be tweaked so we can test the XHR compliance here? Thanks!

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/021.htm
The PHP page doesn’t seem to be producing valid content

http

RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

[Sunava Dutta]

Try this link instead: http://code.msdn.microsoft.com/xdsecuritywp



From: Sunava Dutta
Sent: Wednesday, June 11, 2008 8:24 PM
To: Sunava Dutta; Arthur Barstow; ext Jonas Sicking; Marc Silbey; [EMAIL 
PROTECTED]
Cc: [EMAIL PROTECTED]; public-webapi@w3.org WG (public); [EMAIL PROTECTED]; 
Eric Lawrence; Chris Wilson; David Ross; Mark Shlimovich (SWI); Doug Stamper; 
Zhenbin Xu
Subject: RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for  
Cross Site Requests]

Woo hooo, my first mail to the new webapps alias! -:)

Thanks for waiting for us to get feedback in from people across MSFT. As 
promised, here is the whitepaper on client side cross domain security 
articulating the security principles and challenges (high level and specifics ) 
of the current CS-XHR draft.
I've also addressed the questions members raised in the FAQ.

As Jonas and Art mention, in order to provide the opportunity for members to 
research and usefully discuss the contents and other issues, lets talk about 
our concerns among other items F2F in the first week of July.

https://mail.windows.microsoft.com/OWA/redir.aspx?C=7165bcd1f09048ac9fdcd34d2f9556b1&URL=http%3a%2f%2fcode.msdn.microsoft.com%2fxdsecuritywp%2fRelease%2fProjectReleases.aspx%3fReleaseId%3d1157

Look forward to hosting the members here in Redmond.



From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Sunava Dutta [EMAIL 
PROTECTED]
Sent: Friday, June 06, 2008 2:54 PM
To: Arthur Barstow; ext Jonas Sicking; Marc Silbey
Cc: [EMAIL PROTECTED]; public-webapi@w3.org WG (public); [EMAIL PROTECTED]; 
Eric Lawrence; Chris Wilson; David Ross; Mark Shlimovich (SWI); Doug Stamper; 
Zhenbin Xu
Subject: RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for  
Cross Site Requests]

Art, Jonas,
Just a quick update. We've put a lot of effort into the paper and the good news 
is we're nearly done. It's going through a final peer-review to make sure we've 
received feedback from experts in the company including our security gurus. 
(Yes, they do exist at MSFT -:))

I'll be sending out the paper on Tuesday evening or Wednesday the latest. 
Thanks for waiting.

> -Original Message-
> From: Arthur Barstow [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 16, 2008 5:06 AM
> To: ext Jonas Sicking; Sunava Dutta
> Cc: [EMAIL PROTECTED]; public-webapi@w3.org WG (public); public-
> [EMAIL PROTECTED]; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris Wilson;
> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal for
> Cross Site Requests]
>
> Sunava - I tend to agree with Jonas re the timing of MS' response/
> feedback.
>
> Given the f2f meeting is now about six weeks away, can you commit to
> and deliver on an earlier deadline, no later than June 6?
>
> -Regards, Art Barstow
>
>
> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
>
> >
> > Sunava Dutta wrote:
> >>>  >This message is not attempting to set forth in detail all the
> >>> objections we have had; Sunava will >deliver that in a concise form.
> >>>
> >>> Can you give us a ballpark ETA on this?
> > > [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
> > this to
> > > be ready and available to the Web API by mid June in the latest.
> >
> > Wow, this is really bad news that we won't get this feedback until
> > just two weeks before the face to face meeting. Especially given
> > the numerous delays in getting this feedback in the past I am very
> > worried that there will be further delays. Are you absolutely
> > certain that won't happen again?
> >
> > Even just having two weeks in order to discuss this feedback prior
> > to the meeting seems like very short on time.
> >
> > I would really encourage you to consider providing this feedback
> > more promptly. I do not wish to attend a face to face meeting
> > solely to discuss new feedback which we have not had the
> > opportunity to research and cannot usefully discuss. I also hope to
> > cover much more than microsofts feedback during the meeting.

RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

[Sunava Dutta]

Woo hooo, my first mail to the new webapps alias! -:)

Thanks for waiting for us to get feedback in from people across MSFT. As 
promised, here is the whitepaper on client side cross domain security 
articulating the security principles and challenges (high level and specifics ) 
of the current CS-XHR draft.
I've also addressed the questions members raised in the FAQ.

As Jonas and Art mention, in order to provide the opportunity for members to 
research and usefully discuss the contents and other issues, lets talk about 
our concerns among other items F2F in the first week of July.

https://mail.windows.microsoft.com/OWA/redir.aspx?C=7165bcd1f09048ac9fdcd34d2f9556b1&URL=http%3a%2f%2fcode.msdn.microsoft.com%2fxdsecuritywp%2fRelease%2fProjectReleases.aspx%3fReleaseId%3d1157

Look forward to hosting the members here in Redmond.



From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Sunava Dutta [EMAIL 
PROTECTED]
Sent: Friday, June 06, 2008 2:54 PM
To: Arthur Barstow; ext Jonas Sicking; Marc Silbey
Cc: [EMAIL PROTECTED]; public-webapi@w3.org WG (public); [EMAIL PROTECTED]; 
Eric Lawrence; Chris Wilson; David Ross; Mark Shlimovich (SWI); Doug Stamper; 
Zhenbin Xu
Subject: RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for  
Cross Site Requests]

Art, Jonas,
Just a quick update. We've put a lot of effort into the paper and the good news 
is we're nearly done. It's going through a final peer-review to make sure we've 
received feedback from experts in the company including our security gurus. 
(Yes, they do exist at MSFT -:))

I'll be sending out the paper on Tuesday evening or Wednesday the latest. 
Thanks for waiting.

> -Original Message-
> From: Arthur Barstow [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 16, 2008 5:06 AM
> To: ext Jonas Sicking; Sunava Dutta
> Cc: [EMAIL PROTECTED]; public-webapi@w3.org WG (public); public-
> [EMAIL PROTECTED]; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris Wilson;
> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal for
> Cross Site Requests]
>
> Sunava - I tend to agree with Jonas re the timing of MS' response/
> feedback.
>
> Given the f2f meeting is now about six weeks away, can you commit to
> and deliver on an earlier deadline, no later than June 6?
>
> -Regards, Art Barstow
>
>
> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
>
> >
> > Sunava Dutta wrote:
> >>>  >This message is not attempting to set forth in detail all the
> >>> objections we have had; Sunava will >deliver that in a concise form.
> >>>
> >>> Can you give us a ballpark ETA on this?
> > > [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
> > this to
> > > be ready and available to the Web API by mid June in the latest.
> >
> > Wow, this is really bad news that we won't get this feedback until
> > just two weeks before the face to face meeting. Especially given
> > the numerous delays in getting this feedback in the past I am very
> > worried that there will be further delays. Are you absolutely
> > certain that won't happen again?
> >
> > Even just having two weeks in order to discuss this feedback prior
> > to the meeting seems like very short on time.
> >
> > I would really encourage you to consider providing this feedback
> > more promptly. I do not wish to attend a face to face meeting
> > solely to discuss new feedback which we have not had the
> > opportunity to research and cannot usefully discuss. I also hope to
> > cover much more than microsofts feedback during the meeting.

RE: Microsoft Corp. has nominated Alec Berntson to Web API Working Group

[Sunava Dutta]

Good to have you here Alec!

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Alec Berntson
> Sent: Friday, June 06, 2008 10:32 AM
> To: Charles McCathieNevile; Michael Champion
> Cc: public-webapi@w3.org; Alec Berntson
> Subject: RE: Microsoft Corp. has nominated Alec Berntson to Web API
> Working Group
>
> Thanks Chaals,
>My Name is Alec Berntson, and I work on a variety of location related
> projects at Microsoft. My interest in the group's work is primarily
> focused on the Geolocation API proposal, which I would very much like to
> see take off. My goal is to help define the specification and (hopefully)
> coordinate resources to test it.
>
> Cheers,
>   Alec
>
>
> -Original Message-
> From: Charles McCathieNevile [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2008 2:37 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Michael Champion
> Cc: [EMAIL PROTECTED]; Alec Berntson
> Subject: Re: Microsoft Corp. has nominated Alec Berntson to Web API
> Working Group
>
> Alec,
>
> welcome to WebAPI. Can you please send a brief intro to the group (either
> [EMAIL PROTECTED] or public-webapi@w3.org is fine) including your
> interests in the group's work.
>
> Thanks in advance...
>
> cheers
>
> Chaals
>
> On Fri, 06 Jun 2008 04:52:01 +0200, <[EMAIL PROTECTED]> wrote:
>
> >   Dear AC Rep, Chair, Team Contact, and Participant,
> >
> > On June 6, 2008, 2:50  UTC, Alec Berntson became a participant in the
> Web
> > API Working Group. This person was nominated by Michael Champion
> >
> > This also implies that the following commitments were made:
> > - to  have reviewed the Process Document on individual participant
> > qualifications ( section 3.1 [1]),  Member participation in a Working
> > Group (section 6.2.1.1 [2]) - in particular that (1) the Member will
> > provide the necessary financial support for participation (e.g., for
> > travel, telephone calls, and conferences), and (2) the AC representative
> > attests that the individual accepts the participation terms set forth in
> > the charter [3] -  and good standing (section 6.2.1.7 [4])
> > - to  agree to the participation conditions described in the Working
> > Group
> > charter [3]
> >
> > For more information on Web API Working Group participation, see:
> > http://www.w3.org/2004/01/pp-impl/38482/status
> >
> > 1.
> > http://www.w3.org/2005/10/Process-
> 20051014/policies.html#ParticipationCriteria
> > 2. http://www.w3.org/2005/10/Process-20051014/groups.html#member-rep-wg
> > 3. http://www.w3.org/2006/webapi/admin/charter.html
> > 4. http://www.w3.org/2005/10/Process-20051014/groups.html#good-standing
> >
> >
> > This message has been sent by the W3C Working Group Management System.
>
>
>
> --
> Charles McCathieNevile  Opera Software, Standards Group
>  je parle français -- hablo español -- jeg lærer norsk
> http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

[Sunava Dutta]

Art, Jonas,
Just a quick update. We've put a lot of effort into the paper and the good news 
is we're nearly done. It's going through a final peer-review to make sure we've 
received feedback from experts in the company including our security gurus. 
(Yes, they do exist at MSFT -:))

I'll be sending out the paper on Tuesday evening or Wednesday the latest. 
Thanks for waiting.

> -Original Message-
> From: Arthur Barstow [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 16, 2008 5:06 AM
> To: ext Jonas Sicking; Sunava Dutta
> Cc: [EMAIL PROTECTED]; public-webapi@w3.org WG (public); public-
> [EMAIL PROTECTED]; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris Wilson;
> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal for
> Cross Site Requests]
>
> Sunava - I tend to agree with Jonas re the timing of MS' response/
> feedback.
>
> Given the f2f meeting is now about six weeks away, can you commit to
> and deliver on an earlier deadline, no later than June 6?
>
> -Regards, Art Barstow
>
>
> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
>
> >
> > Sunava Dutta wrote:
> >>>  >This message is not attempting to set forth in detail all the
> >>> objections we have had; Sunava will >deliver that in a concise form.
> >>>
> >>> Can you give us a ballpark ETA on this?
> > > [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
> > this to
> > > be ready and available to the Web API by mid June in the latest.
> >
> > Wow, this is really bad news that we won't get this feedback until
> > just two weeks before the face to face meeting. Especially given
> > the numerous delays in getting this feedback in the past I am very
> > worried that there will be further delays. Are you absolutely
> > certain that won't happen again?
> >
> > Even just having two weeks in order to discuss this feedback prior
> > to the meeting seems like very short on time.
> >
> > I would really encourage you to consider providing this feedback
> > more promptly. I do not wish to attend a face to face meeting
> > solely to discuss new feedback which we have not had the
> > opportunity to research and cannot usefully discuss. I also hope to
> > cover much more than microsofts feedback during the meeting.

Potential bugs identified in XHR LC Test Suite

[Sunava Dutta]

Thanks for writing these cases by LC exit. It really makes the process of 
providing feedback prior to CR a lot easier. I ran these (the tests below fail 
on Safari3 ,Firefox 3 and IE8) with my team and had a few questions. If these 
issues can be addressed we can give further feedback and recommendations on the 
results/implementations. (Let me know if I'm wrong on our test analysis!) The 
rest of the tests that fail (without issues in the test itself) are being 
investigated further by my team so expect more over the next few days as we dig 
in.


http://tc.labs.opera.com/apis/XMLHttpRequest/open/033.htm
This test seems to have a bug even though it passes. Line 24 uses 
top.opener.rr. The framework reports FAIL although the test passes.

http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/001.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/004.php
http://tc.labs.opera.com/apis/XMLHttpRequest/getResponseHeader/001.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/getResponseHeader/007.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/013.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/014.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/015.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/016.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/001.htm
http://tc.labs.opera.com/apis/XMLHttpRequest/readyState/002.htm
These tests seem to be failing when the test autorun is used in IE. Running the 
tests individually causes them to pass on IE8. Looks like a bug in the test 
framework.


http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/005.php
This test fails because the network timeout is too short and passes sometimes 
(Unpredictable).

http://tc.labs.opera.com/apis/XMLHttpRequest/send/005.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/send/007.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/send/008.htm

This seems to be a minor test bug. The file we are receiving does not contain 
the string "PASS", which is necessary for the test to pass.


http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/010.htm
http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/020.htm
The exception object here is not directly supported by IE, causing us to fail 
here. Can the test be tweaked so we can test the XHR compliance here? Thanks!

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/021.htm
The PHP page doesn't seem to be producing valid content

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/034.php
http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/035.php
Server-side PHP seems to be causing the test to pass or fail and we can't 
determine the PASS criteria. May we get a pointer to the source here? (I think 
this was given a long time before but I can't seem to dig it up!)

 Meanwhile, I'd like to re-iterate a point I had raised up awhile back. Are the 
tests going to be 'complete' /comprehensive at CR in relation to the spec? MSFT 
obviously wants this test suite to be official ensuring that third parties do 
not write individual test cases undermining the credibility of the suite and 
demonstrating increased/decreased compliance post CR (when it's much harder to 
make changes).

Thanks!




--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer
One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418
FAX# (425) 936-7329

RE: Dedicated Geolocation List and Channel

[Sunava Dutta]

Inline...

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Maciej Stachowiak
> Sent: Tuesday, June 03, 2008 11:44 AM
> To: Doug Schepers
> Cc: Web API public
> Subject: Re: Dedicated Geolocation List and Channel
>
>
>
> On Jun 3, 2008, at 11:19 AM, Doug Schepers wrote:
>
> > Hi, Maciej-
> >
> > Maciej Stachowiak wrote (on 6/3/08 1:53 PM):
> >> At this point I am really confused about where to discuss
> >> geolocation APIs, and I would rather not have it bounce back and
> >> forth. Maybe we should just wait until the chartering process
> >> reaches its conclusion.
> >
> > There's nothing to be confused about.  Regardless where the
> > deliverable ends up, whether in the proposed Geolocation WG, or the
> > WebApps WG, the *discussion list* will be the same:
> >
> > http://lists.w3.org/Archives/Public/public-geolocation/
> > [EMAIL PROTECTED]
>
> Well I'm pretty interested in coordinating with Google, Opera and
> Mozilla on this and it seems like they were interested in keeping the
> work and discussion here. It's true that you announced a new mailing
> list but it doesn't seem like anyone here asked for it. If it's going
> to be a mailing list for the WebApps WG, then maybe it would be good
> for the WG to discuss whether we want a separate list.[Sunava Dutta]

[Sunava Dutta] I think Doug's point is that there are more parties (and 
industries) that are affected by this. Of course, working with other browser 
vendors AND other invested parties is important.
>
> > I would strongly encourage folks to join and start discussions now,
> > rather than waiting.  A chartering period, with the review from W3C
> > Management and the Advisory Committee, takes at least 6 weeks, and
> > that doesn't include the time have preliminary discussions about it
> > and to write the charter.  Hixie indicated that Google did not want
> > to wait even 2 weeks, and I agree that keeping momentum is a high
> > priority. Naturally, if Apple wants to wait until the chartering
> > period is over, that's your prerogative, but it doesn't seem like a
> > good use of time and energy.
>
> Well, I wasn't that confused about where disucussion should go until
> you asked everyone to move discussion to a new list, when folks seemed
> happy to have it here.

[Sunava Dutta] I think Doug makes some very good points here. MSFT's stand 
based on the considerations that Doug has raised is that it should go to a new 
WG. There are teams here that do not need to be randomized with other WebApps 
conversations (that I participate in) but are nonetheless invested in 
GeoLocations. There is no additional burden for me to join a new list/WG and 
I'm glad to do so.
>
> > I sense that, for some reason, people are feeling territorial about
> > this issue, and I'm not sure why.  Can you please articulate what
> > your concerns about this happening in WebApps are, rather than in a
> > dedicated WG?
>
> I don't have any concerns about this being in WebApps. I think that
> would be a great option.
>
> Regards,
> Maciej
>
>

RE: XHR LC comments

[Sunava Dutta]

Inline...

> -Original Message-
> From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
> Sent: Saturday, May 17, 2008 2:04 AM
> To: Julian Reschke
> Cc: Sunava Dutta; Anne van Kesteren; Web API WG (public)
> Subject: Re: XHR LC comments
>
>
> On May 17, 2008, at 1:03 AM, Julian Reschke wrote:
>
> >
> > Sunava Dutta wrote:
> >> ...
> >>> At this point, I'm not sure why we're bothering with XHR1 at all.
> >>> It is
> >>> *not* what the current implementations do anyway.
> >> [Sunava Dutta] I'm sorry, this statement is concerning and I'd like
> >> to understand it better. We haven't had a chance to run the latest
> >> test suite yet but expect the test suite to be compliant with at
> >> least two existing implementations. Do you mean the XHR 1 draft is
> >> not interoperable with existing implementations?
> >> ...
> >
> > Absolutely. Everytime I check something that is of interest to me it
> > turns out that there is no interop, and that only some or even none
> > of the browsers works as specified.
>
> We decided long ago (and subsequently reaffirmed) that instead of
> leaving the spec so vague that all existing implementations are
> automatically compliant, we would define a shared interoperable
> behavior so that implementations can converge. It should not be news
> to anyone that implementations are not automatically 100% compliant.
>
> > Examples:
> >
> > - Support for HTTP extension methods: IE violates the SHOULD level
> > requirement to support extenstion methods. Opera silently (!!!)
> > changes extension method names to "POST".
> >
> > - setRequestHeader: none of the browsers throws an exception when
> > setting the header to null. Some do something useful (removing the
> > header), some treat it like an empty string, some seem to set the
> > valoue to the string "null".
> >
> > I'm also concerned that the spec proposes behaviour that leads to
> > silent data loss, although it's totally unclear why this is needed
> > for interoperability (such as when a DOM to be serialized has no XML
> > representation).
> >
> > It seems that what's needed here is more work on the test suite. LC
> > is way too early.
>
> By W3C Process, the test suite is supposed to be developed during the
> CR period. So by having one at all before LC, we are ahead of schedule.

[Sunava Dutta] Can I have a link to this? I can't find it. Thanks!
Btw, we discussed the possibility of having the test suite ready before CR (see 
below). I think that's wise given that you mentioned that there are many cases 
where interoperability has not been reached? (or a convergence plan is not in 
place?) Our XHR test is going to be running the test suite in LC to see where 
interop doesn't exist and weigh in with our thoughts where we can to help.
http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0019.html
In response to our mail:
> 2) In fact, on that note, we're interested to see the test suite be
> linked, normatively if necessary.
Charles said
"Yes. I think this is a valuable piece of feedback. Currently W3C process
doesn't require test suites until you're trying to get out of CR and I
think it would be better to have them earlier. I would
like the group to start checking the test cases we have against the spec
and formally agreeing them to facilitate this linkage during last call. It
slows down the LC period, but it should make CR easier and reduce the
possibility of reverting from CR."

)

>
> Regards,
> Maciej
>

RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

[Sunava Dutta]

Sure. I've talked to my team and June 6 is OK.

> -Original Message-
> From: Arthur Barstow [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 16, 2008 5:06 AM
> To: ext Jonas Sicking; Sunava Dutta
> Cc: [EMAIL PROTECTED]; public-webapi@w3.org WG (public); public-
> [EMAIL PROTECTED]; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris Wilson;
> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal for
> Cross Site Requests]
>
> Sunava - I tend to agree with Jonas re the timing of MS' response/
> feedback.
>
> Given the f2f meeting is now about six weeks away, can you commit to
> and deliver on an earlier deadline, no later than June 6?
>
> -Regards, Art Barstow
>
>
> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
>
> >
> > Sunava Dutta wrote:
> >>>  >This message is not attempting to set forth in detail all the
> >>> objections we have had; Sunava will >deliver that in a concise form.
> >>>
> >>> Can you give us a ballpark ETA on this?
> > > [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
> > this to
> > > be ready and available to the Web API by mid June in the latest.
> >
> > Wow, this is really bad news that we won't get this feedback until
> > just two weeks before the face to face meeting. Especially given
> > the numerous delays in getting this feedback in the past I am very
> > worried that there will be further delays. Are you absolutely
> > certain that won't happen again?
> >
> > Even just having two weeks in order to discuss this feedback prior
> > to the meeting seems like very short on time.
> >
> > I would really encourage you to consider providing this feedback
> > more promptly. I do not wish to attend a face to face meeting
> > solely to discuss new feedback which we have not had the
> > opportunity to research and cannot usefully discuss. I also hope to
> > cover much more than microsofts feedback during the meeting.

RE: XHR LC comments

[Sunava Dutta]

Inline...

> -Original Message-
> From: Jonas Sicking [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 19, 2008 3:53 PM
> To: Sunava Dutta
> Cc: Anne van Kesteren; Julian Reschke; Maciej Stachowiak; Web API WG
> (public); IE8 Core AJAX SWAT Team
> Subject: Re: XHR LC comments
>
> Sunava Dutta wrote:
> > Inline...
> >
> >> -Original Message-
> >> From: Jonas Sicking [mailto:[EMAIL PROTECTED]
> >> Sent: Monday, May 19, 2008 3:14 PM
> >> To: Sunava Dutta
> >> Cc: Anne van Kesteren; Julian Reschke; Maciej Stachowiak; Web API WG
> >> (public); IE8 Core AJAX SWAT Team
> >> Subject: Re: XHR LC comments
> >>
> >> Sunava Dutta wrote:
> >>>>> setRequestHeader() currently simply is broken. We should deprecate
> it,
> >>>>> and add new methods with well-defined semantics:
> >>>>>
> >>>>> - removeHeader(...) (or specify set with null to mean remove)
> >>>>> - addHeader...
> >>>>> - getHeader...
> >>>> "Deprecating" a method does not help implementations converge.
> Besides,
> >>>> for typical usage there's no issue in using this header at all.
> >>>>
> >>> [Sunava Dutta] I agree with Anne here. Deprecating an existing
> >>> implementations and re-engineering XHR is something we just cannot
> >>> accept. This spec should be designed to reflect reality and seek
> >>> interoperability for each and every single section/method/event with
> >>> at least one (I think the W3C mandates two?) existing implementations.
> >>> That does not mean the entire spec is aligned with FF or IE, but it
> >>> should be harmonious at any instance with one existing implementation.
> >> There is absolutely no W3C mandate that a spec is compatible with any
> >> existing implementations in order to reach the earlier milestones in
> the
> >> standardization track. Not sure where you got that idea. It would be
> >> very strange if there was a requirement to have implementations in
> order
> >> to reach LC, when W3C is discouraging implementations at that stage.
> >>
> >> Also, I personally don't care at all which UAs the various features of
> >> spec is compatible with. Or if it's not compatible with any UA. What I
> >> care about is that the spec is compatible with the web, and in the
> cases
> >> where the web doesn't care, that it's as useful and simple as possible.
> >>
> >> / Jonas
> > [Sunava Dutta] Compatible with the web sounds very nice and is
> > something I think I share with you. I think you mean compatible with
> > browsers who enable the technologies when you mean compatible with the
> > web?
>
> No, I mean "able to run the javascript that exists on pages on the web".
> So for example if there is an aspect to a feature that no, or very few,
> web pages use, then I don't think we need to pay attention to what UAs
> do today and instead make the best possible spec based on technical
> considerations.
[Sunava Dutta] Thanks for explaining. Yes, if features exist in XHR that web 
content does not rely on, we should absolutely drive to UA alignment with the 
reality.


>
> Figuring out what aspects webpages do or don't use is hard of course.
> But often there are indications as well as implementation experience.
>
> > Getting back to more specifics, if we're talking about compatibility I
> > absolutely believe the spec should be relevant to existing
> > implementations.
>
> What do you mean by "relevant to existing implementations". And why do
> you think that?
[Sunava Dutta] Existing implementations means the web sites. I see the 
confusion, since I use the term implementation later on to mean browsers.
>
> > I'm amenable to what Maciej said when he mentioned
> > that in the case (I'm assuming this is a rarity) where the
> > implementations are doing whacky things or doing nothing at all, it
> > makes sense to work together to identify a way/solution that will
> > allow for convergence.
>
> It is in fact quite common when you start looking at the details of the
> various features that implementations behave very differently. So in
> those details we should in my opinion use the strategy I described above.

>
> / Jonas

RE: XHR LC comments

[Sunava Dutta]

Inline...

> -Original Message-
> From: Jonas Sicking [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 19, 2008 3:14 PM
> To: Sunava Dutta
> Cc: Anne van Kesteren; Julian Reschke; Maciej Stachowiak; Web API WG
> (public); IE8 Core AJAX SWAT Team
> Subject: Re: XHR LC comments
>
> Sunava Dutta wrote:
> >>> setRequestHeader() currently simply is broken. We should deprecate it,
> >>> and add new methods with well-defined semantics:
> >>>
> >>> - removeHeader(...) (or specify set with null to mean remove)
> >>> - addHeader...
> >>> - getHeader...
> >> "Deprecating" a method does not help implementations converge. Besides,
> >> for typical usage there's no issue in using this header at all.
> >>
> > [Sunava Dutta] I agree with Anne here. Deprecating an existing
> > implementations and re-engineering XHR is something we just cannot
> > accept. This spec should be designed to reflect reality and seek
> > interoperability for each and every single section/method/event with
> > at least one (I think the W3C mandates two?) existing implementations.
> > That does not mean the entire spec is aligned with FF or IE, but it
> > should be harmonious at any instance with one existing implementation.
>
> There is absolutely no W3C mandate that a spec is compatible with any
> existing implementations in order to reach the earlier milestones in the
> standardization track. Not sure where you got that idea. It would be
> very strange if there was a requirement to have implementations in order
> to reach LC, when W3C is discouraging implementations at that stage.
>
> Also, I personally don't care at all which UAs the various features of
> spec is compatible with. Or if it's not compatible with any UA. What I
> care about is that the spec is compatible with the web, and in the cases
> where the web doesn't care, that it's as useful and simple as possible.
>
> / Jonas
[Sunava Dutta] Compatible with the web sounds very nice and is something I 
think I share with you. I think you mean compatible with browsers who enable 
the technologies when you mean compatible with the web?
Getting back to more specifics, if we're talking about compatibility I 
absolutely believe the spec should be relevant to existing implementations. I'm 
amenable to what Maciej said when he mentioned that in the case (I'm assuming 
this is a rarity) where the implementations are doing whacky things or doing 
nothing at all, it makes sense to work together to identify a way/solution that 
will allow for convergence.
Thanks for pointing out there is no mandate or guidelines for having two 
implementations in CR. I misunderstood something Chris had mentioned awhile 
back. -:).

RE: XHR LC comments

[Sunava Dutta]

Inline...

> -Original Message-
> From: Anne van Kesteren [mailto:[EMAIL PROTECTED]
> Sent: Saturday, May 17, 2008 5:45 AM
> To: Julian Reschke
> Cc: Maciej Stachowiak; Sunava Dutta; Web API WG (public)
> Subject: Re: XHR LC comments
>
> On Sat, 17 May 2008 14:23:24 +0200, Julian Reschke <[EMAIL PROTECTED]>
> wrote:
> > Anne van Kesteren wrote:
> >> On Sat, 17 May 2008 11:56:45 +0200, Julian Reschke
> >> <[EMAIL PROTECTED]> wrote:
> >>> But what IMHO happens all over again is that strange choices in the
> >>> design are defended with the statement "this is what the vendors do,
> >>> or want to do", and when we check it, that turns out to be incorrect.
> >>  Could you point out one such example? I've actually tested a fair
> >> amount
> >
> > They are in the current threads.
> >
> > - "add" semantics for setRequestHeader
> > - semantics for setRequestHeader(...,null)
> > - silent data loss for send() when DOM can't be serialized
> > - ...
>
> I think only for the last one I have suggested that I rather not change it
> based on that this seems like a safer choice. I have not seen any tests
> that show that implementations actually throw in that case.
>
>
> >> of stuff, including headers, methods, etc. I agree that some of the
> >> details of headers need to be worked out. For null/""/undefined I've
> >> been waiting for the Web IDL specification. For which headers can be
> >> set by the user agent I don't really have an answer and that part has
> >> not been defined as such. That setRequestHeader() always appends was a
> >> conscious choice to be in line with Internet Explorer. Initially the
> >> design was so that it special cased a bunch of headers that did not
> >> allow duplication which would have been more in line with Firefox, but
> >> given that it is not a fixed list and the Internet Explorer route
> >> seemed more appropriate.
> >
> > Well, not to me. And apparently not to FF, as FF3 seems to ship with be
> > non-compliant behavior.
>
> To my best knowledge Mozilla hasn't started implementing the specification
> yet. I've seen several comments in their public bug database to the effect
> that they rather wait until it reaches CR.
>
>
> > setRequestHeader() currently simply is broken. We should deprecate it,
> > and add new methods with well-defined semantics:
> >
> > - removeHeader(...) (or specify set with null to mean remove)
> > - addHeader...
> > - getHeader...
>
> "Deprecating" a method does not help implementations converge. Besides,
> for typical usage there's no issue in using this header at all.
>
[Sunava Dutta] I agree with Anne here. Deprecating an existing implementations 
and re-engineering XHR is something we just cannot accept. This spec should be 
designed to reflect reality and seek interoperability for each and every single 
section/method/event with at least one (I think the W3C mandates two?) existing 
implementations. That does not mean the entire spec is aligned with FF or IE, 
but it should be harmonious at any instance with one existing implementation.
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>

RE: [XHR] referencing HTML5

[Sunava Dutta]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Anne van Kesteren
> Sent: Friday, May 16, 2008 2:16 AM
> To: public-webapi@w3.org
> Subject: [XHR] referencing HTML5
>
>
> There have been a lot of messages about referencing HTML5 and how we can
> mitigate that. I don't think that copying the text from HTML5 is an
> option. The Window specification is fairly complex and especially the
> interaction with browsing contexts is a complex bit of HTML5 that I don't
> feel confident taking over. The same goes for defining the origin policy.

[Sunava Dutta] I agree, copying everything will bloat this spec and will add 
complexity to the specification. I did make this point awhile back below 
(regarding linking to specifications that are in flux) and I'm glad to see 
concerns here being discussed.

" The draft frequently cross references specifications in the W3C.For example, 
the spec makes references to the DOM 3 events and core, namespaces in XML, 
Window Object 1.0 etc (Some of which are drafts themselves). We fail to see the 
value in implicitly embedding other large specs. Simplicity and standing on its 
own would be good."
http://lists.w3.org/Archives/Public/public-webapi/2007Sep/0043.html

The challenge of interlinking right now means that XHR should not go past CR 
unless those interlinked drafts are stabilized. I don’t think we can have a 
spec move past CR that references moving targets.
Also, how are we two ensure that two interoperable implementations exist (isn’t 
this a requirement for CR?) if this is the case? Pardon if I'm wrong.

Also, HTML 5.0 as Ian mentions (those aspects of HTML 5.0 that deal with XHR) 
should reflect existing implementations, or it quickly becomes an academic 
exercise and looses relevance.
Ian says: " HTML5 is describing existing practice on these matters, not 
defining new"

I would strongly urge the editor of the XHR spec to consider defining these 
outside of HTML 5.0 (maybe in the spec or link to it) in a way that reflects 
existing implementation since this is very tied to XHR as mentioned in the past 
by members. Having it outside of HTML 5.0 is OK as the charter of the merged WA 
Working Group (That accepts XHR as a deliverable) does not mention HTML 5.0 as 
an referenced specification.

If not then we should wait for HTML 5.0 to lockdown. (Or perhaps those sections 
of HTML 5.0 to lockdown)
Eitherway, focusing on this getting to REC by any means is not wise until it's 
done.

>
> If someone were to volunteer to define these outside of HTML5 we could
> refer to that specification but so far that has not happened.
>
> So we have two reasonable options I think:
>
> 1) Keep the references intact.
>
> 2) Make various things implementation defined and hint with non-normative
> notes that this will be defined by HTML5 in the future.
>
> Option two would be feasible but implementors have actually requested that
> we define in detail how URIs are resolved and what exactly the same-origin
> policy implies for XMLHttpRequest. I don't think it's worth dropping all
> that work on the floor.
[Sunava Dutta] Your argument that implementers have requested this is fine, but 
then it's the specs responsibility to address those sections (the relevant 
behavior) in the spec or wait till those are settled.
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>

RE: XHR LC comments

[Sunava Dutta]

Comment Inline.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Julian Reschke
> Sent: Friday, May 16, 2008 4:14 AM
> To: Anne van Kesteren
> Cc: Web API WG (public)
> Subject: Re: XHR LC comments
>
>
> Anne van Kesteren wrote:
> > Since this is the second Last Call and credentials are already following
> > each other (and the same for other similar steps) I've decided not to
> > change this.
>
> Unfortunately.
>
> >>>> c) Structure: It would be nice if Section 4 had more structure.
> >>>> Rightnow it's ugly to navigate and refer to.
> >>> This is better in XMLHttpRequest Level 2. I rather not revise
> >>> thatentire section editorially as it might introduce new errors.
> >>
> >> But then, it makes a comparison with XHR2 harder. Please reconsider.
> >
> > Given that XMLHttpRequest Level 2 has more changes than just this in
> > terms of structure I don't think it will help that much.
>
> At this point, I'm not sure why we're bothering with XHR1 at all. It is
> *not* what the current implementations do anyway.
[Sunava Dutta] I'm sorry, this statement is concerning and I'd like to 
understand it better. We haven’t had a chance to run the latest test suite yet 
but expect the test suite to be compliant with at least two existing 
implementations. Do you mean the XHR 1 draft is not interoperable with existing 
implementations?

>
> >>> Yes, as stated it must be a subset that matches what
> >>> XMLHttpRequestrequires from the eventing and core specifications.
> >>
> >> Then it would be clearer if it said "the subset" instead of "some
> >> subset".
> >
> > Changed:
> >
> >   http://dev.w3.org/2006/webapi/XMLHttpRequest/#dependencies
>
> Thanks.
>
> >> Well, if we're talking about URIs (and I think we do), then we need to
> >> refer to RFC3986 grammar and comparison rules.
> >
> > Ok, referenced RFC3986 as well.
>
> That's not sufficient, and not what I asked for. Please make up your
> mind whether it's a URI or a IRI, and then cite accordingly.
>
> >>>> Besides that: this may be a non-optimal example unless we can point
> >>>> toa definition of "HttpOnly cookies". Can we?
> >>> I don't believe we can, but since this was put in mostly for
> >>> HttpOnlycookies I rather not remove that. I think it will be clear
> >>> enough forpeople reading the document.
> >>
> >> So why don't we refer to the specification for httpOnly? Do you
> consider
> >> it a problem that it's a Microsoft document?
> >
> > I added a pointer to http://msdn.microsoft.com/en-
> us/library/ms533046.aspx
>
> Thanks.
>
> >
> >> As TRACK doesn't seem to be documented anywhere, and not implemented in
> >> current IIS versions anymore, I'd really like to see this made a foot
> >> node. The way it's written now is just totally confusing to every
> reader
> >> who doesn't know the full story around it.
> >
> > I added a note.
>
> I'd prefer it to be moved somewhere else, but at least it's an
> improvement.
>
> >> When they are a string, then taking about character encoding doesn't
> >> make any sense here.
> >
> > Actually, since you need to encode them for the request it does.
>
> But that totally depends on the authentication scheme. I think you're
> confusing layers here.
>
> >> Thinking of it, could you please add a clarification that setting to an
> >> empty string is legal, and MUST NOT be ignored? I recall that
> >> Microsoft's original XHR (ActiveX) implementation got that wrong, not
> >> setting the header at all.
> >
> > I added a note to that effect as it is already normatively required.
>
> Thanks. It currently says:
>
> "Note: The empty string is legal."
>
> Maybe you could add "and represent an empty header value"?
>
> >>>> "Serialize data into a namespace well-formed XML document and
> >>>> encodedusing the encoding given by data.inputEncoding, when not
> >>>> null, orUTF-8 otherwise. Or, if this fails because the Document
> >>>> cannot beserialized act as if data  is null."
> >>
> >> Does anybody rely on that? I would be very suprised.
> >
> > I don't know, but it seems safest to not require changes here for
> > compatibility.
>
> Sounds li

RE: IE Team's Proposal for Cross Site Requests

[Sunava Dutta]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Arun Ranganathan
> Sent: Wednesday, May 14, 2008 7:01 PM
> To: public-webapi@w3.org; [EMAIL PROTECTED]
> Subject: Re: IE Team's Proposal for Cross Site Requests
>
>
> Chris,
>
> Thanks for the email. A few points below:
>
>  >This message is not attempting to set forth in detail all the
> objections we have had; Sunava will >deliver that in a concise form.
>
> Can you give us a ballpark ETA on this?

[Sunava Dutta] Sure, I'm compiling this as we speak. I expect this to be ready 
and available to the Web API by mid June in the latest. (Sorry for the time, my 
resources are spread thin over several AJAX features) I don't think there 
should be any surprises here as we have communicated our concerns before. 
However, there does seem to be the scope to provide specific concerns which we 
will do where we can or elaborate on a few, as well as our security principles 
for a good cross domain solution and where AC fails or meets them. This does 
not change what Chris said though. Just because there are not existing threats 
(although the URL canonicalization issue as Eric Lawrence discovered is 
currently open?) does not mean that AC is safe. We can present threats and they 
can be patched. That's just not something we recommend. A good threat modeled 
solution I'm sure many of us will agree is secure by design. That's our 
overarching point we've been trying to get across.
>
>  >For example, today the current XHR draft proposes to block a list of
> headers that are unsafe >only in a cross-domain context; however, this
> is difficult to deploy since XHR has already >shipped, and challenging
> to imagine that there are no other headers in use by servers anywhere
>  >around the world that might not be good to access.
>
> Microsoft feedback on proposals such as
>
> http://lists.w3.org/Archives/Public/public-appformats/2008May/0034.html
>
> are welcome. Also, I'm not averse to discussing a restricted list of
> headers that the XHR API *should* support rather than a block list.

[Sunava Dutta] You're missing the point. I'm agnostic to a block or allow list. 
What I've been asking for in case it's not been clear is the rationale as to 
why these are blocked in the spec. There are threads going on regarding this. 
My point is that blocking headers on shipped implementations is hard, since 
it's difficult for us to patch legacy versions. The current XHR spec should not 
be an academic exercise and should rightfully model existing UA's. That said 
doing the right thing for security is important, but we need to have good 
justifications. Currently that is absent in the case of the blocked headers.
>
>  >There are fundamental cross domain security principles that we firmly
> believe need to be >guaranteed by a cross domain solution; otherwise,
> our experience leads us to believe there will >be exploits found over
> time. Cross-domain access in Flash has had a trail of bugs for these
>  >reasons [1]. Sunava will detail these security principles;
>
> *In particular* what is the direct parallel you are drawing between the
> Flash approach and the XHR2+AC approach? Sunava's commentary eagerly
> awaited. In this message
>
[Sunava Dutta] Wildcarding was a problem in Flash (one of many?). I'm not sure 
if AC is vulnerable to that but it certainly seems possible? The point here is 
that a number of developers won't ready the security notes on the docs and 
inadvertently expose their services. Solutions should be coded for the lowest 
common denominator. That's hard to understand given that most Web API 
participants are quite technical.
http://jeremiahgrossman.blogspot.com/2006/10/crossdomainxml-statistics.html

> http://lists.w3.org/Archives/Public/public-webapi/2008May/0196.html
>
> you suggest we look at "DNS Hardening" for "clues." Can you be a bit
> more specific here, if possible?
>
[Sunava Dutta] The write-up I'm compiling will investigate the DNS rebinding 
issue in more detail. I think that's fair. If DS rebinding is raised as a 
concern, we should be able to give a specific threat or in the minimum a 
potential mechanism. I'm not a security guru here and I expect my security team 
can give me a proper assessment of the risk of AC here, although it seems with 
the two step request here and the requirement of sites to validate the host 
header, TOCTOU and DNS rebinding risks are high.

>  >Even if current vulnerabilities like exposure to Time of Check, Time
> of Use, >DNS Rebinding >attacks, and URL path canonicalization issues
> can be patched (rather than >ignored),
>
> I think we ought to make spec. language an

RE: XHR LC Draft Feedback

[Sunava Dutta]

Comments inline. Thanks,

> -Original Message-
> From: Anne van Kesteren [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 12, 2008 8:12 AM
> To: Sunava Dutta
> Cc: public-webapi@w3.org; Gideon Cohn; Ahmed Kamel; Zhenbin Xu; Doug
> Stamper
> Subject: Re: XHR LC Draft Feedback
>
> On Fri, 18 Apr 2008 03:00:46 +0200, Sunava Dutta
> <[EMAIL PROTECTED]> wrote:
> > So essentially summarizing my two requests for your convenience.
> >
> > 1.   Mentioning for each header the reasons for restriction. (I
> > think security is paramount but for shipped implementations I would
> > hesitate to reduce surface area of attack unless there is a compelling
> > reason. It's much harder to restrict once we ship!)
>
> The restrictions on allowed headers have come forth based on
> implementation feedback from Opera, Apple, and Mozilla. If you have
> feedback that suggests the list of headers should be different, please let
> us know.
[Sunava Dutta] Ah, sorry I'm not being clear. What I'm asking for is the 
reasons for why the headers are blocked (based on implementation feedback, but 
what is the feedback per blocked header?) to be called out for each header in 
the spec. Otherwise it seems arbitrary.
>
>
> > 2.   Protecting Access-Control-Origin header from being set in XHR.
> > Cheers and thank you!
>
> I agree that Access-Control-Origin needs to be blocked, but shouldn't we
> add this header in XMLHttpRequest Level 2? Adding it in XMLHttpRequest
> Level 1 seems slightly odd, though I don't feel strongly either way.
[Sunava Dutta] Having it in XHR L2 is OK with me.
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>

RE: XHR LC comments

[Sunava Dutta]

Ahh, I see my mail client can do that. I just need to make a few changes. 
Having a standardized guidance here would be very helpful -:p.


-Original Message-
From: Julian Reschke [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 06, 2008 12:34 AM
To: Sunava Dutta
Cc: public-webapi@w3.org; IE8 Core AJAX SWAT Team
Subject: Re: XHR LC comments

Sunava,

it would be helpful if you'd use a mail client that can properly quote
:-) In your mail your text appears as if it was indirectly quoted by
myself... I have reformatted your reply so it becomes clear again who
said what.

Sunava Dutta wrote:
>> Julian Reschke wrote:
>> c)
>> "- TRACK??? There's probably a rational for that. If there is, please
>> include it in the spec."
>
>TRACK is unsafe and should be removed. I remember reading about this awhile 
>back. Here's something I found on the web: 
>http://www.aqtronix.com/Advisories/AQ-2003-02.txt

That implies that Microsoft closed the vulnerability with IIS 6.0, so
I'm not entirely sure why a spec in last call in 2008 needs to speak
about it.

There are surely other old servers that have other vulnerabilities that
could be exploited using XHR, should we consider all of these?

That being said, I'm ok with *mentioning* the issue somewhere, but just
enumerating TRACK along with TRACE, as if this was a standard HTTP
method, is *highly* confusing.

 > ...

BR, Julian

RE: Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: IE Team's Proposal for Cross Site Requests]

[Sunava Dutta]

XDomainRequest is optimized for the "public data" use case; it sends anonymous 
requests that do not carry cookies or credentials.

Obviously, it is possible to create XDomainRequest-based AJAX applications 
whereby identity or authorization tokens are carried in a request body payload 
(in JSON/XML/other format) but any server configured to accept such tokens must 
take steps to mitigate any CSRF vulnerabilities, and should also ensure that 
proper HTTP caching directives are present on any non-public response.

-Original Message-
From: Ben Adida [mailto:[EMAIL PROTECTED]
Sent: Friday, May 02, 2008 3:29 PM
To: Sunava Dutta
Cc: Arthur Barstow; Eric Lawrence; Chris Wilson; ext Anne van Kesteren; Web API 
WG (public); [EMAIL PROTECTED]; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Marc 
Silbey
Subject: Re: Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: 
IE Team's Proposal for Cross Site Requests]

Sunava Dutta wrote:
> Art, I apologize for the delay but we're currently coming up with a
> plan moving forward to regarding how we want to proceed with cross
> domain.

Sunava,

I've been lurking on this list for a while, and wanted to ask a question
that I don't think has been answered on the list.

The IE8 White Paper on "Better Ajax Development" says:

"Cross-domain requests are anonymous to protect user data, which means
that servers cannot easily find out who is requesting data. As a result,
you only want to request and respond with cross-domain data that is not
sensitive or personally identifiable."

Is that an accurate representation of MS's position, that XDR should
never be used to request sensitive/private information, only generic
public data?

Thanks,

-Ben Adida
[EMAIL PROTECTED]

RE: XHR LC comments

[Sunava Dutta]

Julian Reschke wrote:
a) I'm confused about the approach to this document. On the one hand,
we're being told that it can't define anything not already in use (and
that new stuff belongs into XHR2), on the other hand it relies on HTML5,
which is a moving target. It's good that this stuff is being written
down, but if it relies on HTML5, I'd propose to consider other
publication options.

>>+1. I had suggested something along the lines of not linking to other 
>>specifications that are moving targets but other publication options if we do 
>>decide to go this route are fine.

"Ensure all new entities like constants, flags etc are versioned or in a new 
object.
The draft frequently cross references specifications in the W3C.For example, 
the spec makes references to the DOM 3 events and core, namespaces in XML, 
Window Object 1.0 etc (Some of which are drafts themselves). We fail to see the 
value in implicitly embedding other large specs. Simplicity and standing on its 
own would be good."

Julian Reschke wrote:

b) Algorithms: the spec uses a method to describe algorithms that IMHO
is extremely hard to read (see for instance send() method). This may be
good for implementors, but seems to be bad for everybody else.
Minimally, the lists should be structured for better readability.

>>+1

Julian Reschke wrote:
c)
"- TRACK??? There's probably a rational for that. If there is, please
include it in the spec."

>>TRACK is unsafe and should be removed. I remember reading about this awhile 
>>back. Here's something I found on the web: 
>>http://www.aqtronix.com/Advisories/AQ-2003-02.txt

Julian Reschke wrote:
d)
""If the user argument was not omitted and is not null let stored user be
user  encoded using the encoding specified in the relevant
authentication scheme or UTF-8 if the scheme fails to specify an encoding."

Why is XHR talking about the encoding here? Is "stored user" a string or
a byte array?

(same for password)"


>>+1. I'm not quite sure what this means and the relevancy.

Julian Reschke wrote:
e)
"For security reasons, these steps should be terminated if the header
argument case-insensitively matches one of the following headers:

 * Accept-Charset
 * Accept-Encoding
 * Connection
 * Content-Length
 * Content-Transfer-Encoding
 * Date
 * Expect
 * Host
 * Keep-Alive
 * Referer
 * TE
 * Trailer
 * Transfer-Encoding
 * Upgrade
 * Via "

It's unclear why there's a security reason not to allow things like
"Accept-Charset" or "Accept-Encoding". Please explain."

>>+1. I've given this feedback before but haven't heard back anything. We 
>>should mention why these are bad and also consider what is currently allowed 
>>today by UA's.
http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0191.html




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Julian Reschke
Sent: Sunday, May 04, 2008 2:47 AM
To: public-webapi@w3.org
Subject: XHR LC comments


Review of .

General points:

a) I'm confused about the approach to this document. On the one hand,
we're being told that it can't define anything not already in use (and
that new stuff belongs into XHR2), on the other hand it relies on HTML5,
which is a moving target. It's good that this stuff is being written
down, but if it relies on HTML5, I'd propose to consider other
publication options.

b) Algorithms: the spec uses a method to describe algorithms that IMHO
is extremely hard to read (see for instance send() method). This may be
good for implementors, but seems to be bad for everybody else.
Minimally, the lists should be structured for better readability.

c) Structure: It would be nice if Section 4 had more structure. Right
now it's ugly to navigate and refer to.



2.1 Dependencies

"DOM

 A conforming user agent must support some subset of the
functionality defined in DOM Events and DOM Core that this specification
relies upon. [DOM2Events] [DOM3Core]"

That reads a bit strange. Must the subset be non-empty?


2.2 Terminology

"Two URIs are same-origin if after performing scheme-based normalization
on both URIs as described in section 5.3.3 of RFC 3987 the scheme, ihost
and port components are identical. If either URI does not have an ihost
component the URIs must not  be considered same-origin. [RFC3987]"

Why are we referring to the IRI spec (RFC3987) when talking about URIs,
as defined RFC3986?


3. Security Considerations

"Apart from requirements affecting security made throughout this
specification implementations may, at their discretion, not expose
certain headers, such as HttpOnly cookies."

"...such as headers containing HttpOnly cookies".

Besides that: this may be a non-optimal example unless we can point to a
definition of "HttpOnly cookies". Can we?


4. The XMLHttpRequest Object

"onreadystatechange of type EventListener

 This attribute is an event handler DOM attribute and 

RE: IE Team's Proposal for Cross Site Requests

[Sunava Dutta]

Maciej wrote:
" I would also prefer to see a clear statement of Microsoft's position
in written form ahead of the telecon. By their nature, these are
issues that need careful analysis, and cannot be evaluated fully in
the context of a teleconference."

I think the request will help discussion. Yes, we will be making our position 
and points that need further deliberation available in a written form prior to 
the teleconference.

-Original Message-
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 29, 2008 5:01 PM
To: Ian Hickson
Cc: Chris Wilson; Anne van Kesteren; Sunava Dutta; Web API WG (public); [EMAIL 
PROTECTED]; Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug 
Stamper; Marc Silbey
Subject: Re: IE Team's Proposal for Cross Site Requests


On Apr 29, 2008, at 2:14 PM, Ian Hickson wrote:

>
> On Tue, 29 Apr 2008, Chris Wilson wrote:
>>
>> Given the multitude of issues raised, and the obvious back-and-forth
>> that denotes many differing opinions, I'd suggest having a telecom to
>> discuss these questions, and make sure that Sunava, Eric and myself
>> can
>> attend.
>
> I'm with Anne on this. Please reply to the e-mails before convening a
> telecon. It is very difficult to carefully consider feedback in the
> context of a telecon.
>
> The problem isn't "back-and-forth" denoting "many differing
> opinions", the
> problem is that we don't know what Microsoft's opinion _is_.
>
> Telecons are by their nature much less open, and minutes are almost
> uniformly so poor that it is hard to impossible to get precise
> technical
> details out of telecons. A telecon would not be appropriate at this
> point.

I would also prefer to see a clear statement of Microsoft's position
in written form ahead of the telecon. By their nature, these are
issues that need careful analysis, and cannot be evaluated fully in
the context of a teleconference.

Regards,
Maciej

RE: Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: IE Team's Proposal for Cross Site Requests]

[Sunava Dutta]

Art,
I apologize for the delay but we're currently coming up with a plan moving 
forward to regarding how we want to proceed with cross domain. Our timeframe 
for responses to the questions below is tied to that plan. As you can imagine, 
the Web API's support for XDR is something we believe would go a long way 
towards securing cross domain. The current WG decision based on the survey will 
cause us to re-strategize significantly.
Chris, out platform architect will get back soon with a response.


-Original Message-
From: Arthur Barstow [mailto:[EMAIL PROTECTED]
Sent: Friday, May 02, 2008 3:57 AM
To: Sunava Dutta; Eric Lawrence; Chris Wilson
Cc: ext Anne van Kesteren; Web API WG (public); [EMAIL PROTECTED]; Zhenbin Xu; 
Gideon Cohn; Sharath Udupa; Marc Silbey
Subject: Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: IE 
Team's Proposal for Cross Site Requests]

Sunava,

Several of the active contributors of the AC spec and XHR{2} specs
have now asked you and your colleagues for follow-ups before a voice
conference.

Would you folks please follow the four UIRs Anne listed below and
provide feedback as requested?

-Regards, Art Barstow


On Apr 23, 2008, at 4:31 AM, ext Anne van Kesteren wrote:

>
> On Wed, 23 Apr 2008 10:01:33 +0200, Anne van Kesteren
> <[EMAIL PROTECTED]> wrote:
>> On Wed, 23 Apr 2008 04:26:39 +0200, Sunava Dutta
>> <[EMAIL PROTECTED]> wrote:
>>> Thanks for the participation and comments.
>>> I think this discussion is best continued in a telecon. I'm
>>> working with Doug Schepers to see what we can schedule here.
>>> Once again, thanks for sharing thoughts and providing feedback.
>>
>> Wouldn't it be better if the IE Team first addressed the issues
>> raised so far with XDomainRequest in an e-mail? Getting this
>> information in a teleconference is not very convenient as minutes
>> are often of poor quality and teleconferences don't allow for
>> thinking arguments through and studying them.
>
> I was told it would be good to point out some of those e-mails.
> Here's a subset of the e-mails that as far as I can have not been
> addressed by the IE Team:
>
>   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0211.html
>   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0212.html
>   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0125.html
>   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0056.html
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>

RE: XHR setting headers

[Sunava Dutta]

>> IMHO we need either removeRequestHeader(), getRequestHeader(), or both.

GetRequestHeader could pose a security risk, because you could then 
GetRequestHeader (Cookie) and steal HTTPOnly cookies.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Julian Reschke
Sent: Thursday, April 17, 2008 6:32 AM
To: Peter Michaux
Cc: public-webapi@w3.org
Subject: Re: XHR setting headers


Peter Michaux wrote:
> The XMLHttpRequest spec says "The setRequestHeader() method appends a
> value if the HTTP header given as argument is already part of the list
> of request headers."
> This is fine but what is a problem is whether or not a new
> XHMHttpRequest object has any default headers. I was trying to use the
> Accept header a few days ago and I wanted to have only
>
> Accept: application/json
>
> but Opera has a default header
>
> Accept: text/html, text/xhtml, etc
>
> so my application/json was appended to the front of that list which
> makes my Accept header useless as part of the client-server
> communication. The server thinks that the client knows what to do with
> text/html. My JavaScript certainly does NOT know what to do with
> text/html. My JavaScript only knows how to handle application/json.
>
> I think all XMLHttpRequest headers should be specified as blank when
> the object is created. Then the JavaScript can add any headers it
> needs to add. If, when the call to send() occurs, some essential
> header(s) is missing the XHMLHttpRequest object should add these
> automatically but only according to specified behavior.

The whole "append" semantics is problematic as long as the user can't
find out what the current value is.

IMHO we need either removeRequestHeader(), getRequestHeader(), or both.

BR, Julian

PS: I may sound like a broken record WRT this, but anyway.

RE: XHR LC Draft Feedback

[Sunava Dutta]

May I also suggest protecting Access-Control-Origin (since it's essentially a 
variant of the referer?).
This is for setRequestHeader of course.

So essentially summarizing my two requests for your convenience.

1.   Mentioning for each header the reasons for restriction. (I think 
security is paramount but for shipped implementations I would hesitate to 
reduce surface area of attack unless there is a compelling reason. It's much 
harder to restrict once we ship!)

2.   Protecting Access-Control-Origin header from being set in XHR.
Cheers and thank you!

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sunava Dutta
Sent: Tuesday, April 15, 2008 2:59 PM
To: Anne van Kesteren
Cc: public-webapi@w3.org; Gideon Cohn; Ahmed Kamel; Zhenbin Xu; Doug Stamper
Subject: XHR LC Draft Feedback

Good to see the draft move to LC.


* Removed dependency on DOM Level 3 Events

* Removed dependency on Window Object 1.0

* Clearly marked which HTTP methods are to raise SECURITY_ERR



Thanks for the changes.




I noticed the draft (http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/) has 
called out the restricted headers. This is great.
Perhaps it would be helpful to mention for each header, why they are 
restricted. It will help developers (and others concerned who are not security 
savvy) understand the security philosophy and also help to ensure that headers 
of equivalent function with different names are also submitted for 
consideration in this blocked list. (I don't have any that comes to mind 
currently).



--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer
One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418
FAX# (425) 936-7329

XHR LC Draft Feedback

[Sunava Dutta]

Good to see the draft move to LC.


* Removed dependency on DOM Level 3 Events

* Removed dependency on Window Object 1.0

* Clearly marked which HTTP methods are to raise SECURITY_ERR



Thanks for the changes.




I noticed the draft (http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/) has 
called out the restricted headers. This is great.
Perhaps it would be helpful to mention for each header, why they are 
restricted. It will help developers (and others concerned who are not security 
savvy) understand the security philosophy and also help to ensure that headers 
of equivalent function with different names are also submitted for 
consideration in this blocked list. (I don't have any that comes to mind 
currently).



--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer
One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418
FAX# (425) 936-7329

RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

[Sunava Dutta]

Agreed. I think it's entirely reasonable to call XDR by its full DOM name, 
XDomainRequest.

-Original Message-
From: Stewart Brodie [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 3:47 AM
To: Sunava Dutta
Cc: Web API WG (public)
Subject: Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE 
Team's Proposal for Cross Site Requests]

Sunava Dutta <[EMAIL PROTECTED]> wrote:

> IE would like to propose XDR as a new (Rec-track) spec for the Web API WG.

Whatever you decide to do, please could you choose a different acronym, as
XDR is already used for encoding in RPC.

--
Stewart Brodie
Software Engineer
ANT Software Limited

RE: Question regarding XDR and https

[Sunava Dutta]

XDR will not participate in HTTPS client authentication, so there is no threat 
here.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hallvord R. M. 
Steen
Sent: Wednesday, March 26, 2008 6:08 PM
To: public-webapi@w3.org
Subject: Question regarding XDR and https


Hi,
I understand that XDomainRequests will omit sending any cookies and
HTTP-Auth to a 3rd party site. However, what happens if the 3rd party site
uses SSL-based authentication instead? For example, my bank uses an SSL
certificate saved in my browser. Can https://attacker.example.com now use
XDR to send POST requests to my bank with my SSL credentials?

If this is the case, I think XDR does increase attack surface compared to
HTML form posts, because many browsers are configured to warn or inform
the users when entering or leaving HTTPS sites. (Most likely everybody on
this list has disabled the warning/information message years ago, but many
average users will still have it enabled.)

--
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience

RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

[Sunava Dutta]

Adding my team back on the thread...

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Wednesday, March 26, 2008 2:22 PM
To: Web API WG (public); [EMAIL PROTECTED]
Subject: RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE 
Team's Proposal for Cross Site Requests]


On Wed, 26 Mar 2008, Sunava Dutta wrote:
>
> IE would like to propose XDR as a new (Rec-track) spec for the Web API
> WG. We think there is a place for both implementations within the
> charter of the Web API.

I think it would be very bad for the Web platform for there to be multiple
ways to achieve this. We need to keep the platform simple, making it more
complicated like this for no extra benefit merely acts as a "divide and
conquer" strategy for proprietary platforms.


> - XDR is provably secure and does not introduce new surface area of
> attack compared to HTML Forms.

This is blatently untrue, a number of serious security problems with XDR
have already been raised (such as the fact that it encourages content-type
sniffing, and the fact that it encourages people to pass their credentials
to untrusted third parties).


> - It's really simple to program against.

IMHO keeping the existing XHR API is far simpler than introducing a
slightly different API that solves nearly the same problem.


> - It accommodates several scenarios around public data aggregation.

It fails to address the majority of use cases for cross-domain data
transfer on the Web.


> - There may be a place for an access control model today, especially
> around RESTful services. The model is extensible and powerful however
> for the draft itself it will need more design thought to build a secure
> implementation.

I disagree, I think XHR and Access Control have been shown to be just as
secure as XDR, possibly more so since they don't require bad security
practices like XDR does.


I strongly object to the Web API working group adopting a proprietary
solution developed by one vendor with no external consultation, when the
group has already spent several man-years' worth of time on a
technologically superior, safer, and more comprehensive solution that has
as much implementation experience and significantly more authoring
experience, based on extending existing APIs instead of arbitarily
introducing new, incompatible APIs.

--
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

[Sunava Dutta]

IE would like to propose XDR as a new (Rec-track) spec for the Web API WG. We 
think there is a place for both implementations within the charter of the Web 
API. Here's a re-summary of why that I've extracted from our proposal and our 
responses. For more details please refer to our proposal and the mail 
conversations on the topic:

- XDR is provably secure and does not introduce new surface area of attack 
compared to HTML Forms.
- It's really simple to program against.
- It accommodates several scenarios around public data aggregation.
- There may be a place for an access control model today, especially around 
RESTful services. The model is extensible and powerful however for the draft 
itself it will need more design thought to build a secure implementation.
- While the existing proposal can do what XDR does and more, it is complicated 
with XHR and also tricky to implement. As we mentioned before, authentication 
scenarios behave differently compared to XHR and so do headers. Editing the 
policy also quickly gets tricky as the number of rules increase. For public 
data aggregation scenarios web developers would benefit from the simple and 
secure XDR object.
If I'm not mistaken this model currently exists within the framework of the W3C 
in the form of the HTML 5.0 DOM Store Spec that's simple and it's bigger 
brother with a larger scope, the SQL based storage.

Along those lines, we are more than glad to pickup editorship here.
Cheers,
-Sunava

-Original Message-
From: Arthur Barstow [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2008 4:52 AM
To: Sunava Dutta
Cc: Web API WG (public); [EMAIL PROTECTED]; Eric Lawrence; Chris Wilson; 
Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's 
Proposal for Cross Site Requests]

[[ My apologies for the late response to this thread (I was OOO last
week). ]]

Sunava, All,

Would you please elaborate on Microsoft's intent with XDR with regard
to W3C? For example is it being proposed as a new (Rec-track) spec
for the Web API WG; is it a counter proposal for the WAF WG's AC4CSR
spec; something else?

Regards, Art Barstow
---


On Mar 13, 2008, at 11:46 PM, ext Sunava Dutta wrote:

> Purpose
>
> XDR helps web developers to create secure mashups, replacing less
> secure or non-performant approaches, including SCRIPT SRC'ing
> content or IFRAME injection.
>
> Microsoft would like to submit XDR to the W3C for standardization
> so that other browsers can benefit from this technology.

RE: XHR tests

[Sunava Dutta]

"> Thanks for going through these Hallvord! Some comments / questons below.
> (Also questions regarding changing XMLHttpRequest. So if the rest of
> the WG could review as well that'd be apprecated.)"

Thanks for making the time to create the tests. I'd love to take a look and 
will review the tests next week.
Cheers,

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hallvord R. M. 
Steen
Sent: Friday, March 21, 2008 3:04 AM
To: Anne van Kesteren; Charles McCathieNevile; Web API WG (public)
Subject: Re: XHR tests


On Mon, 25 Feb 2008 23:56:25 +0900, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:

> Thanks for going through these Hallvord! Some comments / questons below.
> (Also questions regarding changing XMLHttpRequest. So if the rest of the
> WG could review as well that'd be apprecated.)

I second that - more eyes on our tests-in-progress would be good :-)

>>> http://tc.labs.opera.com/apis/XMLHttpRequest/open/016.htm
>>
>> Tests creating an XMLHttpRequest instance, changing the URL of
>> associated document, and loading a relative URL. Assumes that URL
>> should be resolved according to location of original document in said
>> window.
>>
>> Opera 9.5 - fails because it throws INVALID_STATE_ERROR on send()
>> IE7 - fails because it throws on open()
>> Firefox 2 - fails because it throws on open()
>> Safari (version 3 on Windows btw) - fails because it fails to load the
>> new document when location is set (!??)
>>
>>> http://tc.labs.opera.com/apis/XMLHttpRequest/open/024.htm
>>
>> Same results as 016.htm
>
> These probably fail because everyone resolves URIs in different ways.
> The specification defines a clear way to do this, but if there is a
> better alternative I'm open to suggestions.

Personally I think throwing is quite a natural thing to do in this
condition (the document/URL of window has changed since the XHR object was
created) and when 3 out of 4 major implementations already do so we
probably don't introduce compat problems by specifying that.


>>> http://tc.labs.opera.com/apis/XMLHttpRequest/open/031.htm
>>
>> Tests creating an XHR instance from the XMLHttpRequest object of an
>> IFRAME, removing the IFRAME from the DOM, adding a BASE href element
>> with DOM methods to the document in the removed IFRAME, and using the
>> XHR instance. (Anne getting rather creative/evil here :-) )
>>
>> IE7 - my IE7 actually says pass here!
>> Opera / Safari / Firefox: all three kill the script environment of the
>> window object when the IFRAME is removed from the DOM. Hence trying to
>> add BASE href throws and the test says failed.
>>
>> When to kill and garbage collect the script environment inside the
>> IFRAME when it's removed from DOM is obviously not the XHR spec's
>> business. I suggest this test is relaxed to accept several
>> implementation choices, either shutting down the script environment and
>> resolving URL by original IFRAME src or doing whatever IE does. We
>> should have a corresponding evil security test or two checking that
>> removing the IFRAME won't confuse the browser into allowing x-domain
>> requests it shouldn't.
>
> I rather liked the behavior of Internet Explorer 7.

I still think we can't make implementations rewire their garbage
collection to pass an extreme corner case test. This sort of stuff simply
should not be specified here. :-p

> Changing this would require some rewording of the definition of document
> pointer in section 4 probably:
>
>http://dev.w3.org/2006/webapi/XMLHttpRequest/#xmlhttprequest
>
> If we want that suggestions are welcome.

What about just throwing if the associated window is closed or removed
 from the DOM?


--
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience

RE: IE Team's Proposal for Cross Site Requests

[Sunava Dutta]

Maciej Stachowiak [EMAIL PROTECTED] said:
<>

You're right-- setting an arbitrary request content-type is a capability not 
present in HTML forms today.  While we believe that this is a minimal increase 
in attack surface, we agree that it's worth considering whether or not such 
capability should be removed.

If removed, all XDR POST requests could be sent with:

Content-Type: text/plain; charset=UTF-8

Servers would then be flexible in interpreting the data in the higher-level 
format they expect (JSON, XML, etc).

Maciej Stachowiak [EMAIL PROTECTED] asked:
<>

We believe that the XDR proposal represents a simpler mechanism for enabling 
the most commonly requested types of cross-domain access.  We believe that such 
simplicity will lead to improved security in practical implementations by 
browsers.

There are many threats against a cross-domain communication mechanism, so we 
believe the simplicity of XDR makes it more suitable than attempting to plumb 
cross-domain capabilities into the existing XHR object.  In particular, we are 
concerned that attempting to introduce new restrictions/added complexity on an 
XHR object when it is used in a cross-domain manner will result in a confusing 
programming model for the web developer.


-Original Message-
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 15, 2008 1:23 PM
To: Eric Lawrence
Cc: Web API WG (public); [EMAIL PROTECTED]; Sunava Dutta; Chris Wilson; Zhenbin 
Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: Re: IE Team's Proposal for Cross Site Requests


On Mar 14, 2008, at 4:59 PM, Eric Lawrence wrote:

>
> =
>
> Maciej Stachowiak [EMAIL PROTECTED] asked:
> < XMLHttpRequest standard that is being developed by Web API and Web
> App Formats (and as implemented in Firefox betas)? From Apple's
> point of view we would like to have a unified standard in this area.>>
>
> We believe that the XDR proposal exposes a smaller surface of attack
> than the Cross-Site extensions for XHR.  Specifically, it can be
> demonstrated that the capabilities exposed by XDR are virtually
> identical to the capabilities exposed by existing HTML tags.  The
> one exception (obviously) is that the XDR object allows examination
> of response bodies cross-domain if and only if the server explicitly
> indicates that such access is permissible via the
> XDomainRequestAllowed header.

But not exactly identical, since forms can't be used to POST XML
content with a proper MIME type cross-domain. This is actually more
restricted in XHR2+AC.

> =
>
> Maciej Stachowiak [EMAIL PROTECTED] asked, in part:
> < some other method can do anything that you can't do with a cross-
> domain form submission. You can set custom headers, but that seems
> unlikely to make the difference between safe and unsafe.>>
>
> It's certainly a possibility.  For instance, consider a device which
> accepts SOAP XML as input  The designers of the device were wise to
> note that a cross-domain form submission could be made (encType =
> text/plain) that contains XML-formatted content, and thus they
> devised an anti-CSRF mechanism of rejecting requests that do not
> bear a proper SOAPAction header.  Such restriction properly blocks
> CSRF via HTML forms, but is put at risk if a cross-domain XHR
> request is able to send arbitrary headers.

On the other hand, if the anti-CSRF mechanism were checking for a
proper XML Content-Type instead of looking for a SOAPAction header,
XDR would be more vulnerable than XHR2+AC. If the server also checks
the Host header, then XHR2+AC would be completely safe (since no DNS
rebinding attack is then possible).

In any case, it seems like this could be addressed through a strict
whitelist of allowed request headers, including such critical headers
as Accept and Accept-Language but ruling out SOAPAction. Or XHR2+AC
could even block all custom headers on cross-site requests. Let's take
that point as negotiable. Allowed methods are also a negotiable point.
These issues both address what may be customized on the request, but
the most obvious incompatibilities between XDomainRequest and XHR2+AC
are the API and protocol.

What I'd like to understand is whether there are security benefits to
the API and protocol differences. Or if not, if there is any other
reason to prefer the Microsoft-proposed API and protocol to the
current draft standards. Can anyone from Microsoft address that point?

Regards,
Maciej

RE: IE Team's Proposal for Cross Site Requests

[Sunava Dutta]

Sure Doug. Will try to get this out to you in the mentioned format asap.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Schepers
Sent: Friday, March 14, 2008 4:37 AM
To: Web API WG (public)
Subject: Re: IE Team's Proposal for Cross Site Requests


Hi, Sunava-

Could you please resend this as an HTML attachment, rather than as the
body of the email?  Many people use text-based email clients (I myself
normally view emails as text-only, though I can switch on HTML), making
this very hard to read.  It also looks crummy in the archives:

   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0096.html

Thanks-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

RE: Extra Connection Support Proposal

[Sunava Dutta]

As Anne says, I think this would be better is it would be scoped to more than 
just XHR.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anne van Kesteren
Sent: Wednesday, February 27, 2008 3:02 PM
To: Kris Zyp; Jonas Sicking; Kris Zyp
Cc: Stewart Brodie; Web API WG (public)
Subject: Re: Extra Connection Support Proposal


On Wed, 27 Feb 2008 23:48:47 +0100, Kris Zyp <[EMAIL PROTECTED]> wrote:
> I am going to send out another proposal that will hopefully be more
> palatable/feasible.

I don't want this in XMLHttpRequest. It makes no sense that only
XMLHttpRequest would benefit from this. That doesn't help , lots of
external style sheets, images, etc. We need something helps all those APIs.


--
Anne van Kesteren

RE: [XHR] Editorial - labelling sections

[Sunava Dutta]

That would definitely improve readability for us (IE Team) as well.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles 
McCathieNevile
Sent: Tuesday, February 12, 2008 11:02 AM
To: Web API WG (public)
Subject: [XHR] Editorial - labelling sections


Hi All,

working through the first test case I looked at, sections of the document
seem to be quite large. I believe it would be helpful if there were a more
granular breakdown of sections, and a more detailed table of contents, in
order to refer in more detail to important parts of the spec.

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
 je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

RE: IE Team's Feedback on the XHR Draft

[Sunava Dutta]

That is correct. Thanks Hallvord!

-Original Message-
From: Hallvord R. M. Steen [mailto:[EMAIL PROTECTED]
Sent: Monday, February 11, 2008 12:18 PM
To: Charles McCathieNevile; Sunava Dutta; Chris Wilson
Cc: public-webapi@w3.org; Gideon Cohn; Zhenbin Xu; Marc Silbey; Ahmed Kamel
Subject: Re: IE Team's Feedback on the XHR Draft

On Sat, 09 Feb 2008 11:37:17 +0100, Charles McCathieNevile
<[EMAIL PROTECTED]> wrote:

>>  Would it be possible once the tests are relatively stable to package
>> them (including reference files) and send us a copy?

>  We will have them on the Web - you have to fetch your own copy

That's a quite legitimate question because there are some server-side
scripts there. I assume this was what Sunava meant by talking about
inaccessible resource files earlier (to the best of my knowledge none of
the tests rely on hard-coded URLs to Opera's intranet or nonsense like
that!).

It's not possible to access the SVN repository for those tests
anonymously, is it?

--
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience

RE: IE Team's Feedback on the XHR Draft

[Sunava Dutta]

-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles 
McCathieNevile
Sent: Friday, February 08, 2008 12:03 PM
To: Chris Wilson
Cc: Sunava Dutta; public-webapi@w3.org; Gideon Cohn; Zhenbin Xu; Marc Silbey; 
Ahmed Kamel
Subject: Re: IE Team's Feedback on the XHR Draft


On Fri, 08 Feb 2008 22:22:59 +0530, Chris Wilson
<[EMAIL PROTECTED]> wrote:

> I think there are a few misconceptions about Sunava's feedback.
>
> 1) In NO WAY do we want the specification to be less detailed.  MORE
> detailed, if anything.

Yeah, we cleared that up at the technical plenary in my mind.

> 2) In fact, on that note, we're interested to see the test suite be
> linked, normatively if necessary.

Yes. I think this is a valuable piece of feedback. Currently W3C process
doesn't require test suites until you're trying to get out of CR and I
think it would be better to have them earlier.

> 3) we are not intending to block last call, and we understand the
> Process.  Sunava had promised to send comments, and has done so.  We
> would still like to see these comments addressed in the specification,
> and not simply dismissed; whether that is prior to or post LC is not, I
> think, that important.

OK, thanks. I have no intention of simply having comments dismissed. I
have held the last call question open to allow for a sensible discussion.

What I am thinking now is that we should check whether there are
substantive comments that need to be addressed before LC (on my first
reading I don't think so), and continue pretty fast to last call. I would
like the group to start checking the test cases we have against the spec
and formally agreeing them to facilitate this linkage during last call. It
slows down the LC period, but it should make CR easier and reduce the
possibility of reverting from CR.

How do people feel about that as an approach?

Finally, on the question of what we agreed at the technical plenary, the
minutes do not reflect any resolution that we agreed we would make a spec
that is 100% compatible with IE - as Anne, Jonas and Maciej pointed out we
started out working from existing implementation including IE and trying
to make a spec that is as backwards compatible as possible, but that is
*a* goal not the driving requirement.

Naturally any specific requests for technical changes are welcome either
now or during Last Call, and will be considered on their merits. We had
hoped that any such comments would have come in already but one of the
reasons for going to last call when we have run out of comments at normal
working draft is to elicit any outstanding issues.

So I plan to give it a few days (I am only partly available over the next
few days, in India, Poland, Spain, Norway in the next week) and then I'll
propose a formal consensus call on a way forward - based on the above
thoughts and comments here over the next week.

cheers

Chaals

> -Original Message-
> From: Doug Schepers [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 08, 2008 1:54 AM
> To: Maciej Stachowiak
> Cc: Anne van Kesteren; Sunava Dutta; public-webapi@w3.org; Gideon Cohn;
> Zhenbin Xu; Chris Wilson; Marc Silbey; Ahmed Kamel
> Subject: Re: IE Team's Feedback on the XHR Draft
>
> Hi, Folks-
>
> To be clear, I'm not critiquing the spec itself, or advocating any
> specific action.  Rather, I'm trying to manage expectations and ensure
> that the various participants of this WG can work smoothly with one
> another.  I'm acting purely as a Process wonk here.
>
> Sunava, as you see, there is considerable, and reasonable, incentive to
> make the XHR spec as detailed as possible, even where it may not match
> the IE implementation precisely.  Maciej's request for more specific
> details on potential conflicts (in implementations or content) is
> appropriate, I think.
>
> I don't know if you are familiar with the W3C Recommendation Track [1],
> so briefly, you should know that LC (Last Call) is not the end of the
> process.  It simply indicates that the specification is believed to have
> satisfied its technical requirements; it's not considered stable enough
> for implementation, and in practice, this is when most comments are made.
>
> Thus, I see little harm in advancing to LC, since you will still have an
> opportunity to submit additional technical comments.
>
> [1] http://www.w3.org/2005/10/Process-20051014/tr
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG, CDF, and WebAPI



--
Charles McCathieNevile  Opera Software, Standards Group
 je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

IE Team's Feedback on the XHR Draft

[Sunava Dutta]

t; to 
"null", the error 
flag<http://dev.w3.org/2006/webapi/XMLHttpRequest/#error-flag> to "true" and 
reset the list of request headers.

2.  Synchronously switch the state to 
DONE<http://dev.w3.org/2006/webapi/XMLHttpRequest/#done-state>.

3.  If async is set to false raise an 
ABORT_ERR<http://dev.w3.org/2006/webapi/XMLHttpRequest/#abort-err> exception 
and terminate the overall algorithm.

4.  Synchronously dispatch a 
readystatechange<http://dev.w3.org/2006/webapi/XMLHttpRequest/#readystatechange>
 event on the object.

5.  Terminate the overall algorithm.


·Please link conformance test suite to an appendix/bottom of 
specification.

o   The spec is very detailed and the tests are difficult to correlate to exact 
sections of the spec. I think that's understandable at this stage since the 
spec is in flux. We think the official test suite deserves to be called out; 
linking the tests to the spec will ensure that this is the official test.

o   As per our agreement in the tech plenary the spec will conform to IE's 
implementation of XHR (with the exception of constants) and will be changed 
accordingly. The tests are important for us and other UAs as it's the guarantor 
of that.

§  If there is no Content-Type header or there is a Content-Type header which 
contains a MIME type that is text/xml, application/xml or ends in +xml 
(ignoring any parameters) use the rules set forth in the XML specifications to 
determine the character encoding. Let charset be the determined character 
encoding.

·Other observations from the spec

o   Is this included due to security concerns?

§  Scripts in the resulting document tree will not be executed, resources 
referenced will not be loaded and no associated XSLT will be applied.

·It's not clear what the end result is we're trying to achieve with the 
following is. Can we clarify?



§  The associated Document object is the one returned by the document attribute 
from the object on which the XMLHttpRequest() constructor was invoked (a Window 
object).

o   Is it:

§  When invoking a new XHR object, tie new object to the window its associated 
with?

§  User agents should persist document pointers to the newly created XHR object?

·Why is this in the open method section of the specification? I 
recommend the spec does not mention this; if it does, we should talk about "the 
future" in a separate section.

o   A future version or extension of this specification will most likely define 
a way of doing cross-site requests.

o   It is likely that a future version of the 
XMLHttpRequest<http://dev.w3.org/2006/webapi/XMLHttpRequest/#xmlhttprequest-object>
 object will dispatch an error event here as well

o   It is likely that a future version of the 
XMLHttpRequest<http://dev.w3.org/2006/webapi/XMLHttpRequest/#xmlhttprequest-object>
 object will dispatch an abort event here as well.




--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer
One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418
FAX# (425) 936-7329

XHR Draft Compliance Test Cases

[Sunava Dutta]

Hello Anne,
Gideon's going to run the test cases to validate IE7's compliance with the XHR 
draft so that we can align the draft better with the implementation as 
discussed in the Tech Plenary. He's got a few questions on running the test 
cases, accessed here http://tc.labs.opera.com/apis/XMLHttpRequest/.
Adding him and starting a thread so he can communicate with you directly.
Cheers,

--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer
One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418
FAX# (425) 936-7329

FW: Feedback from the IE Team: Web API XHR Draft

[Sunava Dutta]

Re-summarizing the points of our feedback regarding the XHR draft for the 
public list.

*Interoperability/Compatibility for v1 spec for XHR is critical if the 
spec is to achieve consensus.  XHR was first implemented a decade ago, and a 
huge amount of existing content relies upon the stability of the existing 
implementation.  The v1 XHR spec should seek to ensure interoperability between 
the existing client implementations and the deployed base of content.

*All new functionality/features should be specified in a new Level of 
the XHR specification. This will permit developers the freedom that comes with 
a new object without the risk of incompatibility with the hundreds of millions 
of existing browsers that implement XHR today. As you know, the purpose of 
versioning is to guarantee this compatibility while ensuring that innovation 
can proceed without risk.  This reminds me of the DOM L1 vs DOM L0, where the 
DOM L1 spec was engineering to include all new functionality over the DOM L0 
which was assumed to be baseline interoperable across browsers.

*The thread below has more details and specific instances.
Thanks!


From: Sunava Dutta
Sent: Tuesday, August 28, 2007 4:20 PM
To: Anne van Kesteren
Cc: Chris Wilson; Cyra Richardson; Doug Stamper; Zhenbin Xu; Levent Besik; Eric 
Lawrence; Marc Silbey
Subject: Feedback from the IE Team: Web API XHR Draft


Hello Anne,

I've taken a pass at the spec and have a few comments below...



*As you can imagine, we have a huge commitments to developers who build 
on IE and maintain legacy sites on IE. Compatibility consequently is not 
optional for us. We can't break existing compat. The object in its current form 
has been out there for years, is very widely deployed and browsers like FF 
model our implementation.

o   The challenge arising from the existing draft comes in the level of detail 
defined in the spec. For example, a number of algorithms specified in the spec 
(such as that for the open call) do not allow for accommodating different UA's. 
For a new specification this would be great. For a spec that is based on 
existing technology that's widely implemented around IE's behavior this is a 
challenge since IE does not adhere to the algorithm.

o   The spec specifies the table of the errors that should be returned and the 
exact text and type of the errors. The types and text of errors inherit from 
other W3C specs that we don't support. We return our own errors here that do 
not match syntactically the errors the W3C defines although they are thrown for 
the same events. Specifying the exact text of the error is not recommended.

o   If we were to make changes (not possible)  we would still leave web 
developers maintaining the majority of sites out there with the legacy XHR 
that's compatible with IE while trying to support the new one creating 
manageability problems.

oOur testing load to simply verify compliance to the W3C draft is too great 
given the level of detail, the stability of our implementation and the fact 
that the draft is a moving target.

o   The ask here is the level of granularity/ and specificity be reduced. It's 
currently too authoritative in depth. We had signed off on your draft last 
year. This was mostly compatible with IE and FF while being helpful for web 
developers. A simple description of the open call and the types of parameters 
allowed, including which ones are optional would be great.

*The current draft introduces new entities to the object. We're ok with 
creating a new object (or versioned XHR object) in order to ensure that the 
standards can advance. However, a vast majority of developers will not be able 
to reliably use this as the millions of pages build around current IE XHR will 
not support them. This consequently will be a adoption blocker for the standard.

o   Ensure all new entities like constants, flags etc are versioned or in a new 
object.

*The draft frequently cross references specifications in the W3C.For 
example, the spec makes references to the DOM 3 events and core, namespaces in 
XML, Window Object 1.0 etc (Some of which are drafts themselves). We fail to 
see the value in implicitly embedding other large specs. Simplicity and 
standing on its own would be good.





http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8#text-response-entity-body


--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer
One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418
FAX# (425) 936-7329

RE: XMLHttpRequest for Last Call

[Sunava Dutta]

Hello Julian,
We do currently support all WebDAV HTTP verbs from RFC2518.

PROPFIND
PROPPATCH
MKCOL
GET
HEAD
POST
DELETE
PUT
COPY
MOVE
LOCK
UNLOCK

And also OPTIONS.

Details available here:
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml
/reference/objects/obj_xmlhttprequest.asp

Thanks!


-Original Message-
From: Julian Reschke [mailto:[EMAIL PROTECTED] 
Sent: Sunday, February 18, 2007 2:07 PM
To: Sunava Dutta
Cc: Web API WG (public); Zhenbin Xu
Subject: Re: XMLHttpRequest for Last Call

Sunava Dutta schrieb:
> 
> This is fantastic, we took a look at the working draft and it looks
great.
> The IE team's looking forward to seeing it published!

Good to hear.

Are you actually planning to implement it? Such as support for WebDAV 
method names? (remember that's a SHOULD-level requirement).

Best regards, Julian

RE: XMLHttpRequest for Last Call

[Sunava Dutta]

This is fantastic, we took a look at the working draft and it looks great.
The IE team's looking forward to seeing it published!



From: [EMAIL PROTECTED] on behalf of Anne van Kesteren
Sent: Tue 2/13/2007 1:41 AM
To: Web API WG (public)
Cc: Web API WG
Subject: XMLHttpRequest for Last Call




Hi,

I suggest we publish 
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8
 

  
as Last Call Working Draft by next Monday. If you have any objections 
please post them to the public list.

(Please remove the member list on follow-up e-mail.)

Cheers,


--
Anne van Kesteren