See also: IRC log
<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]
http://www.w3.org/2001/tag/2009/06/23-agenda#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].
[break]
http://www.w3.org/2001/tag/2009/06/23-agenda#naming
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)
q
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
http://www.w3.org/2001/tag/2009/06/23-agenda#webAppState
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.
http://www.w3.org/2001/tag/2009/06/23-agenda#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
NM: ADJOURN