TAG f2f

23 Jun 2009


See also: IRC log


Tim Berners-Lee, Dan Connolly, John Kemp, Ashok Malhotra, Larry Masinter, Noah Mendelsohn, Jonathan Rees, Henry S. Thompson
Noah Mendelsohn
Henry S. Thompson, John Kemp


<ht> ScribeNick: ht

<scribe> Scribe: Henry S. Thompson


NM: Scribe duty: Tu: HST, JK; We: TBL, LM; Th: AM, ???

<scribe> Agenda: http://www.w3.org/2001/tag/2009/06/23-agenda

NM: [intro to meeting, see http://www.w3.org/2001/tag/2009/06/23-agenda#F2FReview]

LM: Swap first two Thursday morning a.m. sessions?

NM: Yes

[Language Versioning vs. HTTP Semantics]

W3C Work on APIs


NM: W3C is on the verge of taking on standardization of APIs

<masinter> w3c is in the middle of standardiation of APIs

NM: Some folks asked whether W3C should be doing this
... and maybe the TAG should contribute to this discussion

<noah> ac2 n6ah

LM: WebArch and our findings mostly/entirely are concerned with static stuff
... so this at least appears to be a delta

JK: W3C has some API-type standards already, e.g. the DOM, but the TAG has not said anything about it/them

LM: Wrt the current chartering decision, we don't have a role to play in the decision as such
... but if/when they do, we need to consider whether there are arch. issues there, which is now officially part of "The Web" as the Consortium addresses it, which the TAG ought to address

NM: So the TAG ought to line up its investments with areas of interest to the W3C
... What would that mean wrt e.g. device APIs

LM: We should examine our current findings to see whether they can/should be adapted to cover APIs, and
... as we do new stuff, we should keep APIs in mind

TBL: Yes, obviously -- W3C does APIs, the TAG should include this in their remit
... The WebApps platform is more and more important, and clearly APIs are important there
... So, yes, definitely they're in scope
... Going on to say WebArch 2: The Web as a Computing Platform -- I'm not sure

AM: What direction to we provide to WGs/Chairs -- should it be different? How do API standards get tested? How ensure they are valid/representative? Is this different for APIs?

NM: Consider drawing a circle within the <canvas> TAG -- the rule of least power clearly relevant here: contrast sending JS which says "draw a circle" vs. sending an SVG circle tag
... The JS that comes over the Web is clearly in scope, less so the kind of local scripting which e.g. manages my desktop

LM: I had a long discussion about <canvas>+JS vs. SVG -- declarative vs. imperative

<Zakim> noah, you wanted to talk about rule of least power and canvas tag

LM: For many delivery mechanism, imperative mechanisms are inappropriate, e.g. in HTML-marked-up mail
... But for other contexts, e.g. a drawing program within a Web page, imperative is much more appropriate
... Convenience and performance weigh heavily in this case

NM: RoLP is a bit like 'SHOULD' -- there's a tradeoff -- you get convenience and performance, you lose transparency

TBL: Little declarative languages emerge in this context
... and sometimes get standardized

JR: Contrasting SVG with JS - you start with a weak==declarative language [HTML], and build out by decorating with JS, there's a kind of graceful degradation, whereas with JS, [if you start it] with you are stuck from the beginning, there's no way to move the other way, from the strong==imperative language to something weaker

<jar> (unless you make javascript safe, by changing it a little bit)

NM: We don't want to just rehash the RoLP, but do we need to call it to people's attention?

<noah> Yes, and the question is, what else if anything should we do to "helP" the community that's investing in APIs at W3C?

LM: I don't think people care much about LoRP, insofar as they think of the Web as entirely made up of servers and browsers

<jar> (re my parenthetical comment, larry is pointing out that even a safe javascript is not that useful, since it's not declarative)

LM: but once you start _analyzing_ pages, or you need/want graceful degradation, you have no chance with an imperative language
... So API evolution/degradation/extension that we have the most to say, wrt both balancing declarative vs. imperative, but also given an imperative API, the versioning/extensibility should be taken seriously, and we can help here

TBL: So, yes, endorse LoRP, but when we've got APIs, yes, more to be said as well: e.g. modularity
... So, given that JS modules don't have a packaging system == a URI as a name, there's a problem
... A good web-addressable JS package system would be a great thing
... relates to trust

JR: [scribe missed]

JK: What about WebIDL -- allows some declarative statement of dependencies?

NM: There's no import or anything required to use <canvas> -- either it works or it doesn't

DC: CSS selectors are a better example

<jar> - I wanted to draw connection to "self-describing web" finding. Can one go to an HTML page containing javascript, and learn *without running the code* what its dependencies are? (this question may be simple ignorance) i.e. can you nose-follow effectively without execution? - because this might help with extensibility and graceful degradation.

NM: Some of these are built-in, sometimes you need to try to import a JS library

<DanC_lap> (my "are a better example" is a response to a pattern timbl observed that went by too fast for the scribe or something)

NM: and sometimes you can use one as a fallback for the other
... Self-describing Web applies to this case as well, as far as I can see
... JS interactions are as normatively specified as anything else

JR: But you can't (easily) tell what any given JS will do except by running it

<masinter> wonder if AWWW has enough 'roles' for participants in the web, including authoring, analysis, search engines, proxies, translation gateways, etc... because these are important agents for programs written in JavaScript

TBL: Consider the case where a small module pulls in Google Maps, which has its own module structure and conventions

JR: I don't think you can even tell if that happens

JK: You can check dependencies without running the code

<masinter> and authoring tools

TBL: Not inside Google Maps, because they do their own
... There is no standard way of declaring, or therefore of detecting, JS dependencies on the Web
... So if you try to combine Yahoo Calendar and Google Maps you get into trouble
... You can't do a JS import from inside JS

JK: So they cheat, pushing a <script source=...> tag

<johnk> Tim said "cheat", not I ;)

<DanC_lap> (raman showed me an import technique that doesn't use <script> insertion. I didn't study it well enough to remember the details.)

LM: The problem only arises when you have agents that want to interact with e.g. script-containing pages _without_ just running them
... AWWW doesn't say enough (anything?) about agents like this: spiders, dependency checkers, ...

HST: Tool to download a page and everything it needs to run locally w/o web access

AM: [scribe missed]

NM: TBL, are you asking if the TAG should take on the standardisation of dependency declaration for JS?

LM: There's a lot out there already, we don't have to originate this work
... You can't tell what a program will do w/o running it, but you can make some of it, e.g. dependencies, available/accessible/declarative
... So e.g. our programmers have to adhere to conventions so that raw strings are never used as such, they have to be indirected so that localization can happen systematically

DC: Two JS issues, modularity and same-origin
... ECMAscript WG has passed on modularity, I think
... but that is really in other people's hands
... Wrt same-origin, the best source for this at the moment is Wikipedia
... we probably should lift what there is about that from the HTML5 spec., just as we lifted some things from the HTTP spec

TBL: HST was skeptical otr about the possibility that JS would be made safe

JR: I put my comments in IRC above wrt JS/safety, and then retracted them a bit following LM's comments

LM: Maybe something of the scope of the old QA activity, focussed on declarative languages, might be necessary
... Is the QA precedent hopeful?
... If this pblm is too big about the TAG. . .

NM: Trying to see which way we go, I heard TBL say that maybe AWWW2 might be WebApps
... That's broader than just APIs, involves e.g. TV's draft, security, etc.
... I heard LM say that AWWW didn't talk enough about [other] agents
... JS packaging came up, with the suggestion that we not do the work ourselves
... Finally, the suggestion that same-origin deserves to be pulled up to the Arch level

JR: We could issue as it were a Call for Proposals: We don't yet know what it would mean for us to have Arch. Principles for WebApps, but we know they would have to address the following requirements
... There's a difference between saying "We don't know how to do this" and "This is out of scope"
... Saying "Either this is out of scope, or we have to do it" -- there is a third position, which is "We care about this, please you do it"

TBL: AWWW v. 1 varied hugely in granularity - it's OK to say both "WebApps are really important, be careful" and "Here's a very specific recommendation wrt APIs: ..."
... compare "Use URIs" and "Don't use GET unless it's really a GET"
... So, e.g. "The modularity/packaging situation wrt JS really needs to be improved" and some very specific detailed recommendation
... So we could draw up a ToC, with very variable depth

NM: So maybe will have a session at this meeting to explore a ToC

LM: I heard JR say we could try a document which was _not_ a finding, but a tabulation of the issues, and our understanding of them, and why they are important
... I think such a document would be very helpful, and we could do it quite quickly
... with a goal primarily of raising awareness

NM: Scoped to Web Applications?

LM: No, scoped to APIs

<johnk> I will note though that there is a "widget packaging" specification, which might be considered a solution to "javascript packaging"

HST: I would prefer the broader scope, if possible: we have a situation in which the browser is the _de facto_ distributed web-app delivery platform, but it wasn't designed for it, and we need a better one

NM: Procedural point -- do we need to track JS packaging? Is there something we want to tell the community in this area in the short term

JK: Is the Widget Packaging work relevant?

LM: I don't think so

TBL: Does it give URIs for package components?

<masinter> it might be relevant but it's a different use of the word 'packaging'

JK: No, but people have suggested it should

<masinter> yes the "widget:" URI scheme is a proposals

<johnk> and there were other proposals which didn't involve a new scheme

<johnk> widget URI scheme is _not_ global in scope

LM: I think we should engage in discussing the issues, before we decide where to go with them

<johnk> IIRC, Stuart worked on this quite a bit

JK, yes, he did

AM: Thinking about how we publish the AWWW2 ToC

<masinter> suggest TAG note "Architectural Issues for APIs in the Web Architecture"

<masinter> and that we try to publish a note in 3 months

<masinter> start with APIs and if we have more to say about other parts of APIs

NM: So, back to the ToC -- scope this to APIs, or more broadly to the web-app platform

<masinter> and that 'answers' aren't out of scope, but problems first

HST: I'm happy to follow LM's suggestion and enumerate problems we see, and decide the scope later, bottom-up

<Ashok> +1

<masinter> i'm happy to add other issues that relate to APIs but are part of web applications

NM: There are things on the table which are important, which go beyond APIs, but which are in this general space, about getting the Web right for applications in general

LM: I don't want to rule webapps out of scope from the start, but I want to be able to declare victory when we have a reasonable set of problems outlined

<masinter> in fact, we could scope it by time rather than by breadth: "Some Architectural Issues" and we declare success when we have N months into it

LM: What about XAML and FSG (for Flex, at Adobe) which are hybrids, there's a markup language which looks declarative, but which is implemented by API calls

NM: The XAML stuff provides for declarative access to only a subset of the API

TBL: Possible TOC:
... Declarative:Procedural::....
... APIS: Good Practices, ....
... Modules & Dependencies
... Security: Trust boundaries, Cross-site, Same-origin
... Client-side#URIs

DC: Geopriv?

AM: Don't we need an action to get this started?

NM: We'll come back to that in another session
... AM, any followup wrt geopriv?

<noah> I think we should add PRIVACY to the Possible TOC above

AM: We could ask the GeoLoc WG (W3C) to add some some explicit discussion of privacy

TBL: How would that be different from the IETF work to date?

NM: Do we know enough to ask this question in a way which actually provokes something specific?

<masinter> proposal: be clear that scope of privacy and security issues is not limited to use cases that API is designed for, but rather all applications which might reasonably use the API

NM: Someone prepared to take an action to draft input to the GeoLoc WG?

TBL: Need to be willing to spend face time with the editors/chairs

LM: I'm heading to the IETF meeting in July, I will be happy to liaise with the IETF GeoPriv there

DC: We could pbly talk with Matt Womer and Philippe Le Hegaret here today

<masinter> with whoever is there

ACTION to Dan to propose concrete steps wrt GeoPriv after consultion with W3C members/staff

<trackbot> Sorry, couldn't find user - to

trackbot, status?

ACTION Dan to propose concrete steps wrt GeoPriv after consultion with W3C members/staff

<trackbot> Created ACTION-275 - Propose concrete steps wrt GeoPriv after consultion with W3C members/staff [on Dan Connolly - due 2009-06-30].

ACTION Larry to take GeoPriv discussion with IETF forward in person in July

<trackbot> Created ACTION-276 - Take GeoPriv discussion with IETF forward in person in July [on Larry Masinter - due 2009-06-30].


Language Versioning and HTML


NM: We have both strategic and technical questions before us
... Our goal is to have a positive impact on the HTML WG
... I have doubts about whether we can achieve that
... Before we dive in, and we can mix the meta- and the base-level discussion, but I don't want to proceed w/o _any_ thought to where we're headed
... I'll leave it to LM to decide whether to drive forward a bit technically before looking to how to sell the results

LM: The default action in the HTML5 WG will be that there will be no version indicator
... some people, including Michael Champion, are uncomfortable with that
... So we could come up with a TAG finding, qualifying WebArch, as to what situations don't need or even want VIs
... and why HTML5 is one such
... That would help the WG

<DanC_lap> "A data format specification SHOULD provide for version information." -- http://www.w3.org/TR/webarch/#versioning

NM: I produced a blog entry which went some way in that direction (see http://www.w3.org/QA/2007/12/version_identifiers_reconsider.html)

LM: I think we are making some progress on understanding the problem, going beyond the blog post, I think

<DanC_lap> note D Baron's essay http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html

DC: Some things I found helpful in moving towards accepting the WG default position: current HTML version indicators are rarely correct
... David Baron's essay suggests VIs are counterproductive -- it tells the story of how MSW version 8 has a complete version 7 implementation inside it
... MS can afford to do that, but most folk can't

<Zakim> johnk, you wanted to ask about what we call a "version indicator"

JK: By VI you mean what? An explicit statement of version, or anything which allows some agent to detect difference in versions?

DC: A specific flag that changes the interpretation of the entire document

JK: Entire?

DC: In principle, yes

<DanC_lap> DC: I read http://www.w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html looking for Baron's argument and didn't find it

LM: Where are we?
... JR and I wrote a document

NM: One design point -- all features have a permanent and never-to-be-changed meaning
... at whatever point they are introduced
... In that case, I claim version indicators are redundant
... OTOH, in other cases there may be changes in interpretation between versions

<masinter> version indicators are only redundant. They may be useful, but they're not necessary. if you assume web agents are only browsers and (hand-coded) web pages

<masinter> authoring tools and validators can use version indicators, for example

NM: In this case version indicators are necessary

<masinter> would like to go through document

<masinter> further, not entirely in control of every aspect

TBL: HTML is generated by people who pull stuff together -- if they can't get their act together to match start and end tags, they certainly won't match the whole document to what is essentially the top of the doc
... NM, your dichotomy is too clean -- in general, evolution isn't that nice, things change by accident, or to fix bugs in a previous version
... A single-dimensional VI can almost never achieve accuracy

LM: I'd like to focus on the document, but first
... VIs are only redundant if you look only at hand-authored content and browsers
... Authoring tools are assisted, and do their job better, if they have a version target
... They're helpful in content management, as a signal of intended target
... There's a whole economy of production, consumption, analysis, etc.

act next

TBL: Not just _people_ scribbling, but pulling stuff from RSS feeds, DM systems pulling bits from store and script, etc.

<DanC_lap> (DM systems? I think maybe CM systems)

<DanC_lap> (ah... document management)

<masinter> document management vs content management

TBL: so even in cases w/o a single human author have consistency pblms

<masinter> i've tried to be careful between "version indicator" and "doctype"; certainly doctype has weaknesses

<Zakim> ht, you wanted to be precise about 'redundant'

HST: I think there is a sense in which what NM said was true, because tautological, but that doesn't make LM's point invalid

NM: I heard LM say that the VI is advice, or a statement of intent, not just a summary of an otherwise-determinable fact
... Let's look at http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html

LM: This isn't scoped to the "Is there a DOCTYPE in HTML5", but it bears on that question
... It's about what we mean by words like 'language' and 'version'
... Guidelines to groups on how to write extensible languages

<DanC_lap> (editorial comment: in-your-face URIs are ugly; they're sometimes necessary in constrained environments, but this document is written in HTML, where you can just use normal links)

LM: A language is an agreement of a community on meaning, wrt strings (and maybe syntax)
... I'm uttering [a text], and we have an agreement on what it means
... We're dealing with a community in which many different agents (authors, browsers) have there own precise definition of a language in those terms
... A standard is then an attempt to coordinate all those languages into something expressed in a language specification,
... so that all the parties can use the language to communicate

JR: Yes, I think my attempt to confine the definition of 'language' to appeal only to consumers is probably wrong

NM: I still, going all the way back to our discussions in Edinburgh [in 2005?], that 'language' has an important nature independent of producers _and_ consumers

TBL: But it was there that we _introduced_ the dependence on producers and consumers

NM: We started with the question "per some language specification, is this text in the language or not?"

LM: We end up distinguishing between a language, which is an agreement, and a language specification, which is an attempt to record that agreement

<DanC_lap> (editorial comment: I don't like up-front Terminology sections. I prefer to see the terms introduced in context. put a glossary/index at the end if you like0

<DanC_lap> 0

<DanC_lap> )

LM: This allows us to distinguish between "What the spec. says" and "What was implemented"
... regardless of which comes first -- a spec. can be an after-the-fact attempt to record an agreement which is instantiated in implementations, or it can be a proposal which may or may not be consistently adopted and then implemented

NM: Reasons for language change
... How do languages change? The kind of promises we should make about the future can be informed by an analysis of what kind of changes have happened in the past
... Incompatible changes happen, for good reasons
... This section is incomplete

DC: It would be good to remember the players: a lot of authors, even more readers, few implementors. . .

I would add, per LM, quite a few non-human consumers

[LM continues to summarize the document]

<DanC_lap> note D Baron's essay http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html

LM: There is this bizarre reciprocal heuristic behaviour -- servers are trying to detect what they're serving to, browsers are trying to detect what language they are about to render, and the situation has gotten recursive, i.e. spoofed user agent strings in order to provoke particular kinds of content

<DanC_lap> jar, that's the one

LM: User-agent string and request headers are related to VIs

JR: And content negotiation

NM: The UA string indirectly indicates the language the client is expecting to render
... The server responds not with explicit VIs, but variants that are intended to be tuned to the 'version' requested

<johnk_> User-agent header is an implementation version indicator

<johnk_> (not a language version indicator)

TBL: Note that if HTML5 at the moment is using DOCTYPE as part of its heuristic, that's perhaps an indication that version indicators would be useful in the future as well

<raman> calling zakim

we're just dialing in

We're working through Larry and Jonathan's document: http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html

<DanC_lap> (construction noise)

JR: Wrt Motivation of Implementors of Agents section, this is about the Must Understand rule
... RDFa has been called dangerous to put into HTML, because it can't be checked automatically
... and since it's not meant for human eyes, it can be ignored by browsers

NM: OK, so not the same as the SOAP mustUnderstand flag

JR: I'm working to the criticism that RDFa violates the 'no invisible metadata' HTML5 design principle

DC: Not documented as a design principle, but yes

<DanC_lap> (zeroing in on it http://microformats.org/wiki/invisible-data-considered-harmful )

NM: The concern is that the user never sees this stuff, so can't be sensitive to its significance

DC: The worry is, among other things, that invisible data rots, it isn't maintained because no-one notices if it's stale/wrong

JR: But this is an ecology, there are multiple audiences
... Why isn't this a critique of comments? (which end up being re-purposed for automatic consumption)

<DanC_lap> (which section did LMM pick just now?)

LM: If this were to become a Finding, we have some recommendations to add -- there are placeholders in case we decide to do so
... I don't accept the "HTML is unique" argument for ignoring all background/precedent
... Ignore what you don't understand is not really an option for imperative languages

HST disagrees -- the "debugging a blank sheet of paper" approach to LISP programming depends on the fact that a function which names but does not use at runtime uba or udf is not broken

LM: Moving on to JR's formalism
... Needs to be up-leveled to deal with communities of consumers and producers

JR: Sure, like statistical thermodynamics -- you have to _start_ with two-particle interaction, and then take it up-level
... ref. is John Maynard Smith (application of game theory to study of animal behavior)


HST thinks there's something odd when the consumers are by construction _identical_. . . Not sure what impact on modelling this might have

NM: Adjourned for lunch, back 1315EDT or thereabouts

TV, are you there?

<raman> here

<raman> calling

stand by

<johnk> ScribeNick: johnk

<scribe> Scribe: John Kemp

<raman> on zakim

<raman> all by myself

<ht> noah having trouble keying

Web Application State Management


NM: (summarizes morning's discussion)
... we might add a section to AWWW focused on web as application platform
... which might have implications for this topic ( web app state)

TVR: discussion of changing URL -> URI - where are we?
... what should I edit?

HT: The "URI" version

TVR: (discusses the logistics of the document)

<DanC_lap> technical stuff first, please

TVR: should we tackle logistics or tech details first?

DC: tech first

TVR: we decided to make this public draft, engaging W3C process and raising related issues

NM: summarizes issue raised about W3C patent process, and suggests we solve in email

ACTION Noah to ensure any issue is resolved with Art

<trackbot> Created ACTION-277 - Ensure any issue is resolved with Art [on Noah Mendelsohn - due 2009-06-30].

TVR: move on to technical issues
... we do not yet have "deep" recommendations, simply a list of ways people are using client-side # URIs

<noah> Noah note to self: Action 277 is to make sure we are addressing Art's concerns with the basis on which TAG members participate and disclose patents. To be picked up late July.

<DanC_lap> action-277: Noah note to self: Action 277 is to make sure we are addressing Art's concerns with the basis on which TAG members participate and disclose patents. To be picked up late July.

<trackbot> ACTION-277 Ensure any issue is resolved with Art notes added

TVR: write down the different usages to identify conflicts between different methods

<masinter> thought on this: update the URI specification to redefine "fragment" after # to be 'parameters sent to interpreter' rather than 'fragment'

<masinter> or else redefine 'fragment' for HTML only

TVR: "push state"

<DanC_lap> how is "push state" spelled? I can't find it

TVR: this is in a more recent draft
... than the one in the agenda

<raman> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#dom-history-pushstate

TVR: in a browser you have window, which has document which has a URI
... browser back and forward can page from one URL doucment to the other
... world more complicated now
... overall state is now more than a URI
... "state" object where window.history contains these state objects

<jar> like form fields?

TVR: so what does this have to do with HashinURL?
... pushState( state, title, url)
... then history list is states with/without URL and vice-versa
... what is your window.location then?
... URL + this state object referenced as a JSON object in the URI fragment

NM: are we going anywhere with this document?
... we currently say "here is what's happening"
... should we go beyond that?
... and then, do we have comments on pushState?
... so.... work backwards through that list

<DanC_lap> pushState is sort of obviously good as far as standardizing a pattern that is in lots of JS libs, right?

LMM: not sure I understand the issue
... is it role of fragment ID of indicating state, or about this use of state?

NM: relates to metadata in URI finding
... one case where this state is private to your browser session

TVR: these URIs do show up in browser address bar

NM: so they can leak out
... one position is that these are private
... how should we tell the story about the relationship between the server and client in this case?

<raman> GMail is a better example

NM: (gives Google Maps example)

<noah> http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#forms

NM: address bar doesn't change, but can use 'link' URI to paste to email etc.
... server sent client a big pile of JS
... metadata finding, server sent client a form
... in both cases, server allows client to mint URIs
... if something comes from resource authority, then we can assume it knows how to deal with URIs minted by the client
... sees a parallel here
... resource owner assigns meaning to all URIs and has encoded that knowledge into JS sent to client
... we could make this connection explicit between these two findings

AM: If I zoomed into the same spot to Google Maps in my browser, would I see the same thing?

NM: not necessarily, but it is still "server consistent"

TVR: there are secondary requests with secondary arguments encoded as '#' parameters

NM: isn't that different than what I explained?

TVR: Gmail has notions of thread ID and message ID which can be used to get back the same message/thread

NM: this is like the Maps case, where these ids can be mailed/pasted

<DanC_lap> "identification is orthogonal to access control" -- bookmark that thought for later ;-)

TVR: there are security implications with passing these state ids around

NM: this is discussed in the metadata in URIs finding

<Zakim> noah, you wanted to talk about HTML forms and metadata in URI finding

LMM: the frag id is being used to pass parameters to the UA
... is this a property of the HTML MIME type?
... since HTMLis the authority for that MIME type
... in XHTML case would this delegate to the XML document?

NM: I'm synthesizing an HTML doc from a bunch of different files/places, and creating a DOM

LMM: fragment identifier is a property of the representation retrieved of the resource accessed
... should there be an update to what fragment identifiers mean, such as in HTML case?
... how to do give an identifier to an application in a particular state?

<DanC_lap> (hmm... does the HTML 5 spec cover this mime type/fragment stuff? are there plans to? looking it up...)

LMM: how can you construct identifiers which can identify an application in a particular state?

NM: see this as a set of "virtual documents" - not been in a monolithic application
... should be a discussion about the set of URIs for the virtual document

LMM: transition from Web 1 to Web 2 was about transition from virtual documents linked together to one where application state is the thing transferred

TBL: agree with both of you

LMM: identifier is not just for a resource, but for a resource state

TBL: people are looking at a place (on a map) - not a state of a map
... that is what is invariant

<DanC_lap> (yes, there seem to plans to... http://www.w3.org/html/wg/tracker/issues/53 ISSUE-53 mediatypereg Need to update media type registrations State: RAISED)

NM: we can agree that both of these views are coherent
... document/resource-oriented view is a good model that bridges this web 1.0/2.0 gap

LMM: model is less descriptive of what is going on
... when I sent you a URI of Google Maps pointing at Cambridge, I'm also sending you a link to an application which has the ability to zoom to that place on a larger map

NM: true, but not so different from resource-oriented view

AM: describe the link to metadata in URI again?

NM: main question is "what right do I have to guess what URIs are appropriate here?"
... resource owner chooses
... we tell the story of HTML forms
... two cases:- form itself came from resource authority, so you can assume that URIs delivered are consistent according to the owner
... second is that "all bets are off" otherwise

TVR: what are you suggesting?

NM: point to metadata in URI from Has in URI and draw the parallels

LMM: what problem are we trying to solve here?

DC: people that might be using two conflicting JS libraries
... they mostly don't "bump into each other"

TBL: looking at DCs FOAF page - URI of "you"
... inside tabulator, nowhere to see the #
... RDF has "used" the #
... could propose an "extended URI" scheme
... ##

NM: I'd like to see the Google Maps method explained - showing this usage of the 'link' allowing me to send/email a URI
... showing people how to do this "on the web"
... is good
... equivalent of using cookies to represent state (URI alone is not useful)
... navigation in these apps is often done quite privately

LMM: OpenAJAX Alliance works on good practice statements for AJAX apps
... would our advice fit into their domain, for example?
... is this advice on building web 2.0 applications?

TBL: architectural principal is that user should "have a history" (to browse)

HT: there are some interesting ways in which web 2.0 "breaks the Web"
... much less content that you see is being indexed than it was 5 years ago, because content is synthesized depending on things more than the URI + original representation
... crawlers don't see all the things they need to see (forms, cookies etc.)
... crawlers get stuck in "tarpit" when they attempt to explore such spaces

<DanC_lap> (hark to alexa vs the original calculator web site...)

<DanC_lap> (oops; altavista, not alexa)

HT: image we have of webarch is that servers represent hierarchical file systems

<Zakim> ht, you wanted to remark on non-Browser agents

HT: if this document could bring this issue to the foreground and draw attention to tradeoffs

LMM: this issue is an important instance of a larger problem
... happy to deal with large problems by dealing with single instances, but need to be sure we can address the broad issue with this example

<raman> simple answer to Larry's "why are we doing this" -- because someone on the TAGis motivated to work on it

NM: there are new idioms for building apps, and I think it's a good thing to write down these issues and tradeoffs

<raman> we could say that that shouldn't be how the TAGworks, which is a fine thing to do, but in my experience, people only work on things that motivate them:-)

NM: do we need another session?

TVR: I don't think so

NM: so, where should we go with this?

TVR: if content doesn't change it should turn into a note

AM: would rather consider this in the context of AWWW for web applications

LMM: would publish this as a note describing the issue, and noting it as part of a bigger effort

TVR: happy with the idea of publishing this as a note, and as part of a larger effort

NM: where to draw the line?

<DanC_lap> (I heard TVR say he's happy provided the larger effort happens)

TVR: (says a lot of stuff I didn't hear well enough)

NM: what would you do to get more comments?

TVR: not sure
... worried that our work is dropping off the radar

NM: make no decision right now (on what to do next)
... try looking at the web arch for web applications first

LMM: would like to see a more specific proposal

TVR: will do no further work without further input
... what about cases beyond HTML+Javascript?

NM: thinks TVR is talking about how these parameters are used in things such as Adobe Air

LMM: describes media type registration for PDF and its use of #

TBL: what happened timbl to plaintext # line numbers?

LMM: desire to have "more robust" pointers than line numbers
... for web apps, how you do pointers to app state that survive app updates is interesting
... HTML frag ids are robust in that way
... as you move to other media, the issue of robustness of such pointers is important

NM: would like to see links to the metadata in URI finding, but other than that, put it aside for now
... look at larger issue (web app arch) and revisit
... this issue in that context
... (break)

<timbl> data:text/plain;Text%20plain%20fragids%20are%20like%20L0%20%28same%20as%20L0-L1%29%20or%20L0C0-L3C6%20with%20obvious%20meanings.

Javascript Security


JAR: how to relate the various security issues discussed?
... discussion of Origin header and related risks
... Javascript security related to DC
... relationship to web architecture of JS security
... wrote http://www.w3.org/2001/tag/doc/resource-protection/20090615

<raman> could you call in to zakim?

JAR: Cross-origin requests fall into confused deputy problem

dialling in

JAR: traditional ACL model doesn't work in situations where there are more than two parties involved in security
... risks when you separate the credentials from the name
... that is why this is a "forgery" (forging the link between the name and the credentials)

NM: is this typically a cookie problem?

JAR: whatever ambient credentials held with the site
... could be IP address, client cert or other ambient creds

HT: scenario is by whatever means I am looking at page served by attacker, with link to legitimate page which when clicked will send user's creds to the legitimate site

(discussion about examples of this issue)

JAR: reiterates the three items at the beginning of this topic
... defense against confused deputy attack is to keep creds closely linked to the name

jk: one way is to make the creds and name the same

JAR: can use nonce for example (provide unguessable name)
... secure ECMAscript packages credentials into the object
... you can then put potentially hostile code into a container
... link to web arch is regarding naming
... Tyler (Close)'s solution is to put the creds in the URI
... in JS you'd pass that URI around as part of a JS object

AM: if you have an object with these things in it, there are no methods to extract the credentials?

JAR: if creds are hashed together with the URI, then even if attacker can get access, it cannot change the link between the name and the creds

NM: so URI can be more than a name?
... if you're encouraging people to use URIs which cant be bookmarked, that's not good for webarch

<Zakim> DanC_lap, you wanted to share some thoughts on http://waterken.sourceforge.net/web-key/

DC: saw Tyler's papers, and have met him
... lots of discussion that acl is orthogonal to naming

TBL: we talk about the difference between authn and authz

<raman> off to lunch in 4 mins.

<raman> back in 45 mins or so

<DanC_lap> DC: I think there's room to acknowledge capability style URIs as well as URIs that you can mail around without giving access

<DanC_lap> Tyler's "Mashing with permission" http://waterken.sourceforge.net/web-key/ is an extensive critique of 3.5.2. Linking and access control http://www.w3.org/TR/webarch/#id-access

<Zakim> johnk_, you wanted to talk about multiple identities

JK: which credentials are carried in these references?

<Zakim> noah, you wanted to ask about URIS as capabilities

JAR: you could encode multiple sets into a reference

DC: there is a style where URI is a capability
... Tyler's analysis is that leaking of URIs is less of a problem than phishing+cross-site request forgery

NM: so, advice in 2.7 of Metadata in URIs is still good advice?

JAR/DC: no, Tyler et al say this is bad advice!

LMM: advice is good for some situations, bad for others

TBL: appropriate to say that there are two patterns of use - 1) ACL is done orthogonally to URI metadata (metadata MAY be public)
... and another, where URI must be completely secret

HT: you are fooling yourself if you think URIs won't get out into the wild

(missed TBL third case) - secret information in URI, as noted in 2.7 of metadata in URI spec.

TBL: (describes tripIt 'send to' case)

NM: there is a story about if I use HTTP, then URIs will appear in several places
... and with HTTPS, fewer places

TBL: re-open the metadata in URLs finding, explain capability use-case

http://www.w3.org/TR/access-control/ Cross-origin Resource Sharing

JAR: there is conflict between CORS and this capability approach
... Tyler and Mark Miller asking for GuestXHR feature support in CORS
... to have a way to issue a request such that request is stripped of all credentials

NM: Guest approach only useful with Caja-like approach?

JAR: you could also build your own sandbox

NM: don't think the metadata in URI finding should deal with all the work on this issue

JAR: mnot sent email regarding an issue with CORS - http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0643.html
... concern that this WD is a threat to the use of URIs - causing people to switch from REST mode to SOAP-like methodology

LMM: Origin header has been deployed

JAR: Comments are i) CORS has impact on Web Arch (see above line about REST/SOAP) ii) ACLs won't solve all the issues
... if you accept the capabilities approach, then CORS seems antithetical

LMM: process issue is that orgs which build security infrastructure for the Internet should review this document (CORS)
... responsibility of WGs to get this review

NM: we could comment on this draft

HT: TAG exists because of need to provide web-arch related comments early enough in WG spec. process
... there is precedent for director to hold some specs. to a higher bar when exiting CR
... so, we have an obligation to say something to the WG - that is the role of the TAG

NM: is it about what we (TAG) think, or lack of implementations by particular groups (such as server vendors)?

LMM: the Origin header didn't seem to have significant support from server vendors
... risk when deploying something insufficient for solving the problem, is that it becomes a distraction from solving the actual problem
... particularly a problem for security-related issues

NM: not sure about the concrete steps

AM: we've said that URIs are public and can be sent around, and now we're saying... maybe not

DC: we should send a comment to CORS regarding CR exit criteria

LMM: I believe the counter-arguments against the CORS approach are credible and reasonable
... but would prefer we get the involvement of security experts in order to resolve the conflict
... and would require the involvement of server vendors

NM: strawman - we write a note saying we have reviewed these specs, and have been made aware of possible shortcomings
... we feel these concerns should be convincingly addressed

<ht> The current state of play: http://news.netcraft.com/archives/web_server_survey.html

NM: TAG may do more research, but would prefer the WG confer with security experts, but also note that acceptance by server vendors might resolve these concerns

Action to ht to draft a message to webapps chairs relaying TAG concerns around CORS

<trackbot> Sorry, couldn't find user - to

<scribe> ACTION: ht to draft a message to webapps chairs relaying TAG concerns around CORS [recorded in http://www.w3.org/2009/06/23-tagmem-minutes.html#action01]

<scribe> ACTION: Henry to draft a message to webapps chairs relaying TAG concerns around CORS [recorded in http://www.w3.org/2009/06/23-tagmem-minutes.html#action02]

<DanC_lap> trackbot, status

<scribe> ACTION: Jonathan to draft changes to 2.7 of Metadata in URIs to cover the "Google Calendar" case [recorded in http://www.w3.org/2009/06/23-tagmem-minutes.html#action03]

<trackbot> Created ACTION-278 - Draft changes to 2.7 of Metadata in URIs to cover the "Google Calendar" case [on Jonathan Rees - due 2009-06-30].

<scribe> ACTION: Henry to draft a message to webapps chairs relaying TAG concerns around CORS [recorded in http://www.w3.org/2009/06/23-tagmem-minutes.html#action04]

<trackbot> Created ACTION-279 - Draft a message to webapps chairs relaying TAG concerns around CORS [on Henry S. Thompson - due 2009-06-30].

<DanC_lap> action-278 due 7 july

<trackbot> ACTION-278 Draft changes to 2.7 of Metadata in URIs to cover the "Google Calendar" case due date now 7 july

<noah> http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037.html

<noah> Raman, I'm not sure if you're lurking, but shortly we will be discussing scheduling of future meetings, etc.

<raman> calling zakim

JAR: notes Roy's email on this subject http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037.html

<jar> You can have CSRF even with completely static content.

<noah> Warning, just as we were about to wrap, Dan asked to talk about more security, and I agreed.

DC: (draws 2x2 table) with CSRF cases for GET and POST

1. attacker hosts JS, which is executed by consumer which sends a GET to bank

2. is 1. with POST, and JS

second column has no javascript

3. (no JS, GET) attacker is malicious, bank is negligent (executes a GET with side-effects - img tag calls the GET and hides the side-effect without user input)

4. POST with no JS, and user is asked to click something to same effect as 3.

DC: without negligent system entities, are there still attacks of these forms?

TBL: A POST is a commitment by a user, and should be presented as such

I think we should document the examples in this table, and possibly derive advice to users and servers which wish to mitigate such attacks

<DanC_lap> s/without negligent system entities/without allowing GET scripts to POST/

<DanC_lap> close ACTION-274

<trackbot> ACTION-274 See if I can reconstruct a discussion with tlr where present course and speed will lead to GET-based links becoming regarded as unsafe closed

NM: propose we document this table, first as an email

<DanC_lap> ACTION: DanC (with John K) to enumerate some CSRF scenarios discussed in Jun in Cambridge [recorded in http://www.w3.org/2009/06/23-tagmem-minutes.html#action05]

<trackbot> Created ACTION-280 - (with John K) to enumerate some CSRF scenarios discussed in Jun in Cambridge [on Dan Connolly - due 2009-06-30].

JAR: what about my note on resource protection?

<DanC_lap> +1 TAG blog. good to acknowledge the criticism of "addressing is orthogonal to access control" pattern

<DanC_lap> (capture a sound-bite from noah: "how GET becomes unsafe")

(discussion about blog post vs notes/findings)

LMM: first inclination is to blog it in TAG blog


Summary of Action Items

[NEW] ACTION: DanC (with John K) to enumerate some CSRF scenarios discussed in Jun in Cambridge [recorded in http://www.w3.org/2009/06/23-tagmem-minutes.html#action05]
[NEW] ACTION: Henry to draft a message to webapps chairs relaying TAG concerns around CORS [recorded in http://www.w3.org/2009/06/23-tagmem-minutes.html#action02]
[NEW] ACTION: Henry to draft a message to webapps chairs relaying TAG concerns around CORS [recorded in http://www.w3.org/2009/06/23-tagmem-minutes.html#action04]
[NEW] ACTION: ht to draft a message to webapps chairs relaying TAG concerns around CORS [recorded in http://www.w3.org/2009/06/23-tagmem-minutes.html#action01]
[NEW] ACTION: Jonathan to draft changes to 2.7 of Metadata in URIs to cover the "Google Calendar" case [recorded in http://www.w3.org/2009/06/23-tagmem-minutes.html#action03]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/01/06 22:21:54 $