W3C home > Mailing lists > Public > www-tag@w3.org > August 2009

Text-only version of TAG F2F minutes of 23 June 2009

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 10 Aug 2009 16:46:43 -0400
To: www-tag@w3.org
Cc: public-tag-announce@w3.org
Message-ID: <OF443967BF.EBC25A81-ON8525760E.0071B92C-8525760E.0071D966@lotus.com>
A text-only copy of the minutes from the first day of the TAG's F2F 
meeting in June, 2009 is attached.


[1] http://www.w3.org/2001/tag/2009/06/23-minutes.html

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142


      [1] http://www.w3.org/

                               - DRAFT -

                                TAG f2f

23 Jun 2009


      [2] http://www.w3.org/2001/tag/2009/06/23-agenda

   See also: [3]IRC log

      [3] http://www.w3.org/2009/06/23-tagmem-irc


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


          Noah Mendelsohn

          Henry S. Thompson, John Kemp


     * [4]Topics
         1. [5]Admin
         2. [6]W3C Work on APIs
         3. [7]Language Versioning and HTML
         4. [8]Web Application State Management
         5. [9]Javascript Security
     * [10]Summary of Action Items

   <ht> ScribeNick: ht

   <scribe> Scribe: Henry S. Thompson


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

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

     [11] http://www.w3.org/2001/tag/2009/06/23-agenda

   NM: [intro to meeting, see

     [12] 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


     [13] 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

   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

   LM: The problem only arises when you have agents that want to
   interact with e.g. script-containing pages _without_ just running
   ... 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
   ... You can't tell what a program will do w/o running it, but you
   can make some of it, e.g. dependencies,
   ... 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
   ... 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

   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

   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

   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

   <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

   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

   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

   <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

   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


     [14] 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
   ... 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." -- [15]http://www.w3.org/TR/webarch/#versioning

     [15] http://www.w3.org/TR/webarch/#versioning

   NM: I produced a blog entry which went some way in that direction

     [16] 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


   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

   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

   JK: Entire?

   DC: In principle, yes

   <DanC_lap> DC: I read
   0090611.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
   ... 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
   ... There's a whole economy of production, consumption, analysis,

   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

   <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


   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


   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:


   <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

   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
   [22]http://microformats.org/wiki/invisible-data-considered-harmful )

     [22] 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
   ... 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

   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


     [23] 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
   ... 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

   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



   TVR: in a browser you have window, which has document which has a
   ... browser back and forward can page from one URL doucment to the
   ... 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

   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)


     [25] 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

   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

   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

   <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

   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...
   [26]http://www.w3.org/html/wg/tracker/issues/53 ISSUE-53
   mediatypereg Need to update media type registrations State: RAISED)

     [26] http://www.w3.org/html/wg/tracker/issues/53

   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
   ... navigation in these apps is often done quite privately

   LMM: OpenAJAX Alliance works on good practice statements for AJAX
   ... 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
   ... 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

   <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

   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

   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)


Javascript Security


     [27] 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

     [28] 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

     [29] 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"
   [30]http://waterken.sourceforge.net/web-key/ is an extensive
   critique of 3.5.2. Linking and access control

     [30] http://waterken.sourceforge.net/web-key/
     [31] 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

   [32]http://www.w3.org/TR/access-control/ Cross-origin Resource

     [32] http://www.w3.org/TR/access-control/

   JAR: there is conflict between CORS and this capability approach
   ... Tyler and Mark Miller asking for GuestXHR feature support in
   ... 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 -
   ... 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

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

     [34] 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

     [35] 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

     [36] 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

     [37] 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

   <scribe> ACTION: Henry to draft a message to webapps chairs relaying
   TAG concerns around CORS [recorded in

     [38] 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

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


   <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

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

   <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

     [41] 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

   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

   (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
   [NEW] ACTION: Henry to draft a message to webapps chairs relaying
   TAG concerns around CORS [recorded in
   [NEW] ACTION: Henry to draft a message to webapps chairs relaying
   TAG concerns around CORS [recorded in
   [NEW] ACTION: ht to draft a message to webapps chairs relaying TAG
   concerns around CORS [recorded in
   [NEW] ACTION: Jonathan to draft changes to 2.7 of Metadata in URIs
   to cover the "Google Calendar" case [recorded in

     [42] http://www.w3.org/2009/06/23-tagmem-minutes.html#action05
     [43] http://www.w3.org/2009/06/23-tagmem-minutes.html#action02
     [44] http://www.w3.org/2009/06/23-tagmem-minutes.html#action04
     [45] http://www.w3.org/2009/06/23-tagmem-minutes.html#action01
     [46] http://www.w3.org/2009/06/23-tagmem-minutes.html#action03

   [End of minutes]

    Minutes formatted by David Booth's [47]scribe.perl version 1.135
    ([48]CVS log)
    $Date: 2009/07/21 19:39:15 $

     [47] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [48] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 10 August 2009 20:45:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:30 UTC