<dino> Robin Berjon, Expway
<dino> Mark Baker, RIM
<dino> Gorm Eriksen, Opera
<dino> Arun Ranganathan, AOL
<dino> Dan Zucker, Access (Observer)
<dino> Anne van Kesteren, Opera
<dino> Ian Hickson, Google
<dino> Jonas Sicking, Mozilla
<dino> Dean Jackson, W3C
<dino> Mark Nottingham, Yahoo (Observer)
<dino> Dave Massy, Microsoft (Observer)
<dino> Doug Schepers, Vectoreal
<dino> MN: Anything an observer says that may be taken as a contribution to the WG should be considered possibly tainted by IP.
<dino> RB: Otherwise, we encourage our observers to participate as regular attendees. Please speak freely.
<dino> Scribe: Dean
<darobin> http://www.w3.org/mid/op.s8u24ix564w2qv@id-c0020.lan
RB: Is that a complete list of issues?
<anne> Current draft: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/publish/XMLHttpRequest.html?content-type=text/html;%20charset=utf-8
AvK: Nearly. There are some issues in the draft as well. The spec in CVS is pretty much up to date. MarkN raised some issues as well - I'm not sure if they are in my list.
1. Introduction
AvK: I moved some stuff out of there into acknowledgements. I'll add a History section as well. I propose the Intoduction is for technology only.
<darobin> RESOLUTION: have a history section
<scribe> ACTION: Dean to reorganise the Introduction/History of XHR
<trackbot> Created ACTION-135 - Reorganise the Introduction/History of XHR [on Dean Jackson - due 2006-05-08].
2. Resolving URIs in multiple windows
AvK: Against what do you resolve URIs? document.baseURI or window.location.href? Which window?
JS: The Window spec says it only has one document object. I think this will have to be the resolution.
RB: Does anyone want multiple documents objects on a Window?
<arun> (resounding no)
Everyone: No.
RB: Does this mean we can use document.baseURI?
AvK: Not sure what happens when you create it in one document and use it in another.
JS: I wrote some test cases - sent to public list.
DS: What is the use case for doing this?
RB: There may not be a use case, just that it is possible.
<darobin> http://www.w3.org/mid/441E69F1.2030709@sicking.cc
JS: You'd &btw; otherwise.
<darobin> the zip is at http://lists.w3.org/Archives/Public/public-webapi/2006Mar/att-0224/openresolve.zip
I hereby define &btw; to be "break the Web"
<bjoern> we should really have xhr.domConfig.baseURI, which is initialized at creation time. resolution is then based on that property...
JS: [explains how Mozilla code works it out]
RB/AvK: Safari and Mozilla and Opera return the same results on Jonas's tests.
<Hixie> http://damowmow.com/playground/tests/xmlhttprequest/openresolve/outer.html
<Hixie> IE6b2: 6:inner, 1:inner, 2:outer, 3:outer, 4:inner, 5:outer
<bjoern> 6 Beta 2?
<Hixie> IE7B2
<mjs> I get 6 inner, 1-5 outer
JS: I'm surprised that other browsers do what we do. We resolve the URI at the time open() is called.
... ....... maybe. It's hard to tell.
<mjs> in Safari we copied mozilla's URI resolution on purpose
<mjs> and it also seemed to match other cases like assigning window.location
<Hixie> can you describe what the algorithm is?
DJ: browsers differ on 1 and 4
<Hixie> mozila does: 6:inner, 1:outer, 2:outer, 3:outer, 4:outer, 5:outer
<gorm> Oprea: 6 inner, 1 outer, 2 outer, 3 outer, 4 outer, 5 outer
JS: test 1 is Document A calling a function on Document B, which does all the work.
... In this case we should use the function at the bottom of the call stack, rather than the top. A function should be the same regardless of who calls it.
... Test 4 uses the constructor from the inner window. Everything else is called in the outer.
<Hixie> what i would want: 6:inner, 1: inner, 2:inner, 3:outer, 4:outer, 5:inner
RB: So IE uses the context in which it was created. Which makes sense.
JS: I agree. What IE does makes more sense.
RB: Will other browsers update their code to match this if we change?
AvK: Opera will.
IH: I'd prefer to use the context wherever open() is called.
JS: The proposal is to use whichever constructor is called, not where it is called.
... window.document.baseURI
<mjs> I don't mind changing it for Safari
PROPOSAL: When you construct, you take your sibling document's baseURI and cache it. This is then used for later method calls.
DS: Any security concerne?
<mjs> I'm not sure using the document's base URI makes sense, since the XMLHttpRequest in't all that related to the document
JS: You might be able to grab the URI of another Window, but this is already possible.
<sicking> mjs, otherwise the web breaks
JS: We have to use the document's base URI otherwise we &btw;
<mjs> sicking, it does? does XHR currently use the document base URI, or the actual document location URI?
<mjs> (sorry for inappropriate use of colon)
<sicking> mjs, it uses window.document.baseURI
<anne> mjs, for <base>
<mjs> I didn't think Safari did that, let me check the code
<mjs> ok, I stand corrected
AvK: changing document.baseURI doesn't have any effect in browsers.
<mjs> it does use the base URI
<anne> well, not changing .baseURI (that's readonly), but changing something that affects it doesn't change .baseURI
<anne> (both on Document and on Element...)
RESOLUTION: When you construct XHR, you take your window.document.baseURI and cache it. This is then used for later method calls.
<scribe> ACTION: Anne to write up the resolution for resolving URIs in XHR
<trackbot> Created ACTION-136 - Write up the resolution for resolving URIs in XHR [on Anne van Kesteren - due 2006-05-08].
<Hixie> specifically, the window that the XMLHttpRequest constructor comes from
<Hixie> not the calling window
3. What if a user moves away from the page or closes the window or a window is destructed
AvK: This was raised on the list.
RB: Isn't this similar to the last? Haven't we resolved it. You still have the object if it is destroyed.
JS: The way it works for us is that we create a load group with all the things loaded by a document. When everything there is loaded we fire the Load event. When you navigate away from the document, everything in the load group is cancelled.
AvK: XHR shouldn't delay the Load event.
JS: [checks Mozilla]
... I think it makes sense to use the same Window for all these things.
RB: Where does the issue come up?
AvK: difference from IE?
<scribe> ACTION: Jonas to write test cases for XHR behaviour when a page is closed
<trackbot> Created ACTION-137 - Write test cases for XHR behaviour when a page is closed [on Jonas Sicking - due 2006-05-08].
<darobin> http://www.w3.org/mid/4455AD5A.3000201@mit.edu
4. Should XHR implement the EventTarget interface from DOM 3 Events?
IH: In favour of this, but doesn't need to be now.
JS: I need to see IDL to see what type onreadystatechange is.
AvK: I made it an EventListener.
RB: The goal is to make XHR an EventTarget eventually.
DM: IE7 won't implement a new event model.
JS: I'm not completely sure we should do it. Mozilla will implement it, but this is a new feature for the specification.
RB: Since three browsers are adding it anyway, I'd prefer to specify it now.
<mjs> Isn't XHR already an EventTarget in mozilla?
<mjs> we are definitely adding it in Safari for compatibility with moz-targeted content
mjs, jonas said the patch is being reviewed (for readystatechanged).
<mjs> dino: I think that's about dispatching a "readystatechanged" event, not about XHR being an EventTarget - pretty sure the latter is already true
<mjs> or am I smoking crack?
<sicking> mjs, apparently we are
<mjs> javascript:alert((new XMLHttpRequest).addEventListener)
<mjs> that displays a function in moz
<sicking> mjs, i.e. moz does make XHR an EventTarget
<sicking> mjs, which version?
<mjs> sicking, Mozilla Firefox 1.5.0.2
<anne> RESOLUTION: objects implementing XHR must also implement EventTarget, there's a readystatechange event in the null namespace and .onreadystatechange is an EventListener
<sicking> mjs, we do not however make onreadystatechange an EventListener, yet
<scribe> ACTION: Anne to make XHR an EventTarget and onreadystatechange an EventListener
<trackbot> Created ACTION-138 - Make XHR an EventTarget and onreadystatechange an EventListener [on Anne van Kesteren - due 2006-05-08].
<darobin> .... break ....
<sicking> scribe: sicking
<scribe> scribenick: sicking
RB: this is not specific to XHR but rather general
AK: we can use OMG, or we can use robins suggestion to write our own note
RB: the problem with OMG is that it doesn't support overloading
IH: and you can't specify which are overriable
RB: the the DOM wg added prose for things that OMG doesn't support, like "//throws on setting"
... specifying our own is going to take time
<bjoern> and people are likely to object to that
AK: what we do now is to just write a fuzzy thing
<mjs> the note could just define a delta from OMG IDL
<mjs> that wouldn't take much time
JS: mozilla uses OMG and everywhere where we deviate we have to use hacks and dig into the JS engine manually
<mjs> we need to specify the features that permit optional arguments anyway
<mjs> it doesn't matter really whether they are in the IDL or not
<mjs> or whether implementations put them in the IDL or not
<mjs> I guess they could be specified as JS-only if that makes it easier for mozilla
JS: we could mabe use OMG extensions if they exist
... we have some extensions in mozilla, but i'm not sure if they are formal or something we have invented
IH: what I've done is to use pseduo-idl and normative prose
<bjoern> The key here is that we use the IDL as form of documentation, and the question is whether a slightly changed IDL syntax provides for significantly better documentation to merit breaking IDL-based tools, confusing people used to standard IDL, and would convince the Director to reject the objections people are likely to raise.
RB: can we resolve to use non-normative pseudo-idl and make sure never to refer to the idl?
<MarkB> +1 for documentation
<darobin> ACTION: Anne to make the IDL in the spec informative and clearly indicate that it's not OMG IDL
<trackbot> Created ACTION-139 - Make the IDL in the spec informative and clearly indicate that it\'s not OMG IDL [on Anne van Kesteren - due 2006-05-08].
<scribe> ACTION: JS to check with moz if their extensions follow some formal syntax
<trackbot> Created ACTION-140 - Check with moz if their extensions follow some formal syntax [on Jonas Sicking - due 2006-05-08].
<dino> I think AK matches Anne. Trackbot doesn't understand multiword names.
AK: IE 7 no longer allows arbitarary methods
<darobin> ACTION: RB to keep pestering Dave Massy about why IE7 doesn't allow aribitrary methods anymore
<trackbot> Created ACTION-141 - Keep pestering Dave Massy about why IE7 doesn\'t allow aribitrary methods anymore [on Robin Berjon - due 2006-05-08].
IH: Some methods cause security, like TRACE
<mjs> TRACE should be banned, agreed
GE: and CONNECT
IH: there might be other ones as well that are security issues
<mjs> OPTIONS is questionable
<bjoern> (future ones in particular)
AK: There's a risk that someone uses a method and then a spec comes out where the method is security sensitive
MN: what happens a few years down the road when a new spec comes out if we have a whitelist. That would hurt adoption of the new spec
... we could have a registry and refer to that. Then you won't have to rev the spec just to add methods
GE: we could namespace it by adding some prefix and then underscore
MN: lets say that I come up with a new method but browsers don't support it. Then i'd probably just do the wrong thing and add a new header instead
IH: how's that different from any other API where you have the same problem
RB: the tradeoff is between lag when something new is invented, and security issues
GE: the http spec mentions extensions
<bjoern> e.g. RFC 2774
MB: what's the security problem with CONNECT and TRACE
GE: there are too many unknowns with how they affect servers that the security guys got nervous
MN: my objection to a whitelist is that it's going to be a roadblock for people coming up with new specs
<mjs> here's one article on TRACE security issues: http://xforce.iss.net/xforce/xfdb/11149
<mjs> CONNECT can be ued to get a proxy to connect to an arbitrary URL and so can violate XSS restrictions
<mjs> someone please tell MN, we could allow other specs to define additional methods that should be allowed for XHR if you support the spec
<mjs> or something
see the member mailing list
<bjoern> We had the same problem for the Atom publishing protocol where XHR wasn't so much of an issue; people thought either APP allows use of methods and POST-only directly in the spec, or someone will go ahead and put that into a separate spec.
errr.. .ignore me
<anne> mjs, does Safari allow arbitrary method names at the moment?
<mjs> anne, I'm not actually sure
MN: what would the whitelist
... be
<anne> mjs, ok
<darobin> ACTION: MS to tell the WG why OPTIONS might be a problem [recorded in http://www.w3.org/2006/05/01-webapi-minutes.html#action10]
<trackbot> Sorry, amibiguous username (more than one match) - MS
<trackbot> Try using a different identifier, such as family name or username (eg. mstachow, mshenfie)
<darobin> ACTION: Maciej to tell the WG why OPTIONS might be a problem
<trackbot> Created ACTION-142 - Tell the WG why OPTIONS might be a problem [on Maciej Stachowiak - due 2006-05-08].
<MarkB> mjs - the open proxy would have to be on the same server from whence the script originated
MN: GET HEAD POST PUT DELETE COPY MOVE LOCK UNLOCK PROPPATCH PROPFIND MKCOL should be fine
... PATCH has been suggested
... and should probably be in
... LINK and UNLINK
... CHECKOUT CHECKIN
... maybe subversion adds
... REPORT MERGE
RB: UNCHECKOUT UPDATE
... KITCHENSINK? :)
<MarkB> MKWORKSPACE, gah
<MarkB> UPDATE
RESOLUTION: have a whitelist for now unless IETF says its really bad, someone to come up with a list for now
<scribe> ACTION: RB to pass an action to MN to come up with a list of methods and current specs
<trackbot> Created ACTION-143 - Pass an action to MN to come up with a list of methods and current specs [on Robin Berjon - due 2006-05-08].
<bjoern> we should then give someone an action to raise this with "IETF"
<darobin> ACTION: DJ to move to MB the action to coordinate with IETF about our method whitelist and a potential registry
<trackbot> Created ACTION-144 - Move to MB the action to coordinate with IETF about our method whitelist and a potential registry [on Dean Jackson - due 2006-05-08].
<MarkB> good call, bjoern
<MarkB> ;)
RATIONALE: it is safer and if we make the list long enough it should not be a huge problem
<darobin> ACTION: GE to check our whitelist with the security guys
<trackbot> Created ACTION-145 - Check our whitelist with the security guys [on Gorm Eriksen - due 2006-05-08].
<scribe> ACTION: Maciej to report security issues with CONNECT, TRACE and OPTIONS. And if they are a security issue within a single domain
<gorm> http://www.w3.org/Protocols/HTTP/Methods.html also defined a SPACEJUMP method
<trackbot> Created ACTION-146 - Report security issues with CONNECT, TRACE and OPTIONS. And if they are a security issue within a single domain [on Maciej Stachowiak - due 2006-05-08].
<mjs> with a whitelist there doesn't seem to be any need for case sensitivity
RESOLUTION: we should not be case sensitive
RATIONALE: with a whitelist there is little reason to be case sensitive, and for some methods we have to be case insensitive anyway
<darobin> ACTION: Anne to add case-folding and white space behaviour to the spec
RESOLUTION: Whitespace should not be given special treatment, so anything containing whitespace will not be allowed
<trackbot> Created ACTION-147 - Add case-folding and white space behaviour to the spec [on Anne van Kesteren - due 2006-05-08].
RATIONALE: no reason to treat whitespace specially
AK: the reason we raised an issue is that the HTTP spec says to default to latin-1 and the XHR spec currently says utf-8
AK: mozilla uses utf8 and jonas says the microsoft documentation says that is the default
<darobin> ACTION: Anne to state in the spec that the default char encoding is different from that in HTTP
<trackbot> Created ACTION-148 - State in the spec that the default char encoding is different from that in HTTP [on Anne van Kesteren - due 2006-05-08].
AK reads the spec
MN: there are rfcs that says it depends on the content type
<bjoern> this should be considered out of scope of the spec, and I doubt we have the implied consistency among implementations. as an example, text/xml with <?xml version="1.0" encoding="iso-8859-2"> would be latin-1 per HTTP, us-ascii per RFC 3023, and latin-2 per XML; I doubt any implementation defaults to UTF-8 in a meaningful way.
RB: we could say that if the UA recognizes the content type it should follow the rules for that content type
<bjoern> also, implementations might use intrisinc knowledge about other types to determine the encoding, like for text/css; this should not be disallowed in a way that contradicts CSS 2.1.
IH: one thing we could do is to say that UAs should follow whatever any other spec says, with the exception that the HTTP default is not latin-1 but utf8
<bjoern> is this supposed to ignore byte order marks? so text/plain with no charset but a UTF-32 BOM would be considered UTF-8?
MN: so with other content type specs the issue is really only for text/plain and similar
... default for text/plain is usascii, according to rfc 2046
<bjoern> that's only for MIME, not HTTP
<arun> http://www.ietf.org/rfc/rfc2046.txt
<Hixie> proposal: responseText must return the entity body interpreted as a stream of characters, following the rules of the relevant specifications if the response includes a Content-Type understood by the user agent, with the exception that the rule in the final paragraph of section 3.7.1 of RFC 2616, and the rules in section 4.1.2 of RFC 2046, must be treated as if they specified the default character encoding as being UTF-8.
<arun> +1 Hixie
<Hixie> proposal: responseText must return the entity body interpreted as a stream of characters, following the rules of the relevant specifications if the response includes a Content-Type understood by the user agent, with the exception that the rule in the final paragraph of section 3.7.1 of RFC 2616, and the rules in section 4.1.2 of RFC 2046, must be treated as if they specified the default character encoding as being UTF-8.
<Hixie> (not sure how to handle application/octet-stream, etc)
RESOLUTION: use Hixies proposal
<bjoern> if the implementation doesn't know how to derive a character stream in accord with the media type specification, reponseText should be null.
<Hixie> RB: Do we open a new issue for application/octet-stream, etc?
<Hixie> what bjoern says makes sense
<Hixie> RB: Does that correspond to implementations?
<MarkB> wouldn't implementations tend to guess rather than return null?
<Hixie> RB: Security section
<darobin> Security section: http://lists.w3.org/Archives/Public/public-webapi/2006Mar/0244
CMN: in oslo we decided that we shouldn't define security
<bjoern> I would object to not having a proper security considerations section.
AK: we can have a statement that says that implementations might deviate from the spec for security reasons
<bjoern> we should clearly say what the known threats are and known methods to mitigate them. there doesn't have to be a mandatory model.
IH: 'should' is a good word to use here
<chaals> CMN: What bjoern said.
CMN: speak up or shut up
RESOLUTION: we take the security section and sprinkle it with SHOULDs. We should also make sure to use SHOULD throughout the spec when talking about security
<chaals> RATIONALE: The group should not be enforcing non-conformance on the basis of its perception of security requirements (by using MUST to enforce security restrictions), but it is valuable to say what is normally restricted (and why)
DS: we should list in the security section which other places in the spec we talk about security
<darobin> ACTION: DS list all parts of the spec that discuss security
<trackbot> Created ACTION-149 - List all parts of the spec that discuss security [on Doug Schepers - due 2006-05-08].
<darobin> ACTION: Anne to include Jonas's security section proposal
<trackbot> Created ACTION-150 - Include Jonas\'s security section proposal [on Anne van Kesteren - due 2006-05-08].
AK: ISSUE-71
RB: let's defer and break for lunch
<chaals> scribeNick: Hixie
and... go
AK: I suggest someone suggests something for setRequestHeader
RB: I'm happy to defer this to an action item.
AK: I'd like some consensus before we do this section
RB: Let's discuss this a bit
AK: It should be clear which part the UA must handle and which part the authors can touch
... Not sure how to fit that into the spec
RB: Could be a separate section, not the same section of the spec as teh method description
MN: I tend to think of the HTTP stack as a set of layers
... Where does the line get drawn, is the question.
... The comment that I made that was more relevant than anything is that the part of the spec that says that the UA must not add certain headers is inappropriate.
... e.g. TE is not on this list
... I would change MUST NOT to SHOULD NOT
IH: I would remove it altogether
JS: there are some that we want to prevent
IH: We can list those that it can add
... and those we don't want it to add
AK: or make it a list of headers the UA must not set instead
<bjoern> We could have constraints, UAs must not claim to support charsets, transfer encodings, content encodings, ... they do not support, they must not send malformed requests (content-length longer than entity body), ... phrased in a way so it's clear how to apply this to new standard headers.
<mnot> HTTP headers -> http://www.rfc-editor.org/rfc/rfc4229.txt
IH: We can have prose that just lists a bunch of headers and says whether they can be added/notadded/modified/etc.
AK: The n ext problem
... ...is listing headers and deciding on each header
er yes my bad
RB: We can list the categories that we want to talk about
<mjs> I like the list of forbidden headers I proposed
CM: UAs MUST add, UAs MUST NOT add, UAs MUST allow authors to override, to append, and UAs MUST NOT allow authors to affect
<mjs> those sound good
MN: Default is no restriction, except if it appears in the list.
JS: Cache is one example of things that the UA must not add--
IH: IMHO caching needs its own section because defining all the caching semantics is a whole bigger can of worms.
AK: in the editor's draft there's a section about 304s, etc.
GE: If the UA adds If-Modified-Since headers, then--
IH: IMHO the UA shouldn't ever add cache headers
MN: I was thinking earlier that the UA might want to control transfer encoding or caching
<mjs> doesn't the http spec define how caches should treat various cache headers in the request?
<mjs> the UA cache should just be considered a cache w/ respect to the XHR request
<bjoern> we had a proposal that the UA simply acts as the first proxy for the XHR client, yes
<bjoern> you'd then have pretty well-defined behavior once you have the XHR request composed by the UA.
AK: Can someone write a section describing how to handle the headers according to the categories listed above?
<darobin> ACTION: RB to pester MN until he proposes a list of headers for each category (or some similar solution)
<trackbot> Created ACTION-151 - Pester MN until he proposes a list of headers for each category (or some similar solution) [on Robin Berjon - due 2006-05-08].
AK describes the caching section in the spec
MN suggests a new flag that controls whether to have the UA cache be enabled or not
AK: I don't think that would work
MN: My main concern around caching was around honouring Cache-Control headers
RB: I think the paragraph could be made clearer
... At least a pointer to HTTP
<mjs> bjoern: I don't think it should "act as a proxy" in the literal sense, for instance IMO one-hop headers should not be consumed by the UA itself
MN: If-Modified-Since should, e.g., replace not add
JS: That is the list we need to add
IH: You only need to list the ones that are special
<mjs> bjoern, the http spec talks about caches generally, whether or not the cache is a proxy (I think)
<bjoern> (yes, a cache is always local, where a caching proxy's cache is local to the proxy.)
<mnot> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23
<darobin> ACTION: RB to pester MN until he produces a list of headers that you can't append to
<trackbot> Created ACTION-152 - Pester MN until he produces a list of headers that you can\'t append to [on Robin Berjon - due 2006-05-08].
<scribe> ACTION: MN to write a section listing the headers that need special rules (based on RFC4229 and the existing section in the spec), with those rules, etc [recorded in http://www.w3.org/2006/05/01-webapi-minutes.html#action22]
<trackbot> Sorry, couldn't find user - MN
<chaals> ACTION: Robin to get Mark N to write a section listing the headers that need special rules (based on RFC4229 and the existing section in the spec), with those rules, etc
<trackbot> Created ACTION-153 - Get Mark N to write a section listing the headers that need special rules (based on RFC4229 and the existing section in the spec), with those rules, etc [on Robin Berjon - due 2006-05-08].
RESOLUTION: We list headers that are special with respect to appending.
... with respect to XMLHttpRequest, giving rules for append/overrite/may-not-be-overriden, UAs MUST/MUST NOT set, etc.
JS: We should have a rule saying you can't break HTTP
IH: That's redundant, HTTP already says you can't break HTTP
JS: Content-Length, for example, could cause all kinds of problems if it is not set right
IH: Well, Content-Length should never be set by the author
RB: More events to add to the object
<mjs> sicking, see my proposed set of rules, where I suggest we should not allow authors to set headers that would let them break http (in more than a trivial syntactic way, that is, since almost any header lets you do that)
JS: Also need upload progress events if we do that
<mjs> I would suggest not adding all the new events for XHR 1.0
<mjs> maybe "load"
<mjs> I think adding events that no browser has yet at all is stretching it
<mjs> sicking, email I referred to is here: http://lists.w3.org/Archives/Public/public-webapi/2006Apr/0225.html
JS: The way I feel is that right now [these events aren't important yet], and that cross-domain, e.g., would be more important if we're going to add stuff
CM: We need to get XMLHttpRequest out soon, which means not doing new stuff yet.
Group discusses whether or not to publish soon or whether to add more features to the spec
<Zakim> chaals, you wanted to say there is XS XHR
RB: (describes timeline)
RESOLUTION: Feature freeze today.
... new events (other than readystatechange) are deferred to v2
<chaals> RATIONALE: We need to get this done and get onto our other deliverables
AK: Next draft of XHR in 2 weeks?
Group discusses how long it'll take AK to edit the spec
AK: DNS errors
CM: If we're getting a new draft in 2 weeks, can I make that public
AK: Yes
MN: Referer header?
IH: Referer shouldn't be changed by the author.
JS: What is the referer, is another question?
IH: e.g. in the multi-window case
<mjs> URI of the document that provided the baseURI?
JS: No
... That would be a security problem
... Since you can set the baseURI to anything
<mjs> not the baseURI itself
RB: (not a security problem in non-cross-domain yet, but still wrong)
<mjs> the actual origin URI of the document where you got the baseURI
<mjs> (that might have security issues too)
well the question is do you provide it from the window that constructed the XMLHttpRequest, or do you set it from the window that had the constructor invoked
IH: I think we should just let MN decide when he writes that part fo the spec
JS: I think it should be window.document.location === window.location of the top of the call stack at some point in time
<mjs> it is weird for the base uri to come from one document but the referer from another
AK: Seems like at construction time is most sensible
RB: What do browsers do?
IH: Write a test.
<scribe> ACTION: JS to Test and come up with solution for how to set Referer: header.
<trackbot> Created ACTION-154 - Test and come up with solution for how to set Referer: header. [on Jonas Sicking - due 2006-05-08].
<chaals> RESOLUTION: History with regards to XHR discussion postponed to a later date.
GE: responseText for application/octet-stream
... Opera - ""
... Mozilla - "<"
... IE - exception
IH: Sounds like you did it before readyState 4
GE: Yes
... Opera and Mozilla interpret the binary as text
... Firefox doesn't seem to
<darobin> Welcome to 1970
<darobin> ACTION: GE to check what browsers do for binary data, and make a proposal
<trackbot> Created ACTION-155 - Check what browsers do for binary data, and make a proposal [on Gorm Eriksen - due 2006-05-08].
AK: Network errors
IH: I suggest you just write some text and see if everyone agrees
<scribe> ACTION: Anne to write a proposal and test for behaviour of XHR network errors
<trackbot> Created ACTION-156 - Write a proposal and test for behaviour of XHR network errors [on Anne van Kesteren - due 2006-05-08].
<anne> scribenick: anne
RB: lets look at Mark's proposal before doing DOM3EV
<MarkB> http://www.w3.org/mid/6AF75C3A-1D3E-4A3F-BB39-3FDF9C29D9F9@yahoo-inc.com
AK: is this replacing the whole sections?
MN: not really
IH: seems like a good start, needs to have more detail on what certain headers need to be set to
MN: yeah, didn't go into that level of detail
RB: looks good to me
MB: I have a couple of comments
... It might be appropriate to let authors extend the Connection header
... had some reservations about the white space requirements in setRequestHeader
IH: it prevents people smuggling new headers in
MB: how about a tab character etc.?
IH: a tab character is a continuation of the previous line
... tabs should be one of the things you can't have in a header
RB: white space, basically
IH: that has to be defined...
... I meant ascii control characters
... they should probably all not be allowed
<Hixie> IH: jsut say that anything below 0x20 should cause the header to not be added
<darobin> http://lists.w3.org/Archives/Member/member-webapi/2006May/0000
CMN: expect to have that done tomorrow
DS: will raise the issue now in public
JS: Ray gave some good arguments, but it might be over-engineering
<bjoern> http://www.w3.org/mid/465905FD-255E-4D0B-9C50-3FEAF3CF8C08@personallegal.net
RB: I suggest we wait for public feedback
JS: it doesn't sound like a lot more complexity
RB: might be useful for XBL
IH: I don't see any strong usage for them in XBL
JS: people use a single library
IH: I think people use at most one
RB: people might start using two or three
<bjoern> archive networks like OpenJSAN are gaining traction, making library use much simpler than it is now.
RB: keeping them for now and waiting on public feedback...
JS: yeah...
JS: depends on what you mean with a non-String
GE: on what methods do you use that today?
JS: all...
<bjoern> (the issue is supposed to cover passing Foo where the method expects Bar, for any Foo,Bar with Foo != Bar)
RESOLUTION: for all primitive types we do as specified per http://lists.w3.org/Archives/Member/member-webapi/2006Mar/0008
bjoern, you are expected to specify that... (or do you really want an action?)
<schepers> maciej, I sent an email to the public list about Event Groups. You've raised discussion on this issue before, so would you please chime in?
JS: for complex types we check which interfaces the object implements to see whether or not it matches
bjoern, those are useless...
<mjs> schepers, there have been claims that it supports multiple views, but I don't think they actually work well for that purpose, and they add complexity
<schepers> mjs, can you reply to the list?
<mjs> schepers, all the evidence we have is that even the 3-arg version confuses people and they consistently get it wrong by copying calls that they don't understand
<scribe> ACTION: JS to specify how complex types work
<trackbot> Created ACTION-157 - Specify how complex types work [on Jonas Sicking - due 2006-05-08].
<mjs> schepers, in fact I would go so far as to say that the code using useCapture = true correctly and on purpose is probably less than the amount of code using it accidentally and sorta working by coincidence
[People discussing having a separate specification for this...]
IH: ECMAScript binding for the DOM
<bjoern> It should either be in Core or in a separate specification, I agree.
[Or something like that, that quote might not be entirely accurate...]
JS: can we go straight to LC for a simple specification?
<bjoern> yes
RB: you can, not a good idea I guess
RESOLUTION: we have a separate specification for "ECMASCript binding for the DOM"
<darobin> ACTION: RB to put up a template draft of the E4DOM spec
<trackbot> Created ACTION-158 - Put up a template draft of the E4DOM spec [on Robin Berjon - due 2006-05-08].
<darobin> ACTION: JS to update the E4DOM spec with his improved text
<trackbot> Created ACTION-159 - Update the E4DOM spec with his improved text [on Jonas Sicking - due 2006-05-08].
<bjoern> I take it that obsoletes my actions to include these things in dom3ev?
<darobin> http://lists.w3.org/Archives/Member/member-webapi/2006May/0000
<darobin> bjoern, I assume it would
bjoern, I assume you need to put a reference
<bjoern> right, I'll work with JS so everything is covered there and properly referenced in ev.
RESOLUTION: DontDelete and other internal properties are to be specified in EB4DOM
(EB4DOM means ECMAScript binding for the DOM)
JS: the reason ECMAScript spec didn't do things because there were no exceptions
GE: the problem is that you don't know which exceptions
RB: can we specify that an exception has to be thrown, regardless of which one it is?
JS: yeah, I think so
RESOLUTION: we specify that an exception is thrown, but don't specify which one it is
JS: Unless ECMAScript4 is really quick!
<bjoern> haha
<darobin> ACTION: JS to poke TC39 about their exception for this
<trackbot> Created ACTION-161 - Poke TC39 about their exception for this [on Jonas Sicking - due 2006-05-08].
JS: probably same specification
RB: growing by the minute...
JS: can't remember what we resolved for null...
<bjoern> specify where null may be used and point out what dom core says when null is not expected
<bjoern> the draft does that
RB: what to do about undefined, treating it like null?
bjoern, dom core actually says something on that subject?
bjoern, or is it something for EB4DOM?
<bjoern> "Implementations should raise other exceptions under other circumstances. For example, implementations should raise an implementation-dependent exception if a null argument is passed when null was not expected." -- http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-17189187
RB: sound reasonable
JS: yes
<darobin> ACTION: JS to check whether to treat undefined as null
<trackbot> Created ACTION-162 - Check whether to treat undefined as null [on Jonas Sicking - due 2006-05-08].
CMN: the basic issue is what to do when we start to build a lot of mouse events which assume a particular UI
... you actually want something that doesn't assume a particular UI
RB: is that something for DOM3EV?
CMN: it's not clear, that's why there's an issue
... if these are devices specific events we need DI or some group to tell people how to use them
... haven't chased it around DI people, did coordinate with WAI which are working on making DHTML accessible in browsers
... focusin/focusout/domactivate were created to solve those problems but were never implemented
RB: I'm wondering if that's something that should go into DOM3EV
... or a separate specification that binds/glues all things together
<mjs> focusin/focusout is not any more device independent than focus/blur
RB: makes more sense to me to keep it separate from DOM3EV which already has some feature creep
<mjs> DOMActivate really only differs from "click" in name
mjs, those were considered HTML specific back then (focus and blur)
<mjs> the thing is to not get hung up on the names and just decide how events that may sound device-specific should map to other devices
mjs, you're right on all points though
mjs, mousemove?
<scribe> ACTION: CMN to discuss with DI on events
<mjs> anne, sure, but HTML-specific has nothing to do with device-independence
RESOLUTION: unless we get feedback from DI, or WAI, or someone, we won't address ISSUE-32
mjs, I'm not claiming otherwise :)
<mjs> anne, not sure what specific issue there is with mousemove - devices w/ a joystick that drives the pointer, or a trackpad or trackball or whatever, should use mousemove, devices that don't have an onscreen pointer at all shouldn't dispatch it
<mjs> even if there is a pointer that is moved via the keyboard that should be "mousemove"
<mjs> the mouse* family of events is really about the pointer, not the mouse
mjs, the problem with that is that applications expect it to be dispatched
<bjoern> (mjs, the issue would be if you make a drag and drop thingy based on pointer events, and drag and drop via voice commands)
<chaals> [mjs, true but this problem can arise when we start collecting diagonal mousewheels seperately as movements...]
JS: if we do mousewheel we probably need to adopt the proposal from multive devices from Stephane
RB: perhaps a separate specification...
<chaals> s/`
DS: SVG people want it
RB: it could still be done in a separate specification...
AK: how is mousewheel different from mousemove?
CMN: it seems to do stupid to only address multiple moousewheels while ignoring the issue of other multiple devices
DS: if you have a wheel that is horizontal and one that is vertical... in Apple's implementation they are logically the same wheel
... if the wheel went north west you need synchronization...
AK: if you define the dispatching order it's not hard to synchronize them
JS: Apple has two events
... suggestion from Stephane was to have a related event attribute
<darobin> http://lists.w3.org/Archives/Public/public-webapi/2006Mar/0246
JS: two connected mice and each has one cursor
IH: I didn't know that was supported
JS: his proposal solves that issue
... and his proposal also solves the issue with a mousewheel that has multiple axes
... the first one regarding multiple devices should probably not be solved in this specification
... you have mousewheel and mousewheelx and you have a relatedEvent attribute to handle them
AK: they can both be dispatched and are dispatched in order but are not dispatched as a result of the other so you can cancel them separately
IH: that's fine, you still have to listen to both of them
... cancel means preventDefault...
DS: wheeling is separate from scrolling
<darobin> AK whines
CMN: if you scroll horizontally one fires
... if you go diagonally both fire and you see a relatedEvent attribute that tells you about the other...
RB: you have to listen to both
<Hixie> L vs \
you want to distinguish between L and \ (shapes here) and relatedEvent would solve that...
DS: I have a separate proposal that makes this easier
... you have a wheel event that has all the details
IH: this breaks current usages
CMN: if you have the use case for two different wheels and you catch the first one and cancel it that doesn't work
RB: you want to cancel only vertical or horizontal scrolling
<Hixie> IH: the default action of mousewheel is to scroll
<bjoern> it's not
<bjoern> it depends on environment settings, what the cursor is over, ...
IH: it changes what browsers do todo
... you're proposing having mousewheel and wheel?
DS: no, only wheel
IH: doesn't work
JS: you end up with the activate/click situation
... there's another issue with the two being the same event, there's content currently assuming you're doing certain things...
IH: the issue of scrolling versus wheeling is irrelevant
DS: i'd still say they are separate issues
JS: I still have a problem with the relatedEvent thing
... say you want to implement your own scrolling mechanism
<Hixie> bjoern, is http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html the latest draft of DOM3 Events?
JS: you want to move diagonally... you attach an event listener for the x things etc.
<bjoern> it's about it, yes. It has some changes since the WD
CMN: you listen to them both, if they are related you treat them both the same...
DS: the function is called twice...
<Hixie> bjoern: can you point me to the normative text that defines things like initEvent and preventDefault stuff? I can't find the MUSTs for what should happen when you call preventDefault() -- I'm trying to find out what exactly it does (e.g. if you call it before dispatching the event)
<bjoern> that's ISSUE-35
RB: that's fine, if there's no related event you ignore it... [scribe misses it)
<bjoern> see http://www.w3.org/2005/06/tracker/webapi/issues/35
<Hixie> bjoern, ah ok
<Hixie> bjoern - k, thanks
GE: the mighty mouse from Apple is not really a mouse wheel
IH: whether something is a mouse or a wheel is how the OS reacts to it
... so we don't care
<schepers> hixie, please type in your explanation
RESOLUTION: if we do anything at all we probably take the related event proposal
<Hixie> i suggested that if the OS handles the device as giving absolute coordinates, then it's a mouse, and if it handles it as having a sequence of relative changes, it's a wheel
<schepers> if you do the relatedEvent solution, we should have an explicit example showing how to capture diagonal events
RB: you want to avoid the staircase effect
<scribe> ACTION: GE to make an example script using relatedEvent...
<trackbot> Created ACTION-163 - Make an example script using relatedEvent... [on Gorm Eriksen - due 2006-05-09].
MouseWheel { wheelDelta; relatedEvent; }
RESOLUTION: we have two separate mousewheel events
RB: we are doing DOM3EV tomorrow
bjoern, what's wrong with my proposal for dblclick?
<bjoern> you made one? :)
<bjoern> don't see it on http://www.w3.org/2005/06/tracker/webapi/issues/49 ...
bjoern, http://www.w3.org/mid/op.s64kfqa564w2qv@id-c0020.oslo.opera.com
<bjoern> right, so the group just needs to approve that
<bjoern> you should cite issue numbers more :)
<Hixie> this mousewheel.relatedEvent thing doesn't work in practice
>