See also: IRC log
<Henry> Norm, Dan -- can you read www-tag online OK? My browser is hanging. . .
<Norm> Yes, works fine for me, Henry
<Henry> Nope, still stuck -- nslookup lists.w3.org is 18.104.22.168 for me -- you too?
<Norm> Yep, for me too, Henry
<Henry> Stuart, can you see www-tag OK? Specifically, http://lists.w3.org/Archives/Public/www-tag/2007Jun/ ?
<Dan> (reviewing agenda, it occurs to me that for "Enabling Read Access..." , it would have been nice to have that in the same meeting as passwords-in-the-clear, in that they're security-related. )
<scribe> scribenick: Rhys
Stuart reviews the agenda and claims it could be a short meeting
Dan: Confirms he can scribe for next week
Stuart:Are their any AOB or requests for agenda items for next week
Dan: Do you send the agenda at end of day on Friday?
Dan: Would be good to have additional time
Stuart: We'll talk off line
Stuart: Propose to accept last week's minutes
Stuart: Hearing no objections, resolve to accept
RESOLUTION: The minutes of the 25 June teleconference at http://www.w3.org/2001/tag/2007/06/25-minutes are approved.
Dan: Thinks that lack of distinction between resource and representations is not a problem
Henry: Thinks it might be
<Dan> (it's not a problem that shows up in the way software behaves, that is.)
Tim: You write a script to access data from behind a firewall and it can it because its a browser
Henry: Help me out with this example. I download a page from a known site A. Script on that page accesses a document somewhere else
... Right now, the same domain access rules doesn't allow that.
... Seems that this opens up a hole that causes me to loose protection. Right now, no resources can be accessed that are outside a site
Tim: This is not to prevent damage to your machine.
Dan: Tim can you acknowledge that Henry's example causes increased risk?
... Script changes on site A to grab data from a 'bad' site B. Right now that can't happen. But if this spec is adopted, site B can simply define that the resource can be used by anyone and the cross domain protection is lost.
Tim: The main reason for the cross domain restriction was to protect information behind firewalls
Henry: Then I accept that this specification does have that effect
Dan: It may be that that was the original motivation, but there is a side effect that the restriction would help in the case where a site has been compromised
Tim: but then if the site is compromised it could do anything it wants, and there are other mechanisms that could be employed by the 'bad guys'
<Henry> XSS is the common acronym for Cross Site Scripting
Henry: It's called cross site scripting
<Henry> which is what the cross-domain restriction prevents
<Dan> (I find http://en.wikipedia.org/wiki/Cross-site_scripting ; the first hit I found was http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0240 )
Henry: I just searched and found a discussion about whether or not the restriction should be maintained for xmlhttprequest
Norm: I think that Tim is correct. The danger is that a script can get information from confidential sites.
... It wasn't a vector for viruses, it was a vector for identity theft.
Henry: Ok, so in that case I understand. Is it apparent that this is the case from the spec?
Rhys: I don't think that the motivation is clear from the spec, nor is the mechanism
Stuart: There is a section in the spec where this might live
<Zakim> timbl_, you wanted to sy that the sec needs a summary of the attack in th eintro
<Dan> (re "that's not a TAG comment per se", I'm increasingly of the opinion that the TAG is, while perhaps not presently filled with security experts, in the best position to deal with security issues in W3C specs, as they tend to be cross-WG issues)
Henry: I think that my concern is not a TAG concern, but is one that I may respond with
Tim: I think that the introduction does need explanation of the attacks that are being condsidered
Dan: You may ask, but they may not respond because typically people don't document the things against which they are providing protection
Stuart: Is it worth asking?
Dan: I'd like to see it, but I'm not sure they'll provide it.
Stuart: I was expecting something different. It seemed the other way around.
... It was a better design than I expected
<Zakim> timbl_, you wanted to note that pubic must be a very large proportion and should be optimzed for
Tim: The document has a mechanism that says scripts from a particular set of domains can access content
<timbl_> Content-Access-Control: allow *
Tim: I've been thinking about what it means for public documents.
Henry: The access should be * shouldn't it?
Tim: People know what I think about PIs
... I think the HTTP system is superior. A test would be to ask the W3C webmaster to implement it.
Henry: I think it's bizzarre
<Zakim> Dan, you wanted to ask if any HTTP headers are in this design
Dan: Is there an HTTP header
... The name is much too long.
Tim: I will ask the W3C webmaster to put this on every W3C public document.
Stuart: Aside from Rhys' comments, I noted two other comments. Header name too long, and request to explain why the mechanism is secure
Henry: I think Tim is right and that it needs to be in the introduction.
Dan: But there is text in the introduction about this
<Dan> ("threat model" is the term of art, I think)
Tim: That doesn't explain the particular situation covered by the spec
Henry: I would not be happy if the header name were to be just CAC, rather than Content-Access-Control
<Zakim> Henry, you wanted to 2nd Dan in part
Dan: There is a critical difference between requests that fit into one packet and those that need more
Henry: But we're only talking about responses here
Tim: From the point of view of the IETF community, could we point to something about the volume of HTTP traffic?
... Could be traffic implications and cost, for people who pay for their traffic
Dan: TE (transfer encoding) is a precedent for short names
Stuart: seems as though the point I made on feedback fell apart. Can someone summarise?
Tim: Do we have consensus that the intro could do with explanation
Generally - Yes
Dan: I'll follow up with comments on the header thing
<Dan> (one in RDF?")
Henry: We now have two ways of making assertions about sets of URIs in two different ways. One is regular expression-like and one uses RDF
<Dan> (ah... overlap with POWDER. quite.)
Henry: If these are a compact syntax and an expanded syntax for the same thing, it would be better if they were compatible
Dan: Should ask POWDER WG to review the spec.
Tim: POWDER is tackling the general question. So asking WAF to ask POWDER to provide a simple form of the expressions could be one approach
Henry: What about asking WAF to use POWDER to define the semantics of their patterns
<Zakim> timbl_, you wanted to argue the importaance of NOT using full regexp, but prefixes where possible
Tim: I've thought about putting the POWDER approach into code. Whenever you access a URI, you need to check whether it is covered by rules like this
... Have wondered about asking POWDER about constraints based on prefices
... For this, the domain names are the wrong way around
TVR: You need the java package name approach
Tim: Yes, if the check was against the reversed domain name as a prefix
TVR: This would be ok as long as you don't treat the URI as simply a string
Tim: When you do something like this then it can speed up the look ups
Stuart: Reminds me that they don't default to port 80 if there is no port specified
Tim: Seems like a bug to me
Stuart: Seemed to be a thread encouraging commonality between POWDER methods and the set of access items
Henry: How about the TAG sending a message to the two working groups pointing out the overlap
Tim: Usually it needs more than that
Stuart: Do you have a proposal Tim?
Tim: Well, I suppose we could respond by asking them to come back with a consistent architecture with POWDER
<timbl_> It ISNT access control
<timbl_> It is declaring stuff public
Tim: I don't think it should be called access control, either. It doesn't prevent access
Stuart: Well it does, but it's client side
Tim: It's more like access policy than access control. It's defined by a site that is giving the material away anyway
Henry: Also, browsers don't have to implement this spec. Access control feels more like server side
Stuart: So I have introduction including more explanation, Dan has already written to them about the header length,
<scribe> ACTION: Stuart to write to the chairs of the working groups about the overlap [recorded in http://www.w3.org/2001/tag/2007/07/02-minutes.html#action01]
<trackbot-ng> Created ACTION-3 - Write to the chairs of the working groups about the overlap [on Stuart Williams - due 2007-07-09].
Henry: Would like to see a draft before it goes. Silence means assent
Rhys: Other comment was that the only normative part seemed to be within the algorithm rather than also being in some normative explanation
Stuart: Energetic thread on our list about terminology
<Zakim> Henry, you wanted to comment on the matter at hand
Henry: Noah's recent contribution goes to the heart of the matter and I think progress is being made
<Stuart> wanted to add wrt to the value of an accurate record (ie. email trail)
Dan: I think there could be value in discussion
Tim: I think that a lot of the discussion is terminology not architecture
... Access as an english word doesn't imply that it has to be used against resources as opposed to representations
Henry: I read access as meaning that if you can access it you have got your hands on it.
Tim and Dan disagree with Henry about this
<Stuart> FWIW to my mind access in some sense is to provoke a response (from the resource).
Tim: Can we think of a better word than access? In any case, we just have to define a particular vocabulary
Henry: I understand. In this case, we don't use access a lot, we use dereference more. Does dereferencing a URI mean getting your hands on something?
Dan: Yes. I think it means HTTP Get
Henry: This is stronger than access
<Dan> (I wish readers of the minutes good luck figuring out what "it" and "this" refer to ;-)
Tim: I think that access is a good word for the relationship between the resource and the URI
... There are two routines. Look up an object, which dereferences every URI related to an object, and just dereferencing a URI
Henry: Dereference relates a URI and a representation of a resource.
... I think that I can trace the confusion back to the notion that you can ever access a resource.
<dorchard> I have just sent a link to updates to the versioning finding docs to email@example.com
<Zakim> Stuart, you wanted to note that people typically use derefernce to mean GET
<dorchard> I'd like to talk to them in about ten minutes, I can dial in then.
Stuart: I noted that dereference is commonly taken as synonymous with HTTP GET, and that seems to be two things.
... Dereference is moving to the other end of the pointer and access is any HTTP operation
<Dan> (yes, "dereference" was a poor choice of words; it's suggestive of identification as much as access.)
Henry: That's a legitimate story but is distinct from either of the other two stories. It seems to make dereference weaker than access
Tim: Maybe we should modify the document by removing access?
Norm: I recall struggling with this when we were working on the document. We used access because we felt that it was easier to understand
Henry: It's also clear that the section the quote comes from (3.1) that it tries to be catholic about schemes and then moves on to HTTP
<Zakim> Dan, you wanted to suggest the httpRange-14 finding is the next place I want to get this right; filing webarch errata is moderate cost; re-issuing webarchi is high cost
Dan: httpRange-14 is where we have a chance to get this right. I'd rather get this right in this particular finding before we think about updating the webarch document
Stuart: In which case, the current working title is interesting, because it says Dereferene
Stuart: I think that Pat feels that dereferencing doesn't touch the resource.
Henry: I think that dereference doesn't make sense in Pat's world
Stuart: He also thinks we conflate access and reference
<timbl_> What could we use instead?
Dan: We don't actually use reference. The issue may be use of dereference. I don't have a suggested alternative
Henry: In Pat's vocabulary, reference is ineffable, it does not imply an operation
... In that world, you wouldn't use dereference in the way we do in the Web at all
... So the first thing we would need to do is clarify that dereference takes almost none of it's meaning from the sense of reference
... Denote would be an alternative to refer
Tim: As a verb, I can refer to something using an identifier
Henry: They are related, but are different parts of speech. But they are in the same area of philosophy
Tim: Dereference comes from programming languages
Henry: I think Noah's example of memory locations is a really good example. They can be denoted and dereferenced
<Henry> I would have said they denote, but they can none-the-less serve as the basis for retrieval
Discussion about the nature of equality
Tim: So we do use dereference in a funny way in the context of the philosphy around denote
... Would making a circles and arrows diagram be helpful
Stuart: I thought you were making good progress about relating the way we use terms and the way the philosophy of language uses them
... Would be good to close that
<Henry> Here's a picture that tried to use non-WebArch terminology to try to get clear on all this: http://www.cogsci.ed.ac.uk/~Henry/webpropernames/img2.png
Henry: I will try and join this thread when I can
... The diagram doesn't use web terminology
Tim: I don't want to use this if it doesn't use web terminology
Henry: The distinction I think we need to make is between the HTML representation itself and the weather report itself.
... The rendered version of the HTML that the browser displays is something that webarch doesn't seem to name
<Dan> aha... found my diagram... http://www.w3.org/2001/tag/fdesc54/
Henry: That's why I didn't use webarch terminology for the diagram
<Dan> in particlular http://www.w3.org/2001/tag/fdesc54/slides.html
<Henry> Dan's picture is the same as the one in WebArch
Dan: I have a diagrams from 2003 that might be interesting.
Stuart: Should we schedule more time for next week and ask Dan to walk through the diagram
Henry: We have some people away next week
Stuart: This is the case for several weeks over the summer.
David: Been updating versioning finding. Items from F2F plus comments from individual TAG members. Still a few things to do
... One possibility is to discuss this next week, but then I'm gone for several weeks
Dan: What's the summary of changes?
David: Pretty extensive changes throughout the document. Better definitions, stronger material
Stuart: Happy to schedule 30 mins for next week's call for feedback and discussion. Could be that more time will be needed
David: Earliest after next week would be mid August.
Dan: It's worth doing if the people who had comments that were dealt with can look at the documents
<Dan> (It'll help me if norm and/or stuart will send mail about versioning drafts)
<Norm> (I'll send mail)
Stuart: Dan suggested meeting schedule discussion. Results show three weeks in July where we are short by 4 TAG members
... Question about having meetings for three weeks over the summer
16 and 23 July and 6 August
Tim: Could just have informal chat on IRC instead or voluntary sessions instead?
<Norm> 23 July, 30 July, and 6 Aug, I htink
Dan: Inclined to cancel those three dates
Stuart: I think we'll cancel those three meetings.
<Stuart> Propose to cancel 23rd July, 30th July and 6th Aug
<Norm> I thought we had resolved to cancel them
<Stuart> RRSAgent make log public