See also: IRC log
<trackbot-ng> Date: 23 January 2008
<ArtB> Meeting: WAF WG Voice Conference
<anne> i don't have better equipment than last time so i'll prolly have to be muted all the time...
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0223.html
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
<sicking> I am, but muted
<tlr> I'm muted, folks, so can't be me if the noise is still there
<Art> AB: propose adding the P3P suggestion raised by Mark to the agenda
<anne> it's no longer here
<tlr> oh
<Art> AB: is that OK?
<anne> because you're muted :)
<tlr> I hear it quite well
<tlr> *argh*
<Art> AB: it would be the last part of the meeting ~10 mins or so
<anne> (there is some other noise to though)
<Art> AB: any objections
<Art> JS: OK with me
<Art> [Chair notes noise probs has caused most people to mute ...]
<Art> AB: thanks for submitting the input of requirements Jonas
<Art> AB: since then we've comments from Art, Jon, Thomas, probably others regarding those reqs
<tlr_> sorry...
<Art> AB: open the floor to any major reqs related issues people want to discuss
<Art> DO: want to raise the server-side versus client-side PEP
<Art> ... my related e-mail gave my position
<Art> ... don't think we have consensus on this
<Art> ... within the WG
<Art> ... but I haven't seen Thomas' latest e-mail
<Art> ... there has been lots of discussion
<Art> ... some people in the WG feel strongly about it
<Art> ... I don't think we should close this issue
<Art> ... likely to be a formal objection
<Art> ... think we need to try to get to consensus
<Art> ... I've been dismayed by some of the comments
<Art> ... For example "take it to another WG"
<Art> TR: may make sense to talk about the reqs in the context of the Issues
<Art> AvK: what is the counter-proposal?
<Art> ... how do you not involve the client?
<Art> ... I've raised these questions on the mail list but haven't gotten any response
<Art> DO: I defer to Tyler and other security folks
<sicking> anne, you are causing echo
<Art> AB: I thought Anne's quest for an alternate proposal was to the whole community not just to Dave
<Art> AvK: yes, that's correct
<Art> TR: I think we should first look at the reqs
<tlr> dave?
<anne> whoa
<tlr> anne?
<tlr> dave?
<tlr> want to rejoin?
<Art> AvK: did anyone make a concrete proposal?
<Art> TR: Mark and Tyler both made concrete proposals
<Art> JS: we certainly put more of the enforcement in the client
<Art> TR: one of Mark's proposals should be workable
<tlr> http://www.w3.org/mid/B8F607CD-811A-44DF-BE58-314C8BB9CAE3@yahoo-inc.com
<Art> TR: but it doesn't work with legacy servers
<Art> JS: I don't see any way of doing this and still meeting req #4
<Art> TR: good point
<Art> ... if you wanted to do enforcement on the server side would require a step where client asks the server if it understands the protocol
<Art> ... if the server does, then the details could be moved to the server
<Art> ... but have to be careful not to break existing services
<Art> ... policy lang doesn't have to travel over the wire
<Art> AvK: that makes GET requests more complicated
<Art> ... have to know if server is capable of replying
<Art> ... makes caching on the server harder
<Art> JS: I think we need a concrete proposal
<Art> ... including the attacks it addresses
<Art> AvK: hard to comment on the other proposal when it isn't real concreate
<Art> TR: given DO dropped off I think we don't have critical mass to continue this discussion
<Art> JS: I agree
<Art> AB: would like to understand the requirements angle
<Art> TR: would need some type of discovery mechanism
<Art> ... need to understand the complexity of the server versus the client
<Art> ... i.e. where to put the complexity
<Art> JS: I don't see it as client side PEP vs. server side PEP because there will need to be policy enforcement on both
<Art> TR: I agree
<Art> JS: we need 1) coutner proposal; 2) what are the problems to solve
<Art> TR: I can create some counter proposals
<Art> AB: that would be good
<Art> TR: I can come up with 1 or 2 straw man proposals
<Art> DO: what about the proposals that Tyler proposed
<Art> TR: the question isn't where the PEP resides but how to split the complexity betweent the client and server. The client will not be eliminated from the decision, regardless of the architecture.
<Art> ... The only way to eliminate the client completely is to mint a new HTTP method
<Art> ... But that would create a huge deployment problem.
<Art> ... There will always be some policy enforcement on the client.
<Art> ... Can only entirely move the decision to the server if the client is certain the server can do 100% of the policy decision.
<Art> [Scribe missed some details ...]
<Art> JS: please send this to the mail list
<Art> ACTION: Thomas submit proposal to the mail list regarding the policy decision split and complexity [recorded in http://www.w3.org/2008/01/23-waf-minutes.html#action01]
<trackbot-ng> Created ACTION-154 - Submit proposal to the mail list regarding the policy decision split and complexity [on Thomas Roessler - due 2008-01-30].
<Art> JS: we must understand the problems that will be solved by the other proposal
<Art> TR: agree
<Art> AB: agree
<Art> ACTION: Jonas send a request for comments regarding the policy decision questions and issues [recorded in http://www.w3.org/2008/01/23-waf-minutes.html#action02]
<trackbot-ng> Created ACTION-155 - Send a request for comments regarding the policy decision questions and issues [on Jonas Sicking - due 2008-01-30].
<Art> AB: what do we want to discuss?
<Art> AvK: prefer to discuss on the mail list
<Art> JS: I agree
<Art> DO: think we need to discuss requirements
<Art> TR: would prefer requirement discussion on the phone
<tlr> chair's call, I gues
<Art> DO: think it's hard to follow some of the detailed discussions related to requirements
<Art> AB: what is your plan Anne to address the comments on reqs?
<Art> AvK: I will respond on the mail list
<Art> AvK: I don't think we should delay the work to get everything documented
<Art> DO: but we don't have agreement with what is documented
<Art> AvK: if someone disagrees, they need to submit comments
<Art> TR: we don't have agreements
<Art> ... we need to go through the requirements and discuss them
<Art> AB: who is going to drive this?
<Art> JS: I responded to Jon just now
<Art> TR: I don't have much to add to beyond what I said on the mail list
<Art> ... may be able to merge 13 with #1.d
<Art> JS: It would be good if comments included proposed changes
<Art> AB: any other questions about TR's comments?
<Art> AvK: I haven't read it yet
<Art> JS: me neither
<Art> AvK: could someone give me some ABNF help?
<Art> DO: I can help.
<Art> AvK: thanks!
<Art> AvK: it would be good if there was a proposal for specific reqs before the call.
<Art> AB: any issues with that?
<Art> JS: no
<Art> AB: sounds reasonable to me
<Art> TR: Art should solicit input on specific reqs and add them to the agenda
<Art> AB: I'm OK with that
<Art> DO: one thing we can do is to pick a couple of issues that we want to get closure and give ~ 1 week notice.
<Art> AB: good idea Dave
<Art> AB: Mark's comments about needing to look at P3P
<Art> AB: what is the issue?
<Art> AvK: I think we want per resource
<Art> JS: not clear if P3P was being suggested as something we should use or something we should look at
<Art> ... can put the policy file in a header
<tlr_> P3P use case is slightly different. The policy is retrieved in a special safe zone.
<Art> JS: I think Mark was talking about a mechanismm to associate a policy and a URI
<tlr_> (don't remember the spec's precise name for that)
<tlr_> +1 to JS actually
<Art> AB: Mark suggested this should be added to the Issue List.
<Art> ... What do you think?
<Art> AvK: too vague to know if that is true
<Art> JS: agree I'm not sure what he's looking for
<Art> TR: think he is concerened about scalability (e.g. Akami)
<Art> AvK: we need to ask for clarification
<Art> ACTION: Anne seek clarification from Mark about the P3P-related issue [recorded in http://www.w3.org/2008/01/23-waf-minutes.html#action03]
<trackbot-ng> Created ACTION-156 - Seek clarification from Mark about the P3P-related issue [on Anne van Kesteren - due 2008-01-30].
<Art> AvK: I think we need a plan on how to move forward
<Art> ... e.g. new questions all the time
<Art> AB: I'm open to suggestions on how to move forward
<Art> AvK: I think the design is good
<Art> ... but there is a call for more rationale
<Art> ... dont' want to keep discussing reqs but prefer to talk about technical issues
<sicking> -q
<dorchard> I remain convinced that the design is reflective of an implied set of requirements, of which there is not consensus.
<Art> TR: regarding Voice Confs, I have this slot on the 30th
<Art> ... will need to send regrets on the week of Feb 6
<Art> ... OK on Feb 13
<Art> ... but then it gets more difficult
<Art> JS: I can reiterate we are running out of time
<Art> ... I am nervous about getting this in FF3
<Art> AB: I propose we plan to have a call next week
<Art> TR: are we expecting to stick to this timeslot for the forseeable future?
<Art> AvK: this time is good
<Art> JS: me too
<Art> AB: me too
<Art> AB: meeting adjourned
<Art> ScribeNick: Art
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) Found Scribe: Art Inferring ScribeNick: Art Found ScribeNick: ArtB WARNING: No scribe lines found matching ScribeNick pattern: <ArtB> ... Found ScribeNick: Art ScribeNicks: Art, ArtB Present: Art Anne Dave Jonas Thomas Agenda: http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0223.html Found Date: 23 Jan 2008 Guessing minutes URL: http://www.w3.org/2008/01/23-waf-minutes.html People with action items: anne jonas proposal submit thomas[End of scribe.perl diagnostic output]