W3C

- DRAFT -

W3C Technical Architecture Group (TAG) - Teleconference

2 Jul 2007

Agenda

See also: IRC log

Attendees

Present
Tim Berners-Lee, Dan Connolly, Henry Thompson, Rhys Lewis, T.V. Raman, Norm Walsh, Stuart Williams
Regrets
Noah Mendelsohn, David Orchard (apart from late in the meeting)
Chair
Stuart Williams
Scribe
Rhys Lewis

Contents


<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 128.30.52.16 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

Convene

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?

Stuart: Yes

Dan: Would be good to have additional time

Stuart: We'll talk off line

Approve Last Week's Minutes

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.

Review request for Enabling Read Access for Web Resources

<Dan> No path in access item, etc. Tim Berners-Lee (Monday, 21 May)

http://lists.w3.org/Archives/Public/www-tag/2007Jun/0145.html

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

httpRange-14

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 tag@w3.org

<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

<timbl_> http://images.google.com/images?q=awww&hl=en&client=safari&rls=en&um=1&sa=X&oi=images&ct=title

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

s/Deferene/Dereference/

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

General agreement

Henry: We have some people away next week

Stuart: This is the case for several weeks over the summer.

Versioning finding

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

<Stuart> "http://www.w3.org/2002/09/wbs/34270/summerAvailability2007/results"

<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.
... Wer

<Stuart> Propose to cancel 23rd July, 30th July and 6th Aug

<Norm> I thought we had resolved to cancel them

<Stuart> http://www.w3.org/2007/07/02-tagmem-irc.txt

<Stuart> RRSAgent make log public

Summary of Action Items

[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/09/24 11:55:47 $