minutes TAG meeting 24-26 March in Cambridge, MA, USA for review

by reference:


by value, for tracker/search engine, etc.:


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

                               - DRAFT -

                            TAG F2F Meeting

24 Mar 2010

   See also: [2]agenda, [3]IRC log

      [2] http://www.w3.org/2001/tag/2010/03/24-agenda.html
      [3] http://www.w3.org/2010/03/24-tagmem-irc


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

          Noah Mendelsohn

          Dan Connolly (morning), John Kemp (afternoon)


     * [4]Topics
         1. [5]Convene, review agenda
         2. [6]Joint session w/HTML WG Chairs
         3. [7]Joint session w/HTML WG Chairs: Escalated issues and
            change proposal status
         4. [8]HTML WG joint session with chairs: high level topics
         5. [9]HTML WG co-chair joint session: xml/html co-existence
         6. [10]HTML chairs joint session: decentralized extensibility
         7. [11]Doctypes and Versioning
         8. [12]Web Application Architecture: Security, Policy &
         9. [13]Administrative issues
        10. [14]HTML 5 Decentralized Extensibility (ISSUE-54)
        11. [15]IRIEverywhere
     * [16]Summary of Action Items

Convene, review agenda

   <DanC_> scribenick: DanC_

   NM: we expect Paul Cotton and Sam Ruby for the joint session with
   the HTML WG chairs; we have regrets from Maciej
   ... note LMM is off to the IETF meeting tomorrow afternoon, so
   that's a constraint on the agenda

   (NM notes a few other items on the agenda Revision: 1.36 of
   2010/03/23 15:32:34 )

   NM: the current agenda is biased toward the "let's not introspect
   much; just technical work, please" advice I've heard, but then more
   recently I've heard some call to take a look at the TAG mission

   DKA: yes, as a new TAG arrival, some introspection looks useful
   ... I prepared some stuff on mobile as requested; looks like it's
   not yet on the agenda, presumably because I didn't notify you that
   it's done.

   NM: [missed]

Joint session w/HTML WG Chairs

   Sam Ruby, Mike Smith, and Philippe Le Hégaret arrive

   NM: HT's travel has gotten complicated; he's delayed a few hours

   NM: suggested topics?

   PLH: (1) action items from TAG ftf in Nov ...
   ... (2) go over the list of issues, especially the ones we know the
   TAG is interested, as well as the others to make sure we didn't miss
   some that should be on the TAG radar

   NM: also, there's been a request to talk about where the HTML WG is
   on the way to Last Call, CR, etc.

   -> [17]HTML 5 Update

     [17] http://www.w3.org/2010/Talks/0323-html-plh/

   PLH explains HTML WG decision process...

   PLH: bugs are getting fixed about as fast as they arrive; the good
   news is that they're getting fixed; the bad news is that this
   projects time of LC never comes
   ... bug submission was facilitated by a quick-bug-submit form in the
   spec... such bugs are not attributed /anonymous

   (much grumbling about anonymous contributions)

   "Getting to Last Call" slide

   PLH: rate-limiting factor seems to be accessibility issues

   SR: there are 2 kinds of accessibility issues: (a) the technically
   complex ones, such as accessibility of canvas...
   ... and (b) technicall straightforward issues, such as whether alt
   text is mandatory, where consensus is harder to achieve in larger

   LMM: [something about priority of market forces vs policy? scribe
   was behind]

   <masinter> I wondered whether this was specifically an issue around
   accessibility, or if it was really a conflict between policy-based
   requirements vs. market requirements

   <masinter> that some of the accessibility requirements came from
   trying to enforce a policy that wasn't directly a result of market
   forces but trying to do social re-engineering

   SR: I strongly agree
   ... there's a line of argument that says "this technical feature has
   been in the spec for a decade and experience shows the market
   doesn't want to use it or can't use it productively"...
   ... some people use that argument _against_ mandatory-alt but not
   against presentational markup such as <canvas> [is canvas a typo? I
   think he gave a better example.]

   Paul C. arrives

   TBL: [not sure about the gist... something about the tension between
   acknowledging the importance of accessibility vs the technical
   awkwardness of making alt mandatory]

   <rubys> validator messages for google.com, roughly sorted by

     [18] http://intertwingly.net/stories/2010/03/20/www.google.com

   LMM: is this restricted to accessibility issues? or are there more
   policy issues? the accessibility community is energized now, but
   we've seen similar issues around privacy
   ... also security... e.g. origin header

   <masinter> security over origin header, stability through network

   TVR: as an end-user, alt on images that has frustrated me to no
   end... as an end-user, I couldn't care less. [struggling to
   paraphrase, so just recording verbatim]
   ... the hope for @alt was that authoring tools would prompt for alt
   text when images were added...

   <timbl> TimBL: The mandatoriness of the ALT attribute is a unique
   case in the things the TAG has considered. It is very much of a
   political statement that accessibility is important. It encourages
   but does not force those who hand-edit a spec to include alt text.
   It encourages editors like Amaya to ask for it. There are many cases
   when the spec is not hand-edited. An editor can prompt for it
   anyway. There are many cases when it is important that the alt
   attribute v

   <timbl> be an empty string. Before everyone accepted this as the
   benefit of encouraging ALT tag use was felt of overriding value.In
   these cases the document is made unnecessarily long, wasting time
   and space. As Larry says, the geopriv was similar case.

   <timbl> We do after all have authoring tool guideliens.

   <timbl> But we are not really talking about the ALT attribute, we
   are talking about the srt of problem which the HTML WG has with

   TVR: but with workflows such as flicker, that's not a reasonable

   TVR: so if we could mark aspects of the language with good behaviour
   for authoring tools rather than constraints on the language, that
   seems a better way to go

   <Zakim> DKA, you wanted to note an interesting parallel between alt
   tag discussion and geo api privacy discussion.

   DKA: [... missed some] implementor notes in the spec about privacy
   issues [?]

   DC: On alt and maybe others, I was hoping HTML would say "optional,
   but see WCAG"

   <timbl> See

     [19] http://www.w3.org/TR/WAI-AUTOOLS/#gl-prewritten-descs

   <timbl> Guideline 3. Support the creation of accessible content.

   <timbl> (in Authoring Tool Accessibility Guidelines 1.0

   <timbl> W3C Recommendation 3 February 2000)

   <Zakim> noah, you wanted to discuss tools vs. people

   NM: re implementor guidelines... perhaps there are times/places to
   mention tools...

   NM: but mostly I'd rather you didn't mention tools but rather think
   of them as use cases...

   NM: I think it's better to just say what's in the language and
   what's out

   <johnk_> the problem is one where social policy is enforced in RFPs

   raman: for the alt tag, I would agree, but wouldn't agree in general

   <Zakim> rubys, you wanted to inquire about the IETF practice of BCP

   SR: what about separating "best practices" e.g. "use css rather than
   <center> or <font>" from the core spec? would the TAG support that?

   [poll gets truncated by meta discussion]

   <timbl> My 2c: It is very important for the spec to point guidelines
   but it should not replicate the body of the advice, just the title.

   <johnk_> separating best practices from the specific mechanisms used
   to support/enforce those best practices is a good idea

Joint session w/HTML WG Chairs: Escalated issues and change proposal

   <paulc> [20]http://dev.w3.org/html5/status/issue-status.html

     [20] http://dev.w3.org/html5/status/issue-status.html

   <rubys> [21]http://www.w3.org/html/wg/tracker/issues/open and

     [21] http://www.w3.org/html/wg/tracker/issues/open
     [22] http://dev.w3.org/html5/status/issue-status.html

   <rubys> [23]http://dev.w3.org/html5/status/issue-status.html

     [23] http://dev.w3.org/html5/status/issue-status.html

   <rubys> topic ISSUE-4 html-versioning

   <rubys> ISSUE-9 video-accessibility

   SR: I think that's in hand by the accessibility TF

   <rubys> ISSUE-27 rel-ownership

   SR: doubt this should be on the TAG radar; to summarize: the spec
   currently says "see this wiki"; others a have said "use an IETF

   TBL: that's architectural

   <scribe> ACTION: DanC to track HTML WG ISSUE-27 rel-ownership
   recorded in [24]http://www.w3.org/2010/03/24-tagmem-irc]

     [24] http://www.w3.org/2010/03/24-tagmem-irc

   <trackbot> Created ACTION-404 - Track HTML WG ISSUE-27 rel-ownership
   [on Dan Connolly - due 2010-03-31].

   ACTION-404: Paul C agrees to notify the TAG about this

   <masinter> i'm interested in discussing what I think are the
   higher-level positioning differences rather than the issues

   <rubys> ISSUE-30 longdesc

   <trackbot> ACTION-404 Track HTML WG ISSUE-27 rel-ownership notes

   <rubys> ISSUE-31 missing-alt

   <rubys> table-summary

   <rubys> ISSUE-41 decentralized-extensibility

   <masinter> i think the underlying issue for this one is "who

   LMM notes...


   <trackbot> ACTION-396 -- Noah Mendelsohn to henry to draft emails
   for NM to send to HTML WG chairs and to Liam+MS authors encouraging
   a change proposal wrt distr. extensibility by 23 March -- due
   2010-03-05 -- PENDINGREVIEW

   <trackbot> [25]http://www.w3.org/2001/tag/group/track/actions/396

     [25] http://www.w3.org/2001/tag/group/track/actions/396

   <rubys> ISSUE-56 urls-webarch

   LMM: urls-webarch seems to be on course

   DC: estimated timeline for urls-webarch?

   LMM: I think the HTML WG can treat the URI/IRI spec as orthogonal,
   so it can be done quickly in the HTML WG

   <rubys> ISSUE-66 image-analysis

   <rubys> ISSUE-74 canvas-accessibility

   <rubys> ISSUE-78 urls-terminology

   <rubys> ISSUE-80 title-alternative

   <rubys> ISSUE-81 representation-vs-resource

   <rubys> ISSUE-82 profile-disambiguation

   <DanC> (I think it's pretty wierd to separate the 2 profile issues)

   DC: is there another, lowered-number issue re profile? is that

   SR: yes, it's closed; the resolution is to not add head/@profile,
   but to put it in a separate spec

   <rubys> ISSUE-84 legacy-doctypes

   <rubys> ISSUE-85 anchor-roles

   <rubys> ISSUE-86 atom-id-stability

   <rubys> ISSUE-88 content-language-multiple

   <rubys> ISSUE-104 sniffing-optional

   <rubys> ISSUE-101 us-ascii-ref

   <MikeS> about issue 99, Dublin Core uses meta/@scheme

   NM reviews [26]TAG actions filed under HTML 5 review product

     [26] http://www.w3.org/2001/tag/group/track/products/6

   LMM: I'd like to talk about things at a higher level... policy vs
   market needs... control going forward... the "evergreen WG" model...

   <masinter> policy vs. market needs

   <masinter> backward compatibility vs. future


   <trackbot> ACTION-379 -- Larry Masinter to check whether HTML
   language reference has been published -- due 2010-05-21 -- OPEN

   <trackbot> [27]http://www.w3.org/2001/tag/group/track/actions/379

     [27] http://www.w3.org/2001/tag/group/track/actions/379

   PaulC: we published that on [March 5?]

   <timbl> 3- on 3


     [28] http://intertwingly.net/blog/2010/03/20/Authoring-Conformance-Requirements

HTML WG joint session with chairs: high level topics

   LMM: I was making a list of [html wg issues?] "who can make html

   TBL: this sounds like just life... i.e. something that happens any
   time you get more than one person involved in something

   LMM: W3C can be a lever for parties that advocate for policy
   issues... privacy, i18n, etc. rather than approaching individual
   ... so rather than commenting a la "please change X to Y because we
   like it" but rather "please change X to Y because of this policy

   JK: but then aren't we arguing for people who should themselves be
   in the WG?

   <masinter> modularity

   <masinter> modularity requirements don't affect any particular group

   TBL: I'm not persuaded there's a problem...
   ... there are people who feel strongly about those policies who do
   get involved...

   <masinter> discussion of the nature of policies, the role of the
   TAG, and the nature of the kinds of comments we're making on HTML WG

   TBL: people ref modularity in comments

   <Zakim> DanC_, you wanted to ask PLH about US ASCII and to

   DanC: I think it is really useful to get the people from those those
   companies building stuff other than browsers involved in issues,
   e.g. sniffing

   <johnk_> +1 to getting others involved to be a concrete action that
   TAG members could undertake that would help in advocating for
   policy-type decisions in technical specs.

HTML WG co-chair joint session: xml/html co-existence

   SR: trailing slashes on a small number of elements are allowed...
   ... this brings these worlds closer together...

   SR: it's only on, e.g. <script> and <textarea>, the /> won't work in
   deployed software and hence the spec is unlikely to change in that

   <Zakim> masinter, you wanted to ask whether this is the other side
   of XHTML's appendix on how to be HTML compatible?

   SR: another aspect is character sequences that are valid in both
   XHTML and HTML but mean differen things; e.g. the 1st newline in

   TBL: <tbody>

   <rubys> [29]http://wiki.whatwg.org/wiki/HTML_vs._XHTML

     [29] http://wiki.whatwg.org/wiki/HTML_vs._XHTML

   LMM: there was an appendix of XHTML that said how to write XHTML
   that was compatible with [deployed text/html usage]...

   SR: there's sentiment that that appendix C failed; the spec doesn't
   even try now; in some sense that's a step backwards

   <MikeS> I think as document such as the one that masinter describes
   would be more appropriate as a separate document, editing
   separately, not as part of the HTML5 spec itself

   SR: my site [uses the same bytes for XHTML and HTML or something]

   TBL: my requirement is [everybody talks at once]

   <masinter> there be a requirement to define a polyglot set

   TBL: e.g. for just tbody... there are 2 things you can do: (a)
   include <tbody> all the time; but that's a pain...
   ... or (b) ensure there are no scripts that depend on it...

   <Zakim> plh, you wanted to ask polyglot

   <Zakim> noah, you wanted to discuss form of conformance note

   TBL: some prefer one way; some prefer the other way; so the spec
   should allow both [?]

   <timbl> DanC, the request was to move on from Larry's issue by then.
   We have already

   NM: sounds like there's some sentiment for asking for some document
   to be produced... anybody want to be more concrete?

   <timbl> Why, PLH. if I don't use the DOM?

   <timbl> I use it as a markup language

   DKA: if what I heard is correct... > has to be escaped differently
   in XHTML vs HTML... that sounds like a big problem...

   NM: well, nobody's proposing to fix it --

   SR: or is he?

   LMM: how hard would it be to [fix it]?

   TBL: impossible, because --

   SR: [on layering of javascript parsers and html parsers ]

   <Zakim> DanC_, you wanted to note tbody xpath

   <timbl> Larry, please scribe

   danc: regarding tbody (and xxx) you can make sure your scripts work,
   but you can't keep other people's xpath from not working if you
   don't put in a tbody

   DC: Tim, regarding TBODY in Xpath, just because you don't write a
   script doesn't mean other people won't look in your document using

   timbl: nice point

   <masinter> (discussion about whether xpointer syntax can be used in
   fragment identifier)

   (and whether it's relevant to text/html)

   <masinter> timbl: at the moment, i use text/html and polyglot

   <DanC> (there is (or was?) an XPath/HTML issue in the HTML WG... I
   wonder what became of that.)

   discussion about fragment identifiers & use of xpointer

   paulc: (asking for tag to read minutes from our Nov meeting & do

   <paulc> [30]http://www.w3.org/2009/11/05-html-wg-minutes.html#item02

     [30] http://www.w3.org/2009/11/05-html-wg-minutes.html#item02

   noah: i thought we did what paulc is asking for

   paulc: trying to page the tag back in

   noah: hixie said "that's ambiguous, i'll fix it"

   paulc: there was a reference to a set of rules for polyglot

   <timbl> This? [31]http://www.la-grange.net/2009/07/05/html5-xhtml5/

     [31] http://www.la-grange.net/2009/07/05/html5-xhtml5/

   <DanC> +1 ask the HTML WG to do a Note a la "HTML 5 and XHTML 5 -
   one vocabulary, two serializations"

   <rubys> timbl, I think that is NOT what you want

   tim: would like this to be in TR space, not just hidden somewhere in

   <timbl> ... Thtis? [32]http://wiki.whatwg.org/wiki/HTML_vs._XHTML

     [32] http://wiki.whatwg.org/wiki/HTML_vs._XHTML

   TBL, TVR agree

   <masinter> sam: I think what Tim wants is a description of a set of
   .... (discussion of what polyglot could be)

   + HT

   <plh> Sam: an HTML parser will load xmlns attributes are DOM
   attributes, and not as DOM NS properties

   <plh> ... including xmlns="[33]http://www.w3.org/1999/xhtml"

     [33] http://www.w3.org/1999/xhtml

   <rubys> turn [34]http://wiki.whatwg.org/wiki/HTML_vs._XHTML into a

     [34] http://wiki.whatwg.org/wiki/HTML_vs._XHTML

   <masinter> ask Sam & Tim to come to agreement on what needs to
   happen on polyglot, and bring back to TAG any questions

   <timbl> I want theat there should be in TR space a document which
   specifies how I can create a set of bits which I can server EITHER
   as text/html OR as xhtml+xml, which will work in a browser in both
   bases. As Sam does on his web site.

   <timbl> It will rule out certain features.

   +1 ask the HTML WG for a note that explains, basically, what Sam
   does on his web site; i.e. the flip side of

     [35] http://wiki.whatwg.org/wiki/HTML_vs._XHTML

   <masinter> 1+ to timbl's suggestion

   <noah> I want an action to put before tag the options for doing what
   Tim wants

   <timbl> There may be more than one different recipe.

   <DanC> +1 ask the HTML WG for a W3C WG Note that explains,
   basically, what Sam does on his web site; i.e. the flip side of

     [36] http://wiki.whatwg.org/wiki/HTML_vs._XHTML

   <timbl> PROPOSED: We want theat there should be in TR space a
   document which specifies how I can create a set of bits which I can
   server EITHER as text/html OR as xhtml+xml, which will work in a
   browser in both bases. As Sam does on his web site.

   <timbl> PROPOSED: We want theat there should be in TR space a
   document which specifies how I can crteate a set of bits which I can
   server EITHER as text/html OR as application/xhtml+xml, which will
   work in a browser in both bases. As Sam does on his web site.

   <timbl> ooops

   <MikeS> .me wonders if anybody would be willing to volunteer to act
   as editor for that doc

   <masinter> There might be some changes to HTML needed?

   RESOLVED: We want theat there should be in TR space a document which
   specifies how I can crteate a set of bits which I can server EITHER
   as text/html OR as application/xhtml+xml, which will work in a
   browser in both bases. As Sam does on his web site.
   . ACTION DanC: ask the HTML WG to do produce a WG Note that
   satisfied the document the TAG resolved it wants (sort about
   polyglot documents)

   (that's not English, but I'll fix it)

   <scribe> ACTION: DanC to ask the HTML WG to do produce a WG Note
   that satisfied the document the TAG resolved it wants (sort about
   polyglot documents) [recorded in

     [37] http://www.w3.org/2010/03/24-tagmem-irc

   <trackbot> Created ACTION-405 - Ask the HTML WG to do produce a WG
   Note that satisfied the document the TAG resolved it wants (sort
   about polyglot documents) [on Dan Connolly - due 2010-03-31].

HTML chairs joint session: decentralized extensibility


   <trackbot> ACTION-396 -- Noah Mendelsohn to henry to draft emails
   for NM to send to HTML WG chairs and to Liam+MS authors encouraging
   a change proposal wrt distr. extensibility by 23 March -- due
   2010-03-05 -- PENDINGREVIEW

   <trackbot> [38]http://www.w3.org/2001/tag/group/track/actions/396

     [38] http://www.w3.org/2001/tag/group/track/actions/396

   NM: we encouraged people to send proposals
   ([39]http://lists.w3.org/Archives/Public/www-tag/2010Mar/0015.html )

     [39] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0015.html

   close action-396

   <trackbot> ACTION-396 Henry to draft emails for NM to send to HTML
   WG chairs and to Liam+MS authors encouraging a change proposal wrt
   distr. extensibility by 23 March closed

   <rubys> follow four links in the last column of

     [40] http://dev.w3.org/html5/status/issue-status.html#ISSUE-041


     [41] http://www.w3.org/html/wg/wiki/ChangeProposals/fixedprefixlikexml

   <timbl> Change Proposal: "Proposal X", Registered XML-Style
   Namespace Prefixes

   <timbl> Change Proposal: "Proposal Y", Hyphen-Separated
   Vendor-Prefixed Attributes

   <timbl> Change Proposal: XML-style namespaces with some naming

   <timbl> Change Proposal: Generalize the mechanism used for SVG and

   <timbl> Change Proposal: There is no problem and the proposed remedy
   is to change nothing.


     [42] http://www.w3.org/html/wg/wiki/ChangeProposals/fixedprefixsimple

   <noah> [43]http://www.w3.org/html/wg/wiki/ChangeProposals/html:xmlns

     [43] http://www.w3.org/html/wg/wiki/ChangeProposals/html:xmlns


     [44] http://www.w3.org/html/wg/wiki/ChangeProposals/extensionslikesvg


     [45] http://lists.w3.org/Archives/Public/www-archive/2010Mar/0030.html

   issue status shows ~5 proposals (as noted above)

   SR: re the one-serialization, same DOM idea we just talked about...
   that argues _against_ re-using XML namespace syntax...
   ... because colon-separated names will be parsed differently

   TBL: Microsoft has announced support for XHTML, i.e.
   application/xhtml+xml ; the IE9 thingy-that-is-not-a-browser shows
   alpha support

   PLH: error handling is novel... maybe they're still experimenting
   with that...
   ... it shows the part of the document up to the error, rather than a
   traditional "XML parse error on line XYZ"

   <rubys> [46]http://intertwingly.net/stories/2010/03/17/illformed.jpg

     [46] http://intertwingly.net/stories/2010/03/17/illformed.jpg

   PLH: there's concern about the difference in behaviour here

   TBL: the whole fork of HTML & XHTML .... 'what if' .... things might
   have been different

   raman: two blockers: IE popped up a download, and second was IE
   behavior ...

   SR: the HTML 5 spec defines the term "XHTML" as "content served as
   application/xhtml+xml"; so for the purposes of this discussion,
   let's get clear, please

   TVR: I prefer to define XHTML as "well-formed documents that use the
   HTML vocabulary".

   SR: what if you forget to quote an attribute? double-checking...

   TVR: indeed, a document with such a well-formedness error I call
   HTML, not XHTML

   <Zakim> noah, you wanted to ask Raman, are you expecting

   SR: I don't advocate that definition because people will write
   scripts with < in them and it won't work


   <masinter> "What is a chair? What I'm sitting on is a chair. A stool
   is a kind of a chair. A three-legged stool with one of the legs
   missing is a broken chair, which is a kind of a chair except you
   can't sit on it. A tree that falls in the forest, which looks like a
   chair, but nobody sits on it... is it a chair?"

   [discussion of how to bind/define "XHTML", parsing rules, DOM, etc.
   exceeds scribe bandwidth]

   SR: IE9 currently treats well-formed XHTML 1.0-conforming stuff
   served as text/html using the HTML parsing rules; I obviously can't
   speak for that vendor, but I don't expect that to change..
   ... because of compatibility

   <masinter> ack

   HT: there are documents with .htaccess that says to serve them as
   application/xhtml+xml except to MS IE... [missed the main point;

   <MikeS> ht, I believe the schema spec is non-conformant text/html --
   it has many instances of <a name="foo"/> -- which is not conformant
   in text/html

   <Zakim> masinter, you wanted to review

     [47] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0043.html

   LMM: as I say in 0043, we get into trouble by using terminology as
   if it's intrensic when it's extrinsic

   <plh> the question is "Should text/html in HTML 5 provide support
   for XML namespaces in the syntax and the DOM tree?"

   PC: I heard Tim saying MS IE9 support might change the game... does
   the TAG think that's the case? does that take pressure off? does
   that make the fork less wide?

   TVR: it makes the fork wider

   <DanC>+1 it makes the fork wider

   TBL: to large organizations such as IBM and Microsoft, when rolling
   out new features... will <video> work with XHTML? If so, perhaps I
   don't have such a strong requirement for distributed extensibility
   in text/html...
   ... but I'm not holding my breath for that [verbatim; might be
   missing the gist]

   TBL: [help? colon in tag... not using it for namespaces...] not many

   SR: you'd be surprised... I think I have an example from a top-20

   PLH: opera tried to deploy XML namespaces in text/html that way...
   they found it too troublesome

   <Zakim> noah, you wanted to answer paul

   SR: the top-20 example is jotspot


     [48] http://www.google.com/#hl=en&source=hp&q=xmlns%3D%22http%3A%2F%2Fwww.google.com%2Fns%2Fjotspot%22&btnG=Google+Search&aq=f&aqi=&aql=&oq=xmlns%3D%22http%3A%2F%2Fwww.google.com%2Fns%2Fjotspot%22&fp=ae8f9588018abe0f

   <timbl> Google bought jotspot and so own the content and can fix it

   <plh> timbl, I see content using jotspot on www.pitt.edu

   <plh> they can fix the software though

   NM: I think everybody thinks the text/html mime type is really
   important, for at least a decade or so...

   NM: so when somebody wants to add, e.g. 3d video, must they come to
   a centralized forum, or are they free to innovate?
   ... so to answer your question, TimBL, I think it's important that
   something like one of these 3 proposals gets consensus

   <Zakim> raman, you wanted to point that long-term, an architectural
   goal is the convergence of Web content rather than continuing the
   xml/html fork

   raman: increases the pressure, doesn't decrease the pressure

   TVR: i think having separate mime types converge over time is better

   <Zakim> masinter, you wanted to ask for authoring guidance,
   application to SVG & MathML & 3D graphics, RDFa, as noted in HTML
   working group charter

   LMM: looking at the HTML WG charter, which speaks of extensibility
   in HTML, not XHTML...
   ... sounds like you're making progress...
   ... [missed his main point?]

   <masinter> "The HTML WG is encouraged to provide a mechanism to
   permit independently developed vocabularies such as
   Internationalization Tag Set (ITS), Ruby, and RDFa to be mixed into
   HTML documents. Whether this occurs through the extensibility
   mechanism of XML, whether it is also allowed in the classic HTML
   serialization, and whether it uses the DTD and Schema modularization
   techniques, is for the HTML WG to determine."

   LMM: maybe it's worth re-visiting the way SVG and MathML were
   integrated and using a generalized mechanism


     [49] http://www.w3.org/html/wg/wiki/ChangeProposals/extensionslikesvg

   SR: there's a change proposal along those lines. [cited above]

   lmm: sounds like the working group is closer to meeting what the
   charter called for it to do, which doesn't reduce the priority

   <MikeS> masinter, as far as the exact use cases in the statement you
   quote, we already have specs for integrating Ruby and RDFa (as far
   as ITS, no person or group has yet specifically asked the group to
   address that)

   DKA: is it out of the question to say that text/html is extensible
   to a limited extent, but if you want more, you have to use

   PLH: considering possibilities such as SMIL in HTML 6, I see
   backward compatibility problems...

   <Zakim> ht_stanford, you wanted to argue the benefits of lightweight
   namespaces in their own right

   HT: [missed some] in these proposals, there's something that will
   make XML better...

   HT: if HTML adopts proposals that allow [something about popular
   prefixes or namespaces], I can see it getting integrated into XML

   <raman> I strongly believe this is our last opportunity to fix this

   noah: future proofing of language is important: if you want to add
   something in HTML6 and it would break, that would be bad.

   NM: re which of these proposals the TAG supports, [stuff about

   noah: want to ask HTML WG to come up with clear analysis

   <Zakim> noah, you wanted to talk about profile

   <Zakim> DanC_, you wanted to say I haven't seen anything that looks

   DC: Haven't seen anything that looks likely...I.e. meets
   compatibility constraints, interesting to me, get critical mass of

   <masinter> paulc: discussion of whether this is a political or
   technical extensibility mechanism

   <timbl> The counter-proposal
   l says <<The issue description says that "The HTML5 specification
   does not have a mechanism to allow decentralized parties to create
   their own languages, typically XML languages, and exchange them in
   HTML5 text/html

     [50] http://lists.w3.org/Archives/Public/www-archive/2010Mar/0030.html

   <timbl> serializations", but to all appearances this is a good
   thing, not a problem. Why would we want to encourage vendors to
   create proprietary languages and exchange them as text/html?>> which
   is a false argument as extensions may well be community-related such
   as Mathml, and not vendor proprierary at all. It is a core
   requirement on HTML that it should allow communities to define
   extensions for use by that community without asking the HTML WG.

   PaulC: [something about the evergreen WG no-change proposal]

   <Zakim> masinter, you wanted to ask HT if he can recall what he
   heard from Liam, and whether there might be some way of changing
   error recovery rules in XML or make them more explicit

   <raman> A different perspective on the TAG's bar --- i disagree with
   Dan. I believe any proposal is better than what is in the spec.

   I should clarify... I'd like to see decentralized extensibility
   happen; I probably won't oppose any of the proposals.

   <scribe> ACTION: Noah get the TAG to evaluate the decentralized
   proposals in the HTML WG [recorded in

     [51] http://www.w3.org/2010/03/24-tagmem-irc

   <trackbot> Created ACTION-406 - Get the TAG to evaluate the
   decentralized proposals in the HTML WG [on Noah Mendelsohn - due

   lmm, what did you want to add about noah's action?

   action-406: and the discussion of the proposals in the HTML WG

   <trackbot> ACTION-406 Get the TAG to evaluate the decentralized
   proposals in the HTML WG notes added

Doctypes and Versioning

   <johnk> scribeNick: johnk

   NM: HTML has action on Larry to resolve HTML ISSUE-4
   ... HTML WG set a deadline to close this issue
   ... We told HTML WG we would respond by the end of this meeting



   <trackbot> ACTION-364 -- Dan Connolly to ask HTML WG team contacts
   to make a change proposal re issue-53 mediatypereg informed by HT's
   analysis and today's discussion -- due 2010-02-25 -- PENDINGREVIEW

   <trackbot> [52]http://www.w3.org/2001/tag/group/track/actions/364

     [52] http://www.w3.org/2001/tag/group/track/actions/364

   <DanC_> close action-393

   <trackbot> ACTION-393 Update HTML WG co-chairs along the lines of
   ... DOCTYPE... workflow... media type.. closed

   <noah> [53]http://www.w3.org/html/wg/tracker/actions/172

     [53] http://www.w3.org/html/wg/tracker/actions/172

   LM: HTML5 spec on DOCTYPE has changed, so I closed 172

   <DanC_> [54]8.1.1 The DOCTYPE

     [54] http://dev.w3.org/html5/spec/syntax.html#the-doctype

   (see above link for current text)

   LM: ISSUE-4 is still open, ISSUE-84 already addressed

   NM: is this OK?

   LM: Would like TAG to look at change proposals for ISSUE-4

   DC: should review the 8.1.1 HTML text

   HT: If you allow 1.0 should also allow transitional et al

   NM: this does seem to have been considered carefully

   HT: choosing 2 of the 4 public ids for HTML does seem odd
   ... what happened to the much bigger list of ids?

   LM: there's another section that deals with quirksmode
   ... attempt was to make those doctypes that triggered quirks mode


   <trackbot> ISSUE-41 -- What are good practices for designing
   extensible languages and for handling versioning? -- OPEN

   <trackbot> [55]http://www.w3.org/2001/tag/group/track/issues/41

     [55] http://www.w3.org/2001/tag/group/track/issues/41


     [56] http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html)

   DC: HTML 5 spec says all the font tag containing docs "become lies";
   proposed replacement:

   Serving a document as text/html licenses processing

   by user agents as specified in this spec.

   (specifically, section 8.2 Parsing HTML documents)

   Documents served as text/html *should* conform

   to the HTML 5 syntax, but consumers should beware

   that existing content varies considerably; note especially

   section 11 on Obsolete features.

   <masinter> I like [57]http://www.ietf.org/rfc/rfc2854.txt better

     [57] http://www.ietf.org/rfc/rfc2854.txt

   HT: would rather see this point to media types which HTML supercedes
   ... see [58]http://www.ietf.org/rfc/rfc2854.txt for information
   about "legacy" documents

     [58] http://www.ietf.org/rfc/rfc2854.txt

   <masinter> [59]http://www.ietf.org/rfc/rfc2854.txt

     [59] http://www.ietf.org/rfc/rfc2854.txt

   <masinter> [60]http://tools.ietf.org/html/rfc2854

     [60] http://tools.ietf.org/html/rfc2854

   (reviewing RFC2854)

   TVR: how do we expect the whole community to figure this when we
   have a hard time finding the relevant reference?

   LM: structured as "interoperability considerations"
   ... yes, there's a public spec, but the MIME type reg tells you what
   you have to do
   ... can see updating this doc for HTML5
   ... ie. latest published specification is updated from 4.01 to 5

   TBL: I don't like publishing separate registration from the spec.

   JR: registry of media types will get you to the right place

   HT: I understood you could do this in the relevant section of HTML5

   LM: could take the text from the media reg and put it somewhere else

   TBL: should be a master spec. media type reg _is_ the specification
   of the language, whether it's the cover page, or the full spec.
   ... otherwise there is the irresistable temptation to put stuff in
   one document and not the other

   HT: Like Dan's proposal augmented with something like in RFC2854
   that describes the relationship to previous versions of the language

   TBL: should be clear to anyone reading the spec that old versionned
   documents are ok

   HT: perfectly reasonable to say that HTML5 document doesn't contain
   features of HTML4
   ... side-effect of moving prose from media type spec to language

   TBL: (something about text/html document vs. HTML5 document)

   <masinter> normally mime types point to language series, where
   individual versions are distinguished by language version indicator

   NM: I think it's important that layering is correct - there are two
   ways to make "font tag" legal

   <Zakim> DanC_, you wanted to move to divide the question

   <Zakim> masinter, you wanted to talk about version indicators
   relationship to conformance rquirements

   LM: traditionally, MIME type points to a language _series_
   ... MIME type doesn't change when you change the language
   ... in the doc itself, it says what version it is
   ... allows you to version the language

   <Zakim> noah, you wanted to ask about edge cases

   LM: without DOCTYPE or other version indicator, you can't deprecate
   features from the language

   <DanC_> masinter, I heard that as something of an argument against
   my proposal; I'm sympathetic, but I didn't quite hear an alternative
   proposal, if you made one

   <DanC_> (I think our time is not well-spent word-smithing, since the
   HTML 5 editor is going to re-word anyway)

   NM: if no doctype, SHOULD conform to HTML, may conform to others
   ... but be aware that same syntax in different versions may cause
   clients to interpret document in ways different than specified in
   the current language spec.

   <DanC_> ("design point?" I only heard editorial changes. I guess I
   wasn't sufficiently tuned in)

   NM: design point is whether doctypes go away

   <masinter> this is another use case for DOCTYPE

   <masinter> documents without a doctype, the intended version is

   <Zakim> jar, you wanted to suggest just citing 2854

   NM: when doctype is not there, old constructs may be misinterpreted
   by new processors

   <noah> I suggest that be stated explicitly

   JR: minimum intervention for me would be to reference RFC2854
   ... can't cause old content to go from "OK" to "not OK"

   <masinter> "Interoperability Considerations" are as much of a part
   of the MIME registration as the "Published Specifications"

   LM: iop section of rfc2854 is normative, believis DanC thinks it's

   <DanC_> well, yeah, the considerations are part of the MIME
   registration, but it doesn't say that HTML 2 docs conform; it just
   says that consumers have to be bugward compatible if they want to
   read documents that are on the web

   JR: these specifications don't have a "statute of limitations"

   <masinter> making previously conforming documents non-conforming can
   be justified if they weren't actually implemented and deployed

   JR: just have one sentence that there will be documents out there
   which follow old versions of the specification

   <jar> danc: IETF made some content transition from "OK" to "not OK"

   JR: would like to see the information about these old languages be

   <Zakim> ht, you wanted to (eventually) move to consideration of the
   large list of public identifiers in section of the HTML5

   <Zakim> ht2, you wanted to point to the RFC about media type changes


     [61] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0011.html

   <DanC_> I think the business of making HTML 2 docs no longer
   conforming was an oversight; I was just disputing claims that it had
   never happened.

   My understanding of the discontinuity wrt the text/html media type

   registration prose is this:

   1) Previous media type registrations for text/html have explicitly

   grandfathered in documents allowed by all earlier registrations of


   2) IETF rules for media type re-registrations requires that sort of


   3) The current draft media type registration section of the HTML 5

   spec. does _not_ contain any such grandfathering.

   HT: media type registration rules REQUIRE you to do this for

   TVR: this has to be done right simply for use by other protocols,
   WGs and so on

   NM: any sympathy for my earlier suggestion?

   HT: we've lived without such in RFC2854
   ... can we log DanCs current text against the HTML WG bug

   LM: not happy with language around 'licenses'
   ... MIME reg is informative
   ... mime registration is descriptive of what senders mean


     [62] http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html

   <Zakim> masinter, you wanted to repeat that documents without
   DOCTYPE or version identifiers are thus to be treated as ambiguous

   <ht> ACTION to henry to propose an update to DanC's prose from
   l to explicitly reference or encorporate the HTML history, similarly
   to the way 2854 does

     [63] http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html

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

   <ht> ACTION henry to propose an update to DanC's prose from
   l to explicitly reference or encorporate the HTML history, similarly
   to the way 2854 does

     [64] http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html

   <trackbot> Created ACTION-407 - Propose an update to DanC's prose
   l to explicitly reference or encorporate the HTML history, similarly
   to the way 2854 does [on Henry S. Thompson - due 2010-03-31].

     [65] http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html

   NM: is there anything we should do before Friday for HTML WG?

   <ht> tracker, action-407 due 2010-03-25

   <masinter> action-407?

   <trackbot> ACTION-407 -- Henry S. Thompson to propose an update to
   DanC's prose from
   l to explicitly reference or encorporate the HTML history, similarly
   to the way 2854 does -- due 2010-03-31 -- OPEN

     [66] http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html

   <trackbot> [67]http://www.w3.org/2001/tag/group/track/actions/407

     [67] http://www.w3.org/2001/tag/group/track/actions/407

   <DanC_> action-407 due 25 March

   <trackbot> ACTION-407 Propose an update to DanC's prose from
   l to explicitly reference or encorporate the HTML history, similarly
   to the way 2854 does due date now 25 March

     [68] http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html

   <DanC_> close ACTION-364

   <trackbot> ACTION-364 Ask HTML WG team contacts to make a change
   proposal re issue-53 mediatypereg informed by HT's analysis and
   today's discussion closed

   <DanC_> ACTION-364: see action-407 for follow-up

   <trackbot> ACTION-364 Ask HTML WG team contacts to make a change
   proposal re issue-53 mediatypereg informed by HT's analysis and
   today's discussion notes added

Web Application Architecture: Security, Policy & Privacy

   JK: Thomas Roessler, Matt Womer join


     [69] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0022.html

   <DanC_> close ACTION-397

   <trackbot> ACTION-397 Frame F2F discussion on geolocation and
   geopriv, with help from DKA closed

   AM: Geoloc WG declined to add a "privacy hook" to the API
   ... even after receiving comments


     [70] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0022.html

   AM: I believe this issue will not go away

   DA: reminding people about similarity of this issue to the <alt>
   discussion - "policy through tags"

   AM: was told that some participants didn't want to put policy hooks
   into the API

   TLR: some relation to DAP WG
   ... flag for 'high-accuracy' could be used for protecting privacy
   ... ie. one could say "don't send high accuracy information, if not

   <DanC_> Dom's suggestion:

     [71] http://lists.w3.org/Archives/Public/public-geolocation/2010Mar/0014

   AM: I thought that even this had been requested, and then rejected?

   <DanC_> matt on fuzzing:

     [72] http://www.w3.org/2008/geolocation/track/issues/18

   NM: guidance is "only give it if explicitly requested"?

   MW: discussed "fuzzing" of location

   <tlr> I said that the "high accuracy flag" is motivated by battery
   consumption -- cell phone network based location vs gps

   <Zakim> masinter, you wanted to ask whether this is "mandating
   policy" as much as allowing a policy to be mandated, different from
   alt. This is about just saying there *is* an alt tag

   LM: there's one question "does the img tag have an alt", a second
   whether a value is mandated

   <tlr> can somebody clarify what the direction of the earlier
   discussion about alt was?

   LM: one question is whether the API has a hook to send policy

   <Zakim> noah, you wanted to talk (as usual) about extensibility

   LM: which is different from the question "do you mandate use of that

   <jar> masinter: There's a difference between saying the API has to
   have a way to communicate policy (that the ALT tag exist), and
   requiring communication of policy using that mechanism (making the
   ALT tag required)

   NM: my impression was that there was a difference within the
   ... so make sure you have an extensibility mechanism
   ... and allow that extensibility to be able to have "must
   understand" semantics
   ... policy is decoupled from the technical mechanism

   AM: you are suggesting one model of privacy
   ... geopriv guys have a different model

   <Zakim> DanC_, you wanted to cover "... on their head" from the Doty
   et. al. article in case tlr doesn't cover it

   <DanC_> <excerpt>

   <DanC_> Related work on location privacy standards in the IETF
   Geopriv working group

   <DanC_> takes a play out of the content management environment and
   builds a mechanism

   <DanC_> through which users can attach policies to their location
   information. This

   <DanC_> turns the standard processes of privacy law and practice
   that rely on entities

   <DanC_> providing notice to users through privacy policies on web
   sites to which users

   <DanC_> can choose whether to consent on their head.

   <DanC_> </excerpt>

   DC: arguments in the Doty et al paper, which align with arguments in
   the WG, suggested that the suggested mechanism ended up putting
   liability on the user agent, who would blame the UA

   NM: only way to solve this without trusting the UA is to encrypt the
   data for the public key of the recipient

   <Zakim> timbl, you wanted to ask about the order of magnitude of
   fuzzying typicall needde

   <DanC_> (record of what I said isn't clear, which reflects a certain
   amount of unclarity in my head)

   TBL: question about how well-defined "fuzzing" is

   TLR: fuzzing ...is giving a non-accurate answer

   <masinter> Privacy and how to accomplish it while retaining
   usability is an area of intense R&D. In the meanwhile, the API
   should allow for current known "best practice" to be implemented and
   deployed, even if there are possible new practices

   TLR: how that is arrived at will vary

   <DanC_> the Doty paper says "best practice" is the opposite of the
   way GEOPRIV works, right masinter ?

   <masinter> "best current practice" emphasais on "current"

   TLR: we didn't feel comfortable suggesting a method of fuzzing

   <DanC_> I don't see how "current" argues for or against the way
   GEOPRIV works

   MW: every answer comes with a piece in the response that suggests
   the response is 95% accurate

   <masinter> if people don't really know how to do fuzzing, it can't
   be "best current practice", even if it might be better practice than
   "sending retention policy"

   MW: if you don't ask for "high accuracy" you might still get
   high-accuracy data

   <DanC_> ah. now I see, masinter

   <Zakim> tlr, you wanted to talk about criteria for web sites

   TLR: geoloc WD comment period has run out
   ... WG is ready to proceed further

   <DanC_> (re 7 July last pub... more than 3 months. boo. hiss.)

   TLR: have the group create a checklist during CR

   <DanC_> (yes, showing that sites meet a checklist makes sense as a
   CR task)

   TLR: and show a list of sites that implement the checklist

   AM: that's not a requirement is it?


     [73] http://dev.w3.org/geo/api/spec-source.html#privacy_for_recipients

   <masinter> are there any GeoPriv implementations?

   DA: checklist is exactly the way we went in MWBP - ie. there is
   precedent for this approach

   <Zakim> jar, you wanted to ask for side by side comparison

   <matt> masinter, do you mean implementations of the work that has
   come out of the Geopriv group at the IETF?

   <masinter> yes, matt

   JR: what I would find helpful is a side-by-side comparison of ietf
   geopriv vs. what is in geoloc

   <matt> masinter, I don't have a solid answer. I believe Cisco
   implements the Geopriv DHCP rfc in their SIP gateways or maybe

   JR: this comparison could then be applied in other circumstances

   TLR: confused about the status of conversations between IETF, CDT
   and Geoloc WG

   <DKA> Can I suggest that, following from jar's suggestion, we focus
   the discussion on what happens after geolocation 1.0?

   AM: geopriv has made a spec. where they have a place for putting
   privacy preference-related information

   <Zakim> masinter, you wanted to remind that interoperability between
   GeoPriv and GeoLocation was also an architectural interoperability
   consideration, e.g., implementation of SIPs?

   MW: geopriv had a number of proposals
   ... first was like the existing geopriv method

   <tlr> process question: are we talking about geolocation 1.0 or 2.0?
   and if 1.0, are we talking about a previously closed issue or about
   a new one?

   MW: a compromise was made to get it down to two bits: transmit to
   3rd parties, and rule on retention

   <DanC_> (hmm... I earlier said "I don't think there's going to be a
   better design in the future" but the WG postponed the issues; i.e.
   they suggest that there may well be better designs in the future)

   LM: there is an IOP consideration here - geopriv is deployed in some
   cases, how should geoloc and DAP interoperate?

   <noah> We have 12 mins -- working toward wrapup or next steps would
   be good.

   LM: really looking at such IOP scenarios will help to determine what
   to do with this issue
   ... on fuzzing: there's best current practice and "future better

   <matt> [[Background on geopriv proposals: the first had a number of
   things in it, including an XML policy blob, there was some
   evolution, but the latest proposed just two attributes:
   retransmission to third parties, and how long location information
   can be stored.]]

   LM: it may be that best current practice is to have some bits in
   your responses that specify your privacy preference
   ... better future practice may be to support privacy via fuzzing (or
   other methods)
   ... but shouldn't remove the possibility to support best current
   practice \

   <matt> [[Just to be clear: the API makes no restrictions on the
   accuracy of the information sent now, and allows for it to be
   completely fictional]]

   DA: best use of our time is to figure out what to do after geoloc

   <tlr> +1 to that

   <masinter> may be some disagreement about what "best current
   practice" is, but "no practice" isn't acceptable

   <DanC_> (that's a good way to put it...)

   <DanC_> (the user agent doesn't want to present the question when
   it's actually the remote end that's asking)

   <DKA> [74]https://wiki.mozilla.org/Drumbeat/Challenges/Privacy_Icons

     [74] https://wiki.mozilla.org/Drumbeat/Challenges/Privacy_Icons

   DA: pushback was about it being disingenuous to present a question
   to the user which couldn't be enforced

   <matt> [[please also note that most implementations are receiving
   location information from a third party, and thus the browser can't
   promise that the information that they receive has not already been

   <DKA> [75]http://www.betavine.net/bvportal/resources/location

     [75] http://www.betavine.net/bvportal/resources/location

   DA: this information (above) would be useful for DAP and next
   version of geoloc

   NM: DAP WG is looking at this issue, Frederick (chair) sent a
   message to us about this
   ... they published a strawman approach, which we responded to

   <DanC_> (has the IETF said whether they're satisfied with the
   geolocation WG's response to their comments?)

   TLR: that group (DAP WG) had f2f last week, and there is now an
   editor's draft of privacy reqs for DAP

   <DanC_> "that group"?

   <jar> [76]http://dev.w3.org/2009/dap/policy-reqs/

     [76] http://dev.w3.org/2009/dap/policy-reqs/

   <DanC_> ah. tx.

   TLR: not always obvious what these requirements mean when related to

   <jar> [77]http://dev.w3.org/2009/dap/privacy-reqs/

     [77] http://dev.w3.org/2009/dap/privacy-reqs/

   MW: my gut feeling is that precise lat long information is one of
   the hardest things to make "privacy sensitive"

   DC: ie. "fuzzing is hard" - this stuff is a research issue

   TBL: there are lots of ways to do it, but some of them aren't
   research topics - they can be done easily
   ... whereas fuzzing civic address data could be actually trickier

   AM: with fuzzing I can request country or town - can (from the
   responder) I say give a fuzzy location?

   MW: API doesn't restrict this - "you can lie"

   TBL: I don't like that we design a system where lying is possible

   TLR: possibility to lie gives the user autonomy

   <matt> [78]http://dev.w3.org/geo/api/spec-source.html#introduction

     [78] http://dev.w3.org/geo/api/spec-source.html#introduction

   TLR: "the API is agnostic to the information source"

   <matt> [[The Geolocation API defines a high-level interface to
   location information associated only with the device hosting the
   implementation, such as latitude and longitude. The API itself is
   agnostic of the underlying location information sources. Common
   sources of location information include Global Positioning System
   (GPS) and location inferred from network signals such as IP address,
   RFID, WiFi and Bluetooth MAC addresses, and GSM/CDMA cell IDs, as
   well as user inp

   <matt> guarantee is given that the API returns the device's actual

   <Zakim> DKA, you wanted to propose a workshop or some other kind of
   way to socialize this issue and help with clarity - in line with my
   previous comments.

   <DanC_> (phtpht. queue bug at 14:57)

   DA: this seems to be an area where we could show leadership in the
   ... would it make sense to convene an industry workshop?

   <DanC_> (that long list of complications would have been nice to
   record; shows depth of DKA's backround. too back it's already leaked
   out of my brain)

   DA: where we could get implementation experience and relevant

   <DanC_> . ACTION DKA: look into next steps on a workshop around
   device privacy etc.

   action dan appelquist to further discussion of a w3c workshop in the
   area of web APIs privacy

   <trackbot> Sorry, amibiguous username (more than one match) - dan

   <trackbot> Try using a different identifier, such as family name or
   username (eg. connolly, dappelqu)

   <DanC_> . ACTION DKA: look into next steps on a workshop around
   device privacy etc.

   <DanC_> . ACTION DKA: look into next steps on a workshop around
   device APIs, privacy etc.

   <DanC_> ACTION: DKA to look into next steps on a workshop around
   device APIs, privacy etc. with tlr [recorded in

     [79] http://www.w3.org/2010/03/24-tagmem-irc

   <trackbot> Created ACTION-408 - Look into next steps on a workshop
   around device APIs, privacy etc. with tlr [on Daniel Appelquist -
   due 2010-03-31].

   DC: WG has essentially postponed this issue - suggests they think a
   better design is coming along
   ... I would suggest no TAG action that's critical to CR

   <DanC_> DC: collecting experience in CR seems like a reasonable next

   NM: thanks Matt & Thomas

   (break) Matt Womer and Thomas Roessler depart

   <jar> [80]http://www.kendallhotel.com/dining-events/dinner-menu/

     [80] http://www.kendallhotel.com/dining-events/dinner-menu/

   NM: propose we switch admin topics with ISSUE-27 agenda items
   ... would like to take up admin issues

Administrative issues

   NM: next f2f meeting?

   <amy> say my name when you want and I'll pay attention

   (discussing scheduling)

   <DanC_> 7-9 Jun in the UK is a proposal; likely regrets from 1

   <DanC_> west coast in June has been moved and 2nded

   <DanC_> 2-4 June... (west coast?)

   2-4 June, west coast USA is also a proposal

   fewer people can reliably make that

   DanC: do a video-conf type meeting?

   TVR: how about a split meeting - those who can make it to west coast
   do so, those to UK do so, we overlap for some timezone-useful period
   of time

   LM: either gather f2f as a whole group, (and/) or schedule more,
   longer telecons

   some consensus for UK, 7-9 June

   <DanC_> with regrets from 1

   <DanC_> and another 2 at risk

   proposal: 7-9 June, London

   RESOLUTION: face-to-face meeting, 7-9 June, London

   NM: TPAC is in Lyon, France
   ... NM: 1st week Nov
   ... do we need to re-arrange the agenda?

   LM: propose to swap ISSUE-57 with ISSUE-54

   <DanC_> . close ACTION-356

HTML 5 Decentralized Extensibility (ISSUE-54)

   <DanC_> action-406?

   <trackbot> ACTION-406 -- Noah Mendelsohn to get the TAG to evaluate
   the decentralized proposals in the HTML WG -- due 2010-03-31 -- OPEN

   <trackbot> [81]http://www.w3.org/2001/tag/group/track/actions/406

     [81] http://www.w3.org/2001/tag/group/track/actions/406

   <DanC_> close ACTION-356

   <trackbot> ACTION-356 Work with Carine Bournez to schedule followup
   meeting on xmlnames followup discussion closed

   close ACTION-356

   <trackbot> ACTION-356 Work with Carine Bournez to schedule followup
   meeting on xmlnames followup discussion closed

   <DanC_> action-357: possibly subsumed by action-406

   <trackbot> ACTION-357 Elaborate the DPD proposal to address comments
   from #xmlnames and tag f2f discussion of 2009-12-10, particularly
   wrt integration with XML specs and wrt motivation notes added

   NM: propose HT does follow-up on 357

   <DanC_> ACTION-357 due next week

   <trackbot> ACTION-357 Elaborate the DPD proposal to address comments
   from #xmlnames and tag f2f discussion of 2009-12-10, particularly
   wrt integration with XML specs and wrt motivation due date now next

   <DanC_> (i.e. sometime in the future)

   close ACTION-374

   <trackbot> ACTION-374 Schedule discussion of broader extensibility
   mechanisms question (including this)
   l closed

     [82] http://lists.w3.org/Archives/Public/www-archive/2010Jan/0043.html

   close ACTION-396

   <trackbot> ACTION-396 Henry to draft emails for NM to send to HTML
   WG chairs and to Liam+MS authors encouraging a change proposal wrt
   distr. extensibility by 23 March closed

   <DanC_> ACTION-113?

   <trackbot> ACTION-113 -- Henry S. Thompson to hT to a) revise
   composition.pdf to take account of suggestions from Tim & Jonathan
   and feedback from email and b) produce a new version of the
   Elaborated Infoset finding, possibly incorporating some of the PDF
   -- due 2010-04-01 -- OPEN

   <trackbot> [83]http://www.w3.org/2001/tag/group/track/actions/113

     [83] http://www.w3.org/2001/tag/group/track/actions/113

   <DanC_> HT: yup, don't delete 113

   NM: move ISSUE-57 to Thursday



     [84] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037.html

   NM: there is a proposal for closing it (see above)

   LM: we have to replace stable refs
   ... staging timeline of HTML, LEIRI is different
   ... create a document containing current content, but mention the
   new document

   XML CORE should work in the following phases:

   1. Develop a draft of what a replacement to [LEIRI] would look like,

   given the current content of IRI-BIS. Coordinate with IRI-WG if any

   changes are needed to IRI-BIS, and continue to track IRI-WG.

   2. Publish a new version of [LEIRI] as an updated NOTE with both the

   current content and the proposed new content.

   <masinter> [85]http://tools.ietf.org/html/draft-ietf-iri-3987bis-00

     [85] http://tools.ietf.org/html/draft-ietf-iri-3987bis-00

   3. When IRI-BIS is approved for standards track in IETF (either at

   "Draft Standard" or restarted at "Proposed Standard" level), remove

   the older content of [LEIRI] and leave the pointer to the new

   IRI-BIS document.

   <masinter> look at

     [86] http://tools.ietf.org/html/draft-ietf-iri-3987bis-00#section-7.1

   HT: is this a matter for liaison between XML Core and IETF?

   <masinter> secton 7.1 talks about LEIRI processing

   LM: yes

   <DanC_> . ACTION HT: run this plan by the XML Core WG

   NM: are you proposing to cut detailed discussion from TAG?

   HT: would like Larry to send his proposal to XML Core WG

   <noah> Please s/this/Larry plan for closing ISSUE 27/

   LM: new document describes a transformation process, rather than
   non-terminal in a BNF grammar

   HT: XML Core is the right place to review this

   <DanC_> ACTION: HT to run Larry's plan for closing IRIEverywhere by
   the XML Core WG [recorded in

     [87] http://www.w3.org/2010/03/24-tagmem-irc

   <trackbot> Created ACTION-409 - Run Larry's plan for closing
   IRIEverywhere by the XML Core WG [on Henry S. Thompson - due

   <masinter> section 1.3 should contain definition: LEIRI (Legacy
   Extended IRI): This term was used in

   <masinter> various XML specifications to refer to strings that,
   although not

   <masinter> valid IRIs, were acceptable input to the processing rules

   <masinter> Section 7.1.

   HTML WG should follow the following phases:

   1. Confirm that a document, even with a normative reference to a

   <scribe> in progress, can enter Candidate Recommendation state, and

   advancement of IRI-BIS to IETF standards track is not a 'blocking'

   issue. (Otherwise the contingency plan in step 3 will need to be


   2. Prepare a version of the HTML specification that references a

   specific version of IRI-BIS, noting that the document is evolving.

   3. When preparing HTML5 for Proposed Recommendation, update the

   reference to IRI-BIS as needed: if the IETF IRI WG succeeds in

   completing its work in time, that can be used as a stable

   specification; otherwise, implement a contingency plan following the

   LEIRI development plan above: create a Working Group Note that

   describes a current reference to IRI-BIS, along with a copy or

   of the WEBADDR specification.

   close ACTION-398

   <trackbot> ACTION-398 Prepare plan for resolving issue-27
   IRIEverywhere for F2F discussion closed

   LM: Is there anywhere else where we need to update these references?

   <DanC_> . ACTION Larry: let the TAG know that the IRIEverywhere plan
   in HTML WG went as planned

   DC: RDFa?

   <DanC_> ACTION: Larry to let the TAG know that the IRIEverywhere
   plan in HTML WG went as planned [recorded in

     [88] http://www.w3.org/2010/03/24-tagmem-irc

   <trackbot> Created ACTION-410 - Let the TAG know that the
   IRIEverywhere plan in HTML WG went as planned [on Larry Masinter -
   due 2010-03-31].

   DC: should we close the issue?

   <DanC_> PROPOSED: whereas the plan
   looks credible, to close IRIEverywhere

     [89] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037.html

   <noah> +1

   NM: risk in closing the issue is that something objectionable
   happens, but expect that someone here notices

   <noah> Note that having no actions means the chair anticipates no
   followup at this time.

   <DanC_> DC: note the risk that the HTML WG might want the IRI
   details nailed before last call... but I guess that risk is pretty

   <DanC_> noah, note we have 2 open actions

   <DanC_> 409 and 410

   <noah> Never mind.

   <DanC_> LMM: note various risks getting IRI stuff thru the IETF, due
   to all sorts of hair around IDNA, low participation, etc.

   LM: there are some risks in the IETF process for this document

   TVR: so, do we feel comfortable enough that this plan will succeed,
   since HTML depends on it?

   LM: transition plan does depend on whether HTML can go finished LC
   with normative ref to an I-D

   <masinter> the risks aren't really IETF risks, they're technical

   <masinter> and they need to be resolved in IETF or HTML, venue is
   better, not worse

   <DanC_> issue-27?

   <trackbot> ISSUE-27 -- Should W3C specifications start promoting
   IRIs? -- OPEN

   <trackbot> [90]http://www.w3.org/2001/tag/group/track/issues/27

     [90] http://www.w3.org/2001/tag/group/track/issues/27

   RESOLUTION: whereas the plan
   looks credible, to close IRIEverywhereClose ISSUE-27 IRIEverywhere

     [91] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037.html

   <DanC_> RESOLVED: whereas the plan
   looks credible, to close IRIEverywhere

     [92] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037.html

   <DanC_> ACTION: Larry take the next step on announcing IRIEverywhere
   recorded in [93]http://www.w3.org/2010/03/24-tagmem-irc]

     [93] http://www.w3.org/2010/03/24-tagmem-irc

   <trackbot> Created ACTION-411 - Take the next step on announcing
   IRIEverywhere [on Larry Masinter - due 2010-03-31].

   LM: should tell the community that we plan to close this issue, but
   note that not all the work required is complete

   close action-383

   <trackbot> ACTION-383 Review DanC's email on speaks_for closed

   <DanC_> close ACTION-383

   <trackbot> ACTION-383 Review DanC's email on speaks_for closed


Summary of Action Items

   [NEW] ACTION: DanC to ask the HTML WG to do produce a WG Note that
   satisfied the document the TAG resolved it wants (sort about
   polyglot documents) [recorded in
   [NEW] ACTION: DanC to track HTML WG ISSUE-27 rel-ownership [recorded
   in [95]http://www.w3.org/2010/03/24-tagmem-irc]
   [NEW] ACTION: DKA to look into next steps on a workshop around
   device APIs, privacy etc. with tlr [recorded in
   [NEW] ACTION: HT to run Larry's plan for closing IRIEverywhere by
   the XML Core WG [recorded in
   [NEW] ACTION: Larry take the next step on announcing IRIEverywhere
   recorded in [98]http://www.w3.org/2010/03/24-tagmem-irc]
   [NEW] ACTION: Larry to let the TAG know that the IRIEverywhere plan
   in HTML WG went as planned [recorded in
   [NEW] ACTION: Noah get the TAG to evaluate the decentralized
   proposals in the HTML WG [recorded in

     [94] http://www.w3.org/2010/03/24-tagmem-irc
     [95] http://www.w3.org/2010/03/24-tagmem-irc
     [96] http://www.w3.org/2010/03/24-tagmem-irc
     [97] http://www.w3.org/2010/03/24-tagmem-irc
     [98] http://www.w3.org/2010/03/24-tagmem-irc
     [99] http://www.w3.org/2010/03/24-tagmem-irc
    [100] http://www.w3.org/2010/03/24-tagmem-irc

   [End of minutes]

    Minutes formatted by David Booth's [101]scribe.perl version 1.135
    ([102]CVS log)
    $Date: 2010/04/05 21:03:43 $

    [101] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
    [102] http://dev.w3.org/cvsweb/2002/scribe/


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

                               - DRAFT -

                     W3C TAG Meeting in Cambridge

25 Mar 2010

   See also: [2]agenda, [3]IRC log

      [2] http://www.w3.org/2001/tag/2010/03/24-agenda.html
      [3] http://www.w3.org/2010/03/25-tagmem-irc


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

          Noah Mendelsohn

          Daniel Appelquist (morning), Tim Berners-Lee (afternoon)


     * [4]Topics
         1. [5]Agenda planning
         2. [6]Issue-31
         3. [7]sniffing
         4. [8]ISSUE-57: HTTP Semantics & the use of HTTP Redirection
         5. [9]ISSUE-50 (URNsAndRegistries-50): Persistent naming
     * [10]Summary of Action Items

   <DanC_> (who else scribed yesterday? shall we rock-scissors-paper
   for the editing?)

   <DKA> Scribe: Dan A

   <DKA> ScribeNick: DKA

Agenda planning

   Noah: We could find half-hour to an hour for discussion of mobile
   ... we could also discuss "what is the form of the work we do" we've
   got into a mode of doing things in the small, e.g. finding issues in
   other specs.
   ... working with other working groups. We have also discussed doing
   writing, other things. Should we have a session to discuss such

   [agreement to go on with agenda as planned]


   <trackbot> ISSUE-31 -- Should metadata (e.g., versioning
   information) beencoded in URIs? -- OPEN

   <trackbot> [11]http://www.w3.org/2001/tag/group/track/issues/31

     [11] http://www.w3.org/2001/tag/group/track/issues/31


   Noah: a lot of work done on this is in action-278 now closed.


   <trackbot> ACTION-394 -- John Kemp to compare Noah and Tyler's
   proposals on this subject -- due 2010-03-17 -- OPEN

   <trackbot> [12]http://www.w3.org/2001/tag/group/track/actions/394

     [12] http://www.w3.org/2001/tag/group/track/actions/394

   <DanC_> (let's not use bare issue numbers; always put a technical
   keyword with them. issue-31 is metadataInURI-31)

   <DanC_> (so please edit the TOC)

   <noah> [13]http://www.w3.org/2001/tag/2010/02/action-278-notes.txt

     [13] http://www.w3.org/2001/tag/2010/02/action-278-notes.txt

   John: I wrote an email which I haven't sent on keeping secrets
   including in URIs and I have taken Jonathan Rees's material.

   <johnk> [14]http://www.w3.org/2001/tag/2010/02/action-278-notes.html

     [14] http://www.w3.org/2001/tag/2010/02/action-278-notes.html

   Noah: Given that we're here f2f, could we frame this for discussion
   ... Is there a way to take advantage of f2f to turn the corner?

   <DanC_> (ah... the topic in the agenda has both "secrets in URIs"
   and "metadataInURI": ISSUE-31 (metadatainURI-31): Secrets in URIs )

   Noah: We also have action-341 which is for me stay in touch with
   Thomas about security.

   <DanC_> (er... can he mail this to www-archive or something?)

   John: [goes through material to be sent to working group]

   <masinter> "Secrets and Lies: Digital Security in a Networked World"

   <DanC_> [15]http://www.schneier.com/book-sandl.html

     [15] http://www.schneier.com/book-sandl.html

   <masinter> recommended reading


     [16] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0115.html

   [discussion on "are cookies secret?"]

   Jonathan: Adam Barth is doing some work on cookie security.

   Larry: There is an IETF working group working on "how cookies work."

   <DanC_> the note says "A cookie is a secret", which suggests "all
   cookies are secrets"; I asked and John clarified that he only means
   to say that at least _some_ cookies are secrets

   <masinter> [17]http://tools.ietf.org/wg/httpstate/charters

     [17] http://tools.ietf.org/wg/httpstate/charters

   <masinter> The HTTP State Management Mechanism (aka Cookies) was

   <masinter> created by Netscape Communications in their informal
   Netscape cookie

   <masinter> specification ("cookie_spec.html"), from which formal

   <masinter> RFC 2109 and RFC 2965 evolved. The formal specifications,

   <masinter> were never fully implemented in practice; RFC 2109, in
   addition to

   <masinter> cookie_spec.html, more closely resemble real-world

   <masinter> than RFC 2965, even though RFC 2965 officially obsoletes
   the former.

   <masinter> Compounding the problem are undocumented features (such
   as HTTPOnly),

   <masinter> and varying behaviors among real-world implementations.

   Tim: In my model of how the web works, a UA [is one with] the user.
   So a user-agent should not keep secrets from the user.

   Raman: There are redirects happening under the covers which are
   confusing to the user - only if you look at the address bar do you
   realize that you are somewhere else.

   John: Very often the user doesn't know that: site a redirects the
   browser to site b.
   ... So site a is making the cookie go to site b without [getting the
   user's permission]

   <masinter> i don't understand relationship of cookies to

     [18] http://dev.w3.org/html5/webstorage/

   <DanC_> I think it's confusing/backwards to say "my cookie" where
   "me" is the user... the cookie is made up by the origin

   <DanC_> (photo, please? Noah?)

   John: The UA already has a site B cookie. Now when the user goes to
   Site A but Site a redirects to Site B. Now the user goes back to
   Site B but the user doesn't know that and has not instructed the UA
   to do this.
   ... This is called ambient authority or "the confused deputy

   <DanC_> (seems to me this A/B pattern is used in both positive and
   negative ways)

   Raman: interesting aspect: the browser can write to a page but can't
   read it.
   ... The Json-P hack: you request an html page from someone; you make
   a subsequent request, they send you back a call-back function that
   you can run on the page; google suggest API works this way.

   John: That's a hack around the same-origin policy.

   <masinter> [19]http://visitmix.com/opinions/json-p-an-elegant-hack

     [19] http://visitmix.com/opinions/json-p-an-elegant-hack

   Raman: Yes.

   Henry: How does that hack same-origin?

   Raman: In your page, you want to use google auto-suggest in the
   search box. Auto-suggest needs to make a json call to google.

   John: [back to "secrets" email]

   <raman> jsonp: [20]http://en.wikipedia.org/wiki/JSON#jsonp

     [20] http://en.wikipedia.org/wiki/JSON#jsonp

   <DanC_> (no, I don't see anything in json-p-an-elegant-hack about
   getting around the same-origin restriction, masinter )

   <raman> I didn't say jsonp was inelegant --- I said that design
   pattern was introduced after some of the more obvious
   same/cross-origin vulnerabilities were closed off

   Noah: At some level, the whole reason we're talking about passwords
   is that we are making an assumption that they are unguessable. So -
   possession of the password in some way does mean "its' you."

   Tim: There are different protocols - e.g. I am given a password from
   a bank and told "do not give it away" ; another situation is: this
   is your password for box.net - and you can give it to anyone you
   want to have access to box.net.
   ... People get confused. They have what seems to be a similar
   relationship with their bank's password as with facebook but [these
   are different things.]

   <DanC_> (I hear a pattern language forming... is it BankPIN? or is
   there a more general name for that pattern? and DropBox sounds like
   the Capability pattern)

   John: But in the bank case - what happens if the password given by
   the bank is a URI and contains a pseudo-random number?

   Noah: John - you have a sentence: "an http URI can be a secret,
   shared between a UA and one or more websites"
   ... for me, saying this is only slightly more appealing than "a get
   request can confirm your subscription to a magazine."
   ... I mostly don't want to take responsibility for keeping URIs
   secret. I'd prefer the phrase: there is a controversy - [whether or
   not this is true].

   <DanC_> I'm not bothered by "An HTTP URI can be a secret"

   <DanC_> perhaps that's because of my position on the issue

   Jonathan: There are 2 issues - one is that one [Noah], but another
   is CSRF attacks. Take the security you already have and add another
   level to it to prevent these veunerabilities.

   Tim: So - part of this that gets overlooked - the way the UI is
   built. The normal protocol for a URI is - you are expected to
   bookmark it, etc...

   DanC: Tyler has said that software shouldn't do that without your
   express permission.

   Tim: you should be able to drag these URIs and drop them into
   something else...

   Noah: If javascript goes in and finds links on the page [without
   your express permission] should that be prevented?
   ... You stated as a fact something with some controversy.
   ... It's not clear to me that "http URIs is a secret" is a desirable
   design point for the Web.
   ... we have a finding - the metadata in URI finding - which says
   "don't put secrets in URIs".

   Tim: Let's talk about design patterns. I think it's fine for Noah to
   talk about a design pattern to that does involve secrets in URIs and
   for [John] to define a pattern that does include that and then for
   us [to discuss.]

   Noah: The question is- should we change the finding?

   Tim: I suggest we should change the finding to say that there are
   two ways of working.

   Noah: I'm less convinced.
   ... We could change it to "do this at your own risk"

   Tim: I note that banks -always- put random junk in my URIs. Means I
   can't bookmark any page from my bank's website. Because they are
   using URIs as a secret that will not work without my cookies, etc...

   Larry: Could we add a footnote to the finding noting that though we
   support the finding, there may be some alternatives.

   <DanC_> nope; I don't think the capability pattern should be
   relegated to a footnote. I think it's a regular old 1st class

   Tim: as a user I would love to be able to tell the difference when
   I'm dragging a dropping a secret URI and when I'm not.

   <masinter> mainly, i want to get to the point where we publish this
   analysis -- perhaps in a TAG blog post?

   Tim: [accounts experience using box.net]

   Noah: The google docs case is a "bearer token" thing. My concern is
   that sometimes user agent is not a browser. Taken to its conclusion
   we've got to look at all the email user agents.

   Larry: In Adobe buzzword you can check a box to allow people who
   know the URI.

   <DanC_> masinter, each of us has his own analysis (maybe with some
   overlap). are you aiming for a blog item with just one analysis? I
   think maybe 3 or 4 posts would make sense.

   <DanC_> I also think a pattern language wiki might work

   <masinter> a blog which identifies the different positions, what we
   agree on and what we don't.

   <DanC_> that's one analysis

   <DanC_> hard work

   John: Already we have a case where "unguessable" URIs are used
   today. e.g. Craig's list where you make a post up and you get a URL
   back by email to allow you to edit your post and there is no other
   access control.

   Noah: That is my concern.

   <DanC_> I wonder if we have write access to

     [21] http://www.w3.org/Security/wiki/Main_Page

   <masinter> i think it's possible to summarize the discussion in a
   way that we could all agree with the summary. listing pros & cons

   John: I agree with that concern but I don't think *we* need to solve
   ... Unguessable URIs also form part of a defence against
   clickjacking and XSRF attacks...

   <masinter> DanC, maybe editing a wiki or ... a Google Docs document?

   Noah: Any particular URI may or may not be secret but ... "the bad
   guy makes up URIs not used before" is different from "reusing URIs
   found in the address bar".

   John: We explicitly say [in the finding
   ... ] don't put secrets in URIs. Because of this issue we need to
   say something different than that.
   ... What is the downside? Potential 404 because URIs do change. E.g.
   craigslist gives me a URI to edit my post on craig's list which is
   only valid for 30 days unless renewed.

   Noah: It could return a message saying the resource is locket.

   John: Is it ok to recommend putting the unguessable portion in the
   fragment id of the url?
   ... On the client, the client knows that and adds it to the query
   parameter making a second URI...
   ... [e.g. using javascript]
   ... so - Jonathan's note has put the history in some notes - could
   be a good place to go.

   <johnk> [22]http://www.w3.org/2001/tag/2010/02/action-278-notes.html

     [22] http://www.w3.org/2001/tag/2010/02/action-278-notes.html

   [going through Jonathan's notes]

   John: Tyler's best practice statement is probably good (adding the
   word "guessable") is good but needs more supporting text.

   Noah: Should we look at all the practices that are useful?

   [looking at Tyler's original email]

   <DanC_> (tim, I'm experimenting with the pattern approach at
   [23]http://www.w3.org/Security/wiki/Main_Page#Ongoing_issues )

     [23] http://www.w3.org/Security/wiki/Main_Page#Ongoing_issues


     [24] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0081.html

   Noah: What we said was "don't put things you need to keep secret" in
   a URI.

   <masinter> "kept" implies "kept for a long time". maybe finding just
   needs 'clarification'

   Jonathan: There's [one kind of] confidential that is like a random
   number with a timeout and there's a case where you can learn
   something by looking at the URI. E.g. a social security number or a
   birthday you're getting information that might be applied in a
   different setting.

   Noah: Which was the justification for the original best practice.
   Guessability to me is confusing.

   Larry: finding says "to be kept confidential" by kept we mean kept
   over a certain period of time. If you have information that only
   needs to be kept confidential for 10ns it's OK to put it in a URI.
   We need to clarify that all of the exceptional use cases are where
   "kept confidential" is time limited.
   ... [finer points of naval safe-cracking]

   <DanC_> (navy safe example is an interesting pattern...)

   Larry: What we're trying to do is clarify what "kept confidential"
   means. That it means for a reasonably long period of time.

   <masinter> was told that a safe is measured by "how long does it
   take to break in" where you have both a minimum and a maximum

   John: My actual bank account account number which I use off-line vs.
   the hash of my bank account number which I use online and gives me
   access in one specific setting.

   Noah: I thought the TAG said: access control is orthogonal to

   DanC: Yes, and we were wrong.

   Noah: I think we were right.
   ... What I like [architecturally] is that URIs are identifiers...

   John: What I hear is that we can roughly agree on something that
   looks like Tyler's first best practice - the TAG can agree roughly
   on this with some kind of supporting text.

   Larry: I think "guessable" confuses the issue because of the time

   <DanC_> (I'm not interested in the finding genre, nor the good
   practice note mechanism. I'm interested in the pattern genre)

   Larry: There are other access control methods. I think we need to
   re-interpret the finding as written - [going back to the meaning of
   "kept" in "kept confidential]

   <masinter> there are some usage patterns where metadata only needs
   to be kept confidential for a very short period of time, or where
   disclosure of the information (i.e., not keeping it confidential)
   doesn't have serious consequences

   Noah: URIs are used by many systems. Nothing we say in the
   architecture can restrict where URIs go. We could say: In certain
   practical situations URIs are distributed through systems that are
   sufficiently [secure] ....

   <masinter> where the time-period requirement for confidentiality is
   shorter than any reasonable period of accidential disclosure

   <noah> I agree with Larry, but I'm unconvinced that focusing on time
   unscrambles the particular problem we have here. In principle, I can
   imagine an attack that finds a URI in my email system within
   milliseconds and empties my bank account.

   Larry: You get something confidential - it's valid only for a short
   time - the possiblity for information leakage is low.

   <johnk> to be honest, I can see writing a whole finding on "secrets
   in URIs"

   Larry: The second type is where the consequence of the information
   getting out is not...

   Jonathan: The finding could be read to [say] not do the CSRF

   <Zakim> DKA, you wanted to note that "kept" is not only bound by
   time but also by the kind of information (which is somewhat
   subjective and social).

   <DanC_> (kind of information? oh... how sensitive it is.)

   Raman: There will be multiple readings to anything we write. Just
   add an appendix saying "we were asked this question and ..."

   <masinter> well, that's how "confidential" it is.... something isn't
   really "confidential" because there is no serious consequence to its

   <DanC_> interesting idea, raman

   <DanC_> i.e. just answering clarification questions

   [discussion on proposals from

     [25] http://www.w3.org/2001/tag/2010/02/action-278-notes.html

   Tim: I prefer to have a document with two sections - two design

   <masinter> i don't like Noah's formulation because "risk of
   disclosure" is time varying

   <DanC_> "Q: Does the 'SHOULD not put confidential...' good practice
   note say that [the CSRF protection pattern involving unguessable
   URIs] is bad practice?'

   Tim: There are 3 types of URI - one has no security; one is a token
   that will grant access; one is a URI with crypto-gunk in it to add
   extra security not designed to be passed on as a token;

   Noah: There's a 4th: a URI that is meant for identity where someone
   has stuck [e.g.] your social-security number in it. We have a best
   practice note that was intended to say "don't do this."... Should we
   get rid of this?

   Tim: No. That's an anti-pattern. It's a "bad practice" note. It's
   not a design pattern.

   <DanC_> "A: the unguessable URI pattern, in combination with other
   mechanisms, is a good CSRF attack, but it involves creating aliases;
   see [cite] for implications of aliases'

   <johnk> does "confidential" include "unguessable"?

   Larry: I think there are [more] ways of designing...

   <masinter> "guessable" always comes with "over how much time and

   Tim: If you're telling pattern one then you should tell pattern two
   and three as well.

   John: I like Tim's idea of documenting two design patterns and not
   say anything that favors one pattern over another...

   Tim: we could list the pros and cons.

   <Zakim> DanC_, you wanted to offer to take ACTION DanC: try the
   clarification question approach to metadata-in-uris vs CSRF

   DanC: Raman asked about a clarification or blog item. I'm willing to
   give that a try. I'm trying to do the pattern approach as well...

   Noah: You could first put it on www-tag for discussion.

   Larry: [supports Dan's action]

   <masinter> i like blogging with public comment on the blog before
   updating the finding

   John: One approach is to do a lot more writing. Another approach is
   to write something in the metadata in URIs finding that says
   something based on Noah's and Tyler's proposals.

   <masinter> Should "IRIEverywhere" mean that we update the Use of
   Metadata in URIs to address metadata in IRIs?

   Tim: The concern about a good practice note is that people quote it
   out of context.

   John: We could say not very much more at all....

   Tim: I dislike [that] approach.

   <masinter> i think people need to understand "kept" and
   "confidential" and we should hyperlink those

   Noah: I welcome DanC doing anything he wants. I wonder if we can't
   make a short list of points. e.g. 1 document the antipatern; 2 good
   reasons why people want to do [x,y,z]; ....


   <johnk> ACTION-394?

   <trackbot> ACTION-394 -- John Kemp to compare Noah and Tyler's
   proposals on this subject -- due 2010-03-17 -- OPEN

   <trackbot> [26]http://www.w3.org/2001/tag/group/track/actions/394

     [26] http://www.w3.org/2001/tag/group/track/actions/394

   <DanC_> .

     [27] http://www.w3.org/Security/wiki/Main_Page#Ongoing_issues

   <Zakim> DanC_, you wanted to noodle on patterns a la

     [28] http://www.w3.org/Security/wiki/Main_Page#Ongoing_issues

   DanC: Do you know their names? Pattern languages are really
   powerful. You start talking about the names and discover a lot
   through that.

   <masinter> FWIW, I don't like "design patterns" very much, if people
   take them too seriously as categories rather than just examples and

   [discussion on patterns]

   <masinter> "It's better if access control is orthogonal to
   identification but it often isn't"

   <masinter> secrets in URIs design pattern started with

     [29] http://www.guardians.net/hawass/articles/secret_doors_inside_the_great_pyramid.htm

   Jonathan: Public URIs; URIs that authorize; URIs that protect

   Noah: Anti-pattern: URIs that disclose secrets

   DanC: You could call it "social security number in the URI"

   <Zakim> noah, you wanted to say we need a story on who needs to
   restrict copying of URIs

   Noah: I think you've well covered this - I'd like to see some
   patterns and antipatterns on what are the responsibilities of
   software and people that handle URIs?

   <DanC_> (anti-pattern for giving out a URI without user's consent...
   i.e. another mechanism like referrer)

   <DanC_> action-394?

   <trackbot> ACTION-394 -- John Kemp to compare Noah and Tyler's
   proposals on this subject -- due 2010-03-17 -- OPEN

   <trackbot> [30]http://www.w3.org/2001/tag/group/track/actions/394

     [30] http://www.w3.org/2001/tag/group/track/actions/394

   John: ACTION-394 was for me to compare Tyler's and Noah's proposal.
   Have I completed that action/

   <johnk> close action-394

   <trackbot> ACTION-394 Compare Noah and Tyler's proposals on this
   subject closed

   <DanC_> . ACTION DanC: try the clarification question, blog item, or
   wiki approach to metadata-in-uris vs CSRF

   [general agreement]

   <Zakim> johnk, you wanted to ask about disposition on ACTION-394

   <DanC_> ACTION: DanC to try the clarification question, blog item,
   or wiki approach to metadata-in-uris vs CSRF [recorded in

     [31] http://www.w3.org/2010/03/25-tagmem-irc

   <trackbot> Created ACTION-412 - Try the clarification question, blog
   item, or wiki approach to metadata-in-uris vs CSRF [on Dan Connolly
   - due 2010-04-01].

   <DanC_> action-394: see action-412 for follow-up

   <trackbot> ACTION-394 Compare Noah and Tyler's proposals on this
   subject notes added

   <DanC_> action-412: see action-394 for background

   <trackbot> ACTION-412 Try the clarification question, blog item, or
   wiki approach to metadata-in-uris vs CSRF notes added

   [break till 10:50]




   <trackbot> ISSUE-24 -- Can a specification include rules for
   overriding HTTPcontent type parameters? -- OPEN

   <trackbot> [32]http://www.w3.org/2001/tag/group/track/issues/24

     [32] http://www.w3.org/2001/tag/group/track/issues/24


   <trackbot> ACTION-370 -- Henry S. Thompson to hST to send a
   revised-as-amended version of
   [33]http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html to
   the HTTP bis list on behalf of the TAG -- due 2010-03-09 -- OPEN

     [33] http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html

   <trackbot> [34]http://www.w3.org/2001/tag/group/track/actions/370

     [34] http://www.w3.org/2001/tag/group/track/actions/370

   Henry: Yes, I finally did that a few days ago.
   ... We should look at response...

   John: Would it help to provide some background?

   <DanC_> (how is this background distinct from ACTION-399? maybe it's


     [35] http://www.w3.org/2001/tag/2009/09/24-minutes.html#item03

   John: Background: we had a meeting here in Sept last year where we
   had a call regarding sniffing - in HTTP BIS they were loosening the
   rules around sniffing. We decided that if they were to do something
   like that then we should update "authoritative metadata" and
   "self-describing web" findings to acknowledge the reality of

   <Zakim> DanC_, you wanted to offer to take ACTION DanC: try the
   clarification question, blog item, or wiki approach to
   metadata-in-uris vs CSRF

   John: basic issue is that in general, as discussed in [findings] and
   the http spec, unless content type http header is blank (missing)
   you cannot look into the data and guess the content type.

   <jar> Fresh email from Yves Lafon of httpbis, 14 hours ago:

     [36] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0114.html

   John: Adam Barth wrote a draft of an algorithm for secure sniffing.
   specified in an ietf draft which has no owner or standing. We
   decided "the draft looks reasonable - modulo certain remarks about
   whether it was good enough - let's update the findings to say 'if
   you're going to sniff do it this way'"
   ... I wrote some material. Larry wrote some comments on the Barth
   sniffing draft.

   Larry: The main thrust of my comments were not addressed.
   ... The future of the draft is uncertain.
   ... there's a discussion of how to move it forward - the "venue" has
   not been decided.

   Noah: One more clarification: if we go back to TPAC in 2008 there
   were a whole bunch of discussions with HTML about refactoring spec.
   If there is some hope that this finds a home in IETF would HTML
   draft would HTML reference it?

   Larry: There's a question about the change proposal... ISSUE-104 in
   the HTML working group.

   <masinter> [37]http://www.w3.org/html/wg/tracker/issues/104

     [37] http://www.w3.org/html/wg/tracker/issues/104

   <masinter> HTML working group issue on whether sniffing is optional
   or mandatory

   <DanC_> (fyi, I'm telling tracker about the status of actions; see
   [38]http://www.w3.org/2001/tag/group/track/agenda )

     [38] http://www.w3.org/2001/tag/group/track/agenda

   Noah: We have a number of actions.

   <DanC_> (repeat? pointer?)

   Larry: Request for assistance for reviewing Barth draft on sniffing
   (vers. 4) and discussing - [to help formulate response.]

   <Zakim> johnk, you wanted to offer help for Larry _only_ after we
   describe the general thrust of what we want to do here

   <masinter> I don't think the TAG should have a reference to a draft
   that we haven't reviewed

   John: I've done the work n my action but now in the intervening
   period our position has changed... If we're going to do something it
   has to do something regarding our findings (self describing web and
   authoritative metadata).
   ... I'd be inclined to [not change] the authoritative metadata

   <DanC_> (larry, I can't find your review comments on the sniffing
   draft from [39]http://www.w3.org/2001/tag/group/track/actions/386 ;

     [39] http://www.w3.org/2001/tag/group/track/actions/386


     [40] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01250.html

   Henry: Continuing on - we turned our attention in December to the
   section on sniffing and the concept of sniffing in http bis draft.
   Doing what they proposed to do - which was to say nothing about
   sniffing - in http bis was not acceptable. Attention needed to be
   drawn to the potential downside - in the http bis spec. With the
   group's help, I crafted an email messages which was sent in the
   beginning of January.

   <DanC_> (ah; the action says to cc www-tag, but looks like you
   didn't larry ;-)

   Henry: Some positive response to it. Mark N. declined to act.

   <DanC_> action-386: comments 20 Jan on draft 3

     [41] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01250.html

   <trackbot> ACTION-386 Review draft-barth-sniff-4 and send comments,
   cc TAG notes added

   Jonathan: I've pasted in the URL of their latest offer.


     [42] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0114.html

   Jonathan: this is Yves's latest offer.

   <noah> Discussing:

     [43] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0114.html

   <masinter> action-386?

   <trackbot> ACTION-386 -- Larry Masinter to review
   draft-barth-sniff-4 and send comments, cc TAG -- due 2010-04-08 --

   <trackbot> [44]http://www.w3.org/2001/tag/group/track/actions/386

     [44] http://www.w3.org/2001/tag/group/track/actions/386

   Henry: Can we compare the two?

   <noah> I suggest "identify" ==> "describe"

   <noah> or

   <noah> I suggest "identify" ==> "specify the type of"

   Henry: He's damaged it.

   <masinter> I think the "right" thing to do would be to fix up
   barth-mime-sniff so that it can go onto IETF standards track, and
   that HTTPBIS could make normative reference to that. Wordsmithing
   things that make reference (or implied reference) to the document
   without actually getting the document right... is wrong.

   Larry: I think the right thing to do is to get the Barth document so
   that we like it. So it says when to sniff and when not to and is the
   authority on sniffing. And then get HTTP BIS to point to it.

   John: Right. [Agreement]

   Noah: we should defer discussions of changing our own findings until
   after we get the Barth draft right.

   DanC: Barth is documenting current practice and I think that's

   John: I think current practice is broken too.

   <Zakim> DanC_, you wanted to say that "not correctly" is critically
   wrong for me

   <Zakim> noah, you wanted to suggest changing identify

   DanC: both drafts say "however currently deployed servers send an
   [incorrect] content type" but server is correct by definition so
   that's not correct.

   Noah: I have a problem with the word "identify".
   ... Purpose of the header is not to identify the content - it is to
   identify the type...

   <DanC_> +1 "identify the type"

   <Zakim> masinter, you wanted to note that it is possible to write an
   alternative proposal if we can't convince Barth

   Larry: Procedurally - it isn't necessary to convince Adam Barth. We
   could also propose an alternative draft. One way of fixing the Barth
   draft is to create a derivative work.

   <Zakim> johnk, you wanted to agree with DanC, but...

   <DanC_> ht, do you remember when we came up what you sent? I'm
   pretty sure I suggested other words in that meeting

   John: I like "authoritative metadata" - it accurately describes the
   situation and people should not sniff unless the content type is
   empty. But some servers are misconfigured. Is there anything we can
   do to fix current practice - so that servers send the correct
   metadata and correctly send empty content type if it doesn't know.

   <Zakim> DanC_, you wanted to say we could not progress on getting
   less sniffing; e.g. apache changes

   <DanC_> +1 note the change to the apache default in the
   authoritative metadata finding (and/or a blog finding)

   John: One thing we could do is to issue some steps to implement the
   authoritative metadata findings. Writing code or writing a blog.

   DanC: Yes. Do that.

   <Zakim> noah, you wanted to remind of ISP use case

   <DanC_> (today, I'm in the mood to "chip at the mountain". yes, I go
   back and forth. re decade/year, the future is longer than the past,
   by just about any measure.)

   Noah: I'm sympathetic. I'm in favor if we can find practical things
   to do. But the decay curve on bad practice looks more like a decade
   than a year.
   ... We still have some work to do on TAG findings, RFCs, etc... need
   to be fixed...

   <Zakim> ht, you wanted to try to focus on HTTP-bis

   <johnk> totally agree with Henry

   Henry: There are two different things on the table. We decided
   (correctly) that having HTTP BIS published in its current form is
   not acceptable. I don't want to make fixing that hostage to fixing
   the Barth paper. Fixing HTTP BIS should not be dependent on Barth.
   ... Until I know whether this [message from Yves] is from the HTTP
   working group, not sure how to proceed. I would like to [wordsmith]
   our recommendation.
   ... I'm happy to take an action to draft a response to Yves.

   <masinter> I think Henry is rejecting my proposal?

   Larry: I don't think patching http bis will be effective.
   ... I don't think that it is helpful.

   <Zakim> masinter, you wanted to argue once more for working on
   alternate formulation of mime-sniff and publishing in IETF

   <masinter> or likely to be successful

   Tim: We have this authoritative metadata finding. This the TAG's
   best work on this topic. Suggest a way out of this would be to send
   a competitive internet draft [to Barth] which is exactly our
   authoritative metadata finding.

   <Zakim> timbl, you wanted to suggest we take any good bits from
   mine-sniff a d put it in out in our auth metadata finding

   Larry: The sniffing draft that I would like to see puts a maximum
   bound on sniffing.
   ... and limit the cases on where that is recommended.
   ... the barth draft has done some good work on "where sniffing
   appears to be necessary." I would like to correct the draft to make
   each instance of sniffing "opt in" only when you are confident of
   overriding the content type that you are given.

   John: That may end up weakening authoritative metadata.

   <timbl> I still find the design pattern language works

   DanC: I don't think we should put effort into that. I'd rather say
   "don't sniff - and here is all the ways that things are getting
   ... As long as there is one test case - images served as text/plain
   treated as images - as long as there is one such case in the barth
   draft then it's [incorrect.]

   <Zakim> noah, you wanted to talk about browsers vs. Web in general

   <DanC_> s/[incorrect.]/not something I want to work on/

   Noah: Larry said "the barth draft said - do all this stuff" - the
   barth draft risks trying to serve two masters - the people in the
   future who are writing servers, etc and to be reference by the HTML5
   ... For the specific purpose of HTML5 user agents, I think they've
   done it the right way: specifying exactly when to use sniffing.

   <DanC_> (I the odds that implementations will converge on the
   HTML5/barth spec are dubious. implementations might get more strict
   about sniffing in the name of security, or they might get worse in
   response to some huge deployment of crappy content/servers)

   <noah> s/who are writing servers/who are writing clients/

   Tim: is there any possibility in this new world at tilting at
   windmills. - We've got the browser to reject bad stuff - I've also
   suggested that browsers should have a way of telling you how your
   website could be better - built in validators.
   ... They might say: "This website is broken - should I tell you
   about this again?"

   <Zakim> johnk, you wanted to ask about ACTION-308

   <johnk> ACTION-308?

   <trackbot> ACTION-308 -- John Kemp to propose updates to
   Authoritative Metadata and Self-Describing Web to acknowledge the
   reality of sniffing -- due 2010-01-14 -- CLOSED

   <trackbot> [45]http://www.w3.org/2001/tag/group/track/actions/308

     [45] http://www.w3.org/2001/tag/group/track/actions/308

   <DanC_> +1 do a lazyweb request for the "show me errors about _my_
   site" deely

   <masinter> whitelisting, show error only on first view, thinks that
   big-switch opt-in doesn't actually make sense

   John: Asking about proposing updates to "authoritative metadata" - I
   proposed the very minimum updates, pointing to the Barth draft. Do
   we still want to do anything about this in the finding?

   Noah: Let's put those questions aside - help the community - I
   assume we move discussions away from how to tweak the findings in
   the short term.

   Larry: I would be happy to the update to the metadata finding if I
   were happy with the Barth draft.


   <trackbot> ACTION-370 -- Henry S. Thompson to hST to send a
   revised-as-amended version of
   [46]http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html to
   the HTTP bis list on behalf of the TAG -- due 2010-03-09 -- OPEN

     [46] http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html

   <trackbot> [47]http://www.w3.org/2001/tag/group/track/actions/370

     [47] http://www.w3.org/2001/tag/group/track/actions/370

   Henry: I will draft a response - leave it under ACTION-370.

   <DanC_> ACTION-370 due +2 weeks

   <trackbot> ACTION-370 HST to send a revised-as-amended version of
   [48]http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html to
   the HTTP bis list on behalf of the TAG due date now +2 weeks

     [48] http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html


   <trackbot> ACTION-308 -- John Kemp to propose updates to
   Authoritative Metadata and Self-Describing Web to acknowledge the
   reality of sniffing -- due 2010-01-14 -- CLOSED

   <trackbot> [49]http://www.w3.org/2001/tag/group/track/actions/308

     [49] http://www.w3.org/2001/tag/group/track/actions/308


   <trackbot> ACTION-376 -- Daniel Appelquist to send to www-tag a
   pointer to and brief summary of Mobile Web Best Practices working
   group's "Guidelines for Web Content Transformation Proxies" and its
   implications for content sniffing :
   [50]http://www.w3.org/TR/ct-guidelines/ -- due 2010-03-17 -- OPEN

     [50] http://www.w3.org/TR/ct-guidelines/

   <trackbot> [51]http://www.w3.org/2001/tag/group/track/actions/376

     [51] http://www.w3.org/2001/tag/group/track/actions/376

   DanA: I sent a note.It's only orthogonally related to sniffing.

   <masinter> there was an IETF working group OPES on middleware

   <DanC_> DanA: e.g. there are proxies in mobile networks that take
   pages designed for PC screens...

   <masinter> [52]https://datatracker.ietf.org/doc/rfc4236/

     [52] https://datatracker.ietf.org/doc/rfc4236/

   <DanC_> ... and optimizing them, perhaps even splitting into
   multiple pages...

   <Zakim> noah, you wanted to ask again whether they sniff

   <DanC_> ... so they look into the content to see how it'll render...
   and they sometimes re-write the user agent header in order to get
   more high-fidelity versions of the page

   <Zakim> masinter, you wanted to talk about IETF OPES working group
   and point at all of the RFCs in the area

   <DanC_> NM: I see that " Content Tasting " is orthogonal to
   sniffing, but...

   <DanC_> ... I expect that in practice, such gateways do sniff

   <DanC_> [missed some...]

   <DanC_> NM: how about something like "based on a quick look, we
   don't see any sniffing concerns in " Content Tasting ",

   <DanC_> ... the mobile web BP WG should familiarize itself with
   [related work]"

   <DanC_> DanC: I'm inclined to decline "I'm also requesting general
   feedback on this document from the TAG." and ask for a more specific

   <DanC_> LMM: there's been a lot of work in this middeware/OPES area;
   their work should know about it

   <DanC_> DKA: in fact the document does cite the OPES spec

   <DanC_> break 'till lunch until 1pm


     [53] http://www.w3.org/TR/2010/WD-ct-guidelines-20100211/#sec-iab-considerations

   <noah> Yeah, what I said was, maybe we should encourage them to
   consider the sniffing that transform proxies do, track http-bis,
   Barth draft, TAG findings, etc., and when things settle, reference
   the pertinent stuff. They should give explicit guidance on sniffing
   (my personal opinion)


   <masinter> [54]https://datatracker.ietf.org/doc/rfc4236/

     [54] https://datatracker.ietf.org/doc/rfc4236/

   <johnk> 10.2.4 203 Non-Authoritative Information

   <johnk> The returned metainformation in the entity-header is not the

   <johnk> definitive set as available from the origin server, but is

   <johnk> from a local or a third-party copy. The set presented MAY be
   a subset

   <johnk> or superset of the original version. For example, including

   <johnk> annotation information about the resource might result in a

   <johnk> of the metainformation known by the origin server. Use of

   <johnk> response code is not required and is only appropriate when

   <johnk> response would otherwise be 200 (OK).

   <jar> [For projection:]

     [55] http://www.w3.org/2001/tag/2010/03/metadata-notes.txt

   <timbl> scribenick: Timbl

ISSUE-57: HTTP Semantics & the use of HTTP Redirection

   JAR Presents [56]metadata-notes.txt

     [56] http://www.w3.org/2001/tag/2010/03/metadata-notes.txt

   <DanC_> (does HTTP DELETE delete resources? I'm not so sure; I think
   it might just delete bindings between URIs and resources or

   jar: The HTTP spec talks about things like "resides at" and other
   things I don't deal with here.

   This note, like Roy's writings, takes the view that the HTTP
   protocol expresses something about [resources].

   There is a distinction -- which is prior?

   The correspondence between representation and resource, or the
   behavior of a server? Maybe a bit subtle.

   jar: Note dbooth may disagree with some of this?

   The resource is [implies] a set of constraints on what consitutes a
   valid representation of a [the] resource.

   timbl: unhappy about treting the resource as an agent.

   <DanC_> (timbl, you didn't say that to the meeting)

   Noah: Surely the server is an agent not hte resource

   <masinter> I'm missing the model theory which resolves the boundary
   of what is a 'resource':

     [57] http://masinter.blogspot.com/2010/03/resources-are-angels-urls-are-pins.html

   jar: There is a view in which the resource is an agent; that is not
   my view.

   <DanC_> HT: ah... interesting... in the case of a resource that
   comes from somebody typing in a file, the server is constrained to
   just about 1 representation, but in the case of ...

   <DanC_> ... sensor networks and database cells and such, then the
   server may choose from lots and lots of representations

   Jk: When there is file written by a person hen there is agency but
   is not the resources.

   Ashok: Translations?

   jar: You can have multiple resources, or one resource which exists
   [has representations] in five translations.

   <Zakim> johnk, you wanted to note Henry's point again about creator
   of a resource

   jar: Can you authorize a proxy to do translations? It would have to
   be authorized out of band, you can't negotiate that within HTTP.
   ... There is no way to negotiate that a proxy can do extra
   translations within HTTP.

   DA: Does this account for the serving of a special version of a blog
   page for a mobile phone?

   timbl: That is fine. All is OK in that scenario. The blog os the

   <DanC_> [t1,t2) ::= { x : x >= t1 and x < t2 }

   jar: The over_interval* stuff is about a commitment that a given
   correspondence between resource and representation holds for a
   period of time.

   ht: I am not sure the signature of W() makes sense to me, it is in
   tension with the signatures of the redirects, seeOther() etc.

   <ht> ht: the server needs URIs to manage redirects

   <DanC_> (ht, I too suspect things may fall apart without getting the
   URIs into the theory, but we're not far enough to tell)

   <ht> JAR: I'm trying to be faithful to the spec, which talks about
   resources not URIs

   jar: This is close to being a private theory, but the goal is that
   one can actually infer something in all this.

   <ht> DC: Show me the spec.

   <johnk> some language from RFC 2616

   <masinter> I can't read this unless I think of R as "URI" and not as

   <johnk> 10.3.1 300 Multiple Choices - "If the server has a preferred
   choice of representation, it SHOULD include the specific URI for
   that representation in the Location field;"

   <masinter> "for a resource whose sole representation is the
   representation given ..."

   jar: When a redirect happens, some properties of the first resource
   are "taken from" the second -- specifically representations of B are
   also representations of A. And the seeOthers are also shared.
   ... The seeOther rule is interesting in that it is consistent with
   some sem web clients but not others.

   <johnk> other text from 2616 3XX status explanation talks about
   redirection from one resource to another, or about multiple URIs to
   the same resource

   jar: For example, there are ontologies deployed on purl.org with a
   302 redirect. There is a 302 on purl.org for example whcih might be
   broken [in some clients].

   <johnk> 3xx response codes:

     [58] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3

   noah: Really this property rule works for real properties?

   timbl: Yes, e.g. with a 200 on B then assume both A and B represent
   a document in the tabulator.

   jar: Roy says that the mapping is from [time to set of

   <masinter> please reference HTTPBIS rather 2616 since we might
   actually fix wording problems

   jar: A change in a resource would be observed as a withdrawal of a
   licence to deliver a representation.

   [search for a information resource which is "not restful". ]

   jar: Are there [information] resources which are not RESTful?

   <johnk> "in particular, the convention has been established that the
   GET and HEAD methods SHOULD NOT have the significance of taking an
   action other than retrieval."

   <masinter> is there room in this discussion for believing that
   "resource" is being misused

   <johnk> from [59]http://www.apps.ietf.org/rfc/rfc2616.html#sec-9.1

     [59] http://www.apps.ietf.org/rfc/rfc2616.html#sec-9.1

   jar: Are there changes in representations without change [in the]
   ... But -- which happens first? Is the web stable and then described
   by metadata? or the other way around -- we know what it is from
   metadata and that drives the web? [the scribe thought jar was
   setting up an ordering or exclusion, but he wasn't.]

   ht: In case (1) you are trying to get to where we can form the
   disagreement that Larry has had with much of these discussion in
   more concrete terms, that if we can't talk about authoritativeness
   then we can't talk of anything.

   jar: In case (1), you get authoritative onfo from the protocol, and
   you can actually synthesize information from the protocol itself.
   ... Can you infer anything about a resource frm the representation?
   I don't know?
   ... Possible sources of metadata.
   ... [discusses the note]

   <masinter> and
   [60]http://tools.ietf.org/html/draft-masinter-dated-uri-06 as the
   only really "universal" URI scheme

     [60] http://tools.ietf.org/html/draft-masinter-dated-uri-06

   <masinter> want metadata theory to have provenance, and be couched
   in terms of "party A asserts B about C", never to divorce the
   authority from the statement

   <masinter> including model of trust, A trusts B implies process A
   uses to believe statements (metadata) by B

   <DanC_> "FRBR: Functional Requirements for Bibliographic Records"

     [61] http://www.frbr.org/

   <DanC_> see also [62]http://vocab.org/frbr/core Expression of Core
   FRBR Concepts in RDF

     [62] http://vocab.org/frbr/core

   jar: An frbr:Item is
   ... not an information resource, as it is made of atoms.
   ... Do you want to use a DOI URI for [to name the article]? Normally
   it dereferences to a page about paying money for the article.

   <ht> HST: The question of which [timbl: any] of the FRBR terms is
   right for Z respectively R is, to me, interesting

   timbl: Another thing which is interesting is which FRBR Classes are
   such that membership of that class are properties which carry over
   in the property redirect rule. [for example, does 302 imply same
   Work? Same Expression? etc]

   <DanC_> (where's the dang definition of frbr:Item?)

   <Zakim> masinter, you wanted to talk about
   re-pins.html and thinking about the intrinsic ambiguity

     [63] http://masinter.blogspot.com/2010/03/resources-are-angels-urls-are-pins.html

   <DanC_> (I can't find any evidence that they're physical)

   DanC, click on it!

   <DanC_> I did

   <DanC_> well, I clicked on a schema by Ian Davis, but I don't think
   he speaks for the FRBR folks

   masinter: I have been thinking about whether resources exist. Where
   I have come to is for my web page, is it the web page of then HTML,
   or is it the entire site, and the answer which is most appealing is
   "yes". It is in a way all of those things. find I need ambiguity
   about what it exists or I end up talking about angels on the head of
   a pin. Most communication is ambiguous.
   ... You can't use set theory on these things unless you have
   equality, and we don't even have a theory of equality for resources.

   jar: We can do a lot without this -- look at what I am doing with
   FOL without that


     [64] http://tools.ietf.org/html/draft-masinter-dated-uri-06

   masinter: The URI document is not a good one as a basis for making
   logical systems.

   <DanC_> ([65]http://www.ietf.org/rfc/rfc3986.txt Uniform Resource
   Identifier (URI): Generic Syntax Fielding, Berners-Lee, and

     [65] http://www.ietf.org/rfc/rfc3986.txt

   <DanC_> (tim, you didn't mean a 1-1 mapping between Us and Rs, I

   <noah> +1 Dan

   <DanC_> (to accept a premise that names are ambiguous is to abandon
   first-order-logic. I'm not sure that's a good idea.)

   masinter: It is important to record the provenance of metadata.

   <DanC_> (meanwhile, my attempt to fit the Lampson speaks_for stuff
   into FOL over the last few months sorta failed. so... hmm.)

   (he's not anbandoning that -- i think he is just saying persoanlly
   he can't copye with trying to define what a [information] resource

   <DanC_> [66]http://www.ietf.org/rfc/rfc3986.txt

     [66] http://www.ietf.org/rfc/rfc3986.txt

   Noah: I kinda buy 3986 as a basis for a communication protoocl but
   not a logic -- is that what you said?

   masinter: not quite
   ... I can't beleive that the semantic web works by reading more into
   an existing spec.

   timbl: That's too bad

   <DanC_> (huh? timbl, you didn't speak)

   (very quietly)

   masinter: it would step back from the sem web if it stepped back to
   use an ambiguius stance as to what a URI identified.

   <DanC_> DanC: the semantic web doesn't rely on certain readings of
   the URI spec; it specifies the 1 URI identifies one resource in
   separate specs.

   ashok: By "ambiguous" do you really mean "not knowabout"

   <masinter> larry: yes.... (except for "tdb")

   <Ashok> s/nowknowabout/not knowable/

   <Ashok> s/not knowabout/not knowable/

   <jar> masinter: Semweb has a postulate that you don't need, that
   http responses are meaningful

   timbl: Are you saying the web web is broken or it works and you have
   a better plane/

   masinter: the latter

   <masinter> i don't think it's broken insofar as the assumption isn't
   really necessary

   <masinter> that the meaning of assertions is tied somehow to the
   operational behavior of HTTP servers

   <Zakim> jar, you wanted to ask larry how metadata subjects should be

   jar: A core problem. When you write metadata, how should you
   designate the subject?
   ... The RDF project was started as a metadata project, and used HTTP
   URIs as the things you are talking about, [when they] are on the

   masinter: Adobe products use RDF using sometimes withe HTTP URIs and
   sometimes not.

   <masinter> sometimes using a GUID-based URI scheme that identifies
   resources that aren't on the web.

   <Ashok> ... sometimes using GUIDs because the items have not been
   published yet

   <masinter> in XMP

   <masinter> jonathan's formalism works for me using URIs

   jar: The RDF semantics covers all the stuff you brought up Larry.

   <DanC_> larry, even if you track provenance and such, you do so a la
   "Bob thinks asset:123 is blue". FOL doesn't assume one universal
   referent of asset:123; it has a framework of interpretations that
   map names (functionally) to referents

   <masinter> so you're assuming [67]http://www.w3.org/TR/rdf-mt/ ?

     [67] http://www.w3.org/TR/rdf-mt/

   <jar> yes

   <jar> also known as FOL. RDF is just a vector for FOL

   <noah> Break

   <masinter> I'd like the semantic web to work for content that is
   delivered over bittorrent or FTP or broadcast on television, and
   where there are no HTTP status codes to be found anywhere

   <masinter> and i think the second-order logics about belief, trust,
   provenance are really important

   <Zakim> timbl, you wanted to say that I don't see why jar needs to
   have (1) or (2) to have a causality between the two separate types
   of activity which hcan happen in parallel.

   <DanC_> masinter, I think the semantic web should be able to take
   advantage of (i.e. exploit) http status codes, but it doesn't depend
   on them.

   <DanC_> i.e. the RDF specs treat http URIs and ftp URIs the same.

   <jar> and tag: URIs

   masinter: I don't like this account, particularly when we start
   modeling and talking about who said what.
   ... There is an alternative which is pretty consistent with what you
   (jar) are saying but taking a different gloss.

   <Zakim> ht, you wanted to try to be optimistic on getting to the
   modal version of this

   masinter: For a model of trust we need this too, and it helps fro
   example for me when tallking ag about Cross-Site Request Forgeries.
   ... (CSRF)

   ht: I am sympathetic to your goals, Larry, but getting the "if what
   everybody said was true logic" under control is a good dtart, and
   then proceede to the intentional one.
   ... Otherwise the step function to get off te ground is too high.

   <DanC_> (cyc microtheries are kinda cool for saying "in a world with
   fixed time..." or "in the harry potter world...")

   <ht> TimBL: Doing the who-said-what stuff needs something like
   Jonathan's starting point

   (lets work in the HP world for now ;-)

   <ht> ... I would add that just as not doing the intentional part
   right away, we don't need time either

   <ht> ... it can be added later

   <ht> s/intentional/modal/g

   <ht> [Where by 'modal' above I mean, adding an 'according-to-whom'
   argument to everything, or wrapping everything in belief/authority
   modal operators, or. . .

   <ht> ]

   Timbl: It is really inconvenient to always consider the possibility
   of people having misunderstood each ther -- we move faster if we
   assume that there are things and things which identify them

   noah: Are you sayin gthe sem web is broken, or are you saying Jono's
   model is approaching things in a way which I think could be done

   masinter: There is a setof toolsw which have been devised which make
   sume assumptions -- if you look at the tool in a different way you
   may finf them more useful. The tools worl for a set of examples.
   ... Like when we are doing inference from metadata.
   ... We have a movie nd a script which wwas makde from the movie, and
   therte is no HTTP in sight, and no status code. Thge more they tools
   rely on HTTP, the kless useful they are to me. I need other ways of
   making tose systems.

   timbl: We have sem web tools liek the ones i have been using for 9
   years which will allow you to do all the things you were jsut
   describing. DO go ahead an duse them. Without using the semantcis of
   HTTP expklicitly.

   danc: Some people think that there are no constraints, some want
   fewwe. There are diosagreements

   noah: This is nt aboyt the sem web only. or mainly. The HTTP
   protocol is a really imporant protcol, and this will allow us to
   answer questions abouyt what HTTP, given the right formalism.

   masinter: I think there is some level of abstraction which is

   <noah> s/only. or mainly./only./

   masinter: Some way of darwing assertions about it. With that level
   of abstraction, you wouldn't deep-ending on what HTTP status codes

   <noah> s/aboyt/about/

   <noah> 5 mins

   <noah> s/darwing/drawing/

   jar: That is one of the positions taken by my presentation. But it
   has consequences.

   <noah> 4 mins

   masinter: Good consequences.
   ... It would be good to be able challenging these assumptions
   without being asked whether I am challenging the entire semantic

   ht: Let's , as several of us had a naîve reflex to keep trying to
   read R as U, and as the assertion was made that there is
   justification for this in the RFC, remind outrselfves -- I have just
   remind myself the first few lines:- '

   <noah> 3- mins

   <noah> 2 mins

   <ht> RFC3986 says "This specification does not limit the scope of
   what might be a

   <ht> resource; rather, the term "resource" is used in a general

   <ht> for whatever might be identified by a URI.

   <johnk> 3xx response codes:

     [68] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3

   <ht> 10.3.3 302 Found

   <ht> The requested resource resides temporarily under a different

   <DanC_> noah, I think we're trying to do formalism without some of
   the basic tools in our toolset. Jonathan mentioned the possibility
   of an RDF semantics tutorial. That might speed things up.

   <ht> THat's a relation between R1 and U2, not R1 and R2

   <DanC_> a risk: it took me not an afternoon but 18months to grok it.

   <DanC_> so I'm sympathetic to the view that this is an interesting
   book/research topic, but not cost-effective for the TAG

   <noah> Dan, suggestion on what I do about it?

   <noah> s/I/we/

   <DanC_> I gave 2 different suggestions; I lean toward the latter, I

   <noah> OK, I'll go with the latter. What is it?

   <ht> Have JAR write a book :-)

   <DanC_> um... shall I type it LOUDER? ;-)

   <noah> Thought you said "have" 2 suggs. Sorry.

   <DanC_> (a) tutorial (b) drop it.

   <noah> Tnx

   <DanC_> "Have JAR write a book" falls under (b) drop it from the TAG

   <DanC_> ACTION: DanC to suggest a path thru some logic terminology
   that might speed up httpSemantics discussions [recorded in

     [69] http://www.w3.org/2010/03/25-tagmem-irc

   <trackbot> Created ACTION-413 - Suggest a path thru some logic
   terminology that might speed up httpSemantics discussions [on Dan
   Connolly - due 2010-04-01].

   [a discussion of future directions ensues. DanC proposes that we
   would make more progress if we had a common understanding of FOL and
   wonders whether a talk from Pat or HT might add the necessary

   <DanC_> (DKA, the compositional deely HT mentioned is
   [70]http://www.ltg.ed.ac.uk/~ht/compositional.pdf from
   [71]http://www.w3.org/2001/tag/group/track/issues/34 )

     [70] http://www.ltg.ed.ac.uk/~ht/compositional.pdf
     [71] http://www.w3.org/2001/tag/group/track/issues/34

   <noah> Suggest 24 May

   a discussion of future directions ensues. DanC proposes that we
   would make more progress if we had a common understanding of FOL and
   wonders whether a talk from Pat or member:HT might add the necessary

   <DanC_> action-201?

   <trackbot> ACTION-201 -- Jonathan Rees to report on status of AWWSW
   discussions -- due 2010-04-24 -- OPEN

   <trackbot> [72]http://www.w3.org/2001/tag/group/track/actions/201

     [72] http://www.w3.org/2001/tag/group/track/actions/201

   [Exeunt, pursued by a bear]

   <ht> [Exeunt, stage left, pursued by bear]

ISSUE-50 (URNsAndRegistries-50): Persistent naming

   ht: Possibilities include having a half-day meeting in June with
   peopl eoutside the TAG

   nm: from anywhere in the world?

   ht: From the UK
   ... That is where ACTION-351 rests.
   ... There was a suggestion to line it up with another big meeting

   jonathan: Like DCC

   ht: OCLC are heavility onvolved with a European meeting once a year.
   ... a please come and join us one afternoon would be good to
   brainstorm about this.
   ... Where "this" means range of things including say a new top-level
   domain, special dispensation from IANA, etc.

   <ht> s/European meeting/meeting/

   <ht> s/year./year, and OCLC do something as well, I think./

   <Zakim> noah, you wanted to talk about time frames

   <Zakim> DanC_, you wanted to remind Noah that my suggestion is that
   he doesn't have to track this at all, but rather to have HT pursue
   this as a W3C workshop with the staff and to remind

   <ht> The director of the DCC "Chris Rusbridge"

   danc: Larry sugested not pursued in the TAG.

   jar: I think this ought to be a TAG thing -- I see this is
   important. Unfortunate that HTTP URIs are marginalised and treated
   no better than phone numbers.

   The W3C should care about this.

   <DanC_> (gee... phone numbers are treated with considerable respect;
   "no better than phone numbers" is pretty not bad)

   timbl: This is important, and i don't think anyone else in the tag
   is doing it.

   <ht> I heard JohnK say "It's an architectural issue"

   jonathan: This is important to me. I take issue with the Crossref
   folks for some of what they are doing. It would be good to have this

   <jar> (sorry Geoff)

   timbl: I also feel this is important and do and will put time into
   it talkingto people.

   <DanC_> s/or what/for what/

   ht: I will take an action to propose an agenda for an afternoon

   <ht> ACTION Henry to prepare a draft agenda, including goals and
   means, for a proposed afternoon session with invited guests, and
   circulate for discussion prior to a decision, on the subject of
   addressing the persistence of domain names

   <trackbot> Created ACTION-414 - Prepare a draft agenda, including
   goals and means, for a proposed afternoon session with invited
   guests, and circulate for discussion prior to a decision, on the
   subject of addressing the persistence of domain names [on Henry S.
   Thompson - due 2010-04-01].

   at the June face-face

   <ht> ACTION-414 due Apr 15

   <trackbot> ACTION-414 Prepare a draft agenda, including goals and
   means, for a proposed afternoon session with invited guests, and
   circulate for discussion prior to a decision, on the subject of
   addressing the persistence of domain names due date now Apr 15

   <ht> close action-351

   <trackbot> ACTION-351 Look into a workshop on persistence... perhaps
   the June 2010 timeframe closed

   <DanC_> ACTION-351: see action-414 for follow-up

   <trackbot> ACTION-351 Look into a workshop on persistence... perhaps
   the June 2010 timeframe notes added

   <ht> action-414: The proposed afternoon meeting would be during the
   TAG's June 2010 f2f

   <trackbot> ACTION-414 Prepare a draft agenda, including goals and
   means, for a proposed afternoon session with invited guests, and
   circulate for discussion prior to a decision, on the subject of
   addressing the persistence of domain names notes added



     [73] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0073.html

   jar: I will explain my idea. This may relate to some stuff DanC was
   talking about baout p2p and HTTP.
   ... Comparing what reliable naming systems to to what the web does,
   compare and contrast.
   ... In the message, I have two examples.
   ... 1) species name -> description
   ... 2) description of description of doc -> document

   (description being title and author, etc)

   danc: In fact the puplisher often wants money

   ht: suppose though the publisher went out of business long ago

   jar: You have an author then who does some speech act, and ships [a
   document] to a publisher, who then deistributes copies to shops
   [libraries] which distribute them to readers.

   <ht> s/ht: suppose though/jar: In fact in many cases/

   <ht> ht: but libraries have copies

   jar: We have the same picture on the web, but the only different is
   timescales. We have an author, a hosting service, and caches and
   various readers.
   ... In the first picture, the library is the bridge in time, as the
   difference between the writer and reader is 200 years.
   ... However with the web, [well] we don't know what happens in the

   ht: Actually the national libraries are worrying about the web.

   <ht> The British Library on web archiving:

     [74] http://www.bl.uk/aboutus/stratpolprog/digi/webarch/

   <ht> An example from the British Library web archive pilot project:

     [75] http://www.webarchive.org.uk/wayback/archive/20050808102339/http://robincook.org.uk/index.htm

   jar: If you look at LOCKSS, the system used by libraries to back up
   journals, it is an extension of this system.

   ht: In many cases like the Internet Archives, they really are
   archives of the web.
   ... these people worry about this question for the web.
   ... The librarians are indeed trying to solve this problem.

   jar: There is little role for the URI in that model

   ht: Oh yes there is

   danc: Yes
   ... There are lots of web caches and lots of things
   ... i was talking to John Bosak about the fact that the XML spec had
   no URN: he was worried about it but I pointed out that at any time
   there are many machines with copies of that spec on them.

   NM: Can I just tell your story quickly and see if it is what you
   mean. Do you mean that in the first system , there is no linnean
   identifier at all? That in the existing case there is nothing which
   we would use as a URI - in that case the first one what is the role
   of the URI of preserving that association? Explain how this picture
   gives them comfort... I think yuo will tell me that the linneans wil
   have a time-oriented algorithm -- so the purpose of these ...

   ... things it to preseve the input to that algoroithm? how for case
   2, we have a dfferentc ommunity fo people you dodn't ahve a little
   string name, so they work o a soirt of best effort approach? In taht
   case thyis is a little less like a a UTI case. o in that case with
   autjros and cacshes I a m trying to say what dioes that pe=resvera
   about what you want?

   [Noah, please correct the script]

   I am just trying to make sure I understand how this works. The URIS
   work like the Linean system, but have a way fo breaking ambiguities.
   This is just a hope, nut it may happens.
   ... and with these case hte reason taht the persstence is impoirtant
   is [lost[ .. s ll tese thinsg ahve a systme which takes you from
   [...] to what exists [...]

   idealy a URI resouyrec(in th second case) and the author puts
   somethingup opn a web server and that stuff ends up in a lot fo
   caches and now what?

   Lets thtake the case taht everything is in the cashe and nmes i nthe
   nbashe ... so yo would find all teh caches in the world and see
   which which have a given name ... liek I would find soemthng ...


   danc: But that is quite outside this model

   nm: So that is valuable to know -- it mean that other things whcih
   are not coverd by the model

   DanC: On the left (paper) the system is only solved for static

   DanA: There may be an author who creates an SGML hich generates
   difefrent forms, one hosteed by hosted by nature, but some oethr s
   are preprinst distributed n fvarious ways, and even put in Paul
   Ginsparg's archive.

   jar: What would it take to make URLs so strong that sceptical
   entities like archivists would use them?

   dana: The advantage of a citation is you get an idea of what the
   thing is.

   danC: I concluded that the archivist's requirements can't be met
   with completely opaque URIs. But if you make a domain such as
   .academy whose URIs by policy/definition transparently encode the
   citation information including year and journal and publisher and
   author and title in such a way as you can extract those things,
   that's just as good

   <ht> GET [76]http://www.theacademy.org/ ==> 403 :-)

     [76] http://www.theacademy.org/

   nm: What if acandemy.org has their domain name taken away?

   jar: There is no central authority for libraries.

   <ht> NM: and then how do you tell new ones (post identity theft)
   from old ones (pre identity theft)

   <DanC_> (jar, what was your last question to me? I'm trying to mull
   it, but it's leaking out)

   <ht> TimBL: There's an authority, the publisher, via the name of the
   journal, even if there's no _central_ authority

   <ht> ... So if you don't know, you can go to the publisher

   <ht> ... Publishers do now use ISBNs for books

   <ht> JAR: But they're not universally trusted, because the database
   isn't open

   <ht> TimBL: People are quoting DOIs or ISBNs via

     [77] http://...doi../39585.287

   <ht> JAR: There's no need for any trust, except that there are no

   <ht> ... You have to believe that ten libraries would all change
   their copies

   <jar> If you don't trust the owner of academy.org, then either you
   need to be prepared to secede from ICANN, or you commit to
   attempting to enlist ICANN's help in ensuring stability

   <Zakim> ht, you wanted to gloss "It hasn't been solved"

   <jar> "administrative single point of failure"

   ht: Scholarly communities refuse point blank to use DNS-based
   identifiers on the grounds that their constituency extends for
   hundreds of years and the DNS system can't guarantee any more than a
   few years. They believe that argument.

   <Zakim> DanC_, you wanted to emphasize a point I heard timbl make:
   there _is_ a central authority for journals, publishers, etc; when
   one is created, there's a serious effort to make its name unique

   <jar> danc: It's fixed in an important way

   danc: What i mean by fixed is 99% of the world getting 99%
   reliability -- there is 1% of 1% of the world getting failure
   ... there is a trust that there is no duplication of the publisher
   and journal names

   jar: ISBNs are not trusted because the database is not open.

   raman: The person who solves this problem will want money for it

   jar: Exactly. That is what DOI do. They charge money. They keep the
   database closed. That is why they can't [shouldn't] be trusted.

   <jar> database is open, after registration, for single queries. what
   you can't do is host it yourself (2nd sourcing)

   danc: I am starting to see the appeal of the idea of a domain which
   starts with date; e.g. 2009.arc

   <DanC_> s/getting failure/who wants more reliability than that/

   <jar> muguet

   jar: If you are on a space station and the world blows up, you will
   re-assemble everything using the indexes [?] of the URIs
   ... the person Muguet who passed away recently was talking about the
   politics of te top-level domains.

   dana: There may be a strong push-back from existing interests

   danc: The web has grown in $$ value much faster than the governance
   models have evolved.

   <DanC_> (and dana and I were talking about the DNS as much as the

   ht: We got an consensus of curators etc who use lots of DOIs that
   all proposed persistent identifier schemes should publish a clear
   statement of how to produce an HTTP version of all their identfiers.

   ht: It takes the consensus we hammered ou with all the XRI people
   over many years.
   ... Paul Walk summed it up in one great sentence.

   <ht> Blog about the London persistent identifier meeting I

     [78] http://blogs.cetis.ac.uk/lmc/2010/02/09/jisc-persistent-identifier-meeting-general-discussion/

   <DanC_> we should get that in a TAG blog or tweet stream or
   something, ht. hmm.

   <ht> Not mine!

   <ht> Sorry, that is, the blog is not mine

   <DanC_> right; it's by Lorna

   <ht> The tweet stream at the meeting is the only available record,
   and as of now it's . . . not available!

   <DanC_> huh? I don't follow you


   jar: About Trust.
   ... To make a system trustworthy, one has to make sure there is no
   single point of failure.
   ... So you have to make the system open so that anyone can replicate

   danc: What is different between the web and the journal case -- we
   have to trust ICANN

   ht: ICANN have specifically stated that they will take admian away
   from them The book worlks has no such problem


   [discussion of relative likelyg=hod and worry about failure mode
   with people stealing names in each system]

   <jar> timbl: concern about ICANN failure... many people are watching
   it, are concerned. if it behaved badly, there's a process, it would
   be replaced. so much depends on it that it would be replaced by a
   compatible system.

   <johnk> timbl: lots of people want to run their own DNS root

   <jar> timbl: if we get a special deal for some part of DNS space,
   then... [we would get independent buyin]

   s/[we would get independent buyin]/then we woudl be wise to get
   agreeement for the terms to be respected by all ICANN statekholders

   dka: I remember that there is a political process for top-level
   domain names that teh US dept of commerce was involved. Suppose the
   administration of some authoritarian regime wants to eleiminate say
   a Journal of Eviolution?

   <DanC_> (that would mean closing ACTION-402 and ACTION-33 on Henry
   S. Thompson: revise naming challenges story ...)

   <DanC_> close ACTION-402

   <trackbot> ACTION-402 Summarize JAR's message to HT re HTTP-based
   naming and put it(?) on the agenda closed

Summary of Action Items

   [NEW] ACTION: DanC to suggest a path thru some logic terminology
   that might speed up httpSemantics discussions [recorded in
   [NEW] ACTION: DanC to try the clarification question, blog item, or
   wiki approach to metadata-in-uris vs CSRF [recorded in
   [End of minutes]

     [79] http://www.w3.org/2010/03/25-tagmem-irc
     [80] http://www.w3.org/2010/03/25-tagmem-irc

    Minutes formatted by David Booth's [81]scribe.perl version 1.135
    ([82]CVS log)
    $Date: 2010/04/05 21:37:42 $

     [81] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [82] http://dev.w3.org/cvsweb/2002/scribe/


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

                               - DRAFT -

                                TAG f2f

26 Mar 2010


      [2] http://www.w3.org/2001/tag/2010/03/24-agenda.html

   See also: [3]IRC log

      [3] http://www.w3.org/2010/03/26-tagmem-irc


          Dan Appelquist, Tim Berners-Lee, Dan Connolly, John Kemp,
          Ashok Malhotra, T.V. Raman, Henry S. Thompson, Jonathan_Rees
          (in part)

          Noah Mendelsohn

          Henry S. Thompson (morning), John Kemp (afternoon)


     * [4]Topics
         1. [5]Agenda review/rework
         2. [6]Web Application Architecture: Taxonomy of Web
            Application Structures
         3. [7]Framing/Dividing up further work on Web Applications
         4. [8]Meeting with W3C CEO Jeff Jaffe
         5. [9]ACTION-407
         6. [10]Mobile Web Considerations
         7. [11]text/html registration
         8. [12]F2F arrangements
         9. [13]Client-side identification
     * [14]Summary of Action Items

Agenda review/rework

   NM: Application morning, rest in afternoon?
   ... Approved

Web Application Architecture: Taxonomy of Web Application Structures

   <DanC_> ACTION: John to edit ftf minutes day 1 (Wednesday 24 March)
   [recorded in

   <trackbot> Created ACTION-415 - Edit ftf minutes day 1 (Wednesday 24
   March) [on John Kemp - due 2010-04-02].

   JK: [16]http://www.w3.org/2001/tag/2010/03/web-apps-taxonomy.html

     [16] http://www.w3.org/2001/tag/2010/03/web-apps-taxonomy.html
     [17] http://www.w3.org/2001/tag/2010/03/web-apps-taxonomy/web-apps-taxonomy.html

   <DanC_> ACTION-352?

   <trackbot> ACTION-352 -- John Kemp to integrate whiteboard drawings
   into a prose document about ways to distribute applications -- due
   2010-03-08 -- PENDINGREVIEW

   <trackbot> [18]http://www.w3.org/2001/tag/group/track/actions/352

     [18] http://www.w3.org/2001/tag/group/track/actions/352

   JK: This is a transcription of the whiteboard from last time
   ... Ways of acquiring and using web applications
   ... 1) Widget-style: download compressed packaged widget, install,
   run on client via widget platform
   ... Weak form of trust between widget and widget platform, by means
   of crypto signatures
   ... Trust often proxied by use of an 'app-store'

   JK: 2) Server-side collection, install and run from server

   <DanC_> (I wonder why iGoogle isn't in the document. I think it's
   good to start with concrete things that people know before

   NM: Two versions? Really all CGI on server, completely ignorant
   client, vs. Javascript into client which reflects widget structure

   AM: Widgets execute independently, or can they pass info back and

   JK: To some extent

   TVR: iGoogle has a limited facility

   JK: Limited Javascript sometimes used, e.g. Caja
   ... Security and trust is the main thrust of this investigation

   In (2), DNS-based trust, that is, you trust the owner of the
   server-side container, iGoogle, or Facebook, for example

   <DKA> Apache wookie is a good open source implementation of w3c
   widgets in the context of running in a web page:

     [19] http://incubator.apache.org/wookie/

   JK: 3) Client-side dynamic mashup
   ... Locus of cross-site scripting vulnerabilities
   ... One site creates content including e.g. Javascript which
   requests to other sites
   ... Content assembled on the client, based on multiple sources
   ... Restricted by same-site, CORS, etc.
   ... Trust based on combination of implicit user grant, same-origin
   policy, others
   ... Tabulator?

   TBL: Yes

   DA: Specifically referring to the WARP spec.?

   <DKA> [20]http://www.w3.org/TR/widgets-access/

     [20] http://www.w3.org/TR/widgets-access/

   DA: Adds another security policy in this space

   <DKA> <access origin="[21]https://example.net"/>

     [21] https://example.net/

   <DKA> <access origin="[22]http://example.org" subdomains="true"/>

     [22] http://example.org/

   <DKA> <access origin="[23]http://dahut.example.com:4242"/>

     [23] http://dahut.example.com:4242/

   <DKA> <access origin="*"/>

   DA: Relevant to installed widgets

   <Zakim> DanC_, you wanted to noodle on (a) using this to review HTML
   5 origin and perhaps the origin header draft and (b) think about
   audiences... webapps wg, the group around

   <DanC_> [24]Widget Access Request Policy W3C Working Draft 08
   December 2009

     [24] http://www.w3.org/TR/widgets-access/

   DC: Origin stuff also in HTML5, do these interact?
   ... Learned by writing code

   TVR: Like everyone else

   DC: What about the origin header?

   NM: I think we could produce, for a similar audience to webarch, a
   document with scenarios such as the ones is these diagram

   <timbl> [25]http://mashssl.org/

     [25] http://mashssl.org/

   AM: a problem in this scenario [client-side dynamic Mash-up] is
   establishing trust between Website A and Website B... there's an
   interesting technology for that ... mashssl


   AM: I was very impressed with this

   TVR: You could do this with OAuth

   <timbl> "Many modern web application protocols require applications
   to communicate with each other through a user's browser. But what if
   the user is malicious or the user's browser has malware?"

   TBL: Friend in the middle -- does not trust the user

   TVR: iGoogle uses OAuth to function as that kind of middle-man

   <DanC_> (I've seen this mashssl page, but I can't tell when... I
   don't see it in [26]http://delicious.com/connolly . I haven't
   studied it far enough to tell how it works)

     [26] http://delicious.com/connolly

   <noah> From Mashssl.org:

   <noah> When two web applications are communicating through a user's
   browser, for instance to provide the user a mashup, the applications
   do not have a standard and secure method of authenticating each
   other and establishing a secure channel. In addition to the risk of
   MITMs (man-in-the-middle) between the user and one of the web
   applications, there is the additional, potentially bigger, risk of a
   malicious user. We motivate this problem with a very simple thought

   <timbl> [27]http://mashssl.org/technology_mashssl.html

     [27] http://mashssl.org/technology_mashssl.html


     [28] https://www.safemashups.com/downloads/MashSSL_Towards_Multi_Party_Trust_in_the_Internet.pdf

   <timbl> ^ White paper

   <jar> AFAICT mashssl is a conventional ACL approach, completely
   opposite Caja.. thus the usual vulnerabilities

   JK: But that's still delegated user authorization, via a middleman
   ... not the same as trust between middleman and third-party as such

   DC: Thinking about audiences -- where are we wrt talking
   with/to/hearing from the WebApps WG?
   ... and the public-web-security security mailing list

   <DanC_> [29]http://lists.w3.org/Archives/Public/public-web-security/

     [29] http://lists.w3.org/Archives/Public/public-web-security/

   <DanC_> [30]http://www.w3.org/Security/wiki/Main_Page

     [30] http://www.w3.org/Security/wiki/Main_Page

   NM: next steps? Divide up writing?

   TVR: Divide up the space first, then get ownership

   NM: Do that, for sure, but prefer doing it after we talk about URIs
   and Identification

   TVR: Worried we will be left with no-one assigned to write

   DC: Leaving at 2, prefer to know who owns what during discussion

   NM: Tech Discuss first, vs divvy first
   ... 2 vs. 2

   TBL: add me to Divvy first

   NM: Agreed

   TVR: Time-bound

   NM: Bound to an hour, return after lunch to URIs etc.
   ... While discussing divvy, need to cover what constitutes success,
   who is the audience, table of contents

Framing/Dividing up further work on Web Applications

   TVR: I did this work on # in URIs last year, that's just a small
   ... The large question of Web Applications needs a broad scope
   ... Data plus interaction working via web technologies
   ... Yes, even Flash
   ... My preference is for HTML, CSS and Javascript
   ... but there are lots of others -- anything that comes over HTTP(S)
   ... How does this become 'live' in your memory -- the DOM

   <noah> I personally would say: yes Flash, when the intention is to
   use it in a Wed-arch compatible way (he says circularly). Flash is
   Turing-complete, and I don't want to talk about everything it could

   TVR: plus eventing, javascript interpretation, then more web access
   ... which in turn requires authentication, trust, so we loop back
   into the beginning

   <DanC_> (transport being HTTP/HTTPS... how about websockets? XMPP?
   and SMTP comes in for email callback auth)

   TVR: This breaks down into four or five documents, which I think we
   should divide up responsibility for and try to develop

   <johnk> I deliberately ignored the "browser plugin" model in the
   web-apps taxonomy

   NM: I heard TVR to suggest review of the parts, via e.g. the
   blogsphere, and then pull them back into a whole

   <DanC_> (yeah... I heard "sections", not "documents")

   TVR: Yes, so we do the divide up at this meeting to get this moving

   DA: Yes, emphasize casting the review net very widely

   TVR: Focus on both desktop and mobile

   <jar> re "requires trust", you don't need to trust something that's
   not authorized to do anything harmful. (e.g. script-free html, or a
   script running with only benign rights). sometimes you'll need
   trust, sometimes not.

   JK: What about Web Sockets/XMPP -- how do those fit in?

   TVR: Web Sockets is a back-channel between the browser and the
   server, could use HTTP, so this is definitely in scope

   TVR: XMPP is also, particularly because of Jabber

   NM: Wrt Flash, it's a big system, including it is like trying to do
   C programming

   NM: So include it, but only when it's involved with the Web, not
   just any computation

   HST: Same for Javascript -- can use it to write a Hidden Markov
   Model simulator. . .

   TVR: Yes, the focus is on the web interaction aspect, not what
   happens inside the black box, e.g. internal memory model
   ... Javascript array/JSON hash/Flash blob just doesn't matter

   JK: I didn't include browser plugins, not only because of Turing
   complete, but also because you get beyond the idea of
   sandboxing/managed code
   ... So e.g. Flash can get access to any aspect of the host, because
   it has direct OS access
   ... Whereas the sandboxes have a much more restricted model

   NM: But Firefox could change its mind on this next week, and give
   more access too
   ... look at the geoloc api for example

   <jar> we trust the flash platform *not* to give its rights to the

   AM: Could we use JK's taxonomy to start the division?
   ... Add use cases, problems and proceed from there

   HST: Flash allows write to local disk?

   DC: Google suggests it does

   <DanC_> [31]Reading and Writing Local Files in Flash Player 10

     [31] http://www.mikechambers.com/blog/2008/08/20/reading-and-writing-local-files-in-flash-player-10/

   NM: Mike and camera are (subject to user control) available to Flash
   ... as well as a local store
   ... Looking at the ToC again
   ... given that we're talking about dividing things up
   ... [projects

   <noah> [32]http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921

     [32] http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921


   TVR: Taxonomies are useful, writing down uses cases isn't necessary,
   as they are all around
   ... Architectural descriptions are the focus

   DC: We have five topics, history is not so relevant
   ... we need names

   NM: Section titles are ...
   ... back to older version
   ... includes Security, Client-side ???

   TVR: Candidate section titles could now come from my earlier outline
   plus a few bits

   <raman> What is missing in JAR's outline:

   <raman> Construction of in-memory model from bits on the wire, and
   creating an interactive application from such a memory model using
   eventing and event handlers

   <raman> Might fit into his final section, but personally I'd put it
   in a different section and earlier

   <raman> it would also better motivate the sections on identification
   and naming and authorization etc

   <raman> 1. Web Applications --- from server-side widgets to
   client-side widgets and beyond

   <jar> my sections were mostly whimsical. i thought 3 minutes on how
   to put the list of topics into some order, and it's what I came up
   with. I'm sure there's a better way to organize the document

   <raman> 2. Wire-level protocols for using Web technologies, HTTP,
   HTTPS, and addressing web resources

   <raman> 3. Building in-memory representations that are live --- i.e.
   building a live DOM from the wire

   <raman> 4. Eventing, Handlers, and retrieving more web resources in
   response to interaction AKA the web programming model

   <raman> 5. Authorization, Authentication, Resource identification
   and Trust

   <raman> 6. Deployment scenarios --desktop to mobile and beyond ---
   e.g. a java app on mobile fetches a web resource --- and forks a web
   view to further user interaction

   NM: [building an HTML version, merging with JAR's old ToC]

   TVR: I'll take that and try to cleanup
   ... Logical sequence is as follows: bits off the wire; building a
   live dom; back to the Web; authorization;

   <noah> Here's the URI for the live copy of the outline that we're
   editing: [33]http://www.w3.org/2001/tag/2010/03/webappsoutline.html

     [33] http://www.w3.org/2001/tag/2010/03/webappsoutline.html

   JK: The diagrams fit into item (2) in the outline: From Server-side
   to client-side. . .
   ... So I will try to integrate those into that section

   AM: Maybe include "[some webapp] is an example of this structure" in
   each case

   JK: TVR asked if I would take on the security section
   ... and I could do that

   TVR: Because work you've done already fits in there

   <DanC_> ACTION: John work on diagrams in "From Server-side to
   client-side" section of webapps material [recorded in

   <trackbot> Created ACTION-416 - Work on diagrams in "From
   Server-side to client-side" section of webapps material [on John
   Kemp - due 2010-04-02].

   JK: Would have to do some writing to do that

   <scribe> ACTION: John to frame section 7, security [recorded in

   <trackbot> Created ACTION-417 - Frame section 7, security [on John
   Kemp - due 2010-04-02].

   NM: Good start
   ... Hoping someone will pick up client-side state this afternoon

   DA: I want to contribute, not sure where. . .section 2, setting the
   ... Widget packaging

   <DanC_> (DKA, I second the idea of you working on packaging in
   section 8 deployment)

   NM: Mobile distinct?

   DA: At least implicitly needs to be evident that 'no', everything
   applies to both mobile and fixed deployment

   NM: Team up with JK on section 2?

   DC: Widgets in section 8: deployment would suit your widget
   packaging thing, DA

   TVR: I'll take the section 4 and 6, building DOM and eventing

   AM: I'll contribute on section 5, app state

   NM: There are two aspects of this, long-term persistent and
   ... AM and TVR have looked at these, respectively

   DA: What about APIs, for example geo and DAP ?

   <DanC_> (interaction model section? where is that?)

   NM: JR had a section for that at one point
   ... Re-title section 6 to include APIs

   HST: JAR for section 3

   <johnk> action-417 due may 1st

   <trackbot> ACTION-417 Frame section 7, security due date now may 1st

   JAR: What's section 3 about?

   TVR: When you have a webapp made up out of HTML, CSS, Jscript, all
   are fetched by HTTP, then we go around again via AJAX

   JAR: Not something I know much about

   TVR: I bet Dan C. could help

   NM: We could try to find someone for each section, and if people are
   uncomfortable, we could offer help
   ... or we can just leave some empty

   JAR: Not for me unless I'm a picked victim

   DC: Time frame should be sooner than London

   TVR: That's what I meant by blogging -- I will blog on my own
   ... others can do so, then bring text in chunks to www-tag

   NM: For process reasons, I prefer to see TAG discussion topics to be
   linked from a permanent location
   ... So please work in W3C space as soon as possible

   TVR: Getting TAG agreement to publish is slow

   NM: Not talking about approved, just mail to www-tag as soon as you
   ... This isn't consensus, so just make clear that that's the case

   TBL: Or use the TAG blog -- doesn't require TAG consensus

   JK: I am not sure a highly interactive workflow works for me, I will
   work more in bursts

   <Zakim> DanC_, you wanted to offer to archive stuff that's blogged
   elsewhere in the name of speed/audience/etc.

   DC: I will archive in W3C space if necessary

   NM: My concern was about IP policy -- if DanC archives, that has an
   effect in this regard

Meeting with W3C CEO Jeff Jaffe

   NM: Welcome to Jeff

   JJ: I'm trying to find out how things work around here, and
   understanding the TAG is on the list
   ... When I joined, TBL described a lot of goals for me
   ... The crispest headline was to create a vision for the
   organization of the W3C going forward
   ... I'm not ready for that conversation with the AC yet, but the AB
   looked like a good starting place
   ... So I presented to them, can we find six big things we need to
   ... The size is important -- too big gets us nowhere, too small and
   we can't tackle enough
   ... So stimulate convergence with a list as a starting point
   ... I asked for 3 hours, we had 8, we converged well
   ... Added, subtracted, ended up with 5 headline items
   ... Roughly as follows:
   ... 1) Continuing to strengthen our core mission
   ... [I'll expand that later]
   ... 2) Make W3C the place that people want to bring new standards to
   ... [that came from the reaching out to developer topic]

   JJ: These do all of course overlap a bit, depend on each other, not
   really prioritizable
   ... 3) Establish a sustainable business model
   ... We are surviving now courtesy of ISOC, but the situation is not
   stable in the long term -- we can't keep issuing unfunded mandates
   ... There are challenges behind (2), and addressing some of those
   will need more funds
   ... 4) Drive a truly global and accessible Web
   ... This includes BRIC, as well as Web Foundation and increasing
   access elsewhere
   ... Last was hardest to define and most controversial
   ... 5) Increase our value to users

   JJ: The word 'user' has a lot of different meaning, covers
   everything from developers to. . .non ICT-companies,
   ... verticals, etc. -- Lots outside our core constituencies

   <timbl> "users": "people who are not developers"

   <DanC_> "In economics, BRIC (typically rendered as "the BRICs" or
   "the BRIC countries") is a grouping acronym that refers to the
   related economies of Brazil, Russia, India, and China." --

     [36] http://en.wikipedia.org/wiki/BRIC

   JJ: So there's a sense that we need to expand our reach, in ways we
   can't yet fully agree on

   DA: What about 'stakeholder'

   TBL: Stakeholders are people invested in things, which doesn't cover
   classes of users

   TVR: Who would miss us, would they really miss us, can we increase
   the set who do miss us

   <timbl> "BRICK - and Korea" -- raman

   JJ: I want to get this out to the AC, with some backup, early next
   ... then a lightweight effort over the next three weeks with Team
   and interested AC to make this more precise in terms of what we
   mean, to report to the AB at the end of April
   ... Then the heavy lifting starts: How do we make them happen?
   ... Supposing we have consensus that the 5 are right as elaborated
   ... Then we work for some months on developing answers
   ... AB says that process involves 7 things -- the 5 above, plus how
   do we market W3C
   ... plus, I think separate from (1) above, is the question of what
   the scope of the W3C is.
   ... We are not the only place that does Web standards -- that's OK,
   but I don't see where we have intellectual clarity on which Web
   standards belong here
   ... So that we know when we should feel really bad wrt some work
   getting done elsewhere, and when not
   ... And even then sometimes it's OK if work starts elsewhere, as
   long as it comes here in the end
   ... So clarifying this feeds goal (1), but I think it's large,
   complex and separable from (1)

   NM: Also connects with the business model -- historically what we
   work on is significantly determined by what Members will pay for and
   send engineers to work on. . .

   JJ: From the outside that looks like it's harmful to the Web: when
   important work is done elsewhere it hurts
   ... architectural integrity
   ... Should we take a stand against that, particularly when a Member
   company takes work elsewhere

   DC: It makes them more likely to move when we do, because they don't
   like what we say about Arch. Integrity

   AM: I've been in discussions at Oracle along the lines of "Which
   body do we take this work to for standarization?"
   ... My colleagues see different pluses and minuses for the different
   ... I'll send JJ something one of them wrote

   DC: The TAG history comes in 3 parts -- before the TAG, before
   publication of WebArch, after publication of WebArch
   ... Before the TAG, TBL would say to WG chairs "don't do that, it
   breaks WebArch", and eventually they pushed back and said "What is
   this WebArch of which you speak?"
   ... TAG was chartered to try to answer this question
   ... Tim Bray and Ian Jacobs did a lot of work, Ian catalysed a lot
   ... We sort of knew what the architecture was we were writing
   ... We took the document through the Process, and published in 2004,
   felt pretty good
   ... Well-received
   ... Since then we've done some stuff. . ..

   NM: The other publications we do, starting in overlap with WebArch,
   are Findings
   ... Not usually in the Process, vary in quality and impact
   ... Authoritative Metadata is a good example
   ... either complementing or fleshing out aspects of WebArch

   JJ: Do we go back to the WebArch and edit it to point to them?

   NM: No, Process issues, we have a list

   TBL: TAG work started out with Findings, we pulled some of those
   together into WebArch, since then we have not pulled findings
   ... Volume 2 has never happened -- no agreement on pulling together
   new stuff, or expanding V1 to cover e.g. Semantic Web and WebApps

   JJ: I was suggesting you could just flag in v1 areas where later
   Findings are relevant

   NM: Possibly
   ... Picking up a few years ago we've been unsure about whether our
   working mode was having much impact
   ... We agreed three major goals: Working with HTML WG to make HTML5
   the best it can be; Figuring out how to bring WebApps into Web
   Architecture; Getting a better picture of Metadata in its many forms
   ... Focussing on the first has led us to fewer publications, but a
   lot of interaction and back-and-forth on issues

   JJ: Bringing this back to what is the scope of W3C, which we really
   need a perspective on
   ... whether we convince the world or not
   ... The TAG tends to operate one level than that -- more detailed
   architecture for one particular thing
   ... rather than the arch as a whole
   ... Everyone works topically, the AC, the AB: conversations about
   HTML5, accessibility, etc., but I don't see anyone looking at the
   entire space

   NM: There are the three pillars set out in WebArch

   JJ: I don't see where a lot of things fit with that -- Web Services?

   TVR: This notion of the landscape of standards, and how things fit
   together, hasn't been a focus

   NM: We have worked here in some cases, such as saying HTML5 spec.
   overlaps with IRI spec.

   TBL: We have talked about scope, in the early days. Connects with
   the question of how we find new work.
   ... Not just what is our scope, but how our scope expands
   ... Research is important in feeding into this, for example SemWeb
   for Distributed Social Networks -- OAuth is something we missed
   ... We should bring that in

   JJ: Connection with research. I'm very positive about this, but I
   got a lot of pushback on this, including from the AB.
   ... Position was a bit that our Members have 1000s of research
   staff, what could we hope to do

   JJ: Reformulating to put "Where standards come" first leaves a place
   for this -- not only push from the Members, but pull from the Team:
   if the Team is seen to be technically savvy because of research
   credibility, that helps

   <Zakim> DanC_2, you wanted to talk about writing resources

   DC: We have fallen below a critical mass of writing resources
   ... For example, the deep linking area was something we felt we
   should be involved, but couldn't marshal the resources
   ... I took an action to try to get resources for this, but haven't
   made progress

   <Zakim> timbl, you wanted to talk about scope, research, social web

   NM: The wrong writer would be worse than nobody

   JJ: I have heard a lot of requests already, but we are
   resource-constrained right now, very difficult to prioritize w/o
   getting those five goals agreed
   ... If you can't fit writing resources into that story, then now is
   the time you need to push hard

   DC: I wasn't special - pleading

   JJ: I understood, just emphasizing that we have to have some means
   of prioritizing

   <Zakim> noah, you wanted to talk about research

   NM: One of the interesting things is how our membership is chosen --
   writing skills come or they don't, as does technical expertise
   ... the TAG doesn't always have the people to cover some of the
   things you've mentioned
   ... For example, we just don't have the kind of expertise on
   Security that we do on HTTP
   ... Regarding research, there's a tension between WGs that invent
   new things,
   ... and WGs that ratify things that are nearly baked

   NM: The former is a strain when anybody who turns up from the
   Membership gets to participate
   ... The same thing may happen in the research area

   DA: I'm in favor of the research idea -- I like the W3C as sitting
   between industry and academia
   ... it's an important aspect of W3C for my company

   JJ: I'm looking for passionate support or critique from the AC on
   these points, to help get involved with clarifying this

   DA: The WebApps Arch document which we got closer to scoping today
   will address some of these issues

   TVR: Research is a good thing, on the top-level goal, reframe as
   "W3C is the standards body which people bring new work to"
   ... On the marketing point, it is a problem -- I see the weekly
   email newsletter as low in impact

   TVR: When there are new RECs, the press release avenue for publicity
   is also not doing as much as we need

   <Zakim> timbl, you wanted to say that people do read the newsletter

   TBL: I've had anecdotal input in the other direction wrt the

   DA: I agree

   <Zakim> johnk, you wanted to ask what we can do for "ordinary web

   JK: Amplifying what TVR said, in my company trying to involve
   ordinary employees in paying attention to WebArch, that as just one
   person it's very hard to make that connection on a broad front --
   we're a big company

   NM: The artifacts are useful, but people aren't finding them

   JJ: That also feeds into my point (1): not just clarifying our
   scope, but improving the uptake of the specs we've already published

   NM: Maybe we need new resources to focus on publicize the importance
   of our work

   JJ: Connect this back to our goal being to promulgate our standards,
   and that will work

   NM: The pushes back onto the TAG to clarify our own success criteria
   ... Adjourned until 1315

   JJ: I would like to hear from the TAG as to whether the scoping
   exercise is useful for W3C, and assuming it is, what role the TAG
   should play in that exercise: Doing, leading, participating,
   observing, . . .

   <scribe> ACTION: Noah to initiate discussion of what the TAG thinks
   of JJ's proposed scoping work, and whether and if so how the TAG
   will participate [recorded in

   <trackbot> Created ACTION-418 - Initiate discussion of what the TAG
   thinks of JJ's proposed scoping work, and whether and if so how the
   TAG will participate [on Noah Mendelsohn - due 2010-04-02].

   JJ: First relevant deadline is 26 April AB meeting, input before
   then on definition in particular would be good



   HT: HTML media type section 12.1

   <ht> [38]http://dev.w3.org/html5/spec/iana.html#text-html

     [38] http://dev.w3.org/html5/spec/iana.html#text-html

   <DanC_> ACTION: Henry edit minutes for ftf day 3 (Friday 26 March)
   [recorded in

   <trackbot> Created ACTION-419 - Edit minutes for ftf day 3 (Friday
   26 March) [on Henry S. Thompson - due 2010-04-02].

   HT: Dan says "existing content varies considerably"
   ... I'd like to expand this to give more of the history
   ... largely copied a section of existing RFC 2854

   and added new sections on interop considerations

   HT: no current language in the HTML specification regarding what
   constitutes a "conforming document"

   <DanC_> (noah, if you could find that bug, I'd appreciate it; I
   tried to find my years-old comment about definition of conforming
   document, but couldn't find it)

   <timbl> a/asserts/wejhfkjqwehfk/

   HT: "labeling a document with the text/html type asserts that the
   document is a member of the HTML family"
   ... conformance for user agents is a defined term in the HTML

   <DanC_> "labeling an orange 'made in USA' asserts that it was made
   in USA". seems OK to me.

   TBL: I prefer Dan's original text regarding "processing by user

   HT: "licenses the interpretation of that document as a member of the
   HTML family..."?

   TBL: saying "this document is the relevant specification" seems

   HT: standard text in media type registrations

   NM: how are you dealing with the older spec. issue?

   TVR: what happens when a new browser sees an HTML3 document?

   HT: language covers that and says "interpret it as HTML5"

   NM: same language says "old browsers are not buggy to interpret it
   as HTML3"

   TBL: essentially say that "this specification is designed to cover
   both interpretations"

   TVR: HTML5 says what a browser should do

   <DanC_> (I don't understand raman's point.)

   <Zakim> timbl, you wanted to complain about the asserts language

   TVR: should be careful to say that not all UAs should interpret
   HTML3 according to HTML5 specification

   <ht> timbl prefers licenses to asserts

   NM: in your IOP considerations section, I think you meant
   "conforming to the HTML spec" but there's a sense it felt like
   "conforming to the media type spec"
   ... mention the bug report I put about the lack of a link on
   conforming document

   <noah> The HTML 5 bug regarding the term "conforming document" is:

     [40] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9178

   <Zakim> DanC_, you wanted to invite the tag to try a modern
   collaborative tool [41]http://etherpad.com/a5calzHGRK

     [41] http://etherpad.com/a5calzHGRK

   DC: responded in email that this text is "close enough"

   <timbl> Labeling a document with the text/html media type licenses
   its interpretation according to this specification. This
   specification is designed so that the inter-operation of a document
   written to an earlier definition of this media type is equivalent to
   the inter-operation of that document under those earlier

   HT: will return to ACTION-407 later today

Mobile Web Considerations

   DKA: would be happy to add more technical considerations; didn't
   have time to do that yet

   DKA: "mobile is not a category we should be thinking of separately
   from the rest of the Web"

   <DanC_> "To purchase a copy, please click here." --

     [42] http://www.morganstanley.com/institutional/techresearch/mobile_internet_report122009.html

   DKA: growth of mobile Internet usage is outpacing desktop usage (and
   related statistics)

   <DanC_> [43]Mobile Slides for TAG

     [43] http://lists.w3.org/Archives/Public/www-archive/2010Mar/0038.html

   DKA: mobile device constraints: small screen, CPU weakness,
   constrained input devices, battery usage, not easily addressable,
   cost, lack of "field-upgradability"

   AM: does that mean phones don't have stable URLs?

   DKA: Correct

   TVR: I can decide in Bluetooth whether my device is visible or not,
   why can't I decide for the presence of my mobile on the network?

   DKA: I don't think anyone is thinking about this right now
   ... device capabilities: some constraints are also capabilities
   (small screen, low power)
   ... also, "with you at all times", presence of sensors (local,
   personalized context such as GPS, camera) -> uniquely personal
   ... e.g. Google Goggles - (augmented reality application)
   ... privacy is important (phone number, location) - DAP APIs will
   open up more information subject to privacy policy

   DKA: mobile networks are complex
   ... IP is a layer on top of a complex network system (already)

   <DanC_> "Access point name (APN) identifies an IP packet data
   network (PDN), that a mobile data user wants to communicate with. In
   addition to identifying a PDN, an APN may also be used to define the
   type of service, (e.g. connection to wireless application protocol
   (WAP) server, multimedia messaging service (MMS)), that is provided
   by the PDN. APN is used in 3GPP data access networks, e.g. general
   packet radio service (GPRS), evolved packet core (EPC)." --

     [44] http://en.wikipedia.org/wiki/Access_Point_Name

   DKA: often there is transcoding software - for down-sampling JPEG
   for example
   ... latency and bandwidth considerations
   ... network is designed for ubiquity though
   ... ... and simultaneous connections
   ... ...unlike WiFi
   ... brief history of mobile markup

   <DanC_> (on how to do wifi with 500 people in the room, people are
   raving about the network at pycon 2010 in atlanta, timbl)

   DKA: phone.com / openwave HDML
   ... WAP/WML
   ... XHTML basic, and then HTML5
   ... XHTML basic is a cut-down version of XHTML, which doesn't have
   draconian error handling

   <trackbot> Created ACTION-420 - What is different about XHTML basic
   1.1 (in particular re: namespaces) [on Daniel Appelquist - due

   NM: we've heard that "namespaces are hard, strict parsing is hard"
   but mobile devices are doing these kind of things

   TVR: suspect that mobile industry would prefer that mobiles didn't
   have to handle all the bad content out there
   ... messy documents will not be popular on mobile

   TBL: does everything get compressed anyway?

   DKA: will get to EXI in a bit
   ... MWBP focuses on non-smart phones

   NM: are there predictions for the phase-out of "feature phones"?

   DKA: manufactures are still producing feature phones
   ... got feedback that there was a lot of usage of feature phones in
   developing markets
   ... MWBP focuses on wide accessibility
   ... transcoding proxies exist and MWBP now covers them
   ... most phones sold worldwide are still feature phones (i.e. XHTML
   ... but some websites now only support smart phones
   ... widgets...
   ... see Apache Wookie


     [45] http://getwookie.org/

   DKA: how does HTML5 app cache relate to widgets?
   ... DAP "great power, great responsibility"
   ... web developer gets access deep into the phone (contact book,
   location, and so on)
   ... EXI provides a dramatic increase in efficiency but it's not
   widely deployed

   TBL: you have to feed it well-formed XML

   DKA: no, you can feed it non well-formed markup

   NM: you can agree on the tag dictionary and that's when you get the
   dramatic speedup

   DKA: even without a shared dictionary, you get a big speedup
   ... introduced EXI to OMTP

   TVR: does EXI have a story for CSS/JS?

   DKA: I think it works, yes

   TBL: EXI works on infoset

   HT: yes, so well-formed isn't an issue

   NM: I would define a mapping from DOM to EXI

   TBL: does EXI push you to XML serialization or not?

   DKA: I think it allows tag soup

   HT: (reads the spec. which doesn't seem to require well-formedness)

   NM: if we want to help the world understand how fast EXI is, we need
   to tell the full story

   DKA: EXI would be best at the network edge
   ... i.e. EXI implemented in a proxy

   TBL: why wouldn't origin server just produce EXI?

   DKA: was thinking about radio networks
   ... on networks - new network technologies coming "4G": LTE and
   ... idea of the "mobile web" has changed from viewing of static
   documents to "content production" (i.e. taking and sharing picture)
   - more interactive environment
   ... "greening of the Web" coming from mobile
   ... problem with apps consuming battery power
   ... it has been said that the move to web apps would make this
   problem worse
   ... how to support apps running, without wasting power?

   NM: are people aware of 4G rollout?
   ... roughly, this is the early rollout year for 4G, and will ramp up
   over the next couple of years

   DKA: yes, it's rolling out first for dongles, not phones

   NM: most mobile carriers are doing LTE, but cable companies for
   example, are doing Wimax instead
   ... for people who weren't bound to mobile...

   TBL: why dongles, not phones?

   DKA: because they think people want ubiquitous connectivity from
   their laptops

   TBL: are these entirely different technologies (Wimax and LTE)?

   DKA: not really...

   NM: Wimax is licensed spectrum, Wifi not licensed
   ... Wimax politically comes out of Wifi, but it is competing
   technically with LTE
   ... most people think LTE will win in the USA

   DKA: all have the same issues with urban, rural deployments

   NM: at a pretty low-level they are both deployed as IP networks
   ... and my impression was that you'd be doing voice over IP if you
   made a voice call

   HT: just on EXI: looking at the spec. EXI is about processing
   ... aside from corner cases around namespaces
   ... there are only few infosets that couldn't create well-formed XML

   TBL: issue was about whether you would use EXI with WF XML or tag

   NM: natural way would be to conceive a DOM, and map it to an infoset

   HT: ill-formed XML can't occur with EXI

   NM: so then convert the HTML to DOM, using HTML specification

   <DKA> [46]http://www.w3.org/TR/exi-primer/

     [46] http://www.w3.org/TR/exi-primer/

   TBL: would like the TAG to get a report on EXI usage at a future

   <trackbot> Created ACTION-421 - Frame the discussion of EXI
   deployment at a future meeting [on Henry S. Thompson - due

   DKA: browser use-case is not the only interesting one for EXI -
   mobile infrastructure is interesting too

   JK: for example, streaming TV metadata was one important driver for

text/html registration

   DKA: querying Tim's use of the word "license"

   TBL: as in "permit"

   DKA: "license" engages lawyers

   <noah> I am happy with that use of "license", but I have been
   criticized in the TAG, perhaps by TBL, for doing the same in drafts
   of the Self-Describing Web document.

   TBL: if I send you a message with metadata how to interpret the
   ... ...you can hold me to that interpretation

   <ht> where for metadata, read, inter alia, media type

   TBL: you can blame me only when you interpret based on the media
   ... if you sniff, all bets are off

   <ht> web-architecture-normative sense of 'license'

   DKA: you're talking about a moral sense of "license"?

   TBL: no, architectural sense
   ... what is the reader allowed to conclude from a message (or the
   headers of the message)?


     [47] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html

   TBL: fundamental point of webarch is the use of the media type

   NM: what can you conclude based on the applicable specifications?

   TBL: if you can think of a better word than "license"...?

   JK: "permit" (as per Tim's earlier comment)?

   HT: too weak IMO
   ... interop statement in my text is the first place where we say
   that HTML3.x will get processed reasonably effectively by processors
   which conform to this spec
   ... there is bug in HTML5 where it comes close to equating user
   agent with web browser, but there are several other conformance


     [48] http://dev.w3.org/html5/spec/infrastructure.html#conformance-requirements

   HT: if there are specific flaws in the HTML conformance
   requirements, we should say something - at least it deserves review

   <timbl> Labeling a document with the text/html media type licenses
   its interpretation according to this specification. This
   specification is designed so that the inter-operation of a document
   written to an earlier definition of this media type is equivalent to
   the interpretation of that document under those earlier

   HT: that's not descriptive
   ... the original concern was the apparent "blacklisting" of any
   server that serves HTML4 as text/html

   NM: my concern is that we should explicitly reference the old
   ... some things from old specs. are not legal in HTML
   ... so, an old UA would no longer be legal either if it processes
   things in old specs. not in HTML5
   ... this media type may be used to serve content with the following
   document types

   HT: that goes beyond what RFC 2854 did

   NM: did any of the older specs. eliminate things from previously
   older specs?

   HT: yes 4 ruled out things in 3, etc.

   TBL: what is the design goal?

   HT: will get back to that

   TVR: this is an update to the media type, yes?
   ... why don't we expand the set of documents covered by the media
   type to now include HTML 5 and point to RFC 2854.?

   TBL: point is that it shouldn't matter - if you find HTML2 engine or
   HTML5 engine, both should work

   TVR: not all implementers buy into the HTML5 strategy

   TBL: yes, an HTML2 processor should still be legal

   TVR: simply add HTML5 spec. to the existing registration and point
   to HTML5 specification

   <Zakim> noah, you wanted to ask about old specs and to

   TVR: Just use the HTML5 doctype if you want HTML2 to be processed
   according to the HTML5 spec

   NM: old stuff will be reasonably interpreted according to the new
   ... but there is an old small %tage of content where the new spec.
   will say "this is not HTML"
   ... I want the media type to say "yes it is"

   <Zakim> ht, you wanted to quibble about intent

   HT: authors of HTML5 spec. don't mean "render HTML4 docs according
   to the HTML4 spec"
   ... their goal is to render it according to how how current browsers
   do it
   ... existing registration makes no guarantee about what will be done
   with the content

   NM: it does say what a <p> says/means according to HTML4
   ... it also says "this is legal syntax"
   ... my question is about "things that would become illegal under the
   new specification"
   ... if I make the only normative spec. be HTML5, then some old
   documents will become non-conforming

   <Zakim> timbl, you wanted to say, Noah, that there is nothing about
   validity of documents

   TBL: mime type has nothing to do with conformance
   ... only about interpretation

   NM: what I'm saying is that if a document is served which now
   creates an "error" when yesterday it was valid

   HT: it's perfectly OK to say in a media-type registration that "here
   is a new header to go with that"
   ... it is appropriate to ask whether this message conforms to the
   media-type registration

   <timbl> timbl: Mime type registrations do not define conformance for
   a mime type. The specs they point to may define conformance (of
   various kinds) for documents of various kinds.

   HT: media-type has nothing to say about the document conformance

   NM: so where is it an error?

   HT: in the relevant applicable specification

   <ht> It says "this is not a JPEG" per this specification

   NM: so, are we happy that this will happen for old HTML documents
   that do not conform to HTML5?

   <ht> It does not say "serving this as image/jpg was a violation of
   [some RFC]"

   <ht> So, answer to your question, "yes, I'm happy"

   <ht> We say "this message body is not a conforming HTML document per
   HTML5", not "this message is not correctly labelled text/html"

   <timbl> ---------------------------------------------------------

   TVR: every time this comes up some implementers complain as they
   don't wish to process according to HTML5


   <trackbot> ACTION-407 -- Henry S. Thompson to propose an update to
   DanC's prose from
   l to explicitly reference or incorporate the HTML history, similarly
   to the way 2854 does -- due 2010-03-25 -- OPEN

     [49] http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html

   <trackbot> [50]http://www.w3.org/2001/tag/group/track/actions/407

     [50] http://www.w3.org/2001/tag/group/track/actions/407

   <ht> action-407 due 13 Apr

   <trackbot> ACTION-407 Propose an update to DanC's prose from
   l to explicitly reference or incorporate the HTML history, similarly
   to the way 2854 does due date now 13 Apr

     [51] http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html

   <ht> action-407: HST to redraft on basis of f2f discussion

   <trackbot> ACTION-407 Propose an update to DanC's prose from
   l to explicitly reference or incorporate the HTML history, similarly
   to the way 2854 does notes added

     [52] http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html

F2F arrangements

   DKA: meeting room is confirmed


     [53] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0018.html

Client-side identification

   NM: we (Raman) wrote a draft
   ... I took ACTION-353 to write notes about client-side
   identification in AJAX
   ... related to Raman's draft
   ... let me remind you about "metadatainURI"
   ... URI template-like usage is good
   ... we talked also about HTML forms
   ... HTML forms programs the browser to tell you about some fields
   ... if the form came from the same authority as the URI assignment
   authority, then it's definitely OK
   ... but if it comes from some other authority then it might be OK
   ... then we have the Google Maps case...
   ... there's a URI for the map, centered at a lat/long
   ... Google knows it has created URIS in this way
   ... app sends me some AJAX
   ... client constructs a URI probably with lat/long
   ... can use back/forward button
   ... but can also email that URI to someone else
   ... next time Google sees it, it will be at the server
   ... (it being the URI)

   NM: I think this is similar to the forms case
   ... would like to suggest we add a story to Raman's finding
   ... you have encoded information about the URI Policy
   ... URIs going to conceptually different resources
   ... there's an interesting story to tell there - why is that OK, why

   TVR: why is there something new here?

   NM: trying to say that this is a pattern we encourage
   ... and connect the AJAX case to the HTML forms case
   ... and why Google Maps e.g. is better than those apps which don't
   assign URIs in this way

   TVR: also the symmetric client-side case
   ... when you hand URL to the browser, # doesn't go to the server
   ... part after the # has a JSON dictionary
   ... server sends back Javascript which examines the location bar to
   get the current state of the JSON dict
   ... also analogous to the forms case

   NM: I hear you say that you are adding to what I have said
   ... would like to tie this back to the applicable specs.
   ... is this use of # acceptable?

   TVR: I believe the # in HTML says "move to the element whose id is
   linked after the #"

   NM: would like to check for "squatting"
   ... should lay out this story, how it builds on the applicable
   specs. and how it stretches those specs.

   TVR: I added some text about an interesting JS hack
   ... to my draft finding

   NM: are you willing to take an action?

   <trackbot> Created ACTION-422 - Examine the current text of his
   client state finding and update appropriately with Noah's email from
   ACTION-353 [on T.V. Raman - due 2010-04-02].

   <noah> Noah's ACTION-353 email was

     [54] http://lists.w3.org/Archives/Public/www-tag/2010Mar/0018.html

   ACTION-422: linked to ACTION-353

   <trackbot> ACTION-422 Examine the current text of his client state
   finding and update appropriately with Noah's email from ACTION-353
   notes added


Summary of Action Items

   [NEW] ACTION: Henry edit minutes for ftf day 3 (Friday 26 March)
   [recorded in
   [NEW] ACTION: John to edit ftf minutes day 1 (Wednesday 24 March)
   [recorded in
   [NEW] ACTION: John to frame section 7, security [recorded in
   [NEW] ACTION: John work on diagrams in "From Server-side to
   client-side" section of webapps material [recorded in
   [NEW] ACTION: Noah to initiate discussion of what the TAG thinks of
   JJ's proposed scoping work, and whether and if so how the TAG will
   participate [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [60]scribe.perl version 1.134
    ([61]CVS log)
    $Date: 2010/03/31 15:45:27 $

     [60] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [61] http://dev.w3.org/cvsweb/2002/scribe/

Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Monday, 12 April 2010 18:02:31 UTC