<Hixie> i've been trying to post on lj for a whole now

<Hixie> i keep getting timeouts

<Hixie> while even

<gsnedders> I can't get on godaddy at all to renew domains that expires tomorrow

<Hixie> anyway i'm in css. let me know if i should be here.

<gsnedders> (well, I can get on it, I just can' login)

<gsnedders> shepazu: hey! :P

scribenick adrianba

<shepazu> hey, gsnedders, long time no see

Element Traversal

DS> updated tests

<shepazu> http://dev.w3.org/2006/webapi/ElementTraversal/tests/report/et-implementationReport.html

DS> different tests targeting html, xhtml, svg

DS: testing ent refs plus other namespaces
... what other tests should be included

JS: might have tests to add

AVK: should have other dynamic tests
... PIs, comments

Progress Events

<chaals> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.24

JS: security problems, particularly with headers
... header size could expose password length if other headers known
... cross-site XHR only exposes small set of headers at the moment

CM: don't you see all head anyway

JS: cross site XHR doesn't allow to read all headers, only subset

AVK: aren't progress events only for entity body

JS: we said it might make sense to include headers

<marcos> http://dev.w3.org/2006/waf/widgets-digsig/Overview.src.html

CM: wouldn't normally get events for headers

<marcos> ooops, wrong chan

AVK: isn't worth it for small use case

CM: will change so don't get events for headers

<Adam> does anybody have the link to the wiki agenda?

<chaals> http://www.w3.org/2008/webapps/wiki/WebAppsMandelieuAgenda -> agend

<Adam> tx

CM: added loading event
... will make headers change then publish WD

JS: should it be LC

RESOLUTION: make headers change and move draft to LC

(discussion of must, should, may use of keywords and case)

DOM 3 events

DS: fairly close to done, not at LC yet
... scroll events, feedback needs to be written up
... two events, mouse scroll and wheel event

JS: concern previously about xscroll vs yscroll
... devs may expect only single axis

DS: risk mitigated by mousewheel vs wheel

JS: don't think devs will always be smart enough to differentiate

AVK: what is interaction between events

DS: they are not linked

JS: can page cancel scrolling by cancelling events

DS: yes by canceling both events

JS: may need more discussion on list, could it be if either is cancelled then won't scroll

DS: we could make that change
... will discuss on list

AVK: if canceling mousewheel cancels wheel then that might mask x scroll

DS: key identifiers - need feedback on IME issue
... testing

CMont: have tests but not released yet - about 2000
... ready to publish when group ready

DS: ideally make tests so can easily be reused in vendor's frameworks

CMont: mobile web group has test harness that can be used to run tests

DS: if can reuse would be good way to expose tests
... some other specs depend on DOM 3 events, make progress in Nov

CM: needs assistance with tests for progress events

JS: has tests based on XHR
... testing timing guarantees is hard to test with existing framework

CM: progress events doesn't include timing requirements

testing

CM: has been call for tests earlier in cycle before LC

DS: thinks good idea, helps editor think about assertions

AB: some of best documentation is test cases

CM: sometimes tests are more useful than spec

DS: sometimes authors copy/paste from tests
... what are the practical implications

CM: none, but we agree or not
... can be costly to do tests early

AVK: if tests are complex and spec changes then might start again and time is wasted

DS: don't think wasted if helps implementors find out sooner than later

AVK: without implementation, test isn't useful

CM: for some people, reading tests is easier than reading spec

AVK: tests typically follow implementation, easier to write tests

JS: writing tests during implementation is helpful

AVK: but then you're implementing

CM: not necessarily

AVK: is there an example of tests contributed without implementation

(general discussion of timing of test writing and implication of spec changes)

CMont: assuming would start from scratch if spec changes and not necessarily true

JS: of course less work for test author to do as late as possible, but question is whether implementor or test author feels pain

<anne> (that was not my point)

DS: multiple implementors, only one test author

<anne> (my point was that in case there's no implementation and the spec is just going to LC writing tests is bound to be costly because the chance of the spec changing is huge)

JS: one implementation is often first and generates the feedback for changes

DS: some set of tests before LC would be helpful

<Adam> does it make sense to recommend when it's useful to have tests early, in what situations

CM: clear that having tests is helpful, having tests thrown away not so much

AB: is it worth knowing situations when having tests is more helpful

AVK: not against idea, but want to note that is has costs

<sicking> Progress events tests: http://mxr.mozilla.org/mozilla-central/source/content/base/test/test_bug435425.html?raw=1

DS: are we going to do something or just talk about it
... propose have way WG operates is to have tests early on
... make having some tests part of criteria to decide if to publish next draft

CM: opposed to making that a general principle
... don't want to hold up publication for not having tests

<chaals> (thanks Jonas)

DS: adds discipline - we're not punishing people for not having tests
... would like more discipline in group wrt testing

JS: excessive for all WD, useful for LC

CMont: can construct tests in such a way that change can be less costly

CM: should we insist on tests for LC?
... seems to be a rough consensus to try

XHR2

JS: two requests about timeout and json response

AVK: don't need timeouts, should use async or worker

JS: do need timeout in workers
... plus people are using sync
... don't think people will use more or less because of timeouts

AVK: can add timeouts

JS: responseJSON?

AVK: don't want to be first to add this

JS: json will become part of native ecmascript language
... will want to add json in different areas, being first not good enough reason but there are other reasons

CM: do we have a XHR2 timeline

AVK: not really, but there are two implmentations

JS: not of all features

AVK: need other specs to become more stable before can LC
... probably want to add support for files or blobs depending on how that goes
... changes to XHR1 need to also flow into XHR2

CM: really need other specs to move forward then

taking 15 min break

<chaals> we are actually taking a break until 1.30, and will then meet together with the other half of the group

<gsnedders> Ah, then I'll vanish.

<chaals> We continue at 1.30 (13h30 local time)

<MikeSmith> anne: any idea where Henri is?

<CharlesMcCathieNe> hey chaals, who are you?

<nrmehta> CM: discuss Access Control

<nrmehta> AVK: Processing model is pretty much done

<nrmehta> JS: Prefetch cannot be cached anyway

<nrmehta> if it is redirected

<nrmehta> AVK: Why not?

<nrmehta> JS: What would you cache

<nrmehta> JS: If there is a graph of redirects from A to B to C and so on, then because these are not 200 OK requests, then the final request begets response and you can cache that

<nrmehta> All but the final one will be cached

<nrmehta> JS: Will review that

<nrmehta> JS: All three submissions will have to opt in to allowed headers?

<nrmehta> AVK: During redirect only check Access-Control-Allow-Origin

<nrmehta> AVK: since OPTIONS is not with credentials

<nrmehta> AVK: The spec says for redirect steps require only Access-Control-Allow-Origin headers and not others such as Allow-Headers

<nrmehta> JS: This may be more XHR2 question

<nrmehta> JS: If the redirect goes cross site

<nrmehta> AVK: XHR2 would need to use Access Control

<nrmehta> CM: Does this mean you are happy

<nrmehta> JS: Yeah as long as I know what it means

<nrmehta> CM: Anything else?

<nrmehta> JS: Some editorial and behavioral things

<nrmehta> JS: User agent can put in stricter requirements such as clearing the preflight cache

<nrmehta> JS: Any requests can be denied

<nrmehta> JS: Third party cookie preferences are differently managed by various browser

<nrmehta> JS: Should the spec say browsers are allowed to override algorithms based on user prefs

<nrmehta> JS: This should not be in the algorithm but should still be normative

<nrmehta> JS: This should not be in the algorithm but should still be normative?

<nrmehta> AVK: It does sound that some requirements are normative?

<nrmehta> CM: That means complete implementation, write implementation report

<nrmehta> AVK: Do the editorial work... That is

<nrmehta> JS: Improve security considerations

<nrmehta> AVK: Does that mean I need to do it?

<nrmehta> JS: One section refers to both Web site authors and to server authors

<nrmehta> AVK: Thinks that all are for server authors

<nrmehta> AVK: The first is not, the rest is server

<nrmehta> JS: Break those apart and make those exhaustive

<nrmehta> AVK: I can elaborate the ones I have written and JS can add more

<nrmehta> JS: Clients need to be aware of redirects and if someone is redirecting to other sites

<nrmehta> JS: then handle the data appropriately

<nrmehta> AVK: Why exactly?

<nrmehta> JS: If Web sites have Access-Control opt in, then if a script publishes third-party data in a public way

<nrmehta> JS: then the server A may have redirected a Web site to some other place, and the site author needs to know that they may not have the source they are thinking they got

<nrmehta> JS: Some sort of redirect event may help

<nrmehta> AVK: A list of redirected URIs may be

<nrmehta> JS: prefer events, but any mechanism is fine

<nrmehta> AVK: May be also add more examples

<nrmehta> CM: All we need now is examples, tests, implementations, and interoperability

<nrmehta> JS: I wrote infinitely running tests, but only reports at the end

<nrmehta> (tongue firmly in cheek)

<nrmehta> AVK: Hixie changed something in HTML5 that changes serialization of origin

<nrmehta> JS: We should always make the null origin string rather than mask it

<nrmehta> JS: If you don't know which site is making the request, then the server should return Allow-Origin: *

<nrmehta> JS: It seems weird to have AC-AO: null

<nrmehta> JS: so force people to say * if they want to allow 'null' to read data

<nrmehta> AVK: If you have a data URI, and that server should not allow * domain

<nrmehta> JS: If you are requesting from null domain, disallow any third party?

<nrmehta> JS: Mozilla never produces null domain

<nrmehta> AVK: domain is null if the user types in a javascript: URL after loading an about:blank page

<nrmehta> JS: That seems about right

<nrmehta> JS: We don't allow redirect for data URI

<nrmehta> JS: If you do redirect to JavaScript URI, then many pages will also show ...

<nrmehta> JS: I lost it

<nrmehta> AVK: In Opera, it works

<nrmehta> AVK: Firefox does redirect as well.

<nrmehta> AVK: Should we provide an explicit rule for this?

<nrmehta> JS: If the Origin header was null and if credentials flag is set, then there is no valid response

<nrmehta> JS: We wouldn't allow Origin to be echoed back, if Origin is null, and we are already disallowing * if using credentials, then we are fine

<nrmehta> CM: Do you have a rough idea?

<nrmehta> AVK: Oh yeah, we do have another one

<nrmehta> AVK: If we have to normalize header names that we have to set in various AC headers

<nrmehta> AVK: Should request headers be all lower case?

<nrmehta> JS: That makes sense

<nrmehta> CM: Anything else in the way

<nrmehta> AVK: Not really

<nrmehta> CM: Rough timeline?

<nrmehta> AVK: Depends on editorial bit

<nrmehta> JS: Can be done in LC

<nrmehta> CM: That is OK, but if you are planning on that, then put in a pointer about informative sections that may change after editorial changes

<nrmehta> JS: The changes for UA preferences based overriding would be substantive changes

<nrmehta> JS: Is it possible to make normative changes in LC?

<nrmehta> CM: You can, but that would require another LC

<nrmehta> DS: It is subject to the transition call

<nrmehta> DS: If there are two or three changes that everyone agreed ahead, then you can go from LC to CR

<nrmehta> DS: If someone disagrees you would have to go back to LC

<nrmehta> JS: In most CR phases, some feedback will cause normative changes

<nrmehta> DS: Then you have to go back to LC

<nrmehta> DS: But you can go back from LC to PR

<nrmehta> once such changes are agreed to

<nrmehta> CM: Basic idea is to avoid surprises

<nrmehta> JS: It is an implementor's dilemma whether to wait until CR or do it earlier

<nrmehta> CM: Anne -- you need some work before you can be in LC

<nrmehta> AVK: I will be away for three-four weeks

<nrmehta> AVK: I will have time end of Novemeber/December

<nrmehta> AVK: Any other business?

<nrmehta> DS: Who's editing the Window spec?

<nrmehta> CM: Just let me know when you are done Robin

<nrmehta> CM: We are done, thanks for coming

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/so don't generate a response AO: */so force people to say * if they want to allow 'null' to read data/
No ScribeNick specified.  Guessing ScribeNick: adrianba
Inferring Scribes: adrianba
Present: Chaals Jonas StefanoC AdrianB AdamB Jyrka AnnevanK Lachlan Carmelo Janice Henri Geoffrey ErikD Doug RolandM

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

Guessing minutes URL: http://www.w3.org/2008/10/21-webapps-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)