- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 12 Apr 2010 13:02:16 -0500
- To: www-tag@w3.org
by reference:
http://www.w3.org/2001/tag/2010/03/24-agenda
http://www.w3.org/2001/tag/2010/03/24-tagmem-minutes.html
http://www.w3.org/2001/tag/2010/03/25-minutes.html
http://www.w3.org/2001/tag/2010/03/26-minutes.html
by value, for tracker/search engine, etc.:
[1]W3C
[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
Attendees
Present
Noah Mendelsohn, John Kemp, Ashok Malhotra, Jonathan Rees,
Larry Masinter, T V Raman, Tim Berners-Lee, Dan Connolly, Dan
Appelquist, Henry S. Thompson
Regrets
Chair
Noah Mendelsohn
Scribes
Dan Connolly (morning), John Kemp (afternoon)
Contents
* [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 &
Privacy
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
groups
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
category:
[18]http://intertwingly.net/stories/2010/03/20/www.google.com
[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
gateways
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
acc'y
TVR: but with workflows such as flicker, that's not a reasonable
explanation
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
[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
status
<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
[22]http://dev.w3.org/html5/status/issue-status.html
[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
registry"
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
themselves
<rubys> ISSUE-30 longdesc
<trackbot> ACTION-404 Track HTML WG ISSUE-27 rel-ownership notes
added
<rubys> ISSUE-31 missing-alt
<rubys> table-summary
<rubys> ISSUE-41 decentralized-extensibility
<masinter> i think the underlying issue for this one is "who
controls"
LMM notes...
ACTION-396?
<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
closed?
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...
etc.
<masinter> policy vs. market needs
<masinter> backward compatibility vs. future
action-379?
<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
<rubys>
[28]http://intertwingly.net/blog/2010/03/20/Authoring-Conformance-Re
quirements
[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
6?"...
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
vendors...
... 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
issue"
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
issues
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
respect
<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
<pre>
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
XPAth.
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
XXX)
<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
document.
<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
minutes
<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
note
[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
[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
[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]
[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
ACTION-396?
<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
[40] http://dev.w3.org/html5/status/issue-status.html#ISSUE-041
<noah>
[41]http://www.w3.org/html/wg/wiki/ChangeProposals/fixedprefixlikexm
l
[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
restrictions.
<timbl> Change Proposal: Generalize the mechanism used for SVG and
MathML
<timbl> Change Proposal: There is no problem and the proposed remedy
is to change nothing.
<noah>
[42]http://www.w3.org/html/wg/wiki/ChangeProposals/fixedprefixsimple
[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
<noah>
[44]http://www.w3.org/html/wg/wiki/ChangeProposals/extensionslikesvg
[44] http://www.w3.org/html/wg/wiki/ChangeProposals/extensionslikesvg
<noah>
[45]http://lists.w3.org/Archives/Public/www-archive/2010Mar/0030.htm
l
[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
non-polyglot?
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;
help?]
<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
[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
documents
SR: you'd be surprised... I think I have an example from a top-20
site...
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
<rubys>
[48]http://www.google.com/#hl=en&source=hp&q=xmlns%3D%22http%3A%2F%2
Fwww.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=ae8f9
588018abe0f
[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
[roughly]
<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
<rubys>
[49]http://www.w3.org/html/wg/wiki/ChangeProposals/extensionslikesvg
[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
application/xhtml+xml?
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
tactics...]
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
likely
DC: Haven't seen anything that looks likely...I.e. meets
compatibility constraints, interesting to me, get critical mass of
support
<masinter> paulc: discussion of whether this is a political or
technical extensibility mechanism
<timbl> The counter-proposal
[50]http://lists.w3.org/Archives/Public/www-archive/2010Mar/0030.htm
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]
[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
2010-03-31].
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
ACTION-364
ACTION-364?
<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
non-conforming?
ISSUE-41?
<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
(review
[56]http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.htm
l)
[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
ambiguous
<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
not
<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
traceable
<Zakim> ht, you wanted to (eventually) move to consideration of the
large list of public identifiers in section 8.2.5.4 of the HTML5
spec
<Zakim> ht2, you wanted to point to the RFC about media type changes
<ht>
[61]http://lists.w3.org/Archives/Public/www-tag/2010Feb/0011.html
[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
text/html;
2) IETF rules for media type re-registrations requires that sort of
grandfathering;
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
re-registration
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
<DanC_>
[62]http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.htm
l
[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
[63]http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.htm
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
[64]http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.htm
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
from
[65]http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.htm
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
[66]http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.htm
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
[68]http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.htm
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
<noah>
[69]http://lists.w3.org/Archives/Public/www-tag/2010Mar/0022.html
[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
[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
perspective
... ie. one could say "don't send high accuracy information, if not
needed"
<DanC_> Dom's suggestion:
[71]http://lists.w3.org/Archives/Public/public-geolocation/2010Mar/0
014
[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
[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
information
<Zakim> noah, you wanted to talk (as usual) about extensibility
hooks
LM: which is different from the question "do you mandate use of that
hook"
<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
community
... 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?
<matt>
[73]http://dev.w3.org/geo/api/spec-source.html#privacy_for_recipient
s
[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
phones.
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
practice"
<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
1.0
<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
compromised]]
<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
APIs
<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
location.]]
<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
community
... 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
research
<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]
[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
step
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
member
<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
week
<DanC_> (i.e. sometime in the future)
close ACTION-374
<trackbot> ACTION-374 Schedule discussion of broader extensibility
mechanisms question (including this)
[82]http://lists.w3.org/Archives/Public/www-archive/2010Jan/0043.htm
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
IRIEverywhere
<noah>
[84]http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037.html
[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
(stable)
IRI-BIS document.
<masinter> look at
[86]http://tools.ietf.org/html/draft-ietf-iri-3987bis-00#section-7.1
[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]
[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
2010-03-31].
<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
in
<masinter> Section 7.1.
HTML WG should follow the following phases:
1. Confirm that a document, even with a normative reference to a
work
<scribe> in progress, can enter Candidate Recommendation state, and
that
advancement of IRI-BIS to IETF standards track is not a 'blocking'
issue. (Otherwise the contingency plan in step 3 will need to be
done
sooner.)
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
update
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]
[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
[89]http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037.html
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
remote
<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
risks
<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
[91]http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037.html
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
[92]http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037.html
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
ADJOURNED
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
[94]http://www.w3.org/2010/03/24-tagmem-irc]
[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
[96]http://www.w3.org/2010/03/24-tagmem-irc]
[NEW] ACTION: HT to run Larry's plan for closing IRIEverywhere by
the XML Core WG [recorded in
[97]http://www.w3.org/2010/03/24-tagmem-irc]
[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
[99]http://www.w3.org/2010/03/24-tagmem-irc]
[NEW] ACTION: Noah get the TAG to evaluate the decentralized
proposals in the HTML WG [recorded in
[100]http://www.w3.org/2010/03/24-tagmem-irc]
[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]W3C
[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
Attendees
Present
Daniel Appelquist, Noah Mendelsohn, Larry Masinter, Dan
Connolly, John Kemp, Jonathan Rees, Ashok Malhotra, Henry S.
Thompson, Tim Berners-Lee
Regrets
Chair
Noah Mendelsohn
Scribes
Daniel Appelquist (morning), Tim Berners-Lee (afternoon)
Contents
* [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
stuff.
... 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
meta-issues.
[agreement to go on with agenda as planned]
Issue-31?
<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
Issue-31
Noah: a lot of work done on this is in action-278 now closed.
ACTION-394?
<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
here?
... 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
[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
originally
<masinter> created by Netscape Communications in their informal
Netscape cookie
<masinter> specification ("cookie_spec.html"), from which formal
specifications
<masinter> RFC 2109 and RFC 2965 evolved. The formal specifications,
however,
<masinter> were never fully implemented in practice; RFC 2109, in
addition to
<masinter> cookie_spec.html, more closely resemble real-world
implementations
<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/
[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
attack."
<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
pattern.
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
[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
it.
... 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
[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
identification.
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
issue.
<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
defence.
<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
disclosure
<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
[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
patterns.
<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
effort"
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]; ....
q
<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
[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
[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
inspiration
[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
[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]
[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]
sniffing
ISSUE-24
ISSUE-24?
<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
ACTION-370?
<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
not)
<johnk>
[35]http://www.w3.org/2001/tag/2009/09/24-minutes.html#item03
[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
sniffing.
<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
[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
findings.
<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 ;
help?)
[39] http://www.w3.org/2001/tag/group/track/actions/386
<masinter>
[40]http://www.ietf.org/mail-archive/web/apps-discuss/current/msg012
50.html
[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/msg012
50.html
[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
[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
[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 --
OPEN
<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
broken.
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
better..."
... 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
spec.
... 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.
ACTION-370?
<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
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> [49]http://www.w3.org/2001/tag/group/track/actions/308
[49] http://www.w3.org/2001/tag/group/track/actions/308
ACTION-376?
<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
gateways
<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 "4.1.5.1 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 "4.1.5.1 Content Tasting ",
but...
<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
question
<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-con
siderations
[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)
<noah> ADJOURNED FOR LUNCH
<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
gathered
<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
local
<johnk> annotation information about the resource might result in a
superset
<johnk> of the metainformation known by the origin server. Use of
this
<johnk> response code is not required and is only appropriate when
the
<johnk> response would otherwise be 200 (OK).
<jar> [For projection:]
[55]http://www.w3.org/2001/tag/2010/03/metadata-notes.txt
[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
something.)
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-a
re-pins.html
[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
resource
<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
"Resource"
<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
[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
representation].
<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]
resource?
... 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/
[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
[63]http://masinter.blogspot.com/2010/03/resources-are-angels-urls-a
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
<masinter>
[64]http://tools.ietf.org/html/draft-masinter-dated-uri-06
[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
Masinter)
[65] http://www.ietf.org/rfc/rfc3986.txt
<DanC_> (tim, you didn't mean a 1-1 mapping between Us and Rs, I
hope)
<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
is)
<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
designated
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
web.
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
differently?
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
missing.
<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
mean.
<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
web.
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
sense
<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
[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
URI.
<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
guess.
<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
agenda.
<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]
[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
commonality]
<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
commonality
<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
workshop.
<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
session.
<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
________________________________________
<noah>
[73]http://lists.w3.org/Archives/Public/www-tag/2010Mar/0073.html
[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
future.
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/
[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
[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
documents.
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
[77] http://...doi../39585.287
<ht> JAR: There's no need for any trust, except that there are no
conspiracies
<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
Web)
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
mentioned:
[78]http://blogs.cetis.ac.uk/lmc/2010/02/09/jisc-persistent-identifi
er-meeting-general-discussion/
[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
it.
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
[missed]
[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
too
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
[79]http://www.w3.org/2010/03/25-tagmem-irc]
[NEW] ACTION: DanC to try the clarification question, blog item, or
wiki approach to metadata-in-uris vs CSRF [recorded in
[80]http://www.w3.org/2010/03/25-tagmem-irc]
Â
[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]W3C
[1] http://www.w3.org/
- DRAFT -
TAG f2f
26 Mar 2010
[2]Agenda
[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
Attendees
Present
Dan Appelquist, Tim Berners-Lee, Dan Connolly, John Kemp,
Ashok Malhotra, T.V. Raman, Henry S. Thompson, Jonathan_Rees
(in part)
Chair
Noah Mendelsohn
Scribe
Henry S. Thompson (morning), John Kemp (afternoon)
Contents
* [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
[15]http://www.w3.org/2001/tag/2010/03/26-minutes.html#action01]
<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
...
[17]http://www.w3.org/2001/tag/2010/03/web-apps-taxonomy/web-apps-ta
xonomy.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
abstracting.)
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
forth?
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/
[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
<timbl> "THE STANDARD FOR ESTABLISHING TRUST IN MULTI-PARTY WEB
APPLICATIONS."
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
ex
<timbl> [27]http://mashssl.org/technology_mashssl.html
[27] http://mashssl.org/technology_mashssl.html
<timbl>
[28]https://www.safemashups.com/downloads/MashSSL_Towards_Multi_Part
y_Trust_in_the_Internet.pdf
[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
part
... 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
do.
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
script
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
[34]http://www.w3.org/2001/tag/2010/03/26-minutes.html#action02]
<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
[35]http://www.w3.org/2001/tag/2010/03/26-minutes.html#action03]
<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
scene
... 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
short-term
... 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
can
... 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
address
... 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
[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
week
... 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
bodies
... 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
together
... 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?
Web3D?
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
etc
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
newsletter
DA: I agree
<Zakim> johnk, you wanted to ask what we can do for "ordinary web
developers"
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
[37]http://www.w3.org/2001/tag/2010/03/26-minutes.html#action04]
<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
--------------------------------
ACTION-407
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
[39]http://www.w3.org/2001/tag/2010/03/26-minutes.html#action05]
<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
specification
<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
agents"
HT: "licenses the interpretation of that document as a member of the
HTML family..."?
TBL: saying "this document is the relevant specification" seems
redundant
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
[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
specifications.
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_i
nternet_report122009.html
[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
[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
2010-04-02].
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
basic)
... but some websites now only support smart phones
... widgets...
... see Apache Wookie
[45]http://getwookie.org
[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
Wimax
... 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
infoset
... 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
soup
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
meeting
<trackbot> Created ACTION-421 - Frame the discussion of EXI
deployment at a future meeting [on Henry S. Thompson - due
2010-04-02].
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
EXI
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
message
... ...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
type
... 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)?
<noah>
[47]http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
[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
classes
<ht>
[48]http://dev.w3.org/html5/spec/infrastructure.html#conformance-req
uirements
[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
specifications.
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
versions
... 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
spec.
... 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
ACTION-407?
<trackbot> ACTION-407 -- Henry S. Thompson to propose an update to
DanC's prose from
[49]http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.htm
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
[51]http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.htm
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
2010-03-26
<trackbot> ACTION-407 Propose an update to DanC's prose from
[52]http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.htm
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
<noah>
[53]http://lists.w3.org/Archives/Public/www-tag/2010Mar/0018.html
[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
trustworthy?
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
[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
ADJOURN
Summary of Action Items
[NEW] ACTION: Henry edit minutes for ftf day 3 (Friday 26 March)
[recorded in
[55]http://www.w3.org/2001/tag/2010/03/26-minutes.html#action05]
[NEW] ACTION: John to edit ftf minutes day 1 (Wednesday 24 March)
[recorded in
[56]http://www.w3.org/2001/tag/2010/03/26-minutes.html#action01]
[NEW] ACTION: John to frame section 7, security [recorded in
[57]http://www.w3.org/2001/tag/2010/03/26-minutes.html#action03]
[NEW] ACTION: John work on diagrams in "From Server-side to
client-side" section of webapps material [recorded in
[58]http://www.w3.org/2001/tag/2010/03/26-minutes.html#action02]
[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
[59]http://www.w3.org/2001/tag/2010/03/26-minutes.html#action04]
[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