- From: Dan Connolly <connolly@w3.org>
- Date: Thu, 18 Feb 2010 16:07:38 -0600
- To: www-tag@w3.org
http://www.w3.org/2010/02/18-tagmem-minutes.html
Technical Architecture Group Teleconference
18 Feb 2010
[2]Agenda
[2] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0139.html
See also: [3]IRC log
[3] http://www.w3.org/2010/02/18-tagmem-irc
Attendees
Present
Raman, DanC, Jonathan_Rees, Ashok_Malhotra, noah, John_Kemp,
htt, Larry
Regrets
Dan_Appelquist, Tim_Berners-Lee
Chair
noah
Scribe
DanC
Contents
* [4]Topics
1. [5]Convene, review agenda
2. [6]version indicators, esp in HTML 5
3. [7]changes to 2.7 of Metadata in URIs to cover the "Google
Calendar" case
* [8]Summary of Action Items
_________________________________________________________
<trackbot> Date: 18 February 2010
<scribe> scribe: DanC
Convene, review agenda
+1 approve [9]http://www.w3.org/2001/tag/2010/02/11-minutes
[9] http://www.w3.org/2001/tag/2010/02/11-minutes
<jar> +1 approve
RESOLVED to approve
[10]http://www.w3.org/2001/tag/2010/02/11-minutes
[10] http://www.w3.org/2001/tag/2010/02/11-minutes
NM points out a few admin items (see agenda)
JAR: ftf prep material due date?
action-391?
<trackbot> ACTION-391 -- Noah Mendelsohn to prepare March 2010 ftf
agenda -- due 2010-03-08 -- OPEN
<trackbot> [11]http://www.w3.org/2001/tag/group/track/actions/391
[11] http://www.w3.org/2001/tag/group/track/actions/391
<jar> agenda input by the 8th, reading material the 15th
ACTION-391: reading material due 15 March
<trackbot> ACTION-391 Prepare March 2010 ftf agenda notes added
action-332?
<trackbot> ACTION-332 -- Dan Connolly to note that the HTML 5 spec
has a proposed design for mixing in SVG and MathML, which is said to
be the scope of IsSUE-33 mixedUIXMLNamespace-33 -- due 2010-02-25 --
PENDINGREVIEW
<trackbot> [12]http://www.w3.org/2001/tag/group/track/actions/332
[12] http://www.w3.org/2001/tag/group/track/actions/332
DanC notes the agenda is due at T-2 weeks, 10 March.
version indicators, esp in HTML 5
issue-41?
<trackbot> ISSUE-41 -- What are good practices for designing
extensible languages and for handling versioning? -- OPEN
<trackbot> [13]http://www.w3.org/2001/tag/group/track/issues/41
[13] http://www.w3.org/2001/tag/group/track/issues/41
<noah> Actually, the topic is specifically Larry's proposal
action-388?
<trackbot> ACTION-388 -- Jonathan Rees to take a look at LMM's
doctype/versioning proposal
[14]http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.htm
l -- due 2010-02-11 -- PENDINGREVIEW
[14] http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html
<trackbot> [15]http://www.w3.org/2001/tag/group/track/actions/388
[15] http://www.w3.org/2001/tag/group/track/actions/388
close action-388
<trackbot> ACTION-388 Take a look at LMM's doctype/versioning
proposal
[16]http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.htm
l closed
[16] http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html
NM notes "HTML WG chair has requested that the TAG and HTML WG
coordinate scheduling of work on this"
(quoting from the agenda)
<noah> Larry email:
[17]http://lists.w3.org/Archives/Public/www-tag/2010Feb/0140.html
[17] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0140.html
<noah>
[18]http://lists.w3.org/Archives/Public/www-tag/2010Feb/0143.html
[18] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0143.html
<noah> DC: We already did polyglot documents to my satisfaction, and
I believe Henry's, no?
<jar> nm: 1. Engage as TAG re polyglot docs?
LMM: while yes, part of the issue of polyglot documents has been
dealt with...
<noah> LM: This would make more polylot docs
<noah> DC: I'm aware of that
LMM: there are documents that are conforming XHTML that have
doctypes that the HTML 5 spec prohibits (or shuns)
<noah> LM: The browswers have to accept them, but not label them
conforming
<Zakim> ht, you wanted to separate the two issues
HT: for [various?] reasons... I think the place to pursue this is
around the media type, version indicator and conformant document
issues
(polyglot document issue? help? is there actually such an issue?)
<jar> ht: Polyglot docs is a red herring in this discussion
<noah> From our agenda for today: This relates to Larry Masinter's
HTML WG ACTION - 172, which is associated with HTML WG ISSUE - 4:
HTML Versioning and DOCTYPEs and HTML WG ISSUE - 84: Should spec
discourage use of "legacy" doctypes? (HTML WG chair has requested
that the TAG and HTML WG coordinate scheduling of work on this)
<noah> DC: Is there a polyglot doc issue?
<noah> NM: On the TAG side or HTML?
<noah> DC: Either.\
<noah> ]
<noah> HT: It was an HTML issue, we discussed in Santa Clara, and
Ian Hickson made a change.
-> [19]http://www.w3.org/Bugs/Public/show_bug.cgi?id=8154 Make it
clear that serving polyglot documents as text/htm...
[19] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8154
[20]http://lists.w3.org/Archives/Public/www-tag/2010Feb/0008.html
[20] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0008.html
^ part of a thread on Backward-compatibility of text/html media type
(ACTION-334, ACTION-364)
HT: last time I looked into this, what the HTML 5 spec said about
MIME types and DTDs wasn't acceptable
<noah> HT: See my email at
[21]http://lists.w3.org/Archives/Public/www-tag/2010Feb/0008.html
[21] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0008.html
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-18 -- OPEN
<trackbot> [22]http://www.w3.org/2001/tag/group/track/actions/364
[22] http://www.w3.org/2001/tag/group/track/actions/364
HT: looking at the 15 Feb version, I see lots of changes w.r.t. last
time I looked...
<noah> Dan, is the phrase "informed by HT's analysis" a reference to
2010Feb/0008?
<noah> HT: (looking at HTML spec) What happened to all the text that
was there on DOCTYPEs a few weeks ago?
<noah> Can we have a link to the latest, please?
<noah> HT: Seems to have gone back to status quo ante.
HT: it seems to have gone back to "you can't have any[?] DOCTYPE"
from /html/wg/ I get to [23]http://dev.w3.org/html5/spec/ dated 18
February 2010
[23] http://dev.w3.org/html5/spec/
<noah> Is it this section:
[24]http://dev.w3.org/html5/spec/syntax.html#the-doctype ?
[24] http://dev.w3.org/html5/spec/syntax.html#the-doctype
-> [25]http://dev.w3.org/html5/spec/syntax.html#the-doctype 8.1.1
The DOCTYPE
[25] http://dev.w3.org/html5/spec/syntax.html#the-doctype
<noah> HT: Most of what I commented on is no longer here.
<noah> HT: Ah, where my email refered to 7.2.5.4, now reference
8.2.5.4
8.2.5.4 The "initial" insertion mode "obsolete permitted DOCTYPE"
<noah> HT: Looks like there has been at least some response to some
of my comments. This could be a change for the better. I need to
read it.
<noah> DC: Is this a description of conforming documents or browser
behavior?
<noah> HT: That's the key question, as Noah also mentioned in (some
email?)
pretty much all of 8.2 is in the "Highlight UA text" style
<noah> NM: I read 9.1 as saying XHMTL doctypes are not constrained.
<noah> HT: I >think< so.
<noah> LM: So, it's a polyglot issue.
<noah> DC: Not my Polyglot issue.
<noah> DC: OT
<noah> DC: It's about well formed.
<htt>
[26]http://lists.w3.org/Archives/Public/www-tag/2010Feb/0057.html is
NM's message about conformant document
[26] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0057.html
<masinter> how many well-formed XML/XHTML documents are also valid
HTML?
<masinter> all? some? only those that use more than 17 elements?
DC: as long as I can write HTML 5 documents that are
XML-well-formed, my requirements are met.
<noah> NM: Next steps?
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-18 -- OPEN
<trackbot> [27]http://www.w3.org/2001/tag/group/track/actions/364
[27] http://www.w3.org/2001/tag/group/track/actions/364
<noah> DC: I have an action to get with team contacts
<noah> [28]http://www.w3.org/html/wg/tracker/actions/172
[28] http://www.w3.org/html/wg/tracker/actions/172
(er... 172 is an action, not an issue)
("issue of document vs processor conformance"... that's not an
acknowledged HTML WG issue, AFAIK)
<jar> n.b. Larry's proposal goes beyond the media type issue - tries
to make a point about gratuitous incompatibility
noodling... "to the extent that the HTML versioning issue (4)
overlaps with the media type issue (53) , we're still interested"
where 53 is short for
[29]http://www.w3.org/html/wg/tracker/issues/53
[29] http://www.w3.org/html/wg/tracker/issues/53
NM: does setting expectations that we'll have something as a group
around our ftf sound right?
HT: yes
... consider "there's a constellation of issues around the doctype,
version indicators, and the media type ..."
LMM: I think that's coming at it from the wrong end... "there's some
damage done to HTML and for [scribe lost track...
<jar> LMM: if something's bad for 3 reasons, we don't need to file 3
different issues one for each reason
LMM: dropping the DOCTYPE is bad for 3 reasons: (1) mime type (2)
polyglot (3) ...
DC: "polyglot" doesn't work for me when talking about DOCTYPES. can
we call it "XML workflows"
TVR: probably not effectively
LMM: dropping the DOCTYPE is bad for 3 reasons: (1) mime type (2)
polyglot (3) definition of what conforms
perhaps "dropping the public and system identifier from the
DOCTYPE..."
DanC: I think dropping the doctype is a good idea...
<htt> So, something such as "The current status of DOCTYPE
statements, in the HTML and XHTML syntax sections, and in the HTML
processor section, cause problems in at least four areas: the
interpretation of the text/html media type; document workflows which
use PUBLIC and/or SYSTEM identifiers; the general question of how to
determine what the spec. says with respect to what are conformant
documents; the use of DOCTYPEs as version identifiers
<htt> "The TAG is still working to pull together input in this area
-- we hope to have something to say by the end of our March f2f
DanC: DOCTYPEs are wrong almost all the time. it's a waste of bytes;
provided _dis_information most of the time
LMM: [could you help me record your reply, Larry?]
<htt> </>
<htt> I thought TV's observation about <!DOCTYPE HTML> is a good
one: it's making the W3C's 1999 XHTML mistake all over again
LMM: ... a suggestion was to put the editor's notion of document
type in a comment; that's non-sensical w.r.t. saving bytes
<htt> That is, just because we think we would all be better off if
everyone used <!DOCTYPE HTML>, we shouldn't say "only that is
allowed"
+1 something such as...
<jar> You mean: disallowing doctypes is like requiring end tags -
both change good documents into bad ones?
<masinter> ah yes, that if you are concerned about DOCTYPE being a
waste of bytes and useless to consumers: DOCTYPE on the web is
probably leftover from a XML workflow that then turned into a HTML
workflow, and by the time it hits the browser, sure it's useless,
but doesn't mean it wasn't useful during the XML workflow, which is
the workflow that needs to know what a valid document is anyway
<scribe> ACTION: Noah to update HTML WG co-chairs along the lines of
... DOCTYPE... workflow... media type.. [recorded in
[30]http://www.w3.org/2010/02/18-tagmem-minutes.html#action01]
<trackbot> Created ACTION-393 - Update HTML WG co-chairs along the
lines of ... DOCTYPE... workflow... media type.. [on Noah Mendelsohn
- due 2010-02-25].
changes to 2.7 of Metadata in URIs to cover the "Google Calendar" case
action-278?
<trackbot> ACTION-278 -- Jonathan Rees to draft changes to 2.7 of
Metadata in URIs to cover the "Google Calendar" case -- due
2010-02-07 -- PENDINGREVIEW
<trackbot> [31]http://www.w3.org/2001/tag/group/track/actions/278
[31] http://www.w3.org/2001/tag/group/track/actions/278
<jar> My cheat sheet for this action
[32]http://www.w3.org/2001/tag/2010/02/action-278-notes.txt
[32] http://www.w3.org/2001/tag/2010/02/action-278-notes.txt
<masinter> It used to be that HTML spec was actually useful for XML
workflows, and these kinds of changes, which didn't give significant
value to the XML workflow use cases, were harmful to a community not
well-represented
<noah> Proposal:
[33]http://lists.w3.org/Archives/Public/www-tag/2010Feb/0074.html
[33] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0074.html
NM: Dan said something about "that doesn't look all that different
from tyler's" ...
... a difference is: tyler's says "user agents MUST NOT ..." and I
am careful to not say that
<noah> Actually, you said one bit of mine didn't look that different
from one bit of his.
JAR: ... not sure I'm done thinking this thru... advocacy... [scribe
fails to capture]
<jar> 2 cases: google calendar, csrf defense
NM: the problem I'm seeing is tyler is saying the web should have
been carefully designed so that URIs are treated carefully and not
spread... [scribe bandwidth exceeded]
TVR: this same argument was made against REST and use of params in
the arg...
... people said "it's too fragile; don't call us if it breaks" but
[now it's expected]
DanC: all tyler has said is "don't do things that the user hasn't
asked you [the user agent] to do"
<noah> From Tyler:
<noah> A user-agent
<noah> MUST NOT disclose representations or URIs, unless either
explicitly
<noah> instructed to do so by the user or as legitimately directed
to by
<noah> presented content. Since the user may wish to keep this
information
<noah> confidential, the user-agent must not assume it can be
revealed to
<noah> third-parties.
DanC: all that says is "don't do things that the user hasn't told
you to do"
<masinter> This would require software to not do things that used to
be presumed valid. Imposing such requirements needs a stronger
justification than this one use case.
<masinter> "Everything that isn't mandatory is forbidden" is a bad
design rule.
NM: have I explictly told my web browser which parts of the disk to
store my URLs?
<johnk> is it valid for a browser to automatically send the Referer
HTTP header?
NM: I don't see that we have standing to say when a wide variety of
software conforms, retrospectively
DanC: we can just observe that the community has this rule; when
it's broken, people get pissed off
<noah> JAR: We could redraft.
NM: that's a big difference...
<noah> NM: That would be great. Who will do it?
<noah> Did JAR respond that he would? Didn't hear.
no
<noah> OK
we left it in "we should" state for now
<noah> OK
JAR: in the other case [scribe falls behind]
<jar> If the finding gives only grudging acceptance of unguessable
URIs, that leaves the CSRF in the cold
JAR: to effectively defend against CSRF...
... you have to embrace the unguessable URI pattern
<noah> DC: For every page?
JAR: well, every page that involves authority...
<Zakim> noah, you wanted to talk about word unguessable
JAR: any page that may have confidential information a bit
NM: the main thing the finding is trying to say is not really about
guessing a URI, but that by looking at a URI, you shouldn't be able
to get confidential from it
<jar> If you believe unguessable URIs are important for defense, the
finding needs to embrace them wholeheartedly, not grudgingly
JAR: I don't think anybody argues against that...
NM: but that's all the finding said...
<masinter> Is this right? HTTP has authentication methods, but using
them is awkward. So people are looking for other ways of doing
authentication, and one of those ways is suceptable to CSRF. Rather
than trying to fix HTTP authentication, people are trying to patch
this alternative so that it isn't as suceptable
JAR: the finding said "confidential"
[scribe isn't sure he's following well now]
it's not just awkwardness, masinter ; the HTTP auth mechanisms are
still ambient authority [I think]
NM: [an example... taxes or something... scribe neglected to get it]
... so where do you see the disagreement?
JAR: (a) the finding says don't put confidential info in URIs (b)
CSRF defense requires the use of unguessable URIs, i.e. confidential
info in the URI (c) hence the finding argues against
state-of-the-art defense against CSRF
LMM: picking up on somthing Roy F. said about origin...
... HTTP has authentication methods, but using them is awkward. So
people are looking for other ways of doing authentication... e.g.
not doing a username/password on every request...
... and one of the ones they've selected is vulnerable to CSRF...
<noah> NM: I tried to say: I agree that if you want URIs to be
secret, it's probably good/essential that they be unguessable.
But... I don't think the converse is true: there are lots of good
reasons for making unguessable URIs that aren't otherwise secret.
I.e. where the URIs don't have to be protected, but the mappings
from things like bank account numbers need to be.
LMM: so perhaps we should step back and look at why we picked this
method?
<noah> DC: Useful that you said "it was awkward to type uid/pwd on
every request"
<noah> DC: If you did challenge/resp with password on every request,
would it seal the CSRF hole?
<noah> JAR: Don't think so -- don't know.
<noah> DC: You'd ask for page, server would give nonce. (should have
been in http...but anyway...maybe MD5 auth). You take the number and
password, hash, and return.
<noah> JAR: How do I know password isn't wielded by attacker.
<noah> JK: You need an account with each site?
<johnk> JK: each *site* needs an "account" with each other site
<jar> i thought we agreed not to use the C-word...
<johnk> origin identifies, it doesn't authenticate
<johnk> with "secret unguessable URIs", the URI is a "bearer token"
- the bearer of the URI is authorized, regardless of identity
<Ashok> +1 to JohnK
<johnk> can the bank allow a third-party site to ask the UA to send
the cookie to the bank?
(set of notes? where?)
trackbot, status?
<johnk> ACTION - John to compare Noah and Tyler's proposals on this
subject
<trackbot> Sorry, couldn't find user - -
<johnk> ACTION - johnk to compare Noah and Tyler's proposals on this
subject
<trackbot> Sorry, couldn't find user - -
<noah> ACTION: John to compare Noah and Tyler's proposals on this
subject [recorded in
[34]http://www.w3.org/2010/02/18-tagmem-minutes.html#action02]
<trackbot> Created ACTION-394 - Compare Noah and Tyler's proposals
on this subject [on John Kemp - due 2010-02-25].
<noah> We are adjourned -- please start working on F2F input
Summary of Action Items
[NEW] ACTION: John to compare Noah and Tyler's proposals on this
subject [recorded in
[35]http://www.w3.org/2010/02/18-tagmem-minutes.html#action02]
[NEW] ACTION: Noah to update HTML WG co-chairs along the lines of
... DOCTYPE... workflow... media type.. [recorded in
[36]http://www.w3.org/2010/02/18-tagmem-minutes.html#action01]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [37]scribe.perl version 1.135
([38]CVS log)
$Date: 2010/02/18 22:05:20 $
[37] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[38] 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 Thursday, 18 February 2010 22:07:42 UTC