XMLHttpRequest for Last Call

[Anne van Kesteren]

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

Re: XMLHttpRequest for Last Call

[Doug Schepers]

Hi-

I think we should rename it ".getOrPostRemoteContentByHttp()".

Ok, just kidding.

But I did want to remind you to take out the following:

"Implementors should be aware that this specification is not stable. 
Implementors who are not taking part in the discussions are likely to 
find the specification changing out from under them in incompatible 
ways. Vendors interested in implementing this specification before it 
eventually reaches the Candidate Recommendation stage should join the 
aforementioned mailing list and take part in the discussions."


-Doug


Anne van Kesteren wrote:


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







--

Regards-
-Doug

Re: XMLHttpRequest for Last Call

[Julian Reschke]

Anne van Kesteren schrieb:


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,


I think the spec needs to be carefully checked for usage of 
RFC2119/BCP14 terminology. For instance 
():


"For security reasons nothing SHOULD be done if the header argument 
matches one of the following headers case-insensitively:"


I think I understand what the intent is, but maybe it should be 
rephrased to:


"For security reasons, a server SHOULD ignore any attempt to modify any 
of the headers below (header names being matched case-insensitively):"


Best regards, Julian

Re: XMLHttpRequest for Last Call

[Anne van Kesteren]

On Tue, 13 Feb 2007 16:59:12 +0100, Julian Reschke <[EMAIL PROTECTED]>  
wrote:
I think the spec needs to be carefully checked for usage of  
RFC2119/BCP14 terminology. For instance  
():


"For security reasons nothing SHOULD be done if the header argument  
matches one of the following headers case-insensitively:"


I think I understand what the intent is, but maybe it should be  
rephrased to:


"For security reasons, a server SHOULD ignore any attempt to modify any  
of the headers below (header names being matched case-insensitively):"


I don't understand this suggestion. Are you sure you understand what the  
section is about?



--
Anne van Kesteren

Re: XMLHttpRequest for Last Call

[Julian Reschke]

Anne van Kesteren schrieb:
On Tue, 13 Feb 2007 16:59:12 +0100, Julian Reschke 
<[EMAIL PROTECTED]> wrote:
I think the spec needs to be carefully checked for usage of 
RFC2119/BCP14 terminology. For instance 
(): 



"For security reasons nothing SHOULD be done if the header argument 
matches one of the following headers case-insensitively:"


I think I understand what the intent is, but maybe it should be 
rephrased to:


"For security reasons, a server SHOULD ignore any attempt to modify 
any of the headers below (header names being matched 
case-insensitively):"


I don't understand this suggestion. Are you sure you understand what the 
section is about?


Yes. The problem is the spec saying "...nothing SHOULD be done...". I 
think it's better to be explicit what the implementation should do (in 
this case, ignore the method call).


Best regards, Julian

Re: XMLHttpRequest for Last Call

[Julian Reschke]

Maciej Stachowiak schrieb:
Yes. The problem is the spec saying "...nothing SHOULD be done...". I 
think it's better to be explicit what the implementation should do (in 
this case, ignore the method call).


I agree that using active voice is better than using passive voice, but 
there are no requirements being imposed on the server here (wouldn't 
make sense for XMLHttpRequest to do that).


Yep, sorry. I spent so much time specifying server behavior that is 
automatically slipped into. So...:


"For security reasons, *an implementation* SHOULD ignore any attempt to 
modify any of the headers below (header names being matched 
case-insensitively):"


Best regards, Julian

Re: XMLHttpRequest for Last Call

[Anne van Kesteren]

On Tue, 13 Feb 2007 17:11:03 +0100, Julian Reschke <[EMAIL PROTECTED]>  
wrote:
Yes. The problem is the spec saying "...nothing SHOULD be done...". I  
think it's better to be explicit what the implementation should do (in  
this case, ignore the method call).


Oh, ok. It wasn't clear to me what you meant. (I thought it was a comment  
about not mentioning "server".)


Changed to:

  For security reasons the invocation SHOULD be ignored
  if the header argument matches one of the following
  headers case-insensitively:


--
Anne van Kesteren

Re: XMLHttpRequest for Last Call

[Julian Reschke]

Anne van Kesteren schrieb:
On Tue, 13 Feb 2007 17:11:03 +0100, Julian Reschke 
<[EMAIL PROTECTED]> wrote:
Yes. The problem is the spec saying "...nothing SHOULD be done...". I 
think it's better to be explicit what the implementation should do (in 
this case, ignore the method call).


Oh, ok. It wasn't clear to me what you meant. (I thought it was a 
comment about not mentioning "server".)


Changed to:

  For security reasons the invocation SHOULD be ignored
  if the header argument matches one of the following
  headers case-insensitively:


Yes. Much better.

Best regards, Julian

Re: XMLHttpRequest for Last Call

[Anne van Kesteren]

On Tue, 13 Feb 2007 15:21:26 +0100, Doug Schepers <[EMAIL PROTECTED]> wrote:

But I did want to remind you to take out the following:

"Implementors should be aware that this specification is not stable.  
Implementors who are not taking part in the discussions are likely to  
find the specification changing out from under them in incompatible  
ways. Vendors interested in implementing this specification before it  
eventually reaches the Candidate Recommendation stage should join the  
aforementioned mailing list and take part in the discussions."


Removed this. Still need to update the SotD a bit more I think.


--
Anne van Kesteren

Re: XMLHttpRequest for Last Call

[Maciej Stachowiak]

On Feb 13, 2007, at 8:11 AM, Julian Reschke wrote:



Anne van Kesteren schrieb:
On Tue, 13 Feb 2007 16:59:12 +0100, Julian Reschke  
<[EMAIL PROTECTED]> wrote:
I think the spec needs to be carefully checked for usage of  
RFC2119/BCP14 terminology. For instance ():


"For security reasons nothing SHOULD be done if the header  
argument matches one of the following headers case-insensitively:"


I think I understand what the intent is, but maybe it should be  
rephrased to:


"For security reasons, a server SHOULD ignore any attempt to  
modify any of the headers below (header names being matched case- 
insensitively):"
I don't understand this suggestion. Are you sure you understand  
what the section is about?


Yes. The problem is the spec saying "...nothing SHOULD be done...".  
I think it's better to be explicit what the implementation should  
do (in this case, ignore the method call).


I agree that using active voice is better than using passive voice,  
but there are no requirements being imposed on the server here  
(wouldn't make sense for XMLHttpRequest to do that).


 - Maciej

Re: XMLHttpRequest for Last Call

[Robert Sayre]

On 2/13/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

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.


Where do the requirements for the username and password productions
come from? Is there an old list discussion on them?

--

Robert Sayre

Re: XMLHttpRequest for Last Call

[Anne van Kesteren]

On Sat, 17 Feb 2007 21:15:04 +0100, Robert Sayre <[EMAIL PROTECTED]> wrote:

Where do the requirements for the username and password productions
come from? Is there an old list discussion on them?


Mainly offlist feedback. There's been some discussion (on list) on the  
userinfo production though if you are referring to that:


  http://www.google.com/search?q=inurl:public-webapi+userinfo


--
Anne van Kesteren

Re: XMLHttpRequest for Last Call

[Robert Sayre]

On 2/17/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

On Sat, 17 Feb 2007 21:15:04 +0100, Robert Sayre <[EMAIL PROTECTED]> wrote:
> Where do the requirements for the username and password productions
> come from? Is there an old list discussion on them?

Mainly offlist feedback. There's been some discussion (on list) on the
userinfo production though if you are referring to that:

   http://www.google.com/search?q=inurl:public-webapi+userinfo


OK. AFAIK, Basic and Digest are not interoperable outside of ASCII,
and this specification provides no guidance on the encoding of the
credentials. Is there anything useful we can say here? Maybe just warn
that it isn't internationalized?

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Re: XMLHttpRequest for Last Call

[Anne van Kesteren]

On Sat, 17 Feb 2007 21:27:53 +0100, Robert Sayre <[EMAIL PROTECTED]> wrote:

OK. AFAIK, Basic and Digest are not interoperable outside of ASCII,
and this specification provides no guidance on the encoding of the
credentials. Is there anything useful we can say here? Maybe just warn
that it isn't internationalized?


That or we require a specific encoding, such as UTF-8. Anyone with an  
opinion on that?



--
Anne van Kesteren

Re: XMLHttpRequest for Last Call

[Bjoern Hoehrmann]

* Anne van Kesteren wrote:
>On Sat, 17 Feb 2007 21:27:53 +0100, Robert Sayre <[EMAIL PROTECTED]> wrote:
>> OK. AFAIK, Basic and Digest are not interoperable outside of ASCII,
>> and this specification provides no guidance on the encoding of the
>> credentials. Is there anything useful we can say here? Maybe just warn
>> that it isn't internationalized?
>
>That or we require a specific encoding, such as UTF-8. Anyone with an  
>opinion on that?

It is reasonable to recommend use of UTF-8 if the authentication scheme
can make use of the user name and password specified by the programmer,
and the specification of the scheme fails to define how character to
byte string conversion is supposed to happen. If, however, this is well-
defined for the scheme, XHR must not contradict other specifications and
it seems unwise to require use of UTF-8 if that contradicts deployed im-
plementations, in particular for schemes besides Basic and Digest.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

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
 
<http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=iso-8859-1>
  
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
<http://annevankesteren.nl/>
<http://www.opera.com/>

Re: XMLHttpRequest for Last Call

[Julian Reschke]

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]

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

[Julian Reschke]

Sunava Dutta schrieb:

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


It's nice to know that you (know) allow the methods that you implement 
in Microsoft products. But what about other methods specified in IETF 
RFCs (RFC3253, RFC3648, RFC3744, ...) -- not invented here, thus evil? 
They (still) do not work. What's the point in putting known methods into 
a white list? By definition, POST is the most insecure methods because 
it can do *anything*, so why restrict anything at all if you allow POST?


Best regards, Julian

Re: XMLHttpRequest for Last Call

[William J. Edney]

Hi Sunava -

It should be made clear that these methods work *only* with IE's  
'ActiveX' http object. The new built-in IE7 'native XMLHttpRequest'  
object has the following restrictions, according to the Microsoft  
website:


- Limited to GET, POST and HEAD HTTP verbs
- Limited to http:// or https:// protocols
- Limited to same port, host and domain

Cheers,

- Bill

William J. Edney
Team TIBET

On Feb 26, 2007, at 4:43 PM, Sunava Dutta wrote:



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





!DSPAM:45e362fa94931240465853!


William J. Edney
Product Evangelist, Team TIBET
[EMAIL PROTECTED]
314.757.9200

Re: XMLHttpRequest for Last Call

[Julian Reschke]

William J. Edney schrieb:

Hi Sunava -

It should be made clear that these methods work *only* with IE's 
'ActiveX' http object. The new built-in IE7 'native XMLHttpRequest' 


That's why I raised a bug report calling that a regression 
(, 
not offline...)



object has the following restrictions, according to the Microsoft website:

- Limited to GET, POST and HEAD HTTP verbs
- Limited to http:// or https:// protocols
- Limited to same port, host and domain

Cheers,

- Bill


Well, even that information is incorrect - PROPFIND works (see 
).


Best regards, Julian

Re: XMLHttpRequest for Last Call

[William J. Edney]

Sunava -

My bad. I could've sworn there was a page that mentioned that the  
native object only supported GET, POST and HEAD. This would've been  
around August time frame. Did this get changed before the final  
release of IE7? I guess I'm just getting old :-).


Note that the Microsoft page describing the call does have the words  
'subset of HTTP verbs', but I guess from that its talking about the  
lack of support for CONNECT and TRACE.


Thanks for taking the time to respond.

Cheers,

- Bill


On Feb 27, 2007, at 2:52 PM, Sunava Dutta wrote:


Hello William,

Which site are you referring to? I’ll take a look and verify.

The information is incorrect.



From: William J. Edney [mailto:[EMAIL PROTECTED]
Sent: Monday, February 26, 2007 4:35 PM
To: Sunava Dutta
Cc: [EMAIL PROTECTED]; public-webapi@w3.org
Subject: Re: XMLHttpRequest for Last Call



Hi Sunava -



It should be made clear that these methods work *only* with IE's  
'ActiveX' http object. The new built-in IE7 'native XMLHttpRequest'  
object has the following restrictions, according to the Microsoft  
website:




- Limited to GET, POST and HEAD HTTP verbs

- Limited to http:// or https:// protocols

- Limited to same port, host and domain



Cheers,



- Bill



William J. Edney

Team TIBET



On Feb 26, 2007, at 4:43 PM, Sunava Dutta wrote:






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














William J. Edney

Product Evangelist, Team TIBET

[EMAIL PROTECTED]

314.757.9200








!DSPAM:45e49ab7198847269712395!


William J. Edney
Product Evangelist, Team TIBET
[EMAIL PROTECTED]
314.757.9200