See also: IRC log
nm: Welcome Peter. Let's go around doing brief introductions.
jar: (intro)
ht: (intro) sgml, xml , more recently status of uris in webarch
dka: (intro) mobile web, privacy, social web
timbl: (intro) DIG, privacy, policy, semweb UI
ashok: (intro) standards, oasis, etc, rdb to rdf
plinss: (intro) css, gecko, print
as 1st-class citizen on web
... pre-css: object based editor on nextstep, design model.
Digital Style Websuite
noah: agenda review
... norm w is planning to spend all of wed. with us
noah: (re priorities session on
thu) we had identified 3 areas, larry has created a 4th area of
core technologies (mime, sniffing, etc)
... please think about tradeoffs
<DKA> DAP privacy requirements: http://www.w3.org/TR/dap-privacy-reqs/#privacy-notice
dka: Looking at DAP group's
document on requirements
... javascript apis that access things containing sensitive
information - just about anyting
... camera, address book, calendar, orientation, velocity
(pointing at table 'how each element is covered' with notice, consent, minimization, etc. rows)
dka: what might the tag do to
help promote privacy [control] on web?
... set of small, targeted docs that build on work of others
(DAP, UCB, others)?
... look at existing docs, amplifying, put in specific web
contexts. e.g. (for instance) Hannis (sp?) doc is general, DAP
specific to DAP, connect them.
projecting the API minimization note
dka: come up with several
examples of this idea in action
... want to sidestep Ashok's issue - about the Abelson et al.
paper pointing out that user dialogs are silly, since they
can't assess consequences
Ashok: Abelson et al suggests to consider legal accountability as alternative
dka: Vodafone privacy counsel
said (at workshop) things are coming together on that
front
... Minimization is not about this.
timbl: Need global change in
ethos regarding data use, independent of how they got it
... All these [tactics] need to be in the list
dka: Looking for technical
[tactics] that TAG might be able to say something about.
... image metadata capturing privacy intent?
... If you keep asking people about this, good results are
unlikely
timbl: What if you say: I want my friends to see my pictures. would be nice if software kept track of how/why friend got them, as reminder
dka: Problem - technical jargon in dialog boxes ('GPS coordinates' ...)
noah: You're saying the apps
should be able to say: I don't need more info than xxx.
... What about malicious apps.
dka: Remember this philosophical
approach. We tend to get distracted. Need to find particular
points to focus on.
... [Solve one problem at a time.]
noah: ... But my experience is
that most of the problems have to do with attackers
... and exploiters
dka: Problem comes with attacker
exploiting well-intended app. What to do to well-intended to
make it less vulnerable to exploitation
... We need to be clear that even if you do [any particular
thing], you won't have a privacy solution
noah: Problem is interacting with untrusted services that I need to use.
dka: The aggregate amount of info open to abuse is lower if you minimize. So several docs to chip away at specific things, not to provide comprehensive solution
<ht> http://www.cs.virginia.edu/~evans/cs551/saltzer/
<ht> is what JR is talking about
<ht> LM and JK join the meeting at this point
jar: security is just one way to support privacy... and need to do lots to get security. least privilege just one.
ht: Dan's answer did address
Noah's point. By specifying an approach that the platforms
subscribe, you bound the damage that the bad guys can do. If
they have less info, they can do less.
... You can reduce the bandwidth of any particular API call.
This raises the barrier.
dka: If the app only needs city location, but has to request fine grained location, ... is the right question being asked [or user, developer, app...?]
noah: Document needs an intro that sets expectations
masinter: Framing = it's warfare, we're minimizing the attack surface
<ht> There is a HF/UI design/human engineering issue here which won't go away, but micro-capabilities do create a real opportunity to reduce your exposure, much as they make me tear my hair out as an implementor
masinter: To say there's a way around a defense, is not an argument against the defense
<noah> I also wanted to make the point that: dealing with access control (or legal means) that will prevent malicious apps from getting info they shouldn't have is crucial -- even if none of the solutions we have now have been shown to work very well (e.g. because users say "yes" to everything)
<Zakim> ht, you wanted to support DKA wrt NM's use case and to give the Mark Logic API parallel
ht: I use two different xml
database systems... the 'open' one has unix style object
protection - file x RW
... the commercial one has about 60-70 capabilities. almost 1-1
on API calls, file x cap
... bigger effort to manage for both users and
developers.
... you get high degree of control. Compare minimization. You
have to get informed consent, but if it's granular enough you
get questions that are specific enough to make sense
dka: Resistance to normative
requirements for UI design, esp. re privacy
... The minimization approach doesn't impose specific UI
requirements. This might enable creative UI design
johnk: There's always a
useability tradeoff in security. E.g. facebook has tons of
knobs
... but underneath there's a simple set of access control
privs
... e.g. app needs to do something special to get email
address
... This is a usability issue, a tradeoff
dka: Re minimization, the approach stands, since it says nothing about the user interaction. [API and UI needn't slavishly correspond]
<Zakim> johnk, you wanted to mention the FB API model
noah: Proposal?
<noah> I'm asking: what do you propose we do that will have real, useful impact for the community?
dka: Useful output might be: Umbrella document. Privacy and webarch. Subdocuments, e.g. minimization.
masinter: Big discussion on privacy in larger community. Our schedule should coordinate with external events
<Zakim> masinter, you wanted to talk about participating in larger discussion
masinter: What does API minimization have to do with HTTP?
jar (under breath): there are HTTP APIs
<masinter> my point is that if we're trying to decide what to do with some work that was focused in one group to generalize the principle in a way that it applies to all W3C work and not just to the work of one committee
noah: DKA, can we get together and make a straw-man product proposal?
masinter: E.g. can be a problem
sending info in Accept: headers when it's not needed in order
for server to do its job
... Trying to suggest how to expand this from a DAP point to a
TAG point
timbl: (masinter, you missed the beginning of the session)
(break)
http://www.w3.org/2001/tag/2011/02/security-web.html
jk: I was asked to frame section
7 of the webarch report on apps
... Wanted to echo [style of] Larry's MIME writeup
... If you start with browser/server/protocol, and trace
history of the three with a security focus...
... start with just getting a doc.
... then more support in http. history in doc is well known but
worth reviewing
... NN2 introduced cookies, and cookies needed origin
<masinter> http://tools.ietf.org/html/draft-ietf-websec-origin
jk: Related to lots of security issues. State in protocol. Origin and document not linked securely. Why should you trust the DNS?
timbl: It assumes there's a social connection between - and -. There was a trust model, it just wasn't cryptographically secure.
jk: These are layered protocols, that makes security harder. eg. DNSsec isn't bound to higher protocols
ht: scripts??
jk: Dynamically loaded scripts not subject to SOP
noah: XML and JSON is good example - the weaker language was subject to tighter security controls - dumb
ht: script with a source tag predates JSON. it was never subject to SOP ??
<masinter> http://en.wikipedia.org/wiki/HTTP_cookie
timbl: Suddenly all these APIs have this extra parameter, the calling function ...
<timbl> the function to be called by the injkected script tag
jk: Cookies were easiest way to
do session indicator. shopping carts and so on.
... AJAX was other driver
... XHR does use SOP, but using JSONP you can circumvent
it
... apps send cookies from one place to another
... Trying to abstract away, to find security issues as opposed
to implementation bugs. What issues are architectural in these
examples
... One is, when doc contains multiple parts, contributed from
different security domains
noah: (When did we stop using the term 'representation'?)
jk: If you don't mediate the
interaction, e.g. using sandbox, bad things happen.
... e.g. runaway cpu time
... Silent redirects. Malicious site forwards, cookies sent to
2nd site -> clickjacking
... Authentication based on Referer: (i.e. referrer)
header
... Servers depend on client to do the right thing, in
particular proper origin processing
... Specs are difficult read, so there can be broken user
agents.
... My advice: Server should not trust user agents. What are
circumstances in which you can server can align with user
timbl: We need to preserve the role of the user-agent as the agent of the (human) user.
johnk: Yes, but we need to be a bit more nuanced. There shouldn't be inordinate trust in a class of agents. One should only need to trust an agent to a certain degree.
noah: Users don't understand UAs well enough to be able to discriminate..
<masinter> somehow I want to bring in http://www.schneier.com/book-sandl.html'
timbl: That doesn't diminish the
responsibility of UAs
... One of the the things the TAG does is to ascribe blame
johnk: Who's responsible for a clickjacking attack? Software was behaving per spec
masinter: Users are presented choices that they don't understand
johnk: Not much you can do about that -
masinter: don't require users to
make decisions that they don't understand. design
principle.
... optimize a match between what user wants and what happens.
doesn't matter whether choices are simple or complex
pl: You said simplicity might be better - maybe so at user level, not nec. across the system
<masinter> complex choices are less likely to be understood, but simple choices might be a problem
(scribe notes that henry suggested just the opposite. see above)
jk: Cache poisoning might mean no link between IP and domain name... in fact no way to guarantee domain name ownership
<masinter> want to talk about TAG work in context with http://datatracker.ietf.org/wg/websec/charter/
<masinter> Oct 2010 Submit 'HTTP Application Security Problem Statement and Requirements' as initial WG item. -- don't see that document
jk: ssl... data not encrypted on hotspot
timbl: Firefox 'get me out of here'
jk: When you run web content, the content starts being rendered immediately - there is no install step. It just starts running
ht: I've been manually virus checking every downloaded app. Can't do this with pages
masinter: some antivirus sw modifies the HTTP stack
noah: Also you lose the ability
to make sticky decisions. Nextbus is an example of
non-installed app but that you come back to repeatedly
... you keep getting asked for permssion to use location.
annoying
timbl: But most browsers do this well ?
jk: Lack of tie-in between host
naming and where you access the doc (where published)
... who is responsible for the content of the document?
Nonrepudiation.
timbl: You can sign the document until you're blue in the face ...
noah: Doc is written by an expert, would be helpful if some of the examples were spelled out in more detail
masinter: Security WG calls for a
[...] document. Is what we're doing related to their work
item?
... They have a bunch of specific documents, but nothing at
this level
jk: Their docs are very narrow
masinter: No, look at their charter
Oct 2010 Submit 'HTTP Application Security Problem Statement and Requirements' as initial WG item.
masinter: Isn't this what we're doing?
jk: The issue of mime sniffing. It became a good idea for the browser to ignore media type... problem is guessing user intent
(slight aside)
jk: So what would be desirable properties of security webarch? (reviewing doc)
noah: please clarify use of 'web
agent'
... 'tie' isn't evocative - what constitutes success? what
system properties are we after?
timbl: E.g. maybe avoid separation of authentication and authorization
jk: App layer with signed piece of content, same key should be used in both levels of protocol stack (or at least related)
timbl: WebID people have expereienced this need - converting keys between apps / layers - PGP to log in using ssh etc.
ht: I'm having to use Kerberos - very inconvenient - when I ssh from laptop home I need a kerberos principal... way too much work... [so unification cuts both ways?]
timbl: but kerberos isn't
public-key
... The thing about connecting the two parts together is
valuable
jk: WebID is a case where it can't be done. User generates a cert, puts it in foaf file. Impossible to tie foaf description of me with me the person.
masinter: can show 1 person wrote 2 things
noah: Same issue as in PGP - you have to be careful when first picking up the key
jk: what's the purpose of
encrypting the assertion (in webid)?...
... 3rd bullet in properties section: We should be able to do
what the original web design wanted us to do
timbl: But doesn't CORS do this for us?
jar: Controversial.
<masinter> W3C TAG should be a participant in overall work on web security, including other work in IETF and W3C
<noah> ACTION-417?
<masinter> action-417?
<trackbot> ACTION-417 -- John Kemp to frame section 7, security -- due 2011-01-25 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/417
<masinter> ACTION-417?
<trackbot> ACTION-417 -- John Kemp to frame section 7, security -- due 2011-01-25 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/417
masinter: There's ongoing work. We should review it regularly and be seen as a participant. The way to do that is to publish a note, and announce, repeat. But be clear that we're not trying to take the lead.
noah: But the action was to frame a section of our document...
<masinter> The W3C chapter on security on the web could identify that there are some issues and point at other groups that are working on the problems
<masinter> W3C TAG should have input on W3C activities decisions, and this should be a W3C activity, on "security and privacy"
ashok: Let's close 417, start another one to write a note. If that becomes bigger/better, fine.
masinter: In general the TAG should be more involved in setting up W3C activities.
timbl: So far it's just been a series of workshops, not an activity
ashok: Privacy at w3 is morphing
masinter: Would like to see a note out before Prague meeting (end of March)
<noah> noah: any objection to a proposal to close ACTION-417, and have John publish what he's got, slightly cleaned up, as a note with no formal status, but at a stable URI. Noah will help.
<noah> Larry will help too, and would like this done in time for IETF in Prague.
<noah> PROPOSAL: close ACTION-417, and have John publish what he's got, slightly cleaned up, as a note with no formal status, but at a stable URI. Noah will help.
<noah> No objections.
<noah> close ACTION-417
<trackbot> ACTION-417 Frame section 7, security closed
<noah> action John to publish http://www.w3.org/2001/tag/2011/02/security-web.html, slightly cleaned up, with help from Noah and Larry Due: 2011-03-07
<trackbot> Sorry, couldn't find user - John
<noah> action Larry (as trackbot proxy for John) who will publish http://www.w3.org/2001/tag/2011/02/security-web.html, slightly cleaned up, with help from Noah and Larry Due: 2011-03-07
<trackbot> Created ACTION-515 - (as trackbot proxy for John) who will publish http://www.w3.org/2001/tag/2011/02/security-web.html, slightly cleaned up, with help from Noah and Larry Due: 2011-03-07 [on Larry Masinter - due 2011-02-15].
<noah> ACTION: Noah to talk with Thomas Roessler about organizing W3C architecture work on security [recorded in http://www.w3.org/2011/02/08-tagmem-minutes.html#action01]
<trackbot> Created ACTION-516 - Talk with Thomas Roessler about organizing W3C architecture work on security [on Noah Mendelsohn - due 2011-02-15].
<DKA> Scribe: Dan
<DKA> ScribeNick: DKA
[roll call]
Noah: Ted is joining us.
Noah: [background] there are
certain resources w3c publishes on its website - e.g.
dtds...
... certain organizations were [fetching] these resources a
lot.
<ted> summary Yves wrote of actions taken by W3C
Noah: practical question: what can be done? Architectural question: what can be fixed in the architecture?
<ted> article on DTD traffic
Noah: one angle proposed is :
what would be the role of a catalog? You could tell people that
certain resources won't change or won't change any time soon so
they could build [their products] not to fetch these
resources.
... Anything else from Ted?
Ted: We've employed some
different techniques - for certain patterns we've given http
503 after reaching a threashold. At peaks, we see half a
billion a day. Starts to become a problem. Sometimes this has
resulted in blocking organizations.
... if it's an organization that is a member then we pursue
through the AC rep...
... this doesn't scale well.
... there are several big libraries - eg. msxml - they've put a
fix in which has led to a sharp decline.
... Norm Walsh came up with a URI resolver in Java that would
implement a caching catalog solution but this never made its
way into Sun JDK.
... Sun has been bought by Oracle so now we are talking to
Oracle engineers and they have been responsive. Trying to see
if we can get something into next JDK.
... We had a fast response from Python.
Noah: Do you ask these people to implement caching or a catalog?
Ted: We suggest either. I like
the caching catalog solution [from Norm].
... we educate, we block, we have a high-volume proxy front-end
that distinguishes traffic...
... when we explain to people that this is not good
architecture - receiving the same thing over the network
100000's times a day - they agree.
... we probably should be in the business of packaging and
promoting the catalog. Henry has done some work on this.
... the idea we came up with - find the most popular ones based
on traffic and we routinely package these up, have RSS feeds to
alert to catalog changes, talk to Oracle, Microsoft, Python,
etc... get some of the bigger customers out there to adopt the
catalog.
... meta-topic (that the TAG is concerned with) is the
scalability of URIs in general. There is a lack of directives
to do rate limiting, to set boundaries, how to scale URIs...
Could be useful in dealing with DDOS attacks.
<Zakim> timbl, you wanted to wonder about RSS feeds fro updates to things with distant expiry dates.
<masinter> who's here?
Tim: We don't have real push technology available (apart from Email) but supposing we make a package [a catalog] and we send them out. Then an erratum comes in for something that has a 12 month expiry date. Do we need a revocation mechanism?
Henry: I think there's an 80/20
point. Speaking as a user, I'm grateful for the shift from the
503s to the tarpitting.
... the delay of 30 seconds helps people to remind people to
get the catalog.
... so that's a step forward. In response to Tim: the HTML DTDs
are close to 80% of the problem, and they are legacy, they are
not changing. If there were turn-key solutions for the tools
that legitimately need those DTDs to validate - that made it
easy for system administrators to install the catalog that would cause the tools
to find them, then I don't think there's an expiry problem.
Tim: We have to consider the new and the old separately.
<scribe> ... new systems could be designed differently. The total load on the server from the HTML dtd will go down over time.
Tim: My proposal - the old is
finite damage, in the future we can issue different systems.
This connects to an alternative to catalogs - promote a version
of http that is much more robust, which could help Ted and
could also help with other situations where someone has been
disconnected from the net (e.g. the recent situation in Egyot).
The new http version could use a number of different algorithms
(e.g. P2P) to find the resource you are after.
... so that the chance of finding a copy locally (of a DTD)
would be quite high.
... after the Egypt situation, there's been a lot of interest
in this.
... I'd love to have the TAG push that forward.
<Zakim> timbl, you wanted to mention HTTP automatically morphing to P2P when under stress
<Zakim> noah, you wanted to talk about what's required vs. what's desirable
Noah: I think the role for the
TAG is to talk about the broader problem that is not specific to
particular resources like the HTML dtd. When an organization I
worked with
come across this problem, the response from some was "well
you should be running a proxy" - that sounds good, but
for that organization running a proxy would have meant paying
for and maintaining racks of proxy servers, and in the many cases
where caches miss, adding overhead. As it turned out, buying
more T1 lines or whatever was far cheaper than running
the proxies. Most importantly, I don't believe that
failure to run a proxy violates any normative specificastions.
... so: we could clarify the responsibilities that people have
to cache or to not cache.
... should we change the normative specs?
... [some will push bacl]
... for long term - we could break open this protocol http
version 2.
Ted: Looking over the rfc-2616,
the language is "should" around caching of http.
... it's optional and treated as such.
... lighter-weight implementations tend to be very
barebones.
... I think promoting catalogs is the way to go - and we should
work to get major libraries to include it, ship it, and have it
enabled by default.
... I think the focus for the TAG should be in the meta
problem. How to make URIs and web sites scale.
... Sites do get overwhelmed. There is no way to let consumers
of this data know what is acceptable behaviour besides sending
back a 503.
<masinter> should also note that HTML itself has gotten rid of DTDs. But isn't main problem giving out "http:" URIs in the first place?
Ted: we see lots of sites experiencing similar problems.
<Zakim> ht, you wanted to speak up for the user
Noah: I read it as a MAY in rfc-2616
<noah> From RFC-2616 section 13.2.1:
<noah> "The primary mechanism for avoiding
<noah> requests is for an origin server to provide an explicit expiration
<noah> time in the future, indicating that a response MAY be used to satisfy
<noah> subsequent requests."
<noah> So, it's a MAY not a SHOULD.
Henry: I'm concerned about the message we're sending to students "you should produce valid html, valid XML, etc..." and yet when they try to validate their documents they have to wait 30 seconds, because the web page has the public identifier.
Tim: Why does the validator not cache it?
Henry: Because the number of validators out there is quite large, and the free ones (while they support catalogs) don't distribute the catalog of DTTs as part of their install.
<ted> [libxml from the beginning shipped w a catalog]
<masinter> valid HTML no longer has a doctype http://www.w3.org/html/wg/tracker/issues/4
Tim: That can be fixed relatively easily - the DTDs can be wired into the code for things that aren't going to change any more.
Henry: The crucial people you need to convince are the open source implementers.
Noah: in many cases, when you dig into what needs to be fixed, it is not straightforward to change all the implementations...
Henry: I am more worried about the people [students] who are the future of the Web. The people who use off-the-shelf free validator tools and get burned.
<Zakim> masinter, you wanted to give strawman: specs were wrong, so asking people to run a proxy is really only to compensate for our failures
Noah: should we undertake any work to help Ted and/or ongoing work.
Larry: I think it was a serious
design mistake to put a URL in a document that you didn't want
anyone to retrieve and not tell them that.
... all of these proxies are compensating for someone else's
mistake.
... I'm worried it was a mistake in more than one way. The
presumption was that if I send you a message with a pointer to
a DTD there is some expectation that you'll get the same DTD
that I meant you to get. But the lifetime of the message can be
longer than the lifetime of the DTD.
<Zakim> johnk, you wanted to note that waiting 30 seconds should be to encourage alternate behaviour
Larry: We should think of the architectural design flaw here and make sure we don't do this again.
<masinter> "there are no cool URLs, everything changes eventually"
John: Pragmatically, tarpitting requests that are overwhelming your server seems like the right way to deal with it [counterpoint to Henry's statement]. They should learn that they are doing something wrong.
<masinter> "the URL is already broken"
<Zakim> noah, you wanted to ask: is it a mistake?
John: I'm worried we're going to overthink this, when education plus pragmatic tarpitting could be the right response.
Noah: My inclination is close to John's. This is a big distributed file system. The system should cope with this, or else the specs. should be changed to make it an error to [request at a certain rate, not cache, whatever, TBD]
<timbl> We have to design for the scale free web an we should be able to have specific designs tailored to make the extreme case of the most popular document/DTD/etc work, but we should not let that blind us to the general needs o fthe long tail.
Noah: what's implicit in what John is saying - these things are there to be dereferenced, in principle, you can look at these DTDs whenever you need to. The burden should be on the infrastructure to gracefully degrade and provide fair service. Tarpitting is a fine, proposed recommendation of best practice here.
<Zakim> timbl, you wanted to long tail
Tim: There are lots of DTD-like things out there. We need to be able to copy with various different scaling. We could provide some specific tailored response for these w3c issues. There may be similar things with some libraries...
Noah: Let's say there 100,000 ontologies, getting a lot of traffic. Let's say if I work my way through 100,000 ontologies in a loop. Should I also be tarpitted?
Tim: No.
... I won't want to mess up the fact that in general you should
be able to dereference a dtd if you want to.
Jonathan: I'd like to hear more
from Tim about the economics. [Analogy:] there's a popular
library book. A library buys a copy. There's a lot of demand
for i so you have to get in line to get it. For physical goods
there is an infrastructure to support this.
... Publishers can take care of it.
Tim: For the case of harry potter, the book industry operates differently, because it's a different scale of usage.
Jonathan: Transaction costs [on the web] are so much lower. Inexpensive social expectations.
Jonathan: it's a question of economics in relation to social expectations. ... who pays for what.
<masinter> One downside of using URIs for things other than href@a and img@src is that these scale issues arise. This has been an architectural principle, to use html: URIs for things that you don't really intend to be referenced. it's not the only downside
<noah> I guess I just disagree that they should not be derefenced
<noah> On the contrary, we've said that when you make things like namespaces, we want you to use http-scheme URIs precisely so that you CAN dereference them.
<noah> Larry, these DTD references are like img src -- each of the references is from an HTML document.
Larry: there has been an
architectural principle for using URIs other than for HREFs and
IMG SRC .. that architectural encouragement has some downsides.
One of which is a scaling issue. You expect an IMG SRC to get
as many retrievals as the document. And HREF to get as many
requests as people clicking on it. So you can scale
appropriately. DTDs, namespaces, ontologoes don't follow that
model.
... The mismatch has led to a couple of problems.
<Zakim> noah, you wanted to disagree with Larry
Larry: let's acknowledge the problem.
Noah: [disagreeing on the different scaling model between DTDs and IMG SRC...]
Ted: To Tim's point: a software engineer comes up with a brand new ontology, puts it on his web site, it becomes popular - he will have the same headaches and hassles as we do.
Noah: If the Apache server came pre-configured to handle the load would you be happy?
Ted: Yes, for example, if Apache told search engines "I'm busy right now please come back later" then that would be good. You can't express in HTTP your pain threshold.
Tim: TCP works really well
because you stuff in as much as you can. It was designed at 300
baud times and it works at 300 gigabit times.
... You want to have negotiated quality of service.
Noah: That didn't come easily. Van Jacobson did a lot of hard and rather subtle work to get that scalability into TCP.
<masinter> speaking of Van Jacobson, http://en.wikipedia.org/wiki/Content-centric_networking
<Zakim> masinter, you wanted to say that the problem was the W3C published a STANDARD that pointed to a http URI rather than something more permanent and to
Larry: Van Jacobson - has an interesting project on content-centric networks that we might want to look into.
[debate on whether DTDs are intended to be retrieved or not]
Noah: Next steps...
<noah> ACTION-390?
<trackbot> ACTION-390 -- Daniel Appelquist to review ISSUE-58 and suggest next steps -- due 2011-03-01 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/390
Dan: I don't have an answer...
<ted> ted: the # (2-3?) of connection limit per ip gets in the way of user experiences as well, making CDN more popular. as administrator i would like to improve a user's browser experience (faster load time) and allow in some cases more concurrent connections
Noah: The simple answer is to [keep this on the back burner]. I need a proposal on what we should do and who does it.
<ted> ted: I also want to encourage search engines to crawl me and do so efficiently when convenient for me
Noah: I think we need a short finding on what people's responsibilities are regarding caching.
Henry: I will reach out to [authors of XML parsers].
Tim: We should write what we want clients to do.
<masinter> wonder if Henry could write up what he's asking and what they say or do?
Henry: A good idea is - what Ted mentioned - an adaptive caching mechanism.
Noah: We could talk about turing the MAY in rfc-2616 to a SHOULD.
Larry: I am against that. I think it's the wrong place.
Noah: When you have a piece of software that is in a position to detect repeated requests, you should cache.
<ted> [if caching was less optional and more widely deployed on net popular resources would scale better and performance would be better]
John: [supporting
tarpitting]
... I think it should be cached in the open source code
level...
<masinter> (a) I don't think we can quickly come to a conclusion, but (b) Henry has agreed to ask tool authors to do something, (c) think we could endorse what Henry asks if the tool authors are willing to go along with it
<johnk> Norm has written about this; http://nwalsh.com/docs/articles/xml2003/
[discussion of caching catalog and whether or not it's a catalog]
<masinter> for example, "clear my cache" for privacy reasons might not clear the catalog
Henry: the OASIS catalog is just a string-to-string matcher, matching HTTP URIs to loca disk copies.
Larry: for privacy reasons you might want to say "clear my cache" but that wouldn't clear my catalog.
Noah: What's implicit in John's proposal: separation of concerns.
Tim: I hope you wouldn't expect clients to spot that tcp connection is going slowly...
<masinter> there are several places to intercept this problem. The first is the choice of the URI scheme for DTD or namespace or ontology. Second is choice of server and server infrastructure for serving, when the URI scheme is "http". Third is design of client software, fourth is operation of client.
Noah: the server is creating a network that is robust against traffic access pattern. Different clients will make different choices. A client might not need to change anything [in the case of e.g. tarpitting]. [if you are not time sensitive]
Larry: Henry - I would like you to document what you tell [the implementors] and report back what they say.
Dan: on the p2p topic - should we be doing something here?
Henry: I don't know enough the next gen internet...
Tim: I don't think that internet2 is reinventing http.
<ted> [p2p has too much overhead (startup time to connect to peers) imho to be worthwhile for small resources. yves makes that point as well in his email]
Noah: This seems like an area
where if we succeed it will take a third of our bandwidth.
Rather than inviting people from the p2p community, we should
either back off and do small things OR get one or 2 people on
the tag to do a survey of what's out there and report back at
the next f2f.
... but we need people who want to put time into that.
Henry: over the next 2-3 years we
better start thinking about how much of webarch is going to
survive [with the next gen internet]. The interface between the
tcp/ip layer and the http layer has thus-far been very clean.
There's no guarantee that will be true 10-15 years from now.
The TAG needs to start thinking about how we (the We
... web) is going to survive.
... [clarifying] as the future becomes clearer, we need to
start tracking it ...
<Zakim> ted, you wanted to put that on rec
Noah: I want to focus this on next steps.
<ted> ted: ^^ comment on merits of caching. in practice as we've heard from noah the costs of maintaining caching proxies too high compared to bandwidth.
<ted> ted: glad to hear larry's comment. get library developers to implement what ht suggests. i heard ht (and others) liked norm's caching catalog. would oracle implement it in jdk?
<Zakim> masinter, you wanted to suggest Henry write that up
Ted: [ speaking in support of the caching catalog approach ]
DKA, you wanted to remind people that just because there is a next-gen or internet2 activity doesn't mean that will be the future of the internet. :)
NM: Ted, anything hi priorty you want the TAG to do?
TG: Day by day, we're getting by. The catalog work would be helpful. What seems really useful is for the TAG to tackle the meta-issue.
TG: Directives are potentially useful; peer-to-peer seems most applicable for large things.
NM: Large or high volume?
TG: P2P startup times are typically significant, so large resources.
ted> [and p2p could be intersting failover for http]
NM: Floor is open for volunteers
noah> ACTION: Larry to help us figure out whether to say anything about scalability of access at IETF panel [recorded in http://www.w3.org/2011/02/08-tagmem-minutes.html#action02]
<trackbot> Created ACTION-517 - Help us figure out whether to say anything about scalability of access at IETF panel [on Larry Masinter - due 2011-02-15].
<ht> trackbot, status?
<ht> ACTION: Henry S. to report back on efforts to get undertakings from open-source tool authors to ship pre-provisioned catalogs configured into their tools [recorded in http://www.w3.org/2011/02/08-tagmem-minutes.html#action03]
<trackbot> Created ACTION-518 - S. to report back on efforts to get undertakings from open-source tool authors to ship pre-provisioned catalogs configured into their tools [on Henry S. Thompson - due 2011-02-15].
<noah> . ACTION Peter to frame architectural opportunities relating to scalability of resource access
<ht> trackbot, action-518 due 2011-07-15
<trackbot> ACTION-518 S. to report back on efforts to get undertakings from open-source tool authors to ship pre-provisioned catalogs configured into their tools due date now 2011-07-15
<noah> ACTION Peter to frame architectural opportunities relating to scalability of resource access Due: 2011-03-15
<trackbot> Created ACTION-519 - Frame architectural opportunities relating to scalability of resource access Due: 2011-03-15 [on Peter Linss - due 2011-02-15].
<noah> close ACTION-390
<trackbot> ACTION-390 Review ISSUE-58 and suggest next steps closed
<noah> ACTION-514 Due 2011-03-01
<trackbot> ACTION-514 Draft finding on API minimization Due: 2011-02-01 due date now 2011-03-01
<noah> (that should have been fixed this morning)
http://www.w3.org/2001/tag/2011/02/HashInURI-20110208.html
Noah: I think this draft would be better if it focused on making a few key points.
Ashok: there is at the end a
section on recommendations...
... sections 4, 5 and 6 are the heart of it.
Noah: Can it be abstracted into a one or 2 sentence best practice?
[ looking through section 4 and picking out BP statements ]
<noah> I'm seeing as potential recommendations:
<noah> As the state of the resource and the display changes, the fragment identifier can be changed to keep track of the state.
<masinter> I think the wording would be better if recast a bit
<noah> ...and...
<noah> if the URI is sent to someone else the fragment identifier can be used to recreate the state.
<masinter> "the application can be designed so that the fragment identifier 'identifies' the state"
<noah> NM: What about "?" vs. "#
Ashok: I have added one paragraph - in the google maps case which I think talks about that.
<noah> AM: I added a para about that.
<masinter> "the application can be designed so that the fragment identifier identifies or encodes the relevant transferable parts of the state"
Jonathan: Isn't this a special case of "use URIs to name things"? There are things that happen when you click or do a manipulation in your UI. You can name that action with a URI (a hyperlink) or you can not name it with a URI. If you use a URI then you have a control you can move out of the page.
Ashok: Yes.
Larry: the application can be designed so that the fragment identifier identifies or encodes the relevant transferable parts of the state
Ashok: Yes.
Larry: in the case of a map application with a lot of state, then you want the app to be designed so that the URI contains the [part of the state that you want to be transferred to another client]
<Ashok> Larry: You can design the app so that the frag ig identifies or encodes the state you want uniformly erferenced
Larry: the part that you want to have uniformly referenced.
Noah: let's suspend disbelief and assume that google maps used hash signs. The question is: state of what? [demonstrates using google maps]
Ashok: What [gmaps
Noah: there are a lot of http
interactions under the covers...
... let's be careful about what is the transferable part of the
resource...
... originally, [in the case of gmaps] an http request was made
for the generic http://maps.google.com
document.
... scrolling through this map feels like scrolling through an
http document.
... the question I want to raise: for this class of apps, you
emphasise that there is a virtual document that is the
map...
Ashok: [points to text in:
http://www.w3.org/2001/tag/2011/02/HashInURI-20110208.html#InteractionState]
... we can work on this wording...
Tim: When you're looking at the map... It's interesting that you don't use the hash as you drive around... They do not use the hash, but they could...
Ashok: the question mark tells you what to bring from the server. the has would not tell you that.
Tim: they both would...
Ashok: I disagree it could be done with the hash.
Tim: What comes back on the response is a piece of javascript. The javascript then starts pulling in all the tiles.
Ashok: if the only thing that comes back is javascript on the first get... [then it could be hash...]
Noah: I think one of the
attractions of this - is you don't have to do the distribution
in the same way in all cases. If I use the hash sign and I us
it in an email reader, the typical email client [wouldn't
handle it correctly].
... [disables javascript and reloads the map from google maps;
it works]
... You couldn't do that with the hash sign.
Ashok: Your first access gets you the app plus some javascript...
Noah: Where does the word representation apply? In the case of Google Maps, is it a representation of the original URI with query parms when the rendering is assembled with Javascript, client side?
Tim: yes, it's a
representation.
... lots and lots of web pages are filled in with
javascript.
Noah: Ok - it would be good to tell that story. Many web pages do this. There may be other ajax apps where you get different behavior.
Ashok: I'll ask TV if he can tell us what goes on under the covers [of google maps].
<johnk> example 3 talks about client URI generation - http://www.w3.org/2001/tag/2010/10/interaction-examples.html
Tim: History manipulation - to be able to change the behavior of the back button and change what's in the location bar - is in firefox 4.
Ashok: [talking through section
6]
... Do these or don't these violate specs and what do / should
we do?
... frag ids for html and xml... many media types don't define
usage of frag ids..
Larry: But we are specifically talking about http and html...
Ashok: [last paragraph] - "active content"
Larry: When you talk about URIs
do you mean URIs in general, or just http URIs...?
... [you need to be specific.]
Tim: I think we should make feel bad about using hash in this way. We should change the specs.
Larry: We should fix the specs to match.
Henry: I'm happier with doing this if we can say "because it's not incompatible" with the speced story.
Larry: originally content was static. Fragment ids were pointers to static pointers. Now content is active...
Henry: the interpretation of stuff after the hash should be client side...
[broad agreement]
Larry: it would be great if URIs worked [interoperated] between google maps and yahoo maps...
Henry: Historically the spec told you that all you needed to know was the media type of the response, now it's more tightly coupled.
<Ashok> The page tells you what the fragId is used for
Tim: what's interesting about the maps space - it would be great if the user has independent control over what happens when you get a GEO URI... what service you want to use...
John: Lat and Long have meaning in the real world. You also have the position on a map, which is different from the real space. The third part is the panning and zooming.
Tim: all you need is the lat -
lon.
... the user [should] just see lat, long.
<ht> There has been a real change in where the responsibility for determining the meaning of the post-# strings lies
<ht> Per the existing specs, it's global, and lies in the media type registration
<ht> Per the practice under discussion, it lies with the [transitive closure of] the representation retrieved for the pre-# URI
<ht> This is parallel to where the code comes from the _implements_ the semantics: for the existing spec. story, it's in the UA from the beginning, because it's known at UA-creation time, because it comes from the media type spec.
<ht> whereas for the new usage, it's in the retrieved representation itself
John: I think this goes back to the coupling issue.
Ashok: [back to the document] Section 7 - I didn't do anything with it - Yves says take it out...
Noah: It feels like we haven't nailed the good practices and recommendation. There are some interesting bits here. I'd like to see them in support of some news [some concrete recommendations]. Then we could see what other groups we need to coordinate with.
[back up to section 4]
<noah> Noah: Not happy with the word "operate" in section 4.
[discussion on the wording]
<noah> Noah: I think it's more like: the JavaScript uses the fragment identifier as well as other information to render and support interaction with the representation(?) of the resource.
<noah> Noah: On "As the state of the resource and the display changes, the fragment identifier can be changed to keep track of the state." Yes, but we need to get clear on pros and cons of ? vs. #
Dan: do you need to assume programmatic access to the history/address bar?
<noah> TBL: The key point on # vs ? is that when you update the address bar, the page >will< reload. In the case of #, well, the right document is already loaded. In the case of ?, the tendency would be to reload the page.
<noah> TBL: Right, and when the GET happens, you lose state.
Noah: This finding has been slowly evolving. Need to hear from the TAG : we need to focus on it, get it to where people are happy and move ahead.
+1 on its usefulness.
Jonathan: I am not worked up
about it. My focus tends to be on what does the stuff mean,
independent on the protocols.
... I can't figure out who it would help or who would pay
attention.
Henry: The thing that caused me to wake up: the two people who have the most invested in the history saying "yes we should change the spec." [Larry and Tim] So the way we should change this spec is to have a set of guidelines and suggestions on what specs should change, how they should change and why it's OK.
Larry: the media type registration needs to say (for active content) when and how those parameters are passed to the active content. We are extending something originally designed for passive content to change for active content.
Henry: So this should be a story about how we think about media type registration in the space [active content] that we are now living in.
Larry: ..make the frag
identifiers useful for the potion of the state that you are
interested in [uniformly referencing].
... We could start with the current document as a note and use
that as a basis to add something to the mime-web document and
maybe another document.
Noah: the document either has to
cut the advice out, or it needs to give advice in close to the
style that we've done in findings. "Good practice: xxx ,
explanation"...
... or describe use cases.
... Ashok I think that work needs to be done before publishing
it as a note.
Larry: I'm OK with it. The context is a discovery...
Dan: I think that sounds like the right approach - reformatting / expanding some of the recommendations and publishing it as a note.
John: I think it makes sense to
document things we'd like to see happen.
... highlighting that kind of usage is good. But I worry that
it's getting a bit wooly.
... I told Raman when I reviewed this document that he could
pull out 2 things - the same things referenced in section 4 of
the current document.
Ashok: I think we can make this
[section 4] better.
... If people think that after that we can publish this as a
note, great. Following that, if you want something smaller -
one page, about spec recommendations, then we can pull that
out.
Noah: that could be as simple as giving someone an action...
<masinter> action-508?
<trackbot> ACTION-508 -- Larry Masinter to draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 -- due 2011-02-12 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/508
<masinter> action-500?
<trackbot> ACTION-500 -- Larry Masinter to coordinate about TAG participation in IETF/IAB panel at March 2011 IETF -- due 2011-02-15 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/500
<noah> Leave ACTION-481 as is
<noah> ACTION-508?
<trackbot> ACTION-508 -- Larry Masinter to draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 -- due 2011-02-12 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/508
<noah> LM: Ashok's document should be a stable reference.
<noah> ACTION-508 Due 2011-02-22
<trackbot> ACTION-508 Draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 due date now 2011-02-22
<masinter> action-508 should say that the problem is that #XXXX are parameters to acdtive content
Larry: What is the boundary between "the web" and the "rest of the Internet"?
ISSUE-500?
<trackbot> ISSUE-500 does not exist
<masinter> issue-500?
<trackbot> ISSUE-500 does not exist
<masinter> action-500?
<trackbot> ACTION-500 -- Larry Masinter to coordinate about TAG participation in IETF/IAB panel at March 2011 IETF -- due 2011-02-15 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/500
<Yves> [re: Ashok's document on fragments, I'll send further comments/help working on it]
[debate on what is implied by the quote from the IAB]
<Ashok> Thanks, Yves!
Noah: The TAG has decided to say yes to participating on the IETF panel in Prague.
Noah: Once again, welcome to
Peter.
... Minutes of the 20th - approved?
RESOLUTION: telcon minutes of 20 January 2011 are approved.
Noah: Note that TPAC is happening
November in Santa Clara.
... we would normally meet sometime in may timeframe. there is
an ac meeting in bilbao, spain in may.
... so - open to suggestions.
... we could meet in Cambridge again...
Tim: 11-12-13 of May in London...?
Noah: Doesn't work for me.
... Who else is going to the ac meeting?
... 9-11 in the UK?
Larry: Week of the 9th I am completely booked.
Noah: Week after the AC?
[week of the 23rd]
[not good for Tim]
Noah: Week of June 6?
... 7-8-9 of June?
Tim: Yes could do it - would have to be in Cambridge.
Noah: Formal proposal - 7-9 June in cambridge Mass for next TAG f2f meeting.
+1
Noah: Should we talk about September?
Henry: I would be happy to host.
+1 to edinburgh in September.
<noah> ACTION: Settle London vs. Edinburgh for Sept. 13-15 F2F Due 2011-05-31 [recorded in http://www.w3.org/2011/02/08-tagmem-minutes.html#action04]
<trackbot> Sorry, couldn't find user - Settle
<noah> RESOLUTION: The TAG will meet at MIT 7-9 June
RESOLUTION: The TAG will meet in Cambridge 7-9 June 2011
NOTE: Later, at Tim's request, we changed this to 6-8 June 2011
<noah> ACTION: Noah to settle London vs. Edinburgh for Sept. 13-15 F2F Due 2011-05-31 [recorded in http://www.w3.org/2011/02/08-tagmem-minutes.html#action05]
<trackbot> Created ACTION-520 - Settle London vs. Edinburgh for Sept. 13-15 F2F Due 2011-05-31 [on Noah Mendelsohn - due 2011-02-15].
<noah> RESOLUTION: The TAG will meet in the UK 13-15 Sept, either Edinburgh or London, TBD see ACTION-520
RESOLUTION: The TAG will meet in the UK 13-15 Sept, either Edinburgh or London, TBD see ACTION-520